Interoperable Europe ha destacado GovWay como una plataforma abierta de interoperabilidad capaz de gestionar alrededor de 50.000 millones de transacciones anuales en Administraciones de Italia y otros entornos europeos.
El dato se publicó el 15 de septiembre de 2026 tras una sesión de aprendizaje sobre intercambio de datos en la que también se analizó EMREX.
Qué se ha publicado y por qué importa
GovWay funciona como una pasarela API situada en el perímetro de una organización para gobernar y observar flujos de información entre servicios internos y sistemas externos.
La novedad es relevante para las Administraciones porque muestra una forma concreta de abordar problemas que suelen repetirse entre organismos: intercambio de información, arquitectura, gestión de servicios, formación técnica o adopción de nuevas capacidades digitales. El interés no está solo en la herramienta, sino en las reglas y componentes que pueden reutilizarse.
Cómo funciona el enfoque
La plataforma actúa como capa de control para APIs y puede alinearse con marcos europeos como eDelivery y OOTS. La sesión destacó además su capacidad para mediar accesos a servicios externos, incluidos proveedores de IA, sin convertirse ella misma en un modelo de inteligencia artificial.
Una solución pública madura debería separar claramente interfaces, datos, reglas y operación. Esta separación reduce dependencias y permite que cada componente evolucione sin obligar a reconstruir todo el servicio. También facilita que varias organizaciones participen con productos o infraestructuras diferentes.
La documentación técnica y organizativa es tan importante como el software. Cuando existen contratos de datos, perfiles, procedimientos de incorporación y ejemplos de implementación, el coste de adopción disminuye y se reduce el conocimiento informal.
Interoperabilidad técnica y organizativa
El interés de GovWay está en estandarizar la gestión de flujos sin obligar a que todos los sistemas utilicen el mismo producto. Una pasarela común puede aplicar políticas, monitorización y transformación manteniendo las aplicaciones de origen.
La interoperabilidad no consiste únicamente en mover información de un punto a otro. También requiere acordar significado, responsabilidades, gestión de versiones y tratamiento de errores. Dos sistemas pueden comunicarse correctamente y aun así producir resultados inconsistentes si interpretan de forma diferente los datos.
Las Administraciones deberían mantener interfaces documentadas y evitar integraciones basadas en conocimiento exclusivo del proveedor. Los estándares y componentes abiertos permiten que otros equipos puedan auditar, sustituir o ampliar la solución.
Gobierno del dato
El volumen anual citado muestra que la plataforma opera como infraestructura y no como un simple piloto. Ese nivel de uso obliga a diseñar métricas, registros y gobierno que puedan escalar.
Cada conjunto de información necesita un responsable, una frecuencia de actualización, reglas de acceso y criterios de calidad. Esta ficha básica ayuda a distinguir fuentes oficiales de copias operativas y permite saber dónde corregir un error.
El linaje resulta especialmente importante cuando los datos atraviesan varias organizaciones. Registrar origen, transformación y versión permite explicar un resultado y facilita auditorías, análisis de incidencias y migraciones futuras.
Seguridad y privacidad
Una pasarela perimetral permite controlar qué servicios pueden comunicarse y registrar intercambios. Sin embargo, su posición central también exige alta disponibilidad y protección frente a configuraciones incorrectas.
La seguridad debería integrarse desde el diseño con autenticación, autorización, mínimo privilegio, registros, actualización y continuidad. Si existe intercambio entre organismos o proveedores, también deben quedar claras las responsabilidades ante incidentes.
La minimización de datos es una regla útil incluso cuando no se trata de información especialmente sensible. Reducir copias, accesos y atributos innecesarios limita impacto potencial y simplifica gobernanza.
Qué puede aportar a una Administración española
Ministerios, comunidades y entidades locales pueden estudiar el patrón de API gateway para reducir integraciones punto a punto, especialmente cuando muchas aplicaciones consumen servicios comunes.
La adopción no tiene por qué consistir en copiar una solución completa. Puede reutilizarse un patrón de arquitectura, un protocolo, una metodología, un conjunto de pruebas o una forma de gobernanza. Este enfoque suele ser más realista que intentar sustituir de una vez todos los sistemas existentes.
Antes de adoptar, conviene comparar el caso propio con el contexto original: volumen, usuarios, legislación, identidad, infraestructura y capacidad operativa. La misma tecnología puede necesitar configuraciones diferentes según el servicio.
Contratación pública y dependencia tecnológica
Los pliegos pueden exigir compatibilidad con estándares y capacidad de desplegar políticas sin atar todos los sistemas a una marca concreta.
Los pliegos deberían expresar capacidades, niveles de servicio, documentación y condiciones de salida. Es preferible exigir una interfaz o estándar verificable que una integración descrita únicamente con el nombre de un producto.
La reversibilidad debe probarse y no limitarse a una cláusula. Exportar datos, reconstruir configuraciones o conectar un proveedor alternativo en un entorno controlado permite saber si la independencia es real.
Operación, soporte y continuidad
Una solución digital necesita un modelo de operación después del despliegue. Debe existir un responsable de servicio, un canal de incidencias y una clasificación que diferencie problemas funcionales, integraciones, datos y seguridad. Esta estructura evita que cualquier fallo termine escalado al mismo equipo.
Los niveles de servicio deberían adaptarse a criticidad. Un intercambio utilizado en un trámite en tiempo real puede requerir más disponibilidad que una herramienta de análisis ocasional. Definir estas prioridades ayuda a utilizar mejor los recursos.
Las copias, redundancia y procedimientos de recuperación necesitan pruebas periódicas. Un plan que nunca se ha ensayado puede fallar por credenciales caducadas, documentación obsoleta o dependencias no identificadas.
Capacitación y transferencia de conocimiento
Los equipos necesitan conocer diseño de APIs, seguridad, observabilidad y gestión de versiones para que la pasarela no se convierta en un cuello de botella.
Los usuarios funcionales necesitan comprender qué puede hacer la solución y qué excepciones existen. Los equipos técnicos deben conocer arquitectura, seguridad y versionado. Los responsables de contratación necesitan entender portabilidad, licencias y costes de mantenimiento.
La formación debería actualizarse cuando cambien versiones o procesos. Guías breves, ejemplos y procedimientos de escalado suelen integrarse mejor en el trabajo diario que documentos extensos que quedan obsoletos.
Cómo medir el valor real
Además del número de transacciones, son relevantes disponibilidad, latencia, errores, tiempo de incorporación de nuevas APIs y reducción de integraciones duplicadas.
Las métricas de actividad —usuarios, transacciones o integraciones— son útiles para seguir adopción, pero no demuestran por sí solas valor. Conviene relacionarlas con tiempo ahorrado, errores evitados, fraude reducido, disponibilidad, coste o satisfacción.
También es recomendable medir el tiempo necesario para incorporar un nuevo participante o caso de uso. Si cada integración requiere meses de trabajo específico, la supuesta reutilización puede ser limitada.
Riesgos y límites
Centralizar demasiado tráfico puede aumentar impacto de un fallo. La arquitectura debe contemplar redundancia y evitar reglas excesivamente complejas difíciles de mantener.
Otro riesgo es convertir una solución común en un nuevo punto central de dependencia. La arquitectura debe disponer de redundancia, documentación y mecanismos de salida para evitar que la simplificación de integraciones cree un cuello de botella.
La estandarización tampoco debe bloquear necesidades legítimas. Los perfiles comunes pueden admitir extensiones documentadas cuando un servicio tenga requisitos específicos, manteniendo compatibilidad en el núcleo.
Hoja de ruta para una implantación
Una entidad interesada puede comenzar con un único caso de uso bien delimitado. Debe describir el proceso actual, datos implicados, usuarios, sistemas y métricas. Después puede diseñar la integración y probarla en un entorno separado antes de afectar a producción.
La segunda fase debería documentar resultados y problemas. Si el piloto reduce carga y mantiene seguridad, puede ampliarse a otros departamentos o entidades. Esta evolución incremental permite construir experiencia interna y ajustar arquitectura con menos riesgo.
En una tercera fase conviene formalizar operación, soporte y financiación recurrente. La capacidad deja entonces de ser un proyecto puntual y pasa a integrarse en el catálogo de servicios de la organización.
Qué debería revisar una entidad antes de adoptarlo
- Problema concreto y línea base de costes, tiempos y errores.
- Responsables funcionales, técnicos y de datos.
- Interfaces, estándares y versiones.
- Autenticación, autorización y trazabilidad.
- Portabilidad de información y configuraciones.
- Modelo de soporte y continuidad.
- Documentación y transferencia de conocimiento.
- Pruebas de interoperabilidad y escenarios de fallo.
- Coste total de operación.
- Indicadores de valor después de la implantación.
Qué habrá que observar
Será útil observar su reutilización en nuevos proyectos europeos, su relación con OOTS y el papel de pasarelas abiertas en arquitecturas con IA externa.
La utilidad se comprobará con adopción real y evolución. Será importante observar si nuevas organizaciones reutilizan el enfoque, cuánto tarda una integración, qué problemas aparecen y cómo se resuelven los cambios de versión.
También conviene seguir la relación con otras iniciativas europeas de identidad, datos, interoperabilidad y soberanía digital, porque muchos componentes están convergiendo hacia servicios públicos transfronterizos.
Preguntas frecuentes
¿Quién impulsa esta novedad?
GovWay es una solución abierta desarrollada en Italia y presentada en Interoperable Europe.
¿Cuál es su principal utilidad?
Gobernar intercambios de datos mediante APIs con políticas, observabilidad y estándares comunes.
¿Puede reutilizarse por otras Administraciones?
Sí. Precisamente se presenta como una solución de interoperabilidad reutilizable y abierta.
¿Qué debería comprobarse antes de una adopción?
Compatibilidad con sistemas existentes, seguridad, licencias, documentación, costes de mantenimiento y capacidad de salida.
Fuentes
La información principal procede de Interoperable Europe. Las cifras y características concretas se presentan conforme a esa fuente institucional o al recurso oficial publicado en Interoperable Europe.
Lecturas relacionadas
Puede ampliarse contexto con nuestros análisis sobre gobierno del dato en la AGE, código abierto en la Administración, interoperabilidad semántica y principio once-only europeo.
Cómo llevar GovWay interoperabilidad API a una implantación real
La primera decisión debería ser definir un caso de uso concreto y una línea base. Antes de adoptar una nueva solución conviene describir el proceso actual, quién interviene, qué sistemas utiliza, cuánto tiempo consume y qué errores aparecen. Esta información permite comparar resultados después del cambio y evita medir el éxito solo por número de usuarios o componentes instalados.
La implantación también debería identificar dependencias técnicas y organizativas. Directorios de identidad, redes, APIs, sistemas de expedientes, proveedores y responsables de datos pueden condicionar el proyecto. Un inventario temprano reduce sorpresas durante la integración.
Diseñar contratos de datos y servicio
Cuando varias aplicaciones u organizaciones colaboran, resulta útil documentar qué información se intercambia, qué campos son obligatorios, qué errores pueden producirse y quién responde por cada fuente. Este contrato reduce interpretaciones diferentes y facilita pruebas automatizadas.
El mismo principio se aplica al servicio: disponibilidad, soporte, tiempos de respuesta y escalado de incidencias deberían estar definidos antes de producción. Si cada participante asume expectativas distintas, los problemas operativos aparecen cuando el sistema ya es crítico.
Versionar los contratos permite evolucionar sin romper consumidores. Las aplicaciones necesitan saber qué cambios son compatibles y cuánto tiempo permanecerá disponible una versión anterior.
Pruebas de interoperabilidad y escenarios adversos
Las pruebas no deberían limitarse al caso correcto. Datos incompletos, credenciales caducadas, respuestas lentas, servicios caídos o cambios de versión deben formar parte de la batería. Estos escenarios muestran cómo se comportará el sistema cuando la realidad no coincida con el diseño ideal.
Automatizar pruebas reduce el coste de incorporar nuevos participantes y permite detectar regresiones antes de desplegar una actualización. La evidencia generada puede utilizarse también para aceptar entregas de proveedores.
En proyectos transfronterizos o con muchas entidades, conviene disponer de entornos de pruebas comunes para que cada organización valide su integración antes de conectarse a producción.
Observabilidad y capacidad para explicar fallos
Los servicios interoperables necesitan 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 registrar más datos personales de los necesarios.
La observabilidad también permite medir tendencias. Un aumento gradual de latencia o errores puede detectarse antes de convertirse en una caída. Los cuadros de mando operativos deberían centrarse en señales que ayuden a actuar y no solo en acumular métricas.
Cuando varios organismos participan, las reglas sobre acceso a registros y conservación deben quedar claras para facilitar investigación sin crear una nueva concentración de información sensible.
Seguridad de la cadena tecnológica
Las soluciones públicas dependen de librerías, certificados, servicios y proveedores externos. Mantener un inventario de componentes y versiones ayuda a reaccionar ante vulnerabilidades y cambios de soporte. Esta visibilidad es especialmente importante en plataformas compartidas que pueden afectar a muchos servicios a la vez.
La gestión de identidades técnicas merece la misma atención que las cuentas de usuario. Certificados, secretos de API y cuentas de servicio deben tener propietarios, fechas de renovación y mecanismos de revocación.
También conviene revisar periódicamente permisos. Una integración creada para un proyecto piloto no debería conservar indefinidamente accesos amplios cuando el alcance cambia.
Capacitación y documentación operativa
La documentación debe permitir que un equipo distinto pueda comprender y operar la solución. Diagramas, procedimientos de despliegue, configuración, políticas de seguridad y ejemplos de integración son activos fundamentales para reducir dependencia.
La formación puede organizarse por roles. Los usuarios funcionales necesitan conocer límites y excepciones; los técnicos, arquitectura y troubleshooting; y los responsables, métricas, riesgos y costes.
Los materiales deberían actualizarse junto con las versiones. Una guía obsoleta puede generar más errores que no tener documentación.
Coste total y sostenibilidad
El coste de una solución no termina con su implantación. Infraestructura, soporte, monitorización, actualizaciones, certificados, personal y futuras migraciones forman parte del ciclo de vida. La comparación entre alternativas debería incluir estos elementos.
También conviene medir el coste de incorporación de nuevos participantes. Una plataforma que parece económica puede resultar difícil de escalar si cada integración requiere mucho trabajo especializado.
La sostenibilidad incluye capacidad para retirar componentes. Mantener funciones con poco uso aumenta complejidad y superficie de riesgo.
Gobernanza del cambio
Las decisiones de evolución deberían seguir un proceso claro. Cambios de versión, nuevas APIs, modificación de políticas o sustitución de componentes necesitan responsables y criterios de aceptación.
Una hoja de ruta compartida ayuda a que proveedores y organismos sepan qué cambios vienen y puedan prepararse. En comunidades abiertas, la gobernanza también debe definir cómo se proponen y aprueban contribuciones.
La transparencia sobre decisiones técnicas reduce dependencia de personas concretas y facilita auditorías posteriores.
Cómo medir si la reutilización funciona
Además de contar descargas o implementaciones, conviene medir tiempo de adopción, número de componentes reutilizados, integraciones creadas, incidencias y ahorro frente a desarrollar desde cero. Estas métricas muestran si la solución realmente reduce duplicidades.
También es útil observar diversidad de usuarios. Una herramienta reutilizada solo por organizaciones con gran capacidad técnica puede necesitar simplificación o mejores guías para extenderse a entidades pequeñas.
Los casos de uso que no funcionaron deben documentarse. Compartir limitaciones aporta tanto valor como difundir éxitos.
Conclusión
GovWay gestiona unos 50.000 millones de intercambios al año: qué enseña a las Administraciones ofrece una referencia útil porque combina tecnología con interoperabilidad, gobernanza y reutilización. El valor para una Administración dependerá de adaptar estos principios a su contexto, no de copiar una arquitectura sin evaluar necesidades.
Una implantación sostenible deja documentación, métricas, capacidades internas y opciones de salida. Ese conjunto de activos es lo que permite que el servicio siga siendo gobernable cuando cambien proveedores, usuarios o tecnología.
Fotografía: panumas nikhomkhai / Pexels.