Cómo auditar la gobernanza de IA de terceros

Una empresa puede contratar una plataforma de IA después de meses de diligencia debida y, aun así, perder el control del riesgo pocas semanas después. El proveedor cambia el modelo subyacente, incorpora un nuevo subprocesador, modifica la política de retención de datos o ajusta una función de seguridad. El contrato sigue vigente, el servicio sigue disponible y, sin embargo, la exposición ya no es la misma que se aprobó.

Ese es el problema central de la gobernanza de IA de terceros: externalizar la tecnología no externaliza la responsabilidad.

Para Auditoría Interna, esto cambia el foco. No basta con preguntar si el proveedor fue aprobado, si cuenta con una certificación o si entregó un informe SOC. La pregunta de aseguramiento es más amplia: ¿puede la organización identificar, evaluar y controlar de forma continua los riesgos que dependen de una IA que no administra directamente?

La IA de terceros no es solo otro riesgo de proveedores

La primera es la opacidad. Una organización puede consumir un modelo, una API o una función de IA integrada en software empresarial sin tener visibilidad completa sobre datos de entrenamiento, evaluaciones, arquitectura o controles internos del proveedor. El Marco de Auditoría de Inteligencia Artificial del IIA advierte sobre los riesgos de terceras y cuartas partes y recomienda comprender el entorno de control del proveedor, definir y monitorear sus responsabilidades y, cuando corresponda, establecer derechos de auditoría.

La segunda es el cambio continuo. COSO señala que la fiabilidad de la IA generativa puede deteriorarse por cambios en los datos, deriva del modelo o actualizaciones realizadas por el proveedor. El riesgo no termina al firmar el contrato; debe gestionarse durante todo el ciclo de vida.

ISO/IEC 42001:2023 refuerza esta lógica desde un sistema de gestión de IA. Su Anexo A contempla controles para distribuir responsabilidades entre organización, socios, proveedores, clientes y otras terceras partes, y para asegurar que los productos, servicios o materiales suministrados sean coherentes con el enfoque de IA responsable de la organización. La norma es voluntaria salvo que exista una obligación contractual, regulatoria o de certificación aplicable; no debe confundirse con una ley.

Empiece por el inventario y la clasificación de riesgo

Una auditoría sólida no comienza con el cuestionario del proveedor. Comienza identificando qué dependencias de IA existen.

Esto incluye soluciones compradas como IA, pero también capacidades integradas en herramientas de productividad, ERP, CRM, ciberseguridad, recursos humanos, desarrollo de software o analítica. El NIST Generative AI Profile recomienda inventariar las entidades de terceros con acceso a contenido organizacional y adaptar la diligencia debida de adquisición a riesgos específicos de IA.

El auditor debería evaluar si la organización clasifica a los proveedores por impacto del caso de uso, sensibilidad de los datos, autonomía, efectos sobre personas, dependencia operativa, facilidad de sustitución, frecuencia de cambios y subproveedores. Un asistente interno para redactar borradores no debería recibir el mismo tratamiento que un sistema que prioriza candidatos o ejecuta acciones en producción.

Esta clasificación también determina la profundidad de la auditoría. Las Normas Globales de Auditoría Interna exigen que la planificación y cada trabajo se basen en riesgos relevantes. Además, el Requisito Temático sobre Terceras Partes del IIA, emitido en 2025, entra en vigor el 15 de septiembre de 2026. A partir de esa fecha será obligatorio para los servicios de aseguramiento a los que resulte aplicable y establece una base mínima para evaluar gobierno, gestión de riesgos y controles de terceras partes a lo largo de selección, contratación, incorporación, monitoreo y desvinculación.

El contrato debe hacer posible el control, no solo formalizar la compra

El contrato es un control preventivo. Si la organización descubre después de un incidente que no tiene derecho a recibir información suficiente, cuestionar cambios relevantes o recuperar sus datos, el problema comenzó antes de la puesta en producción.

Para proveedores de IA relevantes, Auditoría Interna debe comprobar que el acuerdo refleja el riesgo identificado y permite obtener evidencia suficiente durante la relación.

Área contractual	Qué debería quedar resuelto	Evidencia útil para auditoría
Uso y datos	Finalidad autorizada, datos permitidos, retención, reutilización y restricciones sobre entrenamiento o mejora del servicio.	Contrato, anexo de tratamiento de datos, arquitectura y flujo de información.
Cambios del servicio	Qué cambios de modelo, configuración, funcionalidad o subprocesadores deben notificarse y cuándo requieren reevaluación.	Cláusulas de cambio, avisos del proveedor, registro de versiones y aprobaciones internas.
Incidentes y desempeño	Umbrales, tiempos de notificación, escalado, análisis de causa raíz y acciones correctivas.	SLA, procedimiento de incidentes, tickets, reportes y revisiones posteriores.
Acceso a aseguramiento	Mecanismos proporcionales al riesgo para evaluar al proveedor: derecho de auditoría o evaluación, informes independientes, resultados de pruebas y evidencia técnica.	Cláusulas de auditoría, SOC u otros reportes, certificaciones, pruebas y respuestas a hallazgos.
Subcontratación	Visibilidad sobre cuartas partes relevantes y obligaciones que deben trasladarse a ellas.	Registro de subprocesadores, notificaciones de cambios y términos contractuales aplicables.
Salida	Sustitución, portabilidad, devolución o destrucción de datos, revocación de accesos y apoyo a la transición.	Plan de salida, pruebas de borrado, inventario de accesos y plan de continuidad.

NIST va en la misma dirección: su perfil de IA generativa sugiere incorporar cláusulas que permitan evaluar procesos y estándares de terceros, actualizar la diligencia debida para adquisición de IA y considerar monitoreo dinámico. Esto es orientación voluntaria, no una obligación universal, pero ofrece criterios útiles para diseñar y auditar controles.

Un punto importante: un informe SOC puede aportar evidencia sobre controles de servicio, seguridad o procesamiento, pero no demuestra por sí solo que el comportamiento del modelo sea adecuado para el caso de uso de la organización. El auditor debe entender qué cubre realmente el informe y qué riesgos quedan fuera.

Cambios, incidentes y monitoreo son la prueba real del gobierno

Seleccione una muestra de proveedores de IA prioritarios y siga eventos reales: una nueva versión del modelo, un cambio de subprocesador, una modificación del SLA, una interrupción, una vulnerabilidad o incidente de privacidad. Para cada evento, compruebe si la organización detectó el cambio, evaluó su impacto, decidió si debía volver a probar el sistema y documentó la aceptación del riesgo o las acciones correctivas.

El NIST AI RMF Playbook establece como resultado de gestión que los riesgos y beneficios de recursos de terceros se monitoreen regularmente y que los controles se documenten. También vincula la operación posterior al despliegue con monitoreo, respuesta a incidentes, recuperación, gestión de cambios y desmantelamiento.

COSO añade una perspectiva de control interno especialmente útil: en IA generativa, modelos, prompts, conectores de recuperación y otras configuraciones pueden cambiar con rapidez, por lo que la evaluación de riesgos, el control de cambios y el monitoreo deben mantener el ritmo. Para Auditoría Interna, eso significa que una aprobación inicial sin evidencia de reevaluación periódica es una señal de debilidad.

Si todo el monitoreo depende de lo que el proveedor decide reportar, la supervisión es frágil. El auditor puede buscar métricas internas de calidad, reclamaciones, fallos, desviaciones de desempeño, excepciones de control, incidentes de datos y cambios en la criticidad del proceso.

La salida es un control de gobernanza, no un trámite administrativo

La dependencia de un proveedor puede crecer silenciosamente. Con el tiempo, la organización acumula integraciones, prompts, repositorios de conocimiento, flujos automatizados, datos históricos y hábitos operativos que hacen costoso cambiar de solución. Por eso, la capacidad de salida debe evaluarse antes de necesitarla.

El Requisito Temático del IIA exige, cuando resulte aplicable, evaluar un proceso formal de desvinculación que contemple terminación, sustitución, devolución o destrucción de datos sensibles y revocación de accesos. Para IA, el auditor debería ampliar la mirada: ¿qué ocurre con embeddings, bases vectoriales, configuraciones, logs, datasets aportados, ajustes personalizados y dependencias vía API? ¿Puede la organización reconstruir una función crítica con otro proveedor? ¿Existe un periodo de transición realista?

Una buena prueba es un ejercicio de mesa: escoger un proveedor crítico y pedir a gestión que describa cómo saldría de la relación en 30, 60 o 90 días. Las brechas aparecen cuando nadie sabe dónde están los datos, qué integraciones deben reemplazarse o qué evidencia de eliminación solicitar.

Una conclusión de auditoría útil debe hablar de dependencia, no de proveedores aislados

Auditar IA de terceros no consiste en determinar si un proveedor es “bueno” o “malo”. Consiste en evaluar si la organización puede mantener control suficiente sobre una capacidad que depende de decisiones técnicas y operativas tomadas fuera de sus fronteras.

Una conclusión fuerte conecta seis elementos: inventario, clasificación de riesgo, diligencia debida, contratos, monitoreo de cambios e incidentes y capacidad de salida. Si uno de ellos falla, la organización puede terminar aceptando un riesgo que nunca evaluó conscientemente.

La pregunta final para el auditor es sencilla: si el proveedor cambiara mañana algo material del modelo, ¿la organización lo sabría, entendería el impacto y tendría opciones reales para actuar? Si la respuesta no puede demostrarse con evidencia, la gobernanza de terceros todavía no está bajo control.