← Blog

IA y RGPD: dónde acaban los datos de tu empresa cuando usas un asistente

Hay una reunión que se repite. Las dos primeras van bien: el equipo ve el asistente funcionando, entiende para qué sirve, se entusiasma. En la tercera aparece alguien de administración, o el asesor externo, y hace la pregunta que congela el proyecto: «¿pero esto cumple el RGPD?».

Es una pregunta mal formulada, y por eso se responde mal. El RGPD no aprueba ni suspende herramientas: regula tratamientos. La misma herramienta puede ser perfectamente legal en una empresa y una infracción en la de al lado, según qué datos le metas, con qué finalidad y qué papeles hayas firmado. Así que la pregunta útil no es si algo «cumple». Es esta otra: dónde acaban exactamente nuestros datos, quién responde si salen mal parados, y qué pasa el día que alguien pida que le borremos.

Lo que sigue es lo que me preguntan los clientes y lo que yo tengo que poder responder por escrito. No soy abogado y esto no es asesoramiento jurídico: es la lista de lo que hay que tener resuelto antes de firmar nada.

1. El responsable sigues siendo tú

Este es el malentendido de fondo. Cuando contratas un asistente de IA, tu empresa sigue siendo la responsable del tratamiento: decides qué datos se tratan y para qué. El proveedor es el encargado: trata esos datos por tu cuenta y siguiendo tus instrucciones. Contratar no delega la responsabilidad; la reparte, y la parte que no se va a ninguna parte es la tuya.

De ahí sale la primera obligación concreta: el artículo 28 del RGPD exige un contrato de encargo de tratamiento entre ambos. No es un trámite ni una cláusula suelta en las condiciones generales: es un documento con contenido tasado —objeto, duración, naturaleza y finalidad del tratamiento, tipos de datos, categorías de interesados, obligaciones de seguridad, destino de los datos al terminar—. Si un proveedor no te lo ofrece firmado, no es que tenga un papeleo pendiente: es que estás cediendo datos personales sin base para hacerlo. El nuestro está publicado y se puede leer entero antes de hablar de precios, que es como creo que debería estar siempre.

Y una consecuencia incómoda de ser el responsable: ante la Agencia Española de Protección de Datos y ante tus propios empleados, respondes tú primero. Que el fallo fuera del proveedor es un asunto entre tu proveedor y tú.

2. La cuenta gratuita de tu equipo ya es un problema

Antes de preocuparte por el proveedor que vas a contratar, mira lo que ya está pasando. En casi todas las empresas de 20 a 150 personas hay gente pegando información en herramientas de IA con su cuenta personal: un contrato para que se lo resuman, un correo de un cliente para que se lo reescriban, una tabla con nombres para que la ordene.

Eso es una cesión de datos a un tercero sin contrato de encargo, sin control de retención y sin registro de qué salió. Se le llama shadow AI y es, hoy, el riesgo más habitual y menos vigilado. Tiene además una asimetría cruel: es invisible hasta que deja de serlo. Nadie se entera de nada hasta que un cliente pregunta por qué su documentación aparece donde no debe.

Lo relevante para esta conversación: prohibirlo por circular no funciona: la gente usa esas herramientas porque le resuelven el trabajo. Dar una vía oficial que funcione igual de bien es lo único que lo reduce de verdad. Un proyecto de IA bien planteado no añade riesgo de protección de datos; canaliza el que ya tenías suelto.

3. «¿Entrenáis con nuestros datos?» es media pregunta

Es la pregunta estrella y casi siempre recibe un «no» tranquilizador que no cubre lo que crees. «No entrenamos con vuestros datos» puede ser verdad y aun así dejar fuera tres cosas que importan igual:

  • La retención. Aunque no se entrene, ¿cuánto tiempo se conservan las consultas? Muchos proveedores guardan un histórico durante días o semanas para detectar abusos. Es legítimo, pero tiene que estar dicho y acotado.
  • Los subencargados. Tu proveedor casi con seguridad se apoya en otros: alojamiento, modelos de terceros, herramientas de soporte. El RGPD te da derecho a saber quiénes son y a oponerte a los cambios. Pide la lista, con nombre y función de cada uno.
  • El soporte humano. ¿Puede un técnico del proveedor leer vuestras conversaciones para resolver una incidencia? Si la respuesta es sí —y a veces tiene que serlo—, que quede registrado igual que cualquier otro acceso.

Formula la pregunta completa: quién puede ver esto, durante cuánto tiempo, y dónde queda constancia de que lo vio.

4. Dónde se procesa, no dónde está la sede

Que un proveedor tenga sociedad en España no significa que tus datos se queden en España. Lo que cuenta es dónde se procesan de verdad, incluidos los modelos de IA que se llaman por debajo.

Si hay tratamiento fuera del Espacio Económico Europeo, hace falta un mecanismo de transferencia válido: una decisión de adecuación de la Comisión Europea para ese país, o cláusulas contractuales tipo con su correspondiente análisis de riesgo. No es imposible ni raro —se hace todos los días—, pero tiene que estar documentado, y el terreno se mueve: lo que hoy se ampara en una decisión de adecuación puede requerir otra cosa mañana.

Pregunta concreta, y por escrito: en qué región se procesan los datos, qué modelos se invocan y bajo qué mecanismo si alguno sale del EEE. Una respuesta clara aquí te dice más del proveedor que cualquier certificación de la web.

5. Lo que no debería entrar nunca

El RGPD manda minimizar: tratar solo los datos necesarios para la finalidad. Aplicado a un asistente corporativo, esto se traduce en una decisión de arquitectura, no en una política de buenas intenciones.

Nóminas, evaluaciones de desempeño, datos de salud, expedientes disciplinarios: nada de eso tiene por qué vivir en el mismo buscador semántico que los manuales de producto y los procedimientos. Y no es solo una cuestión de principios. Cuando un dato sensible entra en un buscador por relevancia, el sistema hará su trabajo —encontrar lo más pertinente— sin distinguir quién pregunta. Lo conté en detalle aquí: la fuga más común de los asistentes corporativos no es un hackeo, es el diseño funcionando según lo previsto.

La regla práctica: si el dato no hace falta para responder preguntas de trabajo, no entra. Y si hace falta, entra con el permiso comprobado en el momento de buscarlo, no filtrado después.

6. La pregunta que casi nadie hace: ¿y si alguien pide que le borren?

Un empleado se va y ejerce su derecho de supresión. O un cliente pide que elimines sus datos. En un sistema clásico borras unas filas y listo. En un sistema de IA, ese dato ha podido convertirse en fragmentos vectorizados repartidos por un almacén de vectores, en un índice de búsqueda y en un histórico de conversaciones.

La posición prudente es la que yo aplico: si un vector se deriva de un documento con datos personales, tratarlo como si siguiera siendo un dato personal. Eso obliga a poder rastrear qué fragmentos vinieron de qué documento, borrarlos y reindexar, no solo a marcar el original como eliminado.

Haz esta pregunta en la demo y observa la cara. Es el mejor detector de si alguien ha pensado el ciclo de vida completo del dato o solo la parte bonita, la de la respuesta impecable. Va en la misma línea que las cinco preguntas que yo llevaría a cualquier reunión con un proveedor.

7. Lo que deberías tener por escrito antes de firmar

  • Contrato de encargo de tratamiento firmado, con el contenido del artículo 28.
  • Lista de subencargados, con función de cada uno y aviso previo de los cambios.
  • Región de procesamiento y, si hay salida del EEE, el mecanismo que la ampara.
  • Política de retención: qué se guarda, cuánto tiempo y con qué finalidad.
  • Procedimiento de supresión que alcance también a los datos derivados, con plazo y verificación.
  • Registro de accesos, incluidos los del propio proveedor durante el soporte.

Al margen del proveedor, del lado de tu empresa quedan otras dos: actualizar el registro de actividades de tratamiento para incluir este uso, y valorar con tu asesor si procede una evaluación de impacto, algo bastante probable cuando el tratamiento afecta a datos de empleados a cierta escala. Y hay una capa más, el Reglamento Europeo de IA, que se aplica por fases y que para un asistente interno se traduce sobre todo en obligaciones de transparencia y de formación de las personas que lo usan. Consúltalo con quien lleve vuestro cumplimiento; no es algo que deba decidir vuestro proveedor de software.

La parte que nadie te dice

Todo esto suena a fricción, y lo es. Pero es fricción que se paga una vez, al principio, y que además ordena el proyecto: obliga a decidir qué información entra, quién puede verla y durante cuánto tiempo. Son exactamente las mismas preguntas que hay que responder para que un asistente sea útil, no solo legal.

Por eso desconfío del proveedor que despacha esta conversación con un «tranquilo, cumplimos todo». Cumplir no es un estado que se tenga; es un conjunto de decisiones que se pueden enseñar. Las nuestras están escritas, y si detectas un hueco, prefiero que me lo digas tú antes que la Agencia.