Anexo Técnico: Modelo Nacional de Interoperabilidad de Información
Documento de trabajo — propuesta inicial
Este anexo técnico complementa la nota de análisis y propone una arquitectura conceptual e implementación de referencia para articular componentes de información pública y de interés público que ya existen en la República Argentina.
El documento no pretende reemplazar los estándares oficiales existentes ni imponer una tecnología única. Su objetivo es explorar una posible estructura común que permita que sistemas, organismos y fuentes diferentes puedan identificar, interpretar, relacionar y utilizar información de manera interoperable.
1. Diagnóstico de la infraestructura existente: articular en lugar de reinventar
Argentina no parte desde cero. El país ya cuenta con activos normativos y técnicos de considerable valor que pueden constituir la base de una infraestructura nacional de información interoperable.
Datos abiertos y metadatos administrativos
La Ley 27.275 de Acceso a la Información Pública, el Decreto 117/2016 y el Perfil Nacional de Metadatos para Datos Abiertos conforman una base normativa y técnica para la publicación, documentación y catalogación de información pública en formatos electrónicos abiertos y reutilizables.
Infraestructura de Datos Espaciales
La Infraestructura de Datos Espaciales de la República Argentina (IDERA) proporciona estándares, perfiles de metadatos, catálogos de objetos geográficos y pautas para la publicación de información y servicios geoespaciales interoperables, incluyendo estándares OGC como WMS, WFS y WCS.
La infraestructura existente demuestra que el país ya dispone de numerosos componentes necesarios para una arquitectura nacional de información.
El desafío
El problema, por lo tanto, no consiste necesariamente en crear nuevas capas tecnológicas desde cero, sino en articular los estándares y sistemas existentes bajo un modelo común de interoperabilidad.
La finalidad sería permitir que información semántica, administrativa, estadística, económica y geoespacial pueda relacionarse sin que cada organismo o sistema tenga que reconstruir manualmente el significado de los datos producidos por los demás.
Argentina ya posee muchos de los componentes fundamentales de una infraestructura nacional de información. El desafío es conseguir que esos componentes puedan trabajar conjuntamente.
2. Modelo Nacional de Interoperabilidad de Información
La propuesta no establece un formato de archivo único para toda la información nacional.
No se plantea que todos los organismos deban publicar necesariamente un único tipo de archivo, ni que JSON, JSON-LD, CSV, XML, GeoJSON u otros formatos deban ser tratados como equivalentes.
Se propone, en cambio, un Modelo Nacional de Interoperabilidad de Información: una capa común de conceptos, identificadores, metadatos y reglas que pueda ser implementada mediante diferentes formatos y servicios.
MODELO NACIONAL
DE INTEROPERABILIDAD
│
┌─────────────────┼─────────────────┐
│ │ │
SEMÁNTICA IDENTIDAD METADATOS
│ │ │
└─────────────────┼─────────────────┘
│
┌───────────┼───────────┐
│ │ │
MEDICIÓN TIEMPO TERRITORIO
│ │ │
└───────────┼───────────┘
│
GEOMETRÍA
│
FORMATOS / SERVICIOS
│
┌──────────────┼──────────────┐
↓ ↓ ↓
JSON-LD GeoJSON WFS
CSV XML API
etc. etc. etc.
La arquitectura se entiende como una capa de interoperabilidad, no como un reemplazo de los estándares técnicos especializados ya existentes.
3. Dimensiones fundamentales del modelo
3.1 Semántica
Los datos deben utilizar vocabularios, diccionarios y definiciones comunes que permitan determinar qué representa cada variable.
Por ejemplo, no debería considerarse automáticamente equivalente:
trabajadores
empleos
puestos de trabajo
empleo registrado
personas ocupadas
El modelo debería permitir identificar con precisión:
- nombre de la variable;
- definición;
- población o universo al que se refiere;
- alcance;
- clasificación utilizada;
- relación con otros conceptos;
- fuente del vocabulario o definición.
El objetivo es que dos sistemas diferentes puedan reconocer cuándo están hablando del mismo concepto y cuándo no.
3.2 Identidad e identificadores
Las entidades que ya poseen identificadores oficiales deberían utilizar esos identificadores en lugar de códigos creados arbitrariamente por cada sistema.
Esto puede incluir:
- unidades territoriales;
- organismos;
- actividades económicas;
- establecimientos;
- registros;
- infraestructuras;
- partidas o unidades catastrales, cuando corresponda;
- personas jurídicas, cuando corresponda y conforme al régimen aplicable;
- otros objetos que dispongan de identificadores oficiales.
Cuando una entidad ya dispone de un identificador oficial y vigente, los sistemas interoperables deberían utilizar ese identificador o mantener una correspondencia explícita con él.
3.3 Metadatos y procedencia
Los metadatos deben permitir conocer qué información se está observando, quién la produce, bajo qué metodología, cuándo fue publicada y cómo puede ser reutilizada.
Como mínimo, según la naturaleza del conjunto de datos, deberían poder describirse:
- identificador del conjunto de datos;
- título;
- organismo o entidad responsable;
- fuente;
- fecha de publicación;
- período de referencia;
- frecuencia de actualización;
- metodología;
- licencia;
- cobertura territorial;
- variables;
- unidades de medida;
- restricciones de acceso;
- documentación asociada;
- fecha de última validación o actualización.
La interoperabilidad requiere también trazabilidad: un sistema consumidor debe poder conocer de dónde proviene el dato que está utilizando.
3.4 Calidad
La procedencia oficial de una fuente no debería confundirse automáticamente con la calidad estadística o técnica de un dato.
Por ello, el modelo debería distinguir entre:
FUENTE
¿Quién produce o publica el dato?
CALIDAD
¿Cómo fue obtenido, validado y documentado?
METODOLOGÍA
¿Cómo fue medido o calculado?
ACTUALIZACIÓN
¿Cuándo fue revisado?
La clasificación de calidad debería basarse en criterios documentados y verificables, evitando utilizar simplemente términos como “oficial” como si fueran una medida universal de exactitud.
3.5 Medición
Toda medición debería poder expresar, cuando corresponda:
- variable medida;
- definición de la variable;
- valor;
- unidad de medida;
- población o universo;
- cobertura;
- período de referencia;
- metodología;
- clasificación utilizada;
- tratamiento de datos faltantes o estimados.
Esto resulta especialmente importante para evitar que valores numéricos aparentemente iguales sean interpretados como equivalentes cuando en realidad representan fenómenos diferentes.
3.6 Tiempo
La dimensión temporal debe formar parte de la interoperabilidad.
Un dato no debería ser interpretado solamente por su valor, sino también por el período al que corresponde.
El modelo debería permitir distinguir, según el caso:
- fecha de publicación;
- fecha de actualización;
- período de referencia;
- fecha de inicio y finalización de una medición;
- frecuencia de actualización;
- vigencia del dato.
3.7 Territorio
La información susceptible de localización debería vincularse con las unidades territoriales oficiales correspondientes.
El modelo debería permitir relacionar, cuando corresponda:
- país;
- provincia;
- departamento;
- municipio;
- localidad;
- región;
- unidad estadística;
- otras divisiones territoriales reconocidas oficialmente.
La referencia territorial debe utilizar identificadores estables y documentados, evitando depender exclusivamente del nombre textual de una localidad.
Por ejemplo:
"San Miguel"
"San Miguel de Tucumán"
no deberían resolverse únicamente mediante coincidencia de texto. Un identificador territorial permite determinar inequívocamente qué entidad representa cada registro.
3.8 Geometría
La existencia de una referencia territorial no implica necesariamente que el dato deba contener una geometría.
Por ello se distinguen:
Identidad territorial
municipio_id = 240056
de:
Representación geométrica
geometry = ...
Cuando exista información espacial, su representación debería ajustarse al marco geodésico y a las especificaciones técnicas aplicables.
4. Precisiones técnicas sobre georreferenciación
4.1 Marco geodésico de referencia
La información geoespacial producida en el marco nacional debería expresarse conforme al Marco de Referencia Geodésico Nacional POSGAR 07, utilizando el sistema de coordenadas y código CRS apropiado para la naturaleza del dato y del servicio.
Debe distinguirse entre:
- marco geodésico nacional, como POSGAR 07;
- sistema de coordenadas o CRS concreto utilizado por un conjunto de datos;
- código EPSG que identifica técnicamente dicho CRS cuando corresponda.
Por lo tanto, no debe suponerse que POSGAR 07 y un determinado código EPSG son conceptos equivalentes.
4.2 Formatos y servicios geoespaciales
Los formatos de intercambio y los servicios web cumplen funciones diferentes.
Formatos de intercambio
- GeoJSON;
- CSV;
- JSON-LD;
- XML;
- otros formatos abiertos apropiados.
Servicios interoperables
- WMS para representación cartográfica;
- WFS para entidades vectoriales;
- WCS para coberturas;
- APIs de consulta y distribución;
- otros servicios compatibles con los estándares adoptados.
La propuesta no pretende homologar estas tecnologías entre sí. La exigencia sería que la información pueda distribuirse mediante formatos y servicios interoperables adecuados a su naturaleza, de acuerdo con los estándares nacionales e internacionales aplicables.
5. Ejemplo práctico: estructura de referencia
El siguiente ejemplo es exclusivamente ilustrativo. No representa un conjunto de datos oficial existente.
{
"$schema": "https://ejemplo.gob.ar/esquema/interoperabilidad/v1/schema.json",
"@context": {
"schema": "http://schema.org/",
"clae": "https://ejemplo.gob.ar/vocabularios/clae/",
"indicadores": "https://ejemplo.gob.ar/vocabularios/indicadores/"
},
"ejemplo": true,
"naturaleza": "modelo_propuesto",
"type": "Feature",
"metadata": {
"dataset_id": "ar-ejemplo-empleo-local-2026",
"titulo": "Registro de ejemplo de empleo formal local",
"fecha_publicacion": "2026-09-22T00:00:00Z",
"frecuencia_actualizacion": "R/P1M",
"licencia": "https://creativecommons.org/licenses/by/4.0/deed.es"
},
"fuente": {
"tipo": "organismo_publico",
"identidad": "Organismo emisor (ejemplo)",
"responsable": "Área responsable (ejemplo)"
},
"calidad": {
"nivel_validacion": "campo_de_ejemplo",
"metodologia_url": "https://ejemplo.gob.ar/metodologia",
"fecha_validacion": "2026-09-01"
},
"territorio": {
"pais_id": "AR",
"provincia_id": "24",
"provincia_nombre": "Tucumán",
"departamento_id": "24084",
"departamento_nombre": "Capital",
"municipio_id": "240056",
"municipio_nombre": "San Miguel de Tucumán"
},
"referencia_espacial": {
"marco_geodesico": "POSGAR 07",
"codigo_crs": "EPSG:4326"
},
"properties": {
"actividad_economica": {
"clae_codigo": "620100",
"descripcion": "Actividad económica de ejemplo"
},
"medicion": {
"variable": "indicadores:empleo_registrado_puestostrabajo",
"valor": 1250,
"unidad_medida": "puestos",
"periodo_referencia": "2026-08",
"tipo_cobertura": "registrado_formal"
}
},
"geometry": {
"type": "Point",
"coordinates": [-65.2176, -26.8241]
}
}
Nota: Los identificadores, vocabularios, códigos y valores utilizados en este ejemplo tienen finalidad exclusivamente demostrativa y deberían ser reemplazados por las referencias oficiales correspondientes en una implementación real.
6. Identificadores oficiales
El modelo debería evitar la generación de códigos ad-hoc cuando ya exista un sistema nacional de identificación aplicable.
| Campo del modelo | Fuente / sistema de referencia | Ejemplo |
|---|---|---|
provincia_id |
Codificación territorial oficial aplicable | "24" |
departamento_id |
Codificación territorial oficial aplicable | "24084" |
municipio_id |
Codificación territorial oficial aplicable | "240056" |
clae_codigo |
Clasificador de actividades económicas vigente | "620100" |
marco_geodesico |
IGN / marco geodésico nacional | "POSGAR 07" |
codigo_crs |
Código CRS/EPSG correspondiente | "EPSG:4326" / otro CRS aplicable |
La tabla es ilustrativa y no pretende sustituir los catálogos oficiales.
7. Reglas generales para APIs y servicios de consulta
Las implementaciones que adopten el modelo deberían facilitar la consulta automatizada de la información.
7.1 Filtros territoriales
GET /api/v1/recursos?municipio_id=240056
7.2 Consultas temporales
GET /api/v1/recursos?fecha_desde=2026-01-01&fecha_hasta=2026-08-31
7.3 Consultas por variables
GET /api/v1/recursos?clae_codigo=620100
7.4 Combinación de filtros
El objetivo final debería ser poder cruzar:
municipio
+
actividad económica
+
período
+
variable
sin reconstruir manualmente la estructura de cada fuente.
8. Compatibilidad con la infraestructura existente
El Modelo Nacional de Interoperabilidad debería diseñarse para convivir con:
- Perfil Nacional de Metadatos para Datos Abiertos;
- data.gob.ar y mecanismos de catalogación;
- IDERA;
- catálogos de objetos geográficos;
- estándares ISO aplicables;
- estándares OGC;
- sistemas estadísticos existentes;
- registros administrativos;
- APIs y servicios públicos ya operativos.
La finalidad sería construir una capa de articulación, no reemplazar las infraestructuras especializadas.
9. No existe una única tecnología obligatoria
JSON-LD puede constituir una alternativa para expresar relaciones semánticas.
GeoJSON puede resultar apropiado para determinados datos geográficos.
CSV puede continuar siendo útil para determinados conjuntos tabulares.
XML puede ser necesario en determinados sistemas.
WFS, WMS, WCS y APIs pueden servir para diferentes modalidades de distribución.
La cuestión central no es imponer uno de estos mecanismos, sino garantizar que los sistemas puedan comprender y relacionar el significado de la información.
10. Validación e interoperabilidad
Una implementación nacional debería contemplar mecanismos automáticos de validación.
Según el tipo de dato, un sistema consumidor debería poder comprobar:
- existencia y validez del identificador;
- tipo de dato;
- unidad de medida;
- período;
- referencia territorial;
- sistema de referencia;
- presencia de metadatos mínimos;
- vocabulario utilizado;
- procedencia declarada.
Esto permitiría pasar de una interoperabilidad dependiente principalmente de interpretación humana a otra en la que una parte importante de las comprobaciones pueda realizarse automáticamente.
11. Beneficio para análisis, planificación e inteligencia artificial
Una estructura interoperable no solamente facilitaría la consulta humana.
También permitiría que herramientas estadísticas, sistemas SIG, aplicaciones, motores de búsqueda y sistemas de inteligencia artificial trabajen sobre información con mayor contexto.
Un sistema podría recibir:
VARIABLE
empleo registrado
VALOR
1250
UNIDAD
puestos de trabajo
ACTIVIDAD
620100
TERRITORIO
240056
PERÍODO
2026-08
FUENTE
organismo determinado
METODOLOGÍA
documentación asociada
en lugar de recibir solamente:
1250
Un número aislado es un dato. Un número contextualizado puede convertirse en información reutilizable.
12. Principio de neutralidad tecnológica
La regulación debería definir principalmente:
- qué debe poder comprender un sistema;
- qué información mínima debe acompañar un dato;
- cómo debe identificarse una entidad;
- cómo debe expresarse su relación territorial y temporal;
- qué mecanismos de validación deben existir;
- qué niveles de interoperabilidad deben cumplirse.
Las tecnologías concretas podrán evolucionar sin necesidad de modificar el principio estructural.
13. Implementación progresiva
Etapa 1 — Normalización conceptual
Definición de vocabularios, identificadores, metadatos, unidades, períodos, reglas territoriales y requisitos mínimos.
Etapa 2 — Catálogo nacional de interoperabilidad
Registro de vocabularios, identificadores, esquemas, catálogos, APIs, servicios geoespaciales y mecanismos de validación.
Etapa 3 — Adaptación de nuevos sistemas
Los nuevos sistemas públicos que produzcan información reutilizable deberían diseñarse desde el inicio conforme al modelo.
Etapa 4 — Adaptación progresiva de sistemas existentes
Los sistemas heredados podrían incorporarse mediante capas de interoperabilidad, adaptadores o servicios de traducción, evitando exigir una reconstrucción inmediata de cada sistema.
Etapa 5 — Interoperabilidad ampliada
Una vez consolidada la infraestructura pública, podrían incorporarse progresivamente otras fuentes de interés público, conforme a su régimen jurídico y reglas de publicación.
14. Información producida por actores no estatales
La interoperabilidad no debería confundirse con una obligación general de hacer pública la información privada.
Una persona, empresa, cooperativa, organización o institución privada no debería quedar obligada por este modelo simplemente por generar o poseer información.
La cuestión cambia cuando un actor decide publicar voluntariamente información de interés público.
En ese caso, cuando corresponda y dentro del marco jurídico aplicable, la publicación podría acogerse a reglas de interoperabilidad que permitan que esa información sea comprendida y relacionada con otras fuentes.
La obligación de interoperabilidad se vincula a la publicación pública de información alcanzada por el modelo, no a la mera generación o posesión de información privada.
15. Resultado buscado
El objetivo final no es producir más documentos ni simplemente aumentar la cantidad de datos publicados.
El objetivo es conseguir que la información que ya produce el país pueda trabajar conjuntamente.
Que un dato producido por un organismo pueda ser localizado por otro sistema.
Que una estadística pueda relacionarse con un territorio.
Que una actividad económica pueda relacionarse con empleo, infraestructura o producción.
Que una serie temporal pueda compararse con otra sin reconstruir manualmente sus períodos.
Que un sistema pueda determinar qué significa una variable antes de utilizarla.
Que una herramienta de análisis pueda consultar información proveniente de diferentes fuentes sin interpretar cada archivo desde cero.
16. Principio estructural
Un país no puede planificar eficazmente aquello que no puede describir, localizar, relacionar y medir de manera común.
La interoperabilidad no significa que todos los organismos deban utilizar el mismo software, la misma base de datos o el mismo formato.
Significa que sistemas diferentes puedan reconocer y utilizar un mismo dato sin perder su significado.
La normalización no consiste en obligar a todos los organismos a utilizar el mismo formato. Consiste en conseguir que sistemas diferentes puedan identificar, interpretar, relacionar y utilizar un mismo dato sin tener que reconstruir manualmente su significado.
17. Consideración final
Este anexo constituye una propuesta técnica inicial, no una especificación normativa definitiva.
Su finalidad es abrir una discusión sobre cómo podría construirse una infraestructura nacional de interoperabilidad aprovechando los estándares, catálogos, registros y sistemas que Argentina ya posee.
El desarrollo posterior debería involucrar a los organismos técnicos competentes, especialistas en datos, geoinformación, estadística, administración pública, seguridad de la información, protección de datos personales, infraestructura tecnológica y representantes de los sectores que producen y utilizan información de interés público.
La arquitectura propuesta pretende servir como punto de partida:
No crear información desde cero, sino conseguir que la información que ya existe pueda hablar entre sí.