EUNOMIA.AI desarrollará y probará soluciones de inteligencia artificial generativa para mejorar servicios públicos, simplificación administrativa y trabajo interno de las Administraciones europeas.
El proyecto, financiado por Digital Europe, tiene una duración prevista de 36 meses y reúne a 33 organizaciones de 13 Estados miembros y Noruega.
Qué se ha publicado
Los pilotos cubrirán simplificación administrativa, cumplimiento normativo, rules-as-code, asistencia virtual a ciudadanía y empleados y automatización de procesos documentales.
La novedad tiene interés para las Administraciones porque afecta a inteligencia artificial generativa, simplificación administrativa y servicios públicos. Su valor dependerá de cómo se traduzca en arquitectura, procedimientos, contratos y capacidades internas.
Qué significa para el sector público
El enfoque combina Administraciones, investigación y proveedores para probar casos reales y producir modelos de implantación reutilizables.
La transformación digital pública requiere combinar eficiencia con control, interoperabilidad, seguridad y capacidad de revisión.
Datos e interoperabilidad
Los pilotos tendrán que documentar fuentes, permisos, calidad y tratamiento de documentos para que los sistemas generativos puedan evaluarse y auditarse.
Las organizaciones deberían documentar fuentes, responsables, formatos, versiones y reglas de acceso. Los estándares y APIs reducen integraciones exclusivas.
Seguridad y soberanía
El proyecto integra requisitos legales, éticos, de ciberseguridad y protección de datos durante desarrollo y despliegue.
La autonomía tecnológica implica conservar capacidad de entender, supervisar, operar o sustituir componentes críticos.
Contratación pública
Las Administraciones participantes ayudarán a definir cómo adquirir y probar soluciones europeas adaptadas a requisitos públicos.
Los pliegos pueden exigir portabilidad, documentación, interfaces, niveles de servicio y reversibilidad.
Capacitación
Los empleados deberán aprender a supervisar resultados generativos, detectar errores y utilizar sistemas de forma responsable.
La disponibilidad de tecnología no sustituye conocimiento interno. Los equipos necesitan saber evaluar resultados, riesgos, costes y dependencia.
Cómo medir resultados
Precisión, tiempo ahorrado, accesibilidad, carga de revisión, incidencias y reutilización entre organismos pueden medir resultados.
Las métricas de adopción deben complementarse con impacto: tiempo ahorrado, calidad, coste, incidencias, disponibilidad o reutilización.
Riesgos y límites
La generación de texto o análisis puede producir respuestas incorrectas, por lo que la supervisión y los conjuntos de prueba serán esenciales.
También conviene evitar que una iniciativa común se convierta en un nuevo punto de dependencia. La gobernanza y la capacidad de salida deben diseñarse desde el inicio.
Qué debería revisar una Administración española
- Compatibilidad con sistemas existentes.
- Propiedad y gobierno de los datos.
- Seguridad y privacidad.
- Licencias y capacidad de operación.
- Portabilidad y reversibilidad.
- Coste total del ciclo de vida.
- Capacitación de usuarios y equipos técnicos.
- Métricas y criterios de continuidad.
Qué habrá que observar
Habrá que observar qué pilotos llegan a producción y qué blueprints, modelos de gobernanza y buenas prácticas se publican para reutilización.
La evolución deberá medirse por adopción real, calidad, resultados y capacidad de reutilización. Los anuncios y pilotos son un punto de partida, no una prueba automática de impacto.
Preguntas frecuentes
¿Quién impulsa la iniciativa?
El consorcio EUNOMIA.AI con apoyo del programa Digital Europe de la Comisión Europea.
¿Es obligatoria para todas las Administraciones?
No. Es un proyecto piloto y de desarrollo, no una obligación para todas las Administraciones.
¿Qué aporta principalmente?
Probar GenAI europea, abierta y reutilizable en procesos públicos concretos con cumplimiento integrado.
Fuentes
La información principal procede de Comisión Europea.
Lecturas relacionadas
Puede ampliarse contexto con nuestros análisis sobre código abierto, gobierno del dato, interoperabilidad semántica y IA pública europea.
Cómo convertir EUNOMIA.AI administraciones públicas en una capacidad pública sostenible
La adopción de una nueva capacidad digital debería comenzar con un diagnóstico de la situación actual. Antes de ampliar tecnología conviene identificar qué procesos se quieren mejorar, qué sistemas ya existen, qué datos están disponibles y quién responde por ellos. Esta fase evita duplicidades y ayuda a separar necesidades reales de funcionalidades simplemente atractivas.
También resulta útil construir una línea base con tiempos, costes, incidencias, calidad y nivel de uso. Sin una referencia previa, la organización puede saber que ha desplegado una herramienta, pero no si realmente ha mejorado el servicio. La comparación posterior debe apoyarse en indicadores definidos antes de empezar.
La gobernanza debe asignar responsables funcionales, técnicos y de datos. Cuando estas funciones no están claras, los problemas operativos suelen terminar trasladándose al proveedor aunque su origen sea una decisión organizativa, una fuente de información o una regla de negocio.
Arquitectura por capas y capacidad de evolución
Una arquitectura pública sostenible separa datos, integración, lógica de negocio, analítica y presentación. Esta estructura permite sustituir un componente sin reconstruir el conjunto y facilita que diferentes proveedores puedan participar en capas distintas. También reduce el impacto de cambios de licencia, producto o infraestructura.
La Administración debería conservar bajo su control los identificadores principales, los modelos de datos, las credenciales maestras y las reglas de negocio. Las herramientas de visualización, motores de inteligencia artificial o soluciones de automatización pueden cambiar con rapidez; el conocimiento estructural del servicio no debería cambiar con ellas.
Los entornos de desarrollo, pruebas y producción deberían estar claramente separados. Los cambios relevantes necesitan control de versiones, pruebas automatizadas cuando sea posible y capacidad de volver a una versión anterior si aparece una regresión.
Calidad del dato y trazabilidad
La calidad de la información debe gestionarse durante todo el ciclo de vida. Una limpieza inicial no es suficiente porque los sistemas origen evolucionan, aparecen nuevas excepciones y las reglas cambian. Cada fuente debería disponer de controles sobre completitud, coherencia, duplicados y actualización.
Los errores detectados deberían corregirse en origen siempre que sea posible. Si cada cuadro de mando o aplicación aplica su propia corrección, las copias divergen y los usuarios terminan trabajando con cifras diferentes. Un procedimiento común de calidad evita que los mismos problemas se reproduzcan.
El linaje de datos también aporta valor: registrar de dónde procede una información, qué transformaciones ha sufrido y cuándo se actualizó permite explicar resultados, investigar incidencias y reconstruir decisiones. Esta trazabilidad es especialmente importante cuando se utiliza analítica avanzada o IA.
Pruebas con situaciones reales y de fallo
Las pruebas no deberían limitarse al escenario correcto. Datos incompletos, credenciales caducadas, servicios lentos, APIs no disponibles, formatos inesperados o cambios de versión deben formar parte de la batería. Un sistema que solo funciona en condiciones ideales puede generar una gran carga cuando entra en producción.
Automatizar pruebas reduce el coste de cada actualización y permite detectar regresiones antes de que afecten a usuarios. Además, la evidencia generada sirve para aceptar entregas de proveedores con criterios objetivos y no solo mediante una demostración puntual.
La reversibilidad también debería probarse. Exportar datos, reconstruir configuraciones, restaurar una copia o conectar un componente alternativo en un entorno controlado permite comprobar si la independencia tecnológica es real.
Observabilidad, soporte y respuesta ante incidencias
Todo servicio necesita registros que permitan seguir una operación de extremo a extremo. Identificadores de transacción, tiempos, sistemas implicados y resultado ayudan a localizar dónde se produjo un fallo sin almacenar más información de la necesaria.
Los cuadros de mando operativos deberían centrarse en señales que permitan actuar: disponibilidad, latencia, errores, calidad, consumo y saturación. Acumular métricas sin responsables ni umbrales claros genera ruido y no mejora la operación.
El soporte debería distinguir incidencias funcionales, problemas de datos, integración, seguridad e infraestructura. Esta clasificación facilita que cada caso llegue al equipo adecuado y permite identificar qué tipos de problema se repiten.
Seguridad de la cadena tecnológica
Los servicios digitales públicos dependen de librerías, certificados, plataformas, proveedores y servicios externos. Mantener un inventario de componentes y versiones ayuda a responder ante vulnerabilidades y cambios de soporte. Esta visibilidad es especialmente importante cuando un componente se reutiliza en muchos servicios.
Las identidades técnicas merecen la misma atención que las cuentas de usuario. Certificados, secretos de API y cuentas de servicio deben tener propietario, fecha de renovación, nivel de privilegio y mecanismo de revocación.
También conviene revisar periódicamente permisos. Una cuenta creada para un piloto no debería conservar indefinidamente accesos amplios cuando el alcance del proyecto cambia.
Capacitación y transferencia de conocimiento
La organización necesita conocimiento suficiente para comprender el servicio y supervisarlo. Los usuarios funcionales deben conocer límites y excepciones; los equipos técnicos, arquitectura y resolución de incidencias; y los responsables, métricas, riesgos, costes y dependencia.
La documentación debe mantenerse junto con las versiones. Diagramas, procedimientos, configuraciones, ejemplos y contactos son activos operativos. Una guía obsoleta puede ser más peligrosa que no disponer de guía porque induce a ejecutar pasos que ya no son válidos.
La transferencia de conocimiento debería formar parte de los entregables contractuales. El objetivo es que un nuevo equipo pueda entender el sistema sin depender exclusivamente de las personas que participaron en su construcción.
Coste total y sostenibilidad
El coste de una solución no termina con la implantación. Infraestructura, almacenamiento, conectividad, soporte, licencias, personal, monitorización, auditorías y futuras migraciones forman parte del ciclo de vida. Estas partidas deberían incluirse en la comparación entre alternativas.
También conviene modelar escenarios de crecimiento. Más usuarios, documentos, consultas, integraciones o inferencias de IA pueden aumentar el consumo de forma no lineal. Una arquitectura sostenible debe permitir controlar gasto y detectar qué componentes concentran coste.
La sostenibilidad incluye la capacidad de simplificar. Mantener funciones con poco uso aumenta complejidad, superficie de riesgo y carga de soporte. Las revisiones periódicas deberían permitir retirar lo que no aporta valor.
Cómo evaluar el valor seis meses después
Seis meses después del despliegue conviene revisar adopción real, incidencias, tiempos, costes, calidad y satisfacción. Esta evaluación permite detectar si los usuarios han incorporado la nueva capacidad o continúan utilizando procesos anteriores en paralelo.
Los resultados deben compararse con la línea base inicial. Si no mejora el indicador que justificó el proyecto, la organización debería ajustar alcance, proceso o tecnología aunque el sistema funcione técnicamente.
Documentar lo aprendido convierte cada implantación en conocimiento reutilizable. Los problemas, decisiones y soluciones pueden servir para nuevos proyectos dentro de la misma Administración o para otras entidades que afronten retos similares.
Conclusión
EUNOMIA.AI reúne 33 organizaciones para probar GenAI pública en simplificación, reglas y asistencia tendrá más valor si se trata como una capacidad que debe operar, medirse y evolucionar, no como una implantación puntual. Datos, arquitectura, seguridad, gobernanza y conocimiento interno determinarán su utilidad a largo plazo.
El objetivo final debería ser conservar capacidad de decisión: saber qué funciona, cuánto cuesta, cómo cambiarlo y qué hacer si un componente deja de ser adecuado. Esa autonomía es una parte esencial de la transformación digital pública.
GenAI pública: simplificación, reglas y asistencia no son el mismo problema
Los casos que explora EUNOMIA.AI abarcan necesidades diferentes. Simplificar texto administrativo, interpretar reglas o asistir a una persona requiere fuentes, métricas y controles distintos.
Separar estos casos evita utilizar el mismo modelo y el mismo criterio de éxito para tareas con riesgos muy diferentes.
Evaluación con conjuntos de prueba públicos y comparables
Una iniciativa europea con 33 organizaciones puede aportar valor si construye datasets y métricas comparables. Esto permitiría saber qué modelos funcionan mejor en distintos idiomas, dominios y tipos de tarea.
Los conjuntos de evaluación deberían incluir excepciones, lenguaje ambiguo y documentos extensos, no solo ejemplos sencillos.
Supervisión humana proporcional
Un asistente que propone una redacción puede requerir una revisión distinta a un sistema que interpreta una regla y desencadena una acción. La gobernanza debería adaptar el nivel de supervisión al impacto del resultado.
También conviene medir cuánta carga añade la revisión: si cada respuesta necesita ser rehacida por completo, la automatización puede no aportar ahorro.
Reutilización europea
El principal potencial de EUNOMIA.AI está en producir componentes, guías y aprendizajes que sirvan a más de una Administración. Los resultados deberían documentar arquitectura, modelos, prompts, datasets, métricas y limitaciones.
Esta reutilización puede reducir pilotos duplicados y ayudar a que organismos con menos capacidad técnica adopten soluciones ya evaluadas.
Qué habrá que observar
Será especialmente relevante conocer qué casos llegan a producción, qué métricas alcanzan y cómo se gestionan privacidad, trazabilidad y seguridad. La calidad del proyecto se medirá por resultados verificables y no únicamente por el número de pilotos.
También será importante conocer cómo se documentan los resultados negativos. Un caso de uso que no alcance precisión suficiente puede aportar aprendizaje si explica limitaciones, costes y motivos. Esa transparencia evita que otras Administraciones repitan pruebas con el mismo enfoque sin conocer sus problemas.
La publicación de métricas comunes también permitiría comparar enfoques sin depender de demostraciones comerciales. Precisión, tiempo ahorrado, tasa de revisión, coste por tarea y errores por idioma pueden convertirse en una base objetiva para decidir qué componentes reutilizar y cuáles necesitan más investigación antes de llegar a producción.
Fotografía: Vladimir Srajber / Pexels.