Los equipos nacionales del Once-Only Technical System se reunirán el 24 y 25 de septiembre de 2026 en Rotterdam para acelerar la incorporación de autoridades competentes al sistema europeo de intercambio transfronterizo de evidencias.
La agenda publicada por la Comisión incluye trabajo sobre incorporación inicial, identidad electrónica, matching de identidades, diálogos de datos y conexiones futuras con la cartera europea de identidad digital y la European Business Wallet.
Qué es y qué problema intenta resolver
OOTS busca aplicar el principio de que ciudadanos y empresas no tengan que aportar repetidamente datos que ya obran en poder de una autoridad pública cuando realizan determinados procedimientos transfronterizos.
En la Administración Pública, el valor de una solución digital depende de su capacidad para integrarse con procesos, datos y responsabilidades existentes. La tecnología aislada puede resolver una necesidad local, pero genera más valor cuando sus componentes pueden reutilizarse y evolucionar sin rehacer integraciones desde cero.
Por qué importa para los servicios públicos digitales
La reducción de cargas depende de que las Administraciones puedan descubrir, solicitar y transferir evidencias de forma segura entre países.
Los servicios públicos modernos se apoyan en múltiples organismos y sistemas. Ciudadanía y empresas esperan experiencias continuas aunque detrás exista una arquitectura distribuida. La interoperabilidad permite que esa complejidad técnica no se traslade directamente al usuario.
También reduce tareas manuales y duplicidades. Cuando los intercambios se estandarizan, las organizaciones pueden concentrarse en la lógica del servicio en lugar de diseñar un conector distinto para cada relación.
Datos, estándares e interoperabilidad
El sistema necesita modelos comunes para describir evidencias y mecanismos para relacionar identidades entre registros de distintos Estados.
Los estándares son especialmente útiles cuando existe un ecosistema con múltiples proveedores. Permiten acordar interfaces y significados sin obligar a utilizar el mismo producto. Esto favorece competencia y facilita incorporar nuevas soluciones.
La interoperabilidad semántica debe acompañar a la técnica. Compartir un dato solo es útil si ambas partes entienden qué representa, qué versión está vigente y qué reglas se aplican.
Seguridad y confianza
El intercambio transfronterizo requiere autenticación fuerte, trazabilidad y respeto a protección de datos. No implica acceso indiscriminado a registros.
Los intercambios entre Administraciones requieren autenticación, autorización y trazabilidad. Una integración sencilla de utilizar puede ocultar una cadena compleja de permisos, por lo que cada acceso debe poder auditarse y revocarse.
En infraestructuras compartidas, la continuidad también es crítica. Un fallo puede afectar a múltiples servicios al mismo tiempo, lo que obliga a diseñar redundancia, monitorización y procedimientos de recuperación.
Gobernanza y operación
Coordinadores nacionales y autoridades competentes deben acordar procedimientos de incorporación y resolución de incidencias.
Un componente reutilizable necesita propietario, hoja de ruta, documentación y un procedimiento para gestionar cambios. La gobernanza determina si una solución continúa siendo útil después de su primera implantación.
La Administración usuaria también debe saber qué parte del servicio gestiona ella y qué parte depende de una plataforma común. Esta separación de responsabilidades evita vacíos durante incidencias o auditorías.
Contratación y reutilización
Los sistemas nacionales que se conectan deben cumplir especificaciones europeas y conservar capacidad de actualización conforme evolucione el marco.
Los pliegos deberían favorecer estándares, APIs y documentación. También conviene exigir pruebas de conformidad cuando exista una especificación común, porque declarar compatibilidad no siempre garantiza que dos implementaciones funcionen juntas.
La reutilización reduce coste solo si adaptar y mantener la solución resulta razonable. Antes de adoptarla, cada entidad debe revisar arquitectura, licencias, comunidad y compatibilidad con su entorno.
Riesgos que conviene evitar
El matching incorrecto de identidad o datos desactualizados pueden generar errores. Los mecanismos de verificación y recurso son esenciales.
Otro riesgo es crear una nueva capa central sin una estrategia de salida. Las plataformas comunes deben facilitar exportación y sustitución de componentes para evitar que la interoperabilidad se convierta paradójicamente en otra dependencia.
Qué debería revisar una Administración
- Casos de uso concretos y volumen esperado.
- Estándares y modelos de datos utilizados.
- Autenticación, autorización y registros.
- APIs y documentación técnica.
- Portabilidad y condiciones de salida.
- Rendimiento y escalabilidad.
- Gobernanza del servicio compartido.
- Pruebas de conformidad e interoperabilidad.
- Coste de operación y mantenimiento.
- Capacidad de reutilización en otros servicios.
Qué pueden aprender otras Administraciones
El principio once-only también ofrece aprendizajes para intercambios internos entre Administraciones españolas, aunque los marcos técnicos puedan ser diferentes.
Los mejores aprendizajes suelen estar en los patrones: catálogos, identificadores, contratos, perfiles de acceso o procedimientos de incorporación. Una entidad puede aprovecharlos incluso si desarrolla su propia solución.
Qué habrá que observar
Habrá que seguir el ritmo de incorporación de autoridades y la integración futura con wallets europeas.
La madurez se comprueba con uso real. Será importante observar adopción, volumen, incidencias, tiempos de integración y capacidad de incorporar nuevos participantes sin incrementar de forma desproporcionada la complejidad.
Preguntas frecuentes
¿Quién mantiene o impulsa esta solución?
La Comisión Europea junto con coordinadores y autoridades de los Estados miembros.
¿Cuál es su finalidad?
Permitir intercambio seguro de evidencias para reducir la necesidad de que ciudadanos y empresas aporten varias veces la misma información.
¿Por qué es relevante la interoperabilidad?
Porque permite que organismos y aplicaciones distintas colaboren mediante reglas comunes sin exigir un único proveedor o sistema.
¿Puede reutilizarse?
Depende de la solución y de su licencia, pero los casos analizados se presentan precisamente como referencias o componentes para facilitar reutilización y aprendizaje entre Administraciones.
Fuente oficial
La información principal procede de Comisión Europea – Once-Only Technical System.
Lecturas relacionadas
Más contexto en nuestros análisis sobre gobierno del dato, código abierto, ENS legible por máquina y pilotos europeos de IA generativa.
El problema práctico de pedir el mismo documento varias veces
Muchos procedimientos administrativos solicitan certificados o datos que ya existen en otro organismo. Para el ciudadano esto supone tiempo y para la Administración genera documentos, validaciones y almacenamiento que podrían evitarse.
El principio once-only pretende que la autoridad competente obtenga la evidencia directamente cuando existe base legal y consentimiento o mecanismo habilitante, reduciendo carga sin eliminar garantías.
Por qué el intercambio transfronterizo es más difícil
Entre países cambian identificadores, idiomas, registros y autoridades. Un sistema europeo necesita resolver no solo transporte de datos, sino descubrimiento de la fuente y correspondencia de identidad.
Los talleres del OOTS trabajan precisamente estas capas porque un intercambio técnicamente correcto puede fallar si no se sabe con certeza que dos registros se refieren a la misma persona o empresa.
El papel de la identidad electrónica
La identificación proporciona un punto de partida para relacionar al usuario con evidencias existentes. La evolución hacia la EUDI Wallet abre nuevas posibilidades para presentar atributos y credenciales de forma controlada.
La arquitectura futura deberá decidir cuándo una evidencia viaja directamente entre Administraciones y cuándo puede presentarse mediante una wallet, manteniendo coherencia entre ambos mecanismos.
Data dialogues y experiencia de usuario
El usuario debe entender qué información se solicita y de dónde procede. Los diálogos de datos permiten aportar transparencia y, cuando corresponda, consentimiento o revisión antes del intercambio.
Una experiencia mal diseñada puede convertir la reducción de carga en un proceso confuso. La simplicidad visible requiere mucha coordinación detrás.
Errores de matching y mecanismos de recurso
Relacionar identidades es una de las áreas más sensibles. Un falso positivo puede asociar información de otra persona, mientras un falso negativo obliga a volver al procedimiento manual.
Por eso deben existir controles, señales de confianza y vías para corregir discrepancias sin bloquear todo el trámite.
Onboarding de autoridades competentes
El sistema solo genera valor cuando muchas autoridades se conectan. Incorporar organismos implica adaptar sistemas, realizar pruebas, configurar identidades y formar equipos.
Automatizar parte de este onboarding y ofrecer perfiles comunes puede acelerar adopción sin sacrificar controles.
Aplicación del principio dentro de un mismo país
Aunque OOTS sea transfronterizo, el principio puede inspirar mejoras internas. Una Administración puede revisar cuántos documentos solicita al ciudadano pese a tenerlos disponibles en otro registro nacional.
Eliminar estas solicitudes requiere acuerdos jurídicos y técnicos, pero reduce fricción y puede mejorar calidad al consultar la fuente original.
Qué medirá el éxito
Más que contar conexiones, será importante medir procedimientos donde realmente se evita aportar documentación, tiempo ahorrado y tasa de intercambios completados sin incidencias.
La interoperabilidad europea tendrá éxito si se vuelve invisible para el usuario: el trámite funciona y los datos necesarios llegan con garantías.
Cómo llevar Once-Only Technical System de referencia a operación
El primer paso para una Administración interesada en este enfoque es delimitar un caso de uso concreto. Antes de elegir herramientas conviene describir qué organismo produce la información, quién la consume, con qué frecuencia y qué problema provoca hoy el intercambio manual. Esta fotografía inicial permite comparar la situación actual con el resultado después de la implantación.
También es útil identificar dependencias existentes: registros maestros, directorios de identidad, catálogos, gestores de expedientes y proveedores. La interoperabilidad rara vez empieza desde cero; suele construirse sobre sistemas que ya funcionan y que no pueden sustituirse todos al mismo tiempo.
Diseñar un contrato de datos antes que un conector
Una integración robusta necesita acordar significado, estructura y reglas de los datos. Qué campos son obligatorios, qué identificador se utiliza, cómo se expresa una ausencia de información o qué códigos se consideran válidos son decisiones que deberían quedar documentadas antes de programar el intercambio.
Este contrato debe versionarse. Si una autoridad añade un campo o cambia una clasificación, las aplicaciones consumidoras necesitan saber si el cambio es compatible y cuánto tiempo se mantendrá la versión anterior. Un buen gobierno de versiones evita interrupciones y facilita evolución gradual.
Pruebas y entornos de preproducción
Antes de conectar sistemas reales conviene disponer de datos de prueba y un entorno donde validar autenticación, formatos, errores y rendimiento. Las pruebas deben incluir escenarios correctos y también situaciones anómalas: datos incompletos, identidades no encontradas, servicios temporalmente indisponibles o respuestas fuera de tiempo.
Automatizar estas pruebas ayuda a detectar regresiones cuando cambia una API o un componente. En ecosistemas con muchos participantes, la conformidad repetible reduce el coste de incorporar nuevos organismos y evita que cada alta requiera una revisión completamente manual.
Observabilidad y trazabilidad
Cuando un intercambio falla, los equipos necesitan localizar rápidamente dónde ocurrió. Es importante registrar identificadores de transacción, tiempos, sistemas implicados y resultado sin almacenar más información personal de la necesaria. Los registros deben permitir seguir una operación de extremo a extremo.
La observabilidad también permite medir disponibilidad, latencia y volumen. Estos indicadores ayudan a anticipar saturación y a distinguir un problema del sistema central de un fallo en una aplicación concreta.
Modelo de soporte para múltiples organismos
Una solución compartida necesita un servicio de soporte capaz de clasificar incidencias y determinar qué equipo debe resolverlas. La documentación de primer nivel debe permitir a las entidades solucionar configuraciones habituales sin depender siempre del equipo central.
Los acuerdos de servicio deberían diferenciar criticidades y tiempos. No todas las integraciones tienen el mismo impacto: una consulta estadística puede tolerar retrasos que serían inaceptables en un trámite ciudadano en tiempo real.
Financiación y sostenibilidad
El coste inicial suele ser solo una parte. Hay que presupuestar operación, monitorización, actualizaciones, certificados, soporte y evolución de estándares. Los modelos compartidos funcionan mejor cuando existe una financiación estable y una regla clara para distribuir costes entre participantes.
Las métricas económicas deberían comparar el modelo común con la alternativa de mantener integraciones individuales. El ahorro puede aparecer en menos desarrollo duplicado, onboarding más rápido y menor esfuerzo de mantenimiento, aunque la plataforma central tenga un coste visible.
Evitar una nueva dependencia central
Una infraestructura de interoperabilidad puede simplificar el ecosistema y al mismo tiempo convertirse en un componente crítico. Para reducir riesgo necesita redundancia, documentación y capacidad para migrar componentes. Los datos y contratos de servicio no deberían depender de formatos internos imposibles de reproducir fuera de la plataforma.
También conviene mantener estándares abiertos en los puntos de conexión. Así, aunque cambie la implementación central, los sistemas participantes pueden conservar interfaces estables y reducir el impacto de la migración.
Indicadores para saber si el modelo funciona
Entre los indicadores útiles están el tiempo medio de incorporación de un nuevo participante, porcentaje de intercambios completados correctamente, número de integraciones reutilizadas, incidencias por versión, coste por transacción y reducción de documentos solicitados manualmente.
La evaluación debe combinar datos técnicos y experiencia de usuarios. Un sistema puede tener disponibilidad excelente y seguir generando carga administrativa si los procedimientos no aprovechan realmente la información intercambiada. Europa acelera el principio de una sola vez para que ciudadanos no repitan datos entre Administraciones resulta relevante precisamente porque permite analizar la infraestructura junto con el servicio que la utiliza.
Fotografía: Miguel Á. Padriñán / Pexels.