Cómo tratar a un proveedor de IA como tercero TIC crítico: due diligence real bajo DORA, AI Act y NIS2

El problema no es comprar IA. El problema es comprarla como si fuera software cualquiera, firmar dos anexos de privacidad y confiar en que el proveedor “ya cumple”. Ese enfoque en 2026 ya no aguanta una revisión seria de cumplimiento, y desde luego no aguanta un incidente.

Si una entidad financiera usa un modelo fundacional, un servicio de scoring asistido por IA, un copiloto para analistas, una herramienta de detección de fraude o un sistema de clasificación documental alojado por un tercero, no está adquiriendo solo funcionalidad. Está metiendo en su cadena operativa una dependencia tecnológica con impacto potencial en confidencialidad, integridad, disponibilidad, trazabilidad y, en algunos casos, en decisiones reguladas. Traducido al lenguaje que sí importa: un tercero TIC con capacidad de romper procesos críticos.

Aquí está el giro que muchas organizaciones siguen intentando esquivar: aunque el AI Act distribuya obligaciones entre proveedor y desplegador, y aunque DORA no mencione la IA como categoría mágica separada, el proveedor de IA debe evaluarse, contratarse y gobernarse como un tercero TIC. Y en bastantes casos, como un tercero TIC crítico o al menos de alta criticidad interna, aunque formalmente no haya sido designado “critical ICT third-party provider” en el sentido de supervisión paneuropea de DORA.

La diferencia no es semántica. Define qué preguntas haces antes de firmar, qué cláusulas impones, qué evidencias exiges, cómo registras la dependencia y si tendrás salida cuando el proveedor cambie el modelo, suba precios, sufra una brecha o retire una función de la noche a la mañana. Que pasa más de lo que los folletos comerciales sugieren.

El encaje regulatorio: tres normas, una sola conclusión operativa

La tesis es sencilla: DORA te obliga a gobernar el riesgo del tercero TIC; el AI Act te obliga a entender qué papel ocupa tu entidad y qué garantías necesitas del proveedor; NIS2 te empuja a tratar la cadena de suministro como superficie de ataque. Juntas, las tres normas destruyen la fantasía de la contratación ligera.

Bajo DORA, el núcleo está en el capítulo V sobre gestión del riesgo asociado a terceros prestadores de servicios TIC. Los artículos 28 a 30 son los que importan de verdad en la contratación diaria. El art. 28 exige integrar el riesgo de terceros TIC en el marco de gestión del riesgo y mantener un registro de información sobre todos los acuerdos contractuales relativos al uso de servicios TIC prestados por terceros. El art. 30 baja al barro contractual: descripción clara de funciones y servicios, lugares de prestación y tratamiento, disponibilidad, integridad, confidencialidad, acceso, recuperación, plazos de notificación, cooperación con autoridades, derechos de terminación y asistencia en salida, entre otros extremos.

¿Dónde entra la IA? En un sitio muy poco glamuroso: en la realidad material del servicio. Si el modelo se consume por API, si el entrenamiento adicional se hace en infraestructura del proveedor, si hay afinado con datos de la entidad, si el proveedor usa subencargados cloud, si registra prompts y respuestas, si los logs están fuera del EEE, si las actualizaciones del modelo son opacas o automáticas, ya estás claramente dentro del perímetro que DORA quiere que gobiernes como dependencia TIC.

El AI Act añade la segunda capa. La Comisión Europea, en su marco explicativo, recuerda que las obligaciones dependen del rol: proveedor, desplegador, importador, distribuidor o representante autorizado. Para sistemas de alto riesgo, el Reglamento impone requisitos sobre gestión del riesgo, gobernanza de datos, documentación técnica, registro de logs, transparencia e intervención humana. No todas esas obligaciones recaen en la entidad usuaria, pero ninguna entidad regulada debería contratar un sistema de alto riesgo sin garantizar contractualmente que el proveedor entrega la documentación, trazabilidad y soporte necesarios para que el desplegador cumpla con su parte.

Y NIS2 termina el trabajo. El art. 21 obliga a adoptar medidas técnicas, operativas y organizativas apropiadas, incluyendo seguridad de la cadena de suministro y la relación entre cada entidad y sus proveedores directos. Eso no convierte cualquier herramienta de IA en infraestructura crítica por arte de magia, pero sí obliga a evaluar si una dependencia sobre modelos, APIs, datasets o servicios de inferencia introduce una vía razonable de incidente sistémico, degradación operativa o exfiltración.

Las tres piezas encajan demasiado bien como para seguir fingiendo que el proveedor de IA es un simple vendedor SaaS con branding futurista.

La primera decisión que separa a los equipos maduros del resto: clasificar la criticidad antes de negociar

Muchos procesos de compra hacen justo lo contrario: primero demo, luego negocio enamorado, después seguridad, y al final legal intentando coser lo imposible. Si quieres aplicar DORA en serio, la criticidad no se decide al final. Se decide antes de pedir la propuesta comercial definitiva.

La pregunta correcta no es “¿usa IA?”. La pregunta correcta es “¿qué proceso de negocio se rompería si este servicio falla, se degrada, entrega resultados erróneos o deja de estar disponible durante 24, 72 o 120 horas?”. Ese análisis debe cruzar al menos seis variables.

Primera: impacto en procesos críticos o importantes. DORA usa esta lógica de forma constante. Si el sistema alimenta onboarding, KYC, AML transaction monitoring, scoring, detección de fraude, ciberdefensa, gestión de incidencias o atención al cliente en operaciones reguladas, no estás ante un juguete de productividad.

Segunda: nivel de autonomía decisional. Un modelo que sugiere texto para marketing no se gobierna igual que uno que prioriza alertas SAR, clasifica clientes para revisiones reforzadas o puntúa operaciones sospechosas.

Tercera: sensibilidad de datos. Si el proveedor procesa datos personales, categorías especiales, secretos empresariales, datos de pago, credenciales, código fuente o información de incidentes, la revisión deja de ser puramente TIC y entra de lleno en privacidad, secreto profesional y resiliencia.

Cuarta: sustituibilidad real. Este punto suele estar maquillado en las matrices de riesgo. Que haya “proveedores alternativos en el mercado” no significa que puedas cambiar en dos semanas sin revalidar prompts, flujos, integraciones, controles, sesgos, métricas y aprobaciones internas. En IA, la portabilidad comercial rara vez equivale a portabilidad operativa.

Quinta: opacidad de la cadena de suministro. Un proveedor de IA puede depender de uno o varios hyperscalers, de modelos licenciados de terceros, de embeddings externos, de servicios de moderación, de herramientas de anotación y de workforce distribuida. Cuanta más caja negra haya por debajo, mayor necesidad de derechos de información y auditoría.

Sexta: volatilidad del servicio. En software tradicional, las versiones cambian. En IA, además cambia el comportamiento estadístico. El mismo endpoint puede responder distinto tras una actualización, una recalibración de seguridad o un cambio de modelo base. Si eso afecta a controles o decisiones reguladas, la criticidad sube aunque la factura sea pequeña.

Mi criterio editorial es este: si el servicio de IA afecta a un proceso crítico o importante, usa datos sensibles, depende de infraestructura opaca y su salida no puede ejecutarse en menos de tres meses con riesgo controlado, trátalo internamente como tercero TIC crítico. Que el regulador europeo lo supervise formalmente o no es otra conversación.

DORA no te pide admirar la innovación. Te pide gobernarla

Conviene aterrizar la parte contractual, porque aquí es donde más organizaciones siguen aceptando papel mojado. DORA art. 30 no es decorativo. Si el contrato con el proveedor de IA no cubre elementos mínimos de seguridad, acceso, disponibilidad, integridad, terminación y cooperación, el problema no es de estilo jurídico: es de incumplimiento operativo.

Hay cinco focos donde los contratos de IA fallan con una frecuencia casi cómica.

1. Objeto del servicio demasiado abstracto

“Acceso a capacidades avanzadas de IA” no sirve. El contrato debe identificar si el servicio incluye inferencia, fine-tuning, retrieval augmentation, almacenamiento de prompts, entrenamiento con datos del cliente, monitorización de uso, moderación automática, logging, soporte humano, componentes open source y subservicios cloud. Si no se describe, no se controla; si no se controla, no se audita.

Además, DORA exige identificar lugares de prestación y tratamiento. En IA eso no puede limitarse a “región UE” en la ficha comercial. Hay que saber dónde se almacenan prompts, outputs, datasets de ajuste, logs de seguridad y copias de respaldo. Si el proveedor no puede decirlo con precisión contractual o por anexo técnico, mala señal.

2. Derechos de auditoría que en realidad son folletos PDF

Uno de los mayores trucos del mercado consiste en vender “transparencia” ofreciendo informes SOC 2, ISO 27001 y una página de trust center, mientras se excluyen visitas, pruebas de control, revisión de subprocesadores y acceso suficiente a evidencias. Eso puede ser razonable para servicios de baja criticidad. Para un proveedor de IA que soporta procesos críticos, no.

DORA exige que el contrato permita pleno acceso, inspección y auditoría por parte de la entidad y, cuando proceda, por autoridades competentes. La práctica madura no consiste en exigir acceso físico indiscriminado a centros de datos, que muchas veces no obtendrás, sino en diseñar un régimen escalonado: documentación previa, walkthroughs de control, derecho a entrevistas, acceso a resultados de auditoría independientes, revisión de registros relevantes, auditorías in situ cuando haya incidentes materiales o deficiencias graves, y compromiso de cooperación regulatoria.

Si el proveedor responde con el clásico “por razones de seguridad no permitimos ninguna auditoría directa”, al menos exige un mecanismo alternativo verificable. Si tampoco hay eso, la respuesta correcta no es negociar mejor. Es descartar.

3. Subcontratación sin mapa ni límites

Este es el agujero negro de la IA. Muchos proveedores no operan un stack propio de punta a punta. Revenden modelos, consumen GPU de terceros, usan anotadores externos, integran servicios de safety, almacenan en otro cloud y delegan soporte o mantenimiento. DORA art. 28 y la lógica del registro de información exigen saber qué terceros hay debajo. NIS2 art. 21 empuja en la misma dirección desde cadena de suministro.

La cláusula mínima no es una lista estática de subencargados publicada en una URL cambiante. Necesitas: inventario actualizado de subcontratistas relevantes; notificación previa de cambios materiales; derecho de objeción en supuestos definidos; obligación de flujo descendente de controles equivalentes; y confirmación de qué parte del servicio depende de cada subcontratista. Si un proveedor no puede explicar de quién depende su inferencia, tu entidad está comprando riesgo envuelto en API.

4. Continuidad de negocio escrita como si el modelo nunca fuese a fallar

Las cláusulas estándar hablan de “commercially reasonable efforts”, una expresión útil si quieres decir poco con muchas sílabas. DORA espera algo más tangible. Para IA, continuidad significa como mínimo objetivos de disponibilidad definidos, procedimientos de gestión de incidentes, RTO/RPO donde tengan sentido, prioridad de recuperación, pruebas periódicas y soporte en contingencias.

Pero con IA hay una capa extra: degradación funcional sin caída total. El servicio puede estar “up” y ser inútil porque sube la latencia, se bloquea el contexto largo, cambia el filtro de seguridad o cae la precisión de clasificación. El contrato debería permitir suspender uso en decisiones sensibles, activar modos degradados y exigir notificación de cambios materiales en arquitectura, modelo o comportamiento que afecten rendimiento, riesgos o controles.

Si tu proveedor puede cambiar el modelo base sin avisar y eso altera salidas en un proceso regulado, no tienes resiliencia. Tienes fe.

5. Salida inexistente o ficticia

DORA insiste en estrategias de salida precisamente porque las dependencias tecnológicas no se resuelven el día que aparece el problema. En IA, la salida es especialmente delicada por tres motivos: portabilidad limitada de prompts y flujos, dependencia de embeddings o formatos propietarios, y pérdida de rendimiento al cambiar de proveedor.

El contrato debería cubrir asistencia de salida, exportación de datos y logs en formato utilizable, borrado certificado, plazos de transición, soporte de conocimiento y, cuando proceda, acceso a artefactos necesarios para reproducir controles. Si la herramienta se usa para decisiones auditables, conservar evidencia histórica y trazabilidad de versiones no es opcional.

Tu equipo ya debería tener una respuesta honesta a esta pregunta: si mañana rescindes al proveedor, ¿qué evidencia puedes conservar para defender decisiones tomadas el mes pasado? Si la respuesta es “depende de su consola”, vas tarde.

AI Act: el error clásico es creer que la carga está en el proveedor y que el desplegador solo usa

Ese argumento cada vez dura menos. El AI Act, tal como lo está aterrizando la Comisión Europea, distribuye obligaciones según el rol y el tipo de sistema. Para sistemas de alto riesgo, el proveedor tiene un paquete fuerte de obligaciones, sí. Pero el desplegador también tiene deberes operativos propios, entre ellos usar el sistema conforme a las instrucciones de uso, asegurar supervisión humana cuando proceda, monitorizar el funcionamiento y conservar registros cuando esté bajo su control o sea exigible en su contexto de uso.

La implicación contractual es obvia: si tu entidad puede ser desplegadora de un sistema de alto riesgo, el proveedor debe darte material suficiente para cumplir. No solo una ficha de marketing sobre “IA responsable”. Hablamos de documentación técnica, instrucciones de uso, limitaciones conocidas, datos sobre rendimiento relevante, controles de logging, eventos de cambio, condiciones de uso previstas y restricciones explícitas.

La cuestión se vuelve especialmente seria cuando la IA toca ámbitos como evaluación de solvencia o scoring crediticio, donde el AI Act incluye casos de alto riesgo en el anexo correspondiente. En esos supuestos, contratar una caja negra con explicaciones vagas es una temeridad regulatoria, aunque el proveedor prometa tasas de acierto espectaculares. Las tasas medias sin contexto no sirven cuando debes explicar decisiones, supervisar errores y demostrar gobernanza.

A eso se suma otra capa que en 2026 ya no debería sorprender a nadie: los modelos de propósito general no viven en un planeta aparte. Aunque determinadas obligaciones específicas recaigan sobre el proveedor del modelo GPAI, la entidad que integra ese modelo en un caso de uso regulado sigue necesitando evaluar limitaciones, dependencia de terceros, seguridad de integración y efectos sobre sus propios deberes sectoriales. El “nosotros solo ofrecemos el modelo base” puede ser jurídicamente interesante; operativamente, no te resuelve gran cosa.

Qué debe mirar de verdad una due diligence de proveedor de IA

La due diligence útil no es una encuesta de 180 preguntas que nadie lee. Es una investigación dirigida a evidencias que cambian decisiones. Si el proveedor responde bien, avanzas con condiciones. Si responde mal, elevas controles o descartas. El resto es teatro corporativo.

Yo la dividiría en ocho bloques.

Gobernanza del servicio y del modelo

Pide identificación precisa del servicio, versión o familia de modelos utilizada, proceso de gestión de cambios, política de retirada de funcionalidades y responsabilidades internas de seguridad, cumplimiento y desarrollo. Si el proveedor no tiene una función identificable para incidentes de seguridad ni otra para cuestiones de conformidad de IA, ya sabes el nivel de madurez.

Prueba útil: evidencia de comité de cambios, notas de versión históricas, política de release management y matriz RACI sobre seguridad/model risk/compliance.

Datos: entrenamiento, ajuste, prompts y outputs

Aquí conviene separar varias capas que los contratos suelen mezclar adrede. Una cosa son los datos de entrenamiento originales del proveedor. Otra, los datos que tú introduces como prompts o archivos. Otra, los datos derivados: embeddings, logs, telemetría, feedback humano, métricas de calidad y outputs reutilizados.

Las preguntas imprescindibles son concretas. ¿Se usan prompts, archivos, outputs o metadatos del cliente para entrenamiento general del proveedor? ¿Se usan para mejora del servicio aunque no se entrenen pesos? ¿Hay segregación por tenant? ¿Qué retención aplica a logs? ¿Dónde se almacenan? ¿Se pueden desactivar ciertas capturas? ¿Qué controles de borrado existen? ¿Qué pasa con datos en backups?

Si hay datos personales, el análisis enlaza con GDPR de inmediato. No basta con el DPA. Hay que cuadrar base jurídica, instrucciones, transferencias, medidas de seguridad, retención, subencargados y capacidad de atender derechos. Si el proveedor dice que no puede borrar ciertos registros porque forman parte de sistemas de seguridad o entrenamiento, eso debe quedar delimitado por escrito. Y si se produce una violación de seguridad de datos personales, GDPR art. 33 mete el reloj en marcha: 72 horas para notificar a la autoridad competente desde que el responsable tiene conocimiento, no desde que el proveedor decida contestar el ticket.

Seguridad técnica y resistencia operativa

NIS2 art. 21 habla de medidas apropiadas; DORA pide resiliencia operativa. Tradúcelo a controles verificables. Cifrado en tránsito y en reposo. Gestión de identidades privilegiadas. Segmentación. Registro y monitorización. Gestión de vulnerabilidades. Seguridad del ciclo de desarrollo. Pruebas de intrusión proporcionadas al riesgo. Protección frente a abuso de API. Gestión de secretos. Seguridad de dependencias open source. Controles contra exfiltración y fuga entre tenants.

En proveedores de IA, añade tres pruebas específicas. Una: controles contra prompt injection y data exfiltration en flujos con retrieval o herramientas conectadas. Dos: límites y protección frente a abuso automatizado de API, incluidos key rotation y detección de uso anómalo. Tres: mecanismos para contener salidas inseguras o no autorizadas cuando el sistema opera en procesos regulados.

No necesitas que te enseñen el código fuente. Sí necesitas evidencia de que estos controles existen, se prueban y generan hallazgos tratables.

Trazabilidad, logging y explicabilidad operativa

La palabra “explicabilidad” se ha convertido en un ambientador regulatorio: todos la venden, pocos la concretan. Para compliance y auditoría lo relevante es otra cosa: qué registros se generan, cuánto duran, quién accede, si incluyen inputs, outputs, identificadores de versión del modelo, parámetros relevantes, acciones del usuario, alertas y cambios de configuración.

Si el caso de uso puede afectar a clientes, operaciones financieras o controles de segunda línea, necesitas capacidad de reconstrucción. No una explicación filosófica de por qué la red neuronal “aprendió patrones complejos”. Necesitas saber qué vio el sistema, qué devolvió, bajo qué versión y con qué intervención humana posterior.

Esto es puro oro para DORA, para el AI Act en usos de alto riesgo y para defensa frente a litigio. También es el primer sitio donde muchos proveedores de IA pinchan.

Subcontratación y concentración

No basta con identificar subproveedores. Hay que medir concentración. Si tu proveedor de IA depende de un único hyperscaler, de una sola familia de modelos o de una sola región, el riesgo de concentración sube. DORA lleva tiempo obsesionado con la concentración en terceros TIC, y con razón. La sofisticación tecnológica no elimina puntos únicos de fallo; a veces los disfraza mejor.

Pide mapa de dependencias críticas. No hace falta que te entreguen su árbol genealógico completo, pero sí los componentes sin los cuales el servicio deja de operar. Si el proveedor se niega incluso a ese nivel, sospecha que tampoco controla bien su propio ecosistema.

Incidentes, notificación y cooperación

La cláusula de incidente debe ser mucho más precisa que “sin demora indebida”. Para servicios de IA con datos sensibles o impacto operativo relevante, conviene fijar ventanas concretas de notificación inicial, por ejemplo 24 horas desde la detección de un incidente con impacto material en confidencialidad, integridad, disponibilidad o funcionamiento del modelo; actualización conforme avance la investigación; y entrega de informe de causa raíz y acciones correctoras en plazo definido.

La razón es doble. DORA exige marcos de gestión y reporte de incidentes TIC. GDPR impone sus propios plazos cuando hay datos personales. Y en regímenes sectoriales o internos, seguridad y continuidad exigen activar crisis management antes de que llegue el informe perfecto, que siempre llega tarde.

Cumplimiento de rol bajo AI Act

El proveedor debe declarar qué rol asume respecto del sistema y qué obligaciones cubre. Si comercializa un sistema de alto riesgo, exige evidencia de conformidad aplicable, documentación técnica, instrucciones y procesos de post-market monitoring si proceden. Si el proveedor ofrece un modelo generalista integrado por tu entidad en un caso de alto riesgo, exige transparencia suficiente para evaluar limitaciones y condiciones de uso, aunque la responsabilidad final del caso de uso no desaparezca.

En otras palabras: que nadie esconda responsabilidades detrás de una taxonomía conveniente.

Salida y reversibilidad

Pide prueba documental de cómo se ejecuta una salida ordenada: exportaciones disponibles, formatos, tiempo de extracción, costes, soporte, borrado y continuidad transitoria. Si hay fine-tuning con datos propios, pregunta qué artefactos pueden recuperarse y qué no. Si la respuesta es “ninguno”, tu dependencia es más profunda de lo que probablemente indica el contrato.

Tabla comparativa: qué exigir según el frente regulatorio

Las cláusulas que más valoran los reguladores son, casualmente, las que más discuten los proveedores

Si tu negociación va en serio, habrá fricción. No porque tu equipo legal sea caprichoso, sino porque estás intentando convertir un servicio opaco y altamente dinámico en una dependencia gobernable. Estas son las cláusulas que más resistencia generan y más conviene pelear.

Notificación de cambios materiales. El proveedor querrá libertad para actualizar el modelo. Tú necesitas aviso previo cuando el cambio afecte rendimiento, seguridad, jurisdicción de tratamiento, subprocesadores, funcionalidades críticas o limitaciones de uso. Sin eso, no puedes revalidar controles internos.

Restricción de uso de datos del cliente. Muchos proveedores aceptan no entrenar el modelo base con tus datos, pero se reservan usos amplios para “service improvement”. Hay que aterrizar qué significa exactamente, con qué datos, durante cuánto tiempo y con qué posibilidad de opt-out.

Auditoría proporcional pero real. La alternativa sensata a la auditoría abierta no es cero auditoría, sino un modelo basado en criticidad y triggers. Si hay incidente material, cambio significativo, hallazgo grave o requerimiento regulatorio, el acceso debe ampliarse.

Asistencia regulatoria. DORA prevé cooperación con autoridades competentes. Si el proveedor atiende a entidades financieras europeas y todavía reacciona con sorpresa ante esta exigencia, quizá vende más rápido de lo que madura.

Subcontratación crítica. Cuando la prestación depende de un hyperscaler o de otro modelo de un tercero, el contrato debería reconocerlo expresamente. No para humillar a nadie, sino para que tu entidad sepa dónde está el verdadero punto de fallo.

Derechos de suspensión. Si el proveedor sufre un incidente grave, altera el servicio sin control o incumple requisitos críticos, la entidad debe poder suspender determinados usos o flujos sin entrar en una guerra contractual absurda mientras sigue corriendo el riesgo.

Implicaciones para entidades financieras españolas

Para banca, pagos, seguros, gestoras y fintech reguladas en España, el ángulo no es teórico. DORA aplica plenamente este año y la expectativa supervisora sobre terceros TIC ya no se limita a grandes outsourcings clásicos. Si una entidad usa IA en operaciones, control interno o atención al cliente con impacto regulado, esa relación entrará en la conversación de resiliencia, outsourcing, continuidad y riesgo tecnológico aunque el contrato naciera en el área de innovación.

Además, el mercado español tiene una peculiaridad práctica: mucha adopción de IA se está haciendo vía proveedores globales con condiciones estándar anglosajonas, mientras las funciones de cumplimiento necesitan anclaje en obligaciones europeas muy concretas. Ese choque produce lagunas previsibles. Contratos sin anexos de salida útiles. DPAs correctos pero incompletos para trazabilidad. Derechos de auditoría sustituidos por informes genéricos. Y una tendencia peligrosa a clasificar como “herramienta de productividad” servicios que ya influyen en procesos de negocio importantes.

Si la entidad está dentro del perímetro de NIS2 por su actividad o por transposición sectorial aplicable, la cadena de suministro de IA deja de ser asunto exclusivo del CISO. Debe entrar también en governance de riesgo, procurement, privacidad, continuidad y cumplimiento regulatorio. No es burocracia extra. Es lo único que evita que un cambio silencioso de proveedor se convierta en un problema de consejo.

Y un apunte nada menor para el mercado español: cuando el proveedor de IA promete “datos en Europa”, hay que preguntar qué significa exactamente. Región de inferencia, almacenamiento primario, backup, soporte, logging, telemetría, revisión manual, subprocesadores. Sin ese desglose, “Europa” puede ser una etiqueta comercial bastante elástica.

Checklist de evidencias para auditoría

Si tienes que demostrar que la due diligence no fue cosmética, estas evidencias son las que suelen marcar la diferencia:

• Evaluación de criticidad del servicio de IA vinculada a procesos críticos o importantes, con aprobación por la función responsable.
• Entrada del proveedor en el registro de información de terceros TIC exigido por DORA art. 28, incluyendo servicio, funciones soportadas, ubicaciones, subcontratistas relevantes y estrategia de salida.
• Contrato principal y anexos con cláusulas de acceso, auditoría, subcontratación, continuidad, incidentes, borrado y terminación.
• Matriz de roles bajo AI Act: proveedor, desplegador u otros, con justificación del caso de uso y categoría regulatoria aplicable.
• Documentación técnica o instrucciones del proveedor sobre límites de uso, métricas de rendimiento, cambios de versión y logging.
• DPA y, si procede, documentación sobre transferencias internacionales, subencargados y retención de datos.
• Resultados de evaluación de seguridad: cuestionario, evidencias de controles, certificaciones relevantes, informes independientes y excepciones aceptadas.
• Mapa de subcontratación y dependencias críticas, incluyendo hyperscalers, servicios de anotación, moderación, almacenamiento y soporte.
• Playbook de incidentes con tiempos de escalado entre proveedor, CISO, DPO, continuidad y compliance.
• Prueba de salida o, al menos, ejercicio documentado de reversibilidad sobre exportación de datos, logs y configuración.
• Revisión periódica posterior a la contratación: cambios de modelo, nuevos subprocesadores, incidentes, degradación de rendimiento y renovación de controles.

La clave no es acumular documentos. Es que cada evidencia responda a una pregunta supervisora simple: ¿sabías de qué dependías, qué riesgos implicaba y cómo ibas a reaccionar si fallaba?

Objeción habitual: “pero si el caso de uso no es alto riesgo, esto es excesivo”

No necesariamente. Es cierto que no todos los casos de uso merecen la misma intensidad. Un asistente interno para redactar borradores sin datos sensibles no exige la misma diligencia que una herramienta de scoring o detección de fraude. La proporcionalidad importa. DORA, NIS2 y el propio diseño del AI Act no piden tratar igual lo desigual.

Ahora bien, proporcionalidad no significa ingenuidad. Incluso un caso de uso aparentemente menor puede convertirse en relevante si se conecta con repositorios internos, sistemas de tickets, bases documentales regulatorias, buzones de clientes o herramientas de ciberseguridad. La historia reciente de la tecnología está llena de componentes “no críticos” que acabaron siéndolo el día del incidente.

La postura sensata es graduar la due diligence, no eliminarla. Menos preguntas donde el riesgo sea bajo, sí. Menos control sobre servicios con datos no sensibles y sin impacto decisional, también. Pero siempre con clasificación previa, definición de uso permitido y límites claros de integración. Lo contrario es comprar primero el problema y evaluar después si era peligroso.

Lo que deberían hacer ahora CISO y compliance, juntos y no por correo

Si tu organización ya usa proveedores de IA, lo primero es localizar la sombra. No toda dependencia de IA entra por procurement. Hay copilotos adquiridos por áreas de negocio, APIs activadas por desarrollo, plugins conectados a suites corporativas y herramientas de seguridad con módulos generativos añadidos casi como extra decorativo. Antes de revisar contratos, necesitas inventario.

Después, clasifica por criticidad y por rol regulatorio. ¿El proveedor soporta proceso crítico o importante? ¿Procesa datos personales o sensibles? ¿Hay un caso de uso que pueda caer en alto riesgo bajo AI Act? ¿Existen subproveedores materiales? ¿La salida es viable? Con esas respuestas puedes decidir qué relaciones exigen remediación contractual prioritaria.

El siguiente paso es revisar el registro DORA de terceros TIC y comprobar si los proveedores de IA están entrando con el nivel de detalle correcto. En demasiadas entidades aparecen escondidos bajo categorías genéricas de software, analytics o cloud. Ese truco quizá ayude a dormir una noche; no ayuda en auditoría.

También conviene alinear a seguridad, privacidad, legal, procurement y negocio sobre una plantilla específica para IA. No una copia del cuestionario SaaS de 2019 con la palabra “modelo” añadida aquí y allá. Una plantilla que pregunte por entrenamiento, telemetría, logging, cambios de modelo, prompt retention, subcontratación multinivel, degradación funcional y reversibilidad.

Y una recomendación final que vale más que veinte políticas: prueba un escenario de fallo antes de necesitarlo. Simula que el proveedor cambia el modelo sin aviso, pierde disponibilidad durante 48 horas o confirma un incidente de exposición de prompts. Mira quién sabe qué hacer, qué datos puedes extraer, qué usos puedes detener y qué comunicación interna se activa. Si el ejercicio incomoda, perfecto. Para eso sirve.

La conclusión incómoda: la IA ya no se compra, se gobierna

En 2026, seguir contratando IA como si fuera una suscripción más es una forma sofisticada de irresponsabilidad. No porque toda IA sea intrínsecamente peligrosa, sino porque su mezcla de opacidad, dependencia de terceros, cambios frecuentes y potencial impacto regulado exige un nivel de gobierno que muchas compras todavía no reflejan.

DORA pone el esqueleto: clasificación, contrato, registro, auditoría, continuidad y salida. El AI Act obliga a dejar de esconderse detrás del proveedor y a definir responsabilidades por rol y por caso de uso. NIS2 recuerda que la cadena de suministro también se ataca, y que la dependencia tecnológica no se reduce por usar terminología más elegante.

La pregunta útil no es si tu proveedor de IA “cumple”. La pregunta útil es si, con las evidencias y cláusulas que hoy tienes, podrías defender ante auditoría, supervisor o consejo que controlas una dependencia crítica. Si dudas, ya tienes respuesta.