Chatbot con los documentos de tu empresa: respuestas con fuente y permisos por usuario

¿Qué significa realmente "chatear con tus documentos"?

El sistema lee tus documentos una vez, los corta en pasajes y guarda cada pasaje con una huella numérica de su significado (un embedding) en una base de datos. Cuando alguien pregunta algo, busca los pasajes más cercanos en significado, se los entrega a un modelo de lenguaje junto con la pregunta, y el modelo redacta una respuesta usando solo lo que recibió. Cada respuesta enlaza a los pasajes que usó, así el lector puede verificar. Eso es RAG, generación aumentada por recuperación.

Dos consecuencias. Primero, no hay entrenamiento: tus documentos no se meten en un modelo que después los recuerda. Quedan en una base de datos que controlas y se consultan en el momento de la pregunta, así que cuando actualizas un documento la siguiente respuesta lo refleja. Segundo, la calidad de las respuestas es sobre todo calidad de recuperación, no inteligencia del modelo. La mayor parte de la ingeniería está en encontrar el pasaje correcto.

¿Por qué un GPT personalizado o un chatbot de catálogo no alcanza para datos internos?

Un GPT personalizado, un proyecto en Claude o un widget de chatbot listo para usar sirve para probar si la idea es útil: subes veinte PDFs, preguntas, ves qué pasa. Se quedan cortos justo donde la información interna se pone delicada. Un solo conjunto de documentos para todos, así que la política de sueldos queda a la vista de cualquiera con el enlace. Desactualizados apenas alguien edita el archivo original, porque lo que subiste fue una copia. Casi nunca una cita. Y los documentos viven en los servidores de un proveedor bajo sus términos, algo que tu cliente más grande puede no aceptar.

Un asistente construido sobre una base de conocimiento resuelve cada punto por diseño: acceso filtrado por usuario antes de que el modelo vea algo, fuentes sincronizadas con una programación, una cita en cada respuesta, y el índice, los registros y las conversaciones en tu Postgres, en tu cuenta de nube, con tus llaves de API.

¿Qué entra en la base de conocimiento y cómo se mantiene al día?

La base de conocimiento es la entrega de verdad, y decidir qué entra toma la primera semana. Las fuentes habituales: la carpeta compartida o la biblioteca de SharePoint con manuales y procedimientos, los PDFs de políticas, el catálogo o la lista de precios, cotizaciones pasadas, el historial del helpdesk, y las preguntas frecuentes que tu mejor persona responde de memoria. No todo debe entrar: borradores, versiones reemplazadas y carpetas personales agregan ruido y producen respuestas contradictorias, así que el alcance se acuerda antes de partir.

La frescura es un conector más una programación. Cada fuente tiene un conector (Google Drive, Microsoft Graph para SharePoint, la API del helpdesk o del CRM, una base de datos) que trae lo nuevo y lo modificado cada hora o cada noche y saca lo que fue borrado. Cada documento conserva su versión y su fecha de modificación en el índice, así el asistente prefiere el procedimiento más nuevo por sobre el de 2021.

¿Quién puede ver qué? Permisos, datos personales y dónde vive la información

Los permisos se aplican al recuperar, no pidiéndole al modelo que guarde secretos. Cada pasaje lleva las reglas de acceso de su documento de origen (permisos de la carpeta, grupos de SharePoint, roles del directorio), y la búsqueda corre solo sobre lo que ese usuario puede leer, así que el modelo nunca ve un párrafo restringido. Un empleado nuevo ve el manual de inducción. Un gerente de finanzas ve además las reglas de precios. Un cliente en el widget público ve solo lo que decidiste publicar.

Los datos personales tienen su propio tratamiento. Los historiales de tickets y las cotizaciones pasadas contienen nombres, correos y teléfonos, y el valor por defecto más seguro es enmascararlos al indexar. Las conversaciones se registran para revisar calidad, con un período de retención que defines tú. Y todo eso, índice, registros y estado de sincronización, corre en tu cuenta de nube (Supabase, GCP, AWS o Railway), así que "dónde están nuestros datos" se responde en una oración.

¿Dónde vive el asistente: widget web, Slack, WhatsApp o el helpdesk?

La base de conocimiento es un solo servicio con una API; los lugares donde la gente le habla son clientes livianos encima. Para uso interno, lo más común es Slack (donde el personal nuevo ya pregunta) y una página web pequeña detrás de tu login. Para clientes, un widget en el sitio o un número de WhatsApp vía la Cloud API de Meta. Para equipos de soporte, el asistente vive dentro del helpdesk y redacta una respuesta que el agente aprueba, con la misma base de conocimiento.

Parte con un solo canal. El canal es la parte barata; la base de conocimiento, los permisos y el set de evaluación son la parte cara, y se comparten. Agregar un segundo canal después es cuestión de días, no un proyecto nuevo.

¿Cómo sabes que las respuestas son correctas?

Antes de que el asistente llegue a alguien, se corre contra un set de evaluación: entre cincuenta y algunos cientos de preguntas reales, cada una con la respuesta que daría una persona que sabe y el documento que debería citar. Cada cambio en prompts, corte de pasajes o recuperación se vuelve a correr contra ese set, así las mejoras se miden en vez de sentirse.

Tres comportamientos se diseñan, no se esperan. El asistente dice "eso no está en los documentos" cuando la recuperación vuelve débil, en vez de producir una adivinanza bien escrita; una respuesta segura y equivocada cuesta más que ninguna respuesta. Cada respuesta lleva citas. Y cada respuesta tiene un pulgar arriba o abajo que cae en una cola de revisión: los errores repetidos casi siempre apuntan a un documento que falta o está mal escrito, y arreglar la fuente mejora todas las respuestas futuras.

¿Cómo se ve la construcción, paso a paso?

La semana uno es alcance y fuentes. Acordamos la lista de fuentes y el modelo de permisos, conectamos los primeros conectores (la biblioteca de SharePoint, las carpetas de Drive, dos años de tickets resueltos) y recogemos las preguntas de evaluación. Los documentos se procesan, se parten en pasajes cortos, se convierten en embeddings y se guardan en Postgres con pgvector dentro de tu proyecto de Supabase o de tu nube, con reglas de acceso y metadatos de versión adjuntos.

La semana dos es el servicio de recuperación y el primer canal. Un servicio en Python y FastAPI expone un solo endpoint: entra la pregunta y la identidad del usuario, sale la respuesta con citas. Corre la búsqueda filtrada por permisos, llama al modelo (Claude, OpenAI o Gemini), aplica las barreras (responder solo desde los pasajes recuperados, rechazar cuando la recuperación es débil) y registra todo. La sincronización corre programada, en n8n o como cron, con reintentos y alertas cuando un conector falla.

La semana tres es evaluación y entrega. El asistente se corre contra el set de evaluación, se ajustan recuperación y prompts hasta que los errores que quedan son vacíos en los documentos, y un grupo piloto lo usa con el ciclo de retroalimentación activo. La entrega incluye el código y los flujos en tu repositorio, documentación y videos Loom de recorrido. Eres dueño del índice, del servicio, de los prompts y de los datos; nada corre en mis cuentas.

¿Cuánto cuesta un chatbot con documentos de tu empresa y cuándo conviene más una wiki?

La construcción de referencia es el AI Intake Agent más base de conocimiento, publicado a USD 4.900 como un solo precio fijo, con una operación mensual opcional de USD 1.200 (conectores, cola de retroalimentación, fuentes y canales nuevos). Un asistente interno sobre unas pocas fuentes con un canal cabe en ese alcance. Los alcances mayores (varios sistemas, cumplimiento estricto, un canal para clientes más uno interno) se cotizan a precio fijo después de una llamada de diagnóstico. El uso del modelo y el alojamiento se facturan directo a ti, a tu nombre, con un tope declarado en la propuesta. Trabajo desde Chile y facturo en USD o en pesos con factura electrónica del SII. La garantía operativa de 60 días aplica después de la entrega.

A veces la respuesta honesta es que todavía no necesitas esto. Si tu equipo tiene menos de diez personas y las preguntas caben en veinte páginas, una wiki bien organizada con un buen buscador le gana a un asistente: más barata y sin nada que evaluar. El asistente se gana su lugar cuando el conocimiento está repartido en cientos de documentos en varios sistemas, cuando las mismas preguntas llegan a diario de empleados o clientes, o cuando la respuesta hay que armarla desde varias fuentes. Si tu caso es el primero, te lo digo en la primera llamada.