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

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, pruebas de control y analítica). Aquí nos centramos en la novedad: un servicio que puede cambiar de comportamiento sin que cambie el contrato.

En la Parte 1 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 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)

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 no habla de IA; es la Guía del Usuario, no obligatoria, la que la menciona al hablar de políticas y monitoreo. Según la Guía de Aplicación de los Requisitos, 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 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 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, 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 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, 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. En su Guía Esencial de Gobernanza de IA, 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

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 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í). 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).