Lo que toda auditoría de IA debería poder responder (y casi nunca puede)

La mayoría de los marcos de cumplimiento (compliance) actuales para la Inteligencia Artificial se centran en el «qué»: ¿Qué modelo usas? ¿Qué datos de entrenamiento tienes? ¿Qué ética profesas? Aunque estas preguntas son valiosas para la política, son inútiles para el control operativo.

Después de auditar sistemas reales y frameworks de vanguardia, hemos llegado a una conclusión incómoda: tener una política de IA no significa que tu IA siga esa política.

Si tu organización está delegando acciones reales en agentes autónomos, hay cinco preguntas de «verdad técnica» que tu auditoría debería ser capaz de responder hoy mismo. Y si no puede, tienes un gap de gobernanza.


1. ¿Quién autorizó esta acción (realmente)?

No nos referimos a qué humano firmó el presupuesto del proyecto. Nos referimos a si el sistema puede demostrar, en tiempo real, que la acción X fue permitida por la regla Y vinculada a la identidad Z.

En muchas arquitecturas, la «autorización» está diluida en el código. Si no hay un interceptor determinista que actúe como aduana antes de cada efecto secundario, tu IA no está autorizada; simplemente está «corriendo libre».

2. ¿Cómo sabemos que los parámetros no fueron alterados?

Es lo que llamamos la Integridad del Intent. Imagina que un humano autoriza una transferencia de 100€. La IA recibe esa autorización, pero en el camino hacia la ejecución, el modelo decide que «1000€ es más eficiente».

Una auditoría de verdad debe poder probar que los parámetros que llegaron al banco (o al ERP, o al cliente) son idénticos a los que pasaron por el filtro de seguridad. Sin un sellado de parámetros (hashing), la IA puede cambiar de opinión entre la autorización y la acción.

3. ¿Existe una prueba que el sistema no pueda borrar?

La mayoría de las empresas confían en los logs de sus aplicaciones. El problema es que esos logs suelen vivir en el mismo entorno que la IA. Si el sistema falla o es comprometido, el rastro de auditoría es lo primero que desaparece.

La gobernanza requiere un Registro de Evidencias no descartable. Un ledger donde cada decisión quede grabada de forma inmutable. Si el sistema puede «olvidar» lo que hizo, no es auditable.


4. ¿Qué ocurre cuando el sistema se «rompe» por dentro?

No hablamos de que se caiga el servidor. Hablamos de cuando la infraestructura de gobernanza falla: cuando el guardrail da error o el validador de políticas no responde.

La pregunta crítica es: ¿el sistema se bloquea o se abre? Si tu IA sigue operando cuando el sistema de control está ciego, no tienes gobernanza; tienes un sistema de control decorativo. La resiliencia real exige que, si la seguridad no puede verificar, la autonomía baje a cero.

5. ¿Podemos reconstruir la cadena de mando?

Ante un incidente, ¿puedes trazar el rastro desde el efecto secundario hasta el prompt original, pasando por el modelo, la versión del código y la política vigente en ese segundo?


La herramienta para responder: La Checklist L1-L6

Hemos formalizado estas preguntas en un instrumento de auditoría técnica que llamamos Implementation Conformance Checklist v1.0. No es un PDF de buenas intenciones; es una herramienta para ingenieros y auditores que evalúa la madurez de la IA en seis capas (desde la autoridad normativa hasta la resiliencia).

El principio central de esta herramienta es: No audites lo que la arquitectura dice que la IA puede hacer. Audita lo que el sistema desplegado puede hacer realidad.


Si quieres ir a la versión formal

Si quieres aplicar este level de rigor en tu organización, el instrumento completo con los estados de conformidad (CONFORMANT, NON-CONFORMANT, etc.) y la taxonomía de la brecha de capacidad está disponible en:

→ Implementation Conformance Checklist v1.0 — LatinFlash Research

Este paper es la traducción operativa de nuestra arquitectura de referencia y es la base de las auditorías aplicadas que publicamos periódicamente.


¿Tu organización está preparada para responder a estas cinco preguntas ante un incidente real? En la próxima entrega, exploraremos un caso donde los tests automatizados dijeron «todo bien» y la realidad fue muy distinta: el punto ciego del oráculo.

— Manuel Enrique Morales Santiago