Hay una escena que se repite en casi todas las empresas con las que trabajamos, aunque nadie la cuente en la reunión de dirección. Un comercial pega en un chatbot el listado de clientes con nombres, teléfonos y facturación para que le redacte un correo de seguimiento. Una administrativa sube el PDF de una nómina para que le expliquen un concepto. Un jefe de proyecto pega el contrato firmado con un cliente y pregunta "¿qué riesgos ves aquí?". Ninguno tiene mala intención: los tres intentan trabajar más rápido. Y los tres acaban de sacar datos personales del perímetro de la empresa sin que nadie lo autorizara, evaluara ni registrara.
El 27 de mayo la Agencia Española de Protección de Datos publicó una nota de prensa que convierte esa escena cotidiana en un asunto con recorrido europeo. Aquí va qué se ha dicho exactamente, qué no se ha dicho —igual de importante—, qué marco jurídico aplica cuando tu equipo pega datos de clientes en un chat y qué puedes hacer la semana que viene.
Qué ha pasado exactamente (y qué NO ha dicho la AEPD)
El 27 de mayo de 2026 la AEPD publicó una nota de prensa titulada, literalmente, "La Agencia promueve ante las autoridades europeas de protección de datos que se estudie si algunos sistemas de IA permiten a terceros acceder a las conversaciones".
En corto: la AEPD remitió al Comité Europeo de Protección de Datos (CEPD/EDPB) una nota informativa sobre un estudio preliminar del instituto IMDEA Networks, titulado "Tu asistente de IA está filtrando tus conversaciones", y pidió que se difundiera a todas las autoridades europeas. Promovió además que el asunto se tratara en el pleno de autoridades del 8 y 9 de junio de 2026, invocando la ventanilla única del RGPD (el mecanismo que determina qué autoridad lidera cuando un tratamiento afecta a varios países de la UE).
Los tres problemas que señala el informe
La nota de la AEPD resume así los hallazgos del estudio preliminar: "la exposición de enlaces permanentes de conversaciones a rastreadores de terceros; la capacidad de vincular estas interacciones con identidades de usuario mediante mecanismos de seguimiento; y la existencia de controles y políticas de privacidad que podrían no reflejar con precisión los flujos reales de datos."
Los terceros a los que se refiere quedan nombrados en la propia nota como "proveedores de análisis y publicidad como Google, Meta, TikTok y otros".
Fuente primaria: nota de prensa de la AEPD del 27 de mayo de 2026. Si vas a citar esto en un comité o ante un cliente, cita la nota original y no los titulares de segunda mano: es un tema donde la imprecisión sale cara.
Lo que la nota NO dice
Importa tanto como lo anterior: en estas dos semanas he leído versiones bastante creativas de la noticia.
La AEPD no ha señalado a ningún asistente de IA por su nombre. Google, Meta y TikTok aparecen en la nota como ejemplos de proveedores de análisis y publicidad —los rastreadores de terceros que reciben información—, no como los asistentes analizados. Cualquier titular del tipo "la AEPD acusa a [nombre de un chatbot]" pone en boca de la Agencia algo que no ha dicho. Si quieres hablar de productos concretos, atribúyelo al estudio de IMDEA Networks tras leerlo tú mismo, no a la AEPD.
No es una sanción ni un procedimiento sancionador, sino una nota informativa para que se estudie el asunto. No consta sanción alguna a ninguna empresa por estos hechos.
No es una conclusión firme. El documento se describe a sí mismo como un estudio preliminar: lo que la AEPD promueve es precisamente que se estudie, no que se dé por probado.
Atribuir mal un señalamiento regulatorio a una empresa concreta es el error que acaba en carta de sus abogados. En protección de datos, la precisión en el sujeto de la frase —quién señala a quién— no es estilo: es la diferencia entre informar y difamar.
Qué es un enlace permanente de conversación y por qué es un problema
Casi todos los asistentes de IA de uso masivo tienen una función de "compartir conversación": pulsas un botón y el sistema genera una URL permanente y pública con el contenido de ese chat para que puedas enviársela a un compañero. Es útil y legítima. El problema no es que exista, sino lo que ocurre alrededor de ella.
Primero: la URL pública es una página web como cualquier otra
Cuando esa conversación se convierte en una página accesible sin iniciar sesión, hereda toda la mecánica de la web abierta: cualquiera con el enlace entra, sin control de acceso ni caducidad por defecto. Y si esa página carga scripts de terceros —analítica, píxeles publicitarios, gestores de etiquetas—, esos scripts reciben como parte de su telemetría normal la URL visitada y a menudo su título. Es exactamente para lo que están diseñados.
Traducido: el título de la conversación y su identificador viajan a proveedores externos que nunca fueron parte de ella. Si ese chat se titula "Reclamación de impago del cliente Martínez S.L.", ese texto ya ha salido de tu empresa. Y una URL pública sin restricciones de rastreo puede acabar además indexada por buscadores: lo que compartiste una vez con un compañero deja de ser "semiprivado".
Segundo: la vinculación con una identidad concreta
Es el punto más serio de los tres: "la capacidad de vincular estas interacciones con identidades de usuario mediante mecanismos de seguimiento".
Los proveedores de analítica y publicidad mantienen identificadores propios —cookies, identificadores de dispositivo, huella digital— que reconocen al mismo navegador a través de miles de sitios. Si uno de ellos está presente al visitarse la página de una conversación, el tercero puede asociar esa conversación con ese perfil publicitario. Ya no es un dato anónimo: es un dato personal vinculable a una persona identificable, justo la definición del art. 4.1 del RGPD.
Y aquí llega el salto que hace levantar la vista de la pantalla: si en esa conversación tu equipo pegó datos de un cliente, el dato expuesto no es el de tu empleado. Es el de tu cliente. Y del tratamiento de los datos de tu cliente respondes tú.
Tercero: controles que no reflejan el flujo real
El hallazgo más silencioso y el que peor encaja con cualquier estrategia de cumplimiento: "la existencia de controles y políticas de privacidad que podrían no reflejar con precisión los flujos reales de datos".
El RGPD se apoya en que puedas documentar y demostrar dónde acaban los datos (responsabilidad proactiva, art. 5.2), y ese análisis lo haces leyendo la política de privacidad y la configuración del proveedor. Si el flujo real no coincide con lo documentado, tu evaluación es correcta sobre el papel y falsa en la realidad, sin que puedas detectarlo desde dentro. Es un fallo de cadena de suministro, no de configuración.
Por eso el asunto trasciende a cualquier producto concreto. El riesgo no es "este chatbot filtra"; es que no puedes verificar por ti mismo el flujo real de datos de un SaaS cerrado. Tu única palanca es contractual y organizativa: qué contratas, qué configuras y qué permites que salga de tu empresa.
Por qué esto es tu problema aunque tu empresa no comparta ninguna conversación
"Nosotros no usamos la función de compartir, así que no nos afecta". Razonable, y probablemente equivocado, por dos motivos.
El primero es que no lo sabes. En la mayoría de pymes la IA entró por la puerta de atrás: cuentas personales gratuitas, sin SSO, sin registro y sin política. Es lo que llaman shadow AI: nadie ha decidido usar nada, simplemente doce personas lo usan a diario. Preguntar ahí "¿quién ha compartido una conversación con datos de cliente?" no tiene respuesta posible.
El segundo es que el enlace compartido es solo el vector más visible. El riesgo de fondo es más simple: cuando tu equipo pega datos personales en un servicio de terceros sin contrato, sin base jurídica y sin registro, ya estás incumpliendo, comparta el enlace o no. La nota de la AEPD no crea el problema. Lo ilumina.
El marco RGPD: quién responde cuando tu comercial pega un listado de clientes
Vamos a lo que le importa al que firma.
Tu empresa es el responsable del tratamiento. Eres tú quien decide fines y medios sobre los datos de tus clientes (art. 4.7), y el empleado actúa bajo tu autoridad. Que no lo hayas autorizado no te exime: precisamente por eso el RGPD te obliga a tener medidas organizativas que lo impidan (arts. 24 y 32).
El proveedor debería ser un encargado del tratamiento, y con una cuenta personal no lo es. El art. 28 exige un contrato de encargo por escrito que fije finalidad, tipo de datos, categorías de interesados y la obligación de no usarlos para fines propios. Si el empleado entra con su cuenta personal, ese contrato no existe: los términos los aceptó él como consumidor. Sin encargo, lo que haces no es delegar un tratamiento sino una comunicación de datos a un tercero, y para ella necesitas una base jurídica que casi con seguridad no tienes: tu cliente te dio sus datos para ejecutar el contrato (art. 6.1.b), no para alimentar el modelo de nadie.
Y si hay datos del art. 9 —salud, afiliación sindical, biométricos— o del art. 10 (condenas penales), el régimen se endurece y las excepciones son tasadas. Para una clínica, una asesoría laboral o un despacho, línea roja.
Transferencias y brechas. Si el proveedor procesa fuera del EEE aplican los arts. 44 a 49 —mecanismo, evaluación y documentación—, y un empleado pegando texto en una web no ha hecho ninguna de las tres cosas; súmale que el marco de transferencias a EE.UU. sigue sin estar zanjado (lo analizamos en el artículo sobre soberanía de datos). Y si datos de tus clientes acaban accesibles para terceros no previstos, eso es una violación de seguridad notificable en 72 horas (arts. 33 y 34).
| Artículo RGPD | Qué exige | Qué pasa con un chatbot público en cuenta personal |
|---|---|---|
| Art. 5.1.b y 5.1.c | Limitación de finalidad y minimización | El dato se usa para un fin distinto del que lo recogiste, y suele pegarse de más ("por si acaso") |
| Art. 5.2 | Responsabilidad proactiva: poder demostrarlo | No hay registro de qué se pegó, cuándo ni por quién |
| Art. 6 | Base jurídica para el tratamiento | Ninguna identificada para la comunicación al proveedor |
| Art. 9 | Régimen reforzado para datos sensibles | Salud, sindicación o datos penales en un chat: incumplimiento claro |
| Art. 28 | Contrato de encargo por escrito | Inexistente: los términos los aceptó el empleado como particular |
| Art. 30 | Registro de actividades de tratamiento | La actividad no está registrada porque nadie sabe que existe |
| Arts. 44-49 | Transferencias internacionales | Sin mecanismo de transferencia ni evaluación previa |
| Art. 35 | Evaluación de impacto cuando hay alto riesgo | No se ha hecho ninguna |
A esto se suma la capa del AI Act, con obligaciones propias de transparencia y gobernanza según la categoría de riesgo. Si no tienes claro dónde caes, la checklist del AI Act europeo te sitúa en veinte minutos.
Qué hacer: cinco medidas por orden de rentabilidad
Ninguna requiere un proyecto de seis meses. Van ordenadas por relación entre esfuerzo y reducción de riesgo real.
1. Escribe una política de uso aceptable de IA (y hazla de una página)
Las políticas de veinte páginas no las lee nadie. La que funciona cabe en un folio, se entiende sin abogado y clasifica los datos por semáforo:
| Nivel | Qué datos | Dónde se puede usar |
|---|---|---|
| Verde | Información pública, textos genéricos, código sin credenciales, borradores sin datos reales | Cualquier herramienta aprobada |
| Ámbar | Datos internos no personales: procesos, precios de coste, documentación técnica | Solo en la cuenta corporativa con plan de empresa |
| Rojo | Datos personales de clientes o empleados, salud, contratos firmados, credenciales, material bajo NDA o secreto profesional | Nunca fuera. Solo en sistemas bajo control de la empresa |
Añade una línea para cada uno de estos puntos: qué herramientas están aprobadas, que se usan siempre con la cuenta corporativa, que está prohibido compartir conversaciones de trabajo, a quién se pregunta ante la duda y qué hacer si alguien detecta que ha pegado algo que no debía (canal claro, sin castigo, con plazo). Ese último es el que más incidentes te ahorra: si castigas el aviso, no te enteras nunca.
Escribe la política pensando en un empleado con prisa, no en un inspector. Si para saber si puede pegar un texto tiene que interpretar tres párrafos, lo pegará igual. Una tabla de semáforo con ejemplos reales de tu negocio vale más que diez páginas de redacción jurídica.
2. Pasa a planes de empresa y configúralos de verdad
La diferencia entre una cuenta personal y un plan corporativo no es el precio: es el régimen jurídico y los controles disponibles.
| Elemento | Cuenta personal / gratuita | Plan de empresa (según proveedor) |
|---|---|---|
| Contrato de encargo (art. 28) | No: términos de consumidor aceptados por el empleado | Sí, firmado por la empresa |
| Uso de tus datos para entrenamiento | Habitualmente sí, salvo que se desactive | Compromiso contractual de no entrenamiento |
| Control de quién accede | Ninguno para la empresa | SSO, altas y bajas centralizadas |
| Trazabilidad y registros | Ninguna | Registro de actividad administrable |
| Retención de conversaciones | Por defecto del proveedor | Configurable, a menudo con retención cero |
| Compartir conversaciones | Activado por defecto | Deshabilitable por política de administrador |
| Residencia de datos | Sin control | Opciones regionales según proveedor |
Contratar el plan no basta: hay que configurarlo. Entrenamiento con tus datos desactivado, función de compartir restringida, retención mínima viable, SSO forzado y revisión de las integraciones de terceros conectadas. Y guarda evidencia de esa configuración: en cumplimiento, lo que no puedes demostrar no cuenta.
Un plan de empresa bien contratado y configurado ayuda a cumplir el RGPD: aporta el contrato de encargo, los controles y la trazabilidad que el reglamento exige. No te "hace cumplidor" por sí solo: el cumplimiento sigue dependiendo de tu base jurídica, tu registro de tratamientos y lo que tu equipo haga a diario.
3. Cuando el dato no puede salir, que no salga
Hay información para la que ninguna cláusula contractual basta: historiales clínicos, expedientes bajo secreto profesional, documentación sujeta a ENS, material con NDA que prohíbe el subencargo. Ahí la respuesta no es un contrato mejor sino una arquitectura distinta: el modelo va a donde está el dato, no al revés.
Un despliegue on-premise o en cloud privado europeo con modelos de pesos abiertos resuelve de raíz los tres problemas del informe: no hay enlaces públicos, no hay rastreadores de terceros y el flujo es verificable porque es tuyo. Ya no exige un equipo de machine learning ni un data center: con una máquina bien dimensionada y stacks maduros se monta en semanas, y lo detallamos en cómo desplegar IA sin enviar datos fuera de la UE.
Lo que no recomiendo es el extremo contrario: prohibir la IA por decreto. No funciona; solo consigues volver invisible el uso, que es justo lo que intentas evitar.
4. Controles técnicos que no dependen de la buena voluntad
Una política sin refuerzo técnico es una declaración de intenciones. Cuatro medidas de bajo coste que sí mueven la aguja:
- SSO corporativo obligatorio, con altas y bajas ligadas al directorio: quien se va pierde el acceso el mismo día.
- Bloqueo o aviso en el proxy/DNS para el resto de asistentes. No como muro infranqueable —siempre está el móvil personal—, sino como recordatorio de que existe una herramienta oficial.
- DLP en los canales que ya tienes (correo, endpoint) con patrones críticos: NIF, IBAN, historia clínica, tus referencias de cliente.
- Inventario y revisión trimestral de herramientas, usuarios e integraciones. Incluye la actividad en tu registro del art. 30 y valora si procede una evaluación de impacto (art. 35).
5. Forma al equipo con casos reales, no con teoría
La formación que funciona dura cuarenta minutos y enseña cinco ejemplos del propio negocio: este correo sí, este listado no, este contrato nunca, este texto anonimizado sí y así se anonimiza. Explica por qué, no solo qué está prohibido: quien entiende que el enlace de una conversación puede acabar visible entiende por qué le pides que no lo genere. Repítela con cada incorporación y cada cambio de herramienta.
Y enseña a anonimizar antes de pegar: nombres por roles ("el cliente A"), fuera NIF, IBAN, direcciones y teléfonos, y trabajar sobre el problema, no sobre el expediente. La mayoría de las veces el asistente hace el mismo trabajo sin un solo dato personal.
Si este mes haces solo dos cosas —publicar la política de una página con el semáforo y mover al equipo a cuentas corporativas con el entrenamiento y el compartir desactivados— habrás eliminado la mayor parte de tu exposición real. No hace falta un proyecto de cumplimiento de seis cifras para adelantar a la media de tu sector.
Checklist accionable
Para llevar al comité de dirección o a la próxima reunión con tu DPO:
- Inventario: qué asistentes usa el equipo, con qué cuentas y para qué. Pregunta sin ánimo sancionador o nadie dirá la verdad.
- Política de uso aceptable de IA de una página, con semáforo y ejemplos del propio negocio, firmada por dirección y comunicada a todo el personal.
- Cuentas corporativas con plan de empresa, y contrato de encargo del art. 28 firmado y archivado.
- Configuración verificada y documentada: entrenamiento desactivado, compartir restringido, retención mínima, SSO obligatorio.
- Revocar los enlaces compartidos que alguien haya generado con contenido de trabajo.
- Registro del art. 30 actualizado con el tratamiento "uso de asistentes de IA": categorías de datos, base jurídica, encargados y transferencias.
- Transferencias internacionales analizadas si se procesa fuera del EEE, y evaluación de impacto (art. 35) si el tratamiento es sistemático, a gran escala o incluye datos del art. 9.
- Línea roja comunicada: qué no sale de la empresa bajo ningún concepto y qué alternativa interna hay para esos casos.
- Controles técnicos: SSO, proxy/DNS, DLP sobre patrones críticos, inventario de integraciones.
- Formación y revisión trimestral, con fecha en el calendario y un responsable con nombre y apellidos.
Conclusión: el problema nunca fue la herramienta
Lo que la AEPD ha promovido en Europa no es una condena a la IA conversacional. Es un recordatorio de algo que en gestión de datos sabemos desde hace veinte años: cuando delegas un tratamiento en un tercero, tu control se reduce a lo que puedas contratar, configurar y verificar. Y si ese servicio tiene flujos que sus propios controles no reflejan con precisión, tu evaluación de riesgos deja de valer sin que te enteres.
La lectura práctica para una pyme es sencilla. La IA generativa aporta valor real y prohibirla es tirar piedras contra tu tejado; pero el uso salvaje —cuentas personales, sin política, sin contrato y sin registro— es una exposición innecesaria que se corrige con dos semanas de trabajo organizativo. La diferencia entre quien dentro de un año tendrá esto ordenado y quien tendrá un susto no es el presupuesto: es haber decidido a tiempo.
Si usáis IA a diario y sospechas que se pegan cosas que no deberían, en Lin-ia ayudamos a poner orden: inventario real de uso, política de uso aceptable, migración a cuentas corporativas bien configuradas y, cuando el dato no puede salir, despliegue de IA dentro del perímetro. Escríbenos o cuéntanos tu caso en el formulario de contacto.
Lecturas relacionadas: IA on-premise y soberanía de datos en Europa, checklist del AI Act europeo y agentes de IA autónomos: qué es real en 2026.
