Chatbot con inteligencia artificial para ayuntamientos: cómo diseñar atención ciudadana útil y segura

Un chatbot con inteligencia artificial para un ayuntamiento puede ayudar a responder preguntas frecuentes, orientar sobre trámites, localizar información institucional y reducir consultas repetitivas. Sin embargo, un asistente público no debería limitarse a conectar un modelo generativo con la web municipal. Para ser útil necesita fuentes fiables, límites claros, integración con contenidos oficiales, escalado a personas y un sistema de evaluación continua.

El objetivo no es que la IA “sepa de todo”, sino que responda correctamente dentro de un ámbito definido y facilite al ciudadano llegar a la información o servicio adecuado. La calidad depende más del diseño de la base de conocimiento y del gobierno del servicio que del nombre del modelo utilizado.

La inteligencia artificial para servicios públicos debe plantearse con casos de uso concretos, métricas y supervisión. Cuando además se conecta con aplicaciones internas, conviene aplicar los principios de integración mediante APIs.

Qué problemas puede resolver un chatbot municipal

El primer grupo de casos de uso son preguntas repetitivas: horarios, ubicaciones, documentación necesaria, plazos orientativos, enlaces a trámites, actividades, tasas o información de servicios municipales. Estas consultas consumen tiempo en teléfono, correo y atención presencial aunque la respuesta ya exista en la web.

Un segundo grupo incluye orientación: ayudar al usuario a identificar qué trámite necesita, qué canal utilizar o dónde encontrar una convocatoria. El asistente puede formular preguntas para acotar la necesidad sin tomar una decisión administrativa.

También puede servir como capa de acceso a documentación extensa, siempre que las respuestas se apoyen en fuentes oficiales y puedan verificarse.

Qué no debería hacer automáticamente

Un chatbot no debería decidir sobre derechos, emitir resoluciones, interpretar casos complejos como si fuera asesoramiento oficial ni inventar requisitos cuando no dispone de una fuente fiable.

Si la pregunta requiere valoración jurídica o técnica, debe indicarlo y ofrecer un canal humano. El diseño debe definir temas prohibidos o de alto riesgo y comportamientos de salida.

La confianza del ciudadano depende de que el sistema sepa cuándo no puede responder.

Base de conocimiento oficial

La calidad comienza por seleccionar fuentes. Ordenanzas, páginas de trámites, preguntas frecuentes, sedes, convocatorias y documentación institucional pueden formar una base de conocimiento controlada.

No todo el contenido de Internet debería entrar en el sistema. Para atención pública es preferible priorizar documentos aprobados y páginas mantenidas por la entidad.

La digitalización de la Administración Pública se beneficia de disponer de información estructurada y reutilizable, no solo de documentos dispersos.

RAG: responder usando fuentes municipales

Una arquitectura habitual utiliza recuperación aumentada por generación, conocida como RAG. Antes de responder, el sistema busca fragmentos relevantes en la base de conocimiento y utiliza ese contexto para construir la respuesta.

Este enfoque reduce la dependencia del conocimiento general del modelo y permite actualizar información sin volver a entrenarlo. También facilita mostrar enlaces o referencias.

El RAG no elimina por completo los errores. Necesita buen indexado, filtros, evaluación y reglas para no responder cuando la evidencia es insuficiente.

Fuentes y citas visibles

Siempre que sea posible, el usuario debería poder abrir la página o documento que sustenta la respuesta. Esto mejora verificabilidad y permite continuar el trámite en el canal oficial.

Las fuentes también ayudan al equipo municipal a detectar contenidos obsoletos. Si el chatbot falla repetidamente en una pregunta, puede ser una señal de que la información institucional necesita mejorar.

El asistente no debería presentar una afirmación delicada como definitiva si no puede vincularla a una fuente adecuada.

Actualización de contenidos

La información municipal cambia: convocatorias, plazos, horarios, teléfonos, ordenanzas y procedimientos. La base de conocimiento necesita sincronización y control de versiones.

Puede establecerse una importación automática desde fuentes seleccionadas, pero los cambios críticos deben tener responsable. También conviene excluir páginas antiguas o duplicadas.

Un panel de contenidos permite ver última actualización, fuente y estado de indexación.

Integración con la sede electrónica

El chatbot puede orientar al ciudadano hacia el trámite correcto y abrir directamente la página correspondiente. No debería sustituir a la sede electrónica municipal ni crear un canal paralelo sin garantías.

En una fase avanzada, puede recuperar información pública del catálogo de procedimientos para explicar requisitos o pasos.

Las operaciones autenticadas requieren un diseño mucho más estricto y deben separarse de la conversación informativa.

Integración con el catálogo de procedimientos

El asistente puede utilizar referencias de SIA y del catálogo municipal de procedimientos para mantener nombres, enlaces y descripciones coherentes.

Esto evita que el bot utilice denominaciones distintas de las que aparecen en sede o gestor.

Los cambios en un procedimiento deberían actualizar automáticamente los contenidos dependientes.

Integración con sistemas internos

Algunos proyectos quieren consultar estado de solicitudes, citas u otros datos personalizados. Esto ya no es un chatbot informativo simple: implica autenticación, permisos, APIs y tratamiento de datos personales.

La arquitectura de APIs municipales debe definir qué operaciones puede ejecutar el asistente y bajo qué identidad.

Conviene empezar por consultas de bajo riesgo antes de permitir acciones que modifiquen sistemas.

Escalado a atención humana

El asistente debe ofrecer una salida clara cuando no resuelve la consulta. Puede facilitar teléfono, formulario, correo, cita o transferencia a un agente si la infraestructura lo permite.

El escalado debería conservar un resumen de la conversación cuando sea apropiado, evitando que el ciudadano repita todo desde cero.

También conviene medir qué temas generan más escalados para mejorar contenidos o detectar necesidades de servicio.

Diseño conversacional

Las respuestas deben ser breves, comprensibles y orientadas a la siguiente acción. Un chatbot que reproduce páginas completas no mejora la experiencia.

Puede utilizar preguntas aclaratorias cuando el mismo concepto se refiere a varios procedimientos. Los botones y enlaces rápidos también reducen ambigüedad.

El tono debe ser institucional, claro y evitar presentar inferencias como hechos.

Accesibilidad

El widget, teclado, foco, contraste, lectores de pantalla y mensajes deben diseñarse con criterios de accesibilidad. La accesibilidad web para ayuntamientos sigue siendo aplicable aunque la interfaz sea conversacional.

También conviene ofrecer alternativas para personas que no quieren o no pueden utilizar un chatbot.

La tecnología debe ampliar canales, no convertirlos en barreras.

Multilingüismo

Un modelo puede responder en varios idiomas, pero la base de conocimiento y la terminología oficial deben estar controladas. La traducción automática puede ser útil para orientación general, con cautela en contenido jurídico o administrativo específico.

El sistema puede detectar idioma y priorizar documentos disponibles en esa lengua.

Las métricas deberían analizar calidad por idioma y no asumir que el rendimiento es idéntico.

Control de alucinaciones

Uno de los principales riesgos es generar una respuesta plausible pero incorrecta. Para reducirlo se utilizan instrucciones estrictas, RAG, umbrales de relevancia, respuestas de “no dispongo de información suficiente” y pruebas frecuentes.

No basta con configurar una temperatura baja. El control requiere arquitectura y evaluación.

Las preguntas de alto impacto pueden derivarse directamente a una fuente o canal humano.

Guardrails y temas restringidos

El sistema debe saber qué tipos de solicitud no puede atender. Información personal, decisiones administrativas, contenidos ofensivos o intentos de manipular instrucciones requieren reglas específicas.

También es necesario proteger las instrucciones internas y evitar que el usuario obligue al sistema a ignorar sus fuentes.

Los incidentes relevantes deben registrarse para mejorar las defensas.

Protección frente a prompt injection

Cuando el asistente recupera contenido de páginas y documentos, esos textos deben tratarse como datos, no como instrucciones. Un documento malicioso podría contener frases destinadas a cambiar el comportamiento del modelo.

La arquitectura debe separar instrucciones del sistema, datos recuperados y entrada del usuario.

Las pruebas de seguridad deberían incluir ataques de prompt injection y extracción de información.

Protección de datos

Un chatbot público debería minimizar la información personal solicitada. Si el servicio es informativo, normalmente no necesita que el usuario escriba datos sensibles.

Cuando existen funciones autenticadas, debe definirse finalidad, base de tratamiento, conservación, proveedores y localización del procesamiento según corresponda.

Los logs de conversación también requieren una política clara y no deberían conservarse indefinidamente por defecto.

Seguridad y ENS

La arquitectura debe contemplar identidades, permisos, logs, cifrado, secretos, continuidad y terceros. La guía del ENS para ayuntamientos ayuda a incorporar estos elementos al proyecto.

Las claves de proveedores de IA o búsqueda no deberían exponerse en el navegador ni incluirse en código público.

Los accesos técnicos deben ser revocables y quedar bajo control institucional.

Modelo propio, API o plataforma

La entidad puede utilizar un servicio de modelo mediante API, una plataforma de chatbot o infraestructura más controlada. La elección depende de coste, seguridad, volumen, funcionalidades y capacidad de mantenimiento.

No siempre compensa alojar un modelo propio. Tampoco conviene elegir una plataforma cerrada sin analizar exportación de datos, documentación e integraciones.

La decisión debe considerar coste total durante la vida del servicio.

Coste por uso

Los modelos generativos suelen tener costes variables según volumen y tamaño de las conversaciones. La arquitectura puede reducir consumo mediante respuestas cacheadas, modelos adecuados a cada tarea y límites de contexto.

El contrato debería explicar qué costes de terceros existen y cómo se monitorizan.

Un dashboard puede mostrar conversaciones, tokens o unidades de consumo y coste estimado.

Pruebas funcionales

Antes de publicar, conviene preparar un banco de preguntas reales: fáciles, ambiguas, desactualizadas, con errores ortográficos, en varios idiomas y fuera de ámbito.

Cada respuesta puede evaluarse por exactitud, utilidad, fuente, tono y capacidad de reconocer límites.

Las pruebas deben repetirse después de cambios importantes en modelo, instrucciones o base de conocimiento.

Red teaming

Además de preguntas normales, el equipo debe intentar romper el sistema: pedir datos que no debería dar, forzar instrucciones, provocar contenido inventado o manipular fuentes.

Estas pruebas ayudan a descubrir fallos antes que los usuarios.

El resultado debe convertirse en reglas, filtros o nuevos casos de evaluación.

KPI del servicio

Pueden medirse porcentaje de consultas resueltas sin escalado, satisfacción, fuentes abiertas, tasa de respuestas sin evidencia, temas más preguntados y tiempo de respuesta.

También es útil medir errores detectados y conversaciones que terminan en canal humano.

El objetivo no debe ser maximizar conversaciones, sino resolver necesidades correctamente.

Analítica para mejorar servicios

Las preguntas agregadas pueden mostrar qué trámites generan confusión, qué contenidos faltan o qué información busca la ciudadanía con frecuencia.

Esta analítica debe utilizar datos agregados y minimizar exposición personal.

Puede convertirse en una fuente de mejora para web, sede y atención presencial.

Integración con la web institucional

El chatbot debe cargarse de forma eficiente, no bloquear el rendimiento y respetar preferencias de privacidad. También debe funcionar correctamente en móvil.

La página de diseño web para ayuntamientos muestra la importancia de una experiencia institucional coherente.

El asistente puede incorporarse primero en páginas de trámites y ampliar después.

Mantenimiento de la base de conocimiento

Un chatbot no es un proyecto de una sola entrega. Nuevos procedimientos, cambios normativos, eventos y contenidos requieren actualización.

El servicio de mantenimiento y soporte puede incluir sincronización, revisión de fallos, nuevas pruebas y control de costes.

Conviene definir responsables funcionales además de técnicos.

Gobierno del asistente

La entidad debería mantener versión del prompt principal, modelos utilizados, fuentes, políticas, métricas, incidencias y cambios. La PMO de transformación digital puede incorporar este servicio a la cartera tecnológica.

Los cambios significativos deben pasar por prueba antes de producción.

El gobierno evita que el asistente evolucione mediante ajustes informales sin evidencia.

Cómo preparar la contratación

El pliego debe definir casos de uso, fuentes, idiomas, integraciones, seguridad, accesibilidad, métricas, pruebas, mantenimiento y condiciones de salida. No basta con pedir “un chatbot con IA”.

La redacción de pliegos técnicos debería exigir una metodología de evaluación y criterios de aceptación.

También conviene definir propiedad de configuraciones, acceso a logs, exportación y reversibilidad.

Desarrollo a medida frente a plataforma cerrada

Una plataforma puede acelerar la puesta en marcha, mientras que un desarrollo propio ofrece más control e integración. La guía sobre software a medida para Administraciones Públicas permite comparar control, mantenimiento y dependencia.

En muchos casos funciona un modelo híbrido: componentes comerciales para modelos o búsqueda y una capa propia para gobierno, fuentes e integraciones.

La arquitectura debería permitir cambiar de proveedor de modelo sin reconstruir todo el servicio.

Qué puede aportar BlackHold Consulting

BlackHold Consulting trabaja en agentes de inteligencia artificial, automatización de procesos con IA, automatizaciones administrativas y consultoría tecnológica e IA.

También dispone de capacidades en IA para gestión documental, automatización de procesos complejos, digitalización e integración de flujos y servicios de automatización. Estas capacidades pueden aplicarse a proyectos públicos mediante el procedimiento de contratación correspondiente.

Checklist para un chatbot municipal

Casos de uso

El ámbito está delimitado y no intenta resolver cualquier pregunta.

Fuentes

La base de conocimiento utiliza contenidos oficiales y actualizados.

RAG

Las respuestas recuperan evidencia y pueden mostrar referencias.

Escalado

Existe un canal humano claro cuando el bot no puede ayudar.

Seguridad

Prompt injection, permisos, secretos y logs están controlados.

Accesibilidad

El widget funciona con teclado y tecnologías de apoyo.

KPI

Se mide calidad, resolución, errores y satisfacción.

Mantenimiento

Fuentes, modelo y evaluaciones se revisan periódicamente.

Preguntas frecuentes

Conclusión

Un chatbot con inteligencia artificial para un ayuntamiento puede mejorar la atención ciudadana si se diseña como un servicio institucional, no como una demostración tecnológica. Fuentes oficiales, RAG, límites, seguridad, accesibilidad y escalado humano son elementos esenciales.

La implantación debería comenzar con un ámbito controlado y preguntas de alto volumen, medir resultados y ampliar solo cuando la calidad esté demostrada.

Cuando el proyecto necesita integración con web, sede, sistemas internos o automatizaciones, un equipo especializado en IA y desarrollo puede convertir el asistente en una pieza útil de la arquitectura municipal y no en un widget aislado.

Fotografía: Sanket Mishra / Pexels.