# Auditar la promesa: qué exigir antes de comprar IA

- Link: https://auditoriainteligente.com/auditar-la-promesa-que-exigir-antes-de-comprar-ia/
- Published: 2026-10-06T00:34:26-04:00
- Author: Christian Vargas

**Serie · IA: entre la promesa y la evidencia · Parte 2 de 4**

**TL;DR**

Cuando una organización compra inteligencia artificial, no compra solo una herramienta:
invita a un tercero (y a los terceros de ese tercero) a su perfil de riesgo. Desde
el 15 de septiembre de 2026, el [Requisito Temático sobre Terceras Partes](https://www.theiia.org/en/standards/2024-standards/topical-requirements/third-party/)
del IIA es obligatorio en los trabajos de aseguramiento cuando el riesgo supera 
el umbral. No habla de IA, pero nos da el piso para auditarla.

Proponemos un método en cuatro pasos: saber qué compramos y a quién, probar con 
nuestros propios datos, asegurar por contrato que podremos verificar y leer con 
lupa el alcance de los sellos. Al final, ocho preguntas para llevar a la mesa con
el proveedor.

Nadie compra un automóvil usado por el brillo de su pintura, ni solo por el certificado
de agencia. Lo conduce por su propio camino, solicita el historial de mantenimiento
y discute qué ocurrirá si presenta fallas durante el primer mes. Con la IA solemos
hacer lo contrario: validamos tras una impecable demostración y un buen sello en
la presentación.

Y es probable que alguien en el comité diga: _"Nosotros ya auditamos proveedores.¿
Qué cambia cuando el tercero es una IA?"_ Cambia bastante. La base ya la recorrimos
en nuestra serie sobre tercerización ([gobernanza](https://auditoriainteligente.com/maximizando-el-valor-en-la-tercerizacion-de-servicios/),
[pruebas de control](https://auditoriainteligente.com/pruebas-de-control-en-la-tercerizacion-el-desafio-tactico/)
y [analítica](https://auditoriainteligente.com/analisis-de-datos-e-ia-en-gestion-de-riesgos-de-terceros/)).
Aquí nos centramos en la novedad: un servicio que puede cambiar de comportamiento
sin que cambie el contrato.

En la [Parte 1](https://auditoriainteligente.com/distorsion-o-valor-que-hace-realmente-la-ia/)
vimos cómo el espejo de feria distorsiona el discurso, el consumo y la escalada.
Toca cambiar la sospecha por método. Para ser sinceros, [ISACA reconoce](https://www.isaca.org/about-us/newsroom/press-releases/2024/audit-and-assurance-guidance-for-the-nist-cybersecurity-framework-2-0-and-artificial-intelligence)
que todavía no hay una forma estandarizada de auditar IA. Es por ello que combinamos
_normas de auditoría, de control interno y de gestión de riesgos de IA_.

### Saber qué compramos (y a quién)

![Cajas anidadas que representan a la organización, su proveedor y el modelo de 
IA detrás, iluminadas por una lupa.](https://auditoriainteligente.com/wp-content/
uploads/2026/10/imagen_2.1-matrioshka-1024x579.png)

El Requisito de Terceras Partes del IIA establece una base mínima que el auditor
debe revisar: debida diligencia, inventario completo y actualizado de terceros, 
monitoreo continuo que compruebe la fiabilidad de lo que informa el proveedor y 
plan de salida para devolver o destruir nuestros datos. Y no se detiene en el proveedor
directo, sino que llega hasta sus subcontratistas (terceros descendentes, o _downstream_),
priorizados de acuerdo al riesgo.

Dos aclaraciones: El [texto obligatorio](https://www.theiia.org/globalassets/site/standards/topical-requirements/third-party/third_party_topical_requirement_spanish.pdf)
no habla de IA; es la [Guía del Usuario](https://www.theiia.org/globalassets/site/standards/topical-requirements/third-party/third_party_tr_user_guide_spanish.pdf),
no obligatoria, la que la menciona al hablar de políticas y monitoreo. Según la 
[Guía de Aplicación de los Requisitos](https://www.theiia.org/globalassets/site/standards/topical-requirements/topical_requirements_application_guidance_english.pdf),
el requisito aplica cuando el tema está en el plan de auditoría, surge durante un
trabajo o se solicita, y el riesgo supera el umbral establecido.

Una lectura que es nuestra, no del IIA: el proveedor de modelos que está detrás 
de nuestro proveedor es ese tercero descendente.

#### El escenario de riesgo (hipotético)

Un banco regional estrena asistente de atención al cliente “con IA” a bombo y platillo.
Su inventario de terceros registra al proveedor, contrato, criticidad y responsable.
Lo que no tiene registrado es que ese proveedor consume un modelo de otra empresa,
en otro país. Seis meses después, la misma empresa modifica sus condiciones sobre
el uso de los datos que recibe. Para el banco el contrato es el mismo; no lo es 
para los datos de sus clientes.

#### El foco del auditor

Vamos a solicitar primero la arquitectura y la lista de subprocesadores, y vamos
a incluir en el inventario de terceros la IA que viene embebida en otros productos.
El [AI RMF del NIST](https://doi.org/10.6028/NIST.AI.100-1) nos da la razón: pide
mecanismos para inventariar los sistemas de IA (GOVERN 1.6) y mapear los riesgos
de todos sus componentes, incluidos los de terceros (MAP 4).

Y si el proveedor no quiere revelar con qué datos entrenó su modelo, no nos quedemos
callados. El [Marco de Auditoría de IA del IIA](https://www.theiia.org/en/content/tools/professional/2023/the-iias-updated-ai-auditing-framework/)
recomienda documentarlo como riesgo y mantener informado al Consejo.

### La prueba de manejo: probar con nuestros datos

Regresemos al auto usado: la prueba de manejo la hacemos por nuestras calles, no
en la pista del vendedor. La prueba se hace con datos del proveedor y poco dice 
de cómo se comportará con los nuestros. De este modo, NIST pide demostrar el comportamiento
en condiciones similares a las del despliegue (MEASURE 2.3) y comprobarlo en producción(
MEASURE 2.4).

En [Achieving Effective Internal Control Over Generative AI](https://www.coso.org/generative-ai),
COSO sugiere realizar pruebas con poblaciones de prueba y casos límite, y nos recuerda
que debemos considerar lo que dice la IA como afirmaciones que deben ser validadas,
no como hechos.

#### El escenario de riesgo (hipotético)

Una compañía de seguros está probando un asistente que extrae los datos de los reclamos.
Casi siempre acierta con la prueba de PDF limpios y bien escaneados. Fotos de formularios
escritos a mano, escaneos torcidos, sellos encima del texto… ya en producción empiezan
a llegar. La precisión se va al tacho, y se alarga la cola de reprocesos. En la 
revisión, nadie recuerda haber definido qué nivel de precisión era aceptable.

#### El foco del auditor

Antes de probar, establezcamos qué significa "suficientemente bueno" y creemos un
conjunto de prueba con nuestros casos difíciles: escaneos, formatos locales, variantes
del español. Ya lo vimos en el artículo anterior: sin línea ni base, no hay mejora
demostrable.

Compartir datos para que se puedan probar con ellos implica riesgos, por lo que 
conviene clasificarlos, anonimizarlos o usar datos sintéticos cuando proceda, y 
poner por escrito el acuerdo sobre cómo se usarán y cuándo se eliminarán antes de
entregarlos. Una otra buena razón para tener [resuelta la gobernanza de datos](https://auditoriainteligente.com/gobernanza-de-datos-bases-esenciales-para-auditar-la-ia/)
antes de negociar.

Que la prueba sea ejecutada por alguien independiente del que patrocina la compra,
como también recomienda el NIST (MEASURE 1.3). Y que guardemos los resultados como
evidencia, pues habrá que repetirlos cada vez que el proveedor haga una actualización.

### Abrir el capó, y volver a abrirlo

Un buen comprador de autos pide un poco más: abrir el capó, y no sólo una vez, porque
este producto va cambiando con el tiempo. COSO advierte que los cambios del proveedor
pueden requerir obligaciones de notificación o de verificación independiente y recomienda
validar las actualizaciones antes de pasarlas a producción.

La Guía del Usuario del IIA dice lo mismo: recomienda una cláusula de derecho de
auditoría que cubra a los subcontratistas, o la prueba de que un asegurador independiente
de buena reputación los auditó. Sin eso, advierte, puede quedar limitada la capacidad
de la auditoría interna para obtener o dar aseguramiento. No basta con tener la 
cláusula, como hemos [visto en las pruebas de control](https://auditoriainteligente.com/pruebas-de-control-en-la-tercerizacion-el-desafio-tactico/),
hay que ejercerla.

#### El escenario de riesgo (hipotético)

El viernes por la tarde el proveedor actualiza su modelo. No lo dice porque no lo
obliga el contrato. El lunes por la mañana, Operaciones observa un disparo en el
rechazo de operaciones legítimas. Cuando Auditoría pregunta qué cambió, nadie puede
responder: no existen registros de la versión del modelo con que reconstruir lo 
ocurrido.

#### El foco del auditor

¿Qué conviene negociar como mínimo?

 * Derecho de auditoría, o un informe independiente, que cubra también a los subcontratistas.
 * Aviso previo de cambios materiales del modelo, con opción de revalidar.
 * Lista de subprocesadores y aviso cuando cambie.
 * Registros de _prompts_ (las instrucciones que se le dan al modelo), salidas y
   versión del modelo; COSO los compara con una "lista de materiales" de IA.
 * Notificación de incidentes.
 * Niveles de servicio con previsiones para fallas y evidencia del plan de continuidad
   del proveedor.
 * Uso de nuestros datos: si el proveedor puede usarlos para entrenar o mejorar 
   modelos, dónde se almacenan, por cuánto tiempo, y su devolución o destrucción
   al salir, con portabilidad en formatos abiertos.

Sobre portabilidad, propiedad de lo personalizado y custodia del código (_escrow_),
conviene repasar [Vendor lock-in](https://auditoriainteligente.com/vendor-lock-in-el-caballo-de-troya-de-la-innovacion-acelerada-en-ia/).
En su [Guía Esencial de Gobernanza de IA](https://www.oceg.org/essential-guide-to-ai-governance/),
la OCEG también recomienda desde la alta dirección la debida diligencia, el monitoreo
continuo, los términos contractuales claros y las auditorías periódicas de los proveedores
de IA y sus planes de contingencia.

No todos los proveedores aceptarán todo, y eso está bien. Lo que no se acepte será
riesgo residual, debiendo ser documentado y comunicado como tal.

### Leer el certificado de la agencia

![Certificado con sello que cubre solo una región resaltada, el resto sin cubrir.](
https://auditoriainteligente.com/wp-content/uploads/2026/10/imagen_2.2-mapa-1024x573.
png)

Vale la pena leer también el certificado. En la Parte 1 de la serie, dijimos que
la certificación es válida para el sistema de gestión, no para el producto. La [norma ISO/IEC 42001](https://www.iso.org/standard/42001)
lo explica: la organización define su propio alcance y puede excluir controles si
lo justifica en su declaración de aplicabilidad (la vimos junto al NIST [aquí](https://auditoriainteligente.com/generando-confianza-en-ia-agentica-mediante-marcos-de-gobernanza/)).
Un certificado puede ser cierto y aún así no cubrir la función, la región o el producto
que compramos.

Imaginemos un proveedor certificado en su plataforma europea y nuestro servicio 
corriendo en otra región. ¿Qué pedimos? El enunciado de alcance, la declaración 
de aplicabilidad y el nombre del organismo certificador acreditado.

La Guía del IIA recoge las certificaciones ISO y los informes SOC como evidencia
de monitoreo, y la Guía de Aplicación permite valernos del trabajo de otros aseguradores,
siempre que documentemos y evaluemos su suficiencia. Es evidencia, sí; conclusión,
no. Y si nos dan un informe SOC, que no se quede en la carpeta: que revisemos los
controles complementarios de la entidad usuaria (CUEC) que nos tocan como clientes.

### Ocho preguntas para poner sobre la mesa

 1. ¿Qué modelos, datos y subprocesadores hay detrás del producto, y quién los cambia?
 2. ¿Qué parte del producto, unidad y región cubre su certificación, y qué controles
    excluyó?
 3. ¿Existe un informe independiente (por ejemplo, SOC) y hemos revisado ya los controles
    aplicables para nuestro alcance?
 4. ¿Qué documenta acerca de sus datos de entrenamiento y su desempeño? Y si no lo 
    comparte, ¿lo estamos registrando como riesgo?
 5. ¿Lo probamos con nuestros datos, con criterios de aceptación definidos de antemano?
 6. ¿El contrato nos otorga derecho de auditoría, o evidencia independiente, que abarque
    a los subcontratistas?
 7. ¿Debería avisarnos de cambios materiales del modelo y dejarnos revalidar?
 8. ¿Qué registros guardamos, qué plan de continuidad hay para los imprevistos y qué
    hace con nuestros datos (uso, retención, salida)?

### Conclusión

Vamos al auto usado: una buena compra es la que incluye haberlo conducido, abierto
y entendido, no la que se basa en el brillo ni en un sello en el parabrisas. Lo 
mismo pasa con la IA. Un sello es un punto de partida, no una prueba, y entre la
promesa y la evidencia hay un trabajo concreto: inventariar, probar, contratar para
verificar y leer los alcances.

No se trata de frenar la compra, sino de asegurar que **lo comprado pueda ser comprobado**.

_El siguiente artículo, **El entusiasmo puertas adentro**: no todas las promesas
son externas; algunas nacen en casa. Veremos cómo medir el retorno real, qué hacer
con la IA que los empleados adoptan por su cuenta y cómo reportarlo al comité (shadow
AI)._