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

Open Knowledge Format (OKF) es la especificación abierta, independiente del proveedor y todavía en borrador 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 julio de 2026, la versión vigente es OKF v0.1 Draft.

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.

¿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]
timestamp: 2026-07-12T09:00:00Z
---

# Definition

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

# Citations

[1] [Política financiera](https://docs.example.com/finance/mrr)

Solo type es obligatorio. title, description, resource, tags y timestamp son recomendados. Los productores pueden añadir claves; los consumidores deben conservar las que no conocen. Ese contrato flexible es la decisión central de la especificación oficial OKF v0.1.

¿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é 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.

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;
• 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, fechas, 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.
• Identidad y ciclo de vida: la ruta es el ID; renombrar requiere convenciones externas.
• Verdad y vigencia: conformidad estructural no significa contenido correcto, completo o seguro.
• 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 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 julio de 2026: un piloto reversible de 20–50 conceptos, un equipo propietario, un caso de agente y un flujo medible. 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.1
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 julio de 2026. Revisa versión e incidencias abiertas antes de fijar un perfil empresarial duradero.