Interoperable Europe actualizó el 14 de septiembre de 2026 la ficha de PDND Interoperabilità, la plataforma nacional italiana para intercambio seguro y estandarizado de datos.
PDND funciona como catálogo común de e-services y APIs para Administraciones y operadores de servicios públicos y, desde enero de 2026, también permite el acceso de determinadas empresas privadas bajo las reglas previstas.
Qué se ha publicado
La plataforma busca aplicar el principio once-only: que una Administración no vuelva a pedir información que ya posee otra entidad autorizada.
La novedad tiene interés para las Administraciones porque afecta a interoperabilidad entre registros, APIs públicas y reutilización segura de datos. Su valor dependerá de cómo se traduzca en arquitectura, procedimientos, contratos y capacidades internas.
Qué significa para el sector público
PDND ofrece un punto común donde proveedores publican servicios de datos y consumidores se suscriben mediante procesos estandarizados de autenticación, autorización y auditoría.
La transformación digital pública requiere combinar eficiencia con control, interoperabilidad, seguridad y capacidad de revisión.
Datos e interoperabilidad
El catálogo público, la documentación técnica y el National Data Catalogue para interoperabilidad semántica ayudan a que las APIs sean comprensibles y reutilizables.
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
La plataforma incorpora autenticación mutua, autorización y trazabilidad de los intercambios, elementos clave cuando varias entidades consultan registros de terceros.
La autonomía tecnológica implica conservar capacidad de entender, supervisar, operar o sustituir componentes críticos.
Contratación pública
Un catálogo nacional de APIs puede reducir integraciones a medida y permitir que proveedores implementen conectores contra interfaces comunes.
Los pliegos pueden exigir portabilidad, documentación, interfaces, niveles de servicio y reversibilidad.
Capacitación
Los organismos necesitan perfiles capaces de publicar e-services, gestionar permisos, interpretar contratos de API y resolver errores.
La disponibilidad de tecnología no sustituye conocimiento interno. Los equipos necesitan saber evaluar resultados, riesgos, costes y dependencia.
Cómo medir resultados
Número de organismos, e-services, consumidores, transacciones, tiempos de alta y errores pueden medir madurez.
Las métricas de adopción deben complementarse con impacto: tiempo ahorrado, calidad, coste, incidencias, disponibilidad o reutilización.
Riesgos y límites
Una plataforma central de interoperabilidad necesita alta disponibilidad y gobernanza estricta para no convertirse en punto de fallo o cuello de botella.
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
Será importante seguir la expansión a actores privados, la evolución del catálogo y su relación con infraestructuras europeas once-only.
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 Departamento para la Transformación Digital de la Presidencia del Consejo de Ministros de Italia.
¿Es obligatoria para todas las Administraciones?
La plataforma forma parte del marco italiano de interoperabilidad; su aplicación concreta depende del servicio y de los sujetos incluidos.
¿Qué aporta principalmente?
Permitir intercambio autorizado y trazable de datos mediante APIs comunes y reducir solicitudes repetidas a ciudadanos y empresas.
Fuentes
La información principal procede de Interoperable Europe.
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 PDND Italia once-only 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
Italia actualiza PDND, su plataforma nacional para aplicar el principio once-only mediante APIs 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.
PDND como infraestructura del principio once-only
La Plataforma Digitale Nazionale Dati italiana busca que los organismos compartan información mediante APIs en lugar de pedir repetidamente documentos a ciudadanos y empresas. La actualización reciente refuerza ese enfoque de plataforma común.
El principio once-only requiere algo más que una API: base jurídica, identidad, autorización, catálogo, modelos de datos y trazabilidad de cada consulta.
Catálogo y descubrimiento de servicios
Una plataforma nacional debe permitir saber qué datos existen, quién los mantiene y bajo qué condiciones pueden consultarse. Un catálogo bien gestionado evita integraciones informales y ayuda a reutilizar servicios ya disponibles.
Los metadatos deberían incluir versión, responsable, SLA, documentación y requisitos de acceso.
Gobierno de APIs a escala nacional
Cuando cientos de organismos dependen de interfaces comunes, el versionado y la retirada de servicios deben planificarse. Cambiar una API sin periodo de transición puede afectar a numerosos procedimientos.
También conviene registrar consumidores para saber quién utiliza cada versión y coordinar migraciones.
Qué puede aprender España
La experiencia italiana resulta comparable con la Plataforma de Intermediación española y con iniciativas de gobierno del dato. El aprendizaje útil está en cómo combinar catálogo, APIs y gobernanza para reducir solicitudes repetidas.
España puede observar métricas de incorporación de organismos, reutilización, latencia y reducción de documentación manual.
Cómo medir el once-only
No basta con contar APIs. El impacto debería reflejar cuántos documentos dejan de pedirse, cuánto tiempo se ahorra y cuántos procedimientos reutilizan datos ya disponibles.
Una plataforma madura será aquella en la que añadir un nuevo servicio o consumidor resulte progresivamente más sencillo.
La gobernanza del catálogo deberá garantizar además que los servicios obsoletos se retiren de forma ordenada y que los consumidores dispongan de una alternativa antes del cierre.
El valor del modelo italiano dependerá también de la facilidad de alta para organismos pequeños. Una plataforma nacional verdaderamente reutilizable debe ofrecer documentación, soporte y entornos de prueba suficientes para que la integración no quede limitada a entidades con grandes equipos técnicos.
Fotografía: Alesia Kozik / Pexels.