Cómo conectar un LLM con la información de mi empresa (y con qué no conectarlo)

El asistente respondió seguro, y estaba citando un documento muerto

Un vendedor le pregunta al asistente interno cuál es el descuento máximo que puede ofrecer a un cliente corporativo. El sistema responde de inmediato, con el mismo tono seguro de siempre, y cita el tope que aparece en el documento de política comercial. El vendedor cierra el trato con ese número. Días después, finanzas descubre que esa política cambió hace meses, el tope real es distinto, y el documento viejo seguía en la carpeta compartida porque nadie lo borró ni lo marcó como vencido. El LLM no mintió: repitió lo que encontró, con la misma convicción con la que hubiera repetido el dato correcto.

Esto se repite en cualquier empresa que conecta un LLM a su información sin antes decidir qué información merece estar ahí. El equipo sube la carpeta completa (manuales, actas de reunión, contratos vencidos, capacitaciones de hace tres años, borradores que nunca se aprobaron) porque conectar “todo” parece más simple que decidir “esto sí, esto no”. Técnicamente funciona: el modelo indexa cualquier documento que le den, con la misma mecánica de RAG, sin distinguir si el contenido sigue vigente. El problema aparece después, cuando alguien toma una decisión real con una respuesta que sonaba exactamente igual de confiable estuviera basada en el documento correcto o en el que caducó hace un año.

Conectar la información no es la parte difícil: decidir cuál lo es

La primera reacción frente a un caso así suele ser técnica: mejorar el buscador interno, ajustar los parámetros de recuperación, probar con otro modelo. Ninguna de esas correcciones resuelve el problema real, porque el problema real nunca estuvo en la tubería que conecta el LLM con los documentos de la empresa. Está en qué documentos decidiste que formaran parte de esa tubería, y en que nadie volvió a revisar esa decisión desde el día en que se subieron.

Esto cambia por completo qué tipo de proyecto es este. No es un proyecto de infraestructura donde el entregable es “ya conectamos el LLM a nuestros documentos”. Es un proyecto editorial, con las mismas preguntas que enfrentaría un equipo armando la única fuente de verdad de la empresa: qué se publica, quién lo aprueba, cuándo caduca y quién responde si queda desactualizado. Ya cubrí varias de esas preguntas al explicar cómo implementar un LLM en una empresa; acá me detengo en la que casi siempre se salta: el criterio de selección del contenido mismo.

El criterio de qué documentos entran y cuáles no

No existe una lista universal de documentos “buenos” para conectar, porque depende del área y de la pregunta que la gente realmente hace. Pero sí hay un filtro que aplico antes de subir cualquier cosa, y que descarta más de lo que la gente espera:

• Vigente y con fecha de corte visible: si el documento no dice desde cuándo aplica y hasta cuándo es válido, no entra tal cual. Primero se le agrega esa fecha, o se descarta directamente.
• Con una sola versión autorizada: si existen varias copias del mismo procedimiento en carpetas distintas y se contradicen entre sí, ninguna entra hasta que alguien decida cuál es la real y archive las otras.
• Con dueño identificable: alguien con nombre y apellido responde por ese documento si el LLM lo cita mal. Sin dueño, no hay a quién reclamarle cuando el contenido envejece.
• Relevante para una pregunta que de verdad se repite: un documento que nadie consulta en la vida real no aporta nada por estar ahí, solo aumenta la probabilidad de que el modelo lo mezcle con otro.
• Verificable hasta la fuente original: se puede rastrear de dónde salió el dato, para que alguien lo confirme antes de actuar sobre una respuesta importante.

Lo que casi nunca debería entrar, aunque esté a la mano: borradores sin aprobar, notas personales, correos sueltos, propuestas comerciales de un cliente específico, actas de reuniones sin conclusión formal. Es información real, pero no es información con la que la empresa quiere que un sistema le hable a un cliente o a un empleado con la misma seguridad que si fuera política oficial. Ese filtro es, en el fondo, el mismo trabajo detrás de construir una memoria organizacional confiable: no junta todo lo que existe, junta lo que la empresa está dispuesta a sostener como cierto.

Por qué la información desactualizada es peor que la ausente

Cuando al LLM le falta información, lo peor que puede pasar es que lo diga: “no tengo ese dato” o “no encontré nada sobre esto en los documentos disponibles”. Es una respuesta incómoda, pero honesta, y cualquier persona sabe qué hacer con ella: preguntarle a alguien más, buscar en otro lado, o esperar. El vacío se nota, y por eso mismo se corrige rápido.

La información desactualizada no se nota. El modelo no sabe que el documento que está citando venció, porque nada en el archivo se lo dice: para el sistema, un documento de hace tres años y uno de esta semana pesan exactamente igual si ambos están en la base. La respuesta sale con la misma seguridad, el mismo tono, la misma cita formal a “la política de la empresa”. Quien la recibe no tiene forma de distinguir, desde afuera, si está frente al dato vigente o al fantasma de uno que ya no existe. Y como el error viene envuelto en la autoridad del sistema, se repite y se propaga antes de que alguien lo cuestione.

Esta es la razón por la que evaluar si un LLM “responde bien” no puede limitarse a revisar si la respuesta suena coherente. Ya expliqué en cómo evaluar un modelo de lenguaje en tu empresa que la fluidez del texto no dice nada sobre si el contenido detrás está vivo o muerto: un modelo mal conectado puede sonar perfecto y estar completamente equivocado.

Quién decide qué entra y quién mantiene la fuente

La pregunta “¿quién decide qué documento entra?” casi nunca tiene dueño claro, y esa ausencia es la raíz de la mayoría de bases de conocimiento desordenadas. El equipo técnico puede conectar cualquier fuente que le indiquen, pero no tiene forma de saber si el manual de recursos humanos de la carpeta compartida es el vigente o el de la reorganización anterior. Esa decisión le corresponde al área dueña del contenido, no a quien construye la tubería técnica.

Dos roles que no conviene fusionar en uno solo

• El dueño del contenido: la persona del área (recursos humanos, comercial, legal, operaciones) que aprueba qué versión es la oficial y cuándo un documento deja de aplicar. Sin esa firma, ningún documento debería entrar a la base.
• El curador de la base: quien revisa periódicamente que lo conectado siga vigente, retira lo vencido y avisa al dueño cuando algo necesita actualizarse. No decide el contenido, cuida que el contenido ya decidido siga siendo cierto.

Sin este reparto claro, la base tiende a acumular todo lo que alguien subió alguna vez, porque nadie tiene el mandato explícito de sacar nada. El equipo técnico no debería cargar con esa responsabilidad editorial, y el área de negocio tampoco puede delegarla completa asumiendo que “ya quedó conectado, entonces ya quedó resuelto”.

El proceso mínimo de curaduría antes de conectar cualquier documento

No hace falta un comité editorial de meses para ordenar esto. El proceso mínimo que le pido a un equipo antes de conectar cualquier fuente al LLM tiene cinco pasos, y ninguno requiere una herramienta especial:

• Inventariar lo que existe: listar todo lo que hoy vive en carpetas, wikis y unidades compartidas, sin filtrar todavía. El objetivo es ver el desorden completo antes de decidir qué se salva.
• Clasificar en tres montones: vigente, vencido y dudoso. Lo dudoso, donde nadie sabe con certeza si sigue aplicando, no se conecta hasta que alguien lo confirme.
• Eliminar duplicados y quedarse con una sola versión: si hay varias copias del mismo procedimiento, se archivan las demás y se deja una, con su dueño asignado.
• Etiquetar cada documento con fecha y dueño: sin esos dos datos visibles, nadie (ni una persona ni el sistema) puede saber si sigue siendo cierto.
• Conectar solo lo que pasó los cuatro pasos anteriores: la conexión técnica es el último paso del proceso, no el primero.

Este orden invierte el instinto natural, que es conectar primero y ordenar después “si hace falta”. En la práctica casi nunca se ordena después: la base crece, la revisión se pospone, y el desorden inicial se vuelve permanente porque el sistema ya está en producción y nadie quiere tocarlo. Desarrollo este mismo orden con más detalle en cómo crear una base de conocimiento con IA para tu empresa, con el paso a paso de cada etapa.

Cómo se detecta que el LLM está citando algo viejo

Nada dentro del sistema avisa solo cuando una fuente envejeció; hay que construir esa señal a propósito. Las prácticas que de verdad funcionan son simples y ninguna depende de usar un modelo más nuevo:

• Obligar al modelo a citar fuente y fecha en cada respuesta: si la respuesta no muestra de qué documento salió y cuándo se actualizó ese documento, no se puede verificar, y lo que no se puede verificar no debería usarse para decidir.
• Auditorías por muestreo: revisar cada cierto tiempo un grupo de respuestas reales contra la fuente vigente, en lugar de confiar en que “si suena bien, está bien”.
• Un canal simple para marcar una respuesta como incorrecta: la señal más barata de una base desactualizada no es una auditoría, es un empleado o un cliente reportando que algo no cuadra, siempre que exista dónde reportarlo.
• Revisar qué documentos se citan con más frecuencia: si uno aparece mucho en las respuestas, merece revisión prioritaria, porque un error ahí se multiplica por cada persona que lo recibe.

Ninguna de estas prácticas es una función que se compra ni un ajuste que se activa una sola vez. Es una rutina, y como toda rutina, funciona solo si alguien la tiene asignada como parte de su trabajo y no como una tarea pendiente para “cuando haya tiempo”.

El mantenimiento de la base no termina el día que se conecta

Conectar la base es el evento visible, el que se presenta en una reunión como “ya tenemos IA con nuestra información”. El mantenimiento es el trabajo invisible que decide si esa frase sigue siendo cierta meses después. Cada documento que entra debería llevar, además del dueño y la fecha, una cadencia de revisión: más seguido para lo que cambia rápido, como precios o disponibilidad, y más espaciada para lo que cambia poco, como políticas estructurales o procesos regulatorios.

Mantener la base no es solo retirar lo vencido; es igual de importante meter lo nuevo apenas una decisión cambia, y no meses después, cuando alguien nota que el sistema sigue respondiendo con la regla anterior. Esto también conecta con cómo el LLM se integra con el resto de los sistemas de la empresa: si el dato real vive en el ERP o el CRM y el documento conectado al LLM es una copia estática que alguien actualiza a mano de vez en cuando, el desfase entre ambos es cuestión de tiempo, no de si va a pasar. Ya desarrollé ese cruce en cómo integrar la IA con los sistemas de la empresa.

La pregunta que debería hacerse tu equipo antes de conectar nada

La pregunta que de verdad importa nunca fue “¿cómo conectamos el LLM con nuestra información?”. Esa parte, hoy, la resuelve cualquier proveedor en cuestión de días. La pregunta que sostiene todo lo demás es distinta y ninguna herramienta la resuelve sola: qué de lo que la empresa tiene merece hablar en su nombre, y quién responde si eso que dijo ya no es cierto.

Las empresas que hacen bien esto no son las que tienen la base más grande ni el modelo más nuevo: son las que tratan cada documento conectado como una declaración pública de la empresa, con dueño y fecha de vencimiento, igual que tratarían un comunicado de prensa. Las que lo hacen mal no tienen un problema de tecnología, tienen un problema de criterio, y ningún proveedor se los resuelve por ellas. Ese criterio, más que cualquier configuración, es lo que separa a una empresa que aplica el framework Arquitectura IA de una que solo instaló un chatbot con acceso a su carpeta compartida.