Claude y el RGPD: cómo construir aplicaciones conformes para empresas europeas

Puntos clave

Anthropic ofrece DPA y opción de residencia de datos en la UE para la API de Claude. Es una base necesaria pero no suficiente para el cumplimiento RGPD
La residencia de datos en la UE resuelve el problema de dónde se almacenan los datos, pero el modelo sigue procesando prompts que pueden contener datos personales
Las Cláusulas Contractuales Tipo (CCT) del DPA son cobertura legal, no técnica. El RGPD exige minimización de datos y medidas técnicas complementarias
La arquitectura correcta: seudonimizar antes de enviar. Claude procesa tokens, no datos personales identificables

Según la documentación publicada de Anthropic, la API de Claude incluye un Acuerdo de Procesamiento de Datos (DPA) y una opción de residencia de datos en la Unión Europea. Para las empresas europeas que evalúan Claude, esto suena a que el problema de cumplimiento está resuelto. No lo está. Es el punto de partida.

Esta guía explica qué cubre realmente el DPA de Anthropic, qué exige el RGPD más allá del contrato y cómo diseñar una arquitectura que cumpla por diseño, no solo por documento.

Aviso: este artículo explica el marco general del RGPD aplicado a la construcción de aplicaciones con Claude. No es asesoramiento jurídico. Cualquier decisión sobre la licitud de un tratamiento concreto corresponde al responsable del tratamiento con su asesoría legal.

Lo que el DPA de Anthropic cubre (y lo que no)

El DPA de Anthropic establece la relación contractual entre tu organización y Anthropic como encargado del tratamiento bajo el Artículo 28 del RGPD. Esto significa que Anthropic acepta obligaciones contractuales sobre cómo trata los datos personales que recibe a través de la API.

Lo que el DPA cubre:

Obligaciones de notificación de brechas: Anthropic se compromete a notificarte en caso de violación de seguridad
Restricción de uso: los datos solo pueden usarse para proporcionar el servicio contratado
Subencargados: Anthropic debe tener acuerdos adecuados con sus propios proveedores de infraestructura
Residencia de datos: opción de procesar y almacenar datos en servidores dentro de la UE

Lo que el DPA no cubre:

Minimización técnica: el DPA no impide que los datos personales estén en el prompt que envías
Control de acceso en tu aplicación: quién en tu organización puede enviar qué datos a Claude es tu responsabilidad
Formación y políticas internas: el DPA cubre a Anthropic, no a tus empleados
Evaluación de impacto (EIPD): la obligación de evaluar el riesgo del tratamiento sigue siendo tuya

Residencia de datos en la UE: qué significa realmente

La opción de residencia de datos en la UE de Anthropic significa que los datos en reposo (almacenados) permanecen en servidores dentro del Espacio Económico Europeo. Esto es valioso y aborda una preocupación real.

Pero hay que entender qué no resuelve:

Procesamiento en inferencia: aunque los datos se almacenen en la UE, el procesamiento ocurre donde Anthropic tenga su infraestructura de inferencia. Verifica si el procesamiento también ocurre en la UE o si los datos viajan fuera durante la inferencia
Acceso administrativo: el personal de Anthropic puede necesitar acceder a los sistemas por motivos operativos. El DPA debe especificar bajo qué condiciones y con qué salvaguardas
Retención: la residencia de datos no define por sí sola cuánto tiempo se conservan. Anthropic describe un período de retención para modelos cubiertos que debe verificarse en las condiciones vigentes

La residencia de datos en la UE es una capa de protección genuina. No sustituye a la minimización de datos.

Zero Data Retention y BAA: la restricción bidireccional

Un detalle importante de la documentación de Anthropic: Zero Data Retention (ZDR) y la cobertura BAA tienen una relación inversa según el producto.

Los Covered Models requieren una ventana de retención y no están disponibles con ZDR activado. Pero algunos servicios funcionan al revés: Claude Code queda cubierto por el BAA solo cuando ZDR está activado, lo que a su vez impide usar Covered Models bajo ese BAA.

Para las empresas europeas, esto crea una tensión real: la postura de máxima minimización (ZDR) puede ser incompatible con la cobertura contractual que necesitas (BAA). No es un defecto de Anthropic — es una realidad arquitectónica: notificar brechas requiere retener datos el tiempo suficiente para investigar.

La solución no está en elegir entre ZDR y BAA. Está en que el dato personal nunca llegue a necesitar ninguna de las dos cosas.

La arquitectura que resuelve el problema de raíz

El enfoque arquitectónico funciona independientemente del proveedor y de si tiene ZDR, DPA, residencia en la UE o cualquier combinación de estas cosas.

Cuando tu aplicación enruta a través de un proxy que aplica seudonimización reversible en el edge:

Nombres → [PERSONA_1]
Emails → [EMAIL_1]
Teléfonos → [TEL_1]
Números de identificación → [ID_1]

Claude recibe tokens. Razona sobre la estructura del documento, el contexto clínico o legal, y genera una respuesta. Tu sistema rehidrata los valores reales en el camino de vuelta, en tu infraestructura, antes de que el usuario vea el resultado.

El resultado: Anthropic nunca recibe datos personales identificables. Da igual dónde estén sus servidores, cuál sea su ventana de retención o si el DPA está firmado. El dato personal nunca salió de tu control.

Qué significa esto en la práctica

Si estás evaluando Claude para tu empresa en Europa, el marco correcto no es “¿tiene Anthropic un DPA?”. Es:

¿Qué datos personales necesitan realmente llegar al modelo? En la mayoría de casos, el modelo necesita contexto (el texto del documento, la consulta del usuario), no identificadores (nombre, email, DNI)
¿Qué pasa con los datos que sí llegan? Con el DPA y residencia en la UE, los datos están contractualmente protegidos. Con un proxy arquitectónico, no hay datos que proteger porque lo que llega no es identificable
¿Qué pasa si mañana cambian las condiciones del DPA? Los contratos cambian, las arquitecturas permanecen. Una arquitectura donde el dato no sale no depende de qué diga el DPA este trimestre

Conclusión

La API de Claude con DPA y residencia de datos en la UE es una base sólida para construir aplicaciones conformes con el RGPD. Pero una base no es un edificio.

El cumplimiento real exige minimización de datos, medidas técnicas, documentación y transparencia. El DPA cubre la relación contractual. La arquitectura cubre la realidad técnica. Y en protección de datos, la realidad técnica es lo que importa cuando algo sale mal.

Privedge proporciona esa capa arquitectónica: una línea de código, sin cambiar de proveedor, sin reescribir integraciones. Claude procesa tokens. Tus datos nunca salen de tu control.

Si necesitas contexto más amplio sobre el marco legal del RGPD y la IA, empieza por aquí: ¿Es legal usar ChatGPT en tu empresa? Lo que dice la AEPD. Y si quieres entender las diferencias entre anonimización, tokenización y cifrado: guía técnica completa.