Tu proveedor de IA ya es un tercero TIC crítico: cómo hacer due diligence de verdad bajo DORA, AI Act y NIS2

La pregunta útil en 2026 ya no es si tu empresa usa IA. La pregunta útil es otra: si el proveedor de esa IA puede tumbar un proceso crítico, por qué sigues contratándolo como si fuera una licencia SaaS más.

Ese es el error de base. Un proveedor de modelos fundacionales, un servicio de inferencia, una plataforma de copilots empresariales o un motor de scoring embebido en un proceso financiero no es solo “tecnología”. En muchos casos es un tercero TIC con impacto directo sobre disponibilidad, integridad, confidencialidad, trazabilidad y cumplimiento normativo. Y si la entidad es financiera o depende de servicios esenciales, ese encaje ya no es una opinión jurídica creativa: está atravesado por DORA, por el AI Act y por NIS2.

La ironía aquí es bastante fina. Muchas organizaciones han dedicado años a endurecer contratos cloud, revisar SOC 2, negociar anexos de seguridad y mapear subencargados bajo GDPR. Luego llega la IA generativa y, de repente, vuelven los reflejos de 2017: demos rápidas, compras por negocio, prompts pegados desde datos internos y contratos estándar donde el derecho de auditoría cabe en letra microscópica. Regulación de primer nivel; gobernanza de cafetería.

Para CISOs y responsables de cumplimiento, el trabajo serio consiste en tratar a los proveedores de IA como terceros TIC con capas regulatorias adicionales. Eso implica revisar no solo controles de seguridad, sino también reparto de responsabilidades sobre datos de entrenamiento, logging, cambios de modelo, pruebas, subcontratación, continuidad, derechos de salida y evidencias auditables. Aquí está el quid: la IA no sustituye la diligencia de terceros; la complica.

El punto de partida legal: tres marcos distintos, una misma presión operativa

El primer marco es DORA, aplicable desde el 17 de enero de 2025 a entidades financieras de la UE. La parte decisiva para esta conversación está en el bloque de gestión del riesgo de terceros TIC, especialmente los artículos 28 a 30, más el artículo 17 sobre registro y clasificación de incidentes relacionados con las TIC, y las obligaciones de gobernanza y resiliencia de los artículos 5 a 16. Si un servicio de IA soporta funciones críticas o importantes, tu entidad no puede esconderlo en la categoría de “herramienta innovadora”. DORA no premia el entusiasmo.

El segundo es el AI Act de la UE. Entró en vigor en agosto de 2024, con aplicación escalonada. En 2026 ya no estamos en fase teórica: las prohibiciones empezaron a aplicar el 2 de febrero de 2025; las obligaciones para modelos GPAI y buena parte de la gobernanza aplican desde el 2 de agosto de 2025; y las obligaciones para sistemas de alto riesgo pasan a ser el centro operativo a partir del 2 de agosto de 2026. El mapa no es simple porque el reglamento reparte deberes entre proveedores, importadores, distribuidores, deployers —el usuario profesional que pone el sistema en uso— y, en ciertos casos, quien hace modificaciones sustanciales. Si compras IA para procesos críticos, quizá no seas el proveedor del sistema, pero sí eres de lleno el deployer, con obligaciones propias.

El tercero es NIS2, que refuerza la gestión del riesgo de ciberseguridad en entidades esenciales e importantes. El núcleo operativo está en el artículo 21: medidas de gestión de riesgos, tratamiento de incidentes, continuidad, seguridad de la cadena de suministro, seguridad en adquisición, desarrollo y mantenimiento de redes y sistemas, políticas para evaluar la eficacia de las medidas y prácticas de higiene/capacitación. Si tu proveedor de IA se integra en procesos cubiertos por NIS2, el argumento de “eso lo lleva compras” no aguanta cinco minutos.

Lo relevante no es recitar tres normas. Lo relevante es ver cómo se pisan entre sí:

• DORA obliga a gobernar el tercero TIC, inventariarlo, clasificarlo, imponer requisitos contractuales y demostrar capacidad de supervisión.
• AI Act obliga a entender la función concreta del sistema, su categoría de riesgo, la documentación técnica disponible, el reparto de responsabilidades y, para alto riesgo, el uso conforme a instrucciones, supervisión humana, calidad de datos de entrada y registro de logs.
• NIS2 obliga a elevar la exigencia sobre la cadena de suministro y a conectar ese proveedor con resiliencia operativa, incidentes y continuidad.

Juntas, las tres normas rompen una costumbre bastante cómoda: firmar con un gran proveedor de IA una versión mejorada del contrato cloud y dar el expediente por cerrado.

Cuándo un proveedor de IA debe tratarse como tercero TIC crítico o, al menos, como riesgo material

No toda herramienta con IA merece la misma profundidad. Un plugin interno para resumir reuniones no se evalúa igual que un motor de decisión que interviene en admisión de clientes, detección de fraude, autenticación, atención automatizada o clasificación de alertas de seguridad. La clave es la función, no el marketing del proveedor.

Bajo DORA, la entidad debe determinar si el servicio soporta una función crítica o importante. El reglamento empuja a mirar el impacto de una interrupción, degradación o fallo sobre continuidad del negocio, cumplimiento normativo, seguridad, prestación de servicios y estabilidad financiera. Un proveedor de IA merece tratamiento reforzado cuando concurre una combinación de factores como estos:

• Interviene en procesos de front-office o back-office cuya caída afectaría a clientes, mercado o cumplimiento.
• Procesa o accede a datos sensibles, secretos empresariales, datos regulados o telemetría de seguridad.
• Introduce automatización en decisiones con impacto jurídico o material.
• Su salida no es rápida ni barata por dependencia de prompts, embeddings, fine-tuning, conectores, APIs o formatos propietarios.
• Opera como capa única para múltiples procesos, lo que multiplica el radio de impacto.
• Subcontrata infraestructura, anotación, tuning, moderación o monitoring a una cadena opaca de proveedores.

En el AI Act, la pregunta adicional es si la solución comprada cae dentro de una categoría de alto riesgo del Anexo III o si se integra como componente de seguridad en un producto cubierto por la legislación de armonización del Anexo I. Ejemplos especialmente sensibles para banca, seguros y sectores regulados: biometría, empleo, acceso a servicios esenciales, evaluación de solvencia o riesgo, sistemas para priorización operativa que afecten derechos o acceso a servicios, y ciertos casos de detección de fraude. No toda analítica es alto riesgo. Pero basta una mala clasificación para que el contrato quede desalineado desde el primer día.

En NIS2, el foco es todavía más terrenal: si ese proveedor toca disponibilidad, integridad, autenticidad o confidencialidad de sistemas esenciales, hay riesgo de cadena de suministro. Traducido: si mañana el proveedor cambia el modelo, cae la región cloud, revoca una API, introduce un subprocesador nuevo o sufre una intrusión, tú heredas el problema. A veces también el regulador.

El error más caro: creer que el proveedor “asume el cumplimiento de IA”

Muchos contratos de IA en 2026 siguen vendiendo una ficción bastante cara: la idea de que el proveedor se ocupa del AI Act y el cliente solo consume el servicio. Esa ficción solo funciona en presentaciones comerciales.

El AI Act reparte obligaciones. Si eres deployer de un sistema de alto riesgo, no puedes limitarte a pedir una cláusula de “cumplimos con la normativa aplicable”. Debes usar el sistema conforme a las instrucciones de uso, garantizar supervisión humana cuando proceda, monitorizar el funcionamiento, conservar logs cuando estén bajo tu control, y suspender el uso si detectas riesgos que hagan que el sistema no sea conforme. Además, si tratas datos personales, el GDPR no desaparece por arte de magia porque haya una capa de IA encima.

Añade un matiz incómodo: con soluciones de IA generativa configurables, la frontera entre proveedor y deployer se mueve. Si reentrenas, ajustas de forma significativa, cambias el propósito previsto o incrustas el modelo en un flujo decisional nuevo, puedes asumir responsabilidades adicionales, incluso acercarte al rol de proveedor para ese sistema derivado. Esa zona gris es justo donde más daño hacen los contratos vagos.

La diligencia correcta parte de una idea simple: cada obligación legal tiene que aterrizar en una responsabilidad operativa y en una evidencia contractual. Si no puedes señalar qué parte aporta la documentación técnica, quién conserva logs, quién valida cambios de modelo, quién notifica incidentes, quién aprueba subcontrataciones, quién garantiza borrado y quién paga la transición de salida, no has terminado la due diligence. Has comprado fe.

Qué pide DORA a un contrato de IA y qué suele faltar

El artículo 30 de DORA establece elementos contractuales clave para servicios TIC. No está escrito pensando solo en cloud, aunque muchos lo lean así. Aplicado a IA, obliga a revisar con lupa aspectos que normalmente llegan mal resueltos en contratos estándar de plataformas de modelos.

1. Descripción clara del servicio y de la función soportada

No basta con “acceso a servicios de IA”. El contrato debe identificar qué servicio exacto se presta: inferencia, fine-tuning, embeddings, almacenamiento de prompts, guardrails, monitoring, agentes, conectores a repositorios internos, funciones de moderación, recuperación aumentada, autenticación técnica y soporte. También debe especificar si soporta una función crítica o importante. Si ese dato no aparece, el resto del paquete de control queda cojo.

Problema habitual: se firma un contrato maestro genérico y las cargas críticas se activan luego desde consola. Magnífico para despliegue. Bastante peor para resiliencia y auditoría.

2. Localización del tratamiento y cadena de subcontratación

DORA exige transparencia suficiente sobre lugares de prestación y tratamiento, y sobre condiciones de subcontratación. En IA esto es más espinoso que en SaaS tradicional. Un proveedor puede apoyarse en varios niveles: infraestructura cloud, servicios de inferencia especializados, etiquetado de datos, filtros de seguridad, proveedores de logging, almacenamientos de vectores y servicios regionales de soporte.

Si el contrato solo permite conocer los subprocesadores “en una página web actualizable”, tienes un problema de control. Bajo DORA, y por lógica de NIS2, necesitas como mínimo:

• inventario identificable de subcontratistas críticos;
• mecanismo de notificación previa o con plazo útil para objetar cambios materiales;
• clasificación de actividades subcontratadas;
• ubicaciones o regiones de tratamiento;
• confirmación de que el proveedor mantiene obligaciones equivalentes con la cadena relevante.

Si el servicio usa un modelo de un tercero y tu proveedor actúa como mera capa comercial, quieres saberlo antes, no el día que falle la API.

3. Acceso, auditoría e inspección

DORA no exige teatro contractual. Exige capacidad real de supervisión. En servicios de IA, el derecho de auditoría suele chocar con la respuesta habitual del proveedor: “por seguridad y propiedad intelectual, no permitimos auditorías directas; aquí tiene nuestro informe independiente”. A veces eso será razonable, sobre todo en proveedores de escala masiva. Pero razonable no significa suficiente por defecto.

La negociación madura combina varias capas:

• derecho de auditoría directa para supuestos gatillo definidos;
• acceso a informes independientes actualizados y de alcance claro;
• derecho a cuestionarios técnicos adicionales sobre controles específicos de IA;
• obligación de remediación con plazos;
• derecho a pruebas conjuntas o evidencias complementarias para integraciones críticas.

En proveedores de IA, el punto fino es que una auditoría puramente de seguridad puede quedarse corta. También interesa validar gobernanza de cambios de modelo, segregación de datos entre clientes, retención de prompts, controles de abuso, trazabilidad de salidas, evaluación de sesgos cuando aplique y gestión de incidentes de modelo.

4. Disponibilidad, integridad, continuidad y recuperación

DORA obliga a definir niveles de servicio y objetivos cuantificables. Con IA, un SLA de uptime general sirve de poco si no cubre el servicio que de verdad consume la entidad. Hay que aterrizar métricas por componente: disponibilidad de API, latencia máxima aceptable en procesos críticos, ventana de mantenimiento, capacidad mínima reservada, tiempo de restauración, integridad de versiones, retención de logs y soporte en incidentes.

Además, la continuidad no se agota en el proveedor. Tu entidad debe valorar si existe conmutación a otro modelo o a un modo degradado sin IA. Si una mesa de fraude, un canal de atención o una función de ciberdefensa depende de una única familia de modelos, no tienes resiliencia; tienes esperanza con presupuesto.

5. Seguridad y notificación de incidentes

DORA conecta la relación con terceros a la gestión de incidentes TIC. El contrato debe obligar al proveedor a notificar incidentes relevantes en plazos útiles para que la entidad cumpla sus propios deberes regulatorios. Si la redacción permite avisar “sin dilación indebida” pero sin concretar ventanas, prepárate para enterarte tarde.

Lo razonable es pactar:

• notificación inicial rápida para incidentes de severidad alta;
• actualizaciones periódicas;
• datos mínimos del incidente, alcance, sistemas afectados, medidas adoptadas y dependencia de subcontratistas;
• cooperación en análisis forense y evidencias;
• apoyo para clasificación regulatoria del incidente.

Si además hay datos personales, esto debe alinearse con el artículo 33 del GDPR, que exige notificación a la autoridad en 72 horas desde que el responsable tiene conocimiento de una violación de seguridad de los datos personales. Tu proveedor puede tardar 60 horas en avisarte y todavía jurar que ha actuado con diligencia. A ti eso no te arregla nada.

6. Terminación y salida

El derecho de salida es donde muchas compras de IA se convierten en matrimonio sin divorcio. DORA exige abordar terminación y estrategias de salida, especialmente para funciones críticas o importantes. En IA, salir no es solo descargar datos. Hay que pensar en:

• exportación de prompts, configuraciones, embeddings, índices, políticas, logs y métricas;
• portabilidad de conectores y agentes;
• asistencia técnica de transición;
• borrado verificable de datos y artefactos del cliente;
• tratamiento de modelos ajustados con datos del cliente;
• continuidad temporal del servicio durante la migración.

Un contrato que reconoce tu propiedad sobre “los datos” pero guarda silencio sobre derivados operativos de IA suele ser una trampa elegante.

AI Act: lo que debes pedir al proveedor para no operar a ciegas

El AI Act introduce un cambio cultural incómodo para el mercado de IA: ya no basta con vender potencia de modelo. Hay que vender también documentación, trazabilidad y reparto claro de obligaciones.

Para sistemas de alto riesgo, el reglamento impone a los proveedores requisitos sobre gestión de riesgos, gobernanza de datos, documentación técnica, registros automáticos, transparencia, supervisión humana, precisión, robustez y ciberseguridad. Esos requisitos se articulan en el reglamento y en anexos como el Anexo IV sobre documentación técnica. Si tú vas a desplegar ese sistema en una función regulada, necesitas acceso contractual a la parte de esa información que te permita operar conforme a derecho.

Eso significa pedir, como mínimo:

• declaración clara de si el sistema está o no clasificado como alto riesgo y por qué;
• propósito previsto y límites de uso;
• instrucciones de uso suficientemente precisas;
• información sobre métricas de rendimiento relevantes y condiciones de validez;
• esquema de logging disponible para el cliente;
• controles de supervisión humana y posibilidades de override;
• medidas de ciberseguridad del sistema y del ciclo de vida del modelo;
• procedimientos de gestión de cambios de modelo y de versionado;
• proceso de notificación cuando se detecten no conformidades o riesgos graves.

Si el proveedor ofrece un modelo GPAI o servicios basados en uno, la conversación cambia un poco, pero no se simplifica tanto como algunos creen. El AI Act impone obligaciones específicas a proveedores de modelos GPAI, incluidas documentación y políticas de cumplimiento relacionadas con copyright, y requisitos reforzados para modelos con riesgo sistémico. Para el cliente, la consecuencia práctica es una: pide documentación reutilizable y garantías de flujo de información a lo largo de la cadena. Si el vendedor final no puede explicar de forma verificable de qué modelo depende, cómo gestiona cambios y qué información puede compartir sobre riesgos y evaluaciones, la due diligence no está madura.

Hay otro punto poco glamuroso pero decisivo: el uso previsto. Mucha IA se contrata para una finalidad aparentemente inocua y termina desplazándose hacia decisiones o priorizaciones sensibles. En el AI Act, cambiar de uso puede cambiar obligaciones. El contrato debería prohibir, o al menos condicionar, ampliaciones de uso a revisión conjunta de impacto regulatorio, pruebas y documentación. Si no, negocio moverá el sistema a una función más crítica en dos clics y tú te enterarás al final del trimestre.

NIS2 y la cadena de suministro: donde la IA deja de ser “innovación” y se convierte en dependencia

El artículo 21 de NIS2 obliga a gestionar la seguridad de la cadena de suministro. Esto no se cumple coleccionando certificados. Se cumple entendiendo dependencias, escenarios de fallo y capacidad de respuesta.

En proveedores de IA hay, al menos, cinco riesgos de cadena de suministro que conviene tratar de forma separada:

Opacidad en la dependencia real

Tu contrato puede ser con un integrador o plataforma, mientras el servicio crítico depende de un modelo o infraestructura de otro gigante tecnológico. Si cae el upstream, tú sufrirás el downstream. La diligencia debe identificar proveedor contractual, proveedor tecnológico real y subproveedores críticos. Tres nombres, no uno.

Cambio unilateral de modelo

Un proveedor puede sustituir versiones, deprecarlas o alterar parámetros del servicio con impacto en precisión, sesgo, coste, latencia o seguridad. En sistemas conectados a controles internos o decisiones reguladas, esto no es una “mejora continua”; es un cambio potencialmente material. Debe existir obligación de preaviso, versionado, documentación del cambio y ventanas de validación.

Exposición de datos en prompts y contexto

Gran parte del riesgo no está en el modelo, sino en la capa de uso: prompts, retrieval, documentos inyectados en contexto, historiales, conectores y telemetría. La diligencia debe aclarar si esos datos se usan para entrenamiento, ajuste, evaluación, mejora del servicio o detección de abuso, y con qué controles de segregación. Esto importa para confidencialidad, secreto empresarial y GDPR.

Seguridad de integraciones y agentes

Los agentes que ejecutan acciones sobre correo, repositorios, CRM, ERP o herramientas de seguridad amplían muchísimo la superficie de ataque. NIS2 obliga a mirar adquisición, desarrollo y mantenimiento seguro. En la práctica, eso exige autenticación fuerte, segmentación, privilegios mínimos, revisión de plugins, control de secretos, logging y sandboxing cuando proceda.

Concentración

DORA ya mira el riesgo de concentración en terceros TIC. Con IA ese riesgo puede ser brutal, porque varias líneas de negocio pueden apoyarse sin saberlo en la misma familia de modelos, la misma API y la misma región cloud. El registro de información sobre terceros no debería tratar la IA como una categoría decorativa. Debería permitir ver concentración por proveedor, modelo, región, función de negocio y criticidad.

La due diligence útil: preguntas que sí cambian decisiones

La peor due diligence es la que produce un PDF bonito y ninguna decisión. La buena reduce incertidumbre material. Para proveedores de IA, eso implica preguntas que el área de compras rara vez formula sola.

Gobernanza y rol regulatorio

Pregunta quién es el proveedor legal del sistema, quién desarrolla el modelo, quién opera la inferencia y quién aloja la infraestructura. Pide identificación del rol bajo AI Act: proveedor, deployer, importador, distribuidor. Solicita una posición escrita sobre si el sistema cae o no en alto riesgo y qué anexos o categorías son relevantes.

Datos y aprendizaje

Pregunta si los prompts, outputs, documentos subidos, metadatos o telemetría se usan para entrenamiento, fine-tuning, evaluación o mejora. Exige opciones de opt-out verificables y, cuando sea necesario, configuración por defecto que impida reutilización. Si el proveedor distingue entre datos de contenido y metadatos técnicos, no aceptes una explicación superficial: ambos pueden ser sensibles.

Arquitectura y subcontratación

Pide diagrama de flujo de datos, lista de subprocesadores y subcontratistas críticos, regiones de tratamiento, cifrado en tránsito y en reposo, segregación lógica, control de acceso privilegiado y esquema de gestión de secretos. Si el proveedor no puede entregar ni un diagrama decente, imagina la calidad del resto.

Seguridad del modelo y del servicio

Pregunta por controles frente a prompt injection, data exfiltration, jailbreaks, model abuse, poisoning en pipelines de ajuste, seguridad del sistema RAG, filtrado de outputs y monitorización de comportamiento anómalo. No todos los proveedores lo resolverán del mismo modo, pero una respuesta madura distingue entre seguridad del modelo y seguridad de la aplicación que lo envuelve.

Logging, trazabilidad y explicabilidad operativa

No todo sistema de IA permite explicaciones profundas, pero sí debería permitir trazabilidad suficiente: logs de llamadas, identidad de usuario o servicio, versión del modelo, configuración relevante, fuentes de contexto y eventos de error. Si el sistema puede impactar controles o decisiones, necesitas retención compatible con auditoría y capacidad de exportación.

Continuidad y salida

Pregunta por RTO y RPO, estrategias multi-región, dependencia de terceros únicos, capacidad reservada, degradación funcional, asistencia de migración y borrado verificable al terminar. Si la respuesta sobre salida es “pueden exportar sus datos”, sigue preguntando. Los datos no son el sistema.

Incidentes y soporte regulatorio

Pregunta por tiempos de notificación, puntos de contacto, soporte durante investigaciones, conservación de evidencias y cooperación en comunicaciones regulatorias. En servicios críticos, conviene probar ese circuito con tabletop exercises. Más vale descubrir en simulación que el proveedor responde con bots.

Qué evidencias deberías exigir, no solo promesas

Una due diligence regulatoria sin evidencias es una novela corta. Para que resista auditoría interna, supervisión o revisión de segunda línea, necesitas pruebas documentales. Aquí sí tiene sentido una checklist, porque hablamos de objetos verificables, no de opiniones.

Checklist de evidencias para auditoría

• Ficha de clasificación del tercero: criticidad del servicio, procesos soportados, valoración de concentración, dependencia de subcontratistas y justificación de si soporta función crítica o importante bajo DORA.
• Mapa de roles bajo AI Act: proveedor, deployer, importador o distribuidor, con análisis de la categoría de riesgo y del propósito previsto.
• Diagrama de flujo de datos: entradas, contexto, outputs, almacenamiento, logs, regiones y subprocesadores.
• Contrato principal y anexos: seguridad, tratamiento de datos, subcontratación, SLA, continuidad, terminación, auditoría e incidentes.
• Lista de subprocesadores y terceros críticos con mecanismo de notificación de cambios.
• Documentación técnica del sistema o extractos suficientes para uso seguro y conforme, especialmente si hay componentes de alto riesgo.
• Política de uso de datos del cliente: entrenamiento, mejora del servicio, retención, borrado y segregación.
• Informes independientes de control: auditorías, certificaciones o atestaciones relevantes, con fecha, alcance y exclusiones.
• Matriz de controles de seguridad de IA: prompt injection, control de acceso, gestión de secretos, logging, filtros, monitorización y pruebas.
• Procedimiento de gestión de cambios: versionado del modelo, preaviso y validación por el cliente para cambios materiales.
• Plan de continuidad y salida: exportaciones soportadas, asistencia de transición, borrado y tiempos comprometidos.
• Playbook de incidentes con terceros: notificación, escalado, evidencias y enlace con GDPR art. 33, DORA y NIS2.

Si una entidad financiera no puede reunir al menos estas piezas para sus proveedores de IA críticos, el problema no es documental. El problema es de control real.

La tabla que evita discusiones estériles entre legal, compras, CISO y compliance

Escenarios por sector: dónde cambia de verdad la exigencia

Banca y pagos

Si la IA se usa en detección de fraude, scoring, onboarding, AML triage, soporte al cliente o priorización de alertas SOC, el proveedor puede afectar funciones que una entidad ya tiene identificadas como críticas o importantes. DORA manda aquí. Y el AI Act entra especialmente si el sistema participa en evaluación de personas o acceso a servicios. La lección operativa es dura: no pongas una caja negra cambiante en un proceso que luego tienes que defender ante auditoría, supervisor o cliente.

En pagos, además, el apetito por copilots de atención y anti-fraude choca con requisitos de disponibilidad alta, trazabilidad y respuesta rápida a incidentes. Si el proveedor no garantiza estabilidad de versión o ventanas de cambio razonables, el coste del falso positivo o del falso negativo lo pagará la entidad, no el modelo.

Seguros

En suscripción, tramitación de siniestros y atención automatizada, la IA puede afectar derechos económicos directos del cliente. Aquí la presión viene tanto por AI Act como por gobernanza interna, trazabilidad y potenciales impactos de protección de datos. El uso de modelos de lenguaje para resumir documentación médica o pericial añade otra capa de sensibilidad. Un error de extracción no es solo un bug; puede distorsionar una decisión material.

Sanidad y life sciences

Aunque el artículo está pensado para responsables europeos en general, este sector ofrece el ejemplo más claro de por qué tratar la IA como tercero TIC. Si el sistema roza diagnóstico, priorización clínica o apoyo a decisiones sensibles, la combinación entre legislación sectorial, AI Act, GDPR y ciberseguridad dispara la exigencia. Aquí la moda del “sube tus datos y te damos insights” debería activar todas las alarmas del comité de riesgos.

Operadores esenciales bajo NIS2

Energía, transporte, agua, salud, digital y otros sectores cubiertos por NIS2 comparten un patrón: la IA se está utilizando para mantenimiento predictivo, atención, clasificación de eventos, automatización operativa y ciberdefensa. Si un proveedor de IA está en esa cadena, seguridad de suministro y continuidad no son anexos legales: son capacidad operativa. La evaluación del tercero debe integrarse con resiliencia, no quedarse en compras.

Implicaciones para entidades financieras españolas

Para entidades financieras en España, la lectura práctica es directa. DORA ya está plenamente aplicable en 2026, y eso convierte a los proveedores de IA relevantes en un asunto de supervisión, no solo de innovación. Bancos, aseguradoras, entidades de pago, ESI y otros sujetos financieros que usen IA en procesos significativos tienen que poder demostrar, si se les pregunta, cuatro cosas muy concretas.

Primero, que el proveedor está correctamente inventariado y clasificado dentro del marco de terceros TIC, con evaluación de criticidad y concentración. Segundo, que el contrato contiene cláusulas suficientes sobre auditoría, subcontratación, incidentes, continuidad y salida conforme a DORA art. 30. Tercero, que la entidad ha resuelto el reparto de obligaciones bajo AI Act, sobre todo cuando el sistema se aproxima al alto riesgo o se utiliza en procesos que afectan a clientes. Cuarto, que la IA no ha entrado por la puerta lateral de negocio sin integrarse en el marco de riesgo tecnológico y operacional.

La tentación de dejar estas herramientas en una categoría especial de “innovación controlada” es comprensible. También es peligrosa. Para una entidad supervisada, un copiloto conectado a información interna o un motor externo de decisión no son gadgets. Son piezas de la cadena operativa. Y si se rompen, quien tiene que responder no es el comercial del proveedor, sino la entidad.

Cláusulas contractuales que merecen pelea, y las que suelen ser humo

No todas las cláusulas valen lo mismo. Algunas cambian tu capacidad de control; otras solo decoran el expediente.

Merecen pelea: derecho a información sobre subcontratistas críticos; preaviso de cambios materiales de modelo o arquitectura; límites claros al uso de datos para entrenamiento y mejora; obligaciones de notificación temprana de incidentes; exportación completa de artefactos operativos; soporte de transición; y remediación vinculada a hallazgos de auditoría o incidentes graves.

Suelen ser humo: compromisos genéricos de cumplimiento de “leyes aplicables”; SLAs globales que no distinguen componentes críticos; referencias vagas a “medidas estándar de la industria”; promesas de no usar datos “salvo para mejorar el servicio”; y certificados que no cubren el servicio concreto consumido.

Un ejemplo clásico: el proveedor presume de certificación de seguridad corporativa, pero el módulo de IA generativa que tú compras está excluido del alcance o depende de un tercero no cubierto. Legalmente impecable. Operativamente, bastante menos.

Qué debería hacer ahora un CISO o un responsable de cumplimiento

No hace falta una cruzada contra la IA. Hace falta meter orden donde ahora mismo abundan excepciones comerciales.

La primera decisión es inventariar todos los servicios de IA usados o en piloto, incluidos los contratados por áreas de negocio, ciberseguridad, RR. HH., atención al cliente y desarrollo. Sin inventario, no hay DORA ni NIS2 que valgan. La segunda es clasificarlos por criticidad, dependencia y categoría regulatoria. La tercera es separar los proveedores sustituibles de los que crean lock-in real. Con esos tres pasos, el programa de due diligence deja de ser abstracto.

Luego toca revisar contratos existentes con una pregunta incómoda: si mañana este proveedor cambia de modelo, sufre un incidente o corta el acceso, qué derechos concretos tiene la entidad y qué evidencias puede exigir? Si la respuesta es “depende de su política vigente en la web”, ya sabes el nivel de exposición.

También conviene alinear TPRM, privacidad, seguridad, arquitectura y negocio en una única matriz de control. La IA castiga mucho las revisiones fragmentadas. Privacidad mira datos personales. Seguridad mira accesos. Legal mira cláusulas. Negocio mira velocidad. Si nadie mira la combinación, aparecen lagunas muy caras.

La última decisión es cultural: dejar de tratar la IA como un caso especial que justifica rebajar controles. En 2026 ya no cuela. Si un proveedor de IA entra en una función crítica, debe someterse a un estándar igual o más duro que el de cualquier otro tercero TIC relevante. Lo contrario no es innovación. Es deuda regulatoria con interfaz bonita.

La conclusión incómoda

La mayoría de las organizaciones no tienen un problema de adopción de IA. Tienen un problema de gobernanza de proveedores de IA. Han aprendido a comprar cloud, outsourcing y software empresarial con cierto músculo contractual; ahora deben aplicar esa disciplina a servicios cuyo comportamiento cambia más rápido, cuya cadena de suministro es más opaca y cuyo encaje legal depende mucho del uso concreto.

DORA pone el listón en gestión del riesgo de terceros TIC y resiliencia; el AI Act obliga a entender qué sistema despliegas, para qué y con qué responsabilidades; NIS2 recuerda que la cadena de suministro no es un detalle administrativo. La suma de las tres normas deja un mensaje bastante poco poético: si tu proveedor de IA puede afectar una función crítica, debes evaluarlo, contratarlo y supervisarlo como tal.

Todo lo demás —el entusiasmo, la demo brillante, el descuento por volumen y la promesa de “cumplimiento por diseño”— está muy bien para cerrar el trimestre. Para cerrar una inspección, bastante menos.