Asistente interno con documentos: el proceso antes de indexar

El proceso que genera el documento importa más que el documento

Un asistente interno no es una idea nueva. Conectar una IA a una carpeta de manuales y políticas es, hoy, un fin de semana de trabajo para cualquier equipo técnico. Lo difícil no es armar el asistente. Lo difícil es que responda bien.

Un asistente que indexa un procedimiento desactualizado responde con la misma seguridad que uno que indexa el procedimiento correcto. La diferencia no la nota la interfaz conversacional. La nota la persona que confía en esa respuesta y toma una decisión equivocada.

Por eso conviene invertir el orden habitual. Antes de preguntar qué asistente conectar, conviene delimitar qué preguntas debe responder el asistente antes de indexar nada: una colección de políticas de soporte, un catálogo técnico o un set de procedimientos operativos, no "toda la empresa" como alcance. Esa disciplina, según explica Lanzamiento Digital en su guía sobre cómo crear un asistente interno con documentos, es lo que separa un piloto evaluable de un experimento sin límites claros. También conviene preguntar qué proceso produce cada documento, quién lo valida y con qué frecuencia se revisa, algo que ampliamos en 5 ajustes de ChatGPT que su empresa debería activar al hablar de configurar un asistente para el uso diario de la empresa.

Como resume Daniel Zárate en su guía sobre asistentes de IA internos, el conocimiento de una empresa suele existir disperso entre carpetas y chats, sin que nadie sepa exactamente dónde buscarlo. Es, casi literalmente, el punto de partida del reel de Bprosys "Tu empresa ya tiene las respuestas. Están escondidas.": la información ya existe, el problema es que nadie la organizó para que un asistente la pueda usar bien.

Sin permisos claros un asistente interno filtra información en vez de protegerla

Que un documento exista en el repositorio no significa que cualquier persona de la empresa deba poder consultarlo a través del asistente. Un contrato con un proveedor, una política de compensaciones o un procedimiento de seguridad tienen audiencias distintas dentro de la misma empresa.

Los permisos no se resuelven con una instrucción dentro del modelo, del tipo "no respondas sobre temas de nómina si quien pregunta no es de Recursos Humanos". Esa instrucción se puede evadir con la pregunta siguiente. Los permisos se resuelven en el sistema que recupera los documentos, filtrando qué fuentes puede ver cada usuario antes de construir la respuesta.

Un asistente interno sin ese filtro no democratiza la información de la empresa. La expone.

En síntesis, preparar y filtrar los documentos por permisos antes de que el asistente los use no es un paso opcional de la implementación: es el paso que decide si el asistente es una herramienta segura o un riesgo nuevo con interfaz conversacional. También aplica la misma lógica de qué puede ver el asistente que describimos en qué es MCP y para qué sirve conectar IA a sus sistemas, aunque ahí la fuente sean sistemas estructurados y acá, documentos.

Responder con referencias evita que el asistente invente una respuesta

Una respuesta útil de un asistente interno indica de dónde salió. Si alguien pregunta cuál es la política de reembolso de gastos de viaje, la respuesta debería señalar el documento y la sección exactos, no solo un resumen sin origen verificable.

Esa referencia cumple dos funciones. Primero, permite que la persona verifique el dato si la decisión lo amerita. Segundo, obliga al asistente a admitir cuándo no encontró evidencia suficiente, en vez de completar el vacío con una respuesta plausible pero inventada.

Un asistente que nunca dice "no tengo esa información" no es más útil. Es menos confiable.

Mapear el proceso antes de indexar evita automatizar el desorden

Aquí está el paso que la mayoría de las guías técnicas sobre asistentes internos no cubre: qué hacer cuando los documentos de la empresa no están ordenados para empezar.

En una empresa mediana típica, la política de vacaciones vive en un PDF de hace tres años, el procedimiento de aprobación de compras cambió el mes pasado sin que nadie actualizara el manual, y el criterio real para resolver una excepción de facturación vive en la memoria de una persona, no en ningún documento. Ese mismo patrón (información que existe pero no es accesible sin preguntarle a alguien) es el que describimos en 3 señales de que su proceso no tiene visibilidad.

Antes de indexar un documento conviene aplicar el filtro de 6 preguntas para saber si su proceso está documentado. Un documento que no pasa ese diagnóstico no es una fuente confiable para un asistente, sea cual sea la tecnología que se use para conectarlo.

Conectar un asistente a ese conjunto sin antes mapear el proceso real no ordena nada. Solo agrega una capa conversacional sobre información que ya era poco confiable. La metodología de Process Discovery de Bprosys parte de relevar el proceso real, con sus excepciones y responsables, antes de automatizar o conectar cualquier sistema. La misma lógica aplica a un asistente que va a responder con esos documentos como fuente.

Una primera versión útil cubre una colección acotada, no toda la empresa

Un piloto razonable no intenta indexar toda la documentación de la empresa desde el primer día. Cubre una colección delimitada (por ejemplo, las políticas de un solo departamento), un grupo definido de usuarios y una vía visible para reportar una respuesta incorrecta.

Ese alcance acotado permite medir dos cosas antes de escalar: si el asistente recupera la fuente correcta y si respeta los permisos definidos. Ampliar la cobertura recién cuando esas dos métricas son sólidas evita heredar, a mayor escala, el mismo desorden documental que existía antes del asistente.

Su empresa probablemente ya tiene las respuestas que su equipo busca todos los días. Están escondidas entre carpetas, correos y la memoria de unas pocas personas. El asistente correcto no es el que responde primero. Es el que responde con el documento correcto, del proceso correcto, validado por la persona correcta.