¿Puedo usar ChatGPT en mi empresa con datos de clientes?

La pregunta ya no es teórica. En casi cualquier empresa hay alguien usando ChatGPT, Copilot o un asistente equivalente con información que no es suya: expedientes de clientes, correos internos, documentos de trabajo. Normalmente sin que nadie lo haya autorizado, y a menudo sin que la dirección lo sepa.

¿Puede tu empresa usar ChatGPT con datos de clientes? La respuesta honesta es: depende de cómo lo uses, y es una pregunta que solo puede responder tu asesoría legal mirando tu caso concreto. Lo que sí se puede explicar es qué preguntas hay que responder — y por qué la mayoría de las empresas no las han respondido todavía.

Aviso: este artículo explica el marco general del RGPD aplicado al uso de herramientas de IA. No es asesoramiento jurídico ni una calificación de tu caso. Cualquier decisión sobre licitud de un tratamiento concreto corresponde al responsable del tratamiento con su asesoría legal.

Las dos preguntas que hay que separar

El error más común es tratar esto como un único problema. Son dos capas independientes, y superar la primera no exime de la segunda.

Capa 1 — ¿Se puede tratar ese dato? Toda operación con datos personales necesita una base que la legitime, y debe respetar los principios del RGPD: limitación de la finalidad, minimización, transparencia. Esta capa aplica aunque el dato no salga de España.

Aquí, “nos hace más eficientes” no es una respuesta. Y hay categorías de datos — salud, ideología, origen, orientación sexual, entre otras del artículo 9 — que tienen un régimen considerablemente más estricto.

Capa 2 — ¿Puede ese dato salir de la Unión Europea? Esta es una capa adicional. Si el proveedor de IA procesa fuera del Espacio Económico Europeo, la salida del dato necesita su propio mecanismo que lo ampare.

Existen varias vías previstas para ello: decisiones de adecuación de la Comisión sobre un país determinado, cláusulas contractuales tipo, normas corporativas vinculantes, y excepciones puntuales del artículo 49 que son estrechas y no sirven para flujos sistemáticos.

Cuál de esas vías ampara hoy a un proveedor concreto, y en qué condiciones, es algo que debes verificar con tu asesoría legal en el momento de decidir. Y hay una razón estructural para no darlo por hecho: los marcos que han regulado la transferencia de datos entre la Unión Europea y Estados Unidos han sido invalidados por el Tribunal de Justicia de la UE en más de una ocasión. Construir la estrategia de datos de una empresa sobre la vigencia de un mecanismo concreto es construir sobre algo que ya ha cambiado antes.

Las preguntas que casi nadie ha respondido

Cuando un empleado copia el expediente de un cliente en ChatGPT para redactar una respuesta, se están procesando datos personales de ese cliente con una herramienta externa.

• ¿Está contemplado en tu política de privacidad?
• ¿Lo sabe el cliente?
• ¿Qué base legitima ese tratamiento?
• ¿Se ha valorado si procede una evaluación de impacto?
• ¿Quién ha autorizado esa herramienta, y con qué alcance?

En la mayoría de las empresas, nadie ha respondido a ninguna. No por negligencia — sino porque el uso empezó por abajo, de forma individual, sin pasar por ninguna decisión formal.

Tres tipos de dato, tres conversaciones distintas

Datos de empleados. Evaluaciones de desempeño, comunicaciones internas, información de nómina o de salud laboral. El tratamiento de datos en el contexto laboral tiene reglas propias y, según el caso, puede implicar obligaciones de información a la representación de los trabajadores. Es un terreno donde la improvisación sale cara.

Información de clientes. Cuando el equipo comercial pega datos del CRM para redactar una propuesta, o atención al cliente resuelve tickets con un asistente, esa información está siendo procesada por un tercero. Si tu política de privacidad hacia el cliente no lo menciona, tienes una brecha de transparencia con él, independientemente de lo demás.

Documentos internos confidenciales. Aquí el problema puede no ser de protección de datos en absoluto. Estrategia comercial, contratos, propiedad intelectual: información que quizá no identifica a nadie, pero cuya salida es igualmente un problema. Volveremos sobre esto, porque es la distinción más importante del artículo.

Por qué una política interna no es un control

“Prohibido pegar datos de clientes en ChatGPT” en el reglamento interno es una declaración de intenciones. No es un control.

Y la razón es simple: si el tratamiento sigue siendo técnicamente posible, va a seguir ocurriendo. No por mala fe, sino porque el empleado tiene una fecha de entrega y la herramienta está a un clic. La política solo cambia quién carga con la responsabilidad cuando algo salga mal — no cambia lo que ocurre.

Una política sin control técnico deja a la empresa en la peor posición posible: con la exposición intacta y con un documento que demuestra que era consciente de ella.

El argumento que cambia el problema de sitio

Y aquí está lo importante, porque no es una cuestión de grado sino de naturaleza.

Toda la capa 2 — los mecanismos de transferencia, las evaluaciones, los contratos — existe porque el dato sale. Es maquinaria construida para legitimar una salida.

Si el dato personal no sale, esa maquinaria no hace falta. No es que el problema se gestione mejor: es que no llega a plantearse. No hay transferencia internacional que amparar cuando lo que cruza la frontera no permite identificar a nadie.

Esa es la diferencia entre un compromiso contractual y una propiedad de la arquitectura. Un contrato promete que el otro se portará bien con tu dato. Una arquitectura donde el dato no sale no necesita esa promesa.

El límite: anonimizar no lo resuelve todo

Y esto hay que decirlo con claridad, porque es donde la mayoría de los proveedores prometen de más.

Anonimizar resuelve el problema de protección de datos. No resuelve el de secreto profesional ni el de soberanía del dato.

La razón es precisa: el secreto profesional —el del abogado, el del médico, el del asesor fiscal— protege por categoría de información, no por si esa información identifica a alguien. Un contrato del que se han quitado todos los nombres, todos los DNI y todas las referencias identificables sigue estando amparado por secreto profesional, porque su contenido pertenece a una categoría protegida. Quitarle la identidad al dato no le quita su naturaleza.

Lo mismo aplica a la soberanía: cuando la obligación es que cierta información no salga de una jurisdicción, esa obligación mira la categoría del dato, no su identificabilidad.

Para esos casos, la anonimización se queda corta y la única respuesta consistente es que el dato no salga en absoluto de la infraestructura donde ya está.

Qué hacer, en orden

1. Saber qué está pasando hoy. Qué herramientas de IA se usan realmente, quién las usa, con qué datos. No lo que dice la política — lo que ocurre.
2. Clasificar por tipo de dato. Empleados, clientes y documentos confidenciales plantean preguntas distintas y no se resuelven igual.
3. Consultar la parte legal con quien corresponde. Base de licitud, transparencia, si procede evaluación de impacto. Eso lo determina tu asesoría, no un proveedor de software.
4. Poner un control técnico, no solo documental, para que la protección no dependa de que nadie se equivoque.
5. Actualizar las políticas para que reflejen lo que de verdad se hace.

El orden importa. Los pasos 3 y 4 no se pueden hacer bien sin el 1: no se puede decidir sobre lo que no se conoce.

---

Ese primer paso — saber qué está saliendo hoy y por qué vía — es lo que hacemos en el Diagnóstico de exposición de datos en IA: un informe con hechos verificados, no con suposiciones, para que la conversación legal parta de datos reales.

Y si lo que buscas es el control técnico, Privedge intercepta los datos personales antes de que salgan hacia el proveedor de IA — con modo edge para la información que directamente no puede salir de tu infraestructura.