Flujos de trabajo de IA conformes con el RGPD: residencia de datos, DPAs y registros de auditoría
La mayoría de los equipos de la UE que añaden un paso de LLM a un flujo real se topan con el mismo muro. El prototipo funciona, y entonces alguien pregunta adónde van los datos personales. Si la respuesta es «a una API en Estados Unidos, creemos», el proyecto pasa el siguiente trimestre en revisión jurídica.
El RGPD (GDPR) no prohíbe los pasos de LLM. Plantea una lista conocida de preguntas, y casi todas son decisiones de arquitectura, no papeleo. Los equipos que las resuelven en la primera semana llevan la automatización de flujos con IA a producción casi a la misma velocidad que los que las ignoran — menos la remediación posterior.
Resuelve la base jurídica antes del PoC
La primera conversación no es con un ingeniero. Lleva una descripción de una página del flujo a quien sea responsable de privacidad — DPO, asesoría jurídica o el fundador que lleva ese sombrero — y cierra cinco preguntas:
¿Cuál es la base jurídica para cada categoría de datos personales que toca el flujo: contrato, interés legítimo o consentimiento?
¿Algún paso produce una decisión con efectos jurídicos o significativamente similares sobre una persona (artículo 22)?
¿Quién es responsable y quién encargado del tratamiento en cada paso, incluido el proveedor del modelo?
¿Algún dato sale de la UE y, en ese caso, bajo qué mecanismo de transferencia?
¿Cuánto tiempo se conservan entradas, salidas y logs, y quién puede borrarlos?
La pregunta del artículo 22 es la más importante porque cambia la arquitectura. Si el flujo influye en crédito, empleo, seguros, vivienda o algo comparable, necesita un punto de decisión humana real — no un sello al final. Eso es una pantalla que se diseña y se presupuesta, no una frase en un documento de políticas.
Envía campos, no registros
La minimización de datos es el control de cumplimiento más barato y, además, suele mejorar la salida del modelo. El principio: el modelo solo ve lo que el paso necesita.
Envía los campos concretos que usa cada paso — el texto de la reclamación y una lista de categorías, no el registro completo del CRM.
Sustituye nombres, emails y números de cuenta por IDs internos antes de la llamada al modelo; vuelve a unirlos después de la respuesta.
Filtra la recuperación antes de que llegue al prompt, de modo que los fragmentos de RAG se limiten a lo que el flujo realmente necesita.
Seudonimiza las entradas de texto libre cuando sea viable; los datos personales incidentales dentro de un hilo de correo pegado siguen siendo datos personales.
Registra exactamente qué se envió. La minimización que no puedes demostrar ante un auditor no cuenta.
Aquí cumplimiento e ingeniería empujan en la misma dirección: los prompts a nivel de campo son más fáciles de probar, más baratos de ejecutar y más fáciles de defender.
Residencia, DPAs y retención
Dónde se ejecuta el modelo es una decisión de compra con tres opciones viables, en orden creciente de control y coste:
Endpoints en región UE. Los principales proveedores de modelos ofrecen inferencia en región UE, con tratamiento dentro de la UE bajo el DPA estándar del proveedor. El valor por defecto sensato para la mayoría de proyectos.
Despliegue en tu nube. Modelos servidos dentro de tu propio tenant de AWS, Azure o GCP en una región de la UE, de modo que los datos permanecen dentro de acuerdos de nube que ya has auditado.
Modelos open-weights autoalojados. Control máximo, coste operativo real. Elígelo porque lo exige un regulador o un contrato con un cliente, no por reflejo.
Elijas lo que elijas, haz explícita la cadena de DPAs. Cuando construimos un flujo, actuamos como tu encargado del tratamiento bajo un DPA, y el proveedor del modelo figura como subencargado designado con sus propias condiciones. Antes de arrancar el PoC, verifica dos cláusulas en esas condiciones: que las entradas por API no se usan para entrenar modelos (estándar en los planes de empresa, pero pídelo por escrito) y que la ventana de retención para supervisión de abusos — normalmente de cero a treinta días — coincide con lo que le contaste a tu DPO.
Los logs de auditoría son una funcionalidad del RGPD
Muchos equipos tratan el log de auditoría como sobrecoste de ingeniería. Bajo el RGPD cumple doble función. Cada llamada al modelo dentro del flujo debería registrar:
El payload de entrada minimizado que realmente se envió
El modelo, su versión y la versión del prompt
La salida, con una señal de confianza cuando esté disponible
El revisor que la aprobó, corrigió o rechazó
Las marcas de tiempo y el reloj de retención que dispara el borrado
Esa única tabla sostiene tu registro de actividades de tratamiento del artículo 30, responde a las solicitudes de acceso sobre tratamiento automatizado y te da algo concreto que mostrar cuando una persona se opone a una decisión. Es también lo que hace que la revisión humana en flujos de IA tenga sentido bajo el artículo 22: una revisión sin log es una opinión; una revisión con log es responsabilidad demostrable.
Qué incluye un PoC de dos semanas listo para cumplimiento
Nada de esto exige un programa largo. En un PoC de dos semanas, el cumplimiento es parte de la construcción, no una vía paralela:
Un diagrama de flujo de datos que nombra cada sistema que tocan los datos personales, incluido el endpoint del modelo y su región
Una ficha de base jurídica y artículo 22 redactada para que la confirme tu DPO — insumo para asesoría jurídica, no un sustituto
Seudonimización en la frontera del flujo, con reidentificación solo después de la llamada al modelo
Un endpoint en región UE o en tu nube acordado en la primera semana, no adaptado en el tercer mes
La tabla de logs de auditoría activa desde el primer día, cubriendo cada llamada al modelo
Una pantalla de revisión humana para cualquier decisión que se acerque al territorio del artículo 22
Documentación de entrega que un DPO pueda leer sin un ingeniero en la sala
Esto cabe dentro de un Quick DX PoC (dos semanas, $12,500–$18,000) porque son decisiones de diseño, no software adicional — consulta el alcance en paquetes. Trabajar con una entidad de la UE (Polonia) también simplifica la logística alrededor: facturación en la UE, SEPA y un encargado del tratamiento que está, a su vez, sujeto al RGPD.
Una advertencia honesta para cerrar. Somos ingenieros, no abogados. Este artículo mapea las decisiones técnicas que aceleran una revisión de RGPD; el juicio jurídico sobre la base legal y el artículo 22 corresponde a tu DPO o a tu asesoría. El movimiento práctico es simple: pon ese diagrama de una página delante de ellos en la primera semana, y la revisión jurídica pasa de bloqueo a visto bueno.