Proveedores de IA como terceros TIC críticos: cómo hacer due diligence de verdad bajo DORA, AI Act y NIS2

El problema no es que media Europa esté comprando IA deprisa. El problema es que demasiadas entidades siguen contratando modelos, copilots, APIs y servicios gestionados como si fueran software corriente con una cláusula de confidencialidad y poco más. No lo son. Si ese proveedor toca procesos críticos, datos sensibles, decisiones con impacto regulado o controles de seguridad, estás ante un tercero TIC con potencial de concentración, opacidad técnica y dependencia operativa. Traducido al idioma que entienden el consejo, auditoría interna y el supervisor: riesgo de DORA por todos lados, obligaciones del AI Act mal repartidas y una cadena de suministro que NIS2 no te deja tratar a ojo.

La tesis de esta pieza es sencilla: en 2026, un proveedor de IA relevante debe evaluarse y contratarse como si fuera un tercero TIC de alta sensibilidad, aunque jurídicamente no todos vayan a ser “críticos” en el sentido formal de supervisión europea. Si esperas a que el regulador te diga proveedor por proveedor dónde está la línea, llegarás tarde. La diligencia debida útil no empieza con una demo brillante ni termina con un anexo de protección de datos. Empieza con una pregunta más incómoda: si este proveedor falla, alucina, cambia el modelo, subcontrata a otro o pierde acceso a computación, qué proceso de negocio, qué control y qué obligación regulatoria se rompen en tu entidad.

Aquí está el quid. DORA no regula la IA como categoría autónoma; regula el riesgo TIC, incluidos los terceros. El AI Act no es un sustituto de DORA; reparte obligaciones entre proveedor, importador, distribuidor, desplegador y, en algunos casos, fabricante de producto, con especial intensidad en sistemas de alto riesgo. NIS2 añade otra capa: seguridad de la cadena de suministro y responsabilidad de la dirección por medidas de ciberseguridad razonables. Si compras IA para scoring, fraude, autenticación, atención automatizada, monitorización de seguridad o productividad interna conectada a datos críticos, el debate ya no es “si usar IA”. El debate serio es “qué nivel de control contractual, técnico y de evidencia necesitas para no enterarte en una inspección de que estabas externalizando riesgo, no eficiencia”.

No todos los proveedores de IA son iguales, pero casi todos exigen una diligencia más dura de la habitual

Conviene separar cuatro perfiles, porque el mercado los mete en el mismo saco y el derecho no debería:

• Proveedor de modelo fundacional o GPAI: quien desarrolla y pone en el mercado un modelo de propósito general, con obligaciones específicas en el AI Act para GPAI y, si existe riesgo sistémico, exigencias reforzadas.
• Proveedor de sistema de IA: quien desarrolla o manda desarrollar un sistema concreto y lo comercializa o lo pone en servicio bajo su nombre.
• Proveedor TIC habilitador: nube, hosting, vector database, observabilidad, MLOps, etiquetado, inferencia, identity o integrador que sostiene la operación de la IA.
• Desplegador o usuario profesional: tu entidad, si utiliza el sistema en su actividad profesional, con obligaciones propias bajo el AI Act en determinados casos.

La fricción regulatoria aparece porque una sola solución puede combinar los cuatro. Un banco puede contratar un asistente de atención al cliente basado en un modelo de un tercero, alojado en una nube de otro tercero, afinado por un integrador y conectado a datos internos mediante un proveedor adicional de búsqueda semántica. Intenta luego explicar a auditoría que la dependencia material está “suficientemente cubierta” porque firmaste un MSA estándar. Suerte con eso.

DORA, en su Capítulo V sobre gestión del riesgo de terceros TIC, obliga a gestionar el ciclo completo: estrategia, registro de información, evaluación previa, condiciones contractuales, seguimiento, subcontratación, planes de salida y, para determinados acuerdos, atención reforzada a la criticidad. El punto operativo más olvidado no es el contrato. Es la clasificación previa del servicio y su encaje en funciones críticas o importantes. Si no has hecho ese ejercicio, todo lo demás se convierte en casuística cosmética.

El AI Act añade una incomodidad saludable: la etiqueta comercial del proveedor no decide tu exposición. La decide el uso. Si empleas IA en un caso que cae en alto riesgo conforme al régimen del Reglamento —por ejemplo, en ciertos usos de empleo, acceso a servicios esenciales o componentes de seguridad de productos regulados— las obligaciones del desplegador no desaparecen porque “el proveedor dice que cumple”. Tendrás que usar el sistema conforme a sus instrucciones, garantizar supervisión humana, conservar logs cuando proceda, monitorizar el funcionamiento y suspender o informar si detectas riesgos. La fantasía de “compliance by vendor slide deck” dura exactamente hasta la primera revisión seria.

DORA no menciona la magia: menciona registro, pruebas, salida y control del subcontratista

La parte menos glamurosa es la que luego acaba en requerimientos. DORA exige una gestión estructurada del riesgo TIC con responsabilidades claras del órgano de dirección, marco interno de control y una gestión específica de terceros TIC. Dos artículos son especialmente útiles para aterrizar la contratación de IA.

DORA art. 28 fija los principios clave de la gestión del riesgo de terceros TIC. No basta con saber quién es tu proveedor directo; debes considerar si la relación soporta funciones críticas o importantes, la concentración de proveedores, la localización, la dependencia y la capacidad de supervisión. Para IA, esto implica ir más allá del logo del front-end y mapear el stack real: modelo, inferencia, almacenamiento, ajuste fino, herramientas de evaluación, soporte, identity y subprocesadores.

DORA art. 30 detalla elementos contractuales para servicios TIC que soportan funciones críticas o importantes: descripción completa del servicio, ubicaciones de prestación y tratamiento, disponibilidad, integridad, confidencialidad, acceso, recuperación, derechos de acceso, inspección y auditoría, cooperación con autoridades competentes, terminación y periodos de preaviso, participación en pruebas de seguridad y gestión de subcontratación. Si el proveedor de IA no acepta discutir estos puntos, el problema no es jurídico. Es de gobernanza del riesgo.

Hay otra pieza igual de áspera y mucho más operativa: el registro de información sobre acuerdos contractuales con terceros TIC. DORA obliga a mantenerlo; las autoridades europeas han desarrollado actos y estándares técnicos para concretar su contenido. En la práctica, si hoy no puedes responder con precisión qué modelo usa cada proceso, dónde corre, qué subcontratistas intervienen, qué datos toca, cuál es la función soportada y cuál es el plan de salida, ya tienes un déficit antes incluso de mirar la ciberseguridad del proveedor.

La ironía del mercado de IA es esta: muchos proveedores venden transparencia algorítmica mientras rehúyen la transparencia operativa. El contrato dice “podemos usar subprocesadores afiliados o terceros especializados”, la documentación dice “la infraestructura puede variar para optimizar rendimiento” y el comercial insiste en que “la arquitectura exacta es propietaria”. Fenomenal para el marketing; bastante peor para DORA. La entidad necesita saber qué parte del servicio depende de qué tercero y bajo qué jurisdicción, porque la resiliencia no se puede auditar por telepatía.

El AI Act no sustituye tu due diligence: la vuelve más incómoda y más específica

La página marco de la Comisión Europea sobre el AI Act resume la arquitectura política. Lo relevante para un CISO o un responsable de cumplimiento en 2026 es otra cosa: cómo aterrizar el reparto de obligaciones cuando compras o despliegas sistemas de IA que afectan a procesos regulados. El Reglamento europeo introduce un enfoque basado en riesgo, prohíbe determinadas prácticas, regula sistemas de alto riesgo y establece obligaciones específicas para modelos de propósito general. Ese reparto obliga a distinguir tres preguntas que demasiadas compras mezclan:

• ¿Qué obligaciones recaen en el proveedor del sistema o del modelo?
• ¿Qué obligaciones recaen en tu entidad como desplegador?
• ¿Qué evidencias necesitas para demostrar que no estás usando el sistema fuera de las condiciones de cumplimiento previstas?

Si el sistema es de alto riesgo, el proveedor tendrá deberes relacionados con gestión de riesgos, gobernanza de datos, documentación técnica, logging, transparencia para usuarios, supervisión humana, precisión, robustez y ciberseguridad. Tu entidad, como desplegador, no queda mirando desde la barrera. Debe utilizar el sistema conforme a instrucciones, garantizar supervisión humana por personas competentes, controlar la calidad y pertinencia de los datos de entrada cuando le corresponda, conservar registros cuando estén bajo su control y monitorizar el funcionamiento. Si aparecen incidentes graves o riesgos, entran en juego deberes de información y medidas correctivas. El mensaje regulatorio es bastante menos sexy que el de las demos: quien despliega hereda obligaciones operativas, no solo funcionalidades.

Con modelos GPAI el ángulo cambia pero no se suaviza. Aunque el proveedor del modelo soporte una parte relevante de las obligaciones, la entidad que integra ese modelo en un flujo crítico sigue necesitando comprobar limitaciones, documentación, controles de seguridad, política de cambios, tratamiento de prompts y outputs, y restricciones de uso. La cuestión jurídica no es si el proveedor publica una “model card”. La cuestión práctica es si esa documentación sirve para decidir algo bajo control interno: umbrales de confianza, usos prohibidos, dependencia de herramientas externas, logging suficiente, segregación por cliente y respuesta ante incidentes.

Y aquí aparece una paradoja bastante europea: DORA te pide control de terceros; el AI Act te exige entender el sistema que despliegas; muchos proveedores de IA aún operan con opacidad contractual y técnica heredada del SaaS más perezoso. Eso obliga al comprador regulado a endurecer el listón. No por capricho. Porque si tú no puedes demostrar qué control existe sobre el modelo, el dato, el cambio y la dependencia, tu supervisor puede concluir que ese control simplemente no existe.

NIS2 mete presión donde más duele: la cadena de suministro y la responsabilidad del órgano de dirección

NIS2 es la regulación que nadie debería tratar como adorno si compra IA para funciones esenciales o importantes. El art. 21 de NIS2 obliga a adoptar medidas técnicas, operativas y organizativas adecuadas y proporcionadas para gestionar los riesgos de seguridad de redes y sistemas de información. Entre esas medidas figura expresamente la seguridad de la cadena de suministro, incluyendo aspectos relativos a las relaciones entre cada entidad y sus proveedores o proveedores de servicios directos.

La novedad no es que la cadena de suministro importe; eso ya lo sabíamos desde SolarWinds y unas cuantas pesadillas más. La novedad es que NIS2 lo integra con un deber de gobernanza más explícito y con un régimen sancionador y de supervisión más serio. Si un proveedor de IA participa en detección de fraude, autenticación, priorización de alertas SOC, KYC o atención al cliente con acceso a datos sensibles, la evaluación de seguridad de la cadena no puede quedarse en un cuestionario genérico de 60 preguntas y una certificación ISO descargada de una carpeta comercial.

La diligencia bajo NIS2, leída junto con DORA, obliga a tres cosas muy concretas. Primera: entender dependencias técnicas reales, no solo contractuales. Segunda: valorar el riesgo de concentración y de sustitución, especialmente si media organización depende del mismo modelo o del mismo proveedor de inferencia. Tercera: asegurar que la dirección puede aprobar el riesgo con información comprensible. Porque cuando NIS2 habla de responsabilidad de los órganos de dirección, no está pidiendo una foto de comité. Está pidiendo que alguien con capacidad decisoria entienda qué se ha externalizado y con qué compensadores.

Cómo decidir si un proveedor de IA merece trato de tercero TIC crítico o cuasi crítico

En DORA, la categoría formal de proveedores terceros TIC críticos tiene implicaciones de supervisión a nivel de la UE y no depende solo de la percepción individual de una entidad. Pero operativamente, para tu due diligence interna, la pregunta útil no es semántica. Es esta: ¿debo tratar este proveedor como si su fallo pudiera comprometer una función crítica o importante? Si la respuesta es sí, tu diligencia debe parecerse a la de un tercero TIC crítico, aunque jurídicamente no lo sea en sentido estricto.

Los indicadores prácticos son bastante tangibles:

• El servicio interviene en una función crítica o importante, o afecta a su integridad, disponibilidad o cumplimiento.
• No existe sustitución rápida sin degradación material del servicio o sin revalidación compleja.
• El proveedor puede cambiar el modelo, pesos, arquitectura o subcontratistas sin que tu entidad tenga visibilidad suficiente.
• Existe acceso a datos personales, datos bancarios, secretos empresariales, credenciales, código fuente o telemetría sensible.
• La salida requiere migrar prompts, embeddings, pipelines, evaluaciones, reglas de seguridad y procesos humanos asociados.
• El rendimiento del sistema tiene impacto en decisiones reguladas o en controles de segunda línea.

Si ves tres o más de estos factores, trata la contratación como una externalización de alta sensibilidad. No hace falta esperar a que el proveedor aparezca en una lista europea con luces de neón. La prudencia regulatoria no consiste en dramatizar todo; consiste en no trivializar dependencias materiales.

La due diligence que sirve: preguntas que un proveedor serio debe poder responder

Un buen proceso de due diligence para proveedores de IA no empieza por “¿tenéis ISO 27001?”. Empieza por preguntas cuya respuesta cambie tu decisión de uso, tu clasificación interna o tus cláusulas. Estas son las que separan el postureo documental del control real.

1. Arquitectura y dependencia real del servicio

Pide identificación del modelo o familia de modelos utilizada, versión, modalidad de despliegue, lugar de inferencia, dependencia de proveedores cloud, uso de subprocesadores, herramientas externas, retrieval, entrenamiento o ajuste fino, y política de cambios. Si el proveedor puede sustituir el modelo subyacente unilateralmente por razones de “mejora”, necesitas enterarte antes o, al menos, tener un mecanismo de notificación y validación cuando el cambio afecte a precisión, seguridad, explainability o tratamiento de datos.

En términos de evidencia, no te conformes con una arquitectura de marketing. Pide inventario de subproveedores materiales, descripción de flujos de datos, segregación lógica por cliente, controles de acceso privilegiado y documentación de release management. Si no lo documentan, luego tampoco podrás demostrar que evaluaste la dependencia conforme a DORA art. 28.

2. Uso de datos: entrenamiento, retención y aislamiento

Aquí confluyen AI Act y GDPR, aunque esta pieza no va de protección de datos en sentido amplio. Debes saber si prompts, inputs, outputs, logs o archivos cargados se utilizan para entrenamiento o mejora del servicio; durante cuánto tiempo se retienen; en qué jurisdicciones; con qué segregación; y qué controles existen para evitar exposición entre clientes. Si el proveedor ofrece “opt-out” del entrenamiento, deja por escrito que ese opt-out aplica a todos los datos y metadatos relevantes, no solo al contenido visible del prompt.

Si hay datos personales, el GDPR art. 28 sobre encargados del tratamiento y el art. 32 sobre seguridad del tratamiento se vuelven inseparables de la due diligence TIC. Si hay violaciones de seguridad de datos personales, el art. 33 impone notificación a la autoridad sin dilación indebida y, cuando sea posible, en un máximo de 72 horas. Eso significa que tu contrato con el proveedor de IA debe imponer plazos de notificación internos bastante más cortos que 72 horas. Si el proveedor pretende avisarte “sin demora injustificada” sin concretar ventana, te está trasladando su comodidad, no tu cumplimiento.

3. Seguridad y resiliencia del servicio

Pregunta por cifrado en tránsito y reposo, gestión de claves, segregación de entornos, hardening, gestión de vulnerabilidades, pruebas de penetración, seguridad de la cadena de software, logging de acciones administrativas, detección de abuso del modelo, protección frente a prompt injection y exfiltración de datos, y capacidad de restauración. Si el proveedor usa agentes o conectores, el perímetro de riesgo se expande de inmediato. Ya no compras solo inferencia; compras capacidad de actuar sobre sistemas.

NIS2 art. 21 vuelve a entrar aquí con medidas como gestión de incidentes, continuidad del negocio, seguridad en adquisición, desarrollo y mantenimiento, y evaluación de eficacia de medidas de gestión del riesgo. Un proveedor serio debe poder mostrar, como mínimo, resúmenes de pentests recientes, tiempos objetivo de recuperación, política de parcheo, evidencias de control de cambios y un proceso definido para vulnerabilidades en librerías o modelos de terceros.

4. Gobierno del modelo y calidad operativa

No basta con saber que “el modelo va bien”. Debes pedir métricas de rendimiento relevantes para tu caso de uso, tasas de error conocidas, limitaciones documentadas, mecanismos de validación, monitorización de deriva, control de alucinaciones cuando proceda, y procedimientos de rollback. Si el sistema se utiliza en una función de alto riesgo según el AI Act, la supervisión humana y la trazabilidad no son extras. Son requisitos estructurales.

Un detalle que muchos pasan por alto: exige saber qué cambios pueden hacerse sin previo aviso. En IA, la frontera entre mantenimiento y modificación material es peligrosamente elástica. Un cambio en prompt orchestration, sistema de retrieval, ranking de fuentes o ajuste de seguridad puede alterar resultados sin tocar el “modelo principal”. Si tu contrato solo cubre cambios mayores de versión, has dejado abierta media casa.

5. Subcontratación y concentración

DORA es muy claro en la sensibilidad del riesgo de subcontratación que soporte funciones críticas o importantes. Necesitas una cláusula de notificación de cambios materiales en subcontratistas, derecho de objeción cuando el cambio aumente el riesgo de forma significativa, y transparencia mínima sobre qué parte del servicio presta cada actor. El proveedor directo no puede esconder una dependencia estructural de otro proveedor cuya caída te arrastra a ti.

Añade una lectura de concentración: ¿cuántos servicios internos dependen del mismo modelo, del mismo proveedor cloud o del mismo identity layer? Lo que parece diversificación por marcas a menudo es concentración bajo el capó. Tres aplicaciones “distintas” pueden depender del mismo proveedor de inferencia. Eso, en resiliencia, no son tres cestas. Es la misma cesta con tres pegatinas.

Cláusulas contractuales que sí cambian el riesgo, y las que solo ocupan papel

Hay contratos que protegen y contratos que solo decoran una carpeta de procurement. En servicios de IA con impacto material, las cláusulas mínimas deberían alinearse con DORA art. 30 y con las necesidades operativas del AI Act y NIS2.

Derechos de auditoría y acceso a información

El proveedor intentará limitar auditorías físicas amplias, y en muchos casos es razonable. Lo que no es razonable es sustituirlas por un “confía en nuestro informe SOC” cuando el servicio soporta una función crítica o importante. La solución práctica suele estar en una combinación escalonada: cuestionarios reforzados, acceso a informes de terceros independientes, sesiones técnicas con evidencias, derecho a auditoría propia o por tercero designado ante incidentes materiales, cambios significativos o requerimientos del supervisor, y cooperación expresa con autoridades competentes. Si esta última pieza falta, DORA queda cojo.

Control de cambios

Debe existir obligación de notificar con antelación razonable cambios que afecten a seguridad, localización de datos, subcontratación material, arquitectura, modelo subyacente, funcionalidades de agente, uso de datos para entrenamiento o métricas comprometidas. Para ciertos usos, conviene exigir ventana de validación por el cliente antes de activar el cambio. Sí, ralentiza. También evita que descubras un cambio por una desviación en producción o una queja del negocio.

Incidentes y cooperación

Fija plazos concretos de notificación. No literatura. Por ejemplo: aviso inicial en horas desde la detección de incidente que afecte a confidencialidad, integridad, disponibilidad o cumplimiento; actualización periódica; informe de causa raíz; medidas de contención y remediación; preservación de evidencias; y soporte para cumplir notificaciones regulatorias. Si tu entidad está sujeta a DORA, NIS2 y GDPR, la coordinación temporal importa mucho más de lo que parece en la negociación comercial.

Continuidad, resiliencia y salida

La cláusula de salida es el campo donde más se engañan las organizaciones. “Podremos exportar nuestros datos” no resuelve la salida de un servicio de IA. También necesitas exportar configuraciones, prompts, embeddings cuando sean tuyos o deban portarse, históricos de evaluación, reglas de supervisión humana, logs necesarios, listas de exclusión, y documentación suficiente para reconfigurar el servicio sustituto. DORA exige estrategias de salida para acuerdos que soporten funciones críticas o importantes. Si tu proveedor no puede describir un proceso de transición con plazos, formatos y asistencia, tu salida es teórica.

Uso de datos, propiedad y confidencialidad reforzada

La cláusula clave no es solo “el cliente conserva la propiedad”. La clave es delimitar licencias de uso por el proveedor, prohibir usos secundarios no autorizados, fijar retención, borrado verificable, entrenamiento y mejora, y establecer tratamiento diferenciado para secretos empresariales, código, datos regulados y credenciales. En proveedores de IA, la ambigüedad sobre uso de datos es una fuente clásica de riesgo jurídico y reputacional.

Registro de información y trazabilidad: la parte que nadie quiere hacer y todos acaban necesitando

Si mañana te preguntan qué servicios de IA utilizas, en qué procesos, con qué proveedores, qué subcontratistas materiales, qué datos tocan, qué base contractual tienen, qué criticidad soportan y cuál es su plan de salida, ¿puedes responder en una tarde o necesitas una romería de correos? Esa diferencia es la distancia entre gobernanza real y gobernanza decorativa.

Para alinear con DORA, el registro interno debería capturar, como mínimo: entidad contratante, servicio, finalidad de negocio, función crítica o importante soportada, categoría de datos, jurisdicciones, proveedor directo, subproveedores materiales conocidos, modelo o familia de modelos, modalidad de despliegue, dependencia cloud, responsables internos, fecha de alta, fecha de revisión, cláusulas especiales, métricas SLA, incidentes, y estrategia de salida. Añade dos campos que en 2026 ya son imprescindibles y rara vez aparecen: política de cambios del modelo y uso de datos para entrenamiento o mejora.

Ese registro no es un museo documental. Debe alimentar decisiones: qué proveedores requieren revisión reforzada, dónde hay concentración, qué renovaciones necesitan renegociación y qué usos deben congelarse hasta disponer de evidencia suficiente. Si se queda en spreadsheet estática para contentar al auditor, has convertido DORA en papiroflexia administrativa.

Tabla comparativa: qué pedir a cada marco y qué evidencia guardar

Marco	Obligación o foco	Quién responde	Evidencia útil	Urgencia en 2026
DORA art. 28	Gestión del riesgo de terceros TIC durante todo el ciclo de vida	Entidad financiera	Clasificación de criticidad, evaluación previa, mapa de dependencias, aprobación interna	Alta
DORA art. 30	Contenido contractual para servicios TIC que soportan funciones críticas o importantes	Entidad y proveedor	Contrato con auditoría, subcontratación, localización, salida, notificación de incidentes	Alta
AI Act alto riesgo	Uso conforme a instrucciones, supervisión humana, logs, monitorización	Desplegador y proveedor, según rol	Procedimientos operativos, evidencias de supervisión, registros de uso, limitaciones documentadas	Alta si el caso de uso cae en alto riesgo
AI Act GPAI	Documentación, transparencia y obligaciones específicas del modelo de propósito general	Proveedor del modelo; el cliente debe verificar suficiencia para su uso	Documentación técnica, política de cambios, restricciones de uso, compromisos de seguridad	Media-alta
NIS2 art. 21	Seguridad de la cadena de suministro y medidas de gestión del riesgo	Entidad esencial o importante	Evaluación de proveedores, requisitos de seguridad, seguimiento continuo, escalado a dirección	Alta
GDPR arts. 28, 32 y 33	Encargo de tratamiento, seguridad y notificación de brechas	Responsable y encargado	DPA, medidas técnicas, plazos de notificación, registros de incidentes	Alta cuando hay datos personales

Checklist de evidencias para auditoría: lo que deberías poder enseñar sin improvisar

Esta sí merece lista, porque hablamos de pruebas auditables y no de consejos de sobremesa. Si compras o renuevas un servicio de IA con impacto material, guarda como mínimo estas evidencias:

• Evaluación de criticidad del servicio y su relación con funciones críticas o importantes.
• Ficha de arquitectura con modelo utilizado, modalidad de despliegue, subproveedores materiales y localización de datos.
• Resultado de due diligence técnica y de seguridad, con hallazgos, riesgos aceptados y compensadores.
• Evaluación legal y de compliance: rol bajo AI Act, necesidad de DPA, restricciones de uso, base contractual.
• Contrato y anexos con derechos de auditoría, subcontratación, notificación de incidentes, continuidad y salida.
• Política de uso interno del sistema: casos permitidos, prohibidos, supervisión humana, escalado de errores.
• Evidencia de validación previa al despliegue: pruebas funcionales, de seguridad, de sesgo o calidad si aplican, y criterios de aceptación.
• Registro de cambios del proveedor y evaluación de impacto interna cuando el servicio cambie de modelo, arquitectura o controles.
• Logs o registros operativos conservados conforme al caso de uso y a las obligaciones del AI Act o normas internas.
• Prueba de estrategia de salida: formato de exportación, dependencias de migración, contacto operativo y tiempos comprometidos.

Si una de estas pruebas no existe, no siempre significa incumplimiento automático. A veces significa algo más prosaico: que el proceso de compra fue más rápido que la capacidad de control. Y esa asimetría, en 2026, ya no se puede vender como innovación.

Errores frecuentes que están creando deuda regulatoria ahora mismo

El primero es tratar la IA generativa interna como si no fuera un servicio externo material porque “solo ayuda a empleados”. Falso consuelo. Si resume expedientes, redacta comunicaciones regulatorias, analiza alertas de fraude o asiste a analistas con acceso a datos sensibles, la criticidad viene del proceso y del acceso, no del hecho de que el usuario sea un empleado.

El segundo es pensar que un proveedor “europeo” reduce automáticamente el riesgo. Puede mejorar ciertos ángulos de jurisdicción o percepción de control, sí. Pero si su stack depende de modelos o infraestructuras de terceros fuera de la UE, la dependencia sigue ahí. El pasaporte comercial no sustituye al mapa de subcontratación.

El tercero es dejar el AI Act en manos exclusivas del equipo legal y DORA en manos exclusivas de resiliencia o procurement. Mala idea. Los usos de IA relevantes exigen un triángulo de control entre negocio, seguridad/compliance TIC y legal/privacidad. Si no existe ese triángulo, aparecerán lagunas. Siempre.

El cuarto es firmar derechos de auditoría imposibles de ejercer. Si el contrato dice que puedes auditar con 90 días de preaviso, una vez al año, en horario laboral, excluyendo subcontratistas y sin acceder a evidencias de seguridad “por confidencialidad”, no tienes un derecho. Tienes una postal.

El quinto es no probar la salida. En IA, la reversibilidad es mucho peor de lo que aparenta el botón de exportar. Cambiar de proveedor implica recalibrar prompts, validaciones, umbrales de confianza, conectores y supervisión humana. Si nunca has ensayado esa transición, tu dependencia es mayor de la que figura en el risk register.

Implicaciones para entidades financieras españolas

Para bancos, aseguradoras, EAF, gestoras, entidades de pago y fintech sujetas al perímetro europeo, el mensaje en España es especialmente claro en 2026: DORA ya no es un proyecto, es el marco operativo con el que habrá que convivir en inspecciones, auditorías internas, revisiones de outsourcing y preguntas del consejo. La IA, mientras tanto, se está colando en prevención del fraude, productividad, atención al cliente, análisis documental, scoring asistido, ciberdefensa y soporte a cumplimiento. Esa combinación multiplica el riesgo de que un servicio aparentemente accesorio acabe soportando, de hecho, una función crítica o importante.

Las entidades españolas tienen además una peculiaridad práctica: una gran parte del stack tecnológico regulado combina legado, outsourcing clásico y nuevos servicios cloud/IA adquiridos por áreas distintas. Eso complica mucho el registro de información y el control de concentración. El peligro no es solo normativo. Es operativo. Puedes descubrir demasiado tarde que el mismo proveedor de nube, identidad o modelo sostiene varios procesos de negocio, varias líneas de defensa y hasta controles de cumplimiento.

Si tu entidad opera en España y en otros países de la UE, añade un matiz: la gobernanza de IA no puede fragmentarse por jurisdicción interna mientras la dependencia técnica es común. Un único servicio de IA central puede generar obligaciones diversas según el caso de uso local, pero el control del tercero TIC debe diseñarse de forma coherente desde grupo. De lo contrario, una filial “rápida” acabará arrastrando al resto con un proveedor mal contratado para un uso demasiado sensible.

Qué deberían hacer ahora CISOs y responsables de cumplimiento, sin esperar al siguiente susto

No hace falta montar un programa mastodóntico para mejorar mucho en pocos meses. Sí hace falta disciplina. Lo primero es inventariar todos los servicios de IA en uso o piloto, incluidos los contratados por áreas de negocio con presupuesto propio. Si solo miras procurement central, verás la mitad. Lo segundo es clasificarlos por impacto en procesos, datos y dependencia tecnológica. Lo tercero es decidir qué casos merecen tratamiento reforzado de tercero TIC sensible. Lo cuarto es renegociar o condicionar renovaciones en los contratos que hoy no te dan visibilidad, auditoría, control de cambios o salida razonable. Lo quinto es diseñar un flujo de aprobación conjunta entre negocio, CISO, resiliencia, cumplimiento y legal para nuevos usos.

Y una advertencia final que en 2026 ya no admite ingenuidad: la velocidad del mercado de IA empuja a aceptar opacidad como si fuera una externalidad inevitable. No lo es. Es una decisión de riesgo. Si un proveedor no puede explicar de forma auditable qué servicio presta, con qué dependencias, con qué política de cambios, con qué controles de seguridad y con qué compromiso de salida, no te está vendiendo solo innovación. Te está vendiendo una caja negra con factura recurrente.

DORA, AI Act y NIS2 no piden que las entidades se conviertan en laboratorios de investigación en aprendizaje automático. Piden algo más mundano y más serio: que sepan qué están comprando, de quién dependen y cómo responden cuando el tercero falla. En tiempos de IA exuberante, esa exigencia suena casi anticuada. Precisamente por eso es la parte más valiosa.