Por qué el control de los agentes de IA debe vivir en la capa de datos
A medida que las empresas dan más autonomía a los agentes de IA, las políticas de gobernanza tradicionales resultan insuficientes: el control debe ejecutarse donde los agentes realmente trabajan, en las bases de datos.
Las empresas deben aplicar gobernanza de agentes de IA directamente en la capa de datos (las bases de datos donde trabajan), usando controles de acceso basados en roles, enmascaramiento dinámico y registros de auditoría que traten al agente como una identidad independiente con un propósito declarado, porque las políticas externas no pueden revisar acciones que ocurren en milisegundos.
Cuando una empresa permite que un agente de IA (un sistema que planifica, decide y actúa de forma autónoma sin que un humano apruebe cada paso) ejecute acciones por su cuenta, surge una pregunta difícil: ¿qué detiene realmente al agente cuando intenta hacer algo que nunca se le autorizó? Según informó VentureBeat, la respuesta no puede estar solo en políticas abstractas o en instrucciones que rodean al modelo, sino en la capa operativa donde el agente trabaja: la base de datos.
El problema es que los agentes operan en milisegundos y a través de múltiples sistemas a la vez. Las reglas que viven fuera de la base de datos —como políticas de cumplimiento escritas en documentos o guardarraíles (restricciones de comportamiento) programados alrededor del modelo— no pueden revisar ni bloquear cada acción antes de que ocurra. Además, el comportamiento de un agente es probabilístico por diseño: puede elegir rutas inesperadas para resolver una tarea. La gobernanza no puede depender de que el agente "decida" seguir las reglas; debe estar integrada en el sistema que almacena y entrega los datos.
La propuesta de EDB (una empresa que desarrolla plataformas de bases de datos basadas en Postgres, un sistema de gestión de bases de datos de código abierto) es tratar al agente como una identidad de primera clase dentro de la base de datos. Esto significa que cuando el agente abre una sesión, declara su propósito (por ejemplo, "generar un informe de ventas para el usuario X") y ese propósito se evalúa junto con otros atributos como el rol o el departamento. Los controles de acceso basados en roles y atributos (políticas que definen qué datos puede ver cada usuario o sistema según su función), el enmascaramiento dinámico de columnas (ocultar información sensible según quién pregunta), y los registros de auditoría a nivel de sesión permiten rastrear qué hizo el agente, para quién, y bajo qué propósito declarado.
Estos controles no son nuevos: muchas empresas ya los usan para usuarios humanos. Lo que cambia es que ahora deben reconocer al agente como un actor independiente. En la práctica, esto se traduce en nueve controles agrupados en tres categorías: aplicar políticas en tiempo real (control de acceso, enmascaramiento, identidad del agente), verlo y demostrarlo (clasificación de datos, registros de auditoría, trazabilidad de procesos), y unificar y endurecer (gestión centralizada de políticas, cifrado, aplicación consistente en entornos cloud, locales o aislados).
El objetivo no es detener a los agentes, sino definir hasta dónde pueden llegar, qué pueden tocar, qué requiere aprobación humana y cómo reconstruir lo que pasó si algo sale mal. Esta arquitectura permite a las empresas adoptar agentes autónomos más rápido, porque los equipos de seguridad y riesgo confían en que el control está donde debe estar: en la fuente misma de los datos, no en promesas hechas por el modelo. Para sectores regulados, donde la soberanía de datos (el control sobre dónde y cómo se almacenan los datos) es obligatoria, este enfoque no es opcional: es la condición previa para poner agentes en producción.
