Blog

Seguridad y RGPD: checklist antes de dar datos a un agente de IA

Pablo Cabrera

Fundador de OperandIA

12 de octubre de 202611 min de lectura

Conectar un agente de IA a tu correo, tu CRM o tu carpeta de facturas se hace en una tarde. Pensar qué puede ver ese agente, qué puede hacer con ello y quién responde si algo sale mal se suele dejar para después, si es que se llega a pensar. La Agencia Española de Protección de Datos (AEPD) notificó en septiembre la primera brecha de datos personales causada por un ataque ejecutado a través de un agente de IA, y en febrero había publicado la primera guía española específica sobre el tema. Este artículo traduce ambas cosas en un checklist que puedes repasar antes de dar acceso a cualquier agente a los datos de tu empresa.

Qué cambia cuando quien accede a tus datos es un agente, no un chat

Cuando escribes en un chat de IA, tú decides cada paso: preguntas, lees la respuesta, decides si sigues. Un agente es distinto: una vez le das una tarea y acceso a unas herramientas, encadena pasos por su cuenta —abre un archivo, consulta otro, escribe en un tercero— sin que nadie revise cada movimiento en tiempo real. Esa autonomía es exactamente lo que lo hace útil (por fin alguien, o algo, hace el trabajo mecánico sin que se lo tengas que ir indicando línea a línea) y exactamente lo que cambia el riesgo.

La AEPD hizo pública en septiembre la primera notificación de una brecha de datos personales derivada de un ataque ejecutado mediante un agente de IA: según la propia agencia, el agente localizó vulnerabilidades en archivos genéricos de la organización, consiguió iniciar sesión y, una vez dentro, fue encadenando fallos adicionales hasta poder modificar datos personales y acceder a facturas, sin que un operador humano dirigiera cada paso del ataque. La AEPD es prudente con el caso: la información procede solo de la organización afectada, no identifica ni la empresa ni el modelo de lenguaje implicado, y aclara que un solo incidente no permite hablar de tendencia estadística. Pero sí ilustra algo que cualquier pyme que esté conectando agentes a sus sistemas debería anotar: un agente con permisos amplios no solo comete errores por su cuenta, también puede ser el punto de entrada de un ataque que avanza solo, sin que nadie lo note hasta que ya ha pasado.

Qué dice la guía de la AEPD sobre IA agéntica

En febrero de 2026, la AEPD publicó sus primeras orientaciones específicas sobre IA agéntica desde la perspectiva de protección de datos, un documento de 81 páginas pensado para que responsables y encargados del tratamiento entiendan qué cambia cuando una parte de un proceso con datos personales se apoya en agentes. No es un manual de cumplimiento genérico: identifica riesgos propios de la arquitectura de estos sistemas, no solo del uso que se les da.

Los riesgos que señala la guía, resumidos en lenguaje de negocio:

Opacidad: no siempre es fácil saber qué ha hecho el agente con los datos ni por qué ha tomado una decisión concreta.
Minimización difícil de garantizar: un agente conectado a una herramienta tiende a ver más información de la que la tarea concreta necesita, salvo que alguien limite ese acceso expresamente.
Riesgos de seguridad al interactuar con entornos externos: la guía menciona explícitamente la inyección de instrucciones maliciosas (prompt injection, instrucciones escondidas en un documento, un correo o una web que el agente consulta y que intentan manipular lo que hace) y las filtraciones parciales que, sumadas, permiten reconstruir información confidencial.
Dificultad para atender los derechos de los interesados: si un agente ha tratado datos de una persona de forma distribuida en varios pasos, reconstruir qué se hizo con ellos para responder a una solicitud de acceso o de supresión es más complicado que en un proceso tradicional.

Y una idea que conviene subrayar porque cambia la conversación con cualquier proveedor: según la guía, quien usa el sistema de IA agéntica es responsable del tratamiento de datos que ese sistema realiza. No se delega la responsabilidad en el fabricante del modelo por el hecho de usar su tecnología.

Entre las medidas que propone la guía, las que de verdad se pueden aplicar en una pyme sin equipo técnico propio son: política de acceso basada en la necesidad de conocer (el agente solo ve lo que su tarea requiere, nunca el sistema entero "por si acaso"), separar datos e instrucciones dentro del razonamiento del agente para reducir el riesgo de que un documento manipulado le dé órdenes, controlar el grado de autonomía de cada proceso en el que interviene (no todos necesitan el mismo nivel de libertad para actuar) y mantener registros de responsabilidades, decisiones y eventos, de forma que si algo falla se pueda reconstruir qué pasó.

Un ejemplo con datos sensibles por todas partes: la notaría

Pensemos en una notaría de tamaño medio, 8 empleados, en Cuenca. Por su actividad, maneja a diario datos de identidad, patrimoniales y bancarios de clientes que firman una escritura: compraventas, herencias, poderes. Cuando se planteó usar un agente de IA para resumir expedientes y preparar borradores de escrituras a partir de la documentación aportada, la tentación inicial fue conectarlo directamente a toda la carpeta compartida de expedientes del despacho, la más cómoda de configurar en diez minutos.

Antes de hacerlo, revisaron qué necesitaba realmente la tarea: el agente no necesita ver expedientes cerrados de hace cinco años para resumir el expediente abierto de esta semana, ni necesita acceso de escritura sobre documentos ya firmados. Acotaron el acceso a la carpeta del expediente activo, en modo solo lectura, y dejaron que el agente generara un borrador que siempre revisa un oficial antes de pasar al notario. El resultado: el tiempo de preparación de un borrador de escritura sencilla bajó de una hora y media a unos 25 minutos, sin abrir una puerta a todo el histórico de clientes del despacho por una tarea que solo necesitaba uno de los expedientes.

Un ejemplo con categoría especial de datos: la clínica oftalmológica

Segundo caso: una clínica oftalmológica en Lleida, 18 empleados, que quería un agente para gestionar la agenda de citas y enviar recordatorios a pacientes antes de cada revisión. Aquí el matiz legal es mayor: los datos de salud son una categoría especial de datos personales según el RGPD, con un nivel de protección más exigente que un dato de contacto o una dirección.

Siguiendo el criterio de la propia guía de la AEPD de revisar las obligaciones del tratamiento cuando se incorpora un agente, la clínica consultó con su delegado de protección de datos (DPO) antes de activar el agente, no después. La conclusión: dado que se trataba de datos de salud tratados de forma automatizada para generar comunicaciones a pacientes, convenía documentar una evaluación de impacto (EIPD) específica para ese uso, aunque fuera breve, y limitar el acceso del agente estrictamente a los campos de fecha de cita y datos de contacto, sin acceso al historial clínico. El agente nunca llegó a "ver" el motivo de la consulta ni el diagnóstico: no lo necesitaba para mandar un recordatorio. Las ausencias a citas bajaron de forma notable al automatizar el recordatorio, y la clínica evitó la pregunta incómoda de por qué un sistema de recordatorios tenía acceso a diagnósticos que nunca iba a usar.

El checklist: 10 puntos antes de dar acceso a un agente

Esto es lo que, con los dos casos anteriores y la guía de la AEPD como referencia, recomendamos repasar antes de conectar un agente de IA a los datos de tu empresa:

Haz un inventario de qué puede ver el agente, no solo de qué tarea va a hacer. La pregunta no es "¿qué va a hacer?", es "¿a qué tiene acceso para hacerlo?".
Da acceso por necesidad de conocer, nunca acceso total "por si acaso". Si la tarea es gestionar citas, el agente no necesita ver el historial clínico completo.
Separa datos e instrucciones. Ten en cuenta que un documento, un correo o una web que el agente consulte puede contener instrucciones escondidas (prompt injection) diseñadas para manipularlo.
Elige el modo de permisos más estricto que la tarea permita. Si la herramienta ofrece modos manual/automático o acceso de solo lectura/lectura-escritura, empieza por el más restrictivo y amplía solo si hace falta.
No compartas una credencial maestra entre varias personas. Si varios miembros del equipo usan el mismo acceso, todos tienen el alcance de esa credencial, aunque solo uno la necesite entera.
Valora si la tarea requiere una evaluación de impacto (EIPD): datos de categoría especial (salud, origen étnico, afiliación sindical...), decisiones automatizadas con efecto significativo sobre personas o tratamiento a gran escala son las señales que la activan.
Involucra a tu DPO (o a quien haga ese papel) desde el diseño, no cuando el agente ya está conectado y funcionando.
Guarda un registro de qué decidió el agente y cuándo. Si algo falla, necesitas poder reconstruir la secuencia de eventos, no solo el resultado final.
Define cómo revocar el acceso en minutos, no en días, si detectas algo raro. Saber dónde se apaga el interruptor antes de necesitarlo es la diferencia entre un incidente contenido y uno que se extiende.
Empieza con un piloto acotado: un departamento, un proceso, una carpeta concreta. Conectar todo de golpe multiplica lo que hay que vigilar antes de haber aprendido nada del primer caso.

Qué controles ofrece ya cada proveedor (y qué no resuelve por ti)

El ecosistema ha avanzado en este punto en 2026, aunque de forma desigual entre proveedores:

Proveedor	Qué controla el administrador	Qué sigue dependiendo de ti
Claude (Anthropic)	Autorización centralizada de conectores por grupos del proveedor de identidad (Okta), revocación vía baja del usuario, acortar la vida de los tokens de acceso, desactivar herramientas interactivas concretas. En Cowork, tres modos de permiso (manual/automático/sin aprobación) y acceso por carpeta (solo lectura, lectura-escritura sin borrar, lectura-escritura total).	Si varios usuarios comparten una misma credencial de conector, todos heredan su alcance. Los conectores MCP locales se ejecutan con los permisos del propio sistema operativo del usuario, fuera del aislamiento de la máquina virtual de Cowork.
ChatGPT (OpenAI)	Consola de administración con roles personalizados, activar o desactivar cada app/conector por rol, SSO, SCIM, listas de IP permitidas y registros de auditoría. Los datos de la cuenta de empresa no se usan para entrenar modelos por defecto.	Las apps y conectores personalizados no están verificadas por OpenAI: son responsabilidad de quien las desarrolla o las conecta, úsalas solo si confías en su origen.
Gemini Enterprise (Google)	Interruptor a nivel de organización sobre si los agentes pueden acceder a datos de Workspace, con una lista de gestión que permite hacer excepciones agente por agente. Respeta los permisos ya existentes en Workspace o Microsoft 365.	El valor por defecto es permisivo (los agentes pueden pedir acceso a cualquier dato de Workspace salvo que lo restrinjas). Revisa ese ajuste global antes de activar cualquier agente nuevo.
Mistral (Agents API)	Acceso a herramientas y datos empresariales a través de conectores MCP, con la opción de despliegue privado o en infraestructura propia para quien necesita mantener los datos dentro de casa.	Las certificaciones concretas y las políticas de retención de datos de la Agents API no están tan documentadas públicamente como en los otros tres proveedores; pide esa documentación por escrito antes de conectar datos sensibles.

El matiz importante, válido para los cuatro: un interruptor de administrador controla la configuración del acceso, no decide por sí solo qué información queda expuesta dentro de una conversación o una tarea concreta. Eso depende de cómo se la has planteado al agente y de qué le has dado acceso para resolverla.

Lo que ningún proveedor resuelve por ti

Ninguna de estas herramientas sustituye el criterio interno. Tres límites que conviene tener claros:

Un control de acceso bien configurado reduce el daño, no lo elimina. Si el agente tiene acceso de lectura a una carpeta con datos personales, un fallo de seguridad en esa conexión sigue exponiendo lo que hay en esa carpeta, aunque sea menos que si tuviera acceso a todo el sistema.
La responsabilidad del tratamiento no se transfiere al proveedor del modelo. Como señala la guía de la AEPD, quien decide usar el agente responde de lo que ese agente haga con los datos, use Claude, ChatGPT, Gemini o Mistral.
Un solo incidente no es una tendencia, pero tampoco una anécdota a ignorar. La propia AEPD evita generalizar a partir del caso de septiembre, y hace bien. Pero la pregunta que debería hacerse cualquier pyme no es "¿cuántos casos como este ha habido?", es "¿qué pasaría en mi empresa si pasara uno?".

Conclusión

Dar acceso a un agente de IA a los datos de tu empresa no es un trámite técnico de cinco minutos: es una decisión sobre quién puede ver qué, con qué supervisión y qué pasa si algo falla. El primer paso accionable para hoy: coge el último agente o automatización de IA que hayáis conectado a algún sistema de la empresa y repasa el checklist de este artículo con él. Si no sabes responder a la mitad de los puntos, todavía estás a tiempo de ajustar los accesos antes de que haga falta.

Si quieres revisar con calma los accesos y riesgos de IA en tu empresa antes de que se conviertan en un problema, en OperandIA hacemos un diagnóstico de IA de una semana, sin compromiso: operandia.es/diagnostico-ia.

Fuentes

← Volver al blog