Chatbot de IA y RGPD: planificar bien los flujos de datos, los avisos y la supresión

Un formulario de contacto tiene campos obligatorios, un botón de envío y un momento claro en el que los datos salen del navegador. Una ventana de chat no tiene nada de eso. Los visitantes escriben como hablan: “Soy la señora Meier, mi tubería de la calefacción pierde desde ayer, llámeme a este número.” En una sola frase figuran nombre, número de teléfono y una petición relacionada con el lugar de residencia.

En este escenario, una empresa de oficios ha construido un chatbot como prototipo. Responde a preguntas sobre servicios y recoge peticiones de cita. Funcionalmente convence, pero a la pregunta de dónde están las conversaciones solo hay encogimientos de hombros. El proveedor está en algún sitio, el modelo procede de otra empresa más y la política de privacidad no menciona el chat.

Este punto de partida es habitual. No surge por descuido, sino porque durante el desarrollo un chatbot aparece como una función y solo más tarde como un tratamiento de datos. El estudio muestra cómo invertir ese orden. Es una orientación para la planificación y para las conversaciones con su asesoría de protección de datos, expresamente no es asesoramiento jurídico ni sustituye la revisión de su caso concreto.

La primera pregunta es: ¿saben los visitantes que escriben a una máquina? Un nombre amable y una foto bastan para que alguien suponga que es una empleada. La segunda: ¿adónde van los mensajes? Entre el navegador y la respuesta suele haber tres estaciones, cada una con sus propios servidores y sus propias reglas.

La tercera pregunta se refiere a la duración. Muchas herramientas de chat guardan los historiales por defecto y sin límite, porque resulta práctico para los análisis. Sin una decisión consciente, crece así un archivo de declaraciones personales que nadie ha pedido. La cuarta pregunta es la más incómoda: ¿qué hace usted si alguien quiere que se borren sus datos y no sabe en qué conversación están?

A ello se suma un patrón de error que en el día a día es más frecuente que la gran fuga de datos: por afán de ayudar, el bot pregunta más de lo que necesita. Quien pregunta por un horario no tiene que dar una dirección. Quien deja una petición de llamada no necesita relatar su historial médico, algo que en las consultas puede ocurrir fácilmente. Cuanto más abierta es la entrada, mayor es la dispersión de lo que llega.

Antes de hablar de contratos, conviene una imagen sencilla del flujo de datos. Un mensaje empieza en el navegador del visitante, va al servidor del proveedor del chatbot, de allí a la interfaz de un modelo de lenguaje y de vuelta. En las peticiones de cita o de llamada se añade una cuarta estación: un calendario, un CRM o un buzón al que se reenvían los datos.

Cada estación responde a las mismas preguntas. ¿Quién la opera, en qué país están los servidores, se guarda el mensaje, se utiliza para mejorar modelos? La última pregunta es especialmente importante porque los proveedores difieren en esto. En las interfaces empresariales, muchos proveedores excluyen contractualmente el uso para entrenamiento; en las ofertas para consumidores suele ser distinto. Esto debe desprenderse de la documentación contractual, no de una suposición.

Un ejemplo muestra con qué facilidad se pasan por alto estaciones. El chat en sí funciona con un proveedor en la UE, pero el aviso de una nueva llamada se envía por correo electrónico a través de otro servicio que contiene el mensaje literal. De repente, la misma frase está en dos lugares, con dos plazos distintos. Estos caminos secundarios pasan inadvertidos si solo se observa el sistema de chat.

Para este inventario basta una hoja de papel. Dibujamos las estaciones, añadimos para cada una el operador, la ubicación, el almacenamiento y la finalidad, y marcamos dónde aparecen realmente datos personales. A menudo resulta que una herramienta ve más de lo pensado, por ejemplo un script de análisis que lee el contenido o un registro que guarda los mensajes en texto plano.

El camino cómodo sería fiarse de la página de protección de datos del proveedor del chatbot. Pero esta describe su punto de vista, no el suyo. El responsable del tratamiento en su sitio web es usted, aunque compre la tecnología. El proveedor es, por lo general, un prestador de servicios que trata datos por encargo suyo y, según principios generalmente conocidos, para ello se necesita un contrato de encargo de tratamiento.

Por eso procederíamos en tres pasos. Primero, aclarar los roles: ¿quién es el responsable, quién el encargado del tratamiento y hay subencargados, por ejemplo el operador del modelo? Segundo, comprobar si el contrato de encargo de tratamiento cubre la cadena real, incluidas la ubicación y los subencargados. Tercero, valorar si se produce una transferencia a países fuera de la UE y sobre qué base.

Existen alternativas. Un modelo operado por cuenta propia mantiene los datos en su propio centro de datos, pero exige operación, actualización y seguridad por su parte, lo que rara vez compensa a los negocios pequeños. Un proveedor con servidores en la UE reduce las dudas sobre transferencias, pero no cumple automáticamente la normativa de protección de datos. La elección es un equilibrio entre esfuerzo, calidad de las respuestas y control, y debería justificarse por escrito para que sea trazable más adelante.

Una tercera vía es no dejar que los datos lleguen a existir. Cuanto menos pregunta el bot, más pequeña es cada cuestión sobre contratos y plazo de conservación. Esta actitud de minimización de datos es un principio generalmente conocido y la palanca más eficaz de todo el concepto.

El aviso sobre la IA va antes de la primera palabra. Como orientación general: quien habla con un sistema de IA debería poder reconocerlo, a más tardar al comienzo de la conversación. El Reglamento europeo de IA recoge esta idea con obligaciones de transparencia. Qué obligaciones se aplican concretamente a su chatbot y desde cuándo, debe aclararlo con su asesoría jurídica. Desde el punto de vista técnico, el aviso tiene sentido en cualquier caso, porque crea expectativas realistas.

El saludo puede cumplir ambas funciones: “Soy el asistente digital de [negocio] y una IA. Respondo a preguntas sobre servicios y citas. Por favor, no escriba aquí datos sensibles como datos de salud, números de cuenta o contraseñas.” Dos frases, un enlace a la información sobre protección de datos. Es más breve que cualquier muro de ventanas emergentes y se lee con más probabilidad.

La propia entrada se puede orientar. En lugar de un campo de texto abierto para todo, el bot guía por pasos: elegir el motivo, indicar la hora deseada y pedir los datos de contacto solo al final, en campos propios. Los campos estructurados tienen una ventaja que el texto libre no ofrece. Se pueden validar, guardar por separado y borrar de forma selectiva, mientras que un nombre en medio de un párrafo apenas se encuentra.

Para las consultas médicas y otros ámbitos con datos especialmente sensibles rige una línea más estricta. El bot debería limitarse de forma visible a preguntas organizativas y, cuando se describan molestias o síntomas, remitir amablemente al teléfono o a una cita. Es menos una cuestión de tecnología que de delimitación de tareas, y debe figurar en las instrucciones del bot antes de la puesta en marcha.

La implementación técnica empieza donde a menudo se ahorra: en la configuración del historial. Comprobamos si el proveedor ofrece un plazo de conservación configurable, si los historiales pueden borrarse automáticamente y si las conversaciones individuales se pueden localizar mediante un identificador. Si falta alguna de estas funciones, no es un detalle, sino un criterio de selección del proveedor.

El widget de chat solo se carga tras el consentimiento cuando establece conexiones con servidores del proveedor y, por ejemplo, transmite la dirección IP. Si hace falta un consentimiento o si otra base jurídica es suficiente depende de la estructura y corresponde a la revisión jurídica. Técnicamente significa que el chat no se carga automáticamente al abrir la página, sino tras un clic o una consulta. Como efecto secundario, se reduce el tiempo de carga.

Los registros merecen atención propia. Además del historial, los servidores web, la supervisión de errores y las herramientas de análisis suelen guardar datos en los que pueden aparecer mensajes o identificadores. Comprobamos si los contenidos del chat aparecen en texto plano en mensajes de error, reenvíos por correo electrónico o webhooks, y los acortamos o enmascaramos cuando es posible. También los envíos al calendario o al CRM transportan solo los campos que allí se necesitan.

La supresión necesita una vía definida. En la práctica ha dado buen resultado un identificador por conversación, que se arrastra al pasar los datos al sistema posterior. Así, ante una solicitud, se pueden localizar la conversación en el sistema de chat y la entrada correspondiente en el calendario o CRM. Además se fijan plazos automáticos tras los cuales los historiales desaparecen, aunque nadie se acuerde.

El caso especial más frecuente es la revelación no solicitada. Un visitante describe con detalle su enfermedad, la separación de su pareja o sus deudas, aunque la pregunta era solo sobre una cita. El bot no puede impedirlo, pero sí reaccionar con calma: confirmar brevemente, no insistir con preguntas y remitir a la vía de contacto adecuada. Un bot que insiste con afán empeora la situación.

Una particularidad son las conversaciones que el bot interrumpe o no entiende. Los visitantes repiten entonces sus datos, a menudo con más detalle y más personales que antes. Aquí ayuda un traspaso temprano y amable a una persona, antes de que alguien explique su situación por tercera vez. Es buena atención y, al mismo tiempo, minimización de datos.

El segundo caso se refiere a menores y terceros. Quien pide una cita para su madre transmite datos de otra persona. En esas conversaciones el bot debería preguntar solo lo imprescindible y no deducir del historial datos de otras personas. Una verificación de edad generalizada no es fiable en un chat, por lo que ayuda sobre todo una oferta que se dirija claramente a adultos.

Otro caso son los archivos adjuntos. En cuanto los visitantes pueden subir fotos o documentos, por ejemplo una foto del daño o una carta, el volumen de datos crece considerablemente y en las imágenes suelen verse personas, matrículas o direcciones. En un primer paso prescindiríamos de las subidas y remitiríamos en su lugar a una vía aparte con información propia y breve conservación.

En tercer lugar, la solicitud de acceso o supresión. Cuando alguien se pone en contacto, quiere saber qué hay guardado sobre él. Sin un identificador o un dato de contacto en la conversación, esto no se puede responder, y no es un fallo. No se debería recopilar a posteriori características solo para poder atribuir una conversación. La solicitud exige además una verificación de identidad, para que personas no autorizadas no pidan historiales.

Un cuarto caso es la inyección de prompts, es decir, el intento de que el bot, mediante entradas, revele instrucciones internas o datos ajenos. Esto adquiere relevancia para la protección de datos cuando el bot tiene acceso a datos de clientes. Por eso, en caso de duda, no se le da ninguno. La base de conocimiento y los datos de las conversaciones se mantienen separados, y el bot nunca ve más que la conversación actual.

Un concepto limpio reduce riesgos, no los elimina. Hace que las decisiones sean trazables: usted puede explicar qué datos se generan, por qué, dónde están y cuándo desaparecen. Si una construcción concreta es suficiente jurídicamente lo decide en última instancia su asesoría de protección de datos o su delegado de protección de datos. Un concepto de este tipo no puede dar garantía de cumplimiento normativo, y nosotros tampoco la damos.

El avance se puede medir con cosas verificables. ¿Existe un contrato para cada proveedor de servicios implicado? ¿Coincide la política de privacidad con el tratamiento real? ¿Se ejecutan automáticamente los plazos de supresión y se puede demostrar por muestreo con una conversación de prueba? ¿Cuántas conversaciones contienen datos que el bot no debería haber pedido en absoluto? Esto último se puede observar en una muestra de historiales anonimizados durante unas semanas.

También para el negocio hay un beneficio que no se puede cuantificar, pero sí describir. Los visitantes que saben de antemano con quién hablan y qué ocurre con sus datos probablemente abandonan menos las conversaciones. Es una expectativa, no una medición, y si se cumple lo mostrarán las tasas de abandono y las consultas en su chat, comparando antes y después del ajuste. Las cifras al respecto tendrían que proceder de su propio negocio.

Otro punto de control es la coherencia. Si la política de privacidad afirma un plazo de conservación que el sistema no cumple, es peor que un plazo largo pero honesto. Por eso contrastamos el texto y la configuración, no solo una vez antes de la puesta en marcha, sino con cada cambio del chat.

No se puede garantizar que nunca ocurra nada inesperado. Los visitantes escriben lo que quieren, los proveedores cambian las condiciones, los modelos reciben nuevas funciones. Por eso el concepto incluye una revisión periódica, por ejemplo dos veces al año y con cada cambio de proveedor o de modelo.

Primero: la protección de datos en un chatbot es ante todo una tarea de diseño. Quien construye los diálogos de modo que se genere poca información personal tiene menos que proteger, explicar y borrar. Eso reduce al mismo tiempo el esfuerzo de todos los pasos posteriores. Segundo: la documentación debería elaborarse en paralelo a la configuración. Una nota con la fecha, quién configuró qué y por qué vale más después que cualquier reconstrucción a posteriori.

Tercero: los textos de aviso son textos de producto. Deberían estar escritos en el lenguaje del negocio, breves y concretos, sin jerga jurídica en la ventana de chat. La información detallada corresponde a la política de privacidad y se enlaza allí. Probamos con gusto los textos con personas que no conocen el proyecto y les preguntamos qué creen que ocurre con lo que escriben.

Cuarto: el personal forma parte del proceso. Quien gestiona las llamadas solicitadas desde el chat debería saber cuánto tiempo puede conservar los datos, dónde no deben estar y cómo trasladar una solicitud de supresión. Una vía de supresión que nadie conoce solo funciona sobre el papel. Quinto: un chatbot cambia con su base de conocimiento. Cada nueva función, como la reserva de citas o la subida de documentos, exige una breve revaluación del flujo de datos.

Un error frecuente para terminar: más avisos no significan más protección. Un banner que nadie lee no sustituye la minimización de datos, y un consentimiento no sustituye la pregunta de si el tratamiento es necesario. Lo eficaz es lo que reduce el tratamiento, no lo que solo lo anuncia.

Un chatbot web puede aliviar consultas y ayudar antes a los visitantes. Al hacerlo, trata declaraciones que los visitantes escriben creyendo mantener una conversación. Esta diferencia con el formulario es el núcleo de la tarea. Quien conoce el recorrido de los datos, ha aclarado roles y contratos, incluye el aviso sobre la IA y fija plazos de conservación y supresión, ha respondido a las preguntas esenciales antes de que alguien las haga.

El siguiente paso es pequeño: dibuje por qué estaciones pasa un mensaje en su chat y anote lo que sabe sobre la ubicación, el almacenamiento y el contrato de cada una. Las lagunas son los temas para su asesoría de protección de datos. Le ayudamos con gusto en la parte técnica de este inventario y en la redacción de textos de aviso y diálogos.

Para ser honestos, hay que añadir: la valoración jurídica sigue en sus manos y en las de su asesoría. Nosotros aportamos la tecnología verificable y una documentación que responde a preguntas en lugar de plantear otras nuevas. Eso ahorra tiempo en cada conversación posterior.

Para los negocios pequeños el esfuerzo es asumible si se hace pronto. Un inventario del flujo de datos, un borrador de los textos de aviso y la configuración de los plazos se pueden preparar en pocos días laborables. Resulta caro cuando hay que poner en orden a posteriori un chat en funcionamiento con cientos de conversaciones. El calendario siguiente muestra una posible secuencia.