IA de terceros: ¿quién asume realmente el riesgo?

Una empresa contrata una solución de inteligencia artificial para revisar reclamaciones, priorizar candidatos o responder preguntas de clientes. El proveedor entrega el modelo, aloja la infraestructura y actualiza el servicio. Meses después cambia el modelo subyacente, incorpora un nuevo subprocesador o modifica sus reglas de retención de datos. El proceso de negocio sigue funcionando, pero el sistema que la organización aprobó ya no es exactamente el mismo.

Ese es el problema central de la IA de terceros: la organización puede externalizar tecnología, operación y parte de la evidencia, pero no puede asumir que también ha externalizado las consecuencias.

La tesis para auditoría es sencilla: el riesgo debe asignarse entre las partes, pero la organización usuaria conserva la responsabilidad de entender qué depende del proveedor, qué controla directamente, qué debe monitorear y qué hará si la relación deja de ser aceptable. En IA, esa responsabilidad exige mirar más allá de la evaluación inicial del proveedor.

Comprar IA no transfiere la responsabilidad

ISO/IEC 42001:2023 aborda expresamente las relaciones con terceros. Su control A.10.2 exige que las responsabilidades a lo largo del ciclo de vida del sistema de IA se asignen entre la organización, sus socios, proveedores, clientes y otros terceros. A.10.3 añade que la organización debe establecer un proceso para asegurar que el uso de productos, servicios o materiales de proveedores sea coherente con su enfoque de desarrollo y uso responsable de IA.

La distinción importa. Asignar responsabilidad no significa transferir toda la rendición de cuentas. Un contrato puede imponer niveles de servicio, protección de información, notificación de incidentes o remediación. La organización aún debe decidir si el proveedor es adecuado para el uso previsto y si la dependencia y los controles internos son aceptables.

El NIST AI Risk Management Framework llega a una conclusión práctica similar. Su función Govern incluye políticas para riesgos derivados de software, datos y otros elementos de terceros, mientras que Manage pide monitorear regularmente los riesgos y beneficios de recursos externos. NIST también advierte que las tecnologías adquiridas pueden ser complejas u opacas y que el apetito de riesgo del proveedor puede no coincidir con el de la organización que despliega el sistema.

Para el auditor, la pregunta no es “¿el proveedor aceptó responsabilidad?”. Es: ¿la organización sabe qué responsabilidad sigue siendo suya y puede demostrar cómo la ejerce?

La opacidad del proveedor cambia lo que cuenta como evidencia

Una aplicación empresarial puede depender de SaaS, un modelo fundacional, bibliotecas, datos adquiridos y nube. El NIST Generative AI Profile identifica este riesgo de cadena de valor: la integración de múltiples componentes de terceros puede reducir la transparencia y la responsabilidad para los usuarios posteriores.

Esto crea una tensión de auditoría. La organización necesita evidencia suficiente para gobernar el uso, pero el proveedor puede limitar el acceso por propiedad intelectual, seguridad o confidencialidad. La respuesta no es exigir automáticamente el código fuente. Es definir qué evidencia es necesaria para el riesgo real.

Según el caso, un auditor puede esperar ver:

documentación sobre uso previsto, limitaciones y cambios relevantes;
resultados de pruebas o evaluaciones independientes;
métricas de desempeño, incidentes y disponibilidad;
descripción de fuentes de datos o procedencia cuando sea material;
controles sobre subproveedores y componentes críticos;
mecanismos de escalación y corrección;
registros que permitan reconstruir decisiones o cambios cuando el uso lo requiera.

La señal de alerta es que la organización no pueda explicar qué evidencia necesita, qué no puede obtener y cómo compensa esa limitación.

El contrato debe diseñarse para un servicio que cambia

Los contratos tecnológicos suelen concentrarse en precio, seguridad, disponibilidad y protección de datos. En IA, eso puede ser insuficiente porque el comportamiento del servicio puede cambiar sin que cambie el proceso de negocio.

Un contrato o acuerdo de servicio debería traducir el riesgo de IA en derechos y obligaciones operables. No existe una cláusula universal, pero los temas que suelen merecer análisis incluyen:

definición del servicio, uso previsto y restricciones relevantes;
obligaciones de documentación y cooperación;
notificación de cambios materiales en modelos, datos, funcionalidades o subprocesadores;
niveles de servicio y métricas de desempeño pertinentes;
tratamiento de información confidencial y datos introducidos por el cliente;
gestión y notificación de incidentes;
derechos de auditoría, evaluación o acceso a evidencia;
obligaciones de remediación;
propiedad, portabilidad, devolución y eliminación de datos;
continuidad, terminación y asistencia de salida.

El punto crítico es la gestión del cambio. ISO/IEC 42001 contempla actualizaciones, modificaciones de uso y comunicación a usuarios. Si cambia el modelo detrás de una decisión de alto impacto, la organización necesita criterios para decidir si requiere nueva validación, aprobación o controles compensatorios.

Un contrato es un control de diseño. El riesgo solo disminuye si las obligaciones se convierten en información, decisiones y acciones durante la vida del servicio.

Monitorear al proveedor significa monitorear la relación y el sistema

El error común es terminar la gestión de riesgos después del due diligence y la firma. Precisamente por eso el Third-Party Topical Requirement del IIA es relevante. Fue emitido el 15 de septiembre de 2025 y entrará en vigor el 15 de septiembre de 2026. A partir de esa fecha, cuando sea aplicable a un servicio de aseguramiento, establece una base para evaluar gobierno, gestión de riesgos y controles de terceros. No obliga por sí mismo a auditar a todos los proveedores ni sustituye la evaluación de riesgos.

Su guía de usuario organiza la relación en cinco etapas: selección, contratación, incorporación, monitoreo y salida. Ese ciclo es especialmente útil para IA porque el riesgo puede cambiar después de la compra.

Etapa	Pregunta de auditoría	Evidencia útil	Riesgo específico de IA
Selección	¿La criticidad y el uso justifican este proveedor?	evaluación de riesgos, due diligence, alternativas	opacidad del modelo, concentración, dependencia
Contratación	¿Las obligaciones reflejan los riesgos relevantes?	contrato, anexos, SLA, derechos de auditoría	cambios de modelo, datos, subprocesadores
Incorporación	¿La integración respeta el uso aprobado?	arquitectura, configuración, pruebas, responsables	uso fuera de propósito, datos inadecuados
Monitoreo	¿Sabemos si el servicio sigue siendo aceptable?	KPIs/KRIs, incidentes, cambios, evaluaciones periódicas	deriva, actualización del modelo, nuevas capacidades
Salida	¿Podemos terminar la relación de forma controlada?	plan de salida, pruebas, inventario de datos y accesos	portabilidad, borrado, continuidad, dependencia técnica

Un programa maduro no trata a todos los proveedores por igual. El monitoreo debería responder a criticidad, impacto, acceso a datos, autonomía, sustitución y concentración. Un asistente de redacción no exige el mismo control que una IA que influye en crédito, contratación, seguridad o decisiones regulatorias.

El riesgo de salida empieza antes de firmar

La prueba más incómoda de una relación con un proveedor suele aparecer cuando la organización quiere salir.

¿Puede recuperar sus datos en un formato utilizable? ¿Puede reconstruir configuraciones, reglas, prompts, registros o decisiones relevantes? ¿Sabe qué información debe eliminar el proveedor y sus subprocesadores? ¿Existe una alternativa operativa mientras se migra? ¿El nuevo proveedor necesitará volver a validar el caso de uso? ¿Qué ocurre con procesos que aprendieron a depender de una API, una taxonomía o una funcionalidad propietaria?

Estas preguntas convierten la salida en un problema de resiliencia, portabilidad, evidencia y concentración, no solo de terminación contractual.

NIST contempla contingencias ante fallos de terceros y desmantelamiento seguro; la guía del IIA incluye estrategia y plan de salida dentro del offboarding. El auditor debería evaluar esa capacidad cuando aún existe poder de negociación, no cuando el proveedor ya es una dependencia crítica.

Qué debería poder concluir un auditor

Una auditoría de IA de terceros no necesita convertirse en una evaluación profunda del modelo para aportar valor. Puede comenzar con una pregunta de gobierno: ¿la organización puede demostrar que conoce, asigna, controla y monitorea el riesgo que ha introducido al depender de un proveedor de IA?

Una conclusión sólida debería estar respaldada por evidencia de que:

existe un inventario suficientemente completo de proveedores y componentes de IA relevantes;
las responsabilidades internas y externas están definidas y no dejan vacíos;
la evaluación de riesgos determina qué evidencia, controles y obligaciones contractuales son necesarios;
los cambios materiales del servicio pueden detectarse y activar revisión;
el desempeño, incidentes y dependencias se monitorean según criticidad;
existe una respuesta viable ante incumplimiento, degradación o fallo del proveedor;
la organización puede terminar la relación sin perder control de datos, accesos, evidencia ni continuidad crítica.

El proveedor puede operar el modelo. Puede alojar la infraestructura. Incluso puede asumir obligaciones contractuales significativas. Pero la decisión de confiar en ese servicio sigue perteneciendo a la organización.

Para auditoría interna, esa es la frontera que importa: la tercerización cambia quién ejecuta el control, no elimina la necesidad de saber quién responde cuando la IA falla.