Volver al blog
GDPREU AI ActComplianceData ProtectionAI GovernancePrivacyCybersecurity

Tu equipo probablemente está pegando datos de clientes en ChatGPT gratuito — y en la UE es ilícito

ChatGPT gratuito no es tu encargado del tratamiento: pegar datos de clientes es ilícito. Cómo detectarlo, una regla de uso, una checklist y qué hacer si pasó.

P
Davi Nunes
June 2, 2026Actualizado October 30, 202611 min de lectura

Alguien de tu empresa está haciendo esto ahora mismo: el email de queja de un cliente pegado en la versión gratuita de ChatGPT, con una cuenta personal, para pedir una respuesta educada. O un CSV de leads para priorizarlos, o una previsión de renovaciones con contactos identificados por su nombre.

En la UE eso es una comunicación ilícita de datos personales. A continuación tienes el motivo jurídico y, después, el kit para corregirlo: detección sin vigilancia, una regla de uso, una checklist de proveedores, un procedimiento ante incidentes, registros, EIPD y formación.

Por qué es ilícito: un chatbot gratuito no es tu encargado del tratamiento

Cuando otra organización trata datos personales por cuenta tuya, el artículo 28(3) del RGPD exige un contrato que obligue a ese encargado a seguir tus instrucciones documentadas, a la confidencialidad y la seguridad, a contar con tu autorización para los subencargados y a suprimir o devolver los datos al final.

Un chatbot gratuito de consumo no tiene ningún contrato así con tu empresa. Tu empleado aceptó unas condiciones de consumidor en su propio nombre, y con ellas es el proveedor quien decide cuánto tiempo se guarda la conversación, si su personal la revisa y si sirve para mejorar el modelo. Una organización que decide los fines del tratamiento es responsable del tratamiento por derecho propio, no tu encargado. Pegar en él el email de un cliente es comunicar datos a un tercero, y eso exige:

  • Una base jurídica del artículo 6 para entregar datos de clientes a un proveedor de IA para sus propios fines. No la tienes.
  • Compatibilidad con la finalidad para la que recogiste los datos (artículo 5(1)(b)). El cliente te escribió para resolver un pedido, no para alimentar un modelo.
  • Que ese destinatario figure en tu información de privacidad (artículo 13(1)(e)).
  • Un mecanismo de transferencia del capítulo V si el tratamiento se hace fuera del EEE.

Si se hace sin autorización, suele ser además una violación de la seguridad de los datos personales: el artículo 4(12) incluye la comunicación no autorizada. El artículo 32(4) te obliga a tomar medidas para que quienes actúan bajo tu autoridad solo traten datos personales siguiendo tus instrucciones. La regla y la formación que vienen después son esas instrucciones. Un ajuste de privacidad en una cuenta de consumidor no cambia nada de esto: un ajuste no es un contrato, y pertenece al empleado.

Averigua si está pasando, sin espiar a nadie

Vigilar la navegación de cada empleado es desproporcionado, destruye la confianza que necesitas y, en varios Estados miembros, las herramientas de monitorización requieren antes la intervención del comité de empresa. Necesitas saber qué herramientas, qué equipos y qué volumen aproximado, no nombres. Explica a la plantilla por adelantado qué vas a mirar.

Pregunta primero. Haz una encuesta breve y anónima: qué herramientas de IA usa la gente en el trabajo, para qué tareas, con qué cuenta y qué datos introduce. Promete, y cumple, que las respuestas servirán para elegir herramientas aprobadas, no para sancionar a nadie.

Cuenta por dominio, no por persona. Pon los dominios de IA en ai-domains.txt, sacados de la categoría de IA generativa de tu web gateway o de tu filtro DNS si la tiene, o de las herramientas que aparecieron en la encuesta. Cuenta las peticiones por dominio y descarta la dirección del cliente. En el formato de log nativo de Squid, la URL es el séptimo campo:

bash
# Requests per AI domain over the log period. No user or client IP is kept.
awk '{print $7}' /var/log/squid/access.log \
  | sed -E 's#^https?://##; s#[:/].*$##' \
  | grep -F -f ai-domains.txt \
  | sort | uniq -c | sort -rn

Los logs de consultas de tu resolvedor DNS funcionan igual.

Revisa las extensiones del navegador. Los asistentes de redacción y los resumidores con IA suelen funcionar como extensiones que pueden leer cualquier web que abra el usuario, CRM y webmail incluidos. Busca en el inventario de extensiones de tu gestión de dispositivos cualquiera con acceso a todos los sitios web. En los navegadores basados en Chromium, impón una lista de extensiones permitidas mediante política gestionada:

json
{
  "ExtensionInstallBlocklist": ["*"],
  "ExtensionInstallAllowlist": ["<approved-extension-id>"]
}

Revisa altas y consentimientos de aplicaciones. Hay dos sitios que muestran las altas en herramientas de IA sin leer el correo de nadie: el seguimiento de mensajes de tu pasarela de correo (mensajes de bienvenida y de verificación, contados por dominio remitente contra la misma lista) y las aplicaciones de terceros a las que los usuarios han dado consentimiento en tu proveedor de identidad. Los asistentes que toman notas en reuniones y los asistentes de bandeja de entrada con acceso al correo y al calendario van primero.

La regla de una página: qué datos van a qué herramienta

Una regla que la gente cumple cabe en una página y funciona en los cinco segundos antes de pegar. Tres tipos de herramienta:

  • Herramientas de consumo: chatbots gratuitos o de plan personal, extensiones y apps con cuentas personales, sin contrato con tu empresa.
  • Herramientas empresariales aprobadas: un plan empresarial o una API que ha superado la checklist de abajo, usado con cuentas de empresa e inicio de sesión único.
  • Despliegues internos: un asistente que tus ingenieros construyeron sobre una API aprobada o un modelo autoalojado, con tu propio control de acceso y tus propios logs.

Después, seis clases de datos:

  • Públicos: lo ya publicado, como los textos de tu web o la documentación open source. Cualquier herramienta.
  • Internos: sin datos personales ni secretos de clientes, como un documento de procesos o código fuente no sensible. Herramientas empresariales aprobadas y despliegues internos.
  • Datos personales: cualquier cosa sobre una persona identificable: nombres, emails, teléfonos, IDs de cliente, direcciones IP, texto de tickets, capturas del CRM, un cargo junto con la empresa. Herramientas empresariales aprobadas y despliegues internos, para una finalidad que figure en tu registro de actividades de tratamiento, y minimizados antes: pega la queja, no la firma.
  • Categorías especiales y datos penales: salud, origen étnico, creencias, orientación sexual y las demás categorías del artículo 9, además de los antecedentes penales. Piensa en bajas médicas e investigaciones de RR. HH. Ninguna herramienta de IA salvo que una EIPD haya aprobado ese uso concreto.
  • Confidencial de clientes: lo que tus clientes te confiaron por contrato, como su código, su arquitectura o sus listas de clientes. Solo si el contrato con el cliente lo permite. Nunca en una herramienta de consumo.
  • Secretos: contraseñas, claves de API, claves privadas. Nunca, en ninguna herramienta. Rota todo lo que se haya pegado.

Sustituir nombres por códigos que puedes volver a asociar es seudonimización, y los datos seudonimizados siguen siendo datos personales. Solo quedan fuera del RGPD los datos que ya no pueden vincularse a una persona por medios que razonablemente puedan utilizarse, incluidas combinaciones como cargo, empresa y ciudad.

¿No sabes qué herramientas de IA usan ya tus equipos, o si las condiciones de los proveedores aguantan? Solicita una evaluación gratuita de gobernanza de IA: inventariamos las herramientas en uso, contrastamos cada una con la checklist de abajo y adaptamos la regla de una página a tus datos.

Antes de usar un plan empresarial o una API: la checklist

Un plan empresarial o una API resuelve el problema del artículo 28 solo si el contrato dice lo que necesitas. Compruébalo por escrito antes del despliegue y guarda las evidencias:

  • Contrato de encargado: que cubra el propio servicio de IA, no solo los demás productos del proveedor, con los términos del artículo 28(3).
  • Sin entrenamiento con tus datos: un compromiso contractual, y el comportamiento por defecto del plan, no una opción que cada usuario pueda activar o desactivar.
  • Conservación y revisión humana: cuánto tiempo se guardan los prompts y las respuestas, también para la supervisión de abusos, si el personal del proveedor puede leerlos, y la supresión cuando te vayas.
  • Dónde se hace el tratamiento: la "residencia de datos en la UE" a veces cubre los datos almacenados pero no el acceso de soporte ni la supervisión de abusos, así que lee el alcance. Todo lo que ocurra fuera del EEE necesita un mecanismo del capítulo V: una decisión de adecuación que cubra el destino, o cláusulas contractuales tipo con una evaluación de impacto de la transferencia.
  • Subencargados: una lista publicada, aviso previo de los cambios y derecho a oponerte (artículo 28(2)).
  • Controles de administración: inicio de sesión único, cuentas de empresa obligatorias y la posibilidad de desactivar funciones no evaluadas, como la navegación web, los conectores, la subida de ficheros y los enlaces públicos para compartir.
  • Logs: logs de auditoría exportables de inicios de sesión, cambios de administración y uso.
  • Notificación de violaciones: sin dilación indebida (artículo 33(2)), idealmente con un número de horas fijado.
  • Garantías de seguridad: un certificado ISO 27001 o un informe SOC 2 cuyo alcance incluya el servicio de IA.

La misma checklist se aplica cuando tus ingenieros llaman a un modelo mediante una API desde vuestro propio código, que es la vía que más control te da: eliges qué campos salen de tus sistemas y eliminas los datos sensibles antes de enviar. Las opciones de diseño están en nuestra guía de patrones de integración de LLM para aplicaciones empresariales; la parte de ataque, desde la inyección de prompts hasta un retrieval que filtra documentos, es lo que pone a prueba una revisión de seguridad de IA.

Datos ya pegados: un procedimiento para evaluar el incidente

Trata cada caso como una posible violación de la seguridad de los datos personales, sin buscar culpables: quien espera un castigo deja de avisar. El plazo de 72 horas del artículo 33(1) cuenta desde que la empresa tiene conocimiento. La decisión la toma tu DPD o tu asesor jurídico; este procedimiento le da los hechos.

  1. 1Reúne los hechos: qué se pegó, cuándo, en qué herramienta y plan, con qué cuenta y si existe un enlace para compartir.
  2. 2Contén: borra la conversación y cualquier enlace para compartir, y déjalo registrado. Borrarla del historial puede no suponer su supresión inmediata en el proveedor, así que anota lo que dicen sus condiciones sobre la conservación.
  3. 3Clasifica: de quién son los datos, cuántas personas, qué clases y si había datos de categorías especiales, financieros o de identidad.
  4. 4Si tratas los datos por cuenta de un cliente, eres su encargado: el artículo 33(2) te obliga a avisar al cliente sin dilación indebida, tu contrato puede fijar un plazo más corto y es el cliente quien decide si notifica a la autoridad.
  5. 5Evalúa: hay que notificar a la autoridad de control salvo que sea improbable que la violación constituya un riesgo para los derechos y libertades de las personas. Si es probable que entrañe un alto riesgo, también hay que informar a los afectados (artículo 34).
  6. 6Regístralo decidas lo que decidas. El artículo 33(5) exige documentar toda violación, se notifique o no.
  7. 7Corrige la causa: la herramienta que faltaba, la regla, la formación.

Dos ejemplos prácticos; solo tus propios hechos deciden. Un agente de soporte pega la queja de un cliente por un envío con retraso, con nombre y email, y la borra el mismo día: una persona, datos de contacto corrientes, nada que permita un fraude. Lo habitual es concluir que es improbable que constituya un riesgo: se registra y no se notifica. Una responsable de RR. HH. pega la baja médica de un empleado: datos de salud de una persona en situación de dependencia. Eso tiene muchas más probabilidades de requerir notificación en 72 horas, y quizá un mensaje al empleado.

Registro de actividades de tratamiento y cuándo necesitas una EIPD

Todo uso aprobado de IA que toque datos personales va en tu registro de actividades de tratamiento del artículo 30. La excepción para organizaciones de menos de 250 empleados no cubre el tratamiento que no es ocasional, y un asistente de soporte usado a diario no es ocasional. Una entrada con los campos del artículo 30(1):

yaml
activity: Drafting replies to customer support tickets with an AI assistant
controller: Your Company, privacy@example.com
dpo: dpo@example.com
purpose: Faster, consistent replies to customer support requests
data_subjects: [customers, prospects]
personal_data: [name, email, order number, ticket text]
excluded_data: [special-category data, payment card data, passwords]
recipients:
  - AI provider (processor, DPA signed <date>)
transfers: None. Processing in an EU region under the contract
retention: Provider deletes prompts and outputs after <N> days per contract
security: SSO, company accounts only, no-training clause, audit logs in SIEM

Una EIPD es obligatoria cuando un tratamiento, "en particular si utiliza nuevas tecnologías", entrañe probablemente un alto riesgo (artículo 35(1)), en los casos que enumera el artículo 35(3) y para todo lo que figure en la lista de tu autoridad de control según el artículo 35(4). Las orientaciones de los reguladores añaden señales de alerta, y dos o más suelen significar una EIPD: evaluar o puntuar a personas, datos sensibles, gran escala, combinación de conjuntos de datos, personas en posición más débil como los empleados, y tecnología innovadora. La IA generativa suele contar como innovadora, así que una señal más inclina la balanza.

  • Redactar respuestas de soporte: datos personales más tecnología nueva. Con mucho volumen eso es gran escala: haz la EIPD.
  • Un asistente de código sobre código interno sin datos personales: sin EIPD. Deja por escrito por qué.
  • Ordenar candidaturas de empleo: puntuar a personas en posición más débil con tecnología nueva, así que EIPD. Además entra en el ámbito de selección de personal que el Reglamento de IA considera de alto riesgo (anexo III), con obligaciones desde el 2 de diciembre de 2027. Eso es un proyecto, no un prompt.

Alfabetización en IA según el artículo 4: un plan de formación que puedas demostrar

El artículo 4 del Reglamento de IA se aplica desde el 2 de febrero de 2025 a los proveedores y responsables del despliegue de sistemas de IA de cualquier nivel de riesgo: deben adoptar medidas sobre la alfabetización en materia de IA de su personal y de otras personas que usan sistemas de IA en su nombre. El Digital Omnibus on AI, en vigor desde el 27 de julio de 2026, suavizó la redacción, pero la obligación de adoptar medidas sigue en pie. Una empresa que aprueba herramientas de IA para su personal es responsable del despliegue, y un plan documentado es la prueba más directa. Además sirve como tu instrucción del artículo 32(4) del RGPD.

  • Todas las personas con una herramienta de IA, una hora, al incorporarse y cada año: qué son estas herramientas (predicen texto plausible y pueden equivocarse con total seguridad), la regla de una página con tus propios ejemplos, cómo avisar de un pegado sin culpas y revisar cada respuesta antes de que llegue a un cliente.
  • Usuarios intensivos y responsables de equipo, media jornada: anonimizar en la práctica, detectar cuándo un uso necesita una EIPD y el artículo 50, que se aplica desde el 2 de agosto de 2026: las personas deben saber cuándo interactúan con un sistema de IA, así que un chatbot en tu web tiene que dejarlo claro.
  • Ingenieros que construyen con IA: inyección de prompts, control de acceso en el retrieval y datos personales en los logs de prompts.
  • Evidencias: registros de asistencia, la versión del material que vio cada persona, un cuestionario con casos prácticos, la regla firmada y la fecha del próximo repaso.

Preguntas de cuestionario para adaptar:

  • Un cliente envía por email una queja con su teléfono y su número de pedido. ¿Con qué herramienta redactas la respuesta y qué quitas primero?
  • Un cliente te envía su diagrama de arquitectura. ¿Puede revisarlo una herramienta de IA?
  • Has pegado por error el certificado médico de un empleado en un chatbot. ¿A quién avisas y en cuánto tiempo?

En resumen

Si no lo has comprobado, da por hecho que alguien de tu empresa lo está haciendo. La solución no es un correo pidiendo a la gente que pare. Es una herramienta aprobada que superó la checklist, una regla de una página, registros que reflejan la realidad, un procedimiento sereno ante incidentes y una formación que puedes demostrar. Nuestro servicio de gobernanza de IA construye exactamente ese conjunto.

¿Quieres saber dónde estás antes de que te lo pregunte un regulador o un cliente? Reserva una evaluación gratuita de gobernanza de IA: mapeamos las herramientas de IA en uso, revisamos sus condiciones, redactamos tu regla y tu registro de actividades de tratamiento, y acompañamos a tu DPD con cualquier dato que ya se haya pegado.