Cuando hablamos con equipos de datos enterprise sobre por qué su piloto de IA agéntica no pasa a producción, la respuesta nunca es lo que esperaba: «no podemos demostrar quién pidió qué, ni en qué momento, ni si tenía permiso para hacerlo». Y sin esa demostración, ni Risk ni Cumplimiento firman.
El problema no es nuevo · solo aparece tarde
Llevamos quince años construyendo data lakes. Funcionan. El acceso se modela a nivel de tabla, partición, columna o fila — fino, pero estático: definido cuando el dato entra al lake, raramente revisado, casi nunca auditable a posteriori con la granularidad que pide DORA o el AI Act.
Para un dashboard ese modelo basta. Para un agente que negocia, decide y ejecuta en nombre de un humano, no. El agente quiere preguntar cosas que no estaban contempladas cuando se diseñó el schema. Y cada pregunta es un evento de acceso que el regulador puede auditar.
Tres patrones que se quedan cortos
- RBAC clásico. Asigna roles a personas, no a sesiones. Funciona para empleados; falla cuando el actor es un agente con contexto efímero.
- ABAC con políticas en YAML. Mejor, pero el log que produce es insuficiente: dice qué política se aplicó, no por qué se denegó esta concreta consulta concreta de este agente concreto.
- Service mesh + JWT scopes. Bloquea bien, pero el scope vive en el token — fuera del dato. El dato no sabe quién lo pidió.
La auditoría regulatoria pregunta cosas como: «Mostrad todos los accesos que un agente X hizo al dataset Y entre marzo y abril, con el scope efectivo y el motivo de la decisión». Si esa pregunta requiere reconstruir logs de cinco sistemas, ya habéis perdido.
Por qué la decisión de acceso debe vivir cerca del dato
Llamamos control atómico a la propiedad de que cada operación de lectura sobre el dato dispare una decisión de acceso explícita, contextual y registrada — todo en el mismo punto. No en el agente, no en el mesh, no en una API gateway: en la celda donde vive el dato.
// ejemplo de payload de decisión atómica
{
"cell_id": "ventas.cliente_segmento.eu-west-1",
"actor": "agent:bedrock/sales-copilot/sess-9a2",
"scope": ["read:segment", "read:revenue:aggregated"],
"decision": "allow",
"policy_id": "P-EU-AGG-2026",
"evaluated_at": "2026-04-22T08:14:33.412Z"
}
Cada decisión tiene cell_id (qué dato), actor (qué agente, qué sesión), scope (qué tipo de lectura), policy_id (qué política se aplicó) y timestamp con precisión de milisegundo. Reconstruir cualquier pregunta regulatoria es un filtro sobre este log — no una arqueología.
Latencia
La objeción esperable: «¿qué pasa con la latencia si cada lectura dispara una evaluación?». Buena pregunta. La respuesta corta: la decisión se evalúa en la celda, no en un servicio externo. Latencia adicional típica: 0.4–1.2ms p95 sobre lecturas que ya están en el rango de 8–40ms p95. El usuario no lo nota; el auditor sí.
Qué cambia para tu equipo
Tres cosas, concretas:
- Dejas de mantener mappings RBAC en cinco sitios. La política vive en un único punto y se aplica donde el dato vive.
- El log de auditoría es la fuente, no una reconstrucción. Cuando llega una DSR (Data Subject Request) o una auditoría DORA, respondes en horas, no semanas.
- Los agentes pueden pedir más cosas — porque ahora la denegación también está tipificada y registrada. Pruebas más, sin perder control.
Si quieres ver cómo aplicamos esto en una organización con cinco data lakes preexistentes y zero downtime, el whitepaper técnico lo cubre con el detalle que aquí no cabe.