Un chatbot municipal trata datos. Aunque solo pregunte “¿a qué hora abre el registro?”, a menudo queda un número de teléfono, un nombre, una foto de la calle o un hilo entero en un servidor. El ayuntamiento es responsable del tratamiento. El proveedor, encargado. Darle la vuelta —“lo lleva la empresa de turno”— no cuela ante la AEPD.
La buena noticia: cumplir no obliga a pedir el DNI para todo. Al contrario. El propio asistente de la AEPD resuelve miles de consultas al mes sin identificación ni certificado, 24 horas, con persona en horario laboral. Ese es el listón de sentido común.
Qué marco aplica (sin convertir esto en un máster)
Tres capas, y las tres caben en una reunión con el DPD:
- RGPD y LOPDGDD: bases jurídicas, minimización, plazos, derechos, encargados, violaciones de seguridad.
- Guías de la AEPD para el sector público y para IA: Tecnologías y protección de datos en las AA.PP. y Adecuación al RGPD de tratamientos que incorporan IA.
- Transparencia de IA, que se cruza con el AI Act en ayuntamientos y con nuestras piezas sobre el reglamento europeo y la ley de IA en España.
El chat de ciudadanía no es un juguete de marketing. Es un tratamiento más del inventario. Si no está, el inventario está incompleto.
Base jurídica: no todo es “consentimiento del cookie”
En una administración, el consentimiento del banner casi nunca es la base adecuada para atender al vecino. Suele ser:
- Misión de interés público / ejercicio de poderes públicos (art. 6.1.e RGPD) cuando el chat es un canal de información o de avisos de vía pública.
- Obligación legal si el canal se usa para algo que ya está tasado en una norma (menos frecuente en un chat informativo).
- Consentimiento solo para lo que sobra: newsletters, cesiones no necesarias, grabar la voz “por si acaso”.
Si el chat exige “acepto el tratamiento” para decir el horario de la piscina, estás pidiendo de más y, además, educas mal. Informa (capa 1 + capa 2) y trata lo mínimo.
Minimización: el checklist que evita el 80% de los sustos
Antes de abrir el canal, recorre esto con el DPD o con quien haga esa función:
- Identificación. Horarios, calendarios y requisitos genéricos: sin DNI, sin Cl@ve, sin padrón. La AEPD lo practica en su propio bot. Identidad fuerte solo cuando el trámite la exige —y entonces el sitio correcto suele ser la sede, no el chat.
- Fotos. Útiles en incidencias. Pide que no aparezcan matrículas ni caras de terceros si se puede evitar. No archives la foto “por si un día”.
- Ubicación. La de la farola, no el historial de desplazamientos del vecino.
- Conversaciones. Conserva lo necesario para resolver, auditar y defender un expediente breve. No eternices el saludo de las 3:00.
- Datos especiales. Salud, ideología, infracciones. Un chat de ayuntamiento no es el sitio. Si alguien los suelta, se minimiza, se deriva y no se usa para entrenar nada.
- Encargado. Contrato art. 28, ubicación de servidores, subencargados, qué pasa con los logs del modelo de IA. “Está en la nube” no es una respuesta.
Evaluación de impacto: ¿hace falta?
No todo chatbot exige una EIPD. Sí hay que argumentar por qué sí o por qué no. Pistas que empujan hacia sí:
- Cruce con padrón, tributos o servicios sociales.
- Decisiones que afecten derechos (acceso a una ayuda, prioridad de una cita).
- Grabación sistemática, voz, o reutilización de chats para entrenar modelos.
- Menores como público principal (actividades, escuelas, becas).
Un bot que solo lee FAQs públicas y escala a humano, con retención corta, suele quedar en análisis de riesgo documentado. Uno que “resuelve el padrón por WhatsApp”, no. La AEPD, en la guía de IA, insiste en legitimación, transparencia, exactitud y decisiones automatizadas: un chat municipal no debería decidir sobre un derecho. Orienta o pasa a persona.
Transparencia hacia el vecino
El primer mensaje no es un adorno legal. Es el servicio:
- Quién es el responsable (el Ayuntamiento de …).
- Que está hablando con un asistente, no con un funcionario.
- Para qué se usan los datos y dónde está la política.
- Cómo ejercer derechos (el canal habitual del DPD, no un laberinto).
- Que el trámite, si existe, se presenta en sede.
Eso alinea RGPD, LOPDGDD y AI Act. Una sola frase bien escrita vale más que un PDF de 40 páginas que nadie abre.
Seguridad que también es protección de datos
Accesos con usuario nominal, no “el móvil de la concejalía”. Copias. Registro de quién lee hilos. Cifrado en tránsito. Baja del personal que se va. Eso es ENS y es RGPD a la vez. Lo desarrollamos en ENS y chatbots de ayuntamiento.
Una violación (un export de chats en un Excel por correo personal) se notifica como cualquier otra. El canal nuevo no baja el listón.
Encargo y modelos de IA: tres preguntas al proveedor
- ¿Dónde se alojan conversaciones y ficheros, y bajo qué derecho?
- ¿Se usan nuestros hilos para entrenar un modelo ajeno? La respuesta por defecto debe ser no.
- ¿Quién puede leer un chat concreto, con qué trazabilidad?
Si no hay respuesta escrita, no hay encargado. Hay un riesgo.
Cerrar el círculo
Inventario del tratamiento, textos de transparencia, minimización de hecho (no solo en la política), contrato de encargado, retención, derechos, y un humano al que escalar. El chat de atención ciudadana se sostiene si esto está resuelto antes del recorte de prensa.
En Infuse los asistentes se diseñan con supervisión humana y con este checklist encima de la mesa, no como anexo. Si lo quieres aplicado a tu entidad, contacto.
La ficha de producto (sin nombres de municipio) está en ayuntamientos.