El 12 de junio de 2026, Google Cloud publicó la versión 0.1 del Open Knowledge Format (OKF): un estándar abierto, independiente de cualquier proveedor, para estructurar el conocimiento que consumen los agentes de inteligencia artificial. La publicación incluye implementaciones de referencia, bundles de ejemplo sobre conjuntos de datos públicos y una especificación que, según sus autores, cabe en una sola página.

Lo que llama la atención del anuncio no es la tecnología, que es deliberadamente simple. Es el diagnóstico que lo precede. Sam McVeety y Amir Hormati, los autores de la especificación, dedican la primera mitad de su entrada en el blog de Google Cloud a explicar por qué el problema del conocimiento en las organizaciones no puede resolverse con más capacidad de modelo ni con mejores sistemas de recuperación. Su tesis es que lo que falta no es otro servicio. Lo que falta es un formato.

Ese diagnóstico merece atención mucho más allá de los equipos de ingeniería de datos de Google Cloud. Porque el problema que OKF viene a formalizar no es un problema de infraestructura técnica. Es el problema de cualquier organización cuya propuesta de valor depende de que un agente de IA pueda representarla con precisión. Una universidad, una institución pública, una firma de servicios profesionales: cualquier organización que produce conocimiento destinado, en última instancia, a ser consumido por una máquina.

Qué es exactamente el Open Knowledge Format

OKF es, en su diseño fundamental, un directorio de archivos markdown con metadatos YAML en la cabecera de cada documento. No es una base de datos. No es una plataforma. No es una API propietaria. Es un formato: una convención para organizar, nombrar y etiquetar archivos de texto de forma que el conocimiento que contienen pueda moverse entre sistemas sin integraciones ad hoc.

La apuesta de diseño está precisamente en lo que OKF no requiere. Sin SDK. Sin cuenta en ningún proveedor. Sin plataforma de despliegue específica ni runtime propietario. Un bundle OKF es, en su forma más básica, una carpeta de archivos de texto que cualquier editor de texto puede abrir, cualquier buscador puede indexar, cualquier agente puede leer y cualquier desarrollador puede auditar sin herramientas especiales.

McVeety y Hormati lo formulan con precisión: “Si has usado Obsidian, Notion, Hugo o cualquiera de los patrones de wiki para LLMs que han emergido durante el último año, la forma te resultará familiar. OKF formaliza el pequeño conjunto de convenciones necesarias para hacer esos patrones interoperables.” La interoperabilidad es el objetivo. No la tecnología.

El problema que Google viene a diagnosticar

Para entender qué viene a resolver OKF, conviene entender el problema que describe —que no es principalmente técnico.

En la mayoría de las organizaciones, el conocimiento que un agente necesita para responder preguntas con precisión está distribuido entre sistemas que no se hablan entre sí. El esquema de una tabla vive en el catálogo de metadatos del equipo, accesible mediante la API de ese proveedor. El significado de una métrica de negocio —qué cuenta exactamente, qué excluye, desde qué fecha se calcula así y no de otra manera— vive en la cabeza de quien la definió hace tres años, o en un documento de Confluence que nadie ha actualizado desde entonces. La restricción que explica por qué dos tablas no se unen directamente está en un hilo de Slack de un equipo que ya se ha reorganizado. El procedimiento que describe cómo responder ante una anomalía está en un Google Doc cuyos permisos de acceso caducaron el trimestre pasado.

Cuando un agente necesita responder “¿cómo calculamos la tasa de retención de nuestros usuarios activos semanales?”, tiene que ensamblar esa respuesta desde superficies fragmentadas, mutuamente incompatibles, sin garantía de que lo que encuentra es la versión actual de la verdad. El agente infiere. Y la inferencia, operando sobre conocimiento implícito o fragmentado, produce lo que los ingenieros llaman “sinsentido plausible”: respuestas que suenan coherentes y son estructuralmente incorrectas.

El diagnóstico de Google en la especificación OKF es el mismo que Andrej Karpathy, el investigador de IA que inspiró parte del diseño, ha articulado desde la perspectiva de los wikis: los LLMs no se aburren, no olvidan actualizar una referencia cruzada y pueden tocar quince archivos en un solo pase. El mantenimiento que lleva a los humanos a abandonar los wikis personales es exactamente lo que los LLMs hacen bien. Lo que los LLMs no pueden hacer —y nadie puede hacer por ellos— es razonar correctamente sobre conocimiento que no ha sido declarado. La capacidad del modelo no cambia el problema de fondo cuando el conocimiento en sí no está ahí.

Más parámetros, mejor recuperación semántica, ventanas de contexto más grandes: todo eso ayuda, pero ninguna de esas mejoras cambia el contenido que los modelos leen. Si los hechos son implícitos, inconsistentes o nunca se declararon, el sistema sigue teniendo que inferir demasiado, y es en la inferencia donde el razonamiento se deteriora.

La anatomía de un bundle OKF

Para que el diagnóstico tenga consecuencias prácticas, conviene examinar el diseño concreto de la especificación.

Un bundle OKF bien construido tiene tres capas. La primera es el directorio de conceptos: una jerarquía de carpetas que refleja los dominios de conocimiento de la organización, con un archivo por concepto y archivos index.md opcionales que facilitan la navegación jerárquica para agentes que exploran el bundle de forma incremental. La segunda capa son los enlaces entre conceptos: referencias markdown estándar que conectan tablas con métricas, métricas con procedimientos, procedimientos con el contexto de negocio que los justifica, APIs con los datos que exponen. La tercera capa son los archivos log.md opcionales que registran un historial cronológico de cambios en un concepto específico, convirtiendo el bundle en un registro vivo en lugar de un snapshot estático.

La cabecera YAML de cada documento lleva cinco campos: type, title, description, resource y timestamp. El campo type es el único que la especificación v0.1 considera obligatorio, y es deliberadamente abierto: OKF no prescribe qué tipos existen. Cada organización define su propio vocabulario de tipos según sus necesidades. Lo que el estándar garantiza es que ese vocabulario es consultable de forma uniforme por cualquier consumidor, independientemente de quién haya producido el bundle.

Este minimalismo tiene una justificación de principio que los autores articulan con claridad. El valor de un formato de conocimiento no viene de la riqueza de su especificación, sino del número de partes que lo adoptan. Un estándar demasiado opinionado sobre el modelo de contenido convierte la adopción en una negociación sobre el modelo, y esa negociación raramente concluye. OKF apuesta por opinar lo mínimo necesario para que la interoperabilidad sea posible, dejando el resto a la discreción de cada productor y consumidor.

Google publicó tres implementaciones de referencia junto con la especificación: un agente de enriquecimiento que recorre un dataset de BigQuery y genera un bundle OKF para cada tabla y vista, un visualizador HTML estático que convierte cualquier bundle en un grafo navegable sin backend, y tres bundles de ejemplo sobre datasets públicos —ecommerce GA4, Stack Overflow y Bitcoin— producidos por el agente de referencia y disponibles en el repositorio. Son pruebas de concepto, no el producto. El ecosistema de productores y consumidores que OKF espera generar se extiende muy por encima de lo que Google ha implementado.

Por qué un formato y no otro servicio

La decisión de publicar OKF como estándar abierto en lugar de como producto de Google Cloud tiene una lógica que vale la pena explicitar, porque no es obvia.

El mercado de gestión del conocimiento para agentes está fragmentado hoy de la misma manera que estaba fragmentado el mercado de APIs antes de que REST y OpenAPI se convirtieran en convenciones compartidas. Cada proveedor de catálogos de datos tiene su propio modelo de metadatos, accesible mediante su propia API, con su propio vocabulario de tipos y su propia lógica de relaciones. Cada sistema de documentación tiene su propio formato de exportación. Cada organización que ha intentado alimentar agentes con contexto interno ha construido su propio sistema de adaptadores para traducir entre superficies.

El resultado: cada equipo que construye un agente resuelve el mismo problema de ensamblado de contexto desde cero, el conocimiento queda atrapado detrás de la superficie que lo creó, y la interoperabilidad entre sistemas requiere integración manual cada vez que algo cambia.

Un estándar abierto rompe esa dinámica de una manera que un servicio no puede. Un servicio requiere adopción comercial: alguien tiene que decidir pagar por él, implementarlo y depender de que el proveedor lo mantenga. Un estándar requiere adopción técnica, cuyo coste marginal es significativamente más bajo. Si el estándar es suficientemente simple como para que cualquier equipo pueda implementar un productor en pocas horas y un consumidor en pocas más, la barrera de entrada desaparece en la práctica.

La apuesta de Google con OKF es explícita en el texto del anuncio: “el valor de un formato de conocimiento viene de cuántas partes lo hablan, no de quién lo posee.” No es retórica open-source. Es la misma lógica que hizo que HTML, RSS o JSON tuvieran más impacto que cualquier plataforma propietaria construida en la misma época: el valor de un formato reside en su ubicuidad, y la ubicuidad solo se alcanza cuando el formato no le pertenece a nadie.

OKF y Machine Experience: transporte y origen

Cuando leí la especificación OKF, reconocí desde otro ángulo el problema que la Machine Experience describe: la distinción entre dónde se produce el conocimiento y cómo viaja desde ahí hasta quien lo consume.

Conviene ilustrarlo con el caso del estudiante universitario. El entorno de autoría donde alguien crea una página, publica una fecha o registra un dato determina si ese dato nace con la estructura que una máquina necesita para confiar en él. Si el entorno registra una fecha de un evento como texto libre dentro de un párrafo —sin un campo de estado ni de caducidad asociado— la información que publica no puede declarar su propia expiración. Un agente que la lea cuatro meses después no tiene manera de saber que ya no es válida: lee “inscripción abierta hasta el 15 de abril” y, sin una señal legible por máquina que indique cuándo deja de ser verdad, infiere que sigue vigente. Esa inferencia es donde el customer journey del estudiante se rompe.

El diagnóstico de la Machine Experience opera en el origen del problema: el momento en que el contenido nace. El diagnóstico de OKF opera en el transporte: el momento en que el conocimiento se mueve de un sistema a otro. Son dos momentos distintos de la misma cadena.

La conexión entre ellos no es metafórica. Un bundle OKF es la representación externa de lo que la Machine Experience describe como responsabilidad del entorno de autoría. Si el entorno de autoría captura la fecha de caducidad de un evento como un campo estructurado con estado —no como texto libre, sino como un dato tipado con un valor y una fecha de expiración— ese campo puede publicarse en un documento OKF con su timestamp. Si el entorno captura el umbral de admisión de un programa universitario como un dato autorizado —vinculado a su fuente, fechado, con un propietario de mantenimiento— ese dato puede viajar en un bundle OKF a cualquier agente que lo necesite, sin necesidad de ser reinterpretado y sin pedirle al consumidor que confíe en una inferencia no supervisada.

La distinción que OKF llama “independencia productor/consumidor” es la misma que la Machine Experience describe cuando dice que el con qué determina el para qué. OKF formaliza el estándar de transporte. La Machine Experience nombra la condición necesaria para que ese transporte funcione. Son dos caras de la misma decisión arquitectónica: OKF formaliza la cara externa; la Machine Experience nombra la interna.

Qué significa esto para una universidad

OKF no es exclusivamente una herramienta para equipos de ingeniería de datos en grandes compañías tecnológicas. Es un estándar que cualquier organización puede adoptar para mejorar la calidad del conocimiento que consumen sus agentes internos y externos. Para las universidades, las implicaciones son directas.

El problema del contenido caducado tiene un nombre técnico. Cuatro de los siete sitios web universitarios que revisé presentaban el mismo patrón: eventos anunciados en futuro con fechas ya pasadas, plazos de inscripción que cerraron meses atrás presentados como vigentes, notas de corte provenientes de agregadores en lugar de fuentes primarias. No es negligencia: es que el conocimiento sobre el estado real de cada contenido existe dentro de la organización —en los gestores de contenido, en los sistemas académicos, en los equipos de admisiones— pero no viaja a la página publicada en una forma que una máquina pueda leer. OKF pone nombre técnico a esa brecha y propone el mecanismo para cerrarla.

El momento de la admisión es exactamente donde los agentes fallan. El customer journey del estudiante hacia la matrícula es un sistema de restricciones: plazos de preinscripción, notas de corte, fechas de jornadas de puertas abiertas, requisitos de documentación, períodos de formalización. Cada una de esas restricciones es, en el lenguaje de OKF, un concepto que debería existir en un bundle verificable: con su tipo, su fuente autorizada, su timestamp de actualización y sus relaciones con otros conceptos del ecosistema. Una universidad que publica esas restricciones como texto en páginas HTML sin metadatos estructurados le da a cualquier agente que la represente una fuente de la que solo puede inferir. Una que las publica como conocimiento estructurado le da una fuente de la que puede razonar.

La plataforma de gestión de contenido es la infraestructura de producción de bundles. Si el contenido digital de una universidad —sus programas, sus eventos, sus fechas críticas, sus condiciones de admisión— es producido por un entorno de autoría que captura esos datos como campos estructurados con estado, fuente y caducidad, ese entorno ya está produciendo los ingredientes de un bundle OKF. Lo que determina si ese conocimiento puede viajar a los agentes con suficiente estructura para ser fiable es si el entorno donde nace lo declara en origen. Las plataformas de gestión de contenido que exportan el conocimiento de sus clientes en formatos alineados con OKF —o que producen directamente documentos compatibles— permiten que ese conocimiento sea consumido por agentes de terceros sin integración bilateral. Es exactamente lo que abordamos con OKF en Griddo: el mismo salto que el ecosistema dio cuando los CMS adoptaron APIs REST estándar, de integraciones punto a punto a un ecosistema de consumidores que se conectan sin fricción.

OKF como infraestructura de GEO

Hay una dimensión de OKF que la especificación toca indirectamente pero que tiene implicaciones directas para cualquier organización con presencia digital: su relación con el GEO —Generative Engine Optimization, el conjunto de prácticas que determinan si una organización está representada con precisión en las respuestas de los sistemas de IA generativa.

Los modelos de lenguaje que alimentan los asistentes de IA aprenden de lo que pueden leer, verificar y atribuir. Una organización cuyo conocimiento está declarado en forma estructurada —con fuentes citables, timestamps actuales y relaciones explícitas entre conceptos— le da a esos modelos exactamente el tipo de conocimiento que pueden incorporar con confianza. Una organización cuyo conocimiento está enterrado en texto no estructurado, sin fechas de actualización y sin autoridad declarada, es una sobre la que los modelos tienen que inferir, y la inferencia produce representaciones imprecisas que ningún equipo de marketing puede controlar después.

OKF, entendido desde esta perspectiva, es infraestructura GEO —no en el sentido de una técnica de posicionamiento, sino en el sentido más básico: un mecanismo para que el conocimiento de una organización exista en una forma que los sistemas de IA puedan leer, verificar y citar. El posicionamiento en LLMs no se logra optimizando texto para un algoritmo; se logra siendo una fuente que merece confianza. Y una fuente merece confianza cuando su conocimiento está declarado con suficiente estructura para que quien lo consume pueda verificarlo.

En Griddo hemos explorado cómo la arquitectura web determina el éxito de la citación en sistemas generativos, y cómo la búsqueda semántica opera sobre contenido que ha sido estructurado para ser comprendido, no solo recuperado. OKF añade una capa más a ese argumento: no solo es importante cómo está estructurada la página, sino si el conocimiento que esa página contiene puede viajar fuera de ella en forma verificable. Una universidad que domina el GEO no es solo la que tiene páginas bien estructuradas; es la que tiene conocimiento que puede ser consumido por cualquier agente con suficiente contexto para confiar en él.

Los bots ya superan a las personas en el tráfico de internet, según datos recientes de Cloudflare. Para una organización cuya visibilidad depende de que los agentes la representen con precisión —que es, de forma creciente, cualquier organización con presencia digital— el problema del conocimiento estructurado pasa de ser una buena práctica arquitectónica a ser una condición básica de visibilidad.

OKF en contexto: qué ya existía y qué viene a formalizar

OKF no emerge en el vacío. Formaliza una familia de patrones que equipos técnicos habían desarrollado de forma independiente durante los últimos años, cada uno con su propia convención y sin interoperabilidad entre ellos.

El patrón más influyente es el LLM-wiki que Karpathy describió en 2024: un repositorio de archivos markdown que los propios agentes mantienen y actualizan, funcionando como memoria persistente y base de conocimiento entre sesiones de trabajo. La lógica es que los LLMs son buenos exactamente en lo que los humanos son malos para mantener wikis: consistencia, actualización de referencias cruzadas, la capacidad de tocar muchos archivos en un solo pase. El wiki que los humanos abandonan porque el mantenimiento es tedioso es el wiki que un LLM puede mantener indefinidamente.

El patrón AGENTS.md y CLAUDE.md, popularizado por Claude Code y otros entornos agénticos, aplica la misma lógica a nivel de repositorio de código: un archivo de instrucciones markdown que el agente lee al inicio de cada sesión y que le da el contexto que necesita para operar sin preguntar sobre cada convención del proyecto. Es un bundle OKF de un solo archivo, sin el nombre y sin la cabecera YAML.

Las Obsidian Vaults conectadas a agentes de código son otro ejemplo: una vault de Obsidian es, estructuralmente, un bundle de archivos markdown con frontmatter YAML y enlaces entre documentos. El plugin Dataview de Obsidian demuestra que ese formato es suficientemente rico para construir consultas complejas sobre el grafo de conocimiento sin ninguna base de datos externa.

Lo que todos estos patrones comparten es la intuición que OKF formaliza: el conocimiento que los agentes necesitan para operar bien puede representarse como markdown con metadatos, versionarse con git y distribuirse sin plataforma. Lo que faltaba era el pequeño conjunto de convenciones que permite que el wiki de un equipo, el catálogo de datos de otro y la documentación de un tercero sean consumibles por el mismo agente sin adaptadores. OKF es ese conjunto de convenciones.

El momento de adoptar

OKF v0.1 es una especificación inicial, y sus autores son explícitos al respecto. El formato evolucionará a medida que emerjan más productores y consumidores y a medida que el ecosistema de agentes identifique qué representaciones de conocimiento son realmente necesarias en la práctica.

Pero el momento del anuncio no es accidental. La curva de adopción de los sistemas agénticos está en el punto en que los problemas de contexto y conocimiento dejan de ser limitaciones teóricas y se convierten en cuellos de botella prácticos. Los equipos que construyen agentes no están limitados por la capacidad del modelo; están limitados por la calidad del conocimiento que el modelo puede leer. OKF aparece en ese momento preciso, cuando la demanda de un estándar es suficientemente alta para que la adopción tenga su propio impulso.

La pregunta para cualquier organización no es si OKF será relevante. Es cuándo adoptarlo y hasta qué profundidad. Las organizaciones que construyen infraestructura de conocimiento compatible con OKF ahora —aunque sea parcialmente, empezando por los dominios más críticos para sus agentes— estarán mejor posicionadas cuando el ecosistema de consumidores madure y la demanda de bundles de calidad aumente.

Las organizaciones que esperen a que el estándar esté completamente estabilizado repetirán el mismo error cometido con schema.org en los primeros años de la última década: el momento de adoptar un estándar de conocimiento estructurado no es cuando todo el mundo lo hace, sino cuando hacerlo tiene bajo coste y alta ventaja diferencial.

Para las universidades, la traducción es concreta. El primer paso no requiere rediseñar toda la arquitectura digital: requiere identificar qué conocimiento crítico —los plazos de admisión, las condiciones de cada programa, las fechas que los estudiantes necesitan para tomar decisiones— está hoy enterrado en texto libre sin estructura verificable, y empezar a declararlo en forma que un agente pueda leer y en la que pueda confiar. La infraestructura para hacerlo ya existe en cualquier plataforma de gestión de contenido que capture campos estructurados con estado y timestamps. Lo que OKF añade es el estándar que permite que ese conocimiento viaje.

Conclusión

Cuando una organización con la capacidad técnica de Google publica una especificación y dice que lo que faltaba no era un servicio sino un formato, está haciendo un diagnóstico sobre el estado del mercado. El diagnóstico es que el problema del conocimiento en las organizaciones es un problema de declaración, no de recuperación. Los agentes tienen acceso a más información que nunca; lo que les falta es información que haya sido declarada en una forma en la que puedan confiar.

OKF propone el mecanismo de transporte: la convención que permite que el conocimiento viaje desde un productor hasta un consumidor con suficiente contexto para ser interpretado correctamente en destino. La Machine Experience describe dónde se decide si ese mecanismo tiene algo útil que transportar: el entorno de autoría, el backoffice, el momento en que el contenido nace.

Ambas son necesarias, y ninguna resuelve el problema de la otra. Un bundle OKF construido sobre contenido que nació sin estructura se limita a mover el problema. Y un entorno de autoría que produce conocimiento estructurado pero que no tiene un formato estándar para distribuirlo deja ese conocimiento atrapado en la herramienta que lo creó.

Para cualquier organización que gestiona contenido destinado a ser consumido por agentes —y ese conjunto es, de forma creciente, cualquier organización con presencia digital— la pregunta ya no es si estructurar el conocimiento. Es qué estándar, desde dónde y a qué ritmo. OKF responde a la primera pregunta. La Machine Experience responde a la segunda. El con qué, como siempre, determina el para qué.