La Piattaforma Digitale Nazionale Dati de Italia se ha consolidado como infraestructura nacional para intercambio seguro y estandarizado de datos entre Administraciones y operadores de servicios públicos.
La ficha actualizada por Interoperable Europe el 14 de septiembre de 2026 destaca un catálogo público de e-services, autenticación y autorización estandarizadas y trazabilidad completa de los intercambios. Desde enero de 2026 también pueden participar empresas privadas en determinadas condiciones.
Qué es y qué problema intenta resolver
PDND funciona como un punto común donde proveedores de datos publican servicios y consumidores autorizados se suscriben y acceden mediante APIs.
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
El modelo reduce integraciones específicas entre pares y facilita aplicar el principio once-only a escala nacional.
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
Un catálogo unificado permite descubrir APIs y documentar qué información ofrece cada organismo. La trazabilidad ayuda a saber quién accedió y con qué autorización.
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
La plataforma incorpora autenticación mutua, autorización y auditoría. Estos controles son esenciales cuando múltiples entidades acceden a información pública no abierta.
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
El catálogo necesita reglas comunes de publicación, versiones y responsabilidades para evitar APIs incompatibles o desactualizadas.
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
Las nuevas aplicaciones públicas pueden diseñarse para consumir y exponer servicios a través de la plataforma, reduciendo conectores propietarios.
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
Centralizar descubrimiento e intercambio aumenta la importancia de continuidad y de una gobernanza robusta. La plataforma no corrige por sí sola problemas de calidad del dato.
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
PDND es un caso útil para estudiar cómo organizar un catálogo nacional de APIs públicas y separar proveedor de dato, consumidor y capa de confianza.
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
Será relevante observar el crecimiento tras la incorporación de actores privados y cómo se gestionan nuevos casos de uso.
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?
El Departamento para la Transformación Digital de la Presidencia del Consejo de Ministros de Italia.
¿Cuál es su finalidad?
Facilitar intercambio seguro mediante APIs y aplicar el principio once-only en el sector público italiano.
¿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 Interoperable Europe.
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.
Un catálogo nacional cambia la forma de descubrir datos
En un modelo tradicional, un organismo que necesita información debe saber primero quién la tiene y negociar una integración específica. Un catálogo nacional de e-services permite buscar capacidades disponibles y conocer condiciones técnicas antes de iniciar el intercambio.
Esta visibilidad reduce una parte importante del coste de coordinación. También ayuda a evitar que distintas unidades construyan soluciones paralelas para acceder al mismo dato.
Autenticación y autorización separadas del dato
PDND establece mecanismos comunes para que proveedor y consumidor se identifiquen y autoricen el acceso. Separar esta capa de confianza de la lógica de cada API permite que los servicios se centren en los datos que ofrecen.
La trazabilidad de cada intercambio es fundamental. Una Administración necesita poder reconstruir quién solicitó información, con qué finalidad y bajo qué autorización, especialmente cuando se manejan datos no abiertos.
Aplicar el principio once-only a escala
El principio de una sola vez pretende evitar que ciudadanos y empresas aporten de nuevo información que ya posee otra autoridad. Para hacerlo realidad, los sistemas deben ser capaces de localizar y solicitar el dato correcto de forma automática.
PDND proporciona parte de esa infraestructura, pero el principio también depende de bases jurídicas, calidad de los registros y reglas claras sobre cuándo puede reutilizarse una información.
Qué cambia al incorporar actores privados
La apertura a determinadas empresas desde 2026 amplía los escenarios posibles, pero también exige diferenciar con precisión qué accesos están permitidos y qué obligaciones tiene cada participante.
La participación privada puede facilitar servicios donde empresas actúan como prestadores o consumidores autorizados, pero la gobernanza debe evitar que el catálogo se interprete como acceso general a datos públicos.
APIs como infraestructura administrativa
Cuando los intercambios se realizan mediante APIs estables, muchos trámites pueden reducir pasos manuales. Un sistema puede verificar información en origen en lugar de pedir certificados que después alguien debe revisar.
La calidad del servicio depende entonces de la disponibilidad de esas APIs. Las Administraciones deben tratar algunas interfaces como infraestructura crítica y definir niveles de servicio y continuidad.
Cómo evitar un catálogo lleno de servicios difíciles de usar
Publicar una API no garantiza que sea reutilizable. La documentación, ejemplos, entornos de prueba y consistencia entre servicios determinan el coste de adopción.
Un catálogo nacional necesita criterios de calidad y mecanismos para retirar versiones obsoletas. De lo contrario puede acumular interfaces duplicadas o poco mantenidas.
Lecciones para contratación
Las nuevas aplicaciones deberían diseñarse para consumir servicios existentes antes de replicar datos. Los pliegos pueden exigir que el proveedor compruebe el catálogo y justifique cualquier copia local necesaria.
También conviene pedir que las nuevas capacidades se publiquen de forma reutilizable cuando tengan valor para otros organismos.
De proyecto tecnológico a política de datos
La plataforma solo alcanza todo su potencial si la Administración la acompaña con gobierno del dato. Saber qué registro es fuente autoritativa y quién responde por su calidad es tan importante como exponer una API.
El caso italiano muestra cómo una infraestructura común puede conectar la estrategia de datos con servicios concretos y medibles.
Cómo llevar PDND interoperabilidad Italia 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. Italia consolida PDND como catálogo nacional de APIs para aplicar el principio once-only resulta relevante precisamente porque permite analizar la infraestructura junto con el servicio que la utiliza.
Fotografía: Brett Sayles / Pexels.