El problema central de gobernar agentes de IA autónomos es el tiempo. Un agente puede consultar una base de datos, recuperar registros sensibles y desencadenar acciones posteriores en milisegundos. Cualquier modelo de gobernanza que dependa de revisar acciones antes de que ocurran, o que confíe en que un modelo elegirá mantenerse dentro de los límites, es estructuralmente demasiado lento y demasiado optimista. El único punto de cumplimiento que funciona a la velocidad de los agentes es la capa de datos misma: controles de acceso, enmascaramiento, auditoría y gestión de identidades aplicados en el momento en que una consulta llega a la base de datos.
Esto importa porque el comportamiento del agente es probabilístico. Un modelo podría seguir instrucciones la mayoría de las veces, pero "la mayoría de las veces" no es un estándar aceptable para el acceso a datos en entornos regulados. La solución no es agregar más instrucciones al agente, sino construir controles que el agente no pueda eludir sin importar qué decida hacer. Esa es la diferencia entre una política que existe en papel y una que es físicamente ejecutada por el sistema que maneja los datos.
La implicación práctica es que las empresas necesitan extender su stack de gobernanza de datos existente para tratar a los agentes como actores de primera clase. Los agentes deben llevar su propia identidad, e esa identidad debe incluir un propósito declarado vinculado al inicio de la sesión. Una vez que el propósito es un atributo que el motor de políticas puede leer, evalúa las solicitudes del agente de la misma manera que evalúa el acceso basado en roles humanos, y el registro de auditoría captura no solo qué fue accedido, sino por qué el agente afirmó que necesitaba acceso. Este es el mecanismo que hace posible la reconstrucción posterior a incidentes.
Los nueve controles específicos que vale la pena implementar se dividen en tres grupos. Primero, hacer cumplir el acceso: controles basados en roles y atributos aplicados en tiempo de consulta para agentes y usuarios, enmascaramiento dinámico de columnas e identidad del agente con propósito declarado preservado junto con la identidad del usuario actuante. Segundo, hacerlo auditable: clasificación de datos que impulse políticas, registro a nivel de sesión vinculado a la identidad del agente y propósito declarado, y trazabilidad a través de canalizaciones. Tercero, unificar la ejecución: gestión de políticas centralizada, cifrado en tránsito y en reposo, y controles consistentes ya sea que la carga de trabajo se ejecute localmente, en la nube o en entornos aislados.
Para equipos que construyen sobre Postgres o evalúan plataformas de datos de código abierto, la arquitectura subyacente aquí tiene una ventaja significativa: la gobernanza ejecutada a nivel de base de datos no depende del framework del agente, del proveedor del modelo o de ninguna capa de abstracción por encima de los datos. Los controles viajan con los datos. Esto es particularmente relevante para industrias reguladas donde los requisitos de soberanía de datos hacen que sea impracticable ceder la gobernanza a infraestructura que no posees o no puedes inspeccionar.
El consejo para los desarrolladores: no esperes hasta que un agente haga algo inesperado para descubrir dónde está tu límite de cumplimiento. Audita qué controles de identidad y acceso ya soporta tu base de datos, determina si tu configuración actual puede reconocer un agente como un actor principal distinto con permisos limitados, y verifica que tu registro capture suficiente contexto para reconstruir qué hizo un agente y por qué. Los controles probablemente ya existen en tu stack: el trabajo es extenderlos para cubrir actores no humanos antes de que esos actores estén en producción.