Cómo crear una base de conocimiento con IA: el proceso de un build real
Crear una base de conocimiento con IA es el proceso de centralizar la documentación de tu empresa y conectarla a un modelo de lenguaje para que cualquier persona del equipo pregunte en lenguaje natural y reciba la respuesta con la información real, citando la fuente. El proceso tiene 6 pasos: relevar dónde vive el conocimiento hoy, decidir la arquitectura, preparar el contenido, implementar sobre tu infraestructura, probar con consultas reales y traspasar la operación a tu equipo. Casi todas las guías sobre este tema son tutoriales de un vendor explicando cómo configurar su plataforma; esta cuenta el proceso como se vive en un proyecto real de construcción, con un caso en producción como columna vertebral.
Qué es una base de conocimiento con IA (y qué cambia respecto de una wiki)
Una base de conocimiento con IA es un sistema donde la documentación de la empresa (procesos, políticas, manuales, contratos) queda centralizada y conectada a un modelo de lenguaje que responde preguntas usando esos documentos como fuente. La diferencia con una wiki o un Drive ordenado es el modo de acceso: la wiki la buscás vos, navegando carpetas y adivinando en qué documento está la respuesta; a la base de conocimiento con IA le preguntás como le preguntarías a un compañero, y responde citando de qué documento salió la respuesta.
De la semana laboral de un trabajador de interacción se va en buscar información interna o rastrear al colega que puede ayudarlo, según el McKinsey Global Institute.
Es cuánto puede reducirse ese tiempo de búsqueda cuando el conocimiento de la empresa queda en un registro buscable, según el mismo estudio.
En la práctica, lo que vemos en empresas medianas es más simple de describir: las consultas internas dependen de que alguien sepa dónde está el documento correcto, y cuando esa persona no está, la operación espera. Si todavía estás evaluando si tu empresa necesita una, en la guía de base de conocimiento con IA para empresas cubrimos el qué y el para qué. Esta pieza asume que ya decidiste avanzar y se concentra en el cómo.
Antes de crear nada: las 2 decisiones que definen el proyecto
El error más caro no se comete cargando documentos, se comete antes: arrancar sin decidir dónde va a vivir el sistema ni cómo va a recuperar la información. Estas dos decisiones definen el costo, la privacidad y la vida útil del proyecto.
Decisión 1: ¿software SaaS o build sobre tu infraestructura?
| Criterio | SaaS de knowledge base | Build sobre tu infraestructura |
|---|---|---|
| Dónde queda tu data | En los servidores del proveedor | En tu propia nube (AWS, GCP, Azure) |
| Adaptación a tus procesos | La que permita el producto | Total: se diseña sobre tus fuentes y flujos |
| Costo | Suscripción mensual por usuario, para siempre | Proyecto una vez + mantenimiento acotado |
| Dependencia | Del roadmap y pricing del vendor | Del equipo propio (queda documentado) |
| Integración con tus sistemas | Conectores estándar | La que tu operación necesite |
El SaaS tiene sentido cuando el caso es soporte al cliente estándar y no hay restricciones sobre dónde queda la información. El build sobre infraestructura propia tiene sentido cuando la documentación es sensible (operaciones, legales, finanzas), cuando ya tenés nube contratada y equipo IT, o cuando el sistema tiene que integrarse con cómo trabaja tu empresa y no al revés. Nuestro trabajo está en el segundo escenario: en el caso de Ecuador, todo quedó desplegado sobre AWS, con la información de la empresa en su propia nube.
Decisión 2: ¿RAG o no?
RAG (retrieval-augmented generation, generación aumentada por recuperación) es la técnica donde el sistema primero busca los fragmentos relevantes de tus documentos y después el modelo redacta la respuesta usando solo esos fragmentos. Es lo que hace que el agente responda con tu información real en vez de inventar, y que pueda citar la fuente.
No todo proyecto lo necesita: con un volumen chico de documentos estables, pasarle el contexto directo al modelo alcanza y es más simple de mantener. El criterio corto: RAG se justifica cuando el volumen de documentación supera lo que un modelo puede leer por consulta, cuando el contenido cambia seguido o cuando necesitás trazabilidad de qué documento respaldó cada respuesta. El framework completo de esta decisión está en RAG para empresas: cuándo conviene y cuándo no.
Cómo crear una base de conocimiento con IA en 6 pasos
Estos pasos son las fases de un proyecto real de construcción, en el orden en que las ejecutamos. No son features de un software: son trabajo que alguien tiene que hacer, con o sin consultora.
Relevá dónde vive el conocimiento hoy
El primer paso es un mapa, no una herramienta. Antes de elegir tecnología hay que responder: qué documentos existen, dónde están (Drive, mails, Excel, PDFs, la cabeza de dos personas), cuáles están vigentes y quién es el dueño de cada tema. En el proyecto de Ecuador, el punto de partida era exactamente ese: documentación dispersa entre archivos, mails y personas, y consultas internas que dependían de que alguien supiera dónde estaba la información.
De este relevamiento sale el alcance real del proyecto. La regla que usamos: entra primero lo que el equipo pregunta más seguido, no lo que está más ordenado.
Decidí la arquitectura
Con el mapa de fuentes, se decide cómo se construye: RAG o contexto directo, en qué nube corre, qué modelo responde y por dónde consulta el equipo (un chat interno, WhatsApp, una app existente). Esta decisión se toma mirando el volumen y la sensibilidad de las fuentes relevadas, no al revés.
La arquitectura de referencia que usamos en producción: documentos en la nube del cliente, un índice de embeddings para la búsqueda semántica, recuperación de los fragmentos relevantes por consulta, y Claude redactando la respuesta con la obligación de citar la fuente interna. Es la arquitectura del caso de Ecuador: AWS, base de conocimiento con RAG, embeddings más recuperación, y Claude como capa conversacional.
Prepará el contenido
Acá se define la calidad de las respuestas. El agente responde tan bien como la peor versión del documento que le diste: si conviven tres versiones de la misma política, el sistema va a responder con alguna de las tres. Tres tareas concretas:
- Depurar: eliminar duplicados y versiones viejas; una sola versión vigente por tema.
- Completar: el conocimiento que vive en la cabeza de alguien se escribe ahora o el sistema nace incompleto.
- Fragmentar con metadatos: dividir los documentos en fragmentos recuperables y etiquetarlos (tema, área, vigencia).
Implementá sobre la infraestructura del cliente
Recién acá aparece el código. Se despliega el índice, se conecta el modelo, se implementa la interfaz de consulta y se configuran los accesos. El punto que diferencia un build serio de una demo: todo corre en la nube de la empresa, con su información adentro de su propio perímetro. En Ecuador eso fue AWS; el criterio es el mismo en cualquier nube que el cliente ya tenga contratada.
En esta fase también se fija el comportamiento del agente: responder solo con lo que está en la base, citar la fuente de cada respuesta y decir "no tengo esa información" cuando el documento no existe. Un agente que inventa respuestas con seguridad es peor que no tener agente.
Probá con consultas reales de usuarios reales
Ningún sistema de estos queda bien a la primera. La fase de prueba consiste en poner el agente frente a usuarios reales del equipo y ajustar con sus consultas: en el proyecto de Ecuador fue una fase propia del plan, ajuste con consultas reales antes del traspaso. Lo que se ajusta, en orden de frecuencia:
- Recuperación: la pregunta era buena pero el sistema trajo el fragmento equivocado; se ajusta la fragmentación o los metadatos.
- Huecos de contenido: la gente pregunta cosas que ningún documento responde; vuelve al paso 3.
- Tono y formato: respuestas demasiado largas, o que no citan la fuente como el equipo necesita.
Traspasá la operación al equipo
Una base de conocimiento que solo la consultora sabe operar es un problema futuro. El cierre del proyecto es documentación y traspaso: cómo se agrega un documento, cómo se corrige una respuesta mala, cómo se da de alta un usuario. En el caso de Ecuador, el sistema quedó documentado para que el equipo lo mantenga y lo amplíe sin depender de nosotros. Ese es el estándar: el sistema es del cliente, corre en su nube y su equipo lo opera.
El proceso en un caso real: la base de conocimiento de Acatha (Ecuador)
Acatha es una empresa de operaciones en Ecuador que llegó con el problema típico: procesos operativos manuales y documentación dispersa entre archivos y personas. Las consultas internas dependían de que alguien encontrara el documento correcto, y no había una fuente única de verdad sobre políticas y procesos.
El proyecto siguió las fases de esta guía, en una implementación por etapas: relevamiento de procesos y de la documentación a centralizar, automatización de los procesos repetitivos prioritarios, montaje de la base de conocimiento con IA sobre AWS, y ajuste con consultas reales más traspaso al equipo. El resultado en producción:
Las consultas internas se responden en lenguaje natural, a cualquier hora.
Salen de los documentos reales de la empresa, citando la fuente interna en vez de inventar.
Una sola fuente única para políticas y procesos, en vez de versiones dispersas.
Todo desplegado sobre AWS, con la información de la empresa en su perímetro, y el equipo lo mantiene sin depender de la consultora.
Qué mantiene viva una base de conocimiento (lo que ningún tutorial cuenta)
La mayoría de las guías terminan en "mantené el contenido actualizado" y ahí es exactamente donde los proyectos mueren. Una base de conocimiento se degrada sola: los procesos cambian, las políticas se actualizan, la gente que sabía se va. Tres prácticas concretas la mantienen viva:
Un dueño con nombre
No "el equipo": una persona responsable de que lo que entra a la base esté vigente. No necesita ser técnica; necesita saber a quién preguntarle por cada tema.
La actualización atada al proceso, no al calendario
Cuando cambia una política, actualizar la base es parte del cambio, no una tarea trimestral que se posterga.
Las preguntas sin respuesta como señal
Las consultas donde el agente respondió "no tengo esa información" son la lista de qué documentar el mes que viene.
La señal de alarma es una sola: el equipo vuelve a preguntar por chat lo que la base debería responder. Cuando eso pasa, el problema casi nunca es el modelo; es contenido viejo o incompleto.
Si te interesa el concepto detrás de esto, el conocimiento de la empresa operando como un sistema que responde solo, lo desarrollamos en el cerebro de la empresa con IA.
Construimos tu base de conocimiento sobre tu infraestructura
En Duotach construimos bases de conocimiento con IA para empresas de LATAM y España, sobre la nube del cliente y con el equipo del cliente operándolas al final del proyecto. Usamos Claude en producción todos los días; el caso de Ecuador de esta guía está en producción, no en un slide. Si tenés la documentación dispersa y querés ver cómo sería el proceso en tu empresa, agendá una llamada de 30 minutos: escuchamos el contexto, te decimos si tu caso amerita RAG o algo más simple, y te mandamos una propuesta cotizada por scope.
Preguntas Frecuentes
¿Qué es una base de conocimiento con IA?+
¿Qué necesito para crear una base de conocimiento con IA?+
¿Cuánto cuesta crear una base de conocimiento con IA?+
¿Conviene un software SaaS o un desarrollo a medida?+
¿Qué es RAG y lo necesito?+
¿Cuánto tarda implementar una base de conocimiento con IA?+
Artículos Relacionados
Base de conocimiento con IA para empresas: qué es y para qué sirve
Qué es una base de conocimiento con IA, qué problemas resuelve y cómo decidir si tu empresa necesita una.
RAG para empresas: cuándo conviene y cuándo no
Framework de decisión para saber si tu base de conocimiento necesita RAG o alcanza con algo más simple.
El cerebro de la empresa con IA
Qué pasa cuando el conocimiento de la empresa deja de vivir en carpetas y empieza a responder solo.