Chatbots en tu web: un nuevo frente de riesgo RGPD (mucho más que “atender al usuario”)

Posted on by Leocadio Marrero Trujillo

Los chatbots se han convertido en la puerta de entrada a muchas organizaciones: atienden dudas, captan leads, permiten tramitar reclamaciones e incluso hacen recomendaciones “inteligentes”.
Desde la óptica GRC, eso significa algo muy concreto: un nuevo sistema de tratamiento intensivo de datos personales, siempre activo, 24/7, en tu web o app.

Las autoridades de control ya han empezado a intervenir: desde guías específicas sobre chatbots y sistemas de IA de la CNIL y la AEPD, hasta sanciones millonarias como la del Garante italiano al chatbot Replika por incumplir principios clave del RGPD en menores y usuarios vulnerables.(CNIL)

Este post resume qué debe vigilar un responsable de tratamiento cuando despliega un chatbot en su web o app, con una mirada integrada de gobierno, riesgo y cumplimiento (GRC).

  1. Qué es “legalmente” un chatbot bajo el RGPD

Detrás de la interfaz conversacional hay varios elementos de riesgo:

  • Canal de recogida directa de datos: el usuario escribe (o dicta) información personal, a menudo muy sensible (salud, emociones, trabajo, conflictos, etc.).
  • Posible perfilado: el sistema puede construir perfiles de comportamiento, intereses o incluso estados emocionales.
  • Posible decisión automatizada: según el diseño, el chatbot puede tomar decisiones con efectos jurídicos o similares (p. ej., preclasificar solicitudes, priorizar incidencias, hacer scoring de riesgo, etc.).

En términos RGPD, hay que aclarar tres capas de responsabilidad:

  1. Quién es el responsable del tratamiento (tu organización, casi siempre).
  2. Quién es el encargado (el proveedor SaaS del chatbot o del modelo de IA).
  3. Si hay corresponsables (p. ej., si se entrena o reutiliza data conjunta con el proveedor).

Las autoridades subrayan que esto no es un “plugin inocuo”, sino un tratamiento complejo que debe reflejarse claramente en el Registro de Actividades, contratos de encargo y acuerdos entre corresponsables.(Data21)

  1. Bases jurídicas típicas y sus límites

En la práctica, con chatbots web suelen aparecer tres bases de licitud:

  1. Ejecución de contrato (art. 6.1.b RGPD)
    • Válida cuando el chatbot es necesario para prestar el servicio contratado (p. ej., soporte técnico a clientes con login).
    • No justifica, por sí sola, entrenar modelos con los datos de las conversaciones para otros fines.
  2. Interés legítimo (art. 6.1.f RGPD)
    • Útil para mejorar el servicio o realizar analítica limitada, siempre que se haga una evaluación de interés legítimo sólida y existan salvaguardas (pseudonimización, retención limitada, opt-out real, etc.).
    • Muy difícil de sostener para tratamientos intensivos, perfiles sensibles o interacciones con menores.
  3. Consentimiento (art. 6.1.a RGPD)
    • Recomendable cuando el chatbot no es necesario para el servicio principal o cuando puede derivar en tratamientos de alto riesgo (p. ej., ayuda emocional, salud, orientación laboral sensible).
    • Debe ser granular, informado y revocable con la misma facilidad con la que se otorgó, como recuerda la CNIL para chatbots y la AEPD en sus guías sobre tratamientos que incorporan IA.(CNIL)

El caso Replika es ilustrativo: el Garante italiano consideró que faltaba base jurídica válida, en especial respecto a menores y datos altamente sensibles (estado emocional, sexualidad, etc.), y sancionó con 5 millones de euros.

  1. Información y transparencia: el “script” que casi nadie escribe

Un chatbot compliant no empieza con el “Hola, ¿en qué puedo ayudarte?”, sino con:

  • Quién es el responsable y, en su caso, el DPO.
  • Para qué se usarán los datos: atención, mejora del servicio, entrenamiento del modelo, analítica, etc.
  • Si interviene IA generativa o aprendizaje automático y qué implica (riesgo de errores, respuestas no verificadas, etc.).
  • Con quién se compartirán los datos (proveedor del chatbot/modelo, subencargados, transferencias internacionales).
  • Qué derechos tiene la persona y cómo ejercerlos.

CNIL y AEPD insisten en que esta información debe ser breve, clara y visible en la propia interfaz, no enterrada solo en la política de privacidad general.(CNIL)

Una buena práctica para GRC:

  • Diseñar un mini-aviso específico de chatbot (capa 1) enlazando a la información extendida (capa 2).
  • Asegurar que el tono y el diseño no constituyan un dark pattern que empuje al usuario a compartir más datos de los necesarios.

  1. Minimización y calidad de datos: el chatbot no es tu cajón desastre

Uno de los mayores riesgos observados por el EDPB en su checklist sobre riesgos de privacidad en LLMs es la captura masiva y no filtrada de información a través de interfaces conversacionales.(CNIL)

Desde la óptica GRC, deberías preguntarte:

  • ¿Cuál es el conjunto mínimo de datos que el chatbot necesita para cada caso de uso?
  • ¿Hemos configurado el sistema para bloquear o enmascarar datos especialmente sensibles (salud, ideología, sexualidad, datos de terceros, etc.)?
  • ¿Se entrenan modelos con las conversaciones?
    • Si sí, ¿con qué garantías de anonimización/pseudonimización?
    • ¿Se ha informado expresamente al usuario?
  • ¿Cuál es el tiempo de retención de los logs de chat y cómo se purgan?

Muchos incidentes recientes no han sido “brechas clásicas”, sino filtraciones graduales a través del propio canal de chat: usuarios copiando datos de clientes, expedientes o contratos a la interfaz sin que exista una política clara que lo limite.

  1. Derechos de las personas: no todo se resuelve “hablando con el bot”

Un chatbot no puede convertirse en un filtro opaco que dificulta el ejercicio de derechos:

  • El usuario debe poder:
    • Solicitar acceso, rectificación o supresión sin depender solo del bot (p. ej., mediante enlace visible a formulario o correo del DPO).
    • Retirar su consentimiento cuando sea la base jurídica principal, con un mecanismo claro y sencillo.
    • Oponerse al perfilado o a las decisiones automatizadas, cuando proceda (art. 21 y 22 RGPD).

Las autoridades recomiendan no delegar totalmente la gestión de derechos en chatbots. Lo adecuado es que el bot:

  1. Reconozca palabras clave (“derecho de acceso”, “borrar mis datos”, “DPO”…).
  2. Redirija rápidamente a canales humanos y verificables.

  1. Riesgos específicos de chatbots con IA generativa

Los documentos recientes del EDPB y varias autoridades nacionales han puesto el foco en tres bloques de riesgo de los modelos generativos integrados en chatbots:(CNIL)

  1. Riesgos para la exactitud y equidad
    • Alucinaciones, sesgos, asociaciones discriminatorias.
    • Recomendaciones incorrectas en contextos sensibles (salud, finanzas, empleo).
  2. Riesgos para la confidencialidad y seguridad
    • Uso del chat como canal de exfiltración de datos internos.
    • Posibilidad de reconstruir información sensible a partir de prompts y contextos.
  3. Riesgos para colectivos vulnerables (menores, personas en crisis, etc.)
    • Chatbots que imitan relaciones afectivas, eróticas o terapéuticas (caso Replika).
    • Falta de age gating efectivo y de mecanismos de protección específicos.

En contextos de alto riesgo, la combinación de RGPD + próxima normativa de IA exige un enfoque reforzado de “privacy & AI by design/by default”, DPIA sólida y mecanismos de supervisión humana.

  1. Enfoque GRC: cómo gobernar un chatbot desde la organización

Para que el chatbot sea una palanca y no un problema, conviene integrarlo en la arquitectura de gobierno y riesgo:

  • Gobernanza
    • Definir un owner funcional (negocio), un owner técnico (IT/Dev) y un owner de cumplimiento (DPO/Compliance).
    • Aprobar una política específica de uso de chatbots/IA en canales de atención.
  • Gestión de riesgos
    • Incorporar el chatbot al mapa de riesgos de privacidad y ciberseguridad.
    • Realizar Evaluación de Impacto (EIPD/DPIA) cuando haya alto riesgo: perfilado intensivo, colectivos vulnerables, grandes volúmenes o decisiones automatizadas.
  • Compliance & contratos
    • Revisar los DPA/contratos de encargo con el proveedor del chatbot/modelo, especialmente:
      • Finalidades y subtratamientos.
      • Transferencias internacionales y subencargados.
      • Medidas de seguridad y auditoría.
    • Verificar que el proveedor soporta derechos de los interesados (borrado, exportación, logs).
  • Control y auditoría
    • Definir controles periódicos (revisión de prompts, de logs, de fallos de clasificación, etc.).
    • Incorporar el chatbot al plan de auditoría interna/externa, alineado con ISO 19011, para revisar diseño, operación, evidencias y acciones correctivas.

Bibliografía esencial para este post

 

Checklist rápido GRC para lanzar un chatbot en tu web/app

Puedes usar este bloque como recuadro práctico al final del post:

    1. Mapa de tratamiento
      • El chatbot y sus flujos están descritos en el Registro de Actividades.
      • Se han identificado responsable, encargados y, en su caso, corresponsables.
    2. Base jurídica y finalidad
      • Cada finalidad del chatbot tiene base jurídica clara (contrato, interés legítimo, consentimiento).
      • El entrenamiento/mejora del modelo está separado y justificado (y, si procede, basado en consentimiento o interés legítimo ponderado).
    3. Transparencia
      • Hay un aviso específico de chatbot en la propia interfaz, con enlace a info ampliada.
      • Se explica si interviene IA generativa y sus límites (posibles errores, no sustitución de asesoramiento profesional, etc.).
    4. Minimización y retención
      • El chatbot pide solo los datos estrictamente necesarios.
      • Existen reglas para bloquear/enmascarar datos especialmente sensibles.
      • Los logs de chat tienen un periodo de retención definido y mecanismos de borrado.
    5. Derechos y experiencia de usuario
      • El chatbot reconoce solicitudes de derechos y redirige a canales humanos.
      • Es tan fácil retirar el consentimiento como darlo.
      • No hay dark patterns que presionen para compartir más datos o aceptar uso extensivo.
    6. Riesgos de IA y colectivos vulnerables
      • Se ha realizado DPIA/EIPD si hay alto riesgo (menores, salud, decisiones automatizadas…).
      • Hay supervisión humana en decisiones relevantes.
      • Existen mecanismos de age gating si el chatbot puede atraer a menores.
    7. Contratos y transferencias
      • Los contratos con el proveedor cubren encargo de tratamiento, subencargados y transferencias internacionales.
      • Se han revisado las cláusulas de entrenamiento de modelos y reutilización de datos.
    8. Auditoría y mejora continua
      • El chatbot está incluido en el plan de auditoría (ISO 19011) con criterios, evidencias y responsables.
  • Existen métricas y KPIs (incidencias de privacidad, errores graves, quejas) y se revisan periódicamente.

 

Leocadio Marrero Trujillo