Proveedores de IA como terceros TIC críticos: la due diligence que DORA ya no te deja improvisar

La mayoría de las empresas siguen contratando servicios de IA con la alegría con la que antes compraban SaaS: demo vistosa, piloto rápido, contrato estándar del proveedor y una promesa más o menos elegante de que “la seguridad está cubierta”. Ese enfoque ya ha caducado. En 2026, un proveedor de modelos fundacionales, una API de inferencia, una plataforma de fine-tuning o un servicio de copilots internos puede convertirse en un tercero TIC material para DORA, un eslabón de riesgo en la cadena de suministro bajo NIS2 y, según el caso de uso, una pieza contractual delicada bajo el AI Act.

Aquí está el quid: el problema no es solo si el proveedor cifra datos o pasa una auditoría SOC 2. El problema real es que la IA introduce dependencias opacas que los marcos clásicos de outsourcing no trataban bien: subprocesadores en cascada, cambios de modelo sin control del cliente, degradaciones silenciosas de rendimiento, telemetría difícil de acotar, uso secundario de datos para entrenamiento y una salida técnicamente costosa aunque el contrato diga que es “razonable”. Sobre el papel, todo suena gobernable. En producción, ya no tanto.

Para un CISO o un responsable de cumplimiento europeo, la pregunta útil no es si un proveedor de IA “cumple”. La pregunta útil es otra: si mañana ese proveedor falla, cambia su stack, sufre una brecha, deja de prestar una funcionalidad crítica o te impone un modelo nuevo, ¿tu entidad puede seguir operando, demostrar diligencia y salir sin quedarse atrapada? DORA, el AI Act y NIS2 convergen exactamente ahí.

Tratar la IA como tercer riesgo TIC no es una metáfora. Es una obligación operativa

DORA lleva aplicándose desde el 17 de enero de 2025. Y no se diseñó pensando en chatbots simpáticos, sino en resiliencia operativa financiera. Aun así, su lógica encaja de forma incómodamente precisa con los proveedores de IA. El Reglamento (UE) 2022/2554 exige un marco de gestión del riesgo de terceros TIC que cubra la estrategia, la precontratación, el contenido contractual, el seguimiento continuo, el registro de información y los planes de salida.

Los artículos que importan aquí no son decorativos. DORA art. 28 obliga a gestionar el riesgo derivado de terceros proveedores de servicios TIC como parte integrante del marco de gestión del riesgo TIC. El art. 30 fija elementos contractuales clave. El art. 31 aborda el registro de información. Y el capítulo V establece el régimen de supervisión para proveedores terceros TIC críticos, aunque no todo proveedor de IA caerá formalmente en esa categoría.

La trampa habitual está en pensar que solo cuenta como tercero TIC el hyperscaler o el proveedor de core banking. Error cómodo, pero error. Si un servicio de IA interviene en procesos de onboarding, antifraude, scoring, monitorización de seguridad, atención al cliente, gestión documental, clasificación de incidencias o productividad de analistas, puede afectar funciones críticas o importantes aunque la licencia se haya firmado desde un presupuesto de innovación. DORA no pregunta de qué partida salía el gasto. Pregunta qué impacto operativo tiene la dependencia.

Eso obliga a reclasificar muchos proveedores de IA que hoy siguen aparcados en categorías contractuales blandas: “software de apoyo”, “herramienta experimental”, “asistente interno” o la versión corporativa del autoengaño, “uso no crítico”. Si la herramienta toca datos sensibles, interviene en decisiones relevantes, se integra con sistemas de producción o se vuelve difícilmente sustituible, la discusión ya no es semántica.

Lo que cambia con el AI Act: no basta con comprar bien; hay que repartir obligaciones sin fantasía contractual

El AI Act añade una capa que muchos equipos de compras todavía están simplificando demasiado: las obligaciones no descansan enteramente ni en el proveedor ni en el cliente. Dependen del papel que cada actor desempeña y del tipo de sistema.

La Comisión Europea sigue presentando el AI Act como un marco basado en riesgos. Correcto, pero lo decisivo para la contratación está en cómo se reparten responsabilidades entre provider, deployer, importador, distribuidor y, en algunos casos, fabricante de producto que integra IA. Si tu entidad utiliza un sistema de alto riesgo, no puede esconderse detrás del “el proveedor ya cumple”. Y si modifica sustancialmente un sistema o lo comercializa bajo su marca, puede acercarse peligrosamente al rol de proveedor a efectos regulatorios.

Los artículos centrales para esta conversación están bastante claros. El AI Act art. 16 establece obligaciones de los proveedores de sistemas de IA de alto riesgo. El art. 26 impone obligaciones a los deployers de sistemas de alto riesgo. El art. 9 exige un sistema de gestión de riesgos. El art. 10 regula la gobernanza de datos y la calidad de los conjuntos de datos cuando proceda. El art. 12 trata el registro automático de eventos. El art. 13, la transparencia e instrucciones de uso. El art. 14, la supervisión humana. El art. 15, la precisión, robustez y ciberseguridad.

Y luego está la capa específica de los modelos de propósito general. Desde 2025 ya no tenía sentido hablar de la IA solo como “aplicación final”; en 2026 mucho menos. El AI Act incorpora obligaciones para proveedores de modelos de IA de propósito general, con requisitos adicionales para aquellos con riesgo sistémico. La Comisión Europea y la Oficina de IA han ido aterrizando esa gobernanza en códigos de práctica y guías, pero el mensaje jurídico de fondo es simple: si consumes un modelo generalista a través de API o integras uno en tus procesos, necesitas saber bastante más que su benchmark de razonamiento.

La consecuencia contractual es obvia y, aun así, se sigue negociando mal. Si eres deployer de un sistema de alto riesgo, no puedes aceptar un contrato que te niega acceso a documentación técnica suficiente, que no detalla límites de uso, que permite cambios materiales del modelo sin notificación o que reduce la trazabilidad a un panel comercial de observabilidad. Eso no es “menos ideal”. Eso puede impedirte cumplir.

DORA y AI Act no se pisan: se acumulan

Algunas áreas de negocio siguen esperando una gran simplificación regulatoria que no llega. DORA cubriría la resiliencia. El AI Act cubriría la IA. NIS2 cubriría la seguridad. Cada una en su carril, sin rozarse. Qué descanso sería. No funciona así.

Cuando una entidad financiera europea contrata un proveedor de IA para un uso relevante, las tres lógicas se superponen:

DORA pregunta si la dependencia TIC está identificada, clasificada, contractualizada, monitorizada y gobernada con capacidad de salida.

El AI Act pregunta si el sistema, según su categoría de riesgo y tu rol, dispone de documentación, controles, trazabilidad, supervisión humana y garantías de robustez y ciberseguridad.

NIS2 pregunta si la entidad gestiona adecuadamente la seguridad de la cadena de suministro y la relación con proveedores. El art. 21 de NIS2 exige medidas técnicas, operativas y organizativas apropiadas, incluyendo la seguridad de la cadena de suministro y las relaciones con proveedores, con atención a las vulnerabilidades específicas de cada proveedor y a la calidad general de sus prácticas de ciberseguridad.

La coincidencia no es académica. Tiene efecto inmediato en la due diligence. Si compras IA para detección de fraude, por ejemplo, ya no basta con validar precisión comercial y anexar un DPA. Necesitas, al menos, evaluar: dependencia operativa, arquitectura de subcontratación, controles de acceso, jurisdicciones de tratamiento, logging, resiliencia, procedimiento de cambios del modelo, trazabilidad de prompts y outputs, limitaciones conocidas, capacidad de auditoría, uso de datos para entrenamiento, mecanismo de retirada, y pruebas de que la supervisión humana no es una casilla vacía.

Si el lector quiere una regla práctica: usa DORA para gobernar la relación; usa el AI Act para gobernar el sistema; usa NIS2 para tensionar la cadena de suministro. Si intentas resolverlo con una sola lente, dejas ángulos ciegos.

La falsa comodidad del “el proveedor es el responsable”

La cláusula favorita de algunos vendedores de IA es la que, traducida al castellano llano, viene a decir: “Nosotros operamos el modelo; usted decide cómo usarlo; por tanto, la responsabilidad regulatoria es suya”. A veces lo dicen con menos brusquedad, pero el mensaje suele ser ese. Conviene leerlo con ceja levantada.

El AI Act reparte responsabilidades, sí. Pero ni borra las del proveedor ni exonera al deployer por falta de diligencia. Si el proveedor suministra un sistema de alto riesgo, le alcanzan obligaciones directas. Si la entidad despliega ese sistema, también. Lo mismo ocurre con los modelos de propósito general: el proveedor tiene deberes propios, pero el cliente debe asegurarse de que su integración y uso no generen incumplimientos previsibles.

Eso tiene un efecto muy concreto en procurement y legal. La entidad debería exigir por contrato, como mínimo, acceso a:

• documentación técnica e instrucciones de uso suficientes para cumplir las obligaciones aplicables;
• información sobre limitaciones conocidas, rendimiento, supuestos de entrenamiento y condiciones de uso prohibidas;
• detalles sobre logging disponible, retención, exportación y trazabilidad de eventos;
• notificación previa o, cuando menos, sin demora injustificada, de cambios materiales de modelo, arquitectura, subprocesadores o controles;
• compromisos de soporte para incidentes, investigaciones regulatorias y ejercicio de derechos cuando haya datos personales implicados.

Sin eso, el cliente compra una caja negra con eslóganes de “IA responsable”. Y los eslóganes no pasan una inspección.

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

La mayoría de cuestionarios de terceros no nacieron para la IA moderna. Preguntan por cifrado, ISO 27001, continuidad, backup y pentests. Todo eso sigue siendo necesario, pero se queda corto. La due diligence útil tiene que entrar en cinco capas donde suelen esconderse los riesgos reales.

1. Dependencia funcional y criticidad operativa

Antes de revisar seguridad, define para qué sirve exactamente la IA y qué ocurre si falla. DORA gira sobre funciones críticas o importantes, y esa clasificación no puede improvisarse al final del proceso.

Preguntas que merecen respuesta documentada:

• ¿El servicio participa en un proceso regulado, en una función de control o en una decisión con impacto financiero, prudencial o de clientes?
• ¿Existe fallback manual realista o solo una fantasía de comité?
• ¿Cuál es el RTO/RPO operacional aceptable si el servicio queda indisponible?
• ¿Qué dependencia existe de prompts, embeddings, pipelines, conectores o formatos propietarios que compliquen la salida?
• ¿Quién valida la calidad del resultado y con qué métricas?

Este punto parece básico. Justamente por eso se hace mal. Muchas organizaciones han desplegado copilots o motores de clasificación documental que, en pocos meses, se han convertido en piezas de facto críticas sin haber pasado por un proceso de clasificación serio. Luego llega la revisión de DORA y aparecen contratos que parecen firmados para una app de notas.

2. Arquitectura de servicio y subcontratación en cadena

Con IA, el proveedor visible rara vez es el proveedor real completo. Puede haber un integrador, un orquestador, un proveedor de inferencia, uno o varios hyperscalers, servicios de observabilidad, herramientas de safety, almacenes vectoriales y subprocesadores de soporte. El riesgo no termina en la entidad con la que firmas.

DORA es especialmente severa con esto. El art. 30 exige que los acuerdos contractuales contemplen, entre otros elementos, la descripción completa de funciones y servicios, los lugares de prestación y condiciones para la subcontratación que soporta funciones críticas o importantes. El control no se satisface con una URL a una página cambiante de subprocesadores.

La pregunta buena no es “¿tenéis subencargados?”. Claro que los tienen. La pregunta buena es otra: ¿qué parte del servicio depende de cada subcontratista, en qué jurisdicción opera, con qué controles, y qué capacidad tiene mi entidad para oponerse o salir si cambia la cadena?

Aquí es donde NIS2 aprieta. Su lógica de cadena de suministro obliga a evaluar no solo al proveedor principal sino la exposición agregada. Si varios servicios de IA dependen del mismo proveedor de nube, del mismo servicio de moderación o del mismo modelo base, la concentración de riesgo puede dispararse sin que compras lo haya visto venir.

3. Datos: entrenamiento, retención, aislamiento y uso secundario

Buena parte del riesgo no está en el modelo, sino en lo que el proveedor hace con tus datos y metadatos. Y “datos” aquí incluye más de lo que la gente cree: prompts, adjuntos, embeddings, logs, feedback del usuario, telemetría, etiquetas de evaluación y resultados inferidos.

Si hay datos personales, el RGPD entra entero en la conversación. El proveedor deberá encajar, según el caso, como encargado o incluso como responsable para ciertos tratamientos independientes. Pero incluso dejando aparte el RGPD, el AI Act y DORA exigen precisión contractual y gobernanza.

La entidad debería forzar respuestas documentadas sobre:

• si los inputs y outputs se usan para entrenamiento, ajuste, evaluación o mejora del modelo;
• si ese uso es por defecto, opcional o excluible;
• qué retención aplica a prompts, logs y artefactos derivados;
• si existe aislamiento lógico o físico entre clientes;
• cómo se gestionan secretos, credenciales y datos sensibles introducidos por usuarios;
• si el proveedor admite despliegue dedicado, residencia regional o claves gestionadas por el cliente.

En servicios de IA generativa, aceptar un lenguaje contractual ambiguo sobre “service improvement” es una forma elegante de comprar incertidumbre. Y en sectores regulados, incertidumbre suele ser el nombre corporativo de un problema futuro.

4. Cambios de modelo, deriva y control de versiones

Este es el ángulo más infravalorado. Un proveedor clásico de software actualiza una versión; un proveedor de IA puede cambiar el comportamiento del sistema aunque la API siga respondiendo con el mismo endpoint. Mismo contrato, mismo nombre comercial, salida distinta. A veces mejor. A veces no.

Para DORA, esto afecta a la gestión del cambio y a la continuidad del servicio. Para el AI Act, toca de lleno la robustez, la trazabilidad, la supervisión y el rendimiento. Para cumplimiento interno, añade un dolor conocido: ¿cómo demuestras que el sistema evaluado en validación es sustancialmente el mismo que está tomando decisiones hoy?

La due diligence debe exigir, como mínimo:

• política de versionado de modelos y componentes;
• notificación de cambios materiales que afecten a rendimiento, seguridad, explicabilidad o compatibilidad;
• capacidad de fijar versión durante un periodo acordado;
• entorno de pruebas previo a cambios significativos;
• métricas históricas y comparables de rendimiento por caso de uso;
• procedimiento de rollback o fallback.

Si el proveedor no puede ofrecer nada de eso, la entidad debe asumir que está contratando una capacidad variable, no un servicio estable. Hay casos en los que puede aceptarse. Pero hay que decirlo en voz alta y tratarlo como riesgo consciente, no como detalle técnico.

5. Auditabilidad real, no marketing de cumplimiento

“No permitimos auditorías on-site por razones de seguridad, pero compartimos certificaciones de terceros”. Esa frase aparece una y otra vez. A veces es razonable; otras, es una forma sofisticada de bloquear visibilidad.

DORA, especialmente en relaciones que soportan funciones críticas o importantes, exige derechos de acceso, inspección y auditoría adecuados. No siempre implicará una visita física del cliente con linterna, pero sí un marco que permita obtener evidencia suficiente. Un derecho de auditoría inútil no cumple la función regulatoria aunque quede precioso en el anexo.

La negociación sensata aquí no consiste en exigir lo imposible, sino en concretar mecanismos escalonados:

• acceso a informes de auditoría independientes recientes y completos;
• posibilidad de cuestionario reforzado y sesiones técnicas con responsables de seguridad y arquitectura;
• evidencia sobre controles específicos, no solo resúmenes ejecutivos;
• derecho de auditoría directa o mediante tercero designado en supuestos gatillo: incidente grave, requerimiento supervisor, incumplimiento material o cambios significativos;
• obligación de remediación con plazos y seguimiento documental.

La palabra clave es “suficiente”. Si la evidencia no permite a la entidad demostrar control razonable frente a su supervisor, no sirve aunque venga envuelta en papel de compliance premium.

Cláusulas contractuales que ya no deberían negociarse como accesorias

Hay contratos de IA que siguen redactados como si el único riesgo serio fuera la factura mensual. Eso en 2026 es una negligencia bastante cara. Si el servicio es relevante para una función crítica o importante, o si soporta un sistema de alto riesgo, hay cláusulas que deben pasar del anexo al centro de la negociación.

Objeto, alcance y dependencias técnicas

El contrato debe describir el servicio con precisión operativa, no con prosa comercial. Qué modelo o familia de modelos se usa, qué funciones cubre, qué límites de capacidad existen, qué componentes o APIs externas intervienen y qué entornos están incluidos. DORA art. 30 pide una descripción completa de funciones y servicios. En IA, esa completitud exige detallar dependencias técnicas sustantivas.

Niveles de servicio que midan lo que importa

Un SLA de disponibilidad del 99,9% dice poco si el modelo responde rápido pero degrada calidad, genera tasas de error inaceptables o bloquea ciertos casos sin transparencia. En IA conviene pactar, además de uptime:

• latencia por operación crítica;
• tasa de error funcional o umbrales de calidad acordados donde sea objetivable;
• ventanas de mantenimiento y límites de cambios sin preaviso;
• tiempos de respuesta para incidentes de seguridad y degradación del modelo;
• mecanismos de escalado y acceso a soporte especializado.

No siempre podrás fijar precisión contractual cerrada; dependerá del caso de uso. Pero sí puedes fijar métricas de degradación, pruebas de aceptación y obligaciones de notificación.

Subcontratación y cambios materiales

Si un proveedor puede cambiar unilateralmente el modelo subyacente, el hyperscaler, el procesador de logs o la jurisdicción de tratamiento con una mera actualización web, el cliente ha perdido el control. DORA no prohíbe la subcontratación; prohíbe, en la práctica, que la entidad no la gobierne cuando importa.

La cláusula útil exige notificación previa para cambios materiales, derecho de objeción en supuestos definidos y derecho de terminación sin penalización cuando el cambio altere riesgo, ubicación de datos, cumplimiento o capacidad de auditoría.

Incidentes, cooperación y plazos

Un proveedor de IA que tarda días en explicar una fuga de prompts, un acceso indebido a datasets o una alteración del comportamiento del modelo no te está prestando resiliencia; te está trasladando ansiedad regulatoria. DORA obliga a gestionar incidentes TIC y el RGPD impone plazos de notificación de brechas de datos personales en 72 horas ante la autoridad de control bajo RGPD art. 33. Si dependes del proveedor para saber qué ocurrió, el reloj no se detiene por cortesía.

El contrato debería fijar:

• plazo de notificación inicial de incidentes de seguridad e incidencias materiales del servicio;
• contenido mínimo de la notificación inicial y de actualizaciones;
• obligación de cooperación en investigaciones internas, forenses y regulatorias;
• preservación de logs y evidencias;
• participación en simulacros o pruebas de continuidad cuando el servicio sea relevante.

Salida y portabilidad

La salida es el gran punto flaco de la IA como servicio. Exportar datos no basta si no puedes migrar prompts, embeddings, configuraciones de seguridad, historiales de evaluación, reglas de filtrado, plantillas, conectores y workflows. DORA insiste en la necesidad de estrategias de salida cuando se trate de funciones críticas o importantes. Y tiene sentido: una dependencia sin salida no es outsourcing; es captura.

La cláusula buena no se limita a prometer “asistencia razonable”. Debe concretar formatos de exportación, plazos, soporte durante transición, coste predefinido o método objetivo para calcularlo, conservación y borrado posterior, y compatibilidad con una migración a proveedor alternativo o a despliegue interno.

El registro de información bajo DORA: donde muchas entidades descubrirán que no saben realmente qué IA han comprado

Uno de los requisitos menos glamurosos y más reveladores de DORA es el registro de información sobre acuerdos contractuales con terceros proveedores de servicios TIC. La norma no lo concibe como burocracia ornamental. Lo concibe como una base de control. Si una entidad no puede inventariar qué servicios tiene, para qué sirven, a qué funciones se vinculan y qué dependencias generan, no puede gestionar el riesgo de terceros con seriedad.

Con IA, este registro se complica porque la cadena de valor es más movediza que en el outsourcing clásico. El “proveedor” visible puede ocultar varias capas de terceros. El caso de uso puede expandirse desde una prueba acotada hasta una función relevante. Y el mismo servicio puede emplearse en departamentos distintos con riesgos regulatorios distintos.

Para que el registro sirva de algo en 2026, debería recoger al menos:

• nombre del proveedor principal y subcontratistas críticos conocidos;
• servicio concreto, modelo o familia de modelos, y tipo de despliegue;
• función de negocio soportada y clasificación de criticidad;
• si intervienen datos personales, categorías especiales o información sensible de clientes;
• si el servicio se usa en un sistema de alto riesgo o en un uso prohibido/excluido del AI Act;
• ubicaciones de tratamiento, soporte y almacenamiento;
• dependencias de nube, identidad, logging, moderación y otros componentes esenciales;
• responsable interno del servicio, propietario de riesgo y fecha de última revisión.

En varias entidades, el primer ejercicio serio de registro ha revelado algo incómodo: había más servicios de IA en uso de los que TI y compliance creían. Shadow AI con tarjeta corporativa, acuerdos piloto reconvertidos en operación, extensiones de productividad activadas por defecto, conectores no evaluados. DORA no creó ese problema. Solo impide seguir fingiendo que no existe.

NIS2 mete presión donde más duele: la cadena de suministro ya no se evalúa a base de PDFs

NIS2, transpuesta progresivamente en los Estados miembros durante 2025 y 2026 según sus calendarios nacionales, ha vuelto menos tolerable una práctica muy extendida: aceptar cuestionarios estandarizados y certificaciones genéricas como prueba suficiente de seguridad de proveedor. El art. 21 obliga a evaluar la seguridad de la cadena de suministro con atención a la calidad de las prácticas de ciberseguridad del proveedor y a sus vulnerabilidades específicas.

Traducido al mundo IA: no sirve con saber que el proveedor tiene controles “alineados con estándares”. Hay que saber si esos controles cubren riesgos concretos del servicio prestado. Algunos ejemplos:

• protección frente a exfiltración vía prompt injection o conectores inseguros;
• segregación de tenants y de contextos de inferencia;
• hardening de pipelines de fine-tuning y de retrieval;
• validación y revisión de plugins, extensiones o herramientas con acceso a sistemas internos;
• mecanismos de detección de abuso, uso indebido y escalado de privilegios por agentes o automatizaciones.

NIS2 no obliga a convertir cada due diligence en una auditoría forense. Pero sí obliga a que la evaluación sea proporcional al riesgo real del proveedor. Y una IA con acceso a repositorios internos, correo, CRM, sistemas de tickets o herramientas de desarrollo merece un escrutinio bastante más intenso que una app ofimática convencional.

Cuando el proveedor de IA también toca datos personales: el RGPD vuelve a la mesa, con razón

No era el foco principal de esta pieza, pero ignorarlo sería poco serio. Si los prompts, documentos, transcripciones, imágenes o resultados incluyen datos personales, el RGPD no aparece como invitado secundario: entra por la puerta principal.

La entidad debe resolver, entre otras cosas, la base jurídica del tratamiento, la minimización, la limitación de finalidad, la conservación, la información a los interesados y el reparto de roles. Si el proveedor reutiliza datos para entrenar o mejorar modelos con una finalidad propia, puede no encajar limpiamente como mero encargado. Y si no encaja, el contrato estándar de tratamiento se queda corto.

Dos artículos pesan especialmente en la práctica. RGPD art. 28, sobre encargados del tratamiento, por las exigencias contractuales. Y RGPD art. 32, sobre seguridad del tratamiento, porque la evaluación de medidas técnicas y organizativas debe aterrizar en el servicio real. Si ocurre una brecha, entra RGPD art. 33 con su plazo de 72 horas. El CISO ya sabe lo que significa depender de un tercero lento para confirmar alcance. En IA generativa, la dificultad aumenta porque los datos comprometidos pueden estar dispersos entre prompts, outputs, caches y logs operativos.

La idea práctica es sencilla: si tu due diligence de IA no involucra a privacidad desde el inicio, acabarás renegociando tarde o asumiendo riesgos mal descritos.

Tabla comparativa: qué exigir y a quién

Checklist de evidencias para auditoría: lo que conviene poder enseñar, no solo prometer

Esta es una de las pocas situaciones donde una checklist sí tiene sentido, porque hablamos de evidencia verificable. Si mañana llega auditoría interna, supervisión o una revisión de segunda línea, esto debería existir en algún repositorio controlado.

• Evaluación de criticidad del servicio de IA, con vínculo a funciones de negocio y análisis de impacto.
• Inventario del proveedor y subproveedores relevantes, con jurisdicciones y dependencias técnicas.
• Contrato maestro y anexos con cláusulas de seguridad, subcontratación, auditoría, incidentes, cambios y salida.
• Evaluación de seguridad del proveedor adaptada al caso de uso de IA, no solo cuestionario genérico.
• Documentación técnica del sistema o servicio, incluidas limitaciones conocidas e instrucciones de uso.
• Mapa de datos: inputs, outputs, logs, retención, uso para entrenamiento y controles de aislamiento.
• Validación interna del caso de uso, con criterios de aceptación, métricas y supervisión humana definida.
• Procedimiento de gestión de cambios del modelo o servicio, con responsables y gatillos de reevaluación.
• Playbook de incidentes que incluya contacto del proveedor, plazos de escalado y dependencia para notificaciones regulatorias.
• Estrategia de salida y prueba, aunque sea limitada, de exportación o sustitución.

Si faltan tres o cuatro de estos elementos, no estás ante un pequeño gap documental. Estás ante una relación de riesgo inmadura.

Implicaciones para entidades financieras españolas

Para bancos, aseguradoras, EAF, entidades de pago, fintech reguladas y parte del ecosistema de servicios financieros en España, el problema tiene dos capas. La primera es europea: DORA ya aplica plenamente y el AI Act va desplegando obligaciones por fases. La segunda es supervisora y de gobernanza local: la expectativa de trazabilidad, control de outsourcing y seguridad de proveedor en España no ha sido precisamente laxa en los últimos años.

Eso significa que una entidad española no debería limitarse a conservar el contrato y una certificación del proveedor. Necesita poder demostrar, de forma muy concreta, por qué el servicio no compromete su resiliencia operativa, cómo se alinea con su marco de outsourcing, cómo se supervisa y qué ocurre si el proveedor cambia condiciones o deja de ser aceptable.

También hay una derivada práctica para grupos con presencia en varios países de la UE: un mismo proveedor de IA puede estar soportando usos distintos en distintas filiales. Si se centraliza el contrato pero no se centraliza el inventario y la evaluación de riesgo, el grupo acabará con una visión fragmentada de una dependencia que, en realidad, es única. Y ese tipo de fragmentación suele descubrirse en el peor momento.

La objeción habitual: “si apretamos demasiado, ningún gran proveedor firmará”

La objeción no es absurda. Algunos grandes proveedores de IA negocian poco, especialmente en servicios estandarizados. Sus contratos son rígidos, los derechos de auditoría limitados y la transparencia técnica selectiva. Pretender que todos aceptarán una plantilla bancaria europea hecha a medida sería ingenuo.

Pero de ahí no se sigue que la entidad deba resignarse. Se sigue otra cosa: que debe aplicar un enfoque basado en riesgo de verdad. Si no puedes obtener transparencia suficiente, compensa por arquitectura, por segmentación de uso, por minimización de datos, por prohibición de ciertos casos de uso, por despliegues dedicados o por elección de proveedor alternativo en funciones más sensibles.

En otras palabras: cuando el contrato no se deja domar del todo, el diseño técnico y el gobierno interno deben endurecerse. Eso implica, por ejemplo, no conectar un copiloto generalista con acceso amplio a datos internos si no tienes control granular de permisos, revisión de outputs, logging exportable y un caso de uso acotado. Implica no usar un servicio opaco en decisiones que puedan caer en alto riesgo o que afecten de forma relevante a clientes. E implica reservar los proveedores menos auditables para usos donde el impacto de su fallo o sesgo sea contenible.

No siempre ganarás la negociación. Sí puedes decidir dónde no merece la pena perderla.

Qué deberían hacer ya CISO y compliance antes de la próxima renovación

Si tu entidad ya consume IA de terceros, la prioridad no es redactar una policy brillante de veinte páginas. La prioridad es identificar dependencias reales y someterlas a una revisión que mezcle legal, seguridad, procurement, arquitectura y negocio. Las revisiones en silos son exactamente lo que permite que la IA entre por una puerta y el riesgo se quede sin dueño.

Empieza por tres preguntas incómodas. Una: qué servicios de IA están ya en uso, incluidos pilotos persistentes y funcionalidades activadas dentro de suites mayores. Dos: cuáles tocan datos sensibles, producción o decisiones relevantes. Tres: en cuáles no podrías explicar con precisión quién hace qué, con qué datos, bajo qué subcontratación y con qué salida.

Ese subconjunto merece revisión reforzada inmediata. No por obsesión regulatoria, sino por simple higiene operativa. DORA no te pide omnisciencia. Te pide control razonable, trazable y demostrable. El AI Act no te pide fe en la innovación responsable. Te pide saber qué sistema despliegas y bajo qué condiciones. NIS2 no te pide coleccionar PDFs de proveedores. Te pide entender la cadena de suministro que sostiene tus servicios esenciales.

La moraleja es menos futurista de lo que parece. La IA no ha abolido las reglas del outsourcing crítico; las ha vuelto más difíciles de aplicar porque añade opacidad, velocidad de cambio y dependencia técnica sofisticada. Precisamente por eso el enfoque correcto no es inventar una gobernanza paralela “solo para IA”, sino tratar estos proveedores como lo que a menudo ya son: terceros TIC con capacidad real de afectar resiliencia, cumplimiento y seguridad.

Quien siga contratándolos como si fueran una simple licencia de software probablemente descubrirá el problema durante una auditoría, un incidente o una renovación conflictiva. Las tres experiencias son educativas. Ninguna sale barata.