Decálogo de la AEPD sobre agentes de IA: cómo configurarlos en una empresa

Cinco preguntas, cinco capas del diseño

La AEPD propone cinco preguntas antes de delegar. Leídas con ojo de arquitecto, son una especificación: cada una es una capa del sistema.

Permisos: leer no es enviar

El punto 2 es el más fácil de trasladar a configuración: «Leer no es lo mismo que enviar, modificar o borrar». La lectura y la escritura son permisos distintos, concedidos por separado y casi siempre con alcances distintos. La AEPD pide el acceso mínimo, «una carpeta, un calendario», no toda la cuenta, y añade: «Si no puedes limitarlo, valora si la tarea justifica conectar todo el servicio».

Un ejemplo: una distribuidora quiere que un agente lea los pedidos de un buzón compartido y prepare respuestas. Se parte de permiso de lectura sobre ese buzón (no del de la dirección), escritura solo para crear borradores, nunca para enviar, y ninguna conexión con el calendario ni la contabilidad hasta que una tarea lo justifique.

• Una identidad por agente, distinta de la sesión de cualquier persona: los registros atribuyen cada acción y se revoca sin afectar a nadie más. Y el límite se fija en el servicio de destino, no en el texto de la instrucción.
• Revisión periódica y al ampliar. El decálogo la pide «de nuevo cuando el asistente o una aplicación incorporen funciones nuevas»: cada función nueva es una petición de permisos nueva.

Si el agente es un copiloto integrado en el correo y los documentos, la revisión empieza por lo que cada persona ya puede ver; lo detallamos en la lista de comprobación previa a activar Microsoft 365 Copilot.

El agente prepara y la persona aprueba

La nota de prensa resume el principio así: el agente prepara y la persona aprueba. El punto 6 lista las acciones que deben pedir confirmación previa: enviar, publicar, compartir, borrar, pagar, contratar o aceptar condiciones. En el diseño, esas siete acciones pasan siempre por una cola de aprobación; para el resto de herramientas con efecto hacia fuera se fija un nivel de riesgo que decide si también la necesitan.

El mismo punto pide leer de verdad lo que se aprueba, «destinatario, importe, fecha, adjunto», porque «un resumen puede ocultar lo esencial». La pantalla debe construirse con los campos reales de la acción (el destinatario que recibirá el correo, la cifra que se cargará, el fichero que se adjuntará), no con el texto que redacta el modelo: si la persona ve un resumen escrito por el sistema que puede haberse equivocado o haber sido engañado, la confirmación no controla nada.

Tampoco conviene ofrecer «aprobar todo». La AEPD pide no conceder autorizaciones permanentes («permitir siempre») salvo que sean realmente necesarias y se comprenda su alcance; su nota cita el caso de un usuario que encargó a su agente vender un objeto, eligió «permitir siempre» creyendo que seguiría pidiéndole autorización antes de aceptar ofertas, y el agente cerró el trato y facilitó su dirección al comprador. Una autorización persistente, si hace falta, lleva alcance acotado y caducidad.

Límites en el sistema, no en la instrucción

Dice el decálogo: «Los límites que escribas en la instrucción orientan al agente, pero no sustituyen a los permisos y las confirmaciones». Un tope de gasto escrito en el texto de partida es una indicación que el modelo puede ignorar o perder de vista. Un límite duro vive en el código de la herramienta:

• El conector de pagos rechaza cualquier importe por encima del máximo configurado, diga lo que diga el modelo.
• La herramienta de correo solo acepta destinatarios de una lista permitida y lo valida antes de enviar.
• El borrado no existe para el agente: solo puede mover a una carpeta de revisión.

El modelo decide qué intentar; la herramienta decide qué se ejecuta. Los filtros sobre el propio modelo, que tratamos en el artículo sobre guardrails y alineación, complementan esta capa, pero no la sustituyen.

Lo que el agente lee también puede dar órdenes

El punto 7 describe el riesgo: una web, un correo, un PDF o una invitación de calendario pueden contener instrucciones ocultas, incluso invisibles («texto blanco sobre fondo blanco»), para que el agente envíe datos, abra un enlace o apruebe algo. Y reconoce el límite de cualquier defensa: «Ninguna medida elimina por completo este riesgo; por eso la mejor protección es limitar lo que el agente puede hacer si consigue ser engañado».

El decálogo pide evitar combinar en una misma tarea contenido de desconocidos, acceso a información privada y capacidad de actuar en tu nombre. Es casi lo que Simon Willison describió como la «trifecta letal» de los agentes («The lethal trifecta for AI agents: private data, untrusted content, and external communication», 16 de junio de 2025). Quitar una de las tres patas la rompe; si no se puede, hay que frenar la acción:

• Separar al que lee del que actúa. Un agente procesa el contenido externo sin datos privados ni herramientas de salida y entrega al siguiente un resultado estructurado (campos, sin texto libre). Reduce la superficie, pero ese resultado también puede venir contaminado.
• Confirmación antes de cualquier acción hacia fuera.
• Salida de red limitada a una lista de destinos permitidos: enviar datos a un dominio desconocido falla por configuración.
• Sin seguir enlaces por iniciativa propia. Una URL puede llevar datos privados en sus parámetros; los enlaces del contenido leído no se abren sin aprobación.
• Parada ante señales de alarma. El decálogo recomienda detener y revisar la tarea si el agente pide una contraseña o un código, urge a aprobar algo, visita sitios inesperados o propone un enlace. Esas señales se pueden convertir en pausas automáticas.

Memoria y retención: borrar no significa lo mismo en todas partes

El punto 4 avisa de que la memoria construye poco a poco un perfil, y de algo que se pasa por alto al diseñar: «borrar un chat, borrar una memoria o eliminar una aplicación conectada no tienen el mismo efecto». Antes de producción hay que saber qué ocurre con cada dato en cada caso.

• Controles propios. La AEPD recomienda usar los controles de memoria, historial y privacidad del servicio y no confiar solo en pedírselo al asistente en la conversación.
• Copias ajenas. Lo que se guarda en los servicios de terceros que use el agente (una web de reservas, una tienda) queda fuera de la gestión del agente. Se inventarían para saber dónde puede haber una copia.
• Espacios separados para usos personal y profesional y conversaciones temporales para lo delicado. En una empresa, sin mezclar en una memoria datos de departamentos distintos.
• Entrenamiento y retención del proveedor. Se comprueba en el contrato y la configuración si los datos se usan para entrenar y cuánto se conservan. El decálogo advierte de que, si se permite, «podría ser difícil eliminarlos después».

Registro de lo hecho, freno y marcha atrás

El punto 1 pide poder comprobar «a qué ha accedido, cuándo y qué ha cambiado en cada tarea, y deshacer los cambios con los que no estés de acuerdo». Eso es un registro de auditoría con reversión: cada acción deja una entrada con la identidad, la herramienta, los datos afectados, el resultado y la hora, guardada fuera del alcance del agente. La operación inversa se diseña desde el principio: borradores en lugar de envíos, papelera en lugar de borrado, versiones en lugar de sobrescritura.

Del punto 10 salen tres requisitos más:

• Avisos de actividad en los servicios críticos, para que lo anómalo llegue a una persona sin esperar a una revisión del historial.
• Tareas programadas con duración limitada. El decálogo pide vigilar las que «siguen funcionando sin que estés presente»: limitar cuánto duran y qué pueden hacer sin preguntar, y eliminar las que sobran. Una tarea recurrente sin caducidad es una autorización permanente con otro nombre.
• Parada y revocación ensayadas. «Averigua cómo detener el agente y cómo retirarle los accesos antes de necesitarlo». Se preparan un interruptor accesible, la revocación de credenciales y la lista de aplicaciones donde comprobar qué se envió o se compró, y se prueban en un simulacro antes del primer incidente.

Cuentas, conectores y navegador

El punto 9 parte de que la cuenta del agente da acceso a todo lo que tiene conectado. Pide contraseña única y segura, verificación en dos pasos (o llave de acceso, passkey) y avisos de inicio de sesión. En una empresa eso se aplica a las cuentas de quien administra el agente; la credencial del propio agente, además, se guarda en un gestor de secretos y se rota.

También pide instalar solo complementos y conectores de origen conocido y comprobar qué permisos piden. Un conector es código de terceros con acceso a los datos del agente, así que entra en el inventario de proveedores y se revisa antes de activarlo. Vale para los servidores MCP: en MCP para empresas: conectar agentes con control explicamos cómo tratarlos como una API privilegiada.

Si el agente controla un navegador, «podría acceder a las páginas en las que hayas iniciado sesión». La respuesta técnica es un perfil o una sesión dedicados al agente, sin las sesiones de ninguna persona, y borrar después cookies y accesos innecesarios.

Datos de terceros y quién escribe

El punto 8 recuerda que el correo, la agenda o los chats contienen información de personas que no han decidido relacionarse con esa IA. En diseño, eso es limitar el alcance de las fuentes (el buzón de pedidos, no el de recursos humanos) y no usar el agente para reunir o deducir información delicada de otras personas.

La otra mitad se refiere a los mensajes: si el agente se comunica en nombre de alguien, el decálogo pide evitar que los destinatarios se confundan sobre quién actúa, la persona o el asistente. Es una decisión de producto: un aviso visible de que lo escribe un sistema automatizado y una vía para hablar con una persona. La guía práctica de agentes y LLM paso a paso trata la transparencia técnica del artículo 50 del Reglamento de IA en uno de sus pasos.

Lista de comprobación antes de pasar un agente a producción

Un punto por apartado del decálogo, como verificación concreta:

1. Proveedor (punto 1). Consta quién presta el servicio, adónde viaja cada dato y qué configuración hay sobre entrenamiento.
2. Permisos (punto 2). Lectura y escritura separadas, alcance mínimo, credencial propia y fecha de la próxima revisión de conexiones.
3. Datos delicados (punto 3). Las fuentes sensibles están excluidas o, si se conectan, el agente tiene sobre ellas acceso y autonomía limitados; ni contraseñas ni números de tarjeta pasan por la conversación.
4. Memoria (punto 4). Se sabe qué se guarda, dónde y cuánto tiempo; se puede borrar desde una pantalla de gestión; los terceros con copia están inventariados.
5. Límites (punto 5). Importes máximos, destinatarios permitidos y acciones prohibidas viven en el código de las herramientas, y se ha probado que no se saltan.
6. Confirmaciones (punto 6). Enviar, publicar, compartir, borrar, pagar, contratar y aceptar condiciones piden aprobación con los campos reales. No existe «aprobar todo».
7. Contenido externo (punto 7). Quien lee contenido ajeno no tiene datos privados ni acciones de salida; hay destinos de red permitidos y pausa ante petición de credenciales.
8. Terceros (punto 8). Se ha revisado quién aparece en las fuentes y los mensajes indican que los envía un sistema automatizado.
9. Cuentas (punto 9). Verificación en dos pasos en las cuentas implicadas, conectores de origen conocido con permisos revisados y navegador del agente en perfil separado.
10. Supervisión (punto 10). Registro de acciones con vía para deshacer, avisos en servicios críticos, tareas con caducidad y un procedimiento de parada ensayado.

Las casillas sin marcar son decisiones pendientes antes del lanzamiento. La AEPD dice a sus lectores que, si un servicio no ofrece estos controles, lo tengan en cuenta al decidir qué le confían; quien implanta el agente es quien está en condiciones de ofrecérselos.

Preguntas frecuentes

¿Qué diferencia hay entre un límite en la instrucción y uno duro?

El primero es un texto que el modelo puede no cumplir; el segundo lo aplica el código de la herramienta antes de ejecutar nada. Un tope de importe escrito en la instrucción orienta; el mismo tope validado en el conector de pagos impide el cargo aunque el modelo se equivoque o lo hayan engañado.

¿Se puede eliminar el riesgo de instrucciones ocultas en correos y webs?

No, y la AEPD lo reconoce. Se reduce lo que el agente consigue si lo engañan: permisos mínimos, separar a quien lee de quien actúa, limitar la salida de red y confirmar antes de actuar hacia fuera.

¿Qué debe poder hacer una persona con la memoria de un agente?

Ver qué recuerda, borrarlo desde una pantalla de gestión y saber qué efecto tiene cada borrado, porque borrar un chat, borrar una memoria o eliminar una aplicación conectada no tienen el mismo efecto.

Última verificación: 5 de noviembre de 2026.