Los supervisores europeos ponen el foco en la IA de frontera: más gobierno interno y menos fe ciega en el proveedor

La pregunta ya no es si la IA entra en el perímetro de la resiliencia operativa. La pregunta útil es otra: qué ocurre cuando una entidad financiera mete procesos críticos o importantes en servicios de IA que no controla, no audita de verdad y, en demasiados casos, ni siquiera ha clasificado con rigor. Ahí es donde el debate deja de sonar futurista y empieza a parecerse bastante a un problema clásico de DORA con ropa nueva.

Eso explica por qué cada vez más supervisores europeos hablan de terceros TIC, concentración y gobernanza con un tono menos ornamental y bastante más práctico. No porque la IA sea mágicamente una categoría regulatoria aparte dentro de DORA, que no lo es, sino porque muchas implantaciones reales de IA acaban dependiendo de proveedores cloud, modelos externos, APIs y cadenas de subcontratación que encajan de lleno en la lógica del reglamento: dependencia tecnológica, riesgo de concentración, necesidad de supervisión y responsabilidad indelegable del consejo.

La tesis de fondo es sencilla. Si tu entidad usa IA en operaciones, control, atención al cliente, fraude, scoring, ciberseguridad o gestión interna, el riesgo relevante no es solo “qué hace el modelo”, sino “de quién depende”, “qué pasaría si falla”, “qué capacidad tienes para detectarlo” y “si puedes seguir operando sin quedarte mirando el panel de un proveedor que promete mucho y explica poco”. DORA no nació para regular la IA, pero sirve perfectamente para pinchar esa burbuja de complacencia.

El punto regulatorio de partida: DORA no menciona la IA como fetiche, pero sí golpea donde duele

El Reglamento (UE) 2022/2554 no dedica un capítulo especial a la inteligencia artificial. Y, francamente, tampoco le hace falta. Su arquitectura gira alrededor de cinco piezas que importan mucho cuando una entidad consume IA como servicio: gobernanza y gestión del riesgo TIC, gestión y notificación de incidentes, pruebas de resiliencia operativa digital, gestión del riesgo de terceros TIC y mecanismos de intercambio de información.

La parte decisiva para este debate está en la gestión del riesgo de terceros. DORA exige una estrategia sobre riesgo derivado de terceros proveedores de servicios TIC y un registro de información que permita identificar dependencias contractuales y funcionales. Eso no es teoría. El artículo 28 obliga a las entidades financieras a gestionar el riesgo asociado a terceros proveedores de servicios TIC como parte integrante de su marco de gestión del riesgo TIC. Y el artículo 29 aprieta más: la externalización o contratación de terceros no reduce la responsabilidad última de la entidad en materia de gestión del riesgo, cumplimiento normativo ni continuidad del negocio.

Dicho de forma menos diplomática: si tu proceso depende de un proveedor de IA, el problema sigue siendo tuyo. Da igual que el proveedor tenga una marca deslumbrante, una web llena de principios éticos o un equipo comercial muy convincente. DORA no compra ese argumento. El consejo tampoco debería.

Hay otro detalle que suele pasar demasiado desapercibido. DORA no se limita a pedir que las entidades “tengan contratos”. Exige que esos acuerdos soporten una supervisión real del servicio, incluyan derechos de acceso, inspección y auditoría cuando proceda, y recojan elementos materiales como descripción de funciones, lugares de tratamiento, disponibilidad, integridad, confidencialidad, asistencia en incidentes y condiciones de terminación, entre otros requisitos del artículo 30. Cuando el servicio de IA se consume por capas —modelo, infraestructura, herramientas de ajuste, observabilidad, filtrado y soporte— la supuesta simplicidad del “lo tenemos por API” se deshace bastante deprisa.

La trampa más habitual: creer que usar IA es comprar software

Muchas entidades siguen evaluando ciertos servicios de IA como si fueran una herramienta SaaS más. Se revisa privacidad, se mira algo de seguridad, se valida el contrato estándar y a correr. El problema es que, en la práctica, un servicio de IA puede introducir riesgos operativos bastante más móviles que los de una aplicación convencional.

Un modelo puede cambiar de comportamiento sin que la entidad controle el ciclo de vida técnico completo. Puede haber modificaciones del servicio, cambios en la cadena de subprocesadores, dependencia de una infraestructura cloud concreta, límites de capacidad, variaciones de rendimiento o restricciones contractuales que compliquen la portabilidad. No hace falta dramatizar ni inventar escenarios exóticos para ver el problema: basta con leer DORA con calma y mirar cómo se consumen hoy muchos servicios de IA en el sector financiero.

Ahí aparece una confusión peligrosa. La seguridad del proveedor no equivale a la resiliencia de la entidad. Son cosas distintas. Un proveedor puede tener buenos controles internos y, aun así, generar una dependencia que deje a la entidad sin margen operativo si el servicio se degrada, cambia o deja de estar disponible en los términos esperados. DORA mira precisamente ese ángulo: la capacidad de la entidad para identificar, gestionar y reducir el impacto de dependencias tecnológicas sobre funciones críticas o importantes.

El reglamento insiste además en la proporcionalidad, pero conviene no leer esa palabra como una excusa blanda. La proporcionalidad de DORA no significa “haz poco si el tema es incómodo”; significa ajustar los controles a la naturaleza, escala y complejidad de los riesgos. Si una entidad usa IA en una función crítica o importante, el listón sube. Y sube por una razón muy poco filosófica: porque una disrupción operativa ahí duele más, cuesta más y se explica peor ante supervisor, consejo y clientes.

No hace falta una definición grandilocuente de “frontier AI” para que el riesgo sea real

El debate público se ha llenado del término frontier AI models, casi siempre con una mezcla de fascinación técnica y niebla conceptual. Conviene recortar el humo. Para una entidad financiera sujeta a DORA, la etiqueta exacta importa menos que la dependencia operativa concreta que genera el servicio utilizado. Si la entidad incorpora capacidades avanzadas de IA mediante un tercero y esas capacidades soportan procesos internos relevantes, decisiones de negocio, controles o interacción con clientes, el análisis serio empieza por ahí, no por el adjetivo de moda.

Eso no significa que la terminología sea irrelevante. Significa que, desde una perspectiva de resiliencia operativa, la prioridad es mapear funciones, dependencias, datos, contratos, escenarios de fallo y capacidad de respuesta. Si el mercado quiere discutir qué entra o no en “frontier”, estupendo. El responsable de resiliencia, mientras tanto, tiene trabajo bastante más urgente: averiguar qué parte del proceso depende de un proveedor externo, qué garantías contractuales existen y qué alternativa operativa mantiene la entidad si ese servicio no responde como esperaba.

La obsesión con la etiqueta técnica puede distraer de una realidad más incómoda. En muchas implementaciones corporativas, la IA no es un sistema aislado, sino una capa incrustada en flujos más amplios: autenticación, atención automatizada, monitorización antifraude, soporte a analistas, clasificación documental o enriquecimiento de alertas. Cuando eso ocurre, el riesgo no reside solo en el modelo, sino en la arquitectura de dependencia que la entidad ha construido a su alrededor. Y esa arquitectura sí cae de lleno bajo la lógica de DORA.

Gobernanza: el consejo no puede fingir que esto es un asunto del equipo técnico

Una de las ideas más claras de DORA está en su régimen de gobernanza. El órgano de dirección aprueba, supervisa y responde por el marco de gestión del riesgo TIC. No es una cortesía institucional. El artículo 5 coloca esa responsabilidad en el centro del reglamento. Y el artículo 6 desarrolla la obligación de contar con un marco interno sólido de gobernanza y control para gestionar el riesgo TIC.

Esto tiene una consecuencia incómoda para muchas entidades: la adopción de IA mediante terceros no puede quedarse en una conversación entre compras, tecnología y la unidad de negocio interesada. Si la herramienta soporta una función crítica o importante, o si añade una dependencia relevante de un tercero TIC, el asunto sube. Debe subir. No porque lo diga una moda de “AI governance”, sino porque DORA obliga a tratar el riesgo tecnológico con implicación real del órgano de dirección.

Aquí conviene separar dos planos que a menudo se mezclan mal. Uno es el riesgo del modelo: errores, sesgos, opacidad, uso indebido o rendimiento insuficiente. Otro es el riesgo operativo de la dependencia tecnológica: continuidad, concentración, subcontratación, acceso a datos, capacidad de salida, trazabilidad contractual, tiempos de respuesta, notificación de incidentes y pruebas. DORA se mueve sobre todo en este segundo plano, aunque en la práctica ambos se toquen constantemente.

Cuando una entidad no distingue entre ambos, el resultado suele ser una gobernanza decorativa. Se crea un comité de IA, se redactan principios generales y se deja intacto el punto verdaderamente delicado: quién decide si un proveedor de IA puede entrar en una función crítica, con qué umbrales, con qué controles contractuales y con qué plan de sustitución o continuidad. Eso ya no es una conversación teórica. Es gobierno corporativo puro.

La palabra incómoda es concentración

DORA tiene una preocupación visible por el riesgo de concentración en terceros proveedores de servicios TIC. No es casualidad. El reglamento dedica atención específica a las dependencias agregadas, tanto a nivel de entidad como potencialmente a nivel sistémico, y crea un marco de supervisión para terceros críticos a escala de la UE. La lógica es evidente: si muchas entidades relevantes dependen de pocos proveedores, el fallo de uno puede propagarse con una eficacia francamente desagradable.

Ahora lleva esa lógica al mercado de IA. No hace falta afirmar más de lo que puede sostenerse para ver el patrón: en numerosos casos, las capacidades avanzadas de IA se concentran en un número limitado de proveedores, a menudo apoyados en infraestructuras cloud igualmente concentradas. Eso no convierte automáticamente cada uso de IA en un riesgo sistémico. Pero sí obliga a las entidades a preguntarse si están añadiendo una nueva capa de concentración sobre otra ya existente.

Ese análisis no puede limitarse al proveedor contractual visible. DORA pide mirar también la subcontratación y las cadenas de prestación del servicio. Si una entidad contrata una solución de IA a través de un integrador, pero el modelo, el hosting, el almacenamiento, la telemetría y parte del soporte descansan sobre terceros adicionales, la concentración puede estar más abajo de la superficie. Y justo ahí es donde muchas due diligences se quedan cortas.

Lo incómodo del asunto es que la concentración no siempre se manifiesta como “tenemos demasiados contratos con el mismo proveedor”. A veces adopta formas menos obvias: múltiples herramientas distintas que acaban apoyándose en la misma infraestructura, varias soluciones que integran el mismo modelo base o una aparente diversificación comercial que, técnicamente, depende de un puñado de plataformas subyacentes. Si tu mapa de dependencias no llega a ese nivel, probablemente tu comprensión del riesgo tampoco.

Qué exige DORA en la práctica cuando el tercero presta capacidades de IA

La pregunta operativa no es si DORA “se aplica” a la IA en abstracto, sino cómo aterrizan sus obligaciones cuando el tercero TIC incorpora o presta capacidades de IA. La respuesta está menos en inventar categorías nuevas y más en ejecutar bien las ya existentes.

Primero, la entidad tiene que clasificar correctamente la función afectada. Si el servicio soporta una función crítica o importante, cambian el nivel de exigencia contractual, la intensidad de supervisión y la atención que debe recibir dentro del marco de resiliencia. DORA no deja esa calificación al capricho comercial. Exige evaluar el impacto potencial de una interrupción y la relevancia del servicio para la continuidad y el cumplimiento.

Segundo, hace falta un registro de información robusto sobre los acuerdos con terceros TIC, conforme al artículo 28 y a los desarrollos técnicos asociados. Ese registro no debería limitarse al nombre del proveedor y la fecha de firma. Si la entidad consume IA seriamente, necesita identificar el servicio exacto, la función soportada, los datos implicados, la criticidad, las subcontrataciones relevantes, los países de prestación y almacenamiento cuando proceda, las dependencias técnicas y los mecanismos de salida. Sin eso, el mapa de riesgo es un decorado.

Tercero, el contrato debe servir para algo más que para cerrar procurement. El artículo 30 enumera elementos que, trasladados a un servicio de IA, importan mucho: descripción clara de los servicios, localizaciones, disponibilidad, integridad, confidencialidad, acceso, recuperación, asistencia en incidentes, cooperación con autoridades competentes, derechos de terminación y, cuando sea pertinente, derechos de acceso, inspección y auditoría. Si el proveedor ofrece términos estándar cerrados y la entidad acepta sin pelear los puntos críticos, no ha eliminado el riesgo; simplemente lo ha maquillado.

Cuarto, la entidad debe integrar ese servicio en su marco de monitorización, gestión de incidentes y pruebas. DORA no contempla terceros TIC como cajas negras intocables. Si un proveedor soporta una función crítica o importante, la entidad necesita saber cómo detectará fallos, qué señales usará, cómo escalará internamente y qué escenarios probará. Eso vale también cuando la “función” es una capa de IA incrustada en otro proceso operativo.

El espejismo contractual: tener cláusulas no equivale a poder usarlas

Aquí aparece uno de los problemas más viejos del compliance tecnológico, ahora reciclado con envoltorio de IA. Muchas entidades consiguen contratos que, sobre el papel, contienen derechos razonables. El problema llega después: ejercerlos cuesta, auditarlos de verdad es complejo y convertirlos en palancas operativas exige recursos, conocimiento técnico y voluntad de confrontar al proveedor cuando haga falta.

DORA no premia el fetichismo documental. Premia, si se puede usar esa palabra, la capacidad de demostrar que el marco funciona. Un derecho de auditoría que nunca se activa y que, en la práctica, se sustituye por un informe genérico del proveedor tiene valor limitado. Una cláusula de cooperación en incidentes que no fija tiempos, canales, responsabilidades y umbrales de información útil puede quedarse en una pieza decorativa. Y un plan de salida que consiste en “buscar otro proveedor si pasa algo” no merece llamarse plan.

Con servicios de IA, esta brecha entre papel y realidad puede ensancharse por varias razones. La opacidad técnica del proveedor, la rapidez de evolución del servicio, las limitaciones de negociación frente a grandes plataformas y la dependencia de componentes subyacentes ajenos al contrato principal complican la supervisión efectiva. Nada de eso exime a la entidad. Lo que hace es elevar la necesidad de priorizar qué servicios entran, para qué funciones y con qué tolerancia real al fallo.

Si una entidad no puede obtener visibilidad suficiente sobre un servicio de IA que pretende usar en una función crítica o importante, la conclusión razonable no es “ya veremos”. La conclusión razonable puede ser que ese uso no está maduro para ese contexto. DORA no exige heroísmo tecnológico. Exige control proporcionado y responsabilidad clara.

Resiliencia operativa no es solo ciberseguridad, y eso cambia la conversación sobre IA

Hay un hábito bastante extendido: cada vez que una entidad habla de terceros tecnológicos, la conversación deriva automáticamente a seguridad de la información. Cifrado, autenticación, vulnerabilidades, certificaciones, pentesting. Todo eso importa, por supuesto. Pero DORA juega en un tablero más amplio.

La resiliencia operativa digital incluye la capacidad de mantener funciones críticas o importantes frente a interrupciones, degradaciones y fallos tecnológicos de distinta naturaleza. Eso significa que una evaluación seria de un proveedor de IA no puede agotarse en un cuestionario de seguridad. También debe cubrir dependencia funcional, continuidad, procedimientos de recuperación, integración con gestión de incidentes, capacidad de sustitución, implicaciones contractuales de la salida y efectos sobre el negocio si el servicio deja de rendir como se esperaba.

Ese matiz es decisivo porque muchos servicios de IA pueden seguir “seguros” en sentido clásico y, a la vez, resultar problemáticos desde una perspectiva de resiliencia. Un servicio puede no haber sufrido una brecha y aun así volverse menos usable, menos disponible o menos compatible con el proceso de la entidad. Desde el punto de vista de DORA, lo relevante no es solo si hay compromiso de confidencialidad o integridad, sino si la entidad mantiene el control operativo suficiente sobre una función relevante.

Por eso conviene conectar DORA con otros marcos sin confundirlos. GDPR puede entrar en juego si hay tratamiento de datos personales, especialmente por los principios del artículo 5, las obligaciones del encargado en el artículo 28 y la notificación de brechas del artículo 33. NIS2 puede afectar a determinadas entidades por sus medidas de gestión del riesgo del artículo 21 y por la lógica de responsabilidad de la dirección. El futuro encaje con el AI Act añadirá obligaciones específicas para ciertos sistemas de IA. Pero nada de eso sustituye la lectura de DORA sobre dependencia operativa de terceros TIC. Lo complementa. Y a veces complica bastante más la vida, qué le vamos a hacer.

La continuidad del negocio empieza antes del incidente

Uno de los errores más frecuentes en la adopción de IA es tratar la continuidad como una cuestión de recuperación posterior. Si algo falla, ya reaccionaremos. Mala idea. En resiliencia operativa, la verdadera pregunta llega antes: qué diseño has elegido para no quedarte sin opciones cuando el servicio se degrada o deja de estar disponible de la forma esperada.

DORA obliga a contar con un marco de gestión del riesgo TIC que incluya mecanismos de continuidad y recuperación proporcionales. No hace falta exagerar la interpretación para extraer una conclusión bastante obvia: si un tercero TIC soporta una función crítica o importante, la entidad debe haber pensado de antemano cómo limitar el impacto de una interrupción relevante. Aplicado a servicios de IA, eso exige dejar de ver el proveedor como una pieza milagrosa y empezar a tratarlo como una dependencia que necesita sustitutos, controles compensatorios o procedimientos alternativos.

La forma concreta dependerá del caso. A veces la respuesta será una arquitectura con redundancia. Otras, una degradación controlada del servicio, intervención humana reforzada, reglas de respaldo no basadas en IA o separación estricta entre funciones críticas y usos accesorios. DORA no prescribe una solución única. Lo que no permite, en esencia, es la improvisación disfrazada de innovación.

Si tu entidad no puede explicar cómo seguiría prestando una función relevante si el servicio de IA deja de estar disponible o cambia de manera que afecte a la operación, el problema no es semántico. Es de resiliencia. Y, tarde o temprano, también será de gobernanza.

Pruebas: donde muchas estrategias de IA descubren que eran presentaciones

Una política interna puede decir que la entidad controla sus dependencias. Un comité puede afirmar que los riesgos están evaluados. Luego llegan las pruebas y se descubre la distancia entre el PowerPoint y la operación real. DORA dedica una parte sustancial a las pruebas de resiliencia operativa digital precisamente porque la disciplina de probar evita una de las grandes tentaciones del sector: confundir declaración de intenciones con capacidad demostrada.

El reglamento exige un programa de pruebas proporcionado al tamaño, perfil de riesgo y complejidad de la entidad, con especial intensidad en relación con funciones críticas o importantes. No todas las entidades estarán sometidas a pruebas avanzadas tipo TLPT, pero todas deben probar su resiliencia de forma adecuada. En el caso de servicios de IA de terceros, eso obliga a traducir el riesgo a escenarios concretos: indisponibilidad del servicio, degradación severa, fallo de integración, respuesta insuficiente del proveedor, corrupción de salidas, pérdida de trazabilidad o imposibilidad temporal de escalar incidencias con información útil.

La cuestión incómoda es que muchas organizaciones prueban su ciberseguridad mejor de lo que prueban sus dependencias operativas. Se simula malware, pero no la caída prolongada de una API crítica. Se mide phishing, pero no la pérdida de una capacidad automatizada que el negocio ya da por descontada. Se revisa el backup, pero no la viabilidad de un modo alternativo de operación con menor automatización. Si la IA está dentro de un proceso relevante, ese vacío se vuelve difícil de defender.

Probar no significa necesariamente montar un laboratorio espectacular. Significa diseñar ejercicios que permitan responder preguntas básicas con evidencia: cuánto tarda la entidad en detectar la incidencia, quién decide el escalado, qué procesos se ven afectados, qué workaround existe, cuánto tiempo es soportable la degradación y qué dependencia adicional aparece al activar el plan alternativo. Sin esa información, la palabra “resiliencia” pierde bastante lustre.

La salida del proveedor: el detalle que todos prometen y pocos aterrizan

Uno de los puntos más concretos de DORA en materia de terceros TIC es la necesidad de abordar las estrategias de salida. No es un adorno contractual ni una cláusula para tranquilizar al auditor. Es una exigencia central para reducir lock-in y dependencia excesiva, especialmente cuando el servicio soporta funciones críticas o importantes.

La salida, además, no se refiere solo al fin ordenado del contrato. También cubre escenarios de deterioro, fallos persistentes, cambios materiales del servicio, incumplimientos o circunstancias que obliguen a la entidad a reemplazar o reducir la dependencia del proveedor. El artículo 28 conecta esta lógica con la necesidad de contar con estrategias apropiadas para evitar la interrupción de las funciones de negocio, incluidas las derivadas del riesgo asociado a terceros TIC.

En servicios de IA, la estrategia de salida suele ser más compleja de lo que parece. No basta con decir “migramos a otro modelo”. Puede haber prompts, flujos, integraciones, datasets, herramientas de evaluación, controles de seguridad, componentes propietarios y dependencias contractuales que hagan la transición mucho más trabajosa. La portabilidad puede ser parcial, costosa o técnicamente imperfecta. Y eso antes de entrar en la parte menos glamurosa: revalidar el proceso, actualizar controles y asegurar que el servicio alternativo no introduce un riesgo distinto igual de serio.

Cuanto antes entienda la entidad esta realidad, mejor. La estrategia de salida no se improvisa cuando el proveedor ya se ha convertido en una pieza estructural del proceso. Se diseña antes, se documenta durante la relación contractual y se prueba de forma razonable cuando la criticidad lo justifica. Si no, lo que la entidad tiene no es una estrategia de salida. Es un deseo.

Qué deberían revisar ahora las entidades financieras

Si una entidad quiere tomarse en serio el cruce entre IA y DORA, hay cinco preguntas que merecen respuesta inmediata. No para llenar una plantilla, sino para descubrir dónde están los puntos ciegos.

• Primera: qué servicios de IA de terceros están ya en producción, en piloto o integrados informalmente en procesos internos. El inventario suele ser peor de lo que la organización cree.
• Segunda: qué funciones soportan exactamente y si alguna puede calificarse como crítica o importante conforme a la lógica operativa de DORA.
• Tercera: qué dependencias técnicas y contractuales existen por debajo del proveedor visible: infraestructura, subprocesadores, hosting, herramientas de soporte, monitorización o subcontrataciones relevantes.
• Cuarta: qué derechos y obligaciones concretas ha conseguido la entidad en contrato respecto a acceso, información, soporte en incidentes, continuidad, subcontratación, terminación y salida.
• Quinta: qué plan operativo existe si el servicio falla, cambia o deja de ser apto para la función que soporta.

Si alguna de estas preguntas no tiene respuesta clara, el problema no es solo de documentación. Es de control efectivo. Y ese es exactamente el tipo de hallazgo que DORA pretende sacar a la superficie.

Hay una tentación muy humana de posponer esta revisión porque la IA todavía se percibe, en algunas áreas, como un espacio experimental. El regulador, sin embargo, no suele mostrar mucha ternura con los experimentos mal encapsulados cuando acaban sosteniendo procesos relevantes. Si la tecnología está suficientemente integrada como para afectar a la operación, también lo está como para entrar en el perímetro de gobernanza, terceros TIC, pruebas y continuidad.

La objeción habitual: “DORA no puede frenar toda innovación”

Cierto. Y tampoco lo intenta. Esa objeción suele usarse como si la alternativa a una adopción rápida y flexible de IA fuera convertir la entidad en un museo del papel timbrado. Es una caricatura útil para vender proyectos, pero mala para gestionar riesgo real.

DORA no prohíbe usar servicios avanzados de terceros. Lo que hace es imponer disciplina en la forma de incorporarlos a funciones de negocio relevantes. Pide saber de qué dependes, qué ocurre si falla, quién responde, cómo se prueba y cómo sales si hace falta. Si eso frena una implantación concreta, quizá el problema no sea DORA. Quizá el problema sea que la implantación descansaba sobre supuestos demasiado optimistas.

La innovación en servicios financieros siempre ha convivido con requisitos de control más exigentes que en otros sectores. No es una anomalía; es parte del contrato regulatorio del sector. Quien crea que la IA merece una excepción tácita porque suena estratégica está leyendo mal el momento. La pregunta no es si innovar o controlar. La pregunta es si puedes innovar sin construir una dependencia operativa que luego no sabrás explicar cuando falle.

Mi lectura: la IA está empujando a DORA hacia su prueba de madurez real

La gran ironía del momento es que DORA no necesita reinventarse para lidiar con buena parte del riesgo operativo asociado a la IA de terceros. Le basta con aplicarse en serio. El reglamento ya contiene los elementos nucleares: responsabilidad del órgano de dirección, marco de gestión del riesgo TIC, disciplina contractual, supervisión de terceros, pruebas y estrategias de salida. El problema no es normativo. Es de ejecución.

Y ahí la IA actúa como acelerador. Expone con más crudeza carencias antiguas: inventarios incompletos, clasificación laxa de funciones, due diligence superficial, contratos que nadie operacionaliza, planes de salida de ficción y pruebas demasiado tímidas. Nada de eso empezó con la IA. Pero la IA puede convertir esos defectos en un riesgo más veloz, más opaco y más difícil de deshacer una vez desplegado a escala.

La conclusión, por tanto, no debería ser alarmista, pero tampoco complaciente. No hace falta sostener afirmaciones grandilocuentes para ver que el sector está entrando en una fase en la que usar IA de terceros en procesos relevantes obliga a elevar el nivel de control. No porque “Bruselas tema a la tecnología”, ese cliché ya cansa, sino porque la dependencia operativa sigue siendo dependencia operativa aunque llegue envuelta en lenguaje de transformación.

Si tu entidad aún trata la IA de terceros como una compra tecnológica rápida con validación jurídica mínima, DORA ofrece una mala noticia y una buena. La mala: ese enfoque se queda corto. La buena: el reglamento también da una hoja de ruta bastante clara para corregirlo. Identificar dependencias, gobernarlas, contratar mejor, probar más y diseñar salidas reales. Glamuroso no es. Útil, sí. Y a estas alturas, eso vale bastante más.