Evaluación de proveedores de chatbots: DPA, subencargados del tratamiento y transferencias internacionales de datos

Un proveedor de chatbots puede ofrecer una demostración convincente, una región dentro de la UE y un contrato de encargo del tratamiento redactado, y aun así dejar preguntas cruciales sin respuesta. Esto se debe a que el chatbot visible no es el único que procesa datos. Con frecuencia, las API de modelos, el alojamiento, las bases de datos vectoriales, el análisis de errores, las herramientas de soporte, los servicios de correo electrónico y las copias de seguridad participan en la prestación del servicio. Para los titulares de sitios web, lo que cuenta es la cadena de tratamiento verificable, no la consigna de protección de datos en una página de ventas.

Esta lista de comprobación ayuda a realizar una evaluación estructurada del proveedor antes de la compra y la puesta en marcha. Sirve como orientación práctica y no constituye asesoramiento legal. Los roles, las bases jurídicas, las obligaciones de información y los mecanismos de transferencia deben evaluarse para el caso de uso concreto; en caso de riesgo elevado, categorías especiales de datos o cuestiones contractuales abiertas, se debe consultar al delegado de protección de datos o a asesores jurídicos cualificados.

Comprender primero el flujo de datos antes de evaluar el contrato

La pregunta central no es solo «¿Dónde está el servidor?», sino: ¿qué datos personales llegan a qué persona jurídica, cuándo, por qué motivo y durante cuánto tiempo? Un visitante puede introducir en el chat nombres, direcciones de correo electrónico, números de cliente o texto libre. Además, se generan direcciones IP, marcas de tiempo, información sobre el dispositivo, identificadores de sesión, historiales de conversación, valoraciones y registros técnicos. Incluso a partir de una conversación supuestamente anónima, la combinación de varios atributos puede dar lugar a un vínculo con una persona física.

Por lo tanto, trace un mapa sencillo de flujo de datos antes de revisar el contrato. Este debe incluir al menos el widget del navegador, la plataforma del chatbot, la base de conocimientos, el proveedor del modelo, los servicios de análisis y errores, el acceso de soporte, las copias de seguridad y las rutas de supresión. Para cada etapa, registre el operador, el país, la finalidad, las categorías de datos, el periodo de conservación y las posibles conexiones remotas. Por ejemplo, una afirmación sobre «alojamiento en la UE» no responde a si un equipo de soporte fuera del Espacio Económico Europeo puede acceder a registros de producción.

Determinar las funciones de protección de datos según la finalidad

El hecho de que un proveedor actúe como encargado del tratamiento o como responsable del tratamiento para finalidades específicas depende de sus actividades reales. Las Directrices 07/2020 del Comité Europeo de Protección de Datos explican esta distinción. Un proveedor puede procesar datos de conversación siguiendo instrucciones documentadas, pero reclamar una función diferente para determinados fines propios de seguridad, facturación o desarrollo de productos. Exija la asignación explícita de cada finalidad, su función correspondiente y su base jurídica. Un DPA (acuerdo de encargo del tratamiento) no cubre automáticamente las finalidades independientes del proveedor.

Revisar el DPA: el contenido obligatorio debe ajustarse al servicio real

El Artículo 28 del RGPD exige que los responsables del tratamiento elijan únicamente encargados que ofrezcan garantías suficientes para aplicar medidas técnicas y organizativas apropiadas. El contrato debe estipular, entre otras cosas, el objeto y la duración, la naturaleza y la finalidad, el tipo de datos, las categorías de interesados, así como los derechos y obligaciones del responsable. A esto se suman las instrucciones documentadas, la confidencialidad, la seguridad, la asistencia en los derechos de los interesados y las obligaciones de protección de datos, la supresión o devolución, así como la información y colaboración para la realización de auditorías.

No se limite a comparar el DPA con una lista de verificación estándar; contrástelo con su mapa de flujo de datos y el plan contratado. Un buen contrato describe con claridad el funcionamiento del chat, el entrenamiento o la indexación de la base de conocimientos, el registro de actividad, los accesos de soporte y las funciones opcionales. Los términos genéricos e imprecisos como «mejora del servicio» deben desglosarse en datos, finalidades, opciones de configuración y funciones específicas.

• Instrucciones: ¿Queda claro que los contenidos y los metadatos se procesan únicamente para los fines documentados del cliente? ¿Qué configuración se considera una instrucción?
• Uso para modelos: ¿Se utilizan los prompts, respuestas o archivos subidos para el entrenamiento general de modelos o la mejora de productos? En caso negativo, esto debe ser verificable contractual y técnicamente; en caso afirmativo, la función y la base jurídica deben evaluarse por separado.
• Supresión: ¿Existen plazos concretos para el historial de conversaciones, registros, índices vectoriales, copias de seguridad y copias de soporte? ¿Qué ocurre al finalizar el contrato?
• Seguridad: ¿Se describen los controles de acceso, la separación entre clientes, el cifrado, el registro de actividad, la gestión de vulnerabilidades y los procedimientos de respuesta a incidentes?
• Asistencia: ¿Regula el DPA de forma práctica las exportaciones, rectificaciones, supresiones, accesos, incidentes de seguridad y, si procede, la evaluación de impacto relativa a la protección de datos (EIPD)?
• Evidencias: ¿Se dispone de informes de auditoría, certificaciones u otras pruebas fehacientes, y se aplican exactamente a los servicios y ubicaciones utilizados?

Los certificados y los informes de auditoría pueden proporcionar información valiosa, pero no sustituyen el examen de la operación de tratamiento concreta ni la existencia de cláusulas contractuales adecuadas. Incluso un DPA estandarizado es tan bueno como sus anexos cumplimentados y su coincidencia con la realidad técnica.

Subencargados del tratamiento: controlar nombres, funciones y cambios

De acuerdo con el artículo 28, apartado 2, del RGPD, el encargado del tratamiento no recurrirá a otro encargado sin la autorización previa por escrito, específica o general, del responsable. En caso de autorización por escrito general, el encargado informará de cualquier cambio previsto en la incorporación o sustitución de otros encargados, dando así la oportunidad de oponerse. Las Preguntas y respuestas de la Comisión Europea sobre las cláusulas contractuales tipo aclaran asimismo que las meras categorías no son suficientes: deben identificarse los subencargados individuales.

Exija una lista actualizada y exportable con el nombre jurídico, el país, el servicio específico prestado y los datos afectados. Compruebe también si una empresa es solo una parte contratante o si realmente realiza el tratamiento en múltiples ubicaciones. Especialmente relevantes son los proveedores de modelos y embeddings, el alojamiento en la nube, las bases de datos, las CDN, el monitoreo, la analítica de errores, el soporte, el correo electrónico y las copias de seguridad. Para cada registro, debe ser evidente si los datos se almacenan, simplemente se transmiten o si el personal puede acceder a ellos.

El proceso de modificación también debe formar parte de la evaluación: ¿cómo se notifica a los clientes, con qué antelación y qué ocurre si hay una objeción justificada? Un correo electrónico enviado el mismo día del cambio sin posibilidad de respuesta técnica o contractual tiene escaso valor. Aclare si es posible una configuración alternativa, la desactivación de la función o, si es necesario, una rescisión ordenada que incluya la exportación de datos. Para los subencargados ulteriores, deben aplicarse las mismas obligaciones de protección de datos; el encargado principal sigue siendo responsable ante el responsable del tratamiento del cumplimiento de dichas obligaciones.

Transferencias a terceros países: verificar el mecanismo y su eficacia real

El Capítulo V del RGPD regula las transferencias de datos personales a terceros países y las transferencias ulteriores. Una transferencia no solo se produce mediante el almacenamiento permanente; el acceso administrativo, el soporte técnico o la consulta por parte de un servicio fuera del EEE también pueden ser relevantes. Por tanto, asigne a cada flecha de su mapa de flujo de datos un país de destino, un destinatario y un mecanismo de transferencia.

1. Decisión de adecuación: Consulte la lista de la Comisión Europea en constante actualización para verificar si la decisión, el territorio, el sector y el destinatario concreto están cubiertos. En el caso de marcos limitados, la mera presencia de una filial en un país no es suficiente.
2. Garantías adecuadas: A falta de una decisión de adecuación pertinente, se pueden considerar instrumentos del artículo 46 del RGPD según el caso. Con frecuencia se utilizan las cláusulas contractuales tipo de la Comisión Europea. El módulo, las partes, los anexos, la descripción de la transferencia y las medidas técnicas deben corresponderse con la cadena real.
3. Evaluación de eficacia: La firma de unas CCT no concluye automáticamente la evaluación. Las Recomendaciones 01/2020 definitivas del CEPD describen un proceso basado en el riesgo: conocer las transferencias, determinar el instrumento, evaluar la legislación y la práctica del tercer país, definir medidas complementarias si es necesario, adoptar los trámites formales y realizar evaluaciones periódicas.

Las medidas técnicas complementarias deben ser proporcionales al riesgo específico. El cifrado, por ejemplo, solo es efectivo si se tienen en cuenta la gestión de claves, los derechos de acceso y la finalidad del tratamiento. Un proveedor de modelos que necesita procesar texto plano y que tiene acceso a las claves presenta una situación muy diferente a la de un almacenamiento de copias de seguridad meramente cifrado. Afirmaciones genéricas como «AES-256» o «compatible con el RGPD» no sustituyen este análisis. Las excepciones del artículo 49 del RGPD tampoco constituyen un mecanismo habitual para el tratamiento recurrente y planificado en modalidad SaaS.

Ejemplo práctico: Región de la UE con una cadena de servicios global

Supongamos que la base de datos principal de un chatbot está alojada en Fráncfort. Sin embargo, las respuestas son generadas por la API de un modelo de una empresa estadounidense, los informes de errores se envían a otro servicio y un equipo global de soporte puede abrir los registros de conversación durante una escalación. En este escenario, hablar de «almacenamiento de datos en la UE» solo describe una parte del sistema.

La due diligence diferencia cuatro preguntas clave: ¿qué contenidos salen del EEE para la generación del modelo? ¿Se almacenan los prompts o se usan para otros fines en ese destino? ¿Los informes de errores contienen datos en texto plano, identificadores o únicamente datos técnicos minimizados? ¿Bajo qué condiciones puede acceder el equipo de soporte situado fuera del EEE? Solo tras responder a esto se pueden evaluar el instrumento de transferencia, las medidas complementarias y el riesgo residual.

Desde el punto de vista técnico, el titular del sitio web a menudo puede mitigar el riesgo: desactivando campos de registro innecesarios, enmascarando o anonimizando las entradas antes de realizar llamadas externas, estableciendo plazos de conservación cortos, separando las áreas sensibles del bot público, aislando las fuentes de conocimiento por cliente y registrando los accesos de soporte sujetos a aprobación. Para saber cómo separar de manera limpia un bot público de un portal de clientes, consulte el artículo Chatbot de IA público frente a portal de clientes. Para archivos subidos, la lista de comprobación sobre inspección de archivos, protección de datos y transferencia a agentes complementa la evaluación de proveedores.

Toma de decisiones mediante semáforo en lugar de intuiciones

Punto de control	Verde	Amarillo	Rojo
Flujo de datos	Completo, actualizado y adaptado al plan	Accesos o ubicaciones puntuales pendientes	Mera declaración de marketing sobre la región de la UE
DPA	Finalidades, datos, plazos y asistencia concretados	Requiere correcciones antes del lanzamiento	Sin vinculación clara a instrucciones o supresión
Subencargados	Lista nominal con país y función detallada	Proceso de notificación poco práctico	Solo categorías genéricas o cadena desconocida
Transferencia internacional	Mecanismo, alcance y evaluación documentados	Medidas aún por verificar	El «servidor en la UE» pretende justificar todo
Operativa	Responsable asignado, revisión programada y salida probada	Evidencias sin revisión periódica fija	Sin supervisión tras la firma del contrato

Un punto amarillo no implica rechazar automáticamente al proveedor, pero requiere asignar un responsable, un plazo y un criterio de aceptación verificable. Un punto rojo en una etapa central de la cadena de tratamiento debería bloquear el lanzamiento en producción hasta que el contrato, la configuración o la elección del proveedor se hayan corregido. Documente también los riesgos residuales aceptados y la persona que asumió dicha decisión.

Lista de comprobación rápida para la puesta en marcha

• El mapa de flujo de datos y las funciones asociadas a cada finalidad están aprobados.
• El DPA y sus anexos se ajustan al plan, las funciones, las categorías de datos y los plazos de conservación.
• Todos los subencargados están documentados por su nombre, país, función y procedimiento de notificación de cambios.
• Cada transferencia a un tercer país cuenta con un mecanismo adecuado y actualizado, así como con medidas complementarias si se requieren.
• El uso de datos para entrenamiento de modelos u otros fines propios del proveedor está aclarado y configurado según lo acordado.
• Los registros de actividad, accesos de soporte, exportación de datos, supresión y fin de contrato han sido probados en la práctica.
• La política de privacidad y la interfaz del chat explican el tratamiento de forma clara; se evita instar al usuario a introducir datos sensibles innecesarios.
• Se ha evaluado si el caso de uso específico requiere realizar una evaluación de impacto relativa a la protección de datos (EIPD).
• Un responsable interno supervisa las modificaciones en los subencargados, los mecanismos de transferencia, las funciones y las evidencias de seguridad.

Adicionalmente, se recomienda revisar la guía general sobre Chatbots de IA y el RGPD, así como las instrucciones para implementar analítica de chatbots con minimización de datos. De este modo, la contratación, la configuración técnica y la operación continua no se gestionan como proyectos aislados.

Seguimiento continuo tras la firma del contrato

La due diligence no finaliza tras guardar un documento PDF. Establezca al menos un ritmo de revisión periódico y evaluaciones basadas en eventos. Los desencadenantes pueden ser la adición de nuevos subencargados, un cambio en el proveedor del modelo, nuevas funcionalidades, modificaciones en las ubicaciones de almacenamiento, un incidente de seguridad, el vencimiento de certificaciones o cambios en una decisión de adecuación. La lista actual de subencargados y las versiones contractuales clave deben archivarse con fecha para garantizar la trazabilidad.

El criterio práctico es sencillo: ¿puede su equipo explicar, para cada flujo de datos relevante, quién procesa qué, por qué motivo, dónde ocurre, cuánto tiempo se conservan los datos, qué medida de protección se aplica y cómo funciona el plan de salida? Cuando estas respuestas están respaldadas con pruebas, las afirmaciones generales sobre protección de datos se transforman en una decisión de compra sólida. Si alguna etapa clave sigue siendo desconocida, el chatbot no debería operar todavía con datos de visitantes reales.