Wiki empresarial preparada para IA: arquitectura y guía de implementación

Una wiki empresarial preparada para IA es una fuente gobernada de conocimiento organizativo que las personas pueden editar y los agentes de IA pueden recuperar con los mismos permisos, procedencia y señales de vigencia. No es un chatbot conectado a una carpeta. El sistema útil separa conocimiento canónico, índices derivados, control de acceso, entrega a agentes y revisión humana.

Esta guía responde a la pregunta de implementación: cómo diseñar y comprar ese sistema. Nuestra guía de Open Knowledge Format explica el formato de intercambio, el análisis de OpenKB evalúa un compilador de conocimiento y la lista de preparación de RAG para producción cubre la calidad de recuperación. Aquí conectamos esas capas en un modelo operativo para toda la empresa.

¿Qué hace que una wiki empresarial esté preparada para IA?

Una wiki está preparada para IA cuando una persona y un agente pueden encontrar, autorizar, atribuir, verificar y probar la misma respuesta. La búsqueda semántica mejora el descubrimiento, pero no asigna responsables, resuelve contradicciones ni conserva por sí sola los permisos documentales.

¿Qué arquitectura funciona para personas y agentes de IA?

El patrón duradero es un sistema de conocimiento de seis capas. Cada capa tiene una función, por lo que puedes cambiar el buscador o el modelo sin mover la fuente de verdad.

1. Sistemas fuente. Wikis, políticas, tickets, repositorios, bases de datos y conversaciones aprobadas siguen siendo evidencia, no un volcado indiferenciado.
2. Conocimiento canónico. Los conceptos duraderos, como una regla de precios, un runbook de incidentes o una definición de cliente, tienen ID estables, responsables, fuentes y metadatos de ciclo de vida.
3. Plano de control de gobernanza. Clasificación, política de acceso, revisiones, aprobaciones, retención y auditoría acompañan al concepto.
4. Índices derivados. Los índices de palabras, vectores y grafos son proyecciones reconstruibles. Nunca son la única copia del conocimiento.
5. Capa de entrega. Una API o servidor MCP consciente de permisos entrega el contexto mínimo relevante y remite a la fuente canónica.
6. Experiencias. Las personas navegan y editan una wiki; los asistentes responden; los agentes cargan contexto para tareas acotadas.

La especificación Open Knowledge Format v0.2 de Google Cloud encaja en la capa canónica porque mantiene los conceptos en Markdown legible e incorpora campos opcionales de procedencia, verificación, ciclo de vida y vigencia. No define recuperación, permisos ni entrega en ejecución. Por eso siguen haciendo falta las demás capas.

¿Deberías sustituir tu wiki actual?

Normalmente no al principio. Trata la wiki actual como superficie de edición o fuente de evidencia y construye una capa gobernada alrededor de un flujo valioso. Sustituir todas las páginas antes de probar la calidad de recuperación crea un proyecto de migración sin demostrar valor empresarial.

Hay tres modelos viables de fuente de verdad:

Un buen piloto puede empezar con 30 a 50 conceptos de alto valor. No ingieras toda la unidad corporativa. Empieza por las preguntas que retrasan onboarding, soporte, ventas o respuesta a incidentes, y por la evidencia que las responde.

¿Cómo deben recuperar conocimiento los agentes?

Ningún método gana en todas las preguntas. Usa el más barato que conserve el significado y la evidencia necesarios.

La evaluación debe incluir lenguaje real e imperfecto. La nota de Google Cloud sobre evaluación del descubrimiento de agentes plantea la recuperación como buscar una aguja en un pajar y pregunta cuánto puede degradarse una consulta antes de fallar. Prueba abreviaturas, nombres antiguos, preguntas incompletas y fuentes contradictorias, no solo prompts pulidos por el equipo de implementación.

¿Cómo se mantienen seguros los permisos y las escrituras?

El control de permisos pertenece a la ruta de recuperación. Copiar documentos restringidos a un índice vectorial común y filtrar después de generar es demasiado tarde. Cada búsqueda y lectura debe derivar la identidad, cruzarla con los permisos de la fuente y devolver solo conceptos autorizados.

La guía de OWASP sobre debilidades de vectores y embeddings identifica fugas entre contextos, conocimiento envenenado y controles débiles como riesgos concretos de RAG. Recomienda almacenes conscientes de permisos, validación de fuentes confiables, clasificación y registros de recuperación.

Si la wiki se expone mediante MCP, conserva autenticación y autorización en esa frontera. La guía actual de seguridad de MCP exige verificar las solicitudes entrantes y rechaza el paso directo de tokens porque puede eludir controles y romper la trazabilidad. El ID de un resultado o un handle de estado no demuestra permiso para leer la página subyacente.

Empieza con una política de escritura asimétrica:

• Las personas publican; los agentes proponen. Los agentes crean borradores o parches con fuentes y el motivo del cambio.
• Los revisores aceptan un diff. Conceptos críticos como precios, políticas legales y runbooks de producción requieren responsables nombrados.
• Los índices se reconstruyen tras la aprobación. El contenido rechazado o sin revisar nunca se convierte en contexto confiable.
• Cada respuesta permanece trazable. Registra consulta, ID recuperados, decisión de política, respuesta y feedback sin registrar secretos.

La reciente arquitectura de referencia de Cloudflare para un espacio empresarial de agentes usa la misma separación: el contexto compartido se publica de forma central en una biblioteca versionada y de solo lectura, mientras modelos, herramientas, credenciales y ejecución se gobiernan fuera del espacio.

¿Qué debe contener cada concepto?

Un concepto debe responder una pregunta duradera y mostrar metadatos suficientes para decidir si es seguro usarlo antes de leer todo su cuerpo.

---
type: Policy
title: Escalado de incidentes de producción
owner: team:platform
status: stable
classification: internal
generated: { by: human:platform-lead, at: 2026-08-13T09:00:00Z }
verified: { by: human:security-owner, at: 2026-08-13T11:00:00Z }
stale_after: 2026-11-13
sources:
  - id: incident-policy
    resource: https://intranet.example/policies/incidents
---

# Decisión

Avisar al comandante de incidentes ante un evento confirmado de severidad uno.

# Excepciones

Los despliegues gestionados por clientes siguen el runbook contractual.

# Procedimiento

1. Abrir el canal del incidente.
2. Registrar evidencia y hora de inicio.
3. Avisar al responsable.

El frontmatter no sustituye una redacción clara. Permite que una persona, un filtro determinista o un agente descarte un concepto obsoleto, sustituido o no autorizado antes de gastar tiempo y contexto del modelo.

¿Cómo es un piloto de 30 días?

1. Días 1 a 3, elegir el flujo. Escoge una ruta costosa, como incorporar a un desarrollador, responder una escalada de soporte o diagnosticar un incidente. Define responsable y métrica.
2. Días 4 a 7, crear el conjunto de preguntas. Recoge 25 preguntas reales, respuestas esperadas, fuentes aprobadas, roles autorizados y casos de rechazo.
3. Días 8 a 14, curar el segmento. Normaliza 30 a 50 conceptos, asigna responsables, elimina duplicados y registra contradicciones sin fusionarlas en silencio.
4. Días 15 a 20, construir recuperación y acceso. Compara búsqueda léxica e híbrida, aplica permisos antes de recuperar y devuelve enlaces de fuente con cada respuesta.
5. Días 21 a 25, añadir ambas interfaces. Las personas navegan y corrigen; un agente aprobado busca y lee mediante una API o superficie MCP estrecha.
6. Días 26 a 30, ejecutar evaluación ciega. Mide corrección con fuentes, recall, calidad del rechazo, tiempo mediano, esfuerzo de revisión y fallos de permisos contra el flujo actual.

Escala solo si el piloto mejora un resultado empresarial sin debilitar acceso ni crear una cola sin dueño. Nuestro modelo de costes de un asistente interno en DACH explica por qué preparación del contenido, permisos, evaluación y mantenimiento suelen importar más que la factura del modelo.

¿Conviene construir, comprar o ampliar?

Una demo comercial no debe decidirlo. Exige una exportación, una prueba de permisos y una evaluación ciega con tus preguntas. Si el sistema no explica por qué recuperó una respuesta, quién puede verla y cuándo se verificó su fuente, no está preparado para ser la memoria de la empresa.

Lista de aceptación para una wiki preparada para IA

1. Un responsable nombrado para cada concepto crítico.
2. ID estables y enlaces visibles a fuentes aprobadas.
3. Estado, verificación y fecha de revisión explícitos.
4. Permisos de fuente aplicados antes de recuperar.
5. Contenido canónico separado de índices reconstruibles.
6. Las respuestas citan los conceptos realmente recuperados.
7. Los agentes proponen cambios mediante borradores o diffs revisables.
8. Las contradicciones y el contenido obsoleto se muestran, no se mezclan.
9. Un conjunto fijo cubre preguntas vagas, rechazos y límites de acceso.
10. Exportación, auditoría y portabilidad del modelo probadas antes del despliegue.