Agente IA conforme al RGPD: guía 2026

Las investigaciones del RGPD relacionadas con IA aumentaron un 340% entre 2024 y 2026, y la Ley de IA de la UE empieza a aplicar las obligaciones de alto riesgo del Anexo III el 2 de agosto de 2026, con multas que alcanzan los 15 millones de euros o el 3% de la facturación global. Los dos marcos se aplican ahora simultáneamente a cualquiera que opere un agente IA que toque datos personales de la UE, y no hay exención por "somos pequeños" o "es solo un proyecto interno del equipo".

Por eso muchas empresas europeas están rehaciendo discretamente las herramientas de IA que usaban el año pasado. La pila de proveedores cambió bajo sus pies: lo que en 2024 era una sola cuenta de OpenAI ahora es un responsable, un encargado, una cadena de subencargados, un mapa de flujo de datos y una Evaluación de Impacto en la Protección de Datos que tiene que existir de verdad antes de poner el agente en producción.

Este artículo es la versión práctica y agnóstica de proveedor de esa reconstrucción. Cubrimos qué exigen realmente el RGPD y la Ley de IA de la UE a un agente IA en 2026, por qué "región UE" sobre una nube estadounidense no basta, las decisiones de arquitectura que te mantienen del lado correcto de la línea, y dónde encaja un agente autoalojado como Hermes.

Qué significa realmente "cumple el RGPD" para un agente

El RGPD se redactó para sistemas donde un humano introduce datos y una máquina los procesa de forma predecible. Los agentes IA son más enredados. El mismo agente lee tu bandeja de entrada, llama a una API de modelo, escribe en un almacén vectorial, ejecuta una tarea programada y publica en Telegram. Cada paso es una actividad de tratamiento distinta con su propia base jurídica.

Las exigencias no han cambiado: simplemente muerden más fuerte cuando el sistema es autónomo.

Artículo 5 (minimización de datos): el agente solo debe recoger y conservar lo necesario. El historial indefinido de transcripciones completas "para analíticas o entrenamiento" es la bandera roja más común.
Artículo 6 (base jurídica): cada paso de tratamiento necesita una. El interés legítimo no es un pase libre cuando el dato es sensible o el usuario no ha sido informado.
Artículo 22 (decisiones automatizadas): si el agente toma decisiones que afectan significativamente a una persona - aprobar un reembolso, puntuar un CV, escalar un caso de soporte - el usuario tiene derecho a revisión humana.
Artículo 25 (protección de datos desde el diseño): los controles de privacidad tienen que estar en la arquitectura desde el principio, no atornillados después de una queja.
Artículo 30 (registro de actividades de tratamiento): necesitas un inventario documentado de datos personales: dónde están, quién accede y cuánto tiempo los conservas.
Artículo 17 (derecho al olvido): cuando un usuario pide ser olvidado, tienes que borrarlo: del registro de conversaciones, del almacén vectorial, de la memoria del agente y de cualquier salida de herramienta que capturó sus datos.

Los Artículos 22 y 25 son los dos más citados en la nueva ola de procedimientos sancionadores. También son los dos que pillan desprevenidos a los agentes IA alojados como servicio, porque la plataforma decide la arquitectura y tú heredas lo que ellos enviaron.

La capa de la Ley de IA de la UE encima

El RGPD regula los datos personales. La Ley de IA de la UE regula el propio sistema de IA. A partir de agosto de 2026, los proveedores y desplegadores de sistemas de "alto riesgo" - que incluyen muchos casos de uso de RRHH, crédito, educación e infraestructuras críticas - deben demostrar tres cosas:

Gobernanza: políticas documentadas, supervisión humana, un proceso real de gestión de riesgos.
Auditabilidad: registros por petición que muestren qué ejecutó el agente, cuándo y sobre qué datos.
Residencia de datos: prueba de que los datos personales y regulados se quedaron en las jurisdicciones que exige la ley.

Los dos marcos no se sustituyen. Se apilan. Para cuando la Ley de IA sea plenamente aplicable en diciembre de 2027, un agente que toque datos personales de la UE tiene que satisfacer ambos, y un único registro ausente puede dejar todo el pipeline fuera de cumplimiento.

Toma fotorrealista oscura de un pequeño rack de servidores en una habitación tenuemente iluminada con un único LED verde de estado que ilumina los cables, sugiriendo una infraestructura autoalojada discreta

Por qué "región UE" no basta

El malentendido más caro de 2026 es tratar "región UE" en un hyperscaler estadounidense como una solución de residencia. No lo es.

La CLOUD Act estadounidense permite a las fuerzas del orden de EE. UU. obligar a empresas con sede en EE. UU. a entregar datos almacenados en cualquier lugar del mundo, incluidos centros de datos europeos. Si tu proveedor de modelo, tu base de datos vectorial o tu host del agente es una entidad legal estadounidense, tus datos están sujetos a la jurisdicción de EE. UU. independientemente de la ubicación física del servidor. El Capítulo V del RGPD sobre transferencias internacionales no se fija en dónde está el disco: se fija en quién controla el acceso.

Eso tiene consecuencias reales para el diseño del agente IA. Llamar a una API de modelo con sede en EE. UU. desde dentro de la UE es una transferencia internacional de datos personales en el momento de la inferencia, aunque todas las demás capas sean europeas. La multa de 15 millones de euros del Garante italiano a OpenAI en 2024 fue parcialmente sobre exactamente este tipo de transferencia no informada.

Hay tres respuestas prácticas:

Usar un proveedor de modelo con sede en la UE (Mistral, Aleph Alpha, modelos open-weight alojados en OVHcloud). Las transferencias se quedan dentro del EEE y no hacen falta Cláusulas Contractuales Tipo.
Autoalojar el modelo en infraestructura de la UE (Llama, Mistral, Qwen vía Ollama o vLLM). No ocurre ninguna transferencia: la inferencia se ejecuta en hardware que tú controlas.
Usar un proveedor estadounidense con un Acuerdo de Tratamiento de Datos firmado y documentar el mecanismo de transferencia. Posible, pero el papeleo es máximo y la base jurídica es la más frágil si no se ha informado al usuario.

La elección depende de la sensibilidad del dato y del presupuesto. Para agentes de cara al consumidor que manejan datos de contacto ordinarios, un proveedor estadounidense respaldado por un DPA puede ser defendible. Para agentes que tocan datos de salud, financieros o de RRHH, la segunda opción es cada vez más el valor por defecto seguro.

La arquitectura de agente autoalojado que aguanta

Autoalojar el runtime ayuda mucho, pero por sí solo no resuelve la residencia en el momento de la inferencia. Una arquitectura defendible en 2026 combina varias capas.

Un runtime autoalojado en infraestructura UE (Hetzner, OVHcloud, Scaleway, tu propio hardware). El proceso del agente, los registros de conversación, el almacén vectorial y los archivos de habilidades viven en discos que tú controlas.
BYOK sobre el proveedor de modelo para que elijas dónde ocurre la inferencia. Bring Your Own Key mantiene transparente la factura del modelo, el flujo de datos y la elección de proveedor.
Secretos cifrados en reposo para claves API, tokens OAuth y credenciales de mensajería. El cifrado a nivel de disco no basta: cifrado a nivel de aplicación con una clave que la plataforma anfitriona nunca ve es el listón.
Listas de permitidos estrictas en cada superficie de mensajería (Telegram, Slack, Signal, email). Los agentes que responden a cualquiera con el nombre del bot son el vector de incidente RGPD más común para quienes autoalojan.
Una política de retención documentada con trabajos de borrado realmente en ejecución. "Borramos a petición" no basta si no puedes mostrar el rastro de auditoría petición-a-borrado.
Logs estructurados por petición que capturen lo que el agente hizo, pero redacten los datos personales dentro de los prompts. Las nuevas pilas de logging estructurado lo hacen práctico sin escribir el tuyo propio.

Este es el patrón de arquitectura que el Artículo 25 del RGPD ("protección de datos desde el diseño") espera que puedas dibujar en una pizarra. También es el patrón que sobrevive a una Evaluación de Impacto en la Protección de Datos sin meses de remediación posterior.

Dónde encajan Hermes y Hermify

Hermes Agent es una opción que se alinea con la arquitectura anterior de fábrica. Tiene licencia MIT, corre en Docker en cualquier VPS de la UE, BYOK sobre el proveedor de modelo para que elijas dónde ocurre la inferencia, cifra las claves API en reposo y trae controles de allowlist por mensajero (SLACK_ALLOWED_USERS, SIGNAL_ALLOWED_USERS, EMAIL_ALLOWED_USERS). El registro de conversación, el almacén vectorial y la memoria persistente del agente viven todos en HERMES_HOME en el host que elegiste, lo que significa que la residencia de datos es una decisión de despliegue, no una decisión de proveedor.

El marco honesto: Hermes autoalojado más BYOK soporta una arquitectura defendible bajo el RGPD, pero no es una certificación. Tú sigues siendo el responsable. Sigues necesitando la EIPD, la política de retención, el trabajo de borrado y los registros del Artículo 30. Lo que cambia es que la capa técnica deja de pelearte.

Para empresas europeas que quieren la misma configuración sin operar infraestructura, Hermify aloja Hermes en VPS de región UE, firma un DPA para la capa de runtime y mantiene tus claves de proveedor cifradas con una clave que la plataforma no puede leer. El proveedor del modelo sigue siendo tu elección y tu responsabilidad: esa es la parte BYOK, y es la capa donde se decide la residencia.

Toma cinematográfica oscura de un escritorio de madera con un portátil abierto en un visor de logs estructurados con suaves resaltes verdes y un cuaderno de papel con marcas escritas a mano al lado, sugiriendo una auditoría manual cuidadosa de un agente IA

Una lista breve de cumplimiento

Una lista corta y práctica para llevarse a una conversación de EIPD:

Mapea cada lugar donde viven datos personales dentro del agente: registro de conversación, almacén vectorial, archivos de habilidades, salidas de herramientas, archivos de mensajes.
Elige el proveedor de modelo con los ojos abiertos respecto a la jurisdicción. UE o autoalojado es el camino más fácil.
Firma DPAs con cada encargado y subencargado de la cadena.
Implementa borrado real, no solo un flag, y demuéstralo con un rastro de auditoría.
Cierra las superficies de mensajería con allowlists explícitas y rota los tokens del bot.
Loguea por petición, redacta al momento del log y conserva los logs solo lo necesario.
Añade un paso humano-en-el-bucle allí donde el agente tome decisiones bajo el Artículo 22.
Documenta todo. Los registros del Artículo 30 son el seguro más barato contra un hallazgo de "no puedes demostrar lo que hizo tu agente".

El valor por defecto de 2026

Hace cinco años "IA conforme al RGPD" sonaba a preocupación europea de nicho. En 2026 es la pregunta de arquitectura que decide si puedes venderle a una empresa grande, hacer un piloto del sector público o aceptar un solo cliente de la UE sin reconstruir el próximo trimestre. Las respuestas técnicas - runtime autoalojado, BYOK, residencia UE en la capa que importa, secretos cifrados, allowlists, borrado de verdad - ya no son exóticas. Son los valores por defecto. Los proveedores que no construyeron para esto son los que se están reconstruyendo alrededor.

Si prefieres saltarte el trabajo de infraestructura y partir de una línea base endurecida, empieza con Hermify lleva unos minutos y te deja en la arquitectura anterior. Si prefieres operar toda la pila tú mismo, los mismos patrones aplican: el resto del trabajo es tuyo, pero el agente no tiene por qué ser la parte que te pelea.