IA para ayuntamientos: qué procesos merece la pena automatizar con modelos abiertos y cómo hacerlo
El ayuntamiento que hemos cogido de ejemplo para este artículo tiene 20.600 habitantes, un secretario y una interventora que firman todo lo que entra y todo lo que sale, diez administrativos y un pleno al mes. Este, en concreto, tiene a dos personas dedicadas a soporte e informática.
Tiene sede electrónica desde 2018, una empresa informática de la comarca que viene cuando algo falla y cero personas dedicadas a implantar IA ni nada parecido.
Es un ayuntamiento perfectamente normal. Y precisamente por eso es un buen sitio para hablar de inteligencia artificial.
Un ayuntamiento pequeño tiene poco que hacer con laboratorios de IA, modelos propios o servidores llenos de GPUs. Su problema es otro: quitar trabajo repetitivo de encima a una plantilla pequeña sin perder el control sobre los datos ni sobre las decisiones.
La pregunta útil, por tanto, es esta:
¿Qué trabajo del ayuntamiento merece la pena pasarle a una máquina y cuál debe seguir haciendo una persona?
Esta es la pregunta que les hicimos en una entrevista sobre su caso de uso, y la respuesta es bastante esperanzadora para cómo ha evolucionado la administración en los últimos años. Clasificar documentos. Transcribir plenos. Buscar en ordenanzas. Vigilar subvenciones. Preparar borradores. Extraer datos de facturas.
Papeleo. Aburrido, tedioso y repetitivo.
Y eso es precisamente lo interesante, porque permite mucha automatización.
Este es el caso de un ayuntamiento pequeño, pero hoy usan Helmcode ayuntamientos de 10.000, de 30.000 y de 220.000 habitantes. Con el tamaño cambia el volumen, pero para muchos el tipo de trabajo es el mismo.
IA para ayuntamientos: por dónde empezar
Les hemos preguntado cómo han empezado a implementar la IA. Las ideas de crear un chatbot ciudadano surgieron al principio, pero la realidad es que el trabajo del día a día les sepulta y les impide poder preocuparse de mejorar cosas del municipio.
Así que empezaron por tareas que cumplen cuatro condiciones: tienen bastante volumen, siguen reglas relativamente estables, consumen tiempo de personal cualificado y permiten que una persona revise el resultado antes de que tenga consecuencias.
La idea de estas reglas está clara: no se toman decisiones importantes sin que una persona revise el resultado. Ese filtro deja fuera algunas de las demos más espectaculares de la IA, pero se centra en buena parte del trabajo que de verdad ocupa horas en una administración pequeña.
Hemos creado esta tabla con casos de uso habituales, su riesgo y el potencial de introducir IA en ello.
| Proceso | Volumen habitual | Riesgo | Potencial de automatización |
| --- | --- | --- | --- |
| Clasificación del registro | Alto | Bajo | Alto |
| Transcripción de plenos | Medio | Bajo | Alto |
| Redacción de avisos | Alto | Bajo | Muy alto |
| Consulta de normativa | Medio | Medio | Alto |
| Vigilancia de subvenciones | Medio | Medio | Muy alto |
| Extracción de facturas | Alto | Medio | Alto |
| Resoluciones administrativas | Medio | Alto | Bajo |
Hay una idea importante antes de seguir: la IA prepara y el funcionario decide. En los casos que siguen, esa es la regla. Vamos a ver el detalle de algunos casos de uso.
1. Registro de entrada: que alguien deje de clasificar PDFs a mano, por favor
Cada mañana entran instancias por la sede electrónica: una queja por ruidos, una solicitud de licencia de obra menor, una alegación, la renovación de una terraza. Alguien tiene que abrirlas, entender de qué van, identificar al solicitante, introducir la información en el gestor de expedientes y mandarlas al departamento correspondiente.
Aquí la IA no tiene que tomar ninguna decisión administrativa. Hace la primera pasada: clasifica el tipo de trámite, extrae solicitante, asunto y referencias, identifica la documentación adjunta, propone el departamento de destino y devuelve los datos estructurados al gestor. El funcionario comprueba la propuesta y corrige cuando hace falta.
La arquitectura es sencilla: sede electrónica → documento → modelo → datos estructurados → gestor de expedientes → revisión humana.
Y el modelo no necesita ser gigantesco: clasificación y extracción son justo las tareas donde los modelos pequeños rinden mejor por coste. En este caso, lo están haciendo con Gemma4.
Se están clasificando una media de 30 instancias al día en este ayuntamiento. Unas 11.000 al año.
No todo es automático y bonito. ¿Dónde falla? En los sitios que ya son difíciles para una persona. Un escaneo torcido de un PDF seguirá siendo un escaneo torcido y una instancia con lenguaje ambiguo seguirá siendo ambigua. En esos casos, se deriva a la cola humana.
2. Actas de pleno: pasar de transcribir a revisar
Pregúntale a un secretario cuánto tarda en convertir un pleno de dos horas en un borrador de acta. La respuesta probablemente empiece por "depende" y termine en unas horas de la jornada. Y el problema no acaba en el pleno: están las juntas de gobierno, las comisiones y las mesas de contratación, que también hay que documentar.
El flujo tiene dos piezas. Primero, un modelo abierto de reconocimiento de voz como Whisper convierte el audio en una transcripción. Después, un modelo de lenguaje estructura esa transcripción siguiendo la plantilla del ayuntamiento: asistentes, orden del día, intervenciones resumidas, propuestas, acuerdos y resultado de las votaciones.
El resultado es un borrador de acta. El secretario revisa nombres, intervenciones y votaciones, corrige lo necesario y lo incorpora al procedimiento.
Aquí los errores habituales que se han encontrado: voces que se pisan, nombres propios del pueblo, términos locales y la atribución de quién dijo qué, que nunca es perfecta.
Funciona como una asistencia a la elaboración del acta, no como una automatización cerrada. Hay que revisar, quitar cosas o mejorar la transcripción si algo no ha quedado perfecto. Pero es una cuestión de 10 minutos.
Para arrancar hace falta poco: micrófonos de sala decentes, la plantilla de acta y el hábito de grabar. Muchos plenos ya se retransmiten, así que el audio existe; lo que faltaba era qué hacer con él para que quedara registrado y accesible.
3. Bandos y comunicación: una información, cinco formatos
El jueves cortan el agua en la calle Mayor de 9 a 14 por una obra. Eso son tres datos y alguien tiene que convertirlos en un bando, una noticia para la web, un mensaje para redes sociales, un aviso breve para WhatsApp y, en muchos municipios, una segunda versión de todo en la lengua cooficial.
Aquí sí tiene sentido usar un modelo generativo de forma muy directa. Le das los datos y una plantilla con el estilo institucional y devuelve las distintas versiones de una vez, con la lengua cooficial en la misma pasada. La persona responsable revisa, corrige lo necesario y publica.
Y si los cuatro canales están conectados, se publica en todos con un clic.
Lo que hoy lleva una hora se puede resolver en diez minutos.
4. Subvenciones: probablemente el caso con más retorno
Este es el caso menos útil para los vecinos de manera directa, pero puede ser el más rentable de manera indirecta. Los municipios pequeños viven en buena medida de convocatorias: diputaciones, comunidades autónomas, Administración General del Estado y programas europeos.
Y el problema suele empezar antes de la solicitud: alguien tiene que encontrarlas, leerlas, comprobar si encajan, mirar el plazo y decidir si merece la pena preparar la solicitud.
Una convocatoria puede aparecer un martes con veinte días de plazo, pero si nadie la detecta a tiempo es dinero que el municipio está perdiendo.
Aquí tiene sentido construir un pequeño pipeline "vigilante". El sistema revisa cada semana el BOE, el boletín autonómico, el boletín provincial y los portales de los organismos convocantes, y clasifica cada convocatoria en tres montones según el perfil del municipio: encaja, no encaja, revisar.
Para las que encajan, extrae importe, beneficiarios, plazo, requisitos, documentación y criterios de valoración y deja arrancado un primer esquema de la memoria con lo que ya sabe del ayuntamiento.
La persona responsable sigue decidiendo, pero empieza con una lista corta de oportunidades en lugar de con cientos de páginas por leer. Una sola convocatoria de 30.000 o 40.000 euros recuperada paga la plataforma durante años.
5. Consultar ordenanzas sin buscar en veinte PDFs
Otro escenario mucho más cotidiano: un técnico necesita saber qué fianza establece la ordenanza de ocupación de vía pública, hasta qué hora pueden funcionar las terrazas o qué documentación exige una licencia concreta. La información existe, pero encontrarla es un problema.
Un sistema RAG indexa las ordenanzas, los reglamentos y la documentación interna y permite preguntar en lenguaje natural. Con una condición: la respuesta tiene que enseñar la fuente. Un buscador documental que entiende lenguaje natural.
El problema de las diferentes versiones. Una ordenanza puede tener la versión original de 2009, una modificación de 2014, otra de 2018 y varios documentos publicados en sitios distintos. Si metes todo eso sin ordenar, el sistema recuperará versiones antiguas. La IA no arregla una mala gestión documental; incluso puede hacerla más fácil de ocultar. Por eso preparar el corpus (los datos, los documentos) es parte del proyecto.
¿Tiene sentido ese chatbot o RAG de cara al ciudadano?
No lo han hecho como primer proyecto. Primero lo están probando por dentro y solo cuando el ayuntamiento tenga la documentación ordenada, las versiones controladas, las respuestas evaluadas y un procedimiento para corregir errores, plantearán una interfaz ciudadana.
Con una diferencia fundamental respecto a un chatbot de propósito general: cada respuesta debe poder llevar al ciudadano hasta la fuente y ofrecer siempre una vía para hablar con una persona. Además, desde el 2 de agosto de 2026 son aplicables las obligaciones de transparencia del artículo 50 del AI Act, y la Comisión Europea aprobó en julio las directrices para su aplicación . Por lo que el ciudadano debe saber que está interactuando con un sistema de IA.
Aquí, la ventaja está en evitar llamadas al teléfono: cada consulta de horarios o de papeles que el asistente de IA resuelve a las nueve de la noche es una llamada menos a las nueve de la mañana siguiente.
6. Intervención: mucho trabajo de extracción y poca magia
Intervención tiene otro paquete de tareas hechas a medida para esto: extraer datos de facturas, comparar ofertas, estructurar información de presupuestos, preparar borradores de memorias, resumir documentación, localizar información dentro de expedientes.
Tampoco aquí hace falta que el modelo decida nada; transforma documentos desordenados en información estructurada. Tres presupuestos en PDF → extracción → tabla comparativa → revisión. Una factura → campos estructurados → validación. Lo que hoy es básicamente copiar celdas.
El principio es el mismo que en el registro: la IA hace el trabajo mecánico y el empleado público comprueba el resultado y toma las decisiones que le corresponden.
Dónde no tiene sentido meter IA en un ayuntamiento
Conocer las zonas prohibidas es casi tan importante como conocer las permitidas: muchos funcionarios no conocen la legislación aplicable a la IA, pero llevar esto controlado es lo que te deja defender el proyecto delante de secretaría, del DPD y del pleno. La regla general:
Cuanto más directamente afecta el resultado a los derechos, prestaciones o situación de una persona, más sube el listón de seguridad, supervisión y justificación.
No usar para resoluciones administrativas automatizadas (Ley 40/2015, artículo 41)
La Ley 40/2015 contempla expresamente la actuación administrativa automatizada en su artículo 41 : cuando existe, deben establecerse previamente los órganos responsables de la definición, programación, mantenimiento, supervisión y control de calidad, así como el responsable a efectos de impugnación.
Un modelo conectado a una API no convierte por sí solo un procedimiento en una actuación administrativa automatizada conforme a ese régimen, porque la revisión y la decisión siempre están en un humano. Por eso este artículo habla de borradores y asistencia.
No poner un modelo a decidir aquello que afecta directamente a las personas (alto riesgo en el AI Act)
El AI Act considera de alto riesgo, en su Anexo III, determinados sistemas utilizados por autoridades públicas para evaluar la elegibilidad de personas para servicios y prestaciones esenciales.
¿Modelo abierto, ChatGPT, API extranjera o servidor propio?
Esta es probablemente la pregunta que aparece después de leer todo lo anterior. La respuesta es que depende de los datos, del proveedor, del tratamiento y del servicio.
Pero para un ayuntamiento pequeño lo solemos plantear así:
| Opción | Nuestra valoración |
| --- | --- |
| Herramienta de consumo (ejemplo: ChatGPT) para datos municipales | No como política general |
| API de un proveedor externo (Claude, Gemini, etc.) | Depende: hay que revisar tratamiento, transferencias, conservación y contrato |
| Modelo abierto en infraestructura europea | Sí, la opción más interesante |
| Modelo propio entrenado por el ayuntamiento | No tiene sentido en la mayoría de casos |
| Comprar GPUs y montar infraestructura propia | Normalmente tampoco |
Una de las cosas más importantes que llevan los modelos abiertos: soberanía tecnológica no significa operar un centro de datos. Un ayuntamiento de 30.000 habitantes no va a contratar a alguien para mantener GPUs ni hacer inferencia.
Puede usar modelos abiertos desplegados en una infraestructura gestionada, siempre que el proveedor explique dónde se procesa la información, qué se conserva, durante cuánto tiempo y cómo encaja el servicio en los requisitos de seguridad aplicables. El modelo es solo una pieza.
La arquitectura real de un proyecto de IA municipal
Una implementación sencilla tiene cinco piezas:
- El modelo, que hace la tarea.
- La infraestructura, que decide dónde se ejecuta y por dónde pasan los datos.
- La integración, por la que entra la información desde la sede, el gestor de expedientes, el correo o el archivo.
- Los datos, es decir, documentos, ordenanzas, plantillas y contexto que necesita el sistema.
- La gobernanza, que fija quién puede usarlo, qué datos puede introducir, qué se registra, quién revisa los resultados y qué ocurre cuando el modelo falla.
En muchos proyectos se habla muchísimo de la primera pieza y casi nada de las otras cuatro. En un ayuntamiento el modelo puede ser la parte más fácil. Lo más complicado está en la integración y los datos.
RGPD e IA municipal: ¿dónde entra la protección de datos?
¿Qué pasa con los datos personales de los vecinos?
Lo primero es mirar los casos de uso con esa lupa, porque se parecen poco entre sí. Bandos, vigilancia de subvenciones y el buscador interno de ordenanzas apenas tocan datos personales: un corte de agua no lleva DNI, los boletines oficiales son información pública y las ordenanzas tampoco llevan nombres.
Con esos se puede empezar mañana sin abrir ningún melón jurídico.
El registro de entrada, en cambio, es datos personales en estado puro: cada instancia lleva nombre, DNI y dirección, y a veces categorías especiales (una queja puede revelar datos de salud; una solicitud de ayuda social los lleva seguro). Las actas también: la voz de un pleno es un dato personal, y en las intervenciones aparecen vecinos con nombre y apellidos. Las facturas llevan datos de proveedores, que cuando son autónomos son personas físicas. Y el chatbot ciudadano tiene un problema propio: aunque no pidas datos, la gente los escribe.
Los casos ricos en datos siguen siendo tema del RGPD de siempre, aplicados a un encargado nuevo. El ayuntamiento es responsable del tratamiento y el proveedor de inferencia es un encargado: sin contrato de encargado del tratamiento ( artículo 28 del RGPD ) no hay proyecto.
Pero es importante entender bien el papel del encargado del tratamiento:
- ¿Qué conserva el proveedor de inferencia, en este caso nosotros, de cada petición? Helmcode no conserva nada.
- ¿Se utilizan los datos para entrenar modelos? No.
En la práctica, recomendamos anonimizar datos ciudadanos mediante su sustitución por tokens u otras alternativas similares, borrar el contexto entre sesiones y un control de usuarios férreo. Es posible hacerlo de manera segura.
La IA municipal no necesita ser espectacular
Hay una tentación comprensible de empezar por lo vistoso: el chatbot que habla con los ciudadanos, el agente que hace cosas por su cuenta.
Pero un ayuntamiento pequeño saca mucho más valor de algo bastante menos sexy: que una persona deje de abrir 40 PDFs cada lunes. Que nadie tenga que escuchar dos horas de pleno para encontrar dónde se votó un punto concreto. Que una convocatoria de 40.000 euros no pase de largo porque nadie tuvo tiempo de leer el boletín ese día. La IA municipal bien planteada le devuelve a la plantilla tiempo para el trabajo que una máquina no debería hacer.
Tampoco hace falta una gran estrategia de inteligencia artificial para empezar.
Hace falta una pregunta más sencilla: ¿qué tarea repetitiva está consumiendo horas de personas que necesitamos para otra cosa? Y un camino corto: medir cuánto tiempo consume, comprobar qué riesgo tiene, decidir qué parte puede hacer una máquina, mantener revisión humana donde corresponda, elegir dónde y cómo se procesarán los datos, probar durante 90 días y medir el resultado.
Si funciona, se escala; si no funciona, se cambia.
En Helmcode trabajamos precisamente en esa capa: ejecutar modelos abiertos en infraestructura europea para que una organización pueda usar distintos modelos sin construir ni mantener toda la infraestructura de inferencia.
En un entorno público esa capa importa tanto como el modelo: dónde se procesa la información, qué se conserva y cómo se puede controlar el servicio. El detalle de compliance, modelos y despliegue está en la página de sector público .
Un ayuntamiento de 5.000, de 10.000 o de 20.000 habitantes, con un secretario-interventor y tres administrativos, puede usar hoy la misma tecnología que una capital de provincia.
Las preguntas que realmente debería hacerse un ayuntamiento
¿Puedo utilizar ChatGPT en un ayuntamiento?
Antes que la marca, lo que importa es qué datos introduces, qué tratamiento realiza el proveedor, dónde se procesan, qué garantías existen y con qué finalidad. Redactar un texto sin datos personales con una herramienta de consumo es una cosa; enviar una instancia con datos de un vecino a un servicio externo es otra muy distinta. Para datos municipales, el análisis se hace sobre el tratamiento concreto y el proveedor, más que sobre el nombre del modelo o la herramienta.
¿Puede la IA firmar o resolver un expediente?
La actuación administrativa automatizada tiene un régimen específico en el artículo 41 de la Ley 40/2015, con responsabilidades y controles definidos previamente, y conectar un LLM a una API no cumple ese régimen por sí solo. En los casos de uso de este artículo, la IA genera borradores, clasifica, extrae, resume o propone; la decisión administrativa sigue siendo responsabilidad de quien corresponda.
¿Necesito un modelo gigantesco?
No. Para clasificar instancias, extraer campos, transcribir audio o transformar documentos, un modelo pequeño puede ser más que suficiente; los grandes tienen sentido cuando la tarea pide más capacidad de razonamiento o más contexto.
¿Y si mi ayuntamiento no tiene informático?
Como casi ninguno de menos de 20.000 habitantes. Las tres vías reales: la empresa informática que ya os lleva los sistemas, un govtech que lo integre en su producto o el servicio de asistencia de tu diputación.
¿Funciona en valenciano, catalán, gallego o euskera?
Sí, aunque el rendimiento depende del modelo y de la tarea concreta. España cuenta además con iniciativas públicas como ALIA , que desarrolla modelos y recursos abiertos orientados al castellano y las lenguas cooficiales. Para un ayuntamiento bilingüe, lo sensato es evaluar el modelo con documentación municipal real antes de elegirlo.
¿Qué debería pedirle a un proveedor?
Como mínimo:
- dónde ejecuta los modelos;
- dónde se procesan los datos;
- qué información conserva y durante cuánto tiempo;
- quién tiene acceso;
- qué subencargados utiliza;
- cómo elimina los datos;
- qué medidas de seguridad aplica;
- qué documentación puede aportar para el ENS;
- qué modelos utiliza;
- y cómo puede cambiarse de modelo o de proveedor en el futuro.
Esta última pregunta también importa: la administración no debería construir una dependencia tecnológica innecesaria alrededor de un único proveedor.
Si quieres el detalle de qué te exige el AI Act según tu perfil, lo tienes en el checklist y en nuestra guía del AI Act .
