Convertir su wiki interno en un asistente de IA: guía paso a paso

Convertir su wiki interno en un asistente de IA consiste en exportar el contenido de Notion, Confluence o Google Docs, trocearlo en fragmentos indexables, mantenerlo actualizado y respetar los permisos originales antes de dejar que la plantilla le haga preguntas en lenguaje natural. El resultado, bien hecho, es un buscador que responde con la frase exacta del manual y el enlace a la página de origen, en lugar de un buscador de palabras clave que devuelve veinte resultados a medias.

Por qué el wiki interno es el caso de uso perfecto para RAG

Casi todas las empresas acumulan años de documentación en Notion, Confluence o una carpeta de Google Docs: políticas de vacaciones, procedimientos de onboarding, runbooks técnicos, decisiones de producto, plantillas de contratos. El problema no es la falta de información, es que nadie la encuentra a tiempo. Un empleado nuevo pregunta en el canal de Slack algo que ya está documentado desde hace dos años, y alguien del equipo pierde diez minutos buscando el enlace correcto (si lo recuerda).

Un asistente basado en recuperación de información (RAG, Retrieval Augmented Generation) resuelve este problema concreto: indexa todo el wiki, entiende la pregunta en lenguaje natural y devuelve una respuesta redactada con las citas exactas de los documentos de origen. No sustituye el wiki, lo convierte en algo consultable. Si quiere entender el mecanismo técnico con detalle, puede repasar cómo funciona RAG paso a paso antes de lanzarse al proyecto.

La diferencia con pedirle directamente a un modelo de lenguaje genérico que "sepa" de su empresa es que aquí la respuesta está anclada en documentos reales, con pasaje citado, lo que reduce drásticamente las invenciones. Si le preocupa ese punto en concreto, conviene leer también cómo reducir las alucinaciones de la IA con respuestas basadas en fuentes.

Paso 1: exportar el contenido de Notion, Confluence o Google Docs

El primer obstáculo suele ser puramente mecánico: sacar el contenido de la herramienta donde vive. Cada plataforma tiene su propio formato de exportación, y conviene saber qué esperar antes de ponerse manos a la obra.

Una recomendación práctica: exporte en PDF o Word cuando el documento tiene tablas o formato visual importante, y en Markdown cuando es texto estructurado con títulos y listas. El motivo es que el chunking (el troceado del documento en fragmentos) funciona mejor cuando conserva la jerarquía de títulos original.

1. Haga un inventario de espacios o carpetas: identifique cuáles están realmente vivos y cuáles son archivo muerto que no merece la pena indexar.
2. Exporte por lotes, no página a página: la mayoría de herramientas permiten exportar un espacio completo de una vez.
3. Revise manualmente una muestra de 10-15 documentos exportados para detectar pérdidas de formato antes de subir cientos de archivos.
4. Elimine duplicados y versiones obsoletas antes de la indexación: un wiki acumula borradores y copias "v2 final" que solo confunden al asistente.

Paso 2: estructurar y trocear el contenido para que el asistente responda bien

Un wiki no es un único documento, es una colección de páginas con jerarquías, enlaces cruzados y niveles de detalle muy distintos. Para que la búsqueda híbrida (texto completo más expansión semántica) funcione, el contenido debe dividirse en fragmentos (chunks) de tamaño razonable, ni tan grandes que diluyan la respuesta ni tan pequeños que pierdan el contexto.

Las políticas de RRHH, por ejemplo, suelen tener artículos cortos y autocontenidos (una cláusula de vacaciones, un procedimiento de baja médica) que funcionan bien como chunks independientes. Los runbooks técnicos, en cambio, mezclan pasos secuenciales que no deberían separarse a mitad de camino. Si quiere entrar en el detalle técnico de tamaños y solapamiento, tenemos una guía específica sobre estrategias de chunking para RAG que le ayudará a decidir parámetros según el tipo de documento.

Un caso real y muy habitual en España es el manual del empleado combinado con el convenio colectivo: dos documentos con estructuras distintas que el asistente debe tratar de forma coherente. Puede ver un ejemplo desarrollado en un asistente de IA para políticas de RRHH.

Paso 3: mantener la base actualizada (el problema del wiki abandonado)

El mayor riesgo de un asistente de IA sobre documentación interna no es que invente respuestas, es que cite con total seguridad una política que cambió hace seis meses. Un wiki desactualizado con un asistente encima es peor que un wiki desactualizado solo, porque la respuesta suena más convincente.

Hay dos estrategias complementarias:

• Reindexación programada: vuelva a exportar y subir los documentos con una frecuencia fija (semanal o mensual según el ritmo de cambios de su wiki).
• Reindexación por evento: si su herramienta de origen tiene webhooks o API, automatice la actualización cuando una página se edita, en lugar de esperar al ciclo programado.
• Fecha visible: asegúrese de que cada respuesta muestra la fecha del documento citado, para que el usuario pueda juzgar si la información sigue vigente.
• Dueños de contenido: asigne a alguien responsable de cada sección del wiki para que revise periódicamente qué está obsoleto antes de volver a indexar.

Si quiere ir un paso más allá y medir de forma objetiva si las respuestas siguen siendo fieles al contenido actualizado, conviene revisar cómo evaluar un sistema RAG: métricas, fidelidad y monitorización.

Paso 4: permisos, privacidad y quién puede preguntar qué

Un wiki interno rara vez es completamente plano en cuanto a acceso. Hay espacios públicos para toda la plantilla, espacios de dirección o de RRHH con información sensible, y a veces documentos legales o financieros que solo deberían consultar unas pocas personas. Antes de indexar todo junto, decida el modelo de acceso:

1. Base privada única: todo el wiki en una sola base de conocimiento, accesible solo con claves API internas o desde el panel de la empresa.
2. Varias bases segmentadas: una base por departamento o nivel de confidencialidad, cada una con sus propias credenciales.
3. Filtrado en el origen: excluya de la exportación cualquier espacio marcado como confidencial antes de subir nada, en lugar de confiar en permisos posteriores.

Esta decisión tiene implicaciones de protección de datos si el wiki contiene datos de empleados (nóminas, evaluaciones, bajas médicas). Conviene revisar qué aplica en su caso antes de lanzar el proyecto, especialmente si se van a tratar datos personales: tenemos una lista de comprobación en RGPD y RAG: qué revisar antes de lanzar su proyecto de IA. Si además el asistente va a estar expuesto a terceros o usado de forma intensiva por la plantilla, también le interesará saber qué significa realmente que un asistente sea "privado" en un ChatGPT privado para los documentos de su empresa.

Paso 5: medir si el equipo realmente lo usa

Montar el asistente es la parte fácil. Que la plantilla cambie el hábito de preguntar en Slack por el hábito de preguntar al asistente es lo difícil. Algunas señales que conviene seguir desde el primer mes:

• Número de preguntas por semana y por departamento: si solo lo usa el equipo que lo montó, algo falla en la difusión.
• Preguntas sin respuesta satisfactoria: revise los casos donde el asistente no encontró pasaje relevante, suelen señalar huecos reales en la documentación.
• Tasa de repetición: usuarios que vuelven a preguntar varias veces en la misma semana indican adopción real, no curiosidad puntual.
• Reducción de preguntas repetidas en Slack o en el canal de soporte interno, que es la métrica de negocio que de verdad justifica el proyecto.

Una forma sencilla de impulsar la adopción sin pedirle a nadie que cambie de pestaña es dejar que el asistente se consulte desde donde ya trabajan: el editor de código, Claude o ChatGPT vía MCP. Si su equipo técnico vive en Cursor o en un cliente MCP, el artículo conectar Claude, Cursor o ChatGPT a una base de conocimiento explica cómo exponer la base del wiki como una herramienta más dentro de esas aplicaciones.

Cómo montarlo en una tarde con Kopik

Si no quiere levantar infraestructura de embeddings, base vectorial y pipeline de chunking desde cero, un marketplace de bases de conocimiento como Kopik permite hacer todo el proceso anterior sin escribir código. Sube los exports de Notion, Confluence o Google Docs (PDF, Word, texto o Markdown), Kopik se encarga de extraer, trocear e indexar el contenido para búsqueda híbrida, y la base queda lista para recibir preguntas con respuestas citadas o solo pasajes, según lo que necesite.

Para un wiki interno, lo habitual es crear una base privada, accesible solo con las claves API de la empresa o desde el panel web, y decidir si quiere consultarla desde una interfaz de chat, integrarla en su intranet vía API REST, o conectarla como servidor MCP a las herramientas que ya usa el equipo técnico. Si prefiere integrarla directamente en una aplicación interna, el artículo añadir una API de base de conocimiento a su aplicación cubre la parte de desarrollo.

Antes de decidirse, conviene también tener claro el presupuesto: montar esto desde cero con una base vectorial propia tiene costes de infraestructura y mantenimiento que muchas pymes subestiman. Puede comparar ambos caminos en ¿Cuánto cuesta realmente un sistema RAG? y explorar el catálogo de bases ya existentes en /bases o la documentación técnica en /developers si prefiere integrarlo vía API o MCP.

Errores habituales al convertir un wiki en asistente de IA

• Indexar todo sin limpiar duplicados ni borradores, lo que hace que el asistente cite versiones obsoletas junto a las vigentes.
• No separar por permisos y acabar con información sensible accesible a toda la plantilla.
• Olvidar un plan de reindexación, de modo que el asistente queda congelado en el día del lanzamiento.
• Lanzar el proyecto sin medir el uso real, perdiendo la oportunidad de detectar huecos de documentación que valdría la pena rellenar.

Convertir el wiki en un asistente de IA no es un proyecto de una sola vez, es un proceso vivo: exportar, estructurar, mantener fresco, controlar accesos y medir adopción son las cinco piezas que marcan la diferencia entre un experimento que nadie usa al segundo mes y una herramienta que de verdad ahorra tiempo a toda la empresa.