Cumplimiento como política ejecutable

La mayoría de las organizaciones trata el cumplimiento como un documento. Se escribe una política, se revisa, se firma y se archiva. El sistema se construye aparte, y en algún punto intermedio el dueño de un control certifica que ambos están alineados. Para software determinista, actualizado en un calendario de entregas, el arreglo casi funciona.

Solo que un agente no lee tu PDF de política y no hace una pausa para tu revisión trimestral de controles. Actúa sobre contexto en vivo, de forma probabilística, potencialmente miles de veces al día, y puede comportarse distinto tras una actualización nocturna del modelo para la que nadie abrió una petición de cambio. Un régimen de cumplimiento que vive en un documento al lado del sistema no puede gobernar un sistema que se mueve así de rápido. La obligación tiene que correr dentro del sistema, o no corre en absoluto.

Este es el giro que el EU AI Act, DORA y el RGPD imponen discretamente a las empresas reguladas: el cumplimiento deja de ser un PDF y pasa a ser código que se ejecuta, emite veredictos que el flujo tiene que obedecer y deja evidencia que un regulador puede reconstruir.

La política es código del que tu equipo de cumplimiento es dueño

El instinto es que los ingenieros incrusten la lógica de cumplimiento en el código del agente. Ese es el dueño equivocado. Quien responde ante el regulador es tu equipo de cumplimiento, así que tiene que ser dueño de las reglas y poder demostrarlo.

En la práctica eso significa política como código: un punto de decisión de políticas, un motor OPA o Rego, que tu equipo de cumplimiento versiona, prueba, firma criptográficamente y aprueba antes del despliegue. El mecanismo queda limpiamente separado de la decisión. Los ingenieros construyen la maquinaria que le pregunta al motor de políticas "¿puede esto seguir adelante?". El equipo de cumplimiento es dueño de las reglas que responden. Ninguno de los dos puede pasar por encima del otro en silencio, y la separación es en sí misma auditable.

El dividendo es que una regla de cumplimiento pasa a ser un artefacto comprobable y versionado, con firma y dueño, y no una interpretación que vive en la cabeza de alguien o enterrada en el código de la aplicación. Cuando un regulador pregunta "¿quién decidió que esto estaba permitido, y cuándo?", la respuesta es una versión firmada de la política, no una reunión de la que nadie levantó acta.

Las políticas además caducan por tiempo de vida. Cada regla tiene que revisarse, reaprobarse y volver a firmarse en plazo, lo que hace la desactualización visible y gobernable en lugar de silenciosa. Una regla que envejeció en silencio hasta dejar de tener sentido deja de ser riesgo invisible y pasa a ser un punto señalado que alguien tiene que volver a firmar.

Cada gate se resuelve en uno de cuatro veredictos

Para que el flujo obedezca la política, la política tiene que hablar en veredictos sobre los que el flujo pueda actuar. Cada gate de cumplimiento se resuelve en uno de cuatro.

• ALLOW. Todas las condiciones satisfechas. El agente sigue adelante sin intervención humana.
• ALLOW-WITH-CONDITIONS. Parcialmente satisfechas. El agente sigue adelante bajo restricciones documentadas, como registro adicional, un límite de alcance o una marca de revisión.
• DENY. Falla una condición dura. La transacción se bloquea, sin vía de excepción.
• REQUIRE-HUMAN. La decisión tiene peso regulatorio que no se puede delegar. El agente solo analiza; decide una persona.

Los cuatro veredictos son lo que convierte "el sistema es conforme" de una garantía en un mecanismo. Una garantía no se puede probar. Un veredicto sí: puedes señalar cualquier transacción y ver qué veredicto se disparó, bajo qué versión de política, y por qué.

REQUIRE-HUMAN es el veredicto que sostiene el trabajo regulado

De los cuatro, uno carga con el peso del caso de uso regulado, y merece la pena conectarlo directamente con la ley.

Bajo el artículo 22 del RGPD, una persona tiene derecho a no ser objeto de una decisión basada únicamente en el tratamiento automatizado cuando produzca efectos jurídicos o le afecte significativamente. La decisión de crédito, la denegación de un siniestro, la aprobación de cumplimiento: no se pueden delegar del todo en una máquina. En esta arquitectura, se resuelven en REQUIRE-HUMAN por política. El agente prepara, verifica y orquesta. La decisión regulada se queda con una persona.

Es fácil leerlo mal, como una limitación atornillada para contentar a un abogado. Es lo contrario. Es el diseño que permite que todo el sistema sea lícito. Un agente que tomara él mismo la decisión con consecuencia sería más rápido e ilegal. Un agente que hace todo el trabajo hasta la decisión y le entrega a una persona un expediente completo y evidenciado es rápido y lícito. REQUIRE-HUMAN no es la debilidad del agente. Es la frontera que hace defendible la autonomía en todo lo demás.

Sin evidencia, no hay decisión

Una política que corre es solo la mitad de la obligación. La otra mitad es demostrar, después, qué pasó. Bajo las expectativas de registro del EU AI Act (artículo 12), tienes que poder reconstruir por qué se tomó una decisión.

Así que cada decisión de un agente deja un rastro de evidencias append-only, encadenado por hash, en almacenamiento de escritura única, escrito antes de que la decisión se confirme. El orden importa: el registro se escribe primero, y solo después la decisión surte efecto. Si la evidencia no se puede escribir, la decisión no ocurre. El sistema falla cerrado.

Esa única regla, sin evidencia no hay decisión, es lo que hace a un agente inspeccionable en lugar de una caja negra. El registro de cualquier decisión recoge quién actuó, bajo qué autoridad, sobre qué datos, contra qué versión firmada de política, a qué nivel de autonomía y con qué evidencia. El encadenado por hash significa que el rastro no se puede editar en silencio después: manipularlo rompe la cadena. Cuando tus auditores señalan una transacción, les entregas un registro, no una reconstrucción.

Esta es además la respuesta a la pregunta que un comité de riesgos hace de verdad: ¿cómo aprobamos una caja negra? La respuesta honesta es que, para el comité, no es una caja negra. Es un sistema donde cada decisión llega ya evidenciada, contra una política que el equipo de cumplimiento firmó, con las decisiones con consecuencia reservadas a personas. El comité aprueba un control documentado y comprobable, no una promesa.

Construido para el horizonte regulatorio, no solo para la regla de hoy

Los reglamentos no están quietos, y ese es el argumento final para hacer el cumplimiento ejecutable en lugar de documental.

El artículo 4 del EU AI Act ya está en vigor: desde febrero de 2025, las organizaciones que despliegan IA tienen que asegurar que sus operadores tengan alfabetización suficiente en IA, y las autoridades nacionales empezaron a supervisarlo desde agosto de 2025. Las obligaciones de alto riesgo, las reglas de resiliencia operativa de DORA, el derecho a explicación y los requisitos de residencia de datos van llegando en sus propios calendarios. Un régimen de cumplimiento codificado como política firmada, versionada y con caducidad se adapta a medida que evolucionan las reglas, porque cambiar un control significa cambiar un artefacto de política, no reconstruir el sistema. Un régimen de cumplimiento que vive en PDFs se adapta a la velocidad de un ciclo de revisión documental, es decir, demasiado despacio.

Así que el replanteamiento que merece la pena llevar a tu próxima auditoría no es "¿somos conformes con la regla actual?". Es ¿podemos ejecutar nuestras obligaciones como política firmada y comprobable, demostrar cada decisión con evidencia escrita antes de que se confirme, y cambiar un control sin reconstruir el sistema? Si el cumplimiento sigue viviendo en un documento al lado del sistema, estás certificando un alineamiento que no puedes demostrar cuando te lo pidan.

Si quieres ver una obligación convertida en un control corriendo sobre un proceso real, reserva una reunión.