La Comisión Europea está impulsando tres nuevos proyectos piloto de inteligencia artificial generativa orientados a la Administración Pública: FLOODS & DROUGHTS, EUNOMIA.AI y EuropAI. Las iniciativas, financiadas bajo una convocatoria del Programa Europa Digital, comenzaron oficialmente el 1 de julio de 2026 y fueron presentadas en septiembre en un encuentro centrado en uno de los grandes problemas actuales del sector público: cómo pasar de pruebas de concepto de IA a servicios que puedan desplegarse con garantías.
Interoperable Europe explica que los proyectos buscan desarrollar, adquirir, probar y desplegar soluciones fiables para servicios públicos. El interés de la iniciativa no está únicamente en los modelos utilizados, sino en los problemas que aparecen cuando una Administración intenta convertir un experimento en una capacidad real: contratación, integración, escalado, gobernanza, datos, seguridad y soporte.
La etapa de los pilotos ya no es suficiente
Durante los últimos años numerosas administraciones han probado asistentes, clasificación automática, generación de texto o búsqueda inteligente. Muchos proyectos funcionan en un entorno controlado, con pocos usuarios y un conjunto limitado de documentos. El salto a producción es bastante más complejo.
Un servicio público necesita autenticación, disponibilidad, protección de datos, trazabilidad, control de errores, atención a incidencias y responsabilidades claras. También tiene que sobrevivir a cambios de proveedor o de modelo. La tecnología puede evolucionar cada pocos meses, mientras que un contrato público puede durar años.
Por eso el debate europeo se está desplazando hacia la industrialización de los casos de uso. El éxito deja de medirse por una demostración llamativa y pasa a depender de métricas operativas, calidad y capacidad de mantenimiento.
Tres proyectos para explorar el despliegue real
Interoperable Europe identifica tres iniciativas: FLOODS & DROUGHTS, EUNOMIA.AI y EuropAI. La Comisión no presenta estos proyectos como una única plataforma pública europea, sino como pilotos diferentes dentro de una línea común de experimentación y despliegue de IA generativa.
El valor de trabajar con varios proyectos está en comparar enfoques. Las Administraciones tienen necesidades muy distintas y una arquitectura válida para un asistente documental puede no ser adecuada para análisis territorial, procedimientos complejos o servicios multilingües.
Las conclusiones pueden ayudar a identificar patrones reutilizables: cómo preparar datos, cómo evaluar modelos, qué cláusulas contractuales funcionan, qué niveles de supervisión se necesitan o cómo medir la calidad.
Contratar IA generativa es diferente a comprar software tradicional
Un programa convencional suele tener un comportamiento relativamente determinista. Un modelo generativo produce resultados probabilísticos y puede cambiar si se actualiza el modelo subyacente. Esto obliga a definir mejor las pruebas de aceptación y el seguimiento posterior.
Los pliegos deberían especificar escenarios de evaluación, fuentes autorizadas, límites de uso, métricas y procedimientos ante respuestas incorrectas. También deben aclarar qué ocurre cuando el proveedor sustituye un modelo por otro o modifica precios y condiciones.
La Administración necesita conservar capacidad de salida. Una arquitectura modular, con APIs y datos separados del proveedor de inferencia, reduce el riesgo de quedar atrapada en una única solución.
Datos públicos: el combustible y también el principal riesgo
La IA generativa puede ofrecer mucho valor cuando trabaja sobre documentación administrativa, pero necesita fuentes de calidad. Si el repositorio contiene versiones antiguas, documentos contradictorios o información sin metadatos, el asistente tendrá dificultades para ofrecer respuestas fiables.
Antes de desplegar un sistema conviene definir qué documentos son fuente oficial, cómo se actualizan y qué permisos existen. Los sistemas de recuperación aumentada por generación, conocidos como RAG, pueden ayudar a anclar respuestas en fuentes concretas, pero no eliminan el riesgo de errores.
La gobernanza del dato y del documento debe preceder al despliegue masivo. En muchos casos el trabajo más importante no será entrenar un modelo, sino ordenar la información que lo alimenta.
Supervisión humana y responsabilidad
En la Administración existe una diferencia fundamental entre ayudar y decidir. Un asistente puede resumir un expediente o proponer un borrador, pero el responsable público debe saber qué parte del resultado procede de una máquina y qué verificación se ha realizado.
Los proyectos deben diseñar puntos de control en función del riesgo. Una herramienta interna de búsqueda puede requerir medidas distintas a un sistema que interactúa directamente con ciudadanía o influye en decisiones administrativas.
La supervisión humana no debe convertirse en una formalidad. Si la persona que valida no dispone de tiempo, contexto o formación para detectar errores, el control existe solo sobre el papel.
Cómo evaluar una IA pública
La evaluación debe realizarse con casos reales y conjuntos de prueba representativos. Algunas métricas pueden medir exactitud factual, capacidad de citar fuentes, porcentaje de consultas sin respuesta, latencia o coste por interacción.
También conviene comprobar comportamiento ante preguntas ambiguas, intentos de manipulación, documentos maliciosos o solicitudes fuera del ámbito autorizado. La ciberseguridad de los sistemas de IA incluye vectores nuevos como prompt injection y manipulación de contexto.
La evaluación debe repetirse cuando cambie el modelo o el repositorio. Un sistema que funcionaba bien en una versión puede degradarse tras una actualización.
Escalabilidad: de cien usuarios a toda una Administración
Un piloto suele tener un coste pequeño porque el número de consultas es reducido. La situación cambia cuando miles de empleados utilizan el servicio. Aparecen límites de capacidad, costes variables y necesidades de soporte.
Antes de escalar conviene estimar consumo, patrones de uso y picos. También hay que decidir qué tareas justifican el coste y cuáles pueden resolverse mediante automatización tradicional más predecible.
La IA no debería añadirse a todos los procesos por defecto. El objetivo es seleccionar problemas donde aporte una mejora medible.
Interoperabilidad y reutilización
Los proyectos europeos se desarrollan dentro de una agenda que da cada vez más importancia a la interoperabilidad. Una solución pública puede tener más valor si sus componentes pueden reutilizarse por varias entidades.
Esto requiere documentación, formatos comunes y separación entre capas. Interfaces reutilizables para autenticación, búsqueda documental o evaluación pueden reducir duplicidades.
La reutilización también puede ayudar a Administraciones pequeñas que no disponen de recursos para desarrollar capacidades avanzadas desde cero.
Qué deberían observar las administraciones españolas
Aunque los pilotos sean europeos, sus aprendizajes pueden ser útiles para ministerios, comunidades autónomas, diputaciones y ayuntamientos españoles. El interés está en los patrones de gobernanza y contratación que surjan.
Las entidades que ya estén realizando pilotos deberían documentar resultados de forma comparable: problema inicial, datos utilizados, coste, precisión, riesgos detectados y decisiones de escalado. Sin esa documentación es difícil aprender de los experimentos.
Checklist antes de escalar un piloto de GenAI
- Definir métricas de negocio y servicio público.
- Identificar fuentes oficiales y reglas de actualización.
- Evaluar protección de datos y seguridad.
- Diseñar supervisión humana proporcional al riesgo.
- Crear un conjunto de pruebas representativo.
- Medir coste total a escala.
- Planificar cambios de modelo y proveedor.
- Exigir trazabilidad y registro de interacciones.
- Definir procedimientos de incidente y retirada.
- Documentar aprendizajes para reutilización.
Preguntas frecuentes
¿Cuáles son los tres pilotos?
Interoperable Europe identifica FLOODS & DROUGHTS, EUNOMIA.AI y EuropAI.
¿Cuándo comenzaron?
La información oficial indica que los proyectos comenzaron el 1 de julio de 2026.
¿Qué persiguen?
Desarrollar, adquirir, probar y desplegar soluciones fiables de IA generativa orientadas a servicios públicos.
¿Qué puede aprender un ayuntamiento de estos proyectos?
Principalmente enfoques sobre contratación, datos, evaluación, supervisión y escalabilidad que pueden adaptarse a proyectos de menor tamaño.
Fuente oficial
La información se basa en la publicación de Interoperable Europe sobre el lanzamiento de los pilotos de IA generativa para Administraciones Públicas.
En Digitalización Pública News seguiremos sus resultados y la evolución de la contratación y gobernanza de IA en el sector público.
Qué convierte un piloto en un servicio público estable
La fase de demostración suele centrarse en precisión y experiencia de usuario. La fase de producción añade obligaciones que no son visibles en una demo: autenticación, registro, soporte, continuidad, accesibilidad, seguridad, protección de datos y capacidad de auditar cambios. El proyecto debe presupuestar estas capas desde el inicio.
También necesita un propietario de servicio. Cuando el piloto termina, alguien debe asumir mantenimiento, métricas, incidencias y relación con proveedores. Sin esa transición, muchas pruebas quedan abandonadas aunque hayan mostrado resultados prometedores.
Contratación por capacidades y no por nombres de modelo
Los pliegos pueden quedar obsoletos si especifican una tecnología demasiado concreta. Resulta más sostenible definir capacidades, niveles de calidad, interfaces y restricciones. Así el adjudicatario puede evolucionar componentes sin alterar el objetivo del servicio, siempre que demuestre que mantiene o mejora los indicadores.
La Administración debería conservar derecho a evaluar cambios significativos. Sustituir un modelo puede modificar comportamiento, coste y riesgo, incluso cuando la interfaz permanezca igual.
Datos de prueba representativos
Una IA debe evaluarse con casos que reflejen diversidad de usuarios y documentos. Un conjunto pequeño y limpio puede ocultar problemas que aparecerán con información real: abreviaturas, documentos escaneados, idiomas, excepciones o datos incompletos.
Conviene construir una batería estable de pruebas para comparar versiones. Esto permite detectar regresiones y justificar decisiones de actualización.
Seguridad específica de sistemas generativos
Los asistentes conectados a repositorios pueden ser objetivo de instrucciones maliciosas ocultas en documentos o páginas. La arquitectura debe limitar qué acciones puede ejecutar el sistema y validar las fuentes recuperadas. No debe asumirse que un modelo distingue automáticamente contenido fiable de instrucciones manipuladas.
La separación de permisos es fundamental. Un usuario no debería obtener a través del asistente información a la que no tendría acceso mediante el sistema original.
Coste total y sostenibilidad
El coste de inferencia puede crecer de forma proporcional al uso. Antes de abrir un servicio a miles de personas, la entidad debe estimar consultas, longitud de contexto y picos de demanda. También debe comparar si determinadas tareas pueden resolverse con reglas o búsqueda convencional.
La solución más avanzada no siempre es la más eficiente. Un buen diseño combina automatización tradicional, búsqueda y modelos generativos donde cada técnica aporta valor.
Reutilización entre Administraciones
Los pilotos europeos pueden ser especialmente útiles si producen componentes, metodologías y conjuntos de evaluación reutilizables. Una Administración local no necesita replicar toda la inversión de un gran organismo si puede adoptar patrones ya probados.
Para ello la documentación es clave: arquitectura, decisiones, métricas y problemas encontrados deben acompañar al código o a los componentes compartidos.
Lecturas relacionadas
Este tema conecta con la estrategia europea de IA para el sector público, con Impulsa DATA, con la agenda europea de código abierto y con el uso de IA en redacción legislativa mediante LEOS y EdiT.
Una metodología común para aprender de los pilotos
El valor de tres proyectos distintos aumenta si sus resultados pueden compararse. Para ello conviene documentar de forma homogénea objetivo, usuarios, fuentes, arquitectura, coste, precisión, riesgos y decisiones de despliegue. Sin una metodología común, cada piloto produce conclusiones difíciles de trasladar a otros organismos.
La evaluación también debe incluir aquello que no funcionó. Los fallos de integración, calidad de datos o adopción interna son tan útiles como los casos de éxito porque permiten a otras entidades evitar inversiones similares.
Del prototipo al expediente de contratación
Cuando una prueba demuestra valor, el siguiente paso no debería ser simplemente ampliar la misma cuenta o licencia. Es necesario formalizar requisitos, tratamiento de datos, seguridad, soporte y reversibilidad. La solución productiva puede incluso necesitar una arquitectura diferente a la utilizada en la prueba.
También conviene separar costes de desarrollo, consumo de modelos, almacenamiento y soporte. Esta estructura permite entender cómo variará el presupuesto cuando aumente el número de usuarios.
El papel de las compras públicas de innovación
Algunos casos emergentes pueden requerir fórmulas que permitan experimentar antes de definir un producto cerrado. La contratación pública de innovación puede ser útil cuando el mercado todavía no ofrece una solución madura, siempre dentro del marco jurídico aplicable y con objetivos verificables.
En cualquier modalidad, la Administración debe conservar los datos, resultados y documentación necesarios para poder continuar el proyecto con alternativas futuras.
Qué conviene documentar antes de cerrar cada piloto
Antes de dar por finalizada una prueba, la Administración debería conservar una ficha completa con el problema abordado, arquitectura utilizada, fuentes de datos, usuarios participantes, métricas, incidencias y costes. Esa documentación permite decidir con criterio si el caso de uso debe escalar, repetirse con otro enfoque o descartarse.
También resulta útil registrar qué decisiones fueron específicas del piloto y cuáles podrían convertirse en estándares internos. De este modo, el siguiente proyecto no empieza desde cero y la organización construye una capacidad acumulativa para contratar, evaluar y gobernar sistemas de IA.
Fotografía: Markus Winkler / Pexels.