# IA y protección de datos: cómo aplica el RGPD a los agentes

> IA y protección de datos con RGPD: minimización, base jurídica, encargado del tratamiento, datos en prompts y trazas, y derechos de los interesados.

- Canonical: https://arkatai.com/ia-y-proteccion-de-datos/
- Site: Arkatai (https://arkatai.com) — agentic operations as a service
- Language: es
- Published: 2026-07-19

---


Un agente de IA que trabaja en tu operación es, casi siempre, un sistema que trata datos personales: lee correos de clientes, consulta fichas del ERP, mete información en prompts y la deja registrada en trazas. En cuanto hay un nombre, un correo o un número de cliente de por medio, aplica el [RGPD](https://eur-lex.europa.eu/eli/reg/2016/679/oj/spa), con los mismos principios que ya conoces. La novedad no son las reglas. Es que un agente las toca en más sitios y más rápido que un empleado, y por eso conviene aplicarlas por diseño.

Aviso de método: hablo de principios generales y verificables, no de artículos numerados. Lo que sigue es cómo traduzco cada principio del RGPD a decisiones concretas cuando pongo un agente a operar. Para el texto exacto y el encaje sectorial, tu asesoría; para el diseño del sistema, esto.

## Minimización: que el agente vea solo lo que necesita

El principio de minimización dice que tratas los datos adecuados y limitados a lo necesario para tu finalidad. En un agente, esto deja de ser una declaración de intenciones y se convierte en una decisión de permisos. Un agente que concilia facturas no necesita ver nóminas, y uno que responde consultas de pedidos no necesita el histórico médico de nadie. Cada dato al que el agente accede sin necesitarlo es superficie de riesgo que no aporta función.

La minimización también aplica al prompt. Meter la ficha completa de un cliente en el contexto cuando el agente solo necesita su número de pedido es un exceso silencioso que se repite en cada ejecución. Diseñar qué información entra en el prompt, y recortarla a lo imprescindible, es parte del trabajo. Esto se implementa con el mismo mecanismo de menor privilegio que describo en [permisos y controles de agentes](/permisos-y-controles-de-agentes/), de modo que el agente accede a lo justo, ni un campo más.

## Base jurídica: por qué tratas cada dato

Antes de que un agente trate un dato personal tiene que haber una base jurídica que lo ampare, igual que con cualquier tratamiento. No cambia porque lo haga una IA. Lo que sí exige la IA es cuidado con la finalidad: si recogiste datos de clientes para gestionar sus pedidos, usarlos para entrenar o afinar un modelo es una finalidad distinta que necesita su propia justificación. Reutilizar datos "porque ya los tengo" es uno de los errores más fáciles de cometer y más caros de explicar después.

La regla práctica que aplico: para cada flujo del agente, sé capaz de decir qué datos personales toca, con qué finalidad y bajo qué base. Si no puedes responder eso de un proceso, no está listo para producción, con o sin IA.

## Encargado del tratamiento: cuando el proveedor opera

Aquí hay una figura que muchos comités pasan por alto. Cuando un proveedor externo opera el agente sobre tus datos, ese proveedor actúa como encargado del tratamiento: trata datos personales por cuenta tuya, que sigues siendo el responsable. Eso exige un contrato que fije qué puede hacer con los datos, con qué medidas de seguridad, con qué subencargados y qué pasa al terminar la relación.

Este punto conecta con el modelo comercial de forma directa. En una operación gestionada, el reparto de papeles —tú responsable, el proveedor encargado— debe estar escrito, igual que el destino de los datos al finalizar el contrato. Una salida limpia no es solo recuperar tu arquitectura operativa: es también que tus datos personales y sus trazas vuelvan a ti o se supriman según lo pactado. Esa separación de propiedad es la que defiendo en [gobernanza de agentes](/gobernanza-de-agentes/) y la que hace que el cumplimiento no dependa de la buena voluntad de un tercero.

## Datos en prompts y trazas: el punto ciego

El sitio donde más veo aparecer datos personales sin que nadie lo haya decidido es en dos capas invisibles: los prompts y las trazas. Un prompt puede arrastrar datos personales hacia el modelo, y una traza los guarda para poder auditar. Ambos son necesarios —el prompt para que el agente trabaje, la traza para gobernar el sistema—, y ambos son datos personales que hay que proteger.

Las decisiones concretas que tomo: minimizar qué datos entran en el prompt, controlar quién puede leer las trazas, cifrarlas, y fijar cuánto tiempo se conservan. Una traza es una obligación de gobierno y a la vez un riesgo de privacidad. Se resuelve tratándola con el mismo cuidado que cualquier otro almacén de datos personales, no como un log técnico que nadie mira. Cómo se usa esa traza para auditar decisiones está en [auditar decisiones de agentes](/auditar-decisiones-de-agentes/). Aquí lo que importa es que también hay que protegerla.

## Derechos de los interesados: acceso, rectificación, supresión

Las personas cuyos datos trata tu agente conservan sus derechos: acceder a lo que tienes, rectificar lo incorrecto, pedir la supresión, oponerse a ciertos tratamientos. Un sistema con agentes tiene que poder atender eso, y aquí la trazabilidad juega a tu favor. Si registras qué datos usó el agente y para qué, responder a una solicitud de acceso es una consulta, no una excavación.

Hay un derecho que merece atención propia, el que ampara a una persona frente a decisiones basadas solo en tratamiento automatizado cuando le afectan de forma significativa. Es una de las razones por las que insisto en el escalado a un humano en las decisiones que cambian el resultado para una persona. El [humano en el circuito](/gobernanza-de-agentes/) no es solo buena práctica de riesgo, sino que en algunos casos es lo que mantiene el sistema del lado correcto del RGPD.

## Cómo encaja con el resto

La protección de datos no vive sola. El [AI Act y los agentes de IA](/ai-act-y-agentes-de-ia/) añaden obligaciones que se solapan con estas. El conjunto de riesgos operativos está ordenado en [riesgos de la IA en las empresas](/riesgos-de-la-ia-en-las-empresas/). Y el uso no controlado por los empleados —el [shadow AI](/shadow-ai-en-la-empresa/)— es la vía más rápida para que datos personales acaben en un servicio que nadie ha evaluado. Antes de arrancar, esto forma parte de lo que reviso en [preparar tu empresa para agentes](/preparar-tu-empresa-para-agentes/), y el punto de entrada general está en [agentes de IA para empresas](/agentes-de-ia-para-empresas/). Para aterrizar estos principios en tratamientos concretos, las [guías de la AEPD](https://www.aepd.es/guias-y-herramientas/guias) son la referencia práctica en España.

## Preguntas frecuentes

### ¿Puedo usar datos de clientes en un agente de IA sin incumplir el RGPD?

Sí, si hay una base jurídica que ampare ese tratamiento y una finalidad definida. La trampa habitual es reutilizar datos recogidos para una cosa —gestionar pedidos— en otra distinta —entrenar o afinar un modelo— sin justificación propia. Por cada flujo del agente deberías poder decir qué datos personales toca, para qué y bajo qué base.

### ¿El proveedor que opera mis agentes es responsable de mis datos?

No como responsable. Actúa como encargado del tratamiento, tratando datos por cuenta tuya, que sigues siendo el responsable. Eso exige un contrato que fije qué puede hacer, con qué seguridad, con qué subencargados y qué ocurre con los datos al terminar. Una salida limpia incluye la devolución o supresión de tus datos y sus trazas.

### ¿Qué pasa con los datos personales que entran en los prompts?

Son datos personales como cualquier otro y hay que tratarlos igual: minimizar cuáles entran, controlar a dónde van y protegerlos. El error frecuente es meter la ficha completa de una persona cuando el agente solo necesita un dato. Diseña qué información entra en el contexto y recórtala a lo imprescindible en cada ejecución.

### ¿Un cliente puede oponerse a que una IA decida sobre él?

En decisiones basadas solo en tratamiento automatizado que le afectan de forma significativa, existe una protección específica a su favor. Por eso el escalado a una persona en las decisiones que cambian el resultado no es solo buena gestión de riesgo, sino que en ciertos casos es lo que mantiene el sistema dentro de la norma. Diseña ese punto de intervención humana desde el principio.