Interoperabilidad: el arte invisible de conectar datos, sistemas y personas

Hay una idea que se repite en casi cualquier iniciativa de datos: “si conectamos fuentes distintas, sacaremos más valor”. Y suele ser verdad. El matiz es que el valor aparece cuando podemos combinar datos sin fricción, sin malentendidos y sin sorpresas. El Decálogo del reutilizador de datos del sector público lo resume muy bien: la interoperabilidad es especialmente crítica justo cuando intentamos mezclar datos de diversas fuentes, que es donde los datos abiertos suelen aportar más.

En la práctica, la interoperabilidad no es solo “que haya una API” o “que el fichero sea descargable”. Es un concepto más amplio, con varias capas: si solo cuidamos una, las demás acaban rompiendo la reutilización. Conectamos… pero no entendemos qué significa cada campo. Entendemos… pero no hay estabilidad ni versionado. Hay estabilidad… pero no existe un proceso común para resolver incidencias. Y, aun teniendo todo lo anterior, pueden faltar reglas claras de uso. Por eso, también es un error pensar que la interoperabilidad es un problema puramente informático que se arregla “comprando el software adecuado”: la tecnología es solo la punta del iceberg. Si queremos que los datos fluyan de verdad entre administración pública, empresa y centros de investigación, necesitamos una visión holística.

Y aquí viene la buena noticia: se puede abordar de forma incremental, paso a paso. Para hacerlo bien, lo primero es aclarar qué tipo de interoperabilidad estamos buscando en cada caso, porque no todas las barreras son técnicas ni se resuelven del mismo modo.

En este post vamos a desglosar los distintos tipos de interoperabilidad que existen, para identificar qué aporta cada uno y qué falla cuando lo dejamos fuera.

Los distintos tipos de interoperabilidad

Siguiendo el Marco Europeo de Interoperabilidad (EIF), conviene pensar la interoperabilidad como un edificio con cuatro principales capas: técnica, semántica, organizativa y jurídica. Si una falla, el conjunto se resiente.

A continuación, unificamos las cuatro capas con un enfoque centrado en datos, incluyendo ejemplos aplicados a distintos sectores.

1. Interoperabilidad técnica: que los sistemas puedan intercambiar datos

Es la capa “visible”: infraestructuras, protocolos y mecanismos para enviar/recibir datos de forma fiable.

Pero, ¿qué implica en la práctica?

• Formatos legibles por máquina: como CSV, JSON, XML, RDF, evitando los documentos solo para lectura humana (como PDF).

• API y endpoints estables: con documentación, autenticación cuando aplique y versionado.

• Requisitos no funcionales: disponibilidad, rendimiento, seguridad y trazabilidad técnica.

¿Cuáles son los errores o fallos típicos que generan problemas?

En el caso específico de la interoperabilidad técnica, estos vienen principalmente originados por cambios “silenciosos”, como, por ejemplo, que se alteren columnas y/o estructura y se rompan integraciones, o que haya URL no persistentes, API sin versionado o sin documentación.

Ejemplo: vamos a aterrizarlo a un caso concreto para el dominio de la movilidad

Imaginemos que un ayuntamiento publica en tiempo real la ocupación de aparcamientos. Si la API cambia el nombre de un campo o el endpoint sin avisar, las apps de navegación dejan de mostrar plazas disponibles, aunque “el dato exista”. El problema es técnico: falta estabilidad, versionado y contrato de interfaz.

2. Interoperabilidad semántica: que, además, se entiendan entre sí

Si la interoperabilidad técnica es “las tuberías”, la semántica es el idioma. Podemos tener sistemas perfectamente conectados y, aun así, obtener resultados desastrosos si cada parte interpreta los datos de forma distinta.

Pero, ¿qué implica en la práctica?

• Glosarios de términos claros: definición de cada campo, unidad, formato, rango, reglas de negocio, granularidad y ejemplos.

• Vocabularios controlados, taxonomías y ontologías para clasificar y codificar valores sin ambigüedad.

• Identificadores unívocos y referencias normalizadas a través de datos de referencia con códigos oficiales, catálogos comunes, etc.

¿Cuáles son los errores o fallos típicos que generan problemas?

Normalmente aparecen cuando hay ambigüedad (por ejemplo, si solo pone fecha, no sabemos si es la fecha de registro, publicación o efecto), unidades distintas (por ejemplo, no se conoce la unidad de medida del dato: kWh vs MWh, euros vs miles de euros), códigos incompatibles (H/M vs 1/2 vs masculino/femenino) o incluso cambios de significado en series históricas sin explicarlo.

Ejemplo: vamos a aterrizarlo a un caso concreto en el sector energía

Una administración publica datos de consumo eléctrico por edificios. Un reutilizador cruza esos datos con otro dataset regional, pero uno está en kWh y el otro en MWh, o uno mide consumo “final” y el otro “bruto”. El cruce “cuadra” técnicamente, pero las conclusiones salen mal porque falta semántica: definiciones y unidades compartidas.

3. Interoperabilidad organizativa: que los procesos sostengan la coherencia

Aquí hablamos menos de sistemas y más de personas, responsabilidades y procesos. Los datos no se mantienen solos: se publican, se actualizan, se corrigen y se explican porque hay una organización detrás que lo hace posible.

Pero, ¿qué implica en la práctica?

• Roles y responsabilidades claras: quién define, quién valida, quién publica, quién mantiene y quién responde ante incidencias.

• Gestión de cambios: qué es un cambio mayor/menor, cómo se versiona, cómo se comunica y si se conserva el histórico.

• Gestión de incidencias: canal único, tiempos de respuesta, priorización, trazabilidad y cierre.

• Compromisos operativos (tipo acuerdos de nivel de servicio o SLA en sus siglas en inglés): frecuencia de actualización, ventanas de mantenimiento, criterios de calidad y revisiones periódicas.

Aquí pueden ayudarnos, por ejemplo, las especificaciones UNE sobre gobierno y gestión del dato donde se dan las claves para establecer modelos organizativos, roles, procesos de gestión y mejora continua. Por lo tanto, encajan precisamente en esta capa: ayudan a que publicar y compartir datos no dependa del “esfuerzo heroico” de un equipo, sino de un modo de trabajo estable en el que el equipo vaya madurando.

¿Cuáles son los errores o fallos típicos que generan problemas?

Los clásicos: “cada unidad publica a su manera”, no hay responsable claro, no existe un circuito para corregir errores, se actualiza sin avisar, no se conserva histórico o el feedback del reutilizador se pierde en un buzón genérico sin seguimiento.

Ejemplo: vamos a aterrizarlo a un caso concreto en medio ambiente

Una confederación publica datos de calidad del agua y varias unidades aportan mediciones. Si no hay un proceso común de validación, un calendario coordinado y un canal de incidencias, el dataset empieza a tener valores inconsistentes, lagunas y correcciones tardías. El problema no es la API ni el formato: es organizativo, porque el mantenimiento no está gobernado.

4. Interoperabilidad jurídica: que el intercambio sea viable y conforme

Esta es la capa que convierte el intercambio en algo seguro y escalable. Puedes tener datos perfectos a nivel técnico, semántico y organizativo… y aun así, no poder reutilizarlos si no hay claridad jurídica.

Pero, ¿qué implica en la práctica?

• Licencia y condiciones de uso claras: atribución, redistribución, uso comercial, obligaciones, etc.

• Compatibilidad entre licencias cuando se mezclan fuentes: evitando combinaciones inviables.

• Cumplimiento de protección de datos: como el Reglamento General de Protección de Datos (RGPD), propiedad intelectual, secretos empresariales o límites sectoriales.

• Reglas explícitas sobre qué se puede hacer y qué no: indicando también con qué requisitos.

¿Cuáles son los errores o fallos típicos que generan problemas?

La “jungla” clásica: licencias ausentes o ambiguas, condiciones contradictorias entre datasets, dudas sobre si hay datos personales o riesgo de reidentificación, o restricciones que se descubren cuando el proyecto ya está avanzado.

Ejemplo: vamos a aterrizarlo a un caso concreto en cultura y patrimonio

Un archivo público publica imágenes y metadatos de una colección. Técnicamente todo está bien, y los metadatos son ricos, pero la licencia es confusa o incompatible con otros datos que se quieren cruzar (por ejemplo, un repositorio privado con restricciones). Resultado: una empresa o una universidad decide no reutilizar por inseguridad jurídica. El bloqueo no es técnico: es jurídico.

En resumen, la interoperabilidad funciona como un “pack” de cuatro capas: conectar (técnica), entender lo mismo (semántica), mantenerlo de forma sostenida (organizativa) y poder reutilizar sin riesgo (jurídica).

Para verlo de un vistazo y con ejemplos reales, la siguiente infografía resume cómo se materializa cada capa en distintos sectores (estándares, modelos, prácticas y marcos normativos) y qué piezas suelen usarse como referencia en cada caso.

Figura 1. Infografía: "Interoperabilidad: la clave para trabajar con datos de diversas fuentes". Versión accesible disponible aquí. Fuente: elaboración propia - datos.gob.es.

La infografía anterior deja una idea clara: la interoperabilidad no depende de una sola decisión, sino de combinar estándares, acuerdos y reglas que cambian según el sector. A partir de aquí, tiene sentido bajar un nivel y ver qué referencias y herramientas se usan en España y en Europa para que esas cuatro capas (técnica, semántica, organizativa y jurídica) no se queden en teoría.

Una referencia práctica en España: NTI-RISP (y por qué tiene sentido citarla)

En el contexto español, la NTI-RISP es una guía muy útil porque pone negro sobre blanco qué hay que cuidar cuando publicamos información para que otros la puedan reutilizar: identificación, descripción (metadatos), formatos y términos de uso, entre otros aspectos.

Metadatos como pegamento: DCAT-AP y DCAT-AP-ES

En datos abiertos, donde más se nota la interoperabilidad “en el día a día” es en los catálogos: si los conjuntos de datos no se describen de forma coherente, cuesta encontrarlos, entenderlos y federarlos.

• DCAT-AP aporta un modelo común de metadatos para catálogos de datos en Europa, apoyándose en vocabularios ampliamente reutilizados.

• En España, DCAT-AP-ES se impulsa precisamente para reforzar esa interoperabilidad de catálogos con un perfil común que facilite intercambio y federación entre portales.

Cómo abordar la interoperabilidad sin morir de ambición

En lugar de “arreglarla de golpe”, suele funcionar mejor tratar la interoperabilidad como mejora continua porque se rompe con cambios en tecnología, organización o normativa. Un enfoque sencillo y realista:

1. Empieza por el “para qué”: ¿Quieres integrar en un servicio, cruzar para análisis, construir indicadores comparables, enriquecer entidades…? El objetivo determina el nivel de rigor necesario.

2. Asegura el mínimo técnico estable: acceso y formatos legibles por máquina, identificadores persistentes, documentación mínima, y algún versionado (aunque sea básico). Esto evita datasets  “útiles hoy” que se rompen mañana.

3. Aplica semántica donde duele (principio de Pareto: 80/20 - establece que el 80% de los resultados provienen del 20% de las causas o acciones-): define muy bien los campos críticos (los que se cruzan/filtran), unidades, tablas de códigos y el significado exacto de fechas/estados. No hace falta “modelarlo todo” para reducir la mayoría de los errores.

4. Pon acuerdos operativos mínimos: quién mantiene, cuándo se actualiza, cómo se reportan incidencias, cómo se anuncian cambios y si se conserva el histórico. Aquí es donde un enfoque de gobierno del dato (y guías como NTI-RISP) marca la diferencia entre “dataset publicado” y “dataset sostenible”.

5. Pilota con un cruce real: un piloto pequeño detecta rápido si el problema era técnico, semántico, organizativo o jurídico, y te da una lista concreta de fricciones a eliminar.

Como conclusión, la interoperabilidad no es simplemente “tener una API”: es el resultado de alinear cuatro capas —técnica, semántica, organizativa y jurídica— para poder combinar datos sin fricción, sin malentendidos y con seguridad. Cada capa resuelve un problema distinto: la técnica evita roturas de integración, la semántica evita interpretaciones erróneas, la organizativa hace sostenible la publicación y el mantenimiento en el tiempo, y la jurídica elimina la inseguridad sobre qué se puede hacer con los datos.

En ese contexto, los marcos y estándares sectoriales actúan como atajos prácticos para acelerar acuerdos y reducir ambigüedad, y por eso es útil ver ejemplos por sectores. Además, los metadatos y los catálogos interoperables son un auténtico multiplicador: cuando un conjunto de datos está bien descrito, se encuentra antes, se entiende mejor y se puede federar con menos coste. Por último, lo más efectivo suele ser un enfoque incremental y medible: empezar por el “para qué”, asegurar estabilidad técnica, reforzar la semántica crítica (80/20), formalizar acuerdos operativos mínimos y validar con un cruce real, en lugar de intentar “solucionar la interoperabilidad” como un único proyecto cerrado.

Contenido elaborado por Dr. Fernando Gualo, Profesor en UCLM y Consultor de Gobierno y Calidad de datos El contenido y el punto de vista reflejado en esta publicación es responsabilidad exclusiva de su autor.