AGORA: un perfil de acceso para registros públicos listos para agentes

1. Introducción#

Un registro público es un hecho que un Estado ha acordado poner a disposición: si una empresa está registrada, si un vehículo tiene una multa pendiente, qué contratos adjudicó una entidad el mes pasado, qué decidió un tribunal en un caso. Toda política moderna de datos abiertos, desde los principios de Sebastopol de 2007 hasta el Reglamento europeo de Conjuntos de Datos de Alto Valor de 2023, descansa sobre la premisa de que el valor de esos registros se realiza solo cuando alguien distinto del Estado puede usarlos (Sebastopol 2007; EU 2023). Las políticas cumplieron su primer objetivo. La mayoría de los gobiernos opera hoy un catálogo nacional, la mayoría de los catálogos habla algún dialecto de DCAT, y el número de datasets publicados se cuenta en decenas de miles por país (OECD 2023).

No cumplieron el segundo. La literatura sobre utilización de datos abiertos ha documentado el mismo patrón durante una década: portales optimizados para el número de datasets y no para la reutilización, archivos desactualizados o sin contexto, y una ausencia persistente de acceso programático (Janssen et al. 2012; Zuiderwijk y Janssen 2014; Attard et al. 2015; Safarov et al. 2017). Una entrada de catálogo dice que un dataset existe y dónde se puede descargar un archivo. No permite que un programa resuelva un registro, filtre por un campo, pagine resultados, pregunte qué cambió desde una fecha dada, o sepa qué tan fresca es la respuesta. Esas son preguntas de consumo, y ningún estándar de uso amplio las responde para los registros públicos como clase.

Dos cosas han cambiado desde que se escribió esa literatura. La primera es el consumidor. Los agentes de software impulsados por modelos de lenguaje ahora recuperan datos públicos en nombre de las personas, en un volumen que ya es medible en el tráfico web (Cloudflare 2025), y lo hacen a través de interfaces de herramientas estructuradas y no de un navegador (Anthropic 2025; MCP 2026). Un agente no puede llenar un formulario web, esperar a que se renderice un certificado y leer el resultado; necesita una respuesta tipada, un identificador estable y una marca de tiempo. La segunda es que el costo de construir una capa de acceso bien tipada sobre un sistema existente ha caído de forma drástica, porque los mismos modelos de lenguaje pueden hacer la mayor parte del trabajo tedioso: leer un diccionario de datos, proponer un esquema, escribir las anotaciones de los campos, mapear campos a un estándar de dominio. Lo que no ha caído es el costo de equivocarse, y por eso la pregunta de ingeniería interesante no es si un modelo puede redactar una interfaz, sino qué verificaciones deciden si el borrador se publica.

Este artículo está escrito desde la posición de un operador. Croma opera una API pública que expone registros oficiales de Colombia, Perú y México a desarrolladores y agentes a través de un solo contrato: 80 endpoints sobre 46 fuentes al momento de escribir, con un servidor MCP y una versión en markdown de cada página de documentación (Croma 2026). Construirla implicó enfrentar, fuente por fuente, el mismo puñado de propiedades ausentes: ningún identificador que resuelva, ninguna consulta más allá de un formulario de búsqueda individual, ninguna forma de saber qué cambió, ninguna marca de tiempo, ningún error legible por máquina, ningún compromiso de disponibilidad. También implicó medir, en producción, lo que esas ausencias le cuestan al consumidor. En los 80 días que se reportan aquí, la solicitud mediana que tuvo que responderse al ritmo de la fuente tardó 2.6 segundos y el cinco por ciento más lento tardó más de 27; una solicitud de cada catorce falló porque la fuente falló. El mismo contrato, sobre las dos fuentes que mantenemos como datasets bajo el perfil que se describe abajo, respondió en 75 milisegundos en la mediana.

Contribuciones#

1. Un mapa por capas del panorama de estándares de datos abiertos gubernamentales (política, catálogo, guías de API, esquema de dominio, plataforma, superficie para agentes) que ubica la brecha de consumo y explica por qué las capas maduras no pueden cerrarla por sí solas (secciones 2 y 3).
2. AGORA, un perfil de acceso mínimo con ocho requisitos y tres niveles de conformidad, cada requisito emparejado con el estándar existente que compone y con una prueba que un validador puede ejecutar sin juicio humano (sección 4, apéndice A).
3. Una implementación de referencia en producción, descrita al nivel de su contrato y de sus dos arquetipos de fuente, con mediciones de latencia, frescura y disponibilidad sobre 25,153 solicitudes (secciones 5 y 7).
4. Un arnés de publicación para instituciones en el que un modelo de lenguaje propone y un conjunto fijo de compuertas dispone, con las compuertas especificadas como condiciones verificables por máquina y la autoridad del modelo acotada de forma explícita (sección 6).
5. Una evaluación de 37 fuentes oficiales en tres países frente a los criterios del perfil, a partir de documentación pública, con la rúbrica y la evidencia por fuente publicadas junto con el artículo (sección 7, apéndice C).
6. Una ruta de adopción y gobernanza derivada de los dos estándares de dominio que lograron adopción global, GTFS y OCDS, y adaptada al panorama institucional latinoamericano (sección 8).

Lo que este artículo no propone. No propone un nuevo vocabulario de metadatos, un nuevo esquema de dominio ni un nuevo transporte. DCAT describe bien los datasets; OCDS, GTFS, BODS y Akoma Ntoso codifican bien sus dominios; OpenAPI y JSON Schema describen bien las interfaces. AGORA es un perfil en el sentido en que DCAT-AP usa la palabra: una forma restringida y verificable de usar estándares que ya existen, para un propósito para el que no fueron diseñados individualmente.

2. Contexto: el panorama de estándares por capas#

Al campo de los datos abiertos gubernamentales no le faltan estándares. Le falta una forma de saber cuál de ellos aplica a un problema dado. Organizamos el panorama en seis capas (figura 1), ordenadas de la política al consumidor, y caracterizamos cada una por lo que decide y por lo que deja sin decidir.

Figura 1. Seis capas del panorama de datos abiertos gubernamentales. Las capas maduras deciden por qué se publican los datos, qué datasets existen, cómo debería diseñar una API una entidad y cómo se codifica un dominio. La capa de acceso, que decide cómo se resuelve, consulta, sigue en el tiempo y confía en un registro, es donde se ubica el perfil de este artículo. La capa de agentes por encima es el consumidor más nuevo y el menos atendido hoy.

Capa 1: política y gobernanza#

Los seis principios de la Carta Internacional de Datos Abiertos (abiertos por defecto; oportunos y completos; accesibles y utilizables; comparables e interoperables; para mejorar la gobernanza y la participación ciudadana; para el desarrollo inclusivo y la innovación) son la declaración de intención más ampliamente adoptada, suscrita por 29 gobiernos nacionales y 146 subnacionales al momento de escribir (Open Data Charter 2015). Descienden de los principios de Sebastopol de 2007 y de los diez principios de la Sunlight Foundation de 2010, que ya pedían datos procesables por máquina, oportunos, primarios y permanentes. Los principios FAIR, escritos para datos de investigación, aportan el vocabulario que la mayoría del trabajo posterior toma prestado: encontrables, accesibles, interoperables, reutilizables (Wilkinson et al. 2016).

Tres instrumentos legales convierten la intención en obligación y merecen mención aparte porque nombran directamente la capa de acceso. La Directiva de Datos Abiertos de la Unión Europea exige a los Estados miembros poner a disposición los conjuntos de datos de alto valor de forma gratuita, en formato legible por máquina, a través de APIs y, donde el anexo lo exige, como descarga masiva, bajo CC0 o CC BY 4.0 o una licencia abierta equivalente; el reglamento de ejecución de 2023 enumera seis categorías temáticas, incluidos los registros de empresas y la movilidad, y aplica desde el 9 de junio de 2024 (EU 2019; EU 2023). El Reglamento de Europa Interoperable, en vigor desde abril de 2024, hace obligatorias las evaluaciones de interoperabilidad para los servicios públicos transfronterizos (EU 2024). En Estados Unidos, la OPEN Government Data Act obliga a cada agencia federal a mantener un inventario legible por máquina de sus activos de datos (US 2019). En América Latina, los equivalentes son las leyes de transparencia (la Ley 1712 de 2014 de Colombia, la Ley General de Transparencia de México de 2015, reexpedida en 2025, y el decreto de la estrategia de datos abiertos de Perú de 2017) y los decretos de apertura por defecto; obligan a publicar y a catalogar, pero no, al momento de escribir, a ofrecer acceso programático.

Los índices de referencia premian lo que esos instrumentos exigen. El índice OURdata de la OCDE califica disponibilidad, accesibilidad y apoyo gubernamental a la reutilización en cuarenta países, y su edición de 2023 encontró que solo el 48% de los conjuntos de datos de alto valor estaban disponibles como datos abiertos (OECD 2023). Ninguno de los índices califica si un dataset publicado responde una consulta por registro. Un gobierno puede, por tanto, posicionarse bien mientras cada uno de sus registros solo es alcanzable a través de un formulario web, y varios lo hacen.

Capa 2: catálogo y metadatos#

El Vocabulario de Catálogo de Datos del W3C (DCAT), Recomendación desde 2014 y en su tercera versión desde agosto de 2024, es el vocabulario base para describir datasets, sus distribuciones y, desde la versión 3, series de datasets (W3C 2024). El perfil europeo DCAT-AP, custodiado por la acción SEMIC del programa Europa Interoperable y en la versión 3.0.1 desde octubre de 2025, es el dialecto continental de facto, con perfiles nacionales hijos en Alemania, Italia y Suiza y perfiles temáticos para datos geoespaciales y estadísticos (SEMIC 2025). Estados Unidos publica DCAT-US, el esquema del data.json de cada agencia federal: la versión 1.1 sigue en producción y siendo cosechada, y la versión 3.0 está publicada con su guía de implementación todavía en borrador (GSA 2026). Junto a DCAT están el tipo Dataset de Schema.org, que alimenta Google Dataset Search (Noy 2018), el esquema de cinco estrellas de Berners-Lee, que todavía enmarca cómo los publicadores piensan la legibilidad por máquina, y el Data Package de Frictionless, un descriptor JSON ligero preferido por periodistas de datos y grupos de investigación (Frictionless 2024).

Esta capa responde la pregunta qué datasets existen y dónde está el archivo. Deliberadamente no responde cómo obtengo el registro 4711. Una distribución DCAT tiene una URL de acceso y un tipo de medio; no tiene noción de registro, de clave, de filtro ni de cambio. La propia guía del grupo de trabajo de DCAT-AP trata los servicios de datos como un tipo de distribución, que es lo más cerca que llega el vocabulario, e incluso ahí la semántica del servicio queda fuera de alcance.

Capa 3: guías de diseño de API#

El Reino Unido, Canadá, Australia, Singapur e India, entre otros, publican estándares de diseño de API para sus entidades: REST por defecto, descripciones OpenAPI, reglas de versionado y deprecación, catálogos de API transversales al gobierno (GDS 2024; Canada 2024; Australia 2024). El Ministerio TIC de Colombia mantiene un marco nacional de interoperabilidad y un lenguaje común de intercambio, un diccionario de elementos de datos para el intercambio entre entidades (MinTIC 2026). Estos documentos son buen consejo de ingeniería y elevan el piso para las entidades que construyen APIs. También son, sin excepción, orientativos, por entidad y silenciosos sobre las propiedades que un consumidor de un registro necesita a través de las entidades: semántica de identificadores, feeds de cambios, procedencia, la forma de una respuesta de no encontrado. Una entidad que siga al pie de la letra la guía del Reino Unido puede igual publicar un registro de empresas sin forma de preguntar qué cambió desde el lunes.

Dos estándares técnicos de esta capa importan para el perfil. OpenAPI 3.1 y JSON Schema 2020-12 le dan a una interfaz una descripción legible por máquina que los agentes pueden leer directamente. El formato Problem Details de la IETF le da forma a los errores (RFC 9457), Web Linking le da un encabezado al descubrimiento (RFC 8288), la canonicalización de JSON le da a un registro un hash estable (RFC 8785), y la URI conocida api-catalog le da a un host un lugar donde listar sus interfaces (RFC 9727). El estándar OGC API Features es el único ejemplo de una API de acceso por registro, filtrable, relevante para gobierno, con descripción OpenAPI y URLs de elemento estables, y es el patrón del que el perfil toma más prestado (OGC 2022; ISO 2025).

Capa 4: esquemas de dominio#

Los estándares que de verdad cambiaron cómo publican los gobiernos son los esquemas de dominio. El Estándar de Datos de Contrataciones Abiertas (OCDS), lanzado en 2014, está implementado por más de cincuenta gobiernos y su registro lista más de cien publicadores (OCP 2026). La General Transit Feed Specification (GTFS) es usada por más de diez mil agencias de transporte en más de cien países (GTFS 2026). El Estándar de Datos de Beneficiarios Finales (BODS), el estándar de la Iniciativa Internacional para la Transparencia de la Ayuda, el Fiscal Data Package, SDMX para estadísticas, Akoma Ntoso para legislación y sentencias, y el Identificador Europeo de Jurisprudencia hicieron lo mismo, cada uno para un dominio (Open Ownership 2025; OASIS 2018; EU 2011). Junto a ellos están los esquemas de identificadores como el Identificador de Entidad Jurídica y el registro org-id.guide de listas de identificadores de organizaciones (GLEIF 2026).

Dos lecciones de esta capa dan forma a todo lo que sigue. Primera, los ganadores fueron pequeños. GTFS empezó como un puñado de archivos CSV que resolvían el problema de un consumidor, el enrutamiento de transporte; OCDS es un esquema JSON más un validador. Segunda, llegaron con herramientas y un custodio neutral: GTFS quitó Google de su nombre para reducir la resistencia de los proveedores, OCDS es custodiado por una organización sin ánimo de lucro y entrega un validador, un registro de datos y una mesa de ayuda. Ninguno impuso un transporte, un catálogo ni un lenguaje de consulta. Por eso AGORA los compone en lugar de competir con ellos: un registro de contratación bajo el perfil es una release de OCDS; el identificador de una sentencia es un ECLI donde la jurisdicción lo emite.

Capa 5: plataformas#

Los gobiernos despliegan un número pequeño de plataformas de catálogo. CKAN, de código abierto, sostiene data.gov, data.gov.uk, el dados.gov.br de Brasil y el datos.gob.mx de México; DKAN, su pariente en Drupal, sostiene el datosabiertos.gob.pe de Perú; Socrata (hoy Data & Insights de Tyler Technologies) sostiene el datos.gov.co de Colombia y buena parte de los gobiernos estatales y locales de Estados Unidos; OpenDataSoft, ArcGIS Hub y uData atienden el resto. Socrata es notable por entregar una API de consulta por dataset con filtros por campo, paginación y una columna de sistema :updated_at, y por eso las fuentes colombianas alojadas ahí puntúan bien en los criterios de consulta del perfil mientras los sistemas propios de las instituciones no (sección 7). La capa de plataformas es donde viven los modos de falla bien documentados de los datos abiertos: dependencia del proveedor, archivos desactualizados detrás de portadas pulidas, datos sin contexto y fragmentación entre jurisdicciones.

Capa 6: superficies para agentes#

La capa más nueva casi no tiene presencia gubernamental. El Model Context Protocol (MCP), un estándar abierto para conectar agentes basados en modelos de lenguaje con herramientas y datos, fue donado a la Agentic AI Foundation de la Linux Foundation en diciembre de 2025 con más de diez mil servidores públicos activos y 97 millones de descargas mensuales de SDK reportadas en ese momento; su especificación se revisa con una cadencia aproximadamente trimestral, la más reciente en julio de 2026 (Anthropic 2025; MCP 2026). Data Commons de Google publica un servidor MCP sobre estadísticas públicas (Google 2025). La convención llms.txt propone un índice en texto plano que un sitio publica para los modelos de lenguaje (Howard 2024); a mediados de 2026 un solo estado de Estados Unidos, Maryland, había publicado uno para su portal oficial, y los principales proveedores de modelos no se habían comprometido a leerlos (StateScoop 2026; Technical.ly 2026). No conocemos ningún registro nacional que publique un servidor MCP, una versión en markdown de sus registros o una descripción estructurada de herramientas para agentes. Este es el espacio más vacío del panorama, y el R7 del perfil está escrito para él.

3. La brecha de consumo#

Al leer las capas en conjunto emerge un patrón. Las capas 1 y 2 deciden que los datos existen y los describen. La capa 4 decide qué contiene un registro de un dominio dado. La capa 3 aconseja a una entidad sobre cómo construir una interfaz, sin decidir qué garantiza la interfaz. La capa 6 tiene consumidores esperando interfaces que no existen. Entre describir un dataset y codificar un registro no hay una capa que diga, para los registros públicos como clase, en qué puede confiar un consumidor. Llamamos a esto la brecha de consumo y la caracterizamos con siete propiedades que un consumidor necesita y que ninguna capa garantiza.

1. Resolución de registros. Dado un identificador que el propio Estado emite (un NIT, un RUC, un radicado, un OCID), obtener el registro, o una declaración definitiva de que no existe.
2. Consulta por campo. Filtrar por los campos que le importan al dominio, con resultados acotados y paginables, en lugar de un formulario de búsqueda individual o una descarga completa.
3. Cambio. Saber qué cambió desde un momento dado, sin releerlo todo.
4. Frescura. Saber cuándo fue cierta la respuesta: el último cambio del propio registro y el momento en que se tomó la instantánea.
5. Procedencia. Saber de qué institución viene el registro, bajo qué licencia, y qué versión del registro es esta.
6. Identidad entre registros. Reconocer que una empresa en el registro de contratación y la misma empresa en el registro tributario son una sola entidad, a través de espacios de nombres de identificadores y no de coincidencia de cadenas.
7. Acceso para máquinas y agentes. Hacer todo lo anterior desde un programa o un agente: una interfaz documentada, errores legibles por máquina, límites de tasa declarados, una descripción de herramienta que un agente pueda leer.

Tres tipos de evidencia sostienen la afirmación de que aquí es donde fallan los datos abiertos, y presentamos cada uno en las secciones que siguen. El primero es documental: una evaluación de 37 fuentes oficiales en tres países frente a trece criterios derivados de estas siete propiedades (sección 7.1). Su titular es que el acceso programático por registro está documentado por una minoría de fuentes, los feeds de cambios y los metadatos de frescura por casi ninguna, y las superficies para agentes por ninguna; donde una fuente puntúa bien es porque publica a través de una plataforma de catálogo nacional o de un estándar de dominio gobernado, no porque la institución haya diseñado para el consumo. El segundo es operativo: ochenta días de tráfico en producción a través de un contrato uniforme sobre esas fuentes (sección 7.2). Su titular es que el consumidor absorbe la varianza de la fuente. La misma forma de solicitud responde en un cuarto de segundo desde un registro y en veinticuatro segundos desde otro; una solicitud de cada catorce falla aguas arriba. El tercero es estructural: las propias pruebas de conformidad del perfil, que fallan en la mayoría de las fuentes por los mismos tres requisitos (sección 4).

Por qué las capas maduras no pueden cerrar la brecha. Es tentador proponer cerrar la brecha por extensión: agregar propiedades a nivel de registro a DCAT, agregar semántica de feed de cambios a OCDS, agregar una cláusula de API obligatoria a cada guía nacional. Cada una de estas cosas se está intentando por separado, y cada una está a la altura equivocada. DCAT describe datasets y debe seguir haciéndolo; un lenguaje de consulta a nivel de registro no pertenece a un vocabulario de catálogo. OCDS describe contratación y debe seguir haciéndolo; un feed de cambios es una propiedad de cualquier registro, no de la contratación. Las guías nacionales de API son por país por construcción; un consumidor que abarca países necesita un contrato que no dependa de qué ministerio escribió la guía. Lo que se necesita es una capa delgada con nombre propio, tan pequeña que un estándar de dominio pueda incrustarse en ella sin cambios y que un catálogo pueda apuntar a ella sin cambios. Ese es el encargo de diseño de AGORA.

Por qué ahora. La brecha ha existido desde el primer portal. Dos cosas la vuelven urgente. Los agentes son una clase de consumidor que no puede rodear la estructura ausente como lo hace un humano con un navegador; para ellos la brecha no es fricción sino un muro, y las solicitudes de rastreadores de IA alcanzaron el 4.2% del tráfico HTML visto por una gran red en 2025, a la par del mayor rastreador de búsqueda (Cloudflare 2025). Y las herramientas para cerrar la brecha se han vuelto baratas: un modelo de lenguaje puede redactar un esquema tipado y sus anotaciones a partir de un diccionario de datos en minutos, así que la restricción que ata a una institución ya no son las horas de ingeniería sino la confianza en que lo que se publica es correcto. El perfil aporta el contrato; el arnés de la sección 6 aporta la confianza.

4. El perfil de acceso AGORA#

AGORA (Agent-ready Government Open Records Access) es un perfil de acceso: una forma restringida y verificable de publicar un registro de modo que un programa o un agente pueda consumirlo sin saber qué institución lo construyó. Se especifica como ocho requisitos, R1 a R8, agrupados en tres niveles de conformidad (figura 2). Cada requisito nombra el estándar existente que compone, establece lo que un publicador debe hacer y establece la prueba que ejecuta un validador. Las pruebas son la especificación; la prosa las explica.

Figura 2. Los ocho requisitos de AGORA y los tres niveles de conformidad que forman. Cada nivel es un superconjunto del anterior. El Nivel 1 hace que un registro sea legible por un programa; el Nivel 2 lo hace consultable y seguible en el tiempo; el Nivel 3 lo hace consumible por un agente sin humanos en el circuito.

4.1 Principios de diseño#

Componer, no competir. Cada requisito se expresa en términos de un estándar que ya tiene custodio. Los registros son documentos JSON Schema; las interfaces son documentos OpenAPI; los datasets son recursos DCAT; los registros de contratación son releases de OCDS; los errores son Problem Details. El perfil agrega restricciones y unos pocos nombres de campo, nada más. Un publicador que ya cumple con un estándar de dominio debería alcanzar el Nivel 2 sin cambiar un registro.

Mínimo, y luego verificable. Un requisito entra al perfil solo si un validador puede decidirlo sin juicio humano. Esto excluye propiedades valiosas, como la "calidad de los datos" o la "completitud", que no son decidibles desde afuera, y es la razón por la que el perfil tiene ocho requisitos y no los treinta que acumularía una lista de verificación. Las historias de GTFS y OCDS dicen lo mismo: gana la especificación más pequeña que tenga un validador.

Listo para agentes sin ser solo para agentes. Toda superficie que un agente necesita es también una superficie que un desarrollador necesita. La descripción de herramienta MCP de R7 se genera a partir del documento OpenAPI; el gemelo en markdown de una página de documentación es el mismo contenido negociado por tipo de medio; el índice llms.txt apunta a las mismas URLs que un humano guardaría. Nada en el perfil crea una segunda ruta de datos específica para agentes que pueda desviarse de la primera.

Procedencia por defecto. Un registro sin marca de tiempo y sin fuente es un rumor. El sobre de R5 es obligatorio en todos los niveles, porque es la propiedad cuya ausencia el consumidor menos puede sortear y la que los publicadores más a menudo omiten (sección 7.1).

Los identificadores de la fuente, no los nuestros. El perfil no acuña identificadores para registros que ya tienen uno. Una empresa es su número de registro; una sentencia es su radicado o su ECLI; un proceso de contratación es su OCID. Donde un identificador no tiene esquema, R2 le pide al publicador que declare uno, no al consumidor que lo invente.

4.2 Requisitos#

R1. Registros tipados#

Compone JSON Schema 2020-12 y los esquemas de dominio. Cada tipo de registro que el registro publica tiene un JSON Schema. Cada propiedad lleva una description legible por humanos y, donde un valor está codificado, una enumeración o una referencia a la lista de códigos. Los nombres de campo son estables entre versiones; un campo renombrado es una versión nueva. Donde existe un esquema de dominio gobernado para el tipo de registro (OCDS, BODS, GTFS, Akoma Ntoso, SDMX), el registro es una instancia de él o lleva un mapeo declarado hacia él.

Prueba. Obtener el esquema desde la descripción de la interfaz; validar una muestra de registros contra él; cada propiedad tiene una descripción no vacía; cada propiedad enumerada lista sus valores.

R2. Identificadores resolubles#

Compone URIs, ECLI, OCID, LEI y org-id.guide. Cada registro tiene un identificador que la institución publicadora emite, y una URL canónica que resuelve al registro (o a una respuesta definitiva de no encontrado). El esquema del identificador se declara: su espacio de nombres, su sintaxis y el registro que lo emite, usando un código de org-id.guide donde exista. Los identificadores de la misma entidad en distintos registros se relacionan por espacio de nombres, de modo que un consumidor pueda afirmar "la entidad conocida por el registro X como a" sin coincidencia de cadenas.

Prueba. Para una muestra de registros, la URL canónica devuelve el registro; un identificador sintácticamente válido pero no asignado devuelve found: false con HTTP 200, no un error; la declaración del esquema está presente en el schema.

R3. Contrato de consulta uniforme#

Compone OpenAPI 3.1 y el patrón de consulta de OGC API Features. La interfaz ofrece al menos dos operaciones por tipo de registro: búsqueda por identificador y búsqueda por campos declarados. Los resultados de búsqueda están acotados (un tamaño máximo de página declarado), paginados por un cursor opaco y ordenados de forma determinista. Qué campos son consultables se declara en el esquema, no se descubre por ensayo. Una búsqueda sin resultado es una respuesta, no un error: tiene la misma forma que un registro encontrado con found en false. Los errores usan Problem Details (RFC 9457).

Prueba. El documento OpenAPI declara ambas operaciones; una búsqueda con un cursor de una página anterior devuelve la página siguiente y nunca un duplicado; una solicitud que excede el límite de tamaño de página se rechaza con un cuerpo Problem Details que nombra el límite.

R4. Feed de cambios#

Compone un cursor monotónico sobre las marcas de tiempo del propio registro. Cada registro lleva _updated_at, el instante en que el publicador lo cambió por última vez. La búsqueda acepta updated_after, devolviendo solo los registros cambiados desde ese instante, en orden ascendente de cambio, de modo que un consumidor pueda reproducir el registro desde cualquier punto sin releerlo. Las eliminaciones también son registros: una lápida con _deleted_at aparece en el feed.

Prueba. Dos búsquedas con updated_after en t1 < t2 devuelven conjuntos donde el segundo es subconjunto del primero; cada registro devuelto tiene _updated_at mayor que el parámetro; el feed es estable bajo repetición.

R5. Sobre de procedencia#

Compone conceptos de PROV-O y metadatos de licencia de DCAT. Cada respuesta envuelve su carga en un sobre que declara: source (la institución, como identificador de org-id.guide donde sea posible), as_of (el instante en que los datos subyacentes se sincronizaron por última vez o, para una consulta en vivo, el instante de la recuperación), record_version (un hash del registro canónico, serializado con JCS según RFC 8785) y license (una URI). La distinción entre "último cambio" (R4) y "última verificación" (as_of) es deliberada: la primera es un hecho sobre el registro, la segunda sobre el proceso del publicador, y los consumidores necesitan ambas.

Prueba. Cada respuesta lleva los cuatro campos; as_of nunca es posterior al momento de la respuesta; dos respuestas para el mismo registro con igual record_version son idénticas byte a byte tras la canonicalización.

R6. Acceso masivo#

Compone distribuciones y series de datasets de DCAT. El conjunto completo de registros de cada tipo está disponible como una exportación masiva versionada, descrita como una distribución DCAT con dct:modified y una suma de verificación, y la exportación es derivable del feed de cambios (o el feed de la exportación): las dos son dos vistas de un mismo dataset, no dos datasets.

Prueba. La descripción DCAT es alcanzable desde la descripción de la interfaz; el conteo de registros de la exportación es igual al conteo que reporta la operación de búsqueda al mismo as_of; una muestra aleatoria de registros exportados coincide con la operación de búsqueda por identificador.

R7. Superficies para agentes#

Compone MCP, llms.txt, el api-catalog de RFC 9727 y la negociación de contenido. El publicador expone (i) un servidor MCP cuyas herramientas se generan a partir del documento OpenAPI, una herramienta por operación, con las descripciones del esquema como descripciones de herramienta; (ii) una versión en markdown de cada página de documentación y de cada registro, negociada con Accept: text/markdown en la misma URL y también disponible con sufijo .md; (iii) un índice llms.txt en la raíz del host que lista la descripción de la interfaz, el catálogo, la documentación y el feed; y (iv) un recurso conocido api-catalog (RFC 9727). Una descripción de herramienta establece qué significa una respuesta de no encontrado, para que un agente no reintente un negativo definitivo.

Prueba. La lista de herramientas del servidor MCP es isomorfa a las operaciones OpenAPI; cada URL de documentación responde markdown bajo negociación; /llms.txt y /.well-known/api-catalog resuelven y sus enlaces resuelven.

R8. Contrato operativo#

Compone OpenAPI, RFC 9457 y los encabezados de límite de tasa. El publicador declara límites de tasa en los encabezados de respuesta, una política de versionado y deprecación con un periodo mínimo de aviso, un compromiso de disponibilidad y una página de estado, y un contacto. Cada error es un documento Problem Details con un type estable legible por máquina. Una solicitud que no puede responderse dentro de un límite declarado se acepta para completarse de forma asíncrona (HTTP 202 con una URL de estado) en lugar de dejarse expirar.

Prueba. Los encabezados de límite de tasa están presentes en cada respuesta; la política de deprecación está enlazada desde la descripción de la interfaz; la página de estado resuelve; un error inducido devuelve Problem Details.

4.3 Niveles de conformidad#

Tabla 1. Niveles de conformidad. Cada nivel es un superconjunto del anterior; un validador reporta el nivel más alto cuyas pruebas pasan todas. R5 (sobre) y R2 (identificadores) están en el Nivel 1 a propósito: son las propiedades cuya ausencia un consumidor menos puede reparar después.

Los tres niveles se ordenan por lo que le permiten a un consumidor dejar de hacer. En el Nivel 1 el consumidor deja de analizar HTML y de adivinar la frescura. En el Nivel 2 deja de descargar el registro entero para responder una pregunta y deja de comparar instantáneas para saber qué cambió. En el Nivel 3 deja de necesitar un desarrollador que escriba la integración. Los niveles también ordenan el esfuerzo para un publicador: el Nivel 1 se alcanza con un archivo masivo y un esquema, que la mayoría de los catálogos nacionales ya alojan; el Nivel 2 necesita un servicio; el Nivel 3 se genera a partir del Nivel 2 con herramientas.

4.4 El sobre#

El sobre es el único formato de cable concreto que el perfil introduce, y es pequeño (el JSON Schema está en el apéndice B). Separa el registro de las afirmaciones sobre el registro, de modo que una carga bajo un estándar de dominio pueda incrustarse sin cambios: una release de OCDS va en data exactamente como OCDS la especifica, y el sobre dice de dónde vino y cuándo.

{
  "found": true,
  "source": { "id": "PE-OECE", "name": "OECE", "org_id": "XI-PB-PE-OECE" },
  "as_of": "2026-08-26T08:15:00Z",
  "record_version": "sha256:9f2c...e1",
  "license": "https://creativecommons.org/licenses/by/4.0/",
  "data": {
    "ocid": "ocds-dgv273-seacev3-873200",
    "_updated_at": "2026-08-21T14:02:11Z",
    "tender": { "title": "...", "status": "complete" }
  }
}

Una respuesta de no encontrado tiene el mismo sobre con found: false y sin data. Esta es la regla de mayor consecuencia del perfil para los agentes: un negativo definitivo que llega como HTTP 200 es una respuesta sobre la que un agente puede actuar, mientras que un 404 es indistinguible de una URL rota y se reintentará o se reportará como falla. Las descripciones de herramienta de la implementación de referencia lo dicen de forma explícita, y eso eliminó una clase entera de comportamientos erróneos de agentes que observamos antes de adoptarla.

4.5 Relación con los estándares existentes#

Tabla 2. Qué compone cada requisito y qué agrega. El perfil introduce una estructura de cable (el sobre) y tres nombres de campo; todo lo demás es una restricción sobre cómo se usa un estándar existente.

En cada fila lo agregado es una restricción o un nombre de campo, nunca un vocabulario competidor. Un catálogo DCAT-AP puede describir un registro conforme al perfil como un dcat:DataService con sus distribuciones, y el validador del perfil puede ejecutarse desde la entrada del catálogo. Un publicador de OCDS llega al Nivel 1 agregando el sobre y un puntero al esquema, y al Nivel 2 agregando updated_after a su búsqueda de releases existente, que el modelo de record package de OCDS ya anticipa. El perfil es, en ese sentido, la capa que OCDS y DCAT han venido asumiendo que existe.

5. Implementación de referencia#

El perfil no se diseñó en papel para después construirse. Se extrajo de una plataforma que tuvo que exponer varias decenas de registros a través de un solo contrato y que se topó una y otra vez con las mismas ausencias. Esta sección describe esa plataforma al nivel de su contrato, para que las mediciones de la sección 7 puedan leerse, y para que un segundo implementador tenga algo concreto con qué compararse. El detalle de producto queda fuera de alcance; la documentación pública lo cubre.

5.1 Alcance#

Al momento de escribir, la plataforma expone 80 endpoints: 75 sobre 46 fuentes oficiales o cuasi oficiales en Colombia (38 endpoints), México (25) y Perú (12), y cinco endpoints de contenido sin fronteras (búsqueda web, extracción e investigación) que quedan fuera del alcance de este artículo. Las fuentes abarcan los registros que un prestamista, un equipo de cumplimiento o un periodista consulta en la práctica: registros de empresas y de contribuyentes, registros de vehículos y de multas de tránsito, expedientes judiciales y jurisprudencia, contratación, sanciones disciplinarias y fiscales, estados financieros, gacetas oficiales, circulares regulatorias, legislación federal y boletines de fiscalías. Cada endpoint es una búsqueda por identificador o una búsqueda por campos en el sentido de R3, descrito en un único documento OpenAPI 3.1, y cada tipo de registro tiene un JSON Schema con campos descritos en el sentido de R1.

5.2 Dos arquetipos de fuente#

Las fuentes caen en dos arquetipos, y la distinción es el hecho más importante sobre las mediciones que siguen.

Respondida al ritmo de la fuente. Para la mayoría de las fuentes, una solicitud se responde consultando el propio sistema de la institución en el momento de la solicitud. La plataforma aporta el contrato: un registro tipado, el sobre, un no encontrado definitivo, un error legible por máquina con un código estable en caso de falla, límites de tasa declarados y finalización asíncrona cuando la fuente es lenta (la solicitud se acepta con HTTP 202 y una URL de estado, que el consumidor sondea). Lo que la plataforma no puede aportar es velocidad ni disponibilidad más allá de las de la propia fuente: si el sistema de la institución tarda veinte segundos o está caído, el consumidor ve veinte segundos o un error source_unavailable. Setenta y dos endpoints cayeron en este arquetipo durante la ventana de medición.

Respondida desde un dataset mantenido bajo el perfil. Para una fuente cuyos registros pueden enumerarse, la plataforma mantiene el conjunto completo de registros como un dataset: tipado por el esquema, sincronizado con la propia cadencia de publicación de la fuente, con cada registro llevando _updated_at y cada respuesta llevando as_of. Las búsquedas se responden desde el dataset. La búsqueda acepta los campos que le importan al dominio en lugar de los que el formulario de la fuente ofrece por casualidad, y updated_after devuelve solo lo que cambió. Durante la ventana este arquetipo cubrió la contratación pública de Perú (OECE, publicada por la institución bajo OCDS) y, desde el último día de la ventana, las 311,878 tesis de la Suprema Corte de México. Este arquetipo es lo que un publicador de Nivel 2 parece desde afuera; la plataforma hace las veces de la institución hasta que la institución publique bajo el perfil por sí misma.

Figura 3. Arquitectura de referencia. Un contrato antecede a dos arquetipos: fuentes respondidas a su propio ritmo en el momento de la solicitud, y datasets mantenidos bajo el perfil. Las superficies para agentes (herramientas MCP, gemelos en markdown, llms.txt, api-catalog) se generan a partir del contrato, nunca se escriben a mano, así que no pueden desviarse de él.

5.3 El contrato tal como está implementado#

• Registros e identificadores (R1, R2). El esquema de respuesta de cada endpoint es un registro tipado con campos descritos; los identificadores son los de la institución (NIT, RUC, radicado, OCID, número de registro). Un identificador sintácticamente válido sin registro devuelve found: false con HTTP 200. La documentación establece, por endpoint, que esta es una respuesta definitiva y no un error; las instrucciones del servidor MCP lo repiten.
• Consulta (R3). Búsqueda por identificador y por campos declarados, con tamaños de página acotados. Los errores son un sobre fijo con un código estable legible por máquina. Existen variantes por lotes donde los consumidores las pidieron.
• Cambio (R4). Los endpoints respaldados por dataset aceptan updated_after y exponen _updated_at. Los endpoints al ritmo de la fuente no pueden ofrecerlo, porque la fuente no lo ofrece; este es el requisito que separa con más claridad los arquetipos.
• Sobre (R5). Cada endpoint está ligado a una única fuente nombrada en su descripción. Las respuestas respaldadas por dataset llevan as_of y la marca de tiempo del propio registro; las respuestas al ritmo de la fuente se responden en el momento de la recuperación y todavía no llevan un as_of explícito. Las respuestas pueden reutilizarse dentro de una ventana de frescura declarada, y una respuesta reutilizada lo indica en un encabezado.
• Superficies para agentes (R7). Un servidor MCP expone cada endpoint como una herramienta, con descripciones de herramienta generadas a partir de las mismas descripciones de esquema que lleva el documento OpenAPI. Cada página de documentación y cada entrada del changelog responde markdown en su propia URL bajo negociación de contenido y con sufijo .md; el sitio publica llms.txt, un recurso conocido api-catalog y encabezados Link que apuntan a todos ellos.
• Operación (R8). Los límites de tasa se declaran en encabezados, con una política diaria por llave; se publica una política de versionado y deprecación; existe una página de estado; las fuentes lentas se responden de forma asíncrona.

5.4 Lo que la implementación todavía no satisface#

La plataforma no es un publicador de Nivel 3 completo y este artículo no afirma que lo sea. La exportación masiva (R6) existe solo para el arquetipo de dataset; los endpoints al ritmo de la fuente no pueden ofrecerla por construcción. El sobre (R5) está completo solo para las respuestas respaldadas por dataset: las respuestas al ritmo de la fuente carecen de un as_of explícito, y record_version (un hash canónico) todavía no se emite en ninguno de los dos casos. Los errores llevan códigos estables en un sobre fijo pero todavía no son Problem Details de RFC 9457 (R3, R8). Los espacios de nombres de identificadores entre registros (R2, la declaración de org-id.guide) están documentados por endpoint en lugar de declarados en el esquema. Cada uno de estos puntos está programado, y cada uno es un cambio menor que los ya hechos; los listamos porque una implementación de referencia que exagerara su conformidad socavaría el validador que defiende.

6. Un arnés de publicación para instituciones#

El perfil dice cómo se ve un registro conforme. Esta sección trata de cómo llega ahí una institución, y en particular de cómo un modelo de lenguaje puede hacer la mayor parte del trabajo sin que se le confíe decidir si el trabajo está bien. El diseño viene de nuestro propio ciclo de incorporación, que ha llevado varias decenas de fuentes desde "un sistema con un diccionario de datos" hasta "un endpoint conforme, documentado y visible para agentes", y que cambió de forma cuando dejamos de pedirle al modelo que construyera cosas y empezamos a pedirle que propusiera cosas para que un conjunto fijo de compuertas las aceptara o rechazara.

6.1 La forma del problema#

Una institución que quiere publicar un registro bajo el perfil parte de una de tres posiciones: una base de datos o API interna con un diccionario de datos (el caso común), una exportación pública o entrada de catálogo existente (un CSV masivo en el portal nacional), o una interfaz pública existente anterior al perfil (un formulario de búsqueda, un servicio SOAP). En las tres, los pasos costosos son los mismos: entender el registro, escribir el esquema y sus descripciones, decidir el esquema de identificadores, mapear a un estándar de dominio donde aplique, generar la interfaz y su documentación, y verificar que todo eso sea cierto del sistema en vivo. Los primeros cuatro son tareas de lenguaje sobre documentos que la institución ya tiene; un modelo las hace bien y rápido. El último no es una tarea de lenguaje, y es donde los errores se convierten en consecuencias.

6.2 El pipeline#

Figura 4. El arnés de publicación. Seis etapas; el modelo propone en las tres primeras y la última es monitoreo. Entre etapas hay compuertas que son condiciones verificables por máquina sobre artefactos, no juicios sobre texto. Una propuesta que falla una compuerta vuelve al modelo con la falla adjunta; nada llega a la etapa de publicación sin haber pasado todas las compuertas, y un humano revisa los reportes de las compuertas, no la prosa del modelo.

1. Descubrir. Entradas: el diccionario de datos de la institución, registros de muestra, documentación existente y (si existe) la interfaz pública actual. El modelo produce un brief de la fuente: los tipos de registro presentes, el identificador que lleva cada uno y quién lo emite, los campos con sus tipos aparentes y listas de códigos, la cadencia de actualización hasta donde pueda inferirse, y el comportamiento de no encontrado del sistema existente. El brief es un documento para personas; también es la entrada a la que se somete la siguiente etapa.

2. Modelar. El modelo propone un JSON Schema por tipo de registro con una descripción para cada campo, una declaración de esquema de identificadores y, donde aplique un esquema de dominio gobernado, un mapeo a nivel de campo hacia él (la fecha_adjudicacion de este registro de contratación es awards[].date de OCDS). La propuesta está anotada: cada descripción cita la entrada del diccionario o la muestra de la que vino. Compuerta: el esquema valida las muestras; cada campo tiene una descripción; los campos destino del mapeo existen en la propia definición del esquema de dominio; las enumeraciones cubren cada valor visto en las muestras.

3. Generar. A partir del esquema aceptado, el arnés genera, de forma determinista, el documento OpenAPI, el envoltorio del sobre, el vocabulario de errores, el manifiesto de herramientas MCP, la documentación en markdown y la entrada de llms.txt. El papel del modelo se limita a la prosa que el generador no puede escribir: ejemplos resueltos y la descripción en lenguaje llano del registro. Compuerta: los artefactos generados son consistentes entre sí por construcción (comparten una fuente); la prosa del modelo se verifica contra un vocabulario fijo que excluye cualquier cosa que la institución no quiera publicar, y contra reglas de marcadores de posición para identificadores personales en los ejemplos.

4. Verificar. Las pruebas de conformidad de la sección 4.2 se ejecutan contra la interfaz en vivo: búsquedas por identificadores conocidos, una sonda de no encontrado con un identificador válido pero no asignado, paginación por cursor, reproducción con updated_after, campos del sobre, encabezados de límite de tasa, la negociación de markdown, la lista de herramientas MCP contra las operaciones OpenAPI. Compuerta: pasan todas las pruebas del nivel objetivo. Esta compuerta es el centro de gravedad del arnés: no se puede discutir con ella, produce el reporte que lee un humano, y es lo que el modelo intenta satisfacer en las etapas anteriores.

5. Publicar. Los artefactos se despliegan; la entrada del catálogo (DCAT) se escribe o actualiza para apuntar a la interfaz; el cambio se anuncia a través del feed. Compuerta: las URLs publicadas resuelven y el validador pasa contra la dirección pública, no contra la de pruebas.

6. Monitorear. Las pruebas de conformidad se ejecutan de forma continua como canarios; el esquema del registro se verifica contra una muestra de registros en vivo para detectar deriva (un campo que cambió de tipo, un valor nuevo en una enumeración, una forma de no encontrado que cambió); la frescura se verifica contra la cadencia declarada. Una falla abre un reporte que reingresa al ciclo en la etapa que implica.

6.3 Lo que el modelo puede y no puede hacer#

Tabla 3. La autoridad del modelo por etapa. El patrón es uniforme: el modelo propone sobre documentos y revisa contra reportes; el arnés genera y verifica; las personas aprueban los reportes de las compuertas.

El principio detrás del límite es que un modelo es un buen autor y un mal testigo: puede escribir un esquema plausible, completo y bien descrito mucho más rápido que una persona, y no se puede confiar en que sepa si el esquema es cierto del sistema. Por eso el arnés nunca deja que el modelo sea el último paso. Cada artefacto que se publica es, o bien generado de forma determinista a partir de algo que una compuerta aceptó, o bien prosa que pasó una verificación de vocabulario fijo. Las pruebas son de la institución, no del modelo; una propuesta que falla se devuelve con la falla adjunta, y el modelo revisa. Es el mismo ciclo que sigue un ingeniero cuidadoso; la diferencia es que el ciclo es explícito, las compuertas tienen nombre y el modelo no puede saltarse ninguna.

6.4 Observaciones del uso#

Vale la pena registrar tres cosas de nuestro propio uso de este ciclo, con la salvedad de que son observaciones de un operador y no un estudio controlado.

Primero, la restricción que ata se movió. Antes de que las compuertas fueran explícitas, el paso lento para agregar una fuente era escribir y revisar el conector; después, fue la etapa de verificación esperando al sistema de la institución, es decir, el ritmo y la disponibilidad propios de la fuente. El esfuerzo de ingeniería por fuente cayó de días a horas; el tiempo transcurrido no cayó tanto, por razones que controla la fuente.

Segundo, las compuertas atraparon lo que la revisión no atrapó. Las tres fallas que la etapa de verificación atrapa con más frecuencia son una forma de no encontrado que difiere de la documentada (el sistema devuelve una lista vacía para un formato de identificador y un error para otro), un campo cuyos valores de muestra eran todos de un tipo pero cuyos valores en vivo no lo son, y un tamaño de página que la documentación declara y el sistema no respeta. Cada una de ellas había llegado, antes de las compuertas, a los consumidores.

Tercero, la compuerta de vocabulario importa más de lo que parece. Una institución tiene cosas que no quiere que se digan sobre sus sistemas, y un modelo que escribe documentación las dirá, de forma servicial y precisa, a menos que se le impida. Una lista fija de términos excluidos, aplicada a cada oración generada, es un instrumento tosco y es el correcto: es la única verificación que nunca ha tenido un falso negativo.

6.5 Costo#

Para una institución, el costo marginal de un registro bajo el arnés está dominado por dos cosas que ya paga: las personas que conocen los datos y el sistema que los sirve. La contribución del modelo está acotada por el número de campos (descripciones y mapeos) y es barata a los precios actuales; la del generador es fija; la del verificador es proporcional al número de pruebas, que es pequeño y no crece con el registro. El costo que no cae es institucional: decidir que un registro es público, que sus identificadores son estables, que su respuesta de no encontrado es definitiva y que se mantendrá disponible. El arnés hace esas decisiones visibles y verificables. No las toma.

7. Evaluación#

Evaluamos la afirmación de que la brecha de consumo es donde fallan los datos abiertos, y la idoneidad del perfil para cerrarla, con dos tipos de evidencia: una evaluación documental de 37 fuentes oficiales frente a criterios derivados del perfil, y mediciones en producción de la implementación de referencia a lo largo de 80 días.

7.1 Evaluación de fuentes#

Método. Seleccionamos las 37 fuentes detrás de los endpoints de la implementación de referencia en Colombia (20), Perú (8) y México (9): los registros que un consumidor en esos países realmente pide, y no una muestra de entradas de catálogo. Cada una se evaluó el 26 de agosto de 2026 frente a trece criterios (tabla 4) derivados de las siete propiedades de la brecha y de los ocho requisitos, usando solo documentación pública: el sitio de la institución, el portal nacional de datos abiertos, diccionarios de datos publicados y prensa acreditada. Cada celda es sí, parcial, no o desconocido, con una nota y una URL de evidencia; desconocido se usó siempre que la documentación no pudo establecer la respuesta, y nunca se infirió. Los evaluadores no sondearon ningún sistema más allá de leer documentación. La tabla completa con evidencia está en el apéndice C y en los archivos de datos del artículo. La confianza se registra por fuente; ocho fuentes están en confianza media o baja porque las páginas oficiales no pudieron obtenerse (errores de certificado o de acceso) y la evaluación se apoyó en extractos de búsqueda.

Tabla 4. Criterios de evaluación. C1 a C4 y C6 a C8 corresponden a R1 a R5; C5 a R6; C10 a R7; C9, C11 y C13 a R8; C12 a la capa de catálogo que el perfil compone.

Resultados. La figura 5 muestra cada fuente frente a cada criterio, y la figura 6 los totales por criterio.

Figura 5. Treinta y siete fuentes oficiales en Colombia, Perú y México frente a los trece criterios, a partir de documentación pública el 26 de agosto de 2026. Las fuentes están ordenadas por puntaje (sí = 1, parcial = 0.5). Las cuatro fuentes de arriba publican a través de una plataforma de catálogo nacional con API de consulta (SODA de Socrata en datos.gov.co) o bajo un estándar de dominio gobernado (OCDS); el bloque de abajo son formularios de consulta individual. La columna C10, superficies para agentes, está vacía. La matriz completa está en el apéndice C.

Figura 6. Totales por criterio en las 37 fuentes. Los feeds de cambios (C6) y las superficies para agentes (C10) son las capacidades más escasas; la frescura (C7) es mayormente parcial (una fecha a nivel de dataset y no de registro) o desconocida; los identificadores (C3) son mayormente parciales (un patrón de URL estable que la institución no documenta como tal).

Cuatro hallazgos destacan.

El acceso programático es una propiedad minoritaria, y donde existe es heredada. Seis de 37 fuentes (16%) documentan una API para el servicio evaluado y otras seis una parcial. De las seis, cuatro son datasets colombianos en datos.gov.co, cuya plataforma Socrata provee una API de consulta, filtros por campo, paginación y una columna de sistema :updated_at a cada dataset que aloja; una es el OECE de Perú, que publica la contratación bajo OCDS con una API de releases y archivos masivos anuales; una es la gaceta oficial de México, el DOF, cuyo sistema SIDOF documenta servicios JSON y un tablero de estado. Ninguna institución de la muestra diseñó y documentó una API por registro para su propio servicio de consulta; cada sí en C1 es una propiedad de una plataforma o de un estándar de dominio que la institución adoptó. Las cuatro fuentes con mayor puntaje (SECOP, Procuraduría, Supersociedades, RUES; 9.5 a 11.5 de 13) son exactamente las cuatro cuyos datos están en datos.gov.co, y la quinta (OECE, 9.5) es el publicador de OCDS. Esta es la evidencia individual más fuerte a favor del principio de composición del perfil: la forma de llevar un registro al Nivel 2 es conectarlo a algo que ya tiene las propiedades, no pedirle a la institución que las invente.

El cambio y la frescura son las capacidades más escasas. Una fuente (SECOP, vía el :updated_at de Socrata) ofrece una forma documentada de recuperar solo lo que cambió; diecinueve ofrecen algo parcial (una fecha de última modificación a nivel de dataset, o un campo de fecha en el registro por el que un consumidor puede filtrar con cuidado); quince no ofrecen nada. La frescura a nivel de registro (C7) está documentada por ocho, parcialmente por dieciocho, y es desconocida para diez, el conteo de desconocido más alto de todos los criterios, lo cual es en sí un hallazgo: la documentación no dice cuándo fue cierta la respuesta. Estos son los dos requisitos (R4, R5) que un consumidor menos puede sortear, y son los dos que una plataforma como Socrata provee gratis y que el formulario propio de una institución nunca provee.

Las superficies para agentes están ausentes. Ninguna fuente en tres países publica un llms.txt, un servidor MCP, una versión en markdown ni datos estructurados destinados al consumo por IA; las sondas devolvieron 404 o cascarones de aplicación. Los tres desconocido son hosts que no pudieron obtenerse. Esto coincide con el estado del campo en la sección 2 y es la columna vacía que el R7 del perfil está escrito para llenar. Es también la columna más barata de llenar: todo lo que hay en R7 se genera a partir del documento OpenAPI y del esquema, así que un publicador de Nivel 2 está a un paso de compilación del Nivel 3.

El fondo de la tabla es el formulario interactivo. Ocho fuentes puntúan uno o menos: las consultas de multas de vehículos y de seguros en Perú, los antecedentes policiales y los expedientes judiciales en Colombia, y el boletín de una fiscalía estatal en México. Cada una es una página donde una persona escribe un identificador y lee una respuesta, sin API, sin descarga masiva, sin esquema, sin marca de tiempo y, en varios casos, con un paso de verificación humana por sesión. Están entre los registros más consultados de sus países. Son también, desde el lado del consumidor, las fuentes con mayor latencia y tasa de falla en la sección 7.2. Los dos hechos son el mismo hecho.

Por país, Colombia puntúa más alto en promedio gracias a la plataforma de catálogo; México tiene el acceso más abierto (C9: nueve de nueve) pero las menos interfaces de consulta; Perú tiene el mejor publicador individual (OECE) y la cola más débil. Los términos de licencia (C13) son explícitos para nueve fuentes, parciales para catorce y desconocidos para diez; los tres portales nacionales asignan por defecto CC BY o CC BY-SA a nivel de dataset, que es lo que reflejan en su mayoría las celdas sí y parcial.

7.2 Mediciones en producción#

Método. La implementación de referencia registra, por cada solicitud autenticada, el endpoint, el estado HTTP, la duración de extremo a extremo, si la respuesta fue reutilizada dentro de su ventana de frescura, y un código de error cuando el estado es 400 o superior. No se registran cuerpos de solicitud ni de respuesta. Reportamos la ventana del 8 de junio al 26 de agosto de 2026 (80 días): 25,153 solicitudes, de las cuales 20,598 respondieron 200, 922 respondieron 202 (aceptadas para completarse de forma asíncrona), 1,833 respondieron 500 a 503 (la fuente falló o no estaba disponible), y 1,800 respondieron un error de cliente (entrada inválida, no autorizado o límite de tasa). Las duraciones son del lado del servidor, desde la recepción de la solicitud hasta la respuesta, así que excluyen la red del consumidor pero incluyen la de la fuente. Clasificamos los endpoints en los dos arquetipos de la sección 5.2: 72 endpoints de consulta al ritmo de la fuente con al menos un éxito, y los endpoints respaldados por el dataset de OECE (el dataset de la SCJN entró en producción el último día de la ventana y aporta dos solicitudes, que excluimos). Los sondeos de estado de trabajos asíncronos y los cinco endpoints de contenido se reportan por separado y no se usan en la comparación.

Tabla 5. Latencia por clase. Duraciones del lado del servidor, solo HTTP 200, 8 de junio al 26 de agosto de 2026. Las consultas al ritmo de la fuente produjeron además 922 aceptaciones asíncronas (202) y 1,225 fallas aguas arriba (500 a 503). El mismo contrato responde en 75 ms en la mediana desde un dataset mantenido bajo el perfil y en 2.6 s en la mediana, 27.9 s en el percentil 95, cuando la fuente responde a su propio ritmo.

Figura 7. Distribución de la latencia del lado del servidor para las consultas exitosas al ritmo de la fuente respondidas por la fuente (arriba; el último intervalo reúne todo lo que supera 30 s, 636 solicitudes, 4.3%) y para las consultas respondidas desde el dataset de OECE (abajo, en intervalos de 50 ms). Los ejes difieren en dos órdenes de magnitud.

Figura 8. Latencia mediana por endpoint al ritmo de la fuente, para los 52 endpoints con al menos diez solicitudes exitosas respondidas por la fuente. Treinta y dos endpoints responden en menos de cinco segundos en la mediana; veinte tardan más, y seis tardan más de veinte segundos. El consumidor de un contrato uniforme hereda esta dispersión de las fuentes.

El consumidor hereda la varianza de la fuente. En los 72 endpoints al ritmo de la fuente, la latencia mediana de la solicitud mediana fue 2.6 s y el percentil 95 fue 27.9 s; 636 solicitudes exitosas (4.3%) tardaron más de 30 s. Por endpoint (figura 8), las medianas van desde un cuarto de segundo (una red de sensores ambientales que publica una API de datos documentada) hasta 24 s (un servicio de certificados policiales que es un formulario interactivo), con seis de 52 endpoints por encima de 20 s en la mediana. Son los mismos registros que están en el fondo de la figura 5. Nada en el contrato puede ocultar esto; la finalización asíncrona (922 solicitudes) lo hace sobrevivible para el consumidor pero no lo hace rápido.

Un dataset bajo el perfil la elimina. Las 84 solicitudes exitosas respondidas desde el dataset de OECE tuvieron una mediana de 75 ms y un percentil 95 de 366 ms, treinta y cinco veces más rápido en la mediana que las consultas al ritmo de la fuente y setenta y cinco veces en la cola, sin fallas aguas arriba. Las respuestas reutilizadas dentro de su ventana de frescura (2,888) muestran el mismo orden de magnitud (100 ms de mediana). El punto no es que una base de datos sea más rápida que un formulario web; es que R4 y R5 del perfil son lo que hace legítimo a un dataset mantenido: un consumidor puede ver as_of, puede pedir updated_after, y por tanto no necesita ir a la fuente por cada pregunta. Un dataset sin esos dos campos es una copia desactualizada; con ellos es una publicación.

La disponibilidad es de la fuente. De 25,153 solicitudes, 1,833 (7.3%) fallaron con un estado 5xx; los principales códigos de error nombran la fuente (contratación, antecedentes disciplinarios, registro de empresas, expediente judicial, antecedentes fiscales) o un proveedor de contenido. Solo contra los éxitos al ritmo de la fuente, la tasa de falla aguas arriba fue 6.5%; contra el dataset, cero. Una solicitud de cada catorce es el costo, para un consumidor, de un registro que no tiene compromiso de disponibilidad (C11: un sí en 37), y es un costo que el consumidor paga en reintentos, tiempos de espera y, en el caso de los agentes, en conclusiones erróneas sacadas de una llamada fallida.

7.3 Amenazas a la validez#

La evaluación de fuentes es documental. Mide lo que las instituciones publican sobre sus servicios, que es el objeto correcto para un perfil cuyo Nivel 3 trata de la descubribilidad, pero puede subestimar capacidades que existen sin documentar y sobreestimar capacidades documentadas y rotas. Diez celdas son desconocido solo en el criterio de frescura. Ocho fuentes están en confianza media o baja porque los hosts oficiales rechazaron las obtenciones automatizadas, una ironía que anotamos. La rúbrica fue aplicada por un evaluador por país con un conjunto fijo de instrucciones; un segundo evaluador movería algunas celdas parcial en ambas direcciones, y publicamos la evidencia para que pueda hacerlo.

Las mediciones en producción provienen del tráfico de un solo operador, moldeado por los clientes de ese operador (predominantemente consumidores colombianos de servicios financieros, de ahí el peso de los endpoints colombianos) y por su propia ingeniería. La clase de dataset es pequeña (n = 84) y cubre una fuente; la comparación es entre arquetipos, no un experimento controlado, y la diferencia es tan grande que la muestra pequeña no amenaza la dirección del resultado. Las duraciones excluyen la red del consumidor. Las solicitudes limitadas por tasa (1,316) o malformadas se excluyen de la latencia pero se incluyen en los totales.

Por último, el autor opera la implementación de referencia y tiene interés en la adopción del perfil. Hemos intentado convertir eso en una fortaleza y no en una debilidad reportando lo que la implementación no satisface (sección 5.4) y publicando cada número de esta sección con los datos que lo respaldan.

8. Adopción y gobernanza#

Un perfil bajo el que nadie publica es un papel. Esta sección expone cómo podría adoptarse AGORA, a partir de los dos estándares de dominio que lograron adopción global y ajustada a las instituciones de la región donde corre la implementación de referencia.

Lecciones de GTFS y OCDS. GTFS empezó en 2005 como un intercambio de datos entre una agencia de transporte, TriMet en Portland, y un consumidor, Google Maps; era un puñado de archivos CSV que resolvían el enrutamiento, y se difundió porque los desarrolladores construyeron aplicaciones sobre él y las agencias querían estar en ellas. Su nombre cambió de Google a General Transit Feed Specification en 2010, a lo que sus custodios atribuyen haber reducido la resistencia de agencias y proveedores recelosos de que una sola empresa fuera dueña de su formato de datos. OCDS se lanzó en 2014 con un esquema JSON, un validador y una mesa de ayuda, custodiado por una organización sin ánimo de lucro financiada por filantropía, y se difundió a través de publicadores emblemáticos cuyos datos otros querían comparar. Ambos estándares se mantuvieron pequeños, ambos entregaron herramientas antes de buscar mandatos, y ambos pasaron a un custodio neutral antes de ser ampliamente adoptados. Ninguno empezó como una especificación en busca de una implementación. Tomamos estas como las tres condiciones para el perfil.

Etapa uno: implementación de referencia y validadores. La primera forma del perfil es software en funcionamiento, no un documento: la implementación de referencia, un validador de conformidad que cualquier publicador puede ejecutar contra cualquier interfaz, y una insignia que el validador emite por nivel. El validador es la especificación; publicarlo primero mantiene honesta la prosa. En esta etapa el perfil adopta en su salida todos los estándares de dominio relevantes, de modo que un publicador de OCDS o de ECLI vea el perfil como una forma de ser leído por agentes y no como un competidor, y publica las superficies para agentes (R7) para cada fuente que cubre, porque son las superficies sin competencia gubernamental hoy.

Etapa dos: una especificación abierta mínima. Una vez que el validador haya corrido contra una docena de publicadores y los requisitos hayan sobrevivido al contacto con ellos, el perfil se escribe como especificación: los ocho requisitos, el esquema del sobre, las definiciones de las pruebas y la tabla de composición, bajo CC0 o CC BY 4.0, con la implementación de referencia y el validador bajo una licencia OSI. La especificación se mantiene a la altura de la sección 4.2: nombra lo que un validador puede verificar y nada más. Las propuestas de agregar requisitos de calidad, completitud o semántica se redirigen, por política, a los estándares de dominio a los que pertenecen.

Etapa tres: custodia neutral. Un estándar controlado por una sola empresa no será adoptado por los gobiernos, y no debería serlo. La custodia del perfil pasa a un grupo de trabajo con publicadores, consumidores y miembros de la sociedad civil, alojado por un organismo en el que los gobiernos ya confían. En América Latina los candidatos existen: la Iniciativa Latinoamericana por los Datos Abiertos (ILDA), que co-opera la mesa de ayuda regional de OCDS; la Red GEALC, la red de gobierno digital de la Organización de los Estados Americanos; los programas de gobierno digital del Banco Interamericano de Desarrollo; y las oficinas nacionales de gobierno digital que ya operan los catálogos (MinTIC en Colombia, la Secretaría de Gobierno y Transformación Digital de la PCM en Perú, la ATDT en México). El nombre del perfil es neutral por diseño y no lleva la marca de ningún operador.

Primero la demanda. GTFS y OCDS fueron jalados por los consumidores, no empujados por mandatos. Los consumidores del perfil ya están presentes: prestamistas, aseguradoras, equipos de cumplimiento y KYC, periodistas, tecnólogos cívicos y, ahora, todo marco de agentes capaz de leer una lista de herramientas MCP. La estrategia de adopción es, por tanto, hacer visibles esos consumidores ante los publicadores, a través del uso de la implementación de referencia y de la insignia del validador, de modo que una institución vea una fila de aplicaciones esperando su registro y no una petición de trabajo.

Alineación con los mandatos. Donde existen mandatos, el perfil es la forma de cumplirlos. El reglamento europeo de Conjuntos de Datos de Alto Valor exige APIs y descarga masiva para registros de empresas y datos de movilidad; el Nivel 2 satisface ambas cláusulas y agrega lo que el reglamento deja sin especificar (identificadores, cambio, procedencia). La OPEN Government Data Act exige inventarios; la descripción DCAT del perfil es uno. En Colombia, Perú y México las leyes de transparencia y los decretos de datos abiertos exigen publicación y catálogos; el perfil les da a los catálogos algo a lo que apuntar. Los lineamientos de datos abiertos de 2025 de México para la administración pública federal son el instrumento más reciente de la región y el lugar natural para que aparezca un requisito de Nivel 1.

Qué cambiaría esta estrategia. Tres desarrollos lo harían. Si un gobierno o la Unión Europea publica un estándar oficial de acceso entre registros o para agentes, el trabajo del perfil se convierte en conformidad y herramientas para ese estándar en lugar de una especificación paralela. Si DCAT-AP o DCAT-US agregan semántica de consulta y de cambio a nivel de registro, el perfil se convierte en una extensión de DCAT-AP. Si la cobertura de OCDS, BODS o Akoma Ntoso en la región se profundiza hasta el punto en que la mayoría de los registros se publique bajo un estándar de dominio, el valor del perfil se concentra en R4, R5 y R7, las partes que esos estándares no cubren, y debería reducirse en consecuencia.

9. Limitaciones y trabajo futuro#

El perfil no ha sido probado fuera de la implementación de su autor. Cada requisito ha sido ejercitado por un operador contra varias decenas de fuentes en tres países. No ha sido implementado por un gobierno, y el arnés no se ha ejecutado dentro de una institución sobre sus propios sistemas. Esos dos son los siguientes pasos obvios, y el primer piloto cambiará el perfil.

La resolución de entidades se declara, no se resuelve. R2 pide a los publicadores declarar espacios de nombres de identificadores para que los consumidores puedan relacionar registros entre registros sin coincidencia de cadenas. No resuelve entidades: el perfil se detiene deliberadamente en "el registro X llama a esto a" y deja "a en X es b en Y" a un servicio de resolución, porque una fusión errónea es peor que ninguna fusión y la propiedad no es verificable desde afuera. Un perfil para servicios de resolución, compuesto sobre LEI y org-id.guide, es trabajo futuro.

Datos personales. Muchos de los registros de la evaluación se refieren a personas: antecedentes disciplinarios, certificados penales, estado de vigencia, afiliaciones. El requisito de acceso masivo del perfil (R6) y el feed de cambios (R4) no son apropiados para todos esos registros, y un publicador conforme de registros personales puede legítimamente detenerse en la búsqueda por identificador con límites de tasa y declaraciones de propósito. El perfil debería adquirir un anexo de datos personales que diga qué requisitos relaja una base legal, escrito con las autoridades de protección de datos y no para ellas.

La evaluación es una instantánea hecha por tres evaluadores. Su valor está en el rastro de evidencia y en la rúbrica, que publicamos para que pueda volver a ejecutarse, disputarse y extenderse. Una evaluación mantenida por la comunidad con un segundo calificador por celda sería un mejor instrumento.

La evidencia de producción es de un solo operador. La clase de dataset es pequeña y la mezcla de tráfico es la de los clientes de ese operador. Los números de un segundo implementador serían lo más útil que un lector podría aportar.

Los agentes como evaluadores. La prueba más fuerte del Nivel 3 es si un agente, dada una pregunta y las superficies de R7, la responde correctamente y cita el registro. Lo hemos observado de forma cualitativa y no lo hemos medido. Un banco de preguntas sobre registros con respuestas de referencia, ejecutado contra publicadores de cada nivel, es la evaluación que este artículo debería haber tenido y que el siguiente tendrá.

10. Conclusión#

El movimiento de datos abiertos construyó las capas que se propuso construir. Los gobiernos publican; los catálogos describen; los estándares de dominio codifican. Lo que no construyó, porque ninguna capa era dueña de ello, es el contrato que un consumidor necesita para usar un registro: resolverlo, consultarlo, seguirlo, confiar en su marca de tiempo, y hacerlo desde un programa. Esa brecha era tolerable mientras el consumidor era una persona con un navegador y tiempo. No es tolerable para un agente, y los agentes son hoy una parte medible del tráfico que reciben los datos públicos.

AGORA es una respuesta pequeña a una brecha grande. Ocho requisitos, tres niveles, un sobre y un validador, compuestos sobre los estándares que ya existen y no junto a ellos. La implementación de referencia muestra que el contrato puede sostenerse de manera uniforme sobre 46 fuentes que no comparten nada más, y las mediciones en producción muestran lo que el contrato no puede ocultar: un registro respondido al ritmo de un formulario web es treinta y cinco veces más lento en la mediana y setenta y cinco veces más lento en la cola que el mismo registro publicado bajo el perfil, y falla una vez de cada catorce. La evaluación de 37 fuentes muestra que las propiedades que el perfil pide son escasas, que donde existen fueron heredadas de una plataforma o de un estándar de dominio, y que las superficies para agentes faltan en todas partes.

El arnés es la parte que esperamos que más importe en la práctica. El costo de escribir una interfaz tipada, documentada y visible para agentes sobre un registro se ha desplomado; el costo de equivocarse no. Dejar que un modelo proponga y que un conjunto fijo de compuertas disponga es cómo una institución puede tener lo primero sin pagar lo segundo. Las compuertas son las pruebas del perfil. Ese es todo el diseño: una especificación tan pequeña que cabe en un validador, un validador tan estricto que sirve de compuerta, y un ciclo en el que la máquina que escribe nunca es la máquina que decide.

Apéndice A. Lista de verificación de conformidad#

Apéndice B. Esquema del sobre#

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "title": "AGORA response envelope",
  "type": "object",
  "required": ["found", "source", "as_of", "license"],
  "properties": {
    "found": { "type": "boolean", "description": "Whether a record exists for the request. false is a definitive answer, not an error." },
    "source": {
      "type": "object", "required": ["id", "name"],
      "properties": {
        "id": { "type": "string", "description": "Publisher identifier, stable across records." },
        "name": { "type": "string" },
        "org_id": { "type": "string", "description": "org-id.guide identifier of the institution, when one exists." }
      }
    },
    "as_of": { "type": "string", "format": "date-time", "description": "Instant the underlying data was last synchronised, or the instant of retrieval for a live lookup." },
    "record_version": { "type": "string", "pattern": "^sha256:[0-9a-f]{64}$", "description": "Hash of the JCS-canonicalised data member. Required when found is true." },
    "license": { "type": "string", "format": "uri" },
    "data": {
      "type": "object", "description": "The record, conforming to its declared schema. Absent when found is false.",
      "properties": {
        "_updated_at": { "type": "string", "format": "date-time", "description": "Instant the publisher last changed this record. Required at Level 2." },
        "_deleted_at": { "type": "string", "format": "date-time", "description": "Present on tombstones in the change feed." }
      }
    }
  },
  "if": { "properties": { "found": { "const": true } } },
  "then": { "required": ["record_version", "data"] }
}

Apéndice C. Matriz de evaluación de fuentes#

Y = sí, P = parcial, N = no, ? = desconocido. El puntaje cuenta sí como 1 y parcial como 0.5. Las notas por celda y las URLs de evidencia están en los archivos de datos del artículo; la fecha de evaluación es el 26 de agosto de 2026.

Los tres catálogos nacionales se caracterizaron junto con las fuentes. datos.gov.co es una instancia de Socrata (Data & Insights de Tyler Technologies) que publica un data.json en DCAT-US, una API de consulta por dataset con filtros por campo, paginación y una columna de sistema :updated_at, y CC BY-SA 4.0 en cada dataset muestreado; su API de descubrimiento reportó 8,391 datasets. datosabiertos.gob.pe es una instancia de DKAN (Drupal) con una API de catálogo compatible con CKAN, gobernada por la Secretaría de Gobierno y Transformación Digital de la PCM bajo el DS 016-2017-PCM, el DL 1412 y normas posteriores, sin licencia por defecto a nivel de portal; su página principal reportó 4,668 datasets de 390 entidades. datos.gob.mx es una instancia de CKAN 2.11 gobernada por la Agencia de Transformación Digital y Telecomunicaciones bajo los lineamientos de septiembre de 2025, con una API de acciones de CKAN funcional pero no documentada y CC BY 4.0 en los datasets; su API de CKAN reportó 1,730 datasets frente a una cifra de 7,420 en la página principal.

Referencias#

• Anthropic (2025). Donating the Model Context Protocol and establishing the Agentic AI Foundation. 9 December 2025. https://www.anthropic.com/news/donating-the-model-context-protocol-and-establishing-of-the-agentic-ai-foundation
• Attard, J., Orlandi, F., Scerri, S. and Auer, S. (2015). A systematic review of open government data initiatives. Government Information Quarterly 32(4), 399-418. https://doi.org/10.1016/j.giq.2015.07.006
• Australian Government (2024). API Design Standard. https://api.gov.au/
• Berners-Lee, T. (2006, 2010). Linked Data. W3C Design Issues; five-star scheme added 2010. https://www.w3.org/DesignIssues/LinkedData.html
• Cloudflare (2025). 2025 Cloudflare Radar Year in Review. https://blog.cloudflare.com/radar-2025-year-in-review/
• Congreso de Colombia (2014). Ley 1712 de 2014, Ley de Transparencia y del Derecho de Acceso a la Información Pública Nacional. Diario Oficial 49.084.
• Council of the European Union (2011). Council conclusions inviting the introduction of the European Case Law Identifier (ECLI). OJ C 127, 29 April 2011.
• Croma (2026). Croma API documentation. https://docs.usecroma.com
• European Union (2019). Directive (EU) 2019/1024 on open data and the re-use of public sector information. OJ L 172.
• European Union (2023). Commission Implementing Regulation (EU) 2023/138 laying down a list of specific high-value datasets. OJ L 19.
• European Union (2024). Regulation (EU) 2024/903 laying down measures for a high level of public sector interoperability (Interoperable Europe Act). OJ L, 2024/903.
• Frictionless Data (2024). Data Package (v2) is released. https://datapackage.org/blog/2024-06-26-v2-release/
• GLEIF (2026). ISO 17442: the LEI code structure. https://www.gleif.org/en/about-lei/iso-17442-the-lei-code-structure
• Google (2025). Introducing the Data Commons Model Context Protocol (MCP) Server. Google Developers Blog, 24 September 2025. https://developers.googleblog.com/en/datacommonsmcp/
• Government Digital Service (2024). API design guidance. https://www.gov.uk/government/collections/api-design-guidance
• GSA (2026). DCAT-US Schema v3.0 and v1.1. resources.data.gov. https://resources.data.gov/resources/dcat-us3/
• GTFS (2026). General Transit Feed Specification. https://gtfs.org/
• Howard, J. (2024). The /llms.txt file. 3 September 2024. https://llmstxt.org/
• ISO (2025). ISO 19168-1:2025 Geographic information. Geospatial API for features. Part 1: Core.
• Janssen, M., Charalabidis, Y. and Zuiderwijk, A. (2012). Benefits, adoption barriers and myths of open data and open government. Information Systems Management 29(4), 258-268. https://doi.org/10.1080/10580530.2012.716740
• MCP (2026). Model Context Protocol specification, version 2026-07-28. https://modelcontextprotocol.io/specification/2026-07-28/changelog
• México (2015). Decreto por el que se establece la regulación en materia de Datos Abiertos. DOF, 20 February 2015.
• México (2025). Ley General de Transparencia y Acceso a la Información Pública. DOF, 20 March 2025; Lineamientos en materia de Datos Abiertos de la Administración Pública Federal. DOF, 11 September 2025.
• MinTIC (2026). Lenguaje Común de Intercambio de Información. https://lenguaje.mintic.gov.co/
• Nottingham, M. (2017). RFC 8288: Web Linking. IETF.
• Nottingham, M., Wilde, E. and Dalal, S. (2023). RFC 9457: Problem Details for HTTP APIs. IETF.
• Noy, N. (2018). Making it easier to discover datasets. Google, 5 September 2018.
• OASIS (2018). Akoma Ntoso Version 1.0, Part 1: XML Vocabulary. OASIS Standard, 29 August 2018.
• OECD (2023). 2023 OECD Open, Useful and Re-usable data (OURdata) Index: results and key findings. https://doi.org/10.1787/a37f51c3-en
• OGC (2022). OGC API - Features - Part 1: Core, version 1.0.1. OGC 17-069r4.
• Open Contracting Partnership (2026). The Open Contracting Data Standard. https://standard.open-contracting.org
• Open Data Charter (2015). Principles. https://opendatacharter.org/principles/
• Open Ownership (2025). Pausing development of the Beneficial Ownership Data Standard. 18 November 2025.
• OpenAPI Initiative (2021). OpenAPI Specification v3.1.0.
• Perú (2017). Decreto Supremo N° 016-2017-PCM, Estrategia Nacional de Datos Abiertos Gubernamentales 2017-2021. El Peruano, 12 February 2017.
• Perú (2018). Decreto Legislativo N° 1412, Ley de Gobierno Digital. El Peruano, 13 September 2018.
• Rundgren, A., Jordan, B. and Erdtman, S. (2020). RFC 8785: JSON Canonicalization Scheme (JCS). IETF.
• Safarov, I., Meijer, A. and Grimmelikhuijsen, S. (2017). Utilization of open government data: a systematic literature review of types, conditions, effects and users. Information Polity 22(1), 1-24. https://doi.org/10.3233/IP-160012
• Sebastopol (2007). The 8 Principles of Open Government Data. https://opengovdata.org/
• SEMIC (2025). DCAT-AP 3.0.1. SEMIC Recommendation, 27 October 2025. https://semiceu.github.io/DCAT-AP/releases/3.0.1/
• Smith, K. (2025). RFC 9727: api-catalog: a well-known URI and link relation to help discovery of APIs. IETF.
• StateScoop (2026). Maryland is the only state with an llms.txt file. 12 January 2026. https://statescoop.com/llmstxt-government-websites-ai/
• Sunlight Foundation (2010). Ten Principles for Opening Up Government Information.
• Technical.ly (2026). Maryland uses llms.txt to guide AI chatbots. https://technical.ly/civics/maryland-uses-llms-txt-to-guide-ai-chatbots/
• Treasury Board of Canada Secretariat (2024). Government of Canada Standards on APIs.
• United States (2019). Foundations for Evidence-Based Policymaking Act of 2018, Title II: OPEN Government Data Act. Public Law 115-435.
• W3C (2013). PROV-O: The PROV Ontology. W3C Recommendation, 30 April 2013.
• W3C (2024). Data Catalog Vocabulary (DCAT), Version 3. W3C Recommendation, 22 August 2024. https://www.w3.org/TR/vocab-dcat-3/
• Wilkinson, M. D. et al. (2016). The FAIR Guiding Principles for scientific data management and stewardship. Scientific Data 3, 160018. https://doi.org/10.1038/sdata.2016.18
• Zuiderwijk, A. and Janssen, M. (2014). Open data policies, their implementation and impact: a framework for comparison. Government Information Quarterly 31(1), 17-29. https://doi.org/10.1016/j.giq.2013.04.003