Base de conocimiento corporativa: el conocimiento más crítico de tu empresa no está en ningún sistema. Está en el hilo de correo del miércoles pasado y en la página de Notion que nadie actualiza desde febrero.
Base de conocimiento corporativa con agentes de IA. En este artículo: por qué el conocimiento crítico de tu empresa está atrapado en correos y wikis sin actualizar, qué arquitectura lo resuelve y cómo un equipo de RRHH redujo el onboarding de 11 semanas a 3,5 sin contratar a nadie nuevo.
El síntoma que todo equipo ignora hasta que duele
Ficticia People es una consultora que crece anualmente a doble dígito. Cuenta con 85 personas y una rotación anual en el equipo comercial del 34%. Cada vez que alguien nuevo entra, el proceso es el mismo: dos semanas con el manual de bienvenida que nadie ha tocado desde 2022, tres semanas preguntando a compañeros que ya están ocupados y otros dos meses hasta que realmente entienden cómo funciona la empresa por dentro.
El coste no está en los salarios de ese período. Está en lo que esa persona no produce, en el tiempo que los compañeros pierden respondiendo las mismas preguntas cada vez, y en los errores que comete porque nadie le explicó que ese proceso cambió en octubre. Siete semanas de onboarding efectivo a 3.500€/mes de coste salarial son más de 6.000€ por contratación. Con 12 entradas al año, el número supera los 70.000€ anuales solo en productividad perdida.
El problema de fondo no es que RRHH haga mal su trabajo. Es que el conocimiento que necesita un nuevo empleado está atrapado en tres lugares que no hablan entre sí: los correos donde se tomaron las decisiones, las páginas de Notion donde alguien lo documentó a medias y la memoria de las personas que llevan más tiempo.
Analogía
Imagina una biblioteca donde cada libro está escrito en el idioma de quien lo escribió, no hay catálogo, y el único índice es la memoria del bibliotecario más antiguo. Cuando ese bibliotecario se va, la biblioteca no desaparece — pero es prácticamente inaccesible. Eso es lo que le ocurre al conocimiento en la mayoría de empresas: existe, pero no está organizado para que nadie más pueda encontrarlo.
Este es el punto de partida antes de hablar de agentes de IA o de arquitecturas de datos. Sin resolver dónde vive el conocimiento y cómo se estructura, cualquier tecnología que montes encima va a amplificar el caos, no a reducirlo.
Por qué el agente de IA sin contexto es más peligroso que no tener agente
La respuesta natural cuando el problema de onboarding se vuelve costoso es integrar un chatbot o un agente de IA. El razonamiento es comprensible: si el nuevo empleado puede preguntar a un sistema en lugar de interrumpir a sus compañeros, el problema se resuelve. Pero hay un detalle que cambia todo: un LLM sin base de conocimiento corporativa responde con lo que sabe en general, no con lo que es verdad en tu empresa.
Pregunta al agente cuántos días de vacaciones tiene el equipo comercial. Si la política cambió el año pasado y nadie lo documentó de forma que el modelo pueda acceder, el agente va a responder con una estimación razonable basada en estándares del sector. Lo va a hacer con la misma seguridad que si supiera la respuesta correcta. El riesgo no es la ignorancia — es la confianza con la que se expresa esa ignorancia.
El problema real
Un LLM sin contexto propio no dice "no sé". Dice algo plausible. En un contexto de onboarding, donde el nuevo empleado no tiene forma de distinguir lo correcto de lo incorrecto, eso es exactamente lo que no necesitas. Un agente mal alimentado no ahorra preguntas — genera respuestas incorrectas que alguien tendrá que corregir después.
La solución no es un modelo más potente. Es una arquitectura que le dé al modelo el contexto correcto en el momento en que lo necesita. Eso es exactamente lo que hace una base de conocimiento corporativa bien construida: convierte documentos dispersos en contexto recuperable, estructurado y actualizable.
Paso previo
Antes de construir cualquier agente, el conocimiento tiene que estar centralizado. Si tus datos siguen dispersos entre herramientas sin conexión, empieza aquí: Cómo centralizar los datos de tu empresa sin equipo técnico →
La arquitectura: de documentos dispersos a memoria institucional
Una base de conocimiento corporativa no es un repositorio de documentos. Es un sistema de recuperación de contexto relevante en el momento adecuado. Un repositorio te devuelve documentos completos cuando los buscas. Una base de conocimiento con RAG te devuelve los fragmentos específicos que responden a tu pregunta, con el contexto suficiente para que el modelo los use correctamente.
RAG son las siglas de Retrieval-Augmented Generation. El principio es simple: antes de que el modelo genere una respuesta, el sistema recupera los fragmentos más relevantes de tu base de conocimiento y los incluye como contexto en el prompt. El modelo no adivina — lee lo que tú le das y responde en base a eso.
Pipeline completo: de fuentes dispersas a respuesta contextualizada por perfil de usuario.
El flujo tiene cuatro etapas. Primero, la extracción: los documentos salen de sus fuentes originales a través de sus APIs. Segundo, el procesamiento: cada documento se divide en fragmentos semánticos con metadatos que indican de qué área es, quién lo escribió, cuándo y qué rol debería poder leerlo. Tercero, el embedding: cada fragmento se convierte en un vector numérico que representa su significado. Cuarto, el retrieval: cuando alguien hace una pregunta, el sistema convierte esa pregunta en un vector, busca los fragmentos más similares y los entrega al modelo como contexto.
Distinción clave para el CTO
La diferencia entre buscar en Google Drive y consultar un vector store no es de velocidad — es de comprensión semántica. Google Drive busca palabras exactas. El vector store entiende que "política de bajas" y "procedimiento de ausencias" son la misma pregunta. Eso es lo que hace que el agente encuentre contexto aunque nadie haya etiquetado los documentos correctamente.
Lectura relacionada
Si tu empresa todavía no tiene una arquitectura de datos mínima en la que apoyar este pipeline, el punto de partida está aquí: Arquitectura de datos para pymes: el stack mínimo viable →
El diferencial: onboarding ajustado al perfil de quien entra
Una base de conocimiento que devuelve los mismos documentos a todo el mundo no resuelve el problema de Ficticia People. Un SDR que entra en ventas no necesita leer las convenciones de código del equipo de ingeniería. Un nuevo director de operaciones no necesita el playbook de objeciones comerciales en la semana uno. El onboarding genérico es el origen del problema — no tiene sentido repetirlo en formato digital.
La solución técnica es el metadata filtering en el retrieval. Cuando se ingesta cada fragmento de documento, se le asigna metadata estructurada: area (ventas, ingeniería, ops, rrhh), rol_minimo (ic, manager, director), tipo (política, proceso, decisión, referencia) y fecha_actualizacion. Cuando el agente recibe una consulta, no busca en toda la base — busca solo en los fragmentos que corresponden al perfil del usuario que pregunta.
El resultado es un onboarding que parece diseñado a mano pero se genera automáticamente. El agente que responde a un nuevo SDR recupera contexto de ventas, objeciones frecuentes de clientes, el proceso de cualificación y las políticas de comisiones. El que responde a un ingeniero nuevo recupera las decisiones de arquitectura registradas, las guías de estilo de código y los postmortems de los últimos seis meses. Misma infraestructura, experiencia completamente distinta.
Analogía
Es como un hotel que tiene toda la información de la ciudad en su sistema pero solo te muestra los restaurantes abiertos a la hora que preguntas, en el barrio donde estás, con el rango de precio que encaja con tu perfil. No filtra porque no confíe en ti — filtra porque darte 4.000 opciones no es útil. El agente hace lo mismo con el conocimiento corporativo.
Cómo funciona: de Notion y Outlook al vector store en tres bloques
El pipeline completo tiene tres bloques con responsabilidades completamente independientes. Cada uno hace una sola cosa, puede validarse por separado y falla de forma aislada si algo va mal. Esa separación es la que hace el sistema mantenible sin un equipo de ingeniería dedicado.
Bloque 1 — Extracción: cada fuente habla su API; la normalización convierte todo al mismo formato de salida.
Bloque 1 — Extracción de fuentes. Cada herramienta expone una API que permite leer su contenido de forma programática. Notion devuelve páginas y bloques en JSON estructurado. Outlook, a través de Microsoft Graph, devuelve correos con asunto, cuerpo y metadatos del remitente. Ambas fuentes producen el mismo formato de salida: texto plano más metadatos mínimos (fuente, área, fecha, título). Ese formato común es el que permite tratar todos los documentos igual en el bloque siguiente.
Bloque 2 — Del texto al vector: cada fragmento entra en Chroma con su significado numérico y sus metadatos de filtrado.
Bloque 2 — Chunking, embedding e ingesta. Cada documento se divide en fragmentos de entre 400 y 600 tokens con solapamiento parcial para no perder contexto en los bordes de corte. Cada fragmento se convierte en un vector numérico de 1.536 dimensiones que representa su significado semántico. Ese vector, junto con los metadatos de área y rol que viajan adjuntos, se almacena en Chroma. El metadato de rol es el que hace posible el filtrado posterior: cada fragmento sabe para quién es visible antes de que nadie lo consulte.
Bloque 3 — Query con perfil: la pregunta activa el filtro antes del retrieval. El LLM solo ve lo que el usuario puede ver.
Bloque 3 — Query con filtro de perfil. Cuando un usuario hace una pregunta, el sistema la convierte en un vector. Antes de buscar en toda la base, aplica los filtros de área y rol del usuario. Los fragmentos recuperados se entregan al LLM como contexto. El modelo responde solo con lo que hay en ese contexto — si la información no está, lo dice.
Por qué el filtro va antes del retrieval, no después
Filtrar los resultados después de recuperarlos es un error de diseño habitual. Si primero recuperas los 20 fragmentos más similares y luego descartas los que no corresponden al perfil del usuario, reduces el contexto de forma aleatoria. Aplicar el filtro antes garantiza que los 5 fragmentos que llegan al modelo son los 5 más relevantes dentro del universo de documentos que esa persona puede ver. La diferencia en calidad de respuesta es significativa.
Caso: Ficticia People
Ficticia People entra con un problema concreto y cuantificable: cada nueva incorporación en el equipo comercial tarda una media de once semanas hasta alcanzar productividad plena. Con 12 incorporaciones al año y un coste salarial medio de 3.800€/mes, el coste de ese período de rampa supera los 100.000€ anuales en productividad no generada. El equipo de RRHH, compuesto por dos personas, dedicaba el 40% de su tiempo a responder preguntas de onboarding que se repetían en cada ciclo.
La situación inicial: 3.200 correos en el buzón de RRHH con políticas, decisiones y respuestas a preguntas frecuentes. 180 páginas en Notion, de las cuales el 60% no se había actualizado en más de seis meses. Cero estructura que permitiera a un sistema externo acceder a ese conocimiento de forma fiable.
Semana 1 — Auditoría y estructura de metadatos
Antes de extraer nada: definir el esquema de metadatos. Qué áreas existen, qué roles hay y qué tipos de documento se van a ingestar. Esta decisión es irreversible sin reingestar todo — es la más importante de todo el proyecto. Resultado: 4 áreas, 3 niveles de rol, 5 tipos de documento (política, proceso, FAQ, decisión, referencia).
Semana 2 — Ingesta y primera validación
Pipeline de extracción ejecutado sobre las 180 páginas de Notion y los 3.200 correos filtrados por carpetas de RRHH. Resultado: 4.847 fragmentos en Chroma. Validación manual de 50 queries representativas para verificar que el retrieval devuelve los fragmentos correctos antes de conectar el LLM.
Semana 3 — Integración y despliegue
Agente desplegado como API en Google Cloud Run. Integrado en Slack como slash command (/conocimiento) y en el portal de bienvenida de nuevos empleados. Actualización automática de la base cada 24 horas vía cron job que ejecuta el pipeline de ingesta incremental.
Semanas de onboarding
11→3.5
Productividad plena en menos de un mes
Preguntas repetidas en Slack
−71%
Medido a 90 días de implantación
Tiempo RRHH en onboarding
−58%
De 40% a 17% del tiempo del equipo
Coste infraestructura
~160€/mes
Cloud Run + Chroma + embeddings API
El hallazgo que no esperaban
Al auditar las páginas de Notion antes de ingestarlas, descubrieron que el 34% contenía información contradictoria o desactualizada. La base de conocimiento no solo resolvió el problema del agente — forzó a la empresa a limpiar su documentación interna por primera vez en tres años. La arquitectura reveló el problema que nadie había visto porque nadie lo había intentado centralizar.
Framework de decisión: cuándo tiene sentido construir esto
No todas las empresas necesitan un sistema completo de ingesta, procesado y almacenamiento de los datos corporativos que trabaje de forma autónoma. Hay situaciones donde una wiki bien mantenida en Notion o Confluence es suficiente — y es honesto decirlo antes de proponer una arquitectura más compleja. El criterio de decisión se reduce a tres variables: el volumen de documentación no estructurada, la frecuencia de rotación o incorporación, y si el conocimiento que necesitas vive en comunicaciones no formales como correos, hilos de Slack o decisiones tomadas en reuniones. Si es lo tercero, ninguna wiki estática lo va a capturar.
Framework — ¿Tiene sentido para tu empresa?
¿Tienes más de 50 personas o rotación activa?
No → Una wiki bien mantenida es suficiente. No necesitas la complejidad de un vector store todavía.
¿El conocimiento crítico vive en correos y chats?
Sí → Ninguna wiki estática lo captura. Ese conocimiento se pierde cada vez que alguien se va. Este es tu caso.
¿Ya tienes documentación mínima en Notion o similar?
No → El primer paso es auditar y estructurar lo que existe. Sin material de partida, no hay base de conocimiento que construir.
¿Puedes definir el esquema de metadatos (áreas, roles, tipos)?
Sí → Estás listo. Esa decisión es la más importante de todo el proyecto y es la única que no se puede cambiar sin reingestar todo.
¿Los cuatro puntos anteriores están resueltos?
Sí → El pipeline técnico es el paso más corto de los cuatro. En tres semanas tienes el sistema operativo. Lo difícil ya está hecho.
La pregunta con la que me gustaría que te quedaras es esta: ¿cuánto conocimiento crítico de tu empresa solo existe en la memoria de las personas que llevan más tiempo, y qué pasa con ese conocimiento la próxima vez que alguien decida irse?
¿Te ha resultado útil?
¿Tienes un problema que
los datos podrían resolver?
Sin formularios largos. Una conversación de 30 minutos para ver si tiene sentido.
Hablamos