Open Knowledge Format (OKF): qué es, cómo funciona y cuándo adoptarlo

Open Knowledge Format (OKF) es la especificación abierta e independiente del proveedor de Google Cloud para empaquetar conocimiento empresarial como archivos Markdown enlazados con metadatos YAML. Personas y agentes de IA pueden leer el mismo contexto portable sin un SDK propietario. A 12 de agosto de 2026, la versión vigente es OKF v0.2, que sustituye a v0.1.

Dos límites evitan malentendidos. Este OKF no es la Open Knowledge Foundation, que comparte las siglas. Tampoco es una base de datos, un modelo, un motor de recuperación, un protocolo de agentes ni una señal confirmada de ranking de Google. Es un formato de intercambio mínimo para el conocimiento que esos sistemas consumen.

¿Qué problema resuelve OKF?

A las empresas no suele faltarles conocimiento; les falta contexto que se pueda ensamblar. La definición de cliente activo está en BI, el cálculo en SQL, la excepción en Slack, el contrato de la API en OpenAPI, el procedimiento de incidentes en Confluence y la razón de todo ello en la cabeza de una persona senior.

Un agente puede buscar en estos sistemas, pero cada integración devuelve una forma distinta. Cada nuevo asistente reconstruye conectores, fragmentación, metadatos y permisos. Cuando cambia el catálogo o el proveedor del modelo, el conocimiento seleccionado queda atrapado en la herramienta anterior. Google Cloud presentó OKF el 12 de junio de 2026 para formalizar el patrón “LLM wiki”: una biblioteca Markdown compartida y mantenida por personas y agentes. El anuncio oficial de Google Cloud plantea que la pieza que falta es un formato, no otro servicio.

Si evalúas una implementación concreta en lugar del formato, nuestra review de OpenKB y comparación con RAG analiza un compilador open source, la evidencia independiente y los controles empresariales que todavía necesita.

Si la pregunta más amplia es cómo personas y agentes comparten una fuente gobernada, nuestra guía de arquitectura para una wiki empresarial preparada para IA cubre conocimiento canónico, permisos, recuperación, escrituras controladas y un piloto de 30 días.

¿Cómo funciona Open Knowledge Format?

Un paquete OKF (Knowledge Bundle) es un árbol de directorios. Cada unidad duradera es un documento de concepto en Markdown UTF-8. Su ruta sin .md es el ID del concepto. Los enlaces Markdown forman un grafo; las carpetas aportan una jerarquía navegable.

conocimiento-empresa/
├── index.md
├── log.md
├── metricas/
│   ├── index.md
│   └── ingresos-recurrentes-mensuales.md
├── sistemas/
│   └── billing-api.md
└── playbooks/
    └── pago-fallido.md

Cada concepto combina metadatos consultables con contenido legible:

---
type: Metric
title: Monthly Recurring Revenue
description: Ingresos recurrentes contratados normalizados a un mes.
resource: https://analytics.example.com/mrr
tags: [finance, saas, board]
status: stable
generated: { by: human:finance-owner, at: 2026-08-12T09:00:00Z }
verified: { by: human:controller, at: 2026-08-12T10:00:00Z }
stale_after: 2026-11-12
sources:
  - id: finance-policy
    resource: https://docs.example.com/finance/mrr
    title: Política financiera
---

# Definition

MRR incluye suscripciones activas y excluye servicios puntuales.[^finance-policy]
La lógica de devoluciones está en el [playbook](/playbooks/refunds.md).

[^finance-policy]: Política financiera

Solo type es siempre obligatorio. title, description, resource y tags siguen recomendados. La versión 0.2 añade campos opcionales de procedencia, confianza, ciclo de vida, vigencia y cálculos. Los productores aún pueden añadir claves; los consumidores deben conservar las que no conocen. Ese contrato flexible sigue siendo la decisión central de la especificación oficial OKF v0.2.

¿Cuáles son las tres reglas de conformidad?

1. Cada archivo Markdown no reservado contiene frontmatter YAML válido.
2. Cada bloque tiene un type no vacío. No existe un registro central de tipos.
3. Los archivos reservados respetan su estructura cuando existen. index.md enumera un directorio para navegar progresivamente y log.md registra cambios fechados. Ambos son opcionales.

El resto es guía flexible. Un consumidor conforme debe tolerar campos opcionales ausentes, tipos desconocidos, extensiones propias, enlaces rotos e índices ausentes. Una base de conocimiento incompleta debe degradarse con elegancia, no quedar inutilizada.

¿Qué cambió de OKF v0.1 a v0.2?

La versión 0.2 conserva las tres reglas de conformidad, pero facilita inspeccionar conocimiento mantenido por agentes. Añade familias de campos opcionales en vez de un esquema central:

• Procedencia: sources registra los materiales que sustentan un concepto. Cada fuente puede incluir id estable, título, autor, recuento de uso y fecha de modificación. Las notas al pie Markdown pueden usar ese ID para atribuir afirmaciones concretas.
• Confianza: generated indica quién o qué produjo el contenido actual; verified registra comprobaciones posteriores. El consumidor deriva los niveles no verificado, confirmado por máquina o revisado por una persona. Son señales consultivas, no control de acceso.
• Ciclo de vida y vigencia: status puede ser draft, stable o deprecated. stale_after fija una fecha absoluta a partir de la que el consumidor debería avisar o rechazar.
• Cálculos atestiguados: el nuevo tipo Attested Computation vincula un cálculo autorizado con runtime, parámetros tipados, ejecutor, campos del recibo y un atestiguador determinista. OKF almacena el contrato y el método de comprobación; no ejecuta el cálculo.

Hay dos cambios de campo que requieren migración. generated.at sustituye al timestamp de v0.1, y sources en el frontmatter sustituye a la lista # Citations del cuerpo. Un consumidor v0.2 puede usar ambas formas antiguas como fallback, por lo que la migración puede ser gradual. El index.md raíz también puede declarar okf_version: "0.2".

¿Qué es OKF y qué no es?

OKF vs RAG vs MCP vs OpenAPI vs llms.txt

Son capas que pueden componerse, no sustitutos.

Una arquitectura práctica: responsables de dominio editan OKF en Git; CI lo valida; RAG indexa el paquete; un servidor MCP ofrece búsqueda y acceso a sistemas vivos. OKF es la fuente duradera, RAG el mecanismo de selección y MCP la puerta de ejecución.

"OKF no resuelve la recuperación ni el gobierno. Primero resuelve una pregunta más silenciosa: si tu conocimiento sobrevive a la herramienta que lo creó y sigue siendo legible para la siguiente persona o agente."

¿Dónde crea valor empresarial?

• Contexto que sobrevive al cambio de proveedor. Cambiar modelo, catálogo, base vectorial o framework no obliga a reescribir el conocimiento.
• Conocimiento revisado como código. Pull requests, diffs, CODEOWNERS, tags y rollback funcionan desde el primer día.
• Onboarding e incidentes más rápidos. Los mismos conceptos alimentan al asistente, se renderizan como documentación y siguen siendo legibles durante una caída.
• Un destino común de exportación. Catálogos, wikis y repositorios producen OKF en vez de integrar cada consumidor por separado.
• Carga progresiva de contexto. El agente lee index.md y abre solo lo relevante.
• Confianza y vigencia consultables. El consumidor distingue contenido no verificado de contenido revisado por personas y avisa al superar stale_after.

El caso comercial es fuerte cuando varios agentes necesitan el mismo contexto, el conocimiento cambia con frecuencia y la independencia o auditoría importan. Para una FAQ estática y un chatbot, documentación normal con buena búsqueda puede bastar.

¿Qué conviene guardar en un paquete OKF?

• métricas de negocio, definiciones, propietarios, fórmulas y excepciones;
• cálculos autorizados que necesiten parámetros tipados, recibos de ejecución y comprobaciones deterministas;
• sistemas, APIs, datasets, tablas, eventos y dependencias;
• reglas de producto, decisiones de arquitectura, runbooks y escalados;
• controles de compliance, evidencias, políticas y fechas de revisión;
• playbooks de soporte con límites claros para acciones automatizadas.

No vuelques secretos, datos personales, chats brutos, contratos o credenciales a un paquete legible desde Git. Los archivos sencillos facilitan la interoperabilidad y también las fugas. Clasificación, mínimo privilegio, retención y revisión siguen siendo obligatorios.

¿Cómo se implementa OKF en una empresa?

1. Elegir un dominio acotado con decisiones reales. Una métrica, un proceso de soporte o un servicio en producción.
2. Inventariar fuentes y responsables. Fuente autoritativa, propietario, sensibilidad, evento de actualización y consumidores.
3. Definir un perfil local pequeño. Cinco a diez tipos, campos, nombres y plantillas propios, sin presentarlos como parte del estándar base.
4. Generar y luego revisar. Exportadores y LLMs redactan; expertos resuelven contradicciones, quitan secretos y aprueban afirmaciones.
5. Validar en CI. YAML, type, reservados, recursos duplicados, enlaces, actores y fechas, IDs de fuentes, conceptos caducados, contratos de cálculo, patrones sensibles y propietarios.
6. Conectar un consumidor. Indexar para RAG o servir al agente. Medir exactitud, trazabilidad, precisión de recuperación y tiempo de actualización.
7. Definir la operación. Revisión, caducidad, acceso, eliminaciones, índices y cachés.

¿Qué deja sin resolver?

• Permisos: no define control por documento o campo.
• Renombrado y eliminación: la ruta es el ID, así que mover exige convenciones externas. v0.2 añade deprecated, pero no define propagación de borrados ni tombstones.
• Verdad y aplicación: la conformidad y los campos de confianza no demuestran que el contenido sea correcto ni que las revisiones se hayan ejecutado.
• Semántica: los enlaces son dirigidos pero sin tipo; “depende de” o “sustituye a” queda en prosa.
• Alta frecuencia: Git es excelente para revisión, no para estado transaccional con muchos escritores.
• Descubrimiento: el consumidor aún debe conocer y poder acceder al paquete.

Por eso OKF encaja como capa curada, no como nuevo sistema de registro. Los datos operativos permanecen en sus sistemas; OKF documenta qué significan, cómo se conectan y cómo deben usarse.

¿OKF mejora el SEO o las citas de LLM?

No de forma automática. Ni el anuncio ni la especificación v0.2 definen OKF como señal de crawling, ranking o citación. Publicar un directorio /okf/ puede ayudar a un consumidor que ya lo conoce, pero no garantiza posiciones en Google, AI Overviews ni citas en ChatGPT.

Para visibilidad pública siguen contando HTML indexable, respuestas directas, URLs estables, autores, fuentes primarias, datos estructurados, enlaces internos y análisis original. OKF puede ser una exportación adicional; no debe sustituir la web.

¿Debería tu empresa adoptar OKF ahora?

Nuestra recomendación en agosto de 2026: un piloto reversible de 20–50 conceptos, un equipo propietario, un caso de agente y un flujo medible. Usa los campos v0.2 de procedencia y vigencia cuando respondan a una pregunta operativa real, y conserva el material fuente. Si cambia el formato, Markdown y YAML son baratos de migrar; si falla el piloto, la documentación curada conserva valor.

Fuentes primarias

1. Google Cloud: Introducing the Open Knowledge Format
2. Especificación oficial OKF v0.2
3. Repositorio y herramientas de referencia
4. Paquetes oficiales de ejemplo
5. Patrón LLM wiki de Andrej Karpathy
6. Licencia Apache 2.0 de OKF

Estado comprobado el 12 de agosto de 2026. Revisa versión e incidencias abiertas antes de fijar un perfil empresarial duradero.