Open Knowledge Format: Google propone un lenguaje común para el conocimiento de los agentes de IA

El 12 de junio de 2026, Google Cloud publicó la versión 0.1 del Open Knowledge Format (OKF), una especificación abierta para representar el conocimiento que rodea a los datos y sistemas de una organización. La propuesta no introduce una nueva base de datos, un servicio obligatorio ni un kit de desarrollo: utiliza directorios, archivos Markdown y metadatos YAML.

Esa sencillez es el centro de la idea. Mientras los modelos de IA mejoran con rapidez, los agentes que los utilizan siguen tropezando con un problema menos llamativo, pero decisivo: no conocen el significado particular de los datos, métricas, procesos y reglas de cada organización. OKF intenta convertir ese contexto disperso en documentos portátiles que puedan leer tanto una persona como una máquina.

La iniciativa formaliza el patrón conocido como LLM-wiki: una biblioteca viva que los agentes consultan y actualizan, mientras los equipos la revisan y administran como código. Sin embargo, OKF no debe confundirse con un producto terminado ni con un estándar ampliamente adoptado. La propia especificación se presenta como un borrador en versión 0.1 y Google la describe como un punto de partida.

El problema no es la inteligencia, sino el contexto

Un agente puede escribir código, resumir un informe o consultar una base de datos. Pero esas capacidades sirven de poco si no sabe qué significa «usuario activo» para una empresa, cuál tabla contiene los pedidos válidos, cómo se calcula un indicador o qué procedimiento debe seguir ante una alerta.

Ese conocimiento suele estar fragmentado entre catálogos de metadatos, wikis, unidades compartidas, comentarios en el código, cuadernos y conversaciones internas. Parte de él ni siquiera está documentado: permanece en la memoria de unas pocas personas. Cuando un agente necesita responder una pregunta, debe reconstruir el contexto desde sistemas incompatibles y repetir el trabajo que otros agentes ya hicieron.

OKF propone separar el conocimiento de la herramienta que lo creó. Una plataforma puede producir los documentos y otra puede consumirlos; un ser humano puede escribirlos y un agente utilizarlos; un agente puede generarlos y otro analizarlos. El contrato común es el formato, no la infraestructura.

Esta separación persigue tres objetivos: reducir la dependencia de proveedores, conservar el conocimiento en control de versiones y evitar que cada equipo invente desde cero su propia estructura para alimentar agentes.

Cómo funciona un paquete OKF

Un paquete de conocimiento es un árbol de directorios compuesto por archivos Markdown. Cada documento representa un solo concepto: una tabla, un conjunto de datos, una métrica, una interfaz de programación, un procedimiento operativo o una idea abstracta. La ruta del archivo, sin la extensión .md, funciona como identificador del concepto.

Cada documento comienza con un bloque de metadatos YAML. La versión 0.1 exige únicamente el campo type; los demás son recomendados u opcionales:

script.js

---
type: Metrica
title: Usuarios activos semanales
description: Personas que iniciaron sesión durante los últimos siete días.
resource: https://ejemplo.com/catalogo/usuarios-activos
tags: [producto, actividad]
timestamp: 2026-07-21T14:00:00Z
---

Después del bloque aparece el cuerpo en Markdown. Allí se pueden documentar definiciones, esquemas, ejemplos, consultas, relaciones y fuentes. La especificación recomienda aprovechar elementos estructurados como encabezados, listas, tablas y bloques de código porque ayudan a la lectura humana y a la recuperación automática.

Los conceptos se conectan mediante enlaces Markdown normales. Así, una métrica puede enlazar las tablas que utiliza; una tabla puede apuntar a su conjunto de datos; y un procedimiento puede relacionarse con el servicio al que responde. El directorio aporta una jerarquía y los enlaces forman un grafo de relaciones.

OKF también reserva dos nombres opcionales. index.md permite enumerar el contenido de un directorio para que una persona o un agente avance por niveles sin cargar todo el paquete. log.md registra cambios de forma cronológica. Un paquete puede distribuirse como repositorio Git —la opción recomendada—, archivo comprimido o subdirectorio dentro de otro proyecto.

La interoperabilidad nace de exigir muy poco

La decisión más importante de OKF es también la más discutible: imponer una estructura mínima. No existe un registro central de tipos, una taxonomía obligatoria ni una lista fija de secciones para el cuerpo. Los productores pueden añadir campos propios, y los consumidores deben tolerar tipos desconocidos, metadatos adicionales, índices ausentes e incluso enlaces rotos.

Esa permisividad reduce la barrera de adopción. Un equipo puede empezar con documentos que ya tiene, agregar type y organizar gradualmente sus conceptos. Las herramientas no necesitan implementar un modelo de datos complejo para reconocer un paquete válido.

Pero la flexibilidad traslada parte del problema a otro nivel. Dos organizaciones pueden producir documentos técnicamente conformes y, aun así, utilizar nombres de tipos, niveles de detalle o criterios de calidad muy diferentes. OKF garantiza una envoltura común; no garantiza que el conocimiento sea correcto, completo o semánticamente equivalente.

El formato tampoco reemplaza esquemas especializados como OpenAPI, Avro o Protobuf. Puede describirlos y enlazarlos, pero no intenta asumir sus funciones. Esta distinción evita convertir una propuesta pequeña en una solución universal que termine siendo difícil de adoptar.

Lo que Google publicó junto con la especificación

Google acompañó OKF v0.1 con implementaciones de referencia para mostrar ambos extremos del intercambio. La primera es un agente de enriquecimiento que recorre un conjunto de datos de BigQuery, crea documentos para tablas y vistas, y después consulta documentación autorizada para añadir citas, esquemas y rutas de unión.

La segunda es un visualizador que transforma cualquier paquete OKF en un archivo HTML interactivo. Muestra los conceptos como un grafo, permite buscar y filtrar por tipo, y presenta los metadatos y el contenido Markdown. El archivo funciona sin servidor y procesa el paquete localmente.

El repositorio incluye además tres paquetes de ejemplo elaborados a partir de datos públicos: comercio electrónico de Google Analytics 4, Stack Overflow y Bitcoin. Son pruebas de concepto, no componentes obligatorios. Un productor podría ser un guion propio o una exportación de un catálogo; un consumidor podría ser un buscador, una interfaz documental o un agente que cargue los archivos directamente en su contexto.

Google también adaptó su Knowledge Catalog para ingerir OKF y servirlo a sus agentes. La integración muestra un camino comercial alrededor del formato, pero no cambia su naturaleza abierta: leer o producir los archivos no requiere una cuenta de Google Cloud.

Qué resuelve y qué deja pendiente

OKF resuelve bien la portabilidad básica. Los archivos son legibles sin herramientas especiales, se pueden revisar mediante solicitudes de cambio, conservan historial en Git y sobreviven al traslado entre sistemas. También facilitan una colaboración verificable: una modificación del significado de una métrica puede revisarse igual que un cambio en el código.

No obstante, la especificación no define mecanismos de permisos, sincronización, resolución de conflictos, validación de hechos ni control de información sensible. Tampoco establece cómo debe decidir un agente qué documento es más confiable cuando encuentra versiones contradictorias. Esos asuntos quedan en manos de los productores, consumidores y sistemas que rodean el paquete.

También conviene evitar una lectura equivocada: OKF no fue anunciado como una técnica de posicionamiento en buscadores ni como un sustituto de schema.org o de llms.txt. Su objetivo inicial es representar conocimiento organizacional para agentes y humanos. Publicar un directorio OKF en un sitio web no implica, por sí solo, mayor visibilidad ni una mejora en las clasificaciones de Google.

El reto principal será social, no técnico. Para que un paquete sea útil, alguien debe mantener definiciones, referencias y relaciones actualizadas. Los agentes pueden encargarse de buena parte del trabajo mecánico, pero la revisión humana sigue siendo necesaria cuando el conocimiento afecta decisiones reales.

OKF no es otro Jira ni otro Confluence

La comparación con Atlassian ayuda a precisar qué es OKF. Jira administra trabajo: tareas, responsables, estados, fechas y dependencias. Confluence permite redactar documentación de manera colaborativa. OKF no ofrece esas funciones porque no es una aplicación, sino un formato de intercambio.

Jira podría contener la tarea «Redactar el análisis sobre OKF», con responsable y estado. Confluence alojaría el manual editorial. El paquete OKF representaría de forma portable los conceptos que un agente debe comprender: el proyecto, sus reglas, participantes y flujo de publicación.

En resumen, Jira registra qué se está haciendo; Confluence conserva lo que el equipo documenta; OKF empaqueta el contexto seleccionado para comprender y reutilizar. Los tres identifican y relacionan información, pero Jira y Confluence la guardan bajo el modelo de una plataforma. Para consumirla desde otro sistema se requiere una API, un conector o una exportación. Un concepto OKF es un archivo que puede copiarse, versionarse y leerse sin la herramienta que lo produjo.

OKF no reemplaza flujos, permisos, comentarios, notificaciones, tableros, búsqueda ni edición colaborativa. Confundirlo con un sustituto de Jira o Confluence sería confundir el formato con las aplicaciones que pueden producirlo o consumirlo.

Una empresa con Jira y Confluence puede no necesitar OKF

Si la información está bien estructurada en Jira y Confluence, y los agentes acceden mediante conectores confiables, añadir OKF podría ser innecesario. Consultar las fuentes originales evita mantener otra copia. Una política podría cambiar en Confluence mientras su exportación permanece intacta, dejando al agente con un contexto limpio, pero desactualizado.

OKF resulta más valioso cuando aparecen requisitos que Jira y Confluence no resuelven por sí solos:

Varios agentes o modelos de proveedores distintos necesitan compartir el mismo contexto.
El conocimiento está fragmentado entre Atlassian, repositorios, bases de datos y otras plataformas.
La organización quiere una versión en Git y legible sin depender de los servicios originales.
Es necesario transferir conocimiento a otro equipo, empresa o herramienta sin imponerle la plataforma de origen.
Se busca reducir la dependencia de un proveedor o facilitar una futura migración.
Los agentes necesitan un conjunto pequeño y cuidadosamente seleccionado, en vez de consultar miles de tareas y páginas sin filtrar.

En esos casos, Jira y Confluence pueden seguir como fuentes operativas, mientras un proceso genera OKF con el contenido autorizado. Ese proceso debe registrar procedencia y fecha para no confundir una copia antigua con la fuente vigente.

La regla práctica es sencilla: Jira sirve para asignar y seguir trabajo; Confluence, para crear documentación colaborativa; y OKF, para intercambiar contexto estructurado entre agentes y sistemas. No son alternativas excluyentes.

Herramientas que ya resuelven partes del problema

OKF no inventa los catálogos ni la documentación como código. Backstage Software Catalog usa archivos YAML junto al código para catalogar servicios, responsables y relaciones; con TechDocs añade documentación en Markdown. Es posiblemente el antecedente más cercano para proyectos de software, aunque Backstage es una plataforma con interfaz, modelo de entidades y complementos.

DataHub y OpenMetadata construyen grafos de metadatos para datos, tableros, modelos, propietarios, linaje y glosarios. Incorporan búsqueda, ingestión, calidad y gobierno, pero son sistemas más complejos y especializados. Google Cloud Knowledge Catalog puede ingerir OKF y servirlo a agentes, mostrando claramente la separación: Knowledge Catalog es el producto administrado; OKF es el formato intercambiable. Las ontologías y agentes de Microsoft Fabric persiguen un objetivo semejante dentro del ecosistema de Microsoft.

Estándares como RDF, OWL y DCAT permiten describir entidades y relaciones con mayor precisión, pero requieren vocabularios y herramientas especializados. OKF sacrifica formalidad para reducir la barrera de entrada a Markdown, YAML, directorios y enlaces.

Su novedad consiste en proponer una envoltura mínima orientada a agentes que pueda generarse desde Jira, Confluence, Backstage, un catálogo o un repositorio, y consumirse sin adoptar la plataforma original. Falta comprobar si una estructura tan permisiva logrará verdadera interoperabilidad.

Por qué OKF merece atención

OKF es relevante porque reconoce que el contexto se está convirtiendo en infraestructura. El rendimiento de un agente no depende solamente del modelo que lo impulsa, sino de la calidad del conocimiento que puede consultar y de la claridad con la que ese conocimiento representa la realidad de una organización.

Su propuesta recuerda una lección conocida del desarrollo de software: los formatos simples y abiertos suelen durar más que las plataformas que los rodean. Markdown, YAML, enlaces y directorios no son tecnologías nuevas, pero su combinación deliberada puede ofrecer un punto de encuentro para catálogos, wikis y agentes que hoy operan como islas.

La versión 0.1 todavía debe demostrar adopción fuera del ecosistema de Google, compatibilidad entre productores independientes y capacidad para evolucionar sin perder la sencillez que la hace atractiva. Si ese ecosistema aparece, OKF podría convertirse en una capa común para intercambiar conocimiento entre agentes. Si no aparece, seguirá siendo una convención útil y fácil de implementar dentro de proyectos individuales.

Para los equipos interesados, la mejor forma de evaluarlo no es migrar toda su documentación, sino crear un paquete pequeño: escoger un dominio concreto, representar unos cuantos conceptos, enlazarlos, revisar el resultado con personas expertas y probarlo con más de un agente. La verdadera medida de éxito no será cuántos archivos produzca el sistema, sino si reduce respuestas incorrectas, búsquedas repetidas y conocimiento encerrado en herramientas propietarias.