La respuesta corta es no. El acuerdo de encargo de tratamiento (DPA) es necesario cuando el proveedor trata datos personales por cuenta del cliente, pero no convierte toda la relación contractual en un tratamiento por cuenta ajena ni garantiza, por sí solo, confidencialidad absoluta, retención cero, ausencia de acceso, residencia europea o licitud del caso de uso. En los servicios corporativos de OpenAI y Anthropic, el DPA convive, a su vez, con los términos comerciales, la documentación técnica, las políticas de uso y la configuración efectiva de cada organización, proyecto, modelo y funcionalidad.
El contrato puede denominar “instrucción” operaciones sobre un tratamiento, pero la condición de responsable o encargado se determina por la realidad operativa: quién determina para qué y los medios esenciales. Cuando el proveedor conserva, revisa o reutiliza datos para un fin propio, por ejemplo, entrenar a partir de feedback voluntario o desarrollar sus mecanismos generales de seguridad, puede actuar como responsable respecto de ese tratamiento en concreto, aunque sea encargado para prestar la inferencia.
1. El DPA es solo una pieza del expediente, no el expediente
El artículo 28 RGPD exige un contrato con contenido mínimo, pero el responsable sigue obligado a escoger encargados con garantías suficientes, documentar la licitud, aplicar minimización y limitación de la finalidad, adoptar medidas de seguridad, facilitar derechos, gobernar transferencias y, cuando proceda, realizar una evaluación de impacto. Firmar el formulario del proveedor acredita una parte de esa diligencia, pero no resuelve el análisis del tratamiento concreto.
Las Directrices 07/2020 del Comité Europeo de Protección de Datos insisten en un criterio funcional, esto es, el encargado solo puede tratar datos siguiendo instrucciones del responsable. Si trasciende y determina finalidades y medios por su cuenta, pasa a ser responsable para ese tratamiento. Tampoco basta una cláusula genérica que autorice cualquier uso necesario para el negocio del prestador; las instrucciones deben ser identificables y compatibles con el RGPD.
2. Primero: identificar la versión realmente contratada
La protección contractual depende del producto, no de la marca ni del precio de la suscripción personal. Las versiones de consumo y las corporativas no son intercambiables.
Antes de comparar productos/versiones conviene precisar cuatro conceptos:
▪ “Entrenamiento” es el uso de información para ajustar o mejorar los parámetros de un modelo.
▪ “Retención” es la conservación de entradas, salidas, archivos, registros u otros datos después de generar la respuesta.
▪ “Retención cero” o “ZDR”, por sus siglas en inglés, es una configuración contractual y técnica por la que el proveedor no guarda determinados contenidos una vez completada la operación, si bien no impide necesariamente la conservación de metadatos, resultados de clasificadores, datos exigidos por ley o información tratada por funciones excluidas.
▪ “Monitorización modificada de abusos” o “MAM”, es un control especial de la API de OpenAI mediante el cual el contenido del cliente normalmente queda excluido de los registros utilizados para detectar abusos. A diferencia de ZDR (Zero Data Retention), MAM permite utilizar ciertas funciones que necesitan conservar estado. Requiere cumplir los requisitos de elegibilidad y obtener la aprobación de OpenAI. Además, existen excepciones para determinados archivos, imágenes o contenidos de riesgo.
Por ello, no entrenar, borrar una conversación y disponer de ZDR son garantías distintas.
Respecto de OpenAI, el análisis de este artículo se refiere exclusivamente a ChatGPT Business, ChatGPT Enterprise, ChatGPT Edu y la OpenAI API cuando se contratan bajo el Services Agreement y su DPA.
En Anthropic se refiere a Claude for Work en sus planes Team y Enterprise, y a la Claude API contratada directamente con Anthropic bajo los Commercial Terms y su DPA.
Las cuentas personales, aunque sean de pago, no deben considerarse versiones corporativas.
| Proveedor / modalidad | DPA corporativo | Entrenamiento por defecto | Retención y controles |
|---|---|---|---|
| OpenAI: ChatGPT Business, Enterprise, Edu y API | Sí, bajo el Services Agreement y el DPA aplicable. | No se usa Customer Content para mejorar servicios salvo aceptación expresa. | La API genera por defecto logs de abuso hasta 30 días; ZDR/MAM exige elegibilidad y aprobación. Algunas funciones conservan estado o no son elegibles. |
| OpenAI: Free, Plus, Pro y otros planes personales | No debe presumirse el DPA corporativo. | Rige la política de consumo y los controles de cuenta. | No debe mezclarse una cuenta personal con el entorno gobernado de la empresa. |
| Anthropic: Claude for Work (Team/Enterprise) y API directa | Sí, incorporado a los Commercial Terms. | No usa inputs/outputs comerciales para entrenar por defecto. | API: eliminación ordinaria en 30 días; Claude for Work conserva chats para la experiencia del producto. Enterprise permite controles, con mínimo publicado de 30 días. |
| Anthropic: Free, Pro, Max y Claude Code asociado a esos planes | No se aplica el régimen corporativo por el mero pago individual. | Rige el régimen de consumo y sus opciones. | No equivale a Team/Enterprise ni a una organización API con ZDR. |
3. OpenAI: el perímetro real del DPA
Este apartado, como se ha indicado, viene referido a ChatGPT Business, ChatGPT Enterprise, ChatGPT Edu y la OpenAI API sujetos al Services Agreement corporativo. El DPA de OpenAI, actualizado el 1 de diciembre de 2025 y efectivo desde el 1 de enero de 2026, establece que OpenAI actúa como encargado respecto de los «Customer Data» tratados para prestar esos servicios. Las instrucciones documentadas incluyen el propio DPA, el Services Agreement, la orden de pedido y las herramientas de configuración. Esa remisión es decisiva, puesto que para conocer la instrucción no basta leer el DPA; hay que leer el contrato principal y la configuración efectiva del espacio de trabajo u organización API.
DPA de OpenAI: ámbito, funciones de las partes e instrucciones documentadas (consulta: 21.09.2026).
Fuente: documento oficial.
El Services Agreement limita el uso del contenido del cliente a prestar los servicios, pero también para cumplir la ley aplicable, hacer cumplir las políticas de OpenAI y prevenir abusos. Prohíbe el uso para desarrollar o mejorar los servicios salvo aceptación expresa. Por tanto, la obligación contractual relevante es “no entrenamiento por defecto”, no “ausencia de cualquier tratamiento secundario”.
Services Agreement de OpenAI, cláusula 4.2: usos permitidos del contenido y exclusión del entrenamiento salvo acuerdo expreso (consulta: 21.09.2026). Fuente: documento oficial.
3.1 Usos y datos que subsisten en las versiones corporativas
Un “log de prevención de abusos” es un registro generado para detectar infracciones de las políticas de uso o actividades no permitidas. Puede incluir el contenido enviado, la respuesta y metadatos creados por sistemas automáticos. “Estado de aplicación” es la información que una función necesita conservar para seguir operando, como una conversación persistente, un archivo o un almacén vectorial. Un “almacén vectorial” es una base de datos que convierte documentos en representaciones numéricas para recuperarlos por similitud semántica.
De la documentación oficial de OpenAI se deducen lo siguientes usos secundarios:
- Prevención de abuso y aplicación de políticas: La documentación de la API declara logs que pueden contener prompts, respuestas y metadatos derivados, incluidos resultados de clasificadores. Se conservan por defecto hasta 30 días, salvo obligación legal o necesidad razonable de proteger servicios o terceros.
- Safety Retention incluso con controles reforzados: OpenAI se reserva hacer determinados modelos inelegibles para ZDR/MAM cuando sea razonablemente necesario investigar o prevenir actividad de riesgo grave. El contenido detectado por clasificadores puede conservarse y someterse a revisión humana.
- CSAM y revisión manual: Las entradas de imágenes y archivos se analizan. Si el clasificador detecta posible material de abuso sexual infantil, la imagen puede conservarse para revisión manual incluso con ZDR, MAM o Eyes Off¹.
- Estado de aplicación: Conversaciones, agentes, assistants, threads, vector stores, files, fine-tuning, evals y batches tienen reglas propias. Algunos objetos se conservan hasta que el cliente los elimina y varias funciones no son elegibles para ZDR.
- Caché y terceros. El prompt caching ² puede mantener tensores cifrados hasta 24 horas. Los servidores MCP y otros servicios conectados están sujetos a sus propias políticas, fuera del control directo del DPA de OpenAI.
- Feedback. Si el cliente lo facilita, concede a OpenAI un derecho de uso y explotación sin restricción ni compensación. Si el feedback incorpora datos personales o reproduce una conversación, ese uso debe analizarse separadamente.
- Datos de cuenta, facturación, soporte, seguridad y navegación. No todo dato relacionado con la relación comercial es «Customer Data» tratado por cuenta del cliente. En la medida en que OpenAI fija fines propios como gestión contractual, cobro, prevención del fraude, seguridad de su plataforma, defensa jurídica o cumplimiento, actúa como responsable, con su propia base jurídica y deberes de información.
4. Anthropic: Claude corporativo tampoco equivale a retención cero
Este apartado se refiere a Claude for Work Team, Claude for Work Enterprise y la Claude API contratada directamente con Anthropic. El DPA de Anthropic, efectivo desde el 24 de febrero de 2025, define al cliente como responsable y a Anthropic como encargado para los datos personales del cliente. Establece el tratamiento solo para prestar o mantener los servicios y conforme a instrucciones documentadas. Su anexo incluye, además de la prestación, la verificación o mantenimiento de la calidad, seguridad e integridad y la depuración de errores. Los Commercial Terms añaden que Anthropic no entrena modelos con Customer Content.
DPA de Anthropic: cliente como responsable, Anthropic como encargado y límites del tratamiento por instrucciones (consulta: 21.09.2026). Fuente: documento oficial.
La propia documentación corporativa, además, describe tratamientos y retenciones adicionales. La API elimina ordinariamente entradas y salidas en 30 días, con excepciones por servicios de almacenamiento, acuerdos específicos, cumplimiento de la Usage Policy y de la Ley. Claude for Work conserva chats y sesiones para ofrecer continuidad, Enterprise permite configurar retención, pero la configuración publicada parte de un mínimo de 30 días y los proyectos pueden conservarse indefinidamente por defecto.
Privacy Center de Anthropic: conservación por infracciones de uso, puntuaciones de seguridad y datos de feedback (consulta: 21.09.2026). Fuente: documento oficial.
4.1 Usos y excepciones relevantes en Claude Team Enterprise y API
Anthropic denomina «Trust & Safety» al conjunto de controles destinados a detectar usos dañinos o contrarios a sus políticas. Los «Covered Models» son modelos de capacidad elevada a los que Anthropic aplica requisitos reforzados de conservación y revisión. Un «clasificador» es un sistema automático que asigna una categoría o puntuación de riesgo a una entrada o respuesta. Esa puntuación puede conservarse separadamente del texto de la conversación.
De conformidad con lo anterior, Anthorpic define los siguientes tratamientos para los que actúa como responsable del tratamiento:
- Trust & Safety: Si los sistemas automatizados marcan una conversación por posible infracción, Anthropic declara conservar inputs y outputs hasta dos años y puntuaciones de clasificación hasta siete años. La excepción se mantiene incluso con ZDR o acuerdos HIPAA.
- Covered Models: Determinados modelos de mayor capacidad exigen 30 días de retención para tareas de seguridad y no están disponibles bajo ZDR salvo autorización expresa. La revisión humana se limita, según Anthropic, a rutas controladas y contenido marcado.
- Feedback y errores comunicados: En productos B2B no hay entrenamiento por defecto, pero al pulsar pulgar arriba/abajo o informar de errores puede conservarse la conversación completa hasta cinco años y usarse para análisis, investigación, estudio de comportamiento y entrenamiento. Anthropic afirma desvincularla de los identificadores de usuario y cliente antes de ese uso.
- Datos anonimizados: La política corporativa indica que, si el contrato lo permite, Anthropic puede anonimizar datos de la organización con fines estadísticos o de investigación y conservarlos más tiempo. La anonimización real queda fuera del RGPD, la mera seudonimización, no.
- Datos de cuenta y relación comercial: Anthropic puede ser responsable respecto de datos que obtiene y usa para administrar cuentas, facturación, comunicaciones, seguridad propia, defensa de reclamaciones y obligaciones legales. El propio Privacy Center reconoce que su Privacy Policy describe tratamientos como responsable al prestar servicios a una organización, aunque la compañía sea encargada para los datos de uso sometidos al DPA.
- Funcionalidades fuera de ZDR: ZDR se habilita por organización y no se extiende automáticamente a otras. Las funciones no elegibles no se bloquean necesariamente, por lo que utilizarlas supone salir del acuerdo ZDR para esos datos y aplicar la retención específica y predeterminada de la función.
5. ¿Cuándo actúan como responsables pese al DPA?
No es correcto afirmar que toda prevención de abuso convierte sin más al proveedor en responsable. La seguridad necesaria para prestar el servicio puede formar parte del encargo puesto que el artículo 32 RGPD obliga también al encargado, y ambos DPA incorporan finalidades de seguridad o calidad. La calificación cambia cuando el proveedor decide un fin propio y los medios esenciales sin que el cliente pueda instruir, configurar o impedir materialmente ese uso.
Esto es, en resumen:
| Tratamiento | Rol más defendible del proveedor de IA | Motivo |
|---|---|---|
| Inferencia y almacenamiento funcional configurado por la empresa. | Encargado | La empresa decide la finalidad de negocio y configura el servicio; el proveedor ejecuta la operación. |
| Seguridad técnica estrictamente necesaria para prestar el servicio. | Normalmente encargado | Puede integrar el encargo si está delimitada, es necesaria y no persigue un fin autónomo incompatible. |
| Aplicación general de políticas y lucha contra abuso para proteger la plataforma o terceros. | Normalmente responsable | El proveedor determina criterios, clasificadores, acceso humano, plazo excepcional y posibles comunicaciones. Debe analizarse cada operación. |
| Cumplimiento de una obligación legal propia, cooperación con autoridades y defensa jurídica. | Responsable | El proveedor decide el tratamiento por una obligación o interés propio; el art. 28.3.a RGPD contempla el tratamiento exigido por el Derecho aplicable al encargado, pero no convierte al cliente en autor de esa finalidad. |
| Uso de feedback para investigación o entrenamiento. | Responsable independiente, salvo que exista un programa encargado y documentado | El proveedor determina la mejora de sus modelos como fin propio. El consentimiento contractual del cliente no altera por sí solo el rol RGPD. |
| Datos de cuenta, facturación, cobro, marketing B2B y relación contractual. | Responsable independiente | Son fines propios de gestión de la relación contractual; quedan fuera del núcleo de Customer Data procesado por cuenta del cliente. |
| Datos realmente anonimizados. | Fuera del RGPD | Solo si la reidentificación no es razonablemente posible. Desvincular IDs o seudonimizar no basta. |
6. La reversibilidad de las “representaciones internas” de los LLM como riesgo técnico
Por último, cabe tener en cuenta que un modelo de lenguaje transforma el texto de entrada en representaciones numéricas internas llamadas “activaciones ocultas”. Una función es «inyectiva» cuando cada entrada distinta genera un resultado diferente. En ese caso, si se conoce la representación interna producida por el modelo, puede ser posible recorrer el proceso en sentido inverso y reconstruir el texto de entrada. El trabajo científico “Language Models are Injective and Hence Invertible³” sostiene que determinados modelos basados en transformers presentan esa propiedad y, por lo tanto, podrían ser capaces de reconstruir el texto exacto a partir de activaciones ocultas.
La consecuencia es que “no entrenar” o “no guardar el prompt como texto” no equivale necesariamente a imposibilidad técnica de recuperación en cualquier arquitectura o fase del tratamiento si se accede a las representaciones internas adecuadas y se mantienen unas condiciones técnicas determinadas.
7. ¿Qué debe exigir (si puede) una empresa además del DPA?
- Inventario exacto de productos, planes, organizaciones, proyectos, modelos, endpoints, herramientas, conectores y subencargados que van a interactuar en el tratamiento.
- Matriz de roles por operación: inferencia, alojamiento, soporte, telemetría, facturación, seguridad, abuso, feedback, entrenamiento, cumplimiento legal y defensa de reclamaciones.
- Configuración probada: exclusión de entrenamiento, desactivación o control del feedback, retención, eliminación, compartición, enlaces públicos, memoria, conectores y almacenamiento de ficheros.
- Confirmación contractual de ZDR o control equivalente cuando el riesgo lo requiera; no basta una página comercial. Debe verificarse su alcance por modelo y funcionalidad, y sus excepciones.
- Análisis de base jurídica, transparencia y compatibilidad para los tratamientos propios del proveedor. El cliente debe informar, al menos, de destinatarios, transferencias y consecuencias relevantes del servicio.
- Evaluación de transferencias internacionales, garantías adecuadas, medidas suplementarias, localización de almacenamiento y procesamiento, soporte remoto y solicitudes de autoridades de terceros países.
- Soporte en la realización de una DPIA cuando concurra alto riesgo, por ejemplo, datos de salud, monitorización, decisiones significativas, gran escala, colectivos vulnerables o uso innovador combinado y consulta al DPO.
- Confección de una política interna de uso: prohibiciones por categoría, anonimización o seudonimización previa, revisión humana, control de salidas, secreto profesional, propiedad intelectual, clasificación de información y respuesta a incidentes.
- Pruebas de borrado y conservación: no solo chats visibles, sino objetos persistentes, archivos, vector stores, batches, proyectos, logs, cachés y copias derivadas.
- Mecanismo de seguimiento de cambios: Los documentos web, listas de subencargados, modelos cubiertos y funciones elegibles para ZDR varían. La revisión debe ser periódica y ante cada nueva función.
8. Conclusión
El DPA de OpenAI o Anthropic es necesario, pero no suficiente. En los planes corporativos, ambos proveedores asumen el rol de encargado para el núcleo de los datos personales tratados por cuenta del cliente y excluyen el entrenamiento por defecto. No obstante, a la vez, subsisten tratamientos de seguridad, aplicación de políticas, cumplimiento, conservación excepcional y feedback, cuyo alcance, finalidad y duración dependen del producto, la funcionalidad y la configuración utilizada.
La empresa que decide utilizar la IA continúa siendo responsable de su propio tratamiento y no puede trasladar esa responsabilidad al proveedor mediante la mera firma del DPA. Debe determinar previamente la finalidad y la base jurídica, aplicar los principios de minimización, limitación de la finalidad, protección de datos desde el diseño y seguridad, seleccionar una modalidad que ofrezca garantías suficientes y documentar las instrucciones, configuraciones y controles efectivamente aplicados. También debe analizar los tratamientos propios o secundarios del proveedor, identificar el rol que corresponde a cada parte, informar de forma transparente sobre destinatarios, obtener una base de legitimación, transferencias, plazos y usos relevantes y, cuando proceda, evaluar su compatibilidad con la finalidad inicial, realizar una evaluación de impacto y establecer medidas adicionales o abstenerse de utilizar el servicio.
El envío de información a una herramienta de IA puede constituir, si se aparta del encargo, una comunicación a un tercero, permitiendo el acceso del proveedor, sus subencargados, servicios conectados o personal de soporte en los supuestos previstos contractualmente. Por ello, antes de introducir datos personales, secretos empresariales, información sujeta a acuerdos de confidencialidad, secreto profesional, la empresa debe comprobar que dispone de autorización y/o cobertura jurídica suficientes y que el acceso queda limitado a los destinatarios autorizados.
Una carga de información no autorizada o una configuración inadecuada puede implicar no solo un incumplimiento del RGPD, sino también la vulneración de obligaciones contractuales o profesionales de confidencialidad. Si ocasiona el acceso, divulgación, alteración o pérdida no autorizados de datos personales, deberá valorarse además como una posible violación de seguridad, con las correspondientes obligaciones de documentación, mitigación y, cuando proceda, notificación a la autoridad de control y comunicación a las personas afectadas.
La respuesta jurídicamente rigurosa no es negar valor al DPA, sino acotar su perímetro funcional. La empresa debe poder demostrar qué datos envía, a qué producto y destinatarios, bajo qué configuración, con qué finalidad y base jurídica, durante cuánto tiempo, con qué excepciones y en qué rol actúa cada parte. Si no puede verificar estos extremos o evitar comunicaciones incompatibles con sus deberes de reserva y secreto, la medida adecuada no es confiar únicamente en una declaración comercial de “no entrenamiento”, sino restringir los datos, adoptar controles adicionales o no utilizar la funcionalidad para ese caso de uso.
¹ Definida como una política de privacidad y de manejo de datos en la que ningún empleado o revisor humano de OpenAI tiene acceso visual o de lectura a las conversaciones, mensajes o archivos que los usuarios intercambian con la inteligencia artificial.
² La API guarda temporalmente una representación procesada de la parte inicial repetida de una entrada, por ejemplo, unas instrucciones extensas que se envían en muchas solicitudes para no tener que procesarla de nuevo cada vez. Esto permite: reducir la latencia, abaratar el coste de los tokens repetidos o responder más eficientemente.
³ Disponible aquí:
https://proceedings.iclr.cc/paper_files/paper/2026/file/5f124a1979570872ff46a6de8fbac35c-Paper-Conference.pdf
Articulo revisado por Gerard Espuga, abogado especialista en Derecho Digital y Protección de Datos
