La AEPD ya escribió sobre agentes como el tuyo
La AEPD ya publicó orientaciones sobre IA agéntica. Si tu sistema puede actuar por su cuenta, esas preguntas de protección de datos, vulnerabilidades y medidas deberían entrar en la arquitectura antes de ponerlo a funcionar con clientes.
Por Reynier RiveroIngeniero de software
A las 09:12, Marta recibe en WhatsApp una pregunta: «¿Está pagada la factura 1842?». Su agente consulta el sistema de gestión de clientes (CRM), comprueba el estado en el sistema de planificación de recursos (ERP), redacta la respuesta y la envía; para hacerlo, también puede haber pasado por un modelo de lenguaje, una memoria de conversación y una herramienta de observabilidad.
Es una escena hipotética compuesta, no un caso real. La consecuencia que interesa aquí aparece al dibujar el recorrido: el agente puede haber tratado más información de la necesaria para confirmar una factura, y cada componente puede conservar una copia distinta.
El 18 de febrero de 2026, la Agencia Española de Protección de Datos (AEPD) publicó orientaciones sobre IA agéntica.
Qué entiende la AEPD por IA agéntica
En estas orientaciones, la AEPD define la IA agéntica como «sistemas de IA capaces no solo de responder a preguntas, sino de interactuar de forma autónoma para conseguir los objetivos».
Con ese marco, las orientaciones abordan la descripción del sistema, la protección de datos, las vulnerabilidades, las amenazas específicas y las posibles medidas para responsables y encargados.
Qué cambia al conectar un agente a tus sistemas
Si mañana revisas una integración con este marco, el documento que conviene tener no es solo el prompt del sistema: es un mapa del recorrido de cada dato, de lo que el agente puede hacer y de por qué.
Para la seguridad, OWASP Top 10 for LLM Applications 2026 es una guía comunitaria, pero sus fuentes muestran fechas distintas: la página del recurso muestra el 3 de agosto de 2026, mientras que el README canónico lo sitúa el 4 de agosto de 2026. La discrepancia impide presentar una fecha única. Sirve para ordenar riesgos de aplicaciones basadas en grandes modelos de lenguaje; no sustituye el análisis de tu arquitectura.
Sus entradas sobre divulgación de información sensible (LLM02:2026) y agencia excesiva (LLM03:2026) ayudan a separar dos preguntas: ¿qué datos salen del perímetro y qué acciones, permisos o autonomía tiene el sistema? El repositorio canónico desarrolla estas entradas.
Con esas dos preguntas, el mapa deja de ser una lista de conexiones: muestra los destinos del dato y las acciones posibles. Esa revisión guía cómo conectar tus sistemas cuando automatizas un proceso.
En la conversación de Marta, ese mapa lleva a una primera regla de minimización de datos: el agente debería recibir solo lo necesario para identificar la factura, comprobar su estado y responder.
No necesita por defecto todo el historial del cliente; la necesidad real depende de la finalidad y del tratamiento concreto, como recuerda la orientación de la AEPD.
Conectar todo suele ser más rápido que decidir qué conectar; también deja una arquitectura más difícil de explicar.
El dato no termina en el CRM
En esa misma escena, la base puede estar cifrada y la autenticación puede funcionar correctamente. RLS (seguridad por fila) puede estar activo, con los permisos ajustados y las copias configuradas.
Nada de eso impide que el agente envíe datos al modelo o guarde la conversación en una herramienta de observabilidad (para registros y trazas). También puede crear embeddings (vectores para búsqueda semántica) y registrar la instrucción que recibe el modelo.
También puede entregar una copia a una integración externa. El dato protegido en la base puede circular así por más destinos de los que alguien había dibujado.
La seguridad de la base no dibuja por sí sola el recorrido del dato.
Antes de conectar otra herramienta, sigue el dato hasta cada destino y pregúntate:
¿Este dato necesita llegar hasta la IA?
Si un dato no es necesario, elimínalo, enmascáralo o sustitúyelo por un identificador temporal. El agente puede trabajar con CLIENTE_8472 mientras una capa controlada de la aplicación conserva la identidad; el modelo no necesita conocerla. Esa lógica también permite revisar qué sabe tu agente sobre tus clientes.
El mapa mínimo de una integración
- documenta qué datos puede ver cada herramienta del agente, y por qué;
- enmascara o tokeniza lo que no hace falta antes de que llegue al modelo;
- limita cada herramienta a las operaciones necesarias, no a las disponibles;
- exige aprobación humana explícita para las acciones que tienen consecuencia real;
- registra qué proveedor externo recibió cada tipo de dato;
- prueba la inyección de instrucciones (prompt injection) antes de producción, no después de un incidente.
Estos controles no suelen aparecer en una demo; aparecen cuando se dibuja el flujo completo del dato.
La prueba que falta en la demo
Si no puedes explicar hoy qué ve exactamente tu agente y por qué lo necesita, todavía no tienes una arquitectura lista para producción.
La respuesta no se resuelve con una política de privacidad aislada: exige revisar arquitectura, permisos, memoria, proveedores y controles de seguridad.
Si al dibujar ese recorrido aparecen permisos que nadie sabe justificar, el siguiente paso no es añadir otra integración: es revisar la arquitectura. Prontavel ayuda a diseñar agentes y chatbots con ese mapa desde el primer día, junto con el equipo que tendrá que operarlos.
El servicio del que habla este artículo: Agentes de IA y chatbots que conocen tu empresa