Modelos LLM de código abierto para ayuntamientos: despliegue soberano y seguro

La adopción de modelos de lenguaje grandes (LLM) de código abierto ofrece a los ayuntamientos una vía práctica para disponer de capacidades de IA generativa sin depender exclusivamente de grandes proveedores cloud. Pero el objetivo no es ejecutar el mayor modelo posible: se trata de elegir, desplegar y operar modelos que respeten la soberanía de los datos, cumplan ENS y RGPD, y sean sostenibles en coste y operación. Esta guía práctica propone criterios claros y pasos accionables para equipos técnicos y responsables de TI.

¿Por qué optar por LLM open‑source y de pequeño/medio tamaño?

• Control de datos y soberanía: permite mantener datos sensibles dentro de la infraestructura administrativa (on‑prem o cloud certificado).
• Costes predecibles: modelos pequeños requieren menos GPU/CPU y reducen gasto operativo.
• Transparencia y gobernanza: facilitan auditoría técnica y revisión de comportamiento frente a modelos cerrados.
• Flexibilidad de adaptación: pueden ajustarse para dominios locales (ordenanzas, trámites, vocabulario municipal).

Checklist de evaluación previa

Antes de seleccionar un modelo y arquitectura, valide:

• Licencia del modelo: compatible con uso público/administrativo y con procesos de contratación.
• Requerimientos de datos: ¿es necesario fine‑tuning con datos municipales? ¿contiene datos personales?
• Riesgos de fuga de datos (memorization): comprobar prácticas de mitigación antes de ponerlo en producción.
• Tamaño y latencia: estimar tiempos de respuesta aceptables para servicios ciudadanos.
• Requisitos de hardware y coste estimado de inferencia por solicitud.
• Compatibilidad con herramientas de observabilidad y pipelines CI/CD.

Opciones de despliegue prácticas

• On‑prem en centro municipal o data center comunitario
  • Ventajas: máximo control, facilita cumplimiento ENS.
  • Requisitos: infraestructura (GPU/CPU), refrigeración, mantenimiento.
• Cloud soberano o proveedor con hosting en España/UE
  • Permite SLA y soporte sin salir de jurisdicción europea.
  • Verificar certificaciones (ENS, ISO/IEC) y cláusulas de tratamiento de datos.
• Edge o servidores ligeros para servicios internos
  • Modelos de tamaño reducido (quantized) pueden ejecutarse en CPU para asistentes internos.
• Arquitectura híbrida
  • Inferencia sensible on‑prem, tareas menos críticas en cloud. Importante trazar flujos de datos y controles.

Seguridad y cumplimiento (ENS, RGPD, EU AI Act)

• ENS (RD 311/2022)
  • Clasificar el sistema según su nivel (bajo, medio, alto) y aplicar controles equivalentes (gestión de identidades, cifrado, registros de acceso).
  • Mantener inventario de activos y documentación de arquitectura.
• RGPD
  • Realizar una EIPD (Evaluación de Impacto) si el tratamiento implica riesgos significativos (perfilado automatizado o tratamiento de datos sensibles).
  • Minimizar datos personales en los conjuntos de entrenamiento; usar técnicas de anonimización o pseudonimización.
  • Diseñar procedimientos de ejercicio de derechos (acceso, supresión) cuando proceda.
• EU AI Act
  • Identificar si el sistema califica como «sistema de IA» y su nivel de riesgo; aplicar requisitos de documentación técnica, transparencia y registro cuando corresponda.

Operación y mantenimiento

• Inventario de modelos: mantener un registro (versión, origen, licencia, fines, responsables) — requisito operativo y útil para auditorías.
• Monitorización: métricas de uso, latencia, tasa de errores, y logs de prompts/respuestas con retención limitada y control de acceso.
• Guardrails: filtrado de salida, listas negras/whitelists, y procesos de escalado humano para respuestas sensibles.
• Actualizaciones: plan de parcheo y reentrenado periódico; gestionar cambios de modelo con pruebas A/B y rollback.
• Formación y soporte: capacitaciones para funcionarios que utilicen la herramienta y un canal de soporte técnico.

Consideraciones prácticas de coste y dimensionamiento

• Prueba con modelos cuantizados y de menor tamaño en fase piloto para estimar coste por consulta.
• Empleo de caching y respuestas templadas para reducir inferencias repetidas.
• Dimensionar infra según picos previstos (horario de atención ciudadana) y priorizar cargas críticas.

Contratación y licencias

• Si se contrata integrador, exigir:
  • Claúsulas de responsabilidad y continuidad.
  • Transparencia sobre uso de modelos y terceros.
  • Entrega del inventario y documentación técnica como parte de la aceptación.
• Revisar compatibilidad de licencias open‑source con uso público y con la posibilidad de realizar adaptaciones.

Primeros pasos (roadmap de 60–90 días)

1. Definir caso de uso concreto y criterios de éxito (p. ej. respuestas a FAQs de tributos).
2. Realizar evaluación legal: RGPD, ENS, y ver impacto bajo EU AI Act.
3. Seleccionar 1–2 modelos candidatos y validar licencias.
4. Montar prototipo en entorno aislado con datos sintéticos o anonimizados.
5. Ejecutar pruebas de seguridad y control de fugas.
6. Medir latencia y coste; ajustar arquitectura (quantization, batching).
7. Capacitar equipo piloto y redactar procedimiento de escalado.
8. Revisar resultados y decidir ampliación o rollback.

Takeaway / Acción recomendada Inicie un piloto controlado con un modelo open‑source cuantizado en un entorno aislado y documente desde el primer día el inventario técnico, licencias y EIPD. Esto le permitirá validar valor operativo y cumplir ENS/RGPD antes de escalar. OptimGov puede integrarse con infraestructuras soberanas y facilitar el inventario y gobernanza del despliegue, pero el primer paso debe ser siempre una evaluación legal y técnica clara.