Ya quedó atrás el "hay que escribir mejores prompts". El consenso que se está formando para agentes en industrias reguladas es sensato: la salida del modelo es probabilística y lo va a seguir siendo, así que entre el modelo y la consecuencia tiene que haber algo determinístico. Una barrera. Antes de cada paso se le pregunta; contesta ALLOW o DENY, sin ningún modelo adentro, siempre lo mismo para el mismo estado, y deja un registro firmado de la decisión. Ante cualquier ambigüedad, falla cerrado. La decisión se registra antes de que la acción se ejecute.
Todo eso es correcto, y es una mejora real frente a un agente que narra su propio cumplimiento. Nada de lo que sigue va en contra de las barreras.
Pero "cada paso pasa por una barrera" se está volviendo lo que fue "firmamos cada acción": una frase a la que se le cargan varias garantías. Cuando un auditor aprieta, se abre en tres preguntas. Cada una tiene una respuesta barata y una cara, y el titular no siempre dice cuál estás comprando.
Primera pregunta: ¿qué pasa si nadie le pregunta a la barrera?
Una barrera puede ser consultiva o estructural.
Una barrera consultiva es un servicio al que tu aplicación llama antes de actuar. La barrera decide y tu código respeta la decisión: si la respuesta es DENY, tu código corta. Si tu código no llama (un camino nuevo que alguien agregó, un reintento que se saltea el chequeo, una herramienta a la que el agente llega directo), la acción corre igual, y la barrera no tiene registro de que la pasaron por alto, porque para ella no pasó nada.
Ahí el cumplimiento depende de la disciplina de integración, que existe y muchas veces alcanza. Pero vive en la capa de aplicación, así que la garantía vale lo que vale el camino de código más débil que puede llegar al efecto.
Una barrera estructural está donde ocurre el efecto. El agente no tiene las credenciales para actuar; sólo puede mandarle una propuesta a quien sí las tiene. La barrera es lo único capaz de apretar el botón, así que el agente no tiene camino que la rodee, y saltearse la llamada no produce nada.
La prueba: si borro la llamada a la barrera, ¿la acción ocurre igual? Si ocurre, tenés una barrera consultiva. Decilo, y poné el esfuerzo en demostrar que todos los caminos la llaman.
Segunda pregunta: ¿el recibo prueba un permiso o una ejecución?
Una barrera que registra su decisión antes de la acción hace algo valioso: deja evidencia de que el paso estaba autorizado en ese momento, con ese estado, y de que esa autorización no se puede reescribir en silencio después.
Pero conviene leer bien el recibo. Dice ALLOW, paso 4, secuencia 812, a las 14:02:11. No dice nada sobre si el paso se ejecutó, qué hizo, si salió bien ni si lo que se ejecutó fue lo autorizado. Un permiso y una ejecución son dos eventos distintos, y la firma cubre el primero.
Es una afirmación distinta de las tres que hace un recibo firmado. La integridad puede ser perfecta (el registro está intacto) y la trustlessness también (la clave la tenés vos); el recibo sigue siendo un enunciado verdadero sobre un permiso, y la veracidad de la acción queda abierta. Un auditor que reconstruye un incidente necesita las dos mitades, si estaba permitido y qué pasó en realidad, enlazadas para que ninguna se aparte de la otra.
Enlazarlas hace falta, pero no alcanza. Un registro de resultado puede estar en la misma cadena que el permiso y aun así ser algo que informó quien llamó. La prueba: para un ALLOW dado, ¿me mostrás el registro de ejecución que produjo, y quién lo escribió: el sistema que ejecutó el paso o la aplicación que le avisa a la barrera que lo hizo?
Tercera pregunta: ¿la barrera chequeó el estado o un informe del estado?
Toda barrera evalúa alguna precondición. "La verificación de identidad tiene que terminar antes del scoring crediticio." La pregunta es qué mira la barrera para decidir que la verificación terminó.
Si la barrera sigue la secuencia (qué pasos se informaron como hechos y en qué orden), sabe que alguien informó el paso de verificación. No sabe si la verificación dio bien. La falla que la barrera venía a evitar, un modelo que da por hecho un chequeo sin haberlo corrido, sube una capa: ahora es la aplicación la que informa que el chequeo se hizo, y la barrera firma una secuencia de afirmaciones en perfecto orden.
Si la barrera evalúa la precondición contra el estado del propio sistema (el registro de verificación que el sistema mismo guardó), entonces "verificación completa" es un hecho que la barrera lee de los registros del sistema. Eso sólo es posible si la barrera tiene acceso al estado, y en general eso quiere decir que la barrera y el estado viven en el mismo lugar.
La prueba: si la aplicación informa un paso como completo cuando no lo está, ¿la barrera se entera? Si la respuesta honesta es no, la barrera hace cumplir el orden, no la verdad.
Los límites, sin maquillaje
Cada respuesta cara tiene un costo real, y las baratas tienen virtudes reales.
Lo estructural cuesta portabilidad. Una barrera consultiva funciona con cualquier framework y cualquier agente: agregás una llamada y listo. Una estructural exige que las acciones pasen por quien tiene la autoridad, es decir, un runtime. Es un compromiso más pesado, y para pasos de bajo impacto puede no valer la pena.
Lo estructural ata al agente, y dos caminos quedan afuera. Quien tenga las credenciales de la base de datos puede escribir por fuera del runtime, y cualquier herramienta de salida que el agente tenga permitido llamar está tan controlada como su propio chequeo. Hay que nombrar las dos cosas.
Enlazar el permiso con la ejecución exige ser dueño de la ejecución. Una autorización sólo se puede atar al evento que produjo si el mismo sistema guarda los dos. Una barrera que está al costado del sistema puede registrar permisos de manera impecable y no ver nunca qué pasó después.
Chequear el estado real exige tener el estado real. Y aun así, la barrera sólo puede chequear lo que el sistema sabe. Una precondición que depende de un sistema externo sigue dependiendo de lo que ese sistema informa. Derivar del estado achica la brecha, y en cada borde externo queda una parte. Hay que decir dónde están esos bordes.
Una barrera estructural hace cumplir lo que se declaró. Si la política está mal, la barrera hace cumplir la política equivocada, de forma determinística y con registro firmado. El error queda visible y atribuible, lo cual sirve, pero la política igual tiene que estar bien.
Lo que está en juego
Una barrera consultiva, que sigue la secuencia y firma recibos antes de la acción, es mucho mejor que un agente que escribe su propio log, y para muchos casos alcanza.
El problema aparece sólo cuando las tres se dicen como si fueran una. "Determinístico, con barrera, con recibos criptográficos" suena a una sola garantía. Un auditor escucha tres afirmaciones y pregunta por cada una: ¿se pudo haber salteado?, ¿pasó de verdad?, ¿la precondición era cierta? Una barrera que contesta las tres con "pasa por la barrera" se queda sin respuesta en la primera repregunta. Una que contesta cada una por separado (es consultiva, y así demostramos que todos los caminos la llaman; el recibo cubre la autorización, y este es el que registra la ejecución; el orden se hace cumplir, y estas son las precondiciones que se leen del estado) suena más modesta durante una oración y tiene respuesta para cada repregunta.
Este artículo afina, del lado de la barrera, un argumento más amplio: la comunicación y la propuesta pueden ser probabilísticas, pero la autoridad, la consecuencia y el registro de las dos tienen que ser determinísticos, declarados y verificables. La versión de este argumento para la prueba está en Un recibo firmado son tres afirmaciones, no una; el caso de la aplicación estructural, en El agente propone; el runtime aprieta el botón.
Nicolás Moreno construye Zarel: operaciones de IA gobernadas, donde la IA propone y el contrato dispone.