El problema del que casi nadie habla con los agentes de IA empresariales
Su CFO pregunta a un agente de IA: “¿Cuánto gastamos en salarios el trimestre pasado?”
El agente llama a su API de nómina. La API devuelve el salario, el bonus y el número personal de cada empleado. El agente lo resume en un total claro.
Hasta aquí bien: el CFO puede ver esos datos.
Ahora un becario hace la misma pregunta al mismo agente. El agente llama a la misma API. La API devuelve la misma carga útil. El agente responde.
Este es el modo de fallo silencioso de casi todo despliegue de “agente de IA empresarial” en producción hoy.
Por qué el RBAC a nivel de endpoint no basta
La mayoría de las plataformas de integración —incluida la nuestra, hasta hace poco— aseguran el acceso a la API a nivel de endpoint. O puedes llamar a GET /payroll/employees o no. Ese modelo funcionó cuando los humanos construían UIs que filtraban en el cliente y los únicos llamadores eran servicios backend de confianza.
Los agentes rompen el modelo de dos formas:
- Los agentes son llamadores genéricos. No saben qué campos ocultar. Resumen todo lo que reciben.
- Los agentes actúan en nombre de muchos usuarios. Un mismo perfil de agente puede atender al CEO y al operario de almacén. El RBAC por endpoint no los distingue una vez autorizada la petición.
El resultado: los agentes se convierten en un problema de “confused deputy” a escala industrial. Un usuario sin acceso directo a la base de datos puede extraer cualquier dato que el agente alcance, con la pregunta adecuada.
Dónde el RBAC del sistema fuente se queda corto
La respuesta estándar es “que lo gestione el sistema fuente”. Pasar la identidad del usuario al sistema de nómina. Que filtre.
Funciona —cuando el sistema fuente lo soporta. En la práctica:
- Sistemas legacy suelen tener una sola cuenta de servicio con acceso total. No hay delegación por usuario.
- APIs SaaS de terceros a menudo carecen de permisos a nivel de fila. O tienes alcance de administrador o ninguno.
- APIs internas propias se construyeron antes de los agentes de IA. Nadie añadió
filter_by_user. - Las agregaciones fugan información. Incluso con filtrado por filas, sumas y medias a menudo se calculan sobre el conjunto completo.
Para un CISO, la superficie de exposición de datos queda definida por el conector más débil en la caja de herramientas del agente.
Defensa en profundidad: filtrado de respuestas basado en políticas
Hemos añadido una nueva capa a la Integration Platform de Copyl: DataAccessPolicy. Se sitúa entre la respuesta del sistema fuente y el agente, y aplica reglas declarativas a lo que se devuelve.
El modelo tiene tres ideas centrales:
1. Las políticas van ligadas a acciones de integración, no a agentes.
Un endpoint de nómina tiene una política. Todo agente —todo usuario— que lo toca pasa por el mismo evaluador. Un agente mal configurado no puede eludir la regla.
2. Las reglas coinciden con el contexto del sujeto, no con el endpoint.
El evaluador ve el sujeto completo: identidad, roles, claims, perfil de agente, empresa. Una regla puede decir “si el rol incluye CEO, permitir todas las filas” o “si el usuario es Employee, devolver solo filas donde employeeId coincida con su ID.”
3. Push-down cuando sea posible, post-filtro como respaldo.
Si la API fuente admite filtrado, la política reescribe la petición — ?employeeId=42 — para que los datos sensibles no salgan del sistema fuente. Sin push-down, se filtra en servidor antes de que el agente vea.
Este último punto importa para cumplimiento. Filtrar en tiempo de consulta es genuinamente más seguro que filtrar después. El post-filtro es defensa en profundidad, no sustituto de los controles en origen.
Qué significa para Sec/Cumplimiento
Tres propiedades lo hacen gobernable:
Auditable. Cada evaluación escribe un registro: qué política corrió, qué regla coincidió, filas entrantes/salientes, campos enmascarados. Puede responder “¿quién vio datos de nómina el martes y qué se filtró?” con SQL.
Versionado. Borrador → publicado → archivado. Cada cambio es una nueva versión. Diff, restauración y prueba de qué estaba activo en una fecha.
Probable antes de publicar. Dry-run: se evalúa y registra el filtro, la respuesta no se modifica. Validar contra tráfico real durante semanas. Publicar requiere prueba superada o anulación explícita.
Para sectores regulados (servicios financieros, salud, sector público bajo NIS2/DORA en Europa), “confiar en el agente” pasa a “demostrar el agente”.
Lo que no resuelve
Límites honestos:
- La delegación en el sistema fuente sigue siendo mejor cuando existe. Úsenla primero. El filtrado por política es para cuando no pueden.
- Las agregaciones son delicadas. Un filtro de filas con el salario de uno y un campo
total: 4.200.000sobre todos los empleados filtra información. Nuestro modelo detecta campos agregados y falla, los elimina o exige opt-in explícito — requiere análisis por endpoint. - Enmascarar campos no es cifrar. Los números personales hash siguen siendo PII. El enmascaramiento reduce el impacto; no elimina la obligación.
- Las políticas son tan buenas como sus reglas. Un emparejamiento de sujeto erróneo sobre- o sub-permite. Por eso exigimos pruebas y visibilidad de auditoría.
Qué implica en la práctica
Si ejecutan agentes de IA contra sistemas sin RBAC a nivel de fila —la mayoría de ERP legacy, nóminas, APIs propias anteriores a 2024— tienen una exposición que el control por endpoint no cierra.
La solución es estructural, no un truco de prompts. Decir en el system prompt “solo muestra los datos del usuario” aguanta hasta el próximo jailbreak. Aplicarlo en la capa de integración con política versionada y auditable es algo que un CISO puede aprobar.
Estamos desplegando DataAccessPolicy en los agentes del marketplace de Copyl, empezando por nómina, RR. HH. e integraciones financieras. Si operan en entornos regulados y quieren revisar dónde está la exposición en su stack, contacten.
Copyl es una plataforma para crear, desplegar y gobernar agentes de IA empresariales. Nuestra Integration Platform (CIP) conecta agentes con sistemas de negocio con cumplimiento de políticas de extremo a extremo, registro de auditoría y control de versiones.