Dos organizaciones firman un acuerdo de intercambio de datos, configuran sus conectores, resuelven los certificados y consiguen que los ficheros lleguen de un sistema a otro sin errores. Técnicamente, todo funciona. Y sin embargo, cuando alguien analiza los datos recibidos descubre que el campo "fecha de entrega" de un proveedor no significa lo mismo que el campo "fecha de entrega" del cliente: uno registra cuándo sale el pedido del almacén y el otro cuándo llega a destino. La conexión existe, pero el significado se ha perdido por el camino.

Este problema tiene nombre propio: interoperabilidad semántica. Se refiere a la capacidad de dos sistemas para interpretar un dato exactamente de la misma manera, más allá de poder transmitirlo o leerlo. Es distinta de la interoperabilidad técnica, que resuelve cómo se transportan los datos, y de la interoperabilidad sintáctica, que resuelve en qué formato se estructuran. Cuando falta la capa semántica, cada equipo interpreta el mismo dato según sus propias convenciones internas, y las decisiones que se toman a partir de él arrastran ese error sin que nadie lo note hasta que ya es tarde.

Para arquitectos de datos, responsables de gobernanza y técnicos de integración que trabajan en proyectos de colaboración entre organizaciones, este no es un problema teórico. Es la causa más frecuente de que los cuadros de mando no cuadren, de que los informes agregados entre varias empresas contengan errores silenciosos y de que los proyectos de intercambio de datos pierdan la confianza de quienes deberían beneficiarse de ellos.

Qué es la interoperabilidad semántica y por qué no basta con conectar sistemas

La interoperabilidad semántica exige que exista un acuerdo previo sobre el significado de cada dato: qué mide, en qué unidad, con qué precisión, en qué momento del proceso y bajo qué condiciones. Ese acuerdo no surge de forma espontánea entre dos organizaciones que nunca se han puesto de acuerdo formalmente, porque cada una ha construido su modelo de datos de forma independiente, respondiendo a sus propias necesidades internas.

El resultado habitual es que dos campos con el mismo nombre significan cosas distintas, o que dos campos con nombres distintos significan lo mismo. Ambos casos son peligrosos, pero el primero es más traicionero porque nadie sospecha del error hasta que los números no cuadran.

Resolver esto requiere tres piezas que trabajan juntas:

• Vocabularios de datos compartidos, que fijan los términos y sus definiciones exactas.

• Ontologías, que describen las relaciones entre esos términos y el contexto en el que tienen sentido.

• Modelos de datos comunes, que traducen ese acuerdo conceptual en estructuras técnicas concretas (esquemas, campos, tipos).

Sin estas tres capas, cualquier intercambio de datos entre organizaciones distintas es, en el mejor de los casos, una traducción manual constante, y en el peor, una fuente de errores que nadie detecta a tiempo.

Ejemplos reales de malentendidos semánticos

Los malentendidos semánticos no suelen ser espectaculares. Son pequeños, silenciosos y acumulativos, lo que los hace más difíciles de detectar que un fallo técnico evidente.

Unidades de medida sin especificar

Una cooperativa agroalimentaria de Castilla y León recibe de un proveedor logístico un dato de "peso" en cada envío. El proveedor lo registra en kilogramos; la cooperativa, por convención interna, asumía que se trataba de toneladas al integrarlo en su sistema de planificación. La diferencia no se detecta hasta que los cálculos de capacidad de almacén empiezan a no cuadrar durante semanas, y para entonces ya se han tomado decisiones de compra basadas en cifras erróneas.

Formatos y significados de fecha

Una administración local y una empresa de servicios urbanos comparten datos de incidencias. Un sistema registra "fecha de resolución" como el momento en que se cierra el expediente administrativo; el otro, como el momento en que un técnico termina la intervención en campo. Ambos campos se llaman igual, ambos parecen fechas de cierre, pero miden hitos distintos del proceso. Los indicadores de tiempo de respuesta que se calculan cruzando ambas fuentes quedan distorsionados sin que el error sea visible en una simple inspección de los datos.

Categorías que no significan lo mismo

Una empresa de distribución que clasifica sus productos como "perecederos" y "no perecederos" comparte esta categorización con un socio comercial que, en su propio sistema, usa la misma etiqueta "perecedero" pero con un criterio de caducidad distinto (por ejemplo, incluye productos con vida útil de hasta seis meses, mientras que el primero solo incluye los de vida útil inferior a treinta días). El intercambio de datos parece correcto porque los valores coinciden textualmente, pero el significado detrás de cada categoría no es el mismo, y cualquier análisis conjunto de inventario hereda esa ambigüedad.

Estos tres ejemplos comparten un patrón: el error no está en el dato en sí, sino en la falta de un acuerdo explícito sobre lo que ese dato representa.

Cómo evita estos problemas un espacio de datos

Un espacio de datos moderno no resuelve la interoperabilidad semántica de forma automática, pero proporciona la infraestructura necesaria para que las organizaciones participantes lleguen a ese acuerdo y lo mantengan vivo en el tiempo.

Vocabularios comunes en el catálogo federado

El broker de metadatos actúa como catálogo federado entre las organizaciones que participan en el espacio de datos. Cada conjunto de datos publicado se describe con metadatos estructurados que indican no solo dónde está el dato y quién lo ofrece, sino qué significa cada campo, en qué unidad se expresa y bajo qué condiciones se ha generado. Al exportar estos metadatos en un estándar como DCAT-AP-ES, se fuerza a las organizaciones a documentar su información siguiendo un vocabulario compartido en lugar de uno propio e implícito.

Esto no elimina la diversidad de modelos internos —cada organización sigue trabajando con sus propios sistemas—, pero obliga a hacer explícita la traducción entre el modelo interno y el modelo común en el momento de publicar el dato, que es precisamente el punto donde antes se perdía el significado.

Ontologías y modelos de datos como contrato técnico

Mientras que un vocabulario fija los términos, una ontología describe cómo se relacionan entre sí y en qué contexto se aplican: no basta con acordar que "fecha de entrega" es un campo de tipo fecha, hace falta especificar si se refiere a la salida del almacén, al tránsito o a la recepción. Estas relaciones, explícitas mediante identificadores y enlaces propios del enfoque de linked data, permiten a dos sistemas distintos razonar sobre los datos de forma coherente, no solo transmitirlos.

El último paso es traducir vocabularios y ontologías en modelos de datos técnicos: esquemas concretos que definen campos, tipos, formatos y restricciones. Este modelo compartido funciona como un contrato: cualquier organización que publique un dato de un tipo determinado sabe qué estructura debe seguir, y cualquier organización que lo consuma sabe qué esperar, sin necesidad de acuerdos bilaterales ad hoc con cada nuevo socio. El motor de políticas y el módulo de transferencia del espacio de datos se apoyan en estos modelos comunes para validar que los datos que circulan cumplen la estructura y el significado acordados.

Un ejemplo aplicado en Castilla y León

Imaginemos una industria agroalimentaria de Castilla y León que necesita compartir datos de calidad de materia prima con varios proveedores de la región. Sin un vocabulario común, cada proveedor envía sus certificados de calidad con sus propios criterios, escalas y unidades, obligando al equipo de calidad de la industria a normalizar manualmente cada entrega antes de poder compararlas.

Al incorporarse a un espacio de datos con un vocabulario y un modelo de datos compartidos para "calidad de materia prima", los proveedores publican su información siguiendo la misma estructura y las mismas definiciones. El equipo de calidad deja de traducir manualmente cada fuente y puede comparar entregas de distintos proveedores con la certeza de que un mismo campo significa lo mismo en todos los casos. El ahorro no está solo en el tiempo de integración técnica, sino en la reducción de errores de interpretación que antes pasaban desapercibidos.

Por dónde empezar

Lograr interoperabilidad semántica no es un proyecto que se complete una vez y se olvide. Requiere gobernanza continua: revisar los vocabularios cuando aparecen nuevos casos de uso, mantener actualizadas las ontologías y asegurar que los modelos de datos evolucionan de forma coordinada entre todas las organizaciones participantes.

Un espacio de datos regional proporciona el marco donde esa gobernanza compartida tiene sentido, porque reúne a las organizaciones interesadas en torno a catálogos, vocabularios y modelos comunes que nadie tendría incentivos para mantener en solitario.

Si tu organización necesita compartir datos con proveedores, clientes o administraciones y quiere evitar que los malentendidos semánticos contaminen sus análisis y decisiones, un espacio de datos moderno ofrece la infraestructura y el acompañamiento técnico para construir ese acuerdo semántico desde el primer intercambio. Busca un socio tecnológico con experiencia en espacios de datos para conocer cómo empezar.