¿Necesita consentimiento el widget de soporte? § 25 TDDDG

Conclusiones principales

• El § 25 apartado 1 TDDDG exige, por principio, consentimiento para almacenar y leer información en el equipo terminal.
• Existen dos posiciones sin resolver: el widget como formulario de contacto necesario, o como servicio sujeto a consentimiento.
• La Datenschutzkonferenz interpreta las excepciones de forma estricta y suele considerar que los scripts de carga automática requieren consentimiento.
• Incumplir el requisito de consentimiento es una infracción administrativa y puede sancionarse con multa conforme al § 28 TDDDG.
• La vía de menor riesgo es cargar el script del chat solo después de que la visitante haya dado su conformidad activa.

No es asesoramiento jurídico, pero sí un marco legal claro

Este artículo no constituye asesoramiento jurídico. Ordena de forma pragmática la situación legal en torno a los widgets de soporte y muestra qué decisiones técnicas debes tomar como responsable de soporte o del sitio web. Quien integra un widget de chat en su propia web se enfrenta antes o después a la pregunta del departamento jurídico o del delegado de protección de datos: ¿el widget va en el banner de consentimiento o puede cargarse directamente?

El eje jurídico es el § 25 de la Telekommunikation-Digitale-Dienste-Datenschutz-Gesetz (TDDDG), la ley alemana de protección de datos en telecomunicaciones y servicios digitales. Este artículo regula la protección de la privacidad en los equipos terminales y distingue con precisión entre las operaciones sujetas a consentimiento y las excepciones legales.

El principio del apartado 1. La excepción del apartado 2.

Conforme al § 25 apartado 1 frase 1 TDDDG, almacenar información en el equipo terminal del usuario final o acceder a la información ya almacenada allí solo está permitido si se ha consentido previamente sobre la base de una información clara y completa¹. Según la lectura de las autoridades de control, la norma está formulada de forma neutra respecto a la tecnología, de modo que abarca todas las técnicas y procedimientos con los que puede producirse el almacenamiento y la lectura de información, como Local Storage, Session Storage o IndexedDB².

El § 25 apartado 2 número 2 TDDDG establece una excepción estrecha a ese principio: no se requiere consentimiento cuando el almacenamiento o el acceso es estrictamente necesario para que el prestador de un servicio digital pueda facilitar un servicio digital expresamente solicitado por el usuario¹.

Aquí importa separar con limpieza el TDDDG del Reglamento General de Protección de Datos (RGPD): el TDDDG protege la integridad del equipo terminal con total independencia de que los datos leídos o fijados sean personales. El RGPD se aplica además, en cuanto se tratan datos personales como direcciones IP o contenidos del chat.

Posición 1: el widget como formulario de contacto necesario

La primera interpretación jurídica trata el widget de soporte esencialmente como un formulario de contacto moderno y siempre presente. Quienes la defienden argumentan que la atención al cliente es una función esencial de cualquier oferta digital. Quien visita un sitio web o una aplicación web espera una forma de contacto directo.

La persistencia de sesión como necesidad técnica.

Desde el punto de vista técnico, un widget de soporte interactivo necesita un identificador en el Session Storage o el Local Storage del navegador. Sin él, el historial del chat se interrumpiría en cuanto la visitante cambiara de página o recargara la pestaña. La posición 1 argumenta, por tanto: si se ofrece soporte, fijar ese identificador de sesión puramente funcional es técnicamente imprescindible para mantener viva la conversación a lo largo de varias páginas.

Sobre esa premisa, las empresas se apoyan en la excepción del § 25 apartado 2 número 2 TDDDG, que hace innecesario el consentimiento cuando el acceso es estrictamente necesario para facilitar un servicio digital expresamente solicitado por el usuario¹. El script se clasifica como Necesario o Esencial en la herramienta de gestión del consentimiento y se carga de inmediato en la primera visita, sin que la visitante tenga que marcar antes una casilla en el banner.

• El canal de soporte se valora como vía de contacto estándar, análoga a los enlaces de correo o a los formularios de contacto.
• Guardar el identificador de sesión sirve exclusivamente para prestar el diálogo y no implica ningún seguimiento.
• La función de traspaso y de ayuda está disponible para las clientas de inmediato, sin barrera alguna ni clic previo de consentimiento.
• El script figura en el banner de consentimiento como servicio esencial y se carga automáticamente con la página.

Posición 2: la visión estricta de la Datenschutzkonferenz

La Datenschutzkonferenz (DSK), el órgano conjunto de las autoridades independientes de protección de datos de la Federación y de los estados alemanes, sostiene una interpretación notablemente más estricta. En su guía para prestadores de telemedios establece que el § 25 apartado 1 fija el principio de necesidad de consentimiento y que solo se apartan de él las dos excepciones estrechamente delimitadas del apartado 2². El legislador se ciñó deliberadamente al tenor literal de la norma europea y no incorporó más excepciones, de modo que solo unos pocos servicios pueden integrarse sin consentimiento².

La carga automática sin interacción no es una solicitud expresa.

En opinión de las autoridades de control, ahí está justamente el punto crítico de un widget de chat que se carga automáticamente: la visitante abre un sitio web para informarse sobre un producto o leer un artículo. En ese momento todavía no ha solicitado expresamente el servicio de soporte. Según el tenor de la ley, la excepción solo se aplica cuando el acceso es estrictamente necesario para facilitar un servicio digital expresamente solicitado por el usuario¹. La Datenschutzkonferenz subraya que ambos elementos están indisolublemente ligados y que la necesidad estricta debe valorarse siempre en relación con el servicio concretamente solicitado, lo que exige una mirada granular a cada función del sitio web². Si el script ya se carga en segundo plano y fija un identificador de dispositivo antes de que la usuaria haya pulsado activamente el icono del chat, según esta lectura falta el criterio de la solicitud expresa.

Las autoridades señalan además que muchos scripts de widget habituales ya recogen datos del dispositivo y del navegador al inicializarse, transmiten direcciones IP a servidores de terceros o cargan tipografías y recursos externos. El requisito de consentimiento se aplica con independencia de que la información almacenada o leída tenga carácter personal². A ello se suma el momento: el consentimiento debe existir antes de que se acceda al equipo terminal. Según esta lectura estricta, cargar el widget de forma general en cada subpágina requiere consentimiento.

Consecuencias prácticas: ¿carga tras clic o categoría en el banner?

La calificación jurídica no es un ejercicio teórico. Dicta exactamente cómo debe implementarse técnicamente tu widget e integrarse en tu sistema de gestión del consentimiento. Quien se decide por una de las dos interpretaciones debe elegir la arquitectura técnica que le corresponde.

Opción A: carga inmediata como servicio esencial.

Si tu empresa clasifica el widget como técnicamente imprescindible, registras el script en el grupo Esencial o Necesario de tu herramienta de consentimiento. El widget se carga de forma asíncrona al abrir la página. La visitante ve el botón de soporte enseguida en la esquina de la pantalla. La ventaja: máxima disponibilidad y ninguna barrera de entrada para quien busca ayuda.

Opción B: control a través del banner de consentimiento.

Si tu empresa sigue el criterio de las autoridades de protección de datos, el widget pertenece a la categoría Funcional o Medios externos. En la práctica esto significa: el banner de consentimiento bloquea el script y solo lo inyecta cuando la usuaria pulsa activamente Aceptar todo o selecciona Funcional en el banner. Si la visitante lo rechaza, el widget permanece completamente invisible para ella. En ese caso conviene ofrecer vías de contacto estáticas en el pie de página o un centro de ayuda público como alternativa.

Opción C: la solución de dos clics con marcador de posición.

Una alternativa elegante al bloqueo por banner es la carga tras clic. Aquí no se carga inicialmente ningún script externo ni ninguna cookie. En la página solo hay un icono local que hace de marcador. Cuando la visitante pulsa activamente ese icono de chat, confirma con ello la solicitud expresa del servicio de soporte. Solo ese clic desencadena la carga dinámica del script del widget. Esto encaja con el tenor de la excepción del § 25 apartado 2 número 2 TDDDG, que exime el acceso únicamente para un servicio digital expresamente solicitado¹.

1. 01Variante 1 (esencial): el script se carga directamente. Alta disponibilidad, exige una documentación sólida en la empresa.
2. 02Variante 2 (opt-in en el banner): el script solo se carga con el consentimiento del banner. Si se rechaza el banner, se pierde el canal de chat.
3. 03Variante 3 (carga en dos clics): el marcador carga el script solo con una interacción activa. Alta seguridad jurídica manteniendo la visibilidad.

Documentación: por qué no basta con una simple decisión

Sea cual sea la vía que elija tu equipo: una decisión informal en el Slack de soporte o una conformidad verbal no bastan ante una inspección de la autoridad. El art. 5 apartado 2 RGPD impone la responsabilidad proactiva. Debes poder acreditar y justificar en todo momento por qué una herramienta se emplea como se emplea.

Inscripción en el registro de actividades de tratamiento.

Todo sistema de soporte en uso debe constar obligatoriamente en el registro de actividades de tratamiento conforme al art. 30 RGPD. Allí deben recogerse de forma transparente los fines del tratamiento, las categorías de interesados, los destinatarios de los datos, los plazos de conservación y las bases jurídicas empleadas según el TDDDG y el RGPD.

Además, la política de privacidad de tu web debe desglosar en detalle el uso del widget. Si allí se fijan identificadores, hay que nombrar con precisión el plazo de conservación, el funcionamiento y los prestadores implicados. Esta es también la base para responder con solvencia y dentro de plazo a consultas posteriores de los usuarios o a solicitudes de acceso conforme al RGPD.

• Justificación documentada de la clasificación según el § 25 TDDDG (esencial, opt-in en el banner o dos clics).
• Mantenimiento de la inscripción en el registro de actividades de tratamiento conforme al art. 30 RGPD.
• Cláusula completa en la política de privacidad con mención del prestador, los plazos de conservación y la finalidad de los datos.
• Celebración de un contrato de encargo de tratamiento conforme al art. 28 RGPD con el proveedor del widget.

La vía de menor riesgo para los responsables del sitio web

Quien quiera minimizar los riesgos jurídicos debe sopesar con serenidad las consecuencias posibles. Las infracciones de lo dispuesto en el § 25 apartado 1 TDDDG no son bagatelas. Conforme al § 28 apartado 1 número 13 en relación con el apartado 2 TDDDG, almacenar información o acceder a ella sin consentimiento puede sancionarse con una multa de hasta trescientos mil euros⁴.

Riesgo de requerimientos de asociaciones y competidores.

Además de las multas administrativas, los scripts integrados sin transparencia conllevan siempre el riesgo de requerimientos por competencia desleal de asociaciones de consumidores o de competidores. Los scripts que fijan cookies de seguimiento sin consentimiento en el banner, o que transfieren datos a terceros países sin un nivel de protección adecuado, son el blanco de los rastreadores automatizados.

Por eso la vía con diferencia menos arriesgada es doble: o integras el widget con una lógica real de dos clics, de modo que los datos solo fluyan al pulsar el chat, o asignas el widget en el banner a la categoría sujeta a consentimiento. Si, en cambio, quieres cargar el widget directamente como esencial, asegúrate de que el proveedor no realiza ningún seguimiento de terceros, de que los datos se tratan íntegramente en la UE y de que la justificación está documentada sin lagunas en el registro de actividades de tratamiento.

Soporte con IA conforme al RGPD con Comlayer

Si quieres automatizar la atención al cliente moderna sin arriesgarte a zonas grises jurídicas, la base técnica adecuada es lo que cuenta. Lo decisivo es una solución que separe con limpieza la interfaz del tratamiento de datos y te deje plena flexibilidad en la integración.

Script ligero y modos de carga flexibles.

El widget de Comlayer se integra mediante un fragmento asíncrono de JavaScript. Tú decides si el fragmento se carga directamente en el código fuente, si tu sistema de gestión del consentimiento lo libera tras el consentimiento, o si se inicializa dinámicamente solo a través de un evento de clic en tu página. La lista de dominios permitidos garantiza que tu clave de widget no pueda usarse indebidamente en dominios ajenos.

Cómo se ve una decisión así una vez tomada puede leerse en la propia Comlayer. En su registro de consentimiento, el chat de soporte está clasificado como necesario conforme al § 25 apartado 2 número 2 TDDDG, con el argumento de que es el único canal de soporte de esa página y por eso se trata como un formulario de contacto. La posición contraria consta expresamente al lado: la Datenschutzkonferenz cuenta los widgets de chat de carga automática entre los servicios sujetos a consentimiento, porque el script se carga sin intervención de la visitante y fija un identificador. Quien lo valore de otro modo mueve la entrada a la categoría funcional, vincula la carga al consentimiento y sube la versión del banner para que se vuelva a preguntar. Eso tampoco es una cuestión jurídica resuelta, sino una decisión razonada y documentada: exactamente la que describe este artículo.

Tratamiento en la UE y sin entrenamiento de modelos.

Detrás del widget trabaja una infraestructura europea limpia de seguridad y protección de datos: las conversaciones, los archivos adjuntos y el procesamiento por IA se ejecutan en centros de datos europeos. Se facilita directamente un contrato de encargo de tratamiento conforme al art. 28 RGPD. Un punto esencial para las empresas: tus datos de clientes y tus conversaciones de soporte no se utilizan para entrenar modelos de IA. Las respuestas se basan en RAG (Retrieval-Augmented Generation) y ofrecen siempre el enlace a la fuente.

Las tarifas están estructuradas con transparencia: la tarifa Free permite empezar gratis con el widget de soporte, el centro de ayuda y dos plazas de equipo. La tarifa Pro se dirige a equipos que usan el soporte con IA en producción e incluye 500 respuestas de IA y un dominio propio para el centro de ayuda. Para volúmenes mayores está la tarifa Scale, con 5.000 respuestas de IA incluidas.

• Integración flexible: carga directa, acoplamiento al banner o disparador de dos clics mediante JavaScript.
• Alojamiento y procesamiento de IA en regiones europeas, con contrato de encargo de tratamiento.
• Sin entrenamiento de modelos de IA públicos con tus conversaciones de clientes.
• Modelos de precios transparentes, desde la tarifa Free gratuita hasta Pro y Scale, con un precio base mensual, un precio por plaza y respuestas de IA según consumo.

Preguntas frecuentes