Preparación para auditoría de la EU AI Act: ¿tu runtime de IA puede aportar pruebas?

En resumen: una auditoría no va sobre tu modelo, sino sobre si tu runtime puede mostrar quién autorizó cada acción de IA, qué cambió y dónde está la evidencia; y la auditabilidad no se puede añadir después, solo registrar a medida que ocurre.

Imagina una sala de reuniones.

Una aseguradora con operaciones en Europa contrató una auditoría externa para un simulacro de cumplimiento de la AI Act. El auditor se sienta, abre su portátil, sin preámbulos, y hace la primera pregunta:

“Sáqueme el recorrido completo de aquella reclamación que el mes pasado la IA marcó automáticamente como ‘riesgo alto de fraude’ y por eso se denegó: quién la disparó, en qué datos se basó la IA, qué regla usó, quién la revisó y qué proceso siguió la reclamación del cliente.”

Y la sala se queda en silencio.

No porque esa denegación fuera necesariamente errónea, sino porque del tramo en que participó la IA en esa decisión no hay en el sistema un lugar completo, continuo e irrefutable del que sacarlo. Los datos de la reclamación están en un sistema, el servicio de scoring de la IA en otro, el registro de revisión en un tercero, y además no están en el mismo libro de cuentas que las operaciones humanas. Para reconstruir la línea que pide el auditor harían falta tres equipos revolviendo logs durante tres días, y aun así no hay garantía de que se reconstruya entera.

A esta empresa no la multaron en ese momento; solo era un simulacro. Pero las sanciones de la AI Act para los sistemas de IA de alto riesgo se calculan como un porcentaje de la facturación global, una magnitud suficiente para que cualquier empresa se lo tome en serio. Y el problema que destapó el simulacro es el que la auditoría real volverá a preguntar, idéntico, unas semanas después.

Esta sala silenciosa es el escenario al que muchas empresas se enfrentarán en 2026.

La cuenta atrás es real, y está muy cerca

La EU AI Act empieza a aplicarse de forma obligatoria en agosto de 2026; y justo a principios de este mes, el 3 de junio, la UE propuso además la Ley de Desarrollo de la Nube y la Inteligencia Artificial (CADA), que por primera vez fija un marco de soberanía de cuatro niveles unificado para toda Europa para los servicios de nube e IA. Para las empresas que operan en Europa o sirven a clientes europeos, esto es cuestión de semanas.

El hecho más incómodo es este: muchas organizaciones usan IA, pero no confían en poder aportar rápido la evidencia que pediría una auditoría independiente de gobernanza. No es que no quieran cumplir, es que cuando llegan de verdad a esa sala, no saben responder.

La auditoría no revisa el modelo, revisa el runtime

Lo primero que muchos equipos hacen por el cumplimiento es evaluar el modelo: si tiene certificación, si produce contenido dañino. Eso importa, pero no es el frente principal de la auditoría. Lo que el regulador quiere de verdad es que puedas dejar claras tres cosas sobre cada acción con la que la IA toca el negocio:

Lo que pregunta el auditor	Qué está revisando	La consecuencia de no saber responder
¿Se trataron estos datos de forma legal?	Dónde están los datos, quién puede leerlos, si han salido de la UE	Incumplimiento de residencia de datos, exposición a la CLOUD Act
¿Quién autorizó a la IA a hacer esta acción?	Bajo qué permisos se contabilizan acciones como denegar o conceder	La responsabilidad no se puede atribuir, la acción es incontrolable
¿Quedó constancia del paso en que participó la IA?	Si puedes presentar una cadena de evidencia completa e irrefutable	La auditoría falla directamente

Ninguna de estas preguntas trata del modelo. Todas tratan de la capa que está más allá del modelo: el runtime que soporta los datos, fuerza los permisos y registra la evidencia.

¿Qué exige exactamente la AI Act para los “sistemas de alto riesgo”?

Esto no es un abstracto “hay que cumplir”. La AI Act enumera por su nombre varias obligaciones duras para los sistemas de IA de alto riesgo (reclamaciones, crédito, contratación, infraestructuras críticas y similares) que vale la pena contrastar una a una, porque casi todas caen en el runtime, no en el modelo:

Lo que exige la AI Act	En qué capa cae	¿Puede darlo el modelo?
Registro automático de eventos (trazable)	El registro de auditoría del runtime	No, el modelo no deja rastro
Supervisión humana (poder intervenir y revocar decisiones críticas)	Las aprobaciones y procesos del runtime	No, hay que forzarlo con el proceso
Decisión explicable (en qué se basó)	Las entradas y reglas registradas por el runtime	En parte, pero el registro irrefutable está en el runtime
Gobierno de datos (origen, permisos, residencia)	Los permisos y el despliegue del runtime	No

Verás que, por potente que sea el modelo, en esta tabla no puede marcar ni una sola casilla. Esta es justo la raíz de que tantos equipos “elijan el modelo con mucho cuidado pero no pasen el cumplimiento”: se esfuerzan en la capa equivocada. Lo que el regulador pide crece, estructuralmente, sobre el runtime.

¿No basta con comprar una herramienta de cumplimiento?

La reacción más natural es: hay un montón de “plataformas de cumplimiento de la AI Act” en el mercado, los proveedores presumen todos de ser conformes; firmas un DPA, consigues una certificación y ya externalizaste el asunto, ¿no?

Este camino resuelve una parte, pero no resuelve el problema de aquella sala.

Las herramientas de cumplimiento y las certificaciones hacen una cosa: registrar y avalar. Le dicen al regulador “tenemos procesos, tenemos documentación, tenemos acuerdos de tratamiento de datos”. Pero lo que el auditor quiere no es “si tienes procesos”, es “sáqueme el recorrido completo de esta en concreto”. La documentación no puede demostrar la legalidad de una acción concreta, y un DPA tampoco responde a ‘en qué permiso se basó la IA para hacer esta denegación, ni quién la revisó’. Este tipo de evidencia solo puede registrarla, en el mismo momento en que ocurre la acción, el runtime que de verdad la ejecuta. Comprar una herramienta te ayuda a controlar la “capa de las políticas”, pero no la “capa de las acciones”; y cuando la auditoría llega al final, lo que pregunta siempre es por una acción concreta.

La auditabilidad no se puede improvisar

Esto lleva a una verdad dura que muchos no han caído: el cumplimiento no es un documento que sacas a toda prisa en el Q3, sino una propiedad que un sistema tiene o no tiene.

Esa cadena de evidencia que quiere el auditor tiene que registrarse en el mismo instante en que ocurre la acción. Si el runtime no la registró entonces, por mucho que te lances a una carrera contrarreloj antes del siguiente hito regulatorio, no podrás conjurar el recorrido real de aquella denegación del mes pasado; lo único que puedes hacer es “reconstruir”, y un registro reconstruido el auditor sabe de un vistazo que no es fiable.

Por eso “primero lanzamos la IA y el cumplimiento ya lo veremos” es una apuesta peligrosa: apuestas a que la auditoría no preguntará por las acciones que entonces no se registraron. En cuanto pregunte, todas las decisiones de IA de ese periodo se convierten en un hueco imposible de probar.

Antes de entrar en la sala de auditoría, autocomprueba con estas cinco preguntas: cualquiera a la que no puedas responder “sí” es un punto de riesgo:

1. Toma al azar cualquier acción de negocio en la que participó la IA: ¿puedes sacar en el acto su recorrido completo?
2. ¿Los permisos los fuerza el runtime, o están escritos en el prompt?
3. ¿Las acciones de las personas y de los agents quedan en el mismo registro de auditoría?
4. Estos datos y este proceso de tratamiento, ¿bajo qué jurisdicción caen?
5. Si algo falla, ¿puedes detener con un clic un agent o un tipo de acción?

Por qué “meter las reglas en el prompt” no pasa esta prueba

No pocos equipos sí hicieron gobernanza, solo que en el lugar equivocado: la metieron en el prompt. “Solo puedes consultar los datos sobre los que el usuario actual tiene permiso”, “las reclamaciones de alto riesgo requieren revisión humana”; en el día a día hasta parece que funciona. Pero no pasa la auditoría, y por dos razones, ambas fatales:

Primero, el prompt es una sugerencia, no un control. Surte efecto porque el modelo “quiera hacer caso”; un solo jailbreak, un solo borde no cubierto, y se sortea. Cuando el auditor pregunta “¿cómo garantizas que cierto tipo de reclamación pasa siempre por revisión humana?”, “lo escribimos en el prompt” no es una respuesta que se pueda firmar.

Segundo, el prompt no produce registro. La auditoría quiere evidencia estructurada e irrefutable, y el prompt no la da.

Lo que el cumplimiento exige de verdad es trasladar la gobernanza de “una sugerencia en el prompt” a “una imposición en el motor de ejecución”: los permisos los verifica el runtime en cada lectura y escritura, y la auditoría es un subproducto natural de la acción.

Tras CADA, “dónde están los datos” pasa a ser un indicador duro, pero el autoalojamiento no es una indulgencia

CADA empuja otra cosa al primer plano: la soberanía de datos. En esencia pregunta: tus datos y tu proceso de tratamiento por IA, ¿bajo qué jurisdicción están? Y esa pregunta apunta directamente a la forma de despliegue. Entregar el runtime de IA que lee datos de negocio reales a un SaaS externo cuyo interior no puedes examinar y que además cae bajo la CLOUD Act es cada vez más difícil de firmar bajo el nuevo marco. El autoalojamiento mejora de un golpe la residencia de datos, la exposición a terceros y la visibilidad; lo que hay que autoalojar no es necesariamente el modelo, sino el runtime que soporta los objetos, los permisos, las herramientas, las aprobaciones y la evidencia de auditoría.

Pero hay que decirlo con honestidad: el autoalojamiento no es una indulgencia, es una transacción. Cuando el runtime corre en tu propia infraestructura, parchear, rotar claves, garantizar que no se pierdan los logs, cortar de raíz con un clic si algo falla: esas operaciones y esa carga de la prueba también recaen en ti. Lo que ganas es el control, y el precio es la responsabilidad. A la inversa, si quieres que otro asuma esa responsabilidad por ti, normalmente significa entregarle también los datos. En esta cuenta no hay un lado que salga gratis; depende de qué precio puedas asumir y firmar.

Qué pinta tiene un runtime que se puede firmar

Da la vuelta a los requisitos de arriba y tendrás la lista de aceptación. La prueba más directa no es mirar la presentación del producto, sino ver si puede escupir en el acto el registro que pide el auditor. En ObjectOS, aquella denegación del principio sale así:

{
  "event": "claim.decision.update",
  "actor": { "type": "agent", "on_behalf_of": "user:risk.bot.supervised" },
  "object": "ins_claim/CLM-88231",
  "decision": { "from": "pending", "to": "rejected", "reason_code": "fraud_high" },
  "model_evidence": ["device_mismatch", "velocity_anomaly"],
  "permission_checked": "claims_adjuster → allowDecide: true",
  "human_review": { "rule": "fraud_high → requiere revisión humana", "by": "user:wang.adjuster", "at": "2026-05-12T09:40:55Z" },
  "timestamp": "2026-05-12T09:31:02Z"
}

En este registro está todo: quién, qué hizo, en qué se basó la IA, qué permiso disparó, quién revisó y cuándo. No es una ingeniería añadida a posteriori, es una anotación que el runtime deja de pasada cuando el agent invoca una herramienta gobernada bajo una identidad supervisada. Las personas y los agents pasan por el mismo motor de permisos y quedan en el mismo registro. Y la definición de negocio (objetos, permisos, flujos de revisión) son metadatos en tu repositorio, diff-eables y trazables: cuando el auditor pregunta “qué tipo de reclamación requiere obligatoriamente revisión humana”, la respuesta no está en la cabeza de alguien, está escrita en la definición del proceso.

Cierre

Quedan solo unas semanas para agosto. Volvamos a aquella sala: si el auditor se sentara ahora mismo y te pidiera el recorrido completo de cierta decisión de IA del mes pasado, ¿podría tu sistema escupirlo en ese instante, sin que tres equipos pasen tres días revolviendo logs?

No saber responder casi nunca se debe a que el modelo no dé la talla, sino a que la gobernanza se puso en la capa equivocada: metida en el prompt, externalizada a la documentación de políticas, en lugar de aterrizada en el runtime. Devuélvela al runtime y esa cadena de evidencia estará ahí antes de que la necesites. Esto no se puede improvisar; solo se puede hacer que sea cierto ahora.

npm i -g @objectstack/cli && os start

Haz que un agent cambie un dato bajo la identidad de cierto usuario y luego abre el registro de auditoría: verás que la línea que quiere el auditor ya estaba ahí desde el principio.