La IA de compliance debe contrastar con reglas, no releer la normativa. Abu Dhabi lo puso en producción

Pregúntele a un modelo de lenguaje si un envío cumple una normativa de importación y leerá la normativa, los documentos del envío y su pregunta, y producirá una respuesta. Vuelva a preguntarle mañana con los mismos documentos y lo leerá todo otra vez. Cada respuesta es una interpretación nueva de la ley, hecha por un modelo, en el momento de la consulta, sin registro de qué lectura de la regla aplicó.

Así funcionan hoy la mayoría de los asistentes de compliance, y es el diseño equivocado para el trabajo regulado.

Qué hizo Abu Dhabi de forma distinta

El 2 de noviembre, el Gobierno de Abu Dhabi y OpenAI lanzaron lo que llaman una iniciativa Machine-Readable Government, nativa de IA, liderada y gobernada por el Department of Government Enablement del emirato. Abarca un conjunto definido de políticas y regulaciones gubernamentales y las convierte en una forma que los sistemas de IA pueden aplicar a evaluaciones rutinarias de compliance, como permisos y certificados.

El primer piloto está en producción en la Abu Dhabi Agriculture and Food Safety Authority y se centra en las importaciones de alimentos. Dos compromisos de diseño destacan en el anuncio: cada evaluación es trazable hasta la regla que la gobierna, y los funcionarios mantienen la supervisión y la responsabilidad sobre las decisiones finales. La inferencia se ejecuta en GPUs en centros de datos de Emiratos Árabes Unidos.

No se publicaron resultados de precisión, velocidad ni costo, y la afirmación de los patrocinadores de que es el primero del mundo es suya. Lo útil es la arquitectura, porque invierte la habitual.

La interpretación se adelanta y ocurre una sola vez

En un diseño legible por máquina, el trabajo duro de interpretación sigue ocurriendo, pero antes, lo hacen personas y solo una vez por versión de la regla. Abogados y reguladores deciden qué significa una cláusula en términos operativos, la codifican, revisan la codificación y la publican con una versión. La IA hace entonces un trabajo más acotado: mapear el caso a las reglas aplicables, contrastar la evidencia con ellas y citar qué regla, en qué versión, aplicó.

1. Texto de la regulación
2. Regla codificada, versionada y revisada
3. Evaluación de la IA que cita la regla y la versión
4. Un funcionario decide y responde por ello
5. Registro del caso, la regla, la evidencia y la decisión

• Personas, una vez por versión de la regla: Texto de la regulación · Regla codificada, versionada y revisada
• Cada caso: Evaluación de la IA que cita la regla y la versión · Un funcionario decide y responde por ello · Registro del caso, la regla, la evidencia y la decisión

Es el mismo movimiento que varios proveedores están haciendo en datos empresariales. El nuevo Ontology Manager de SAP Business Data Cloud, anunciado el 29 de octubre, construye vistas de dominio de un grafo de conocimiento que conecta entidades de negocio, relaciones y reglas, para que los agentes trabajen contra un contexto definido y no contra documentos en bruto. La arquitectura Deep Trust de Oracle lleva las reglas de negocio a la base de datos como aserciones que ninguna consulta generada puede eludir. El patrón es consistente: mantener el modelo lejos de la parte que define qué está permitido.

Por qué esto importa más de lo que parece

Hemos sostenido que la prueba en la IA regulada tiene que venir de fuera del modelo. Una regla versionada es exactamente eso: un artefacto que el modelo no escribió y contra el cual se puede verificar su salida. También responde la pregunta que un inspector hará primero. “¿Por qué aprobó el sistema esto?” obtiene una respuesta nítida, por ejemplo: la regla 4.2 en su versión de marzo, los elementos de evidencia uno a tres, decidido por este funcionario.

También es la extensión lógica de tratar las habilidades de agente como documentos controlados. Una habilidad le dice a un agente cómo hacer una tarea; una regla codificada le dice qué ha decidido la organización que exige una regulación. Ambas son procedimientos, ambas necesitan un dueño, una revisión y una versión.

Nuestra opinión, y es una opinión y no un hecho: en dos años, se esperará que las empresas reguladas muestren la base de reglas que hay detrás de una decisión de compliance asistida por IA, no el prompt.

Lo que no desaparece

Codificar una regla no elimina la ambigüedad: registra una interpretación y la hace consistente. Eso es un beneficio solo si la interpretación se revisa y se puede cuestionar. Tres cosas necesitan diseño desde el principio.

Excepciones y apelaciones. Los casos reales caen entre reglas. El sistema necesita una vía que los derive a una persona con el motivo, y esos casos deberían alimentar la siguiente versión de la base de reglas.

Control de cambios. Cuando cambia la regulación, cada regla codificada derivada de ella necesita revisión, y las decisiones pasadas deben seguir vinculadas a la versión que usaron.

Propiedad. Alguien en legal o en compliance es dueño de cada regla, igual que alguien es dueño de cada definición de negocio que lee un agente. Sin un dueño, la base de reglas se convierte en otro prompt sin revisar, solo que más largo.

Para el equipo de calidad de una farmacéutica, la función de compliance de un banco supervisado por la CNBV en México, la de una aseguradora supervisada por la DGSFP en España o un agente aduanal, el primer paso no es elegir un modelo. Es escoger una evaluación acotada y de alto volumen, escribir sus reglas en una forma que una máquina pueda aplicar y conseguir que quienes son dueños de la regulación firmen la codificación.