¿Qué es un DPA?
Privacidad, seguridad e identidad
En este artículo, DPA significa Acuerdo de Procesamiento de Datos (Data Processing Agreement). Es el contrato escrito o acuerdo legal que establece cómo un encargado del tratamiento puede gestionar datos personales en nombre de un responsable. En el trabajo con IA, un DPA ayuda a definir instrucciones, seguridad, subencargados, derechos de los interesados, supresión, derechos de auditoría y lo que el proveedor puede o no puede hacer con los datos personales.
Revisado por Jackie, Head of Learning & Development, Levellers - Última revisión: 8 de junio de 2026
Qué significa esto
DPA puede significar más de una cosa. En el derecho de privacidad del Reino Unido, algunas personas usan DPA para referirse a la Data Protection Act 2018. En la contratación de proveedores y herramientas de IA, DPA suele significar Acuerdo de Procesamiento de Datos (Data Processing Agreement). Este artículo usa DPA en ese segundo sentido: el acuerdo entre un responsable del tratamiento y un encargado.
Un responsable decide por qué y cómo se tratan los datos personales. Un encargado actúa en nombre del responsable. Cuando un encargado trata datos personales por cuenta de un responsable, el UK GDPR exige un contrato escrito u otro acto jurídico que establezca condiciones específicas.
En el trabajo con IA, un DPA no es un anexo meramente formal a un formulario de pedido de software. Es el documento que debe hacer que la relación con el proveedor sea operativamente viable: qué datos se tratan, con qué finalidad, bajo las instrucciones de quién, con qué salvaguardas, con qué subencargados y qué ocurre cuando finaliza el contrato.
Por qué es importante
Las herramientas de IA suelen estar en el centro de flujos de trabajo con datos en tiempo real. Pueden resumir mensajes de clientes, transcribir reuniones, clasificar tickets de soporte, enriquecer registros, buscar en documentos internos o generar borradores de respuestas. Si esos flujos de trabajo contienen datos personales, la organización necesita comprender el papel del proveedor.
Un DPA es importante porque convierte garantías genéricas en obligaciones concretas. Debe ayudar al responsable a demostrar responsabilidad proactiva, responder a solicitudes de acceso (DSARs), gestionar brechas de seguridad, revisar la seguridad, controlar a los subencargados y garantizar que los datos personales se supriman o devuelvan cuando finalice el servicio.
Para las organizaciones pequeñas y medianas, el riesgo práctico es adquirir una herramienta primero y plantearse las preguntas sobre protección de datos después. Una vez que el personal ha construido un flujo de trabajo en torno a un proveedor, los términos contractuales débiles son más difíciles de corregir.
Cómo funciona
La ICO establece que siempre que un responsable utilice un encargado, debe existir un contrato escrito u otro acto jurídico. El contrato debe especificar el objeto, la duración, la naturaleza y la finalidad del tratamiento, el tipo de datos personales, las categorías de interesados y las obligaciones y derechos del responsable.
El contrato también debe incluir cláusulas sobre instrucciones documentadas, confidencialidad, seguridad, subencargados, asistencia con los derechos de las personas, asistencia en materia de seguridad, notificación de brechas y evaluaciones de impacto (DPIAs), supresión o devolución de datos al finalizar el contrato, e información de auditoría.
En un proceso de contratación de IA, el DPA debe revisarse junto con las condiciones del producto, la información de seguridad, los ajustes de retención de datos, las declaraciones sobre uso para entrenamiento y cualquier mecanismo de transferencia internacional. El DPA puede indicar "encargado", pero la configuración real del producto puede seguir siendo relevante. Un proveedor que utiliza los prompts de los clientes para mejorar sus propios modelos puede plantear preguntas distintas a las de un proveedor que solo trata datos para prestar el servicio contratado.
El acuerdo también debe leerse teniendo en cuenta la realidad operativa. Si el personal puede pegar cualquier documento en una herramienta, el contrato por sí solo no impedirá un uso excesivo de los datos. Si una integración sincroniza un buzón de correo o un repositorio de documentos completo, la descripción del tratamiento no debería dar a entender que el proveedor solo accede a un conjunto reducido de campos. El DPA debe ajustarse al flujo de trabajo configurado con suficiente precisión como para que un responsable pueda entender el riesgo sin necesidad de leer cada anexo técnico.
Ejemplos
Un equipo de atención al cliente adopta una herramienta de IA para resumir tickets. El DPA debe explicar que el proveedor trata el contenido de los tickets siguiendo instrucciones documentadas, lo protege, colabora en las solicitudes de acceso (DSARs), controla a los subencargados y suprime o devuelve los datos al finalizar el contrato.
Una firma de servicios profesionales conecta una herramienta de búsqueda con IA a su repositorio de documentos. El DPA debe establecer límites claros en cuanto a la indexación, los controles de acceso, los registros, la retención, los subencargados y si los documentos se utilizan para mejorar algún modelo fuera de las instrucciones de la firma.
Un equipo de recursos humanos prueba una herramienta de IA para tomar notas. Antes de su implantación, la organización debe verificar si se capturan datos personales de empleados, candidatos o clientes, si podrían aparecer datos de categoría especial en las transcripciones y si el DPA permite la recuperación, supresión y atención de solicitudes de acceso.
Malentendidos frecuentes
Un DPA significa que el proveedor es seguro. No es así. Es un control más. Siguen siendo necesarias las comprobaciones de idoneidad, la revisión de seguridad, la configuración, las normas de uso y la gobernanza del flujo de trabajo.
Todos los proveedores de SaaS son encargados del tratamiento. No siempre. Algunos proveedores pueden ser responsables para determinadas finalidades, encargados para otras o corresponsables en situaciones concretas. El papel depende del tratamiento real.
El contrato principal es suficiente. Es posible que el contrato principal no incluya las cláusulas específicas del UK GDPR necesarias para el tratamiento por parte de un encargado.
Los subencargados son solo un problema del proveedor. El encargado necesita autorización y condiciones escritas con los subencargados, pero el responsable debe igualmente conocer la cadena en los flujos de trabajo de IA relevantes.
La supresión es automática. La gestión al finalizar el contrato debe ser explícita. Las copias de seguridad, los registros, los índices y los registros derivados pueden requerir atención por separado.
Riesgos y límites
El mayor riesgo es la confusión de roles. Si la organización asume que el proveedor de IA es únicamente un encargado, pero el proveedor determina sus propias finalidades para algunos datos, el contrato puede no ajustarse a la realidad. Otro riesgo es el control débil de los subencargados, especialmente cuando los servicios de IA dependen de múltiples proveedores de infraestructura, modelos y analítica.
También existe un riesgo derivado de la configuración. Un DPA puede contener las cláusulas correctas mientras que los ajustes del producto permiten la retención de datos, el entrenamiento, un acceso administrativo amplio o integraciones no gestionadas. La revisión contractual debe ir acompañada, por tanto, de una revisión técnica y del flujo de trabajo.
Un DPA no hace que el tratamiento de alto riesgo sea lícito por sí solo. No sustituye a una base jurídica, un aviso de privacidad, una DPIA cuando sea necesaria, la minimización de datos, las pruebas de seguridad ni la supervisión humana. Este artículo no constituye asesoramiento jurídico y no debe utilizarse como sustituto de la revisión de contratos reales.
Otro límite es el intercambio entre responsables. Si un proveedor determina sus propias finalidades para algunos datos, un DPA de encargado puede no ser el instrumento adecuado para esa parte de la relación. La organización puede necesitar un análisis separado de transparencia, base jurídica e intercambio de datos. Por eso, la revisión del proveedor debe preguntar qué hace el proveedor con los prompts, los archivos, los metadatos, los registros de uso y los comentarios, y no solo si existe un DPA estándar.
Próximos pasos
Elabore una lista de verificación sencilla para la incorporación de proveedores de herramientas de IA que traten datos personales. Recoja el flujo de trabajo propuesto, las categorías de datos, las personas afectadas, el papel del proveedor, la ubicación de los datos, los subencargados, la retención, las condiciones de uso para entrenamiento, el soporte para DSARs, el soporte ante brechas y el proceso de supresión.
A continuación, vincule cada proveedor de IA aprobado a su Registro de Actividades de Tratamiento (ROPA). Cuando el flujo de trabajo sea relevante, mantenga juntos el DPA, la documentación de seguridad y las notas de configuración. El objetivo no es generar papeleo por sí mismo, sino garantizar que el equipo operativo pueda responder preguntas básicas antes de que la herramienta quede integrada en el trabajo diario.
Utilice preguntas directas durante la contratación. ¿Nuestros datos se usarán para entrenar o mejorar modelos compartidos? ¿Dónde se almacenan? ¿Quién puede acceder a ellos? ¿Qué subencargados intervienen? ¿Cómo recuperamos datos para una solicitud de acceso (DSAR)? ¿Cómo suprimimos prompts, resultados, registros e índices? Un proveedor que no pueda responder a estas preguntas puede seguir siendo utilizable para trabajos de bajo riesgo, pero no debería integrarse discretamente en flujos de trabajo sensibles.
Revise los resultados de la negociación, no solo los documentos. Si el proveedor modifica una cláusula de uso de datos, añade un nuevo subencargado, activa un ajuste de retención o lanza una función de mejora de modelos, el registro operativo debe actualizarse y el responsable del negocio debe conocer los cambios antes de que el personal dependa de la herramienta.
¿Tiene alguna pregunta o sugerencia, o desea saber cómo investigamos y revisamos estas guías? Lea sobre nuestros estándares editoriales y cómo contactarnos.
Preguntas frecuentes
¿DPA significa Acuerdo de Procesamiento de Datos o Data Protection Act?
Puede significar ambas cosas. En este artículo significa Acuerdo de Procesamiento de Datos (Data Processing Agreement). Al hablar de la legislación del Reino Unido, conviene escribir Data Protection Act 2018 completo para evitar confusiones.
¿Cuándo se necesita un Acuerdo de Procesamiento de Datos?
Se necesita un contrato escrito u otro acto jurídico cuando un responsable utiliza un encargado para tratar datos personales en su nombre.
¿Cubre un DPA el entrenamiento de modelos de IA?
Debe cubrir cualquier tratamiento de datos personales por parte del proveedor. Si los prompts, documentos o resultados pueden utilizarse para mejorar modelos, la organización debe revisar si eso se ajusta al papel, la finalidad y las instrucciones acordadas.
¿Podemos aceptar el DPA estándar de un proveedor?
En ocasiones sí, pero igualmente debe revisarse en relación con el flujo de trabajo real. Las condiciones estándar pueden ser aceptables para usos de bajo riesgo e insuficientes para tratamientos sensibles o de alto impacto.
¿Es suficiente un DPA para las transferencias internacionales?
No. Si los datos personales se transfieren fuera del Reino Unido, también pueden ser necesarias salvaguardas de transferencia adecuadas. El DPA debe revisarse junto con la situación relativa a las transferencias.