Inicio/Blog/GDPR para agentes de IA
Ingeniería de Privacidad y Sistemas de IA

GDPR para agentes de IA: minimizar datos personales en memoria, herramientas y logs

Un agente no procesa datos personales solo cuando envía un prompt al modelo. El armado del contexto, la recuperación, la memoria persistente, las llamadas a herramientas, los reintentos, las trazas, las exportaciones y la telemetría del proveedor pueden crear copias y finalidades adicionales. Minimizar datos significa diseñar todo el sistema alrededor de lo que una tarea concreta necesita y después hacer que la retención y las solicitudes de derechos funcionen en todos los almacenes.

El GDPR no depende de la tecnología. Sus principios se aplican tanto si los datos personales están en un CRM, un índice vectorial, la transcripción de un agente, el resultado de una herramienta, una plataforma de observabilidad o el endpoint de un proveedor de modelos. El artículo 5 exige datos adecuados, pertinentes y limitados a lo necesario para la finalidad, además de limitar el tiempo durante el que pueden permanecer identificables. El resumen de 2026 del European Data Protection Board sobre protección desde el diseño y por defecto insiste en operacionalizar estos principios durante todo el ciclo del tratamiento. Para ingeniería, esto se convierte en un problema concreto de inventario y controles, no en un ejercicio de redacción de prompts.

Esta es una guía de ingeniería, no asesoramiento jurídico. El responsable debe determinar finalidades, base jurídica, transparencia, funciones y derechos aplicables a cada despliegue. Un framework de agentes o un ajuste de privacidad no puede decidir esas cuestiones por una organización.

Mapea todos los lugares por los que pueden circular los datos

Recorrido de una solicitud al agente y las copias que suelen escapar del almacenamiento principal de conversaciones
Origen e identidadEntrada, contexto de cuenta, archivos cargados, ID de sesión y finalidad.
Armado del contextoPrompt de sistema, registros recuperados, resúmenes, historial y schemas.
Modelo y herramientasSolicitud al proveedor, contenido generado, acciones API, reintentos y callbacks.
Persistencia y telemetríaMemoria, fragmentos vectoriales, trazas, logs, colas, backups y diagnósticos.

Dibuja flechas en ambos sentidos: las consultas y los resultados de herramientas devuelven datos personales al contexto, donde pueden copiarse otra vez.

Construye el mapa por finalidad y categoría de datos. Incluye buffers transitorios y datos derivados, no solo tablas de bases de datos. Un resumen de texto libre aún puede identificar a alguien; un embedding no es anónimo automáticamente; un ID seudónimo sigue siendo dato personal si puede vincularse con una persona. La opinión del EDPB sobre modelos de IA trata el anonimato como una evaluación caso por caso, incluso considerando si una persona puede identificarse o si los datos personales pueden extraerse mediante consultas.

Reduce el contexto antes de enviarlo al modelo

Empieza por el contrato de la tarea. Un agente de soporte que explica un retraso puede necesitar el estado del pedido y la fecha estimada, no el perfil completo, tickets sin relación, credenciales de pago o años de conversaciones. Recupera campos mediante una lista permitida, filtra por finalidad y autorización antes del ranking y devuelve al modelo el registro útil más pequeño. Cuando sea posible, deja que una herramienta de backend realice una operación acotada y devuelva un código de resultado, sin exponer los datos personales subyacentes.

Una ventana de contexto más amplia no autoriza a enviar más datos. Añade reglas explícitas de antigüedad máxima, origen, finalidad y sensibilidad a la recuperación. Redacta o transforma identificadores solo cuando la tarea siga funcionando y la transformación sea adecuada; aplicar hash a un correo estable no lo vuelve anónimo si los registros siguen siendo enlazables. No uses conversaciones personales para entrenar el modelo ni para crear memoria entre usuarios por defecto. Una finalidad distinta requiere su propia evaluación, transparencia y controles.

Haz que la memoria tenga alcance, sea inspeccionable y caduque

Separa el estado temporal de conversación, preferencias solicitadas por la persona, registros operativos y parámetros aprendidos por el modelo. Cada elemento tiene finalidad, acceso, retención y comportamiento de borrado diferentes. Mantén el estado de una tarea breve en almacenamiento con TTL; persiste una preferencia solo si existe una necesidad clara y una expectativa de usuario; conserva los registros empresariales obligatorios en el sistema de origen, en lugar de promoverlos silenciosamente a la memoria del agente.

Las entradas de memoria deberían incluir procedencia, finalidad, categoría, registro de origen, fecha de creación, caducidad y referencia de persona o tenant cuando corresponda. Aplica límites de usuario y tenant en el filtro de metadatos y en la autorización del almacenamiento. Prueba fugas entre sesiones, hechos obsoletos que reaparecen y solicitudes que borran la fila original pero dejan fragmentos vectoriales consultables.

La retención debe abarcar reintentos, trazas y proveedores

01 · RecopilarFinalidad y alcanceDocumenta categorías, responsable de la base jurídica, fuentes y campos necesarios.
02 · ProcesarMinimizar por defectoFiltra recuperación, redacta, limita herramientas y evita historial innecesario.
03 · PersistirClasificar y caducarDefine TTL por almacén, acceso, backups y comportamiento de borrado.
04 · ObservarRedactar telemetríaConserva eventos operativos útiles; excluye prompts y payloads por defecto.
05 · ConciliarDerechos y evidenciaLocaliza copias, ejecuta acciones acotadas, registra excepciones y verifica.

Registrar cada prompt es tentador en un prototipo y peligroso como configuración permanente. Prefiere eventos estructurados: tipo de tarea, versión del modelo, nombre de herramienta, latencia, estado y un token de correlación que no sea un identificador reutilizable de cuenta. Si se necesita capturar contenido para una finalidad de depuración concreta, limita acceso, reduce datos, fija una retención breve y documenta la excepción. Revisa las condiciones del proveedor, región, subencargados, retención y accesos de soporte para cada proveedor de modelos u observabilidad.

Convierte una solicitud de derechos en un flujo distribuido

Los derechos no se implementan con “borra la fila de conversación”. Una solicitud puede exigir buscar registros vinculados a la cuenta en sistemas de origen, memoria, índices vectoriales, cachés, event stores y proveedores. El acceso y la portabilidad también necesitan una forma significativa de reunir los registros pertinentes. La supresión tiene condiciones y excepciones legales; algunos registros pueden tener que conservarse y el responsable debe evaluar la solicitud, no prometer un borrado incondicional de todos los sistemas.

Diseña un flujo orquestado con una clave verificada, búsquedas acotadas, adaptadores por almacén, acciones idempotentes, una cola de revisión para coincidencias ambiguas e informe de finalización auditable. Propaga tombstones de borrado a consumidores asíncronos para evitar que un evento antiguo vuelva a crear un embedding suprimido. Para backups, define caducidad y controles de restauración: el proceso debe reaplicar las eliminaciones antes de volver a ofrecer los datos restaurados.

Separa decisiones automatizadas y escalamiento humano

No toda acción asistida por IA es una decisión del artículo 22. Esa disposición se refiere a decisiones basadas únicamente en tratamiento automatizado, incluida la elaboración de perfiles, con efectos jurídicos o similarmente significativos, sujetas a condiciones y garantías del GDPR. Aun así, los flujos con consecuencias merecen un inventario: qué recomienda el agente, qué puede ejecutar, si una persona realiza una revisión significativa y cómo la persona afectada puede impugnar o corregir el resultado.

Usa herramientas de mínimo privilegio, schemas de acción acotados, confirmación de transacciones y controles de política fuera del modelo. Una frase del agente que afirma que la persona aceptó no es un registro fiable de autorización. Impide que el modelo amplíe sus propios permisos y trata los resultados de herramientas y documentos recuperados como datos no confiables, no como instrucciones.

Controles de ingeniería para poner en marcha

Presupuesto de contexto por finalidadDefine categorías permitidas, antigüedad y número máximo de registros por tarea. Rechaza recuperaciones que no justifiquen cada campo.
Inventario de almacenes y proveedoresMapea copias, responsables, encargados, regiones, retención, permisos, adaptadores de borrado y backups.
Observabilidad respetuosa con la privacidadMide éxito, latencia, seguridad y coste sin registrar prompts personales ni payloads completos por defecto.
Pruebas de solicitudes de derechosSiembra identidades sintéticas en origen, memoria, vectores, logs y colas; simula acceso o supresión y verifica el resultado.
Memoria vinculada a la finalidadSepara preferencias del estado temporal; muestra qué se recuerda y permite corregir o retirar cuando corresponda.
Límite del proveedorDocumenta qué sale del entorno, retención y reutilización, subencargados y qué ocurre al terminar el servicio.
Artefacto del agenteControl de minimizaciónRiesgo de retención y derechosPrueba
Contexto del promptLista permitida por tarea y filtros de recuperación.El proveedor del modelo puede recibir datos personales.Verificar que los campos excluidos nunca estén en el payload.
Resumen de conversaciónConservar solo hechos necesarios para la finalidad activa.Puede perpetuar datos sensibles u obsoletos.Inspeccionar tras corregir y al caducar.
Memoria vectorialÍndice por tenant, referencia de origen y TTL.El borrado debe cubrir fragmentos e índices derivados.Buscar tras borrar y tras restaurar un backup.
Argumentos y resultados de herramientasSchemas acotados y autorización en servidor.Reintentos, colas y auditorías crean copias adicionales.Rastrear reintentos y excluir payloads de logs rutinarios.
Dataset de evaluaciónDatos sintéticos o controlados adecuadamente.Las fixtures pueden convertirse en almacenes duraderos de datos.Revisar fixtures, exportaciones y permisos.

Qué construiría

Añadiría al agente un registro de flujo de datos: cada tarea declara finalidad, campos permitidos, orígenes, herramientas, almacenes, encargados y retención. Una capa de políticas valida esa declaración antes de armar el contexto; un filtro de privacidad redacta salidas; los hooks de eventos asocian retención y persona a los artefactos persistidos; y un orquestador de derechos distribuye solicitudes entre adaptadores registrados. Las pruebas CI inspeccionan payloads a proveedores y ejecutan escenarios de borrado, rectificación y restauración con datos sintéticos.

Haz que el registro responda preguntas operativas: adónde puede enviar datos la tarea, qué artefactos se pueden localizar, qué caduca automáticamente y quién se ocupa de un adaptador de borrado fallido. Un tablero debe mostrar cobertura y excepciones, no afirmar “cumplimiento GDPR” porque todas las casillas están verdes.

En resumen

En agentes de IA, la minimización es una propiedad de todo el recorrido: qué entra en el contexto, qué herramientas lo ven, qué queda en memoria, qué registra la telemetría, qué proveedores reciben datos y si las copias se pueden localizar después. Delimita cada tarea, deja caducar la memoria, registra poca información de contenido y crea flujos de derechos entre almacenes. A menudo el control más fuerte es decidir desde la arquitectura que una copia innecesaria no se va a crear.

Nota editorial: Este artículo traduce principios del GDPR y materiales del EDPB en controles de ingeniería. No determina la base jurídica, las obligaciones del responsable ni la respuesta a una solicitud concreta; consulta a profesionales cualificados de privacidad y derecho para esas decisiones.

Lecturas relacionadas