Lo que un agente puede hacer no es lo que debe hacer

Cuando damos acceso a un sistema, respondemos a una pregunta técnica: ¿puede esta entidad ejecutar la acción X? Es la lógica del control de acceso de toda la vida. Roles, permisos, una puerta que se abre o no se abre. Binario y cómodo.

Con los agentes esa pregunta se queda corta. Un agente con acceso al correo, al calendario y a la cuenta de facturación puede, técnicamente, hacer cientos de cosas. La cuestión deja de ser qué es capaz de hacer y pasa a ser qué le permitimos hacer, qué le obligamos a hacer y qué le prohibimos. Eso ya no es una cerradura. Es una norma.

Un trabajo reciente en arXiv (cs.AI), Deontic Policies for Runtime Governance of Agentic AI Systems, pone nombre a esa intuición. La palabra clave es deóntica: la lógica de la obligación, el permiso y la prohibición. La misma que usamos, sin llamarla así, cuando escribimos el código de conducta de una empresa.

Permiso técnico no es permiso normativo

La diferencia es más profunda de lo que parece. El control de acceso impide. Si no tienes la llave, no entras, y punto. Una política deóntica describe una conducta esperada: puedes hacer esto, debes hacer aquello, no debes hacer lo otro. Y aquí está el matiz incómodo: una norma se puede violar. Un empleado con acceso a la base de datos de clientes tiene el permiso técnico para exportarla entera; la política de la empresa es lo que dice que no debe, y el control posterior es lo que detecta si lo hizo.

Con software determinista esa brecha apenas existe: lo que no programas, no ocurre. Con un agente que decide en tiempo de ejecución, planifica pasos y encadena herramientas, la brecha reaparece. El agente puede combinar acciones individualmente permitidas para producir un resultado que nadie autorizó. Cada movimiento es legal; la jugada completa, no.

Gobernar en ejecución, no solo en el diseño

De ahí lo de runtime governance, gobernanza en tiempo de ejecución. La idea no es solo poner barreras antes de empezar, sino vigilar la conducta mientras ocurre. Expresar las reglas en términos de negocio (este agente nunca mueve dinero sin una segunda firma, siempre registra a quién contactó, jamás borra un registro original) y comprobar contra ellas cada acción real.

Es un cambio de modelo mental que conviene a quien decide. Configurar un agente se parece menos a abrir puertos en un firewall y más a incorporar a alguien nuevo: le das acceso, sí, pero sobre todo le explicas qué se espera de él, qué no se tolera y cómo se audita su trabajo. La organización que ya sabe redactar políticas internas tiene media tarea hecha; solo le falta traducirlas a algo que una máquina pueda comprobar.

Lo práctico

Antes de delegar un proceso a agentes, el orden útil es este. Primero, escribir la norma en lenguaje de negocio, no de permisos: qué obligaciones, qué permisos, qué prohibiciones. Segundo, separar esa norma del acceso técnico, porque responden a preguntas distintas y se mantienen distinto. Tercero, asumir que la norma se puede romper y, por tanto, instrumentar la detección: si solo previenes, te enteras de lo que bloqueaste, no de lo que se coló.

No es un detalle de ingeniería. Es la condición para delegar con criterio. Un agente sin política deóntica explícita hace lo que su acceso le permite, que casi siempre es más de lo que querríamos. Y la pregunta que deberíamos hacernos antes de soltarlo no es si funciona, sino qué le hemos prohibido y cómo lo sabríamos si lo intentara.

¿Tu organización tiene escrito, en algún sitio, lo que sus agentes no deben hacer? ¿O solo lo que técnicamente pueden?