Toda la información de tu empresa, accesible para cualquier empleado en 2 segundos desde Slack.
¿Tienes prisa? No te leas el artículo. Si sabes usar n8n, cópialo tú mismo en vuestros servidores.
El problema: tu documentación existe, pero nadie la encuentra
Casi todas las empresas con las que trabajamos tienen el mismo patrón. La documentación interna existe: políticas de vacaciones, manuales de onboarding, procesos de compras, guías de seguridad. Vive en Notion, en Google Drive, en algún wiki que alguien montó con buena intención. Y aun así, las mismas preguntas se repiten cada semana en Slack: cuántos días de vacaciones tengo, cómo pido un portátil, qué hago si pierdo el móvil de empresa.
El coste no es solo el tiempo de quien pregunta. Es el de quien responde: normalmente las dos o tres personas de People, IT u Operaciones que actúan como buscadores humanos de la organización. Cada interrupción es un cambio de contexto, y la información que entregan de memoria no siempre coincide con la versión vigente del documento.
El buscador nativo de estas herramientas no resuelve el problema porque exige saber qué palabras exactas usó quien escribió el documento. Un empleado que pregunta "he perdido el portátil, ¿qué hago?" no encontrará una página titulada "Guía de seguridad y accesos". La búsqueda por palabra clave falla justo donde más se necesita: cuando la pregunta y el documento no comparten vocabulario.
Lo que sigue es la receta completa del workflow que resuelve esto. No una descripción a alto nivel: el paso a paso con las decisiones técnicas justificadas, el prompt exacto de producción y el JSON para que lo importes en tu n8n esta misma tarde.
La arquitectura: RAG sobre tu propia documentación
El sistema es una implementación de RAG (Retrieval-Augmented Generation) con dos ramas independientes dentro de un mismo workflow de n8n:
Rama 1, la ingesta. Cada noche, el workflow lee todas las páginas de la base de datos de Notion donde vive la documentación, extrae su contenido en texto, lo trocea en fragmentos y lo convierte en vectores numéricos (embeddings) que se almacenan en una base de datos vectorial: Pinecone en nuestra versión, aunque Qdrant o Supabase con pgvector funcionan con cambios mínimos.
Rama 2, el bot. Cuando un empleado escribe en un canal específico de Slack, un agente de IA convierte la pregunta en un vector, busca los fragmentos más parecidos semánticamente en la base vectorial, redacta una respuesta usando solo ese contexto y la publica en el hilo del mensaje, citando el documento de Notion de origen con enlace directo.
La palabra clave es "semánticamente". Los embeddings capturan significado, no palabras. "He perdido el portátil" y "en caso de robo o extravío de dispositivos corporativos" quedan cerca en el espacio vectorial aunque no compartan ni un término. Ese es el salto cualitativo frente al buscador de Notion.
La segunda decisión de diseño importante: el bot cita siempre la fuente. Cada respuesta termina con un enlace a la página exacta de Notion de donde salió la información. Esto convierte al bot de oráculo opaco en índice verificable, y es lo que hace que el equipo confíe en él.
El paso a paso, sin omitir nada
1. La sincronización nocturna. Un Schedule Trigger ejecuta la ingesta a las 02:00, cuando nadie pregunta y el equipo ya terminó de editar documentación. Un nodo de Notion recupera todas las páginas de la database de la Knowledge Base, y un segundo nodo de Notion descarga los bloques de contenido de cada página, incluyendo los anidados. Requisito previo que cuesta una tarde a quien no lo sabe: la integración de Notion no ve ninguna página por defecto; hay que compartir la database con ella explícitamente desde el menú de conexiones.
2. La preparación de documentos. Un nodo Code agrupa los bloques por página y construye un documento por cada una, adjuntando metadatos: título, URL de Notion y fecha de última edición. Estos metadatos son la pieza más importante del sistema, porque son los que después permiten citar la fuente exacta. Un pipeline RAG sin metadatos de origen produce respuestas imposibles de auditar.
3. Troceado y vectorización. Un text splitter recursivo divide cada documento en fragmentos de 1.000 caracteres con 200 de solapamiento. Probamos 500 y el modelo perdía contexto en manuales largos; con 2.000, las respuestas arrastraban contenido irrelevante. Los fragmentos se vectorizan con text-embedding-3-small de OpenAI (dimensión 1536, coste marginal) y se insertan en un namespace dedicado del índice de Pinecone. Vaciamos el namespace en cada sincronización: preferimos reconstruir el índice cada noche a arrastrar fragmentos de documentos ya borrados. La sincronización incremental es una optimización que solo compensa con volúmenes grandes.
4. El disparador del bot. Un Slack Trigger escucha los mensajes de un único canal designado, por ejemplo #ayuda-kb. Restringirlo a un canal es una decisión deliberada: un bot que opina en todas las conversaciones de la empresa es un bot que acaba silenciado.
5. El nodo más importante del workflow. Un IF descarta cualquier mensaje que tenga bot_id o subtype. Sin este filtro, el bot lee su propia respuesta como si fuera una pregunta nueva y entra en un bucle infinito de autorespuestas. Es el error clásico de esta arquitectura y el primero que hay que prevenir. Relacionado: la credencial de Slack debe usar el token de bot (xoxb), no el de usuario (xoxp); con el token de usuario las respuestas salen publicadas a tu nombre y, además, pueden no llevar bot_id, debilitando este mismo filtro.
6. El agente y su herramienta. Un AI Agent recibe la pregunta con GPT-4o a temperatura 0.2 como modelo. La base vectorial se le conecta como herramienta en modo retrieve-as-tool con topK 5: con 3 fragmentos se dejaba información fuera, con 10 el contexto se llenaba de ruido. Detalle que no da error pero rompe todo en silencio: el modelo de embeddings de la consulta debe ser exactamente el mismo que el de la ingesta. Si difieren, la búsqueda devuelve resultados malos sin ningún aviso.
7. El prompt. Transparencia completa: este es el system prompt que usamos en el agente, tal cual está en producción.
Eres el asistente de la Knowledge Base interna de la empresa. Tu única
fuente de verdad es la herramienta `knowledge_base`, que busca en la
documentación interna vectorizada (Notion: manuales de onboarding,
procesos, políticas, guías).
Reglas:
1. SIEMPRE usa la herramienta `knowledge_base` antes de responder.
Nunca respondas de memoria.
2. Responde en el mismo idioma de la pregunta, de forma clara y concisa.
3. CITA SIEMPRE la fuente exacta: cada resultado de la herramienta
incluye metadatos `source_title` y `source_url`. Termina tu respuesta
con una sección `Fuentes:` listando cada documento usado como enlace
de Slack con formato <URL|Título>.
4. Si la información no aparece en la base de conocimiento, dilo
honestamente: "No he encontrado esto en la documentación interna"
y sugiere a quién podría preguntar. NO inventes respuestas.
5. Formatea para Slack: usa *negrita*, listas con viñetas y bloques de
código cuando aplique. No uses Markdown de encabezados (#).
6. Si la pregunta es ambigua, responde lo mejor posible con lo
encontrado e indica qué detalle ayudaría a afinar la búsqueda.
La regla 4 es la que separa un asistente útil de un generador de problemas. Un bot interno que inventa una política de gastos es peor que no tener bot. Prohibir responder de memoria y obligar a admitir la ignorancia son las dos instrucciones menos negociables del prompt.
8. La respuesta. El agente publica en el hilo del mensaje original, nunca en el canal principal. El canal se mantiene legible y cada pregunta queda con su respuesta y sus fuentes en un contexto autocontenido.
Qué más se puede conectar
La misma arquitectura admite fuentes adicionales sin tocar la rama del bot. Para Google Drive, se duplica la rama de ingesta con el nodo de Drive y un extractor de texto apuntando al mismo índice vectorial. Manuales de onboarding en PDF, actas de reuniones, documentación técnica: todo lo que se convierta en texto con una URL de origen puede entrar en la base de conocimiento. El agente no distingue de dónde vino cada fragmento; solo ve texto y metadatos.
También funciona en la dirección opuesta: el mismo patrón de agente con herramienta de búsqueda vectorial sirve para soporte a clientes sobre documentación de producto, para que el equipo comercial consulte especificaciones técnicas, o como capa de consulta sobre el ERP si se vectoriza la documentación de procesos.
Beneficios que se pueden medir
No vamos a prometer porcentajes inventados. Lo que sí se puede medir en tu propia organización, antes y después:
- Volumen de preguntas repetitivas que llegan a People, IT y Operaciones por mensaje directo, y cuántas absorbe el canal del bot.
- Tiempo de primera respuesta: de minutos u horas dependiendo de la disponibilidad de una persona, a segundos.
- Trazabilidad: cada respuesta enlaza al documento vigente, lo que elimina la deriva entre "lo que se responde de memoria" y "lo que dice la política actual".
- Detección de huecos: las preguntas que el bot no puede responder son una lista priorizada de la documentación que falta por escribir. Es el efecto secundario más valioso del sistema.
- Escalabilidad del onboarding: cada persona nueva tiene un canal donde preguntar sin la fricción de interrumpir a nadie.
Riesgos y consideraciones antes de ponerlo en producción
Seguridad y alcance del índice. Todo lo que se vectoriza queda accesible para cualquiera con acceso al canal. No indexes documentación con información salarial, datos personales o material restringido, o segmenta por namespaces con canales separados por nivel de acceso. Revisa también qué proveedor procesa los textos: los fragmentos viajan a la API del modelo de embeddings y del LLM.
Calidad de datos. El bot es tan bueno como la documentación que indexa. Páginas obsoletas producen respuestas obsoletas con total seguridad en el tono. La sincronización nocturna con reconstrucción completa mitiga el problema, pero no sustituye la revisión periódica del contenido.
Supervisión humana. Las primeras semanas conviene que alguien del equipo revise las respuestas en el canal. El prompt reduce las alucinaciones, no las elimina: es un sistema probabilístico y hay que tratarlo como tal.
Mantenimiento y dependencias. El sistema depende de cuatro servicios externos: Notion, Slack, OpenAI y la base vectorial. Cualquier cambio de API o de esquema en Notion (algo tan simple como renombrar la propiedad del título) puede degradar la ingesta. Presupuesta mantenimiento, no solo construcción.
Coste operativo. Con una KB de tamaño típico, el coste dominante es el LLM de las respuestas, no los embeddings. Merece la pena monitorizar consumo por pregunta antes de abrir el canal a toda la empresa.
Ahora es tuyo
El JSON descargable contiene el workflow completo: las dos ramas, el filtro anti-bucle, el prompt y las anotaciones de configuración en cada nodo. Si tienes un n8n operativo y una tarde libre, no nos necesitas.
Si prefieres que funcione a la primera, adaptado a tus fuentes reales, con la segmentación de permisos bien resuelta y sin descubrir los errores silenciosos por el camino, eso es exactamente lo que hacemos en DigitalCube.ai: automatización con IA sobre los sistemas que ya usas. Escríbenos y lo montamos contigo.