Búsqueda con IA dentro de tu empresa: la versión realista

Toda empresa tiene el mismo sueño: un asistente al que puedas preguntar cualquier cosa, que responda a partir de todo tu conocimiento interno —el wiki, los documentos, el historial de chat, las propuestas viejas que nadie encuentra—. La demo, construida sobre una carpeta limpia de documentos bien redactados, es genuinamente mágica. Luego la apuntas a la empresa real y descubres que los documentos son un desastre, los permisos son un campo minado y las preguntas que la gente hace de verdad no se parecen en nada a la demo. Este artículo es la versión realista: por qué la búsqueda interna con IA es más difícil que la búsqueda externa, y qué separa los despliegues que se usan de los que se abandonan en silencio.

Tus documentos son peores de lo que crees

La primera realidad es el corpus. La demo funciona sobre documentos que alguien curó. La empresa funciona sobre documentos que se acumularon a lo largo de años: copias duplicadas con pequeñas diferencias, borradores que nunca se marcaron como borradores, una política de hace tres reorganizaciones junto a su sustituta, y la única respuesta más necesaria viviendo solo en la cabeza de alguien o en un hilo de chat enterrado. La búsqueda con IA no arregla esto; lo saca a la luz. Cuando dos documentos se contradicen, el sistema responderá con seguridad a partir del que la recuperación haya clasificado más alto.

Por eso los proyectos exitosos dedican más esfuerzo al corpus que al modelo. Deduplicar, marcar documentos como autorizados u obsoletos y eliminar los desfasados hace más por la calidad de las respuestas que cualquier cantidad de ajuste. La verdad poco glamurosa es que la búsqueda interna es un proyecto de higiene del conocimiento disfrazado de IA.

La recuperación lo es todo

Como cualquier sistema que responde a partir de documentos, el techo de calidad lo fija la recuperación, no la generación. Si el pasaje relevante no se pone delante del modelo, ninguna cantidad de escritura fluida produce la respuesta correcta: produce una equivocada y segura en su lugar. La mayoría de los fallos en la búsqueda interna son fallos de recuperación, y son fáciles de diagnosticar mal porque la respuesta igual se lee bien.

Los corpus internos hacen la recuperación especialmente difícil. La gente busca con jerga propia de la empresa, nombres en clave de proyectos y siglas que significan una cosa en finanzas y otra en ingeniería. El documento relevante puede usar palabras totalmente distintas a las de la pregunta. Medir si el documento correcto se recupera de verdad —por separado de si la respuesta suena bien— es lo más útil que puede hacer un equipo, y lo que la mayoría de los equipos se saltan.

Los permisos son la parte que puede meterte en problemas

La búsqueda externa tiene una sola audiencia. La búsqueda interna tiene muchas, y no tienen permiso para ver lo mismo. El comercial no debería recuperar la hoja de ruta no anunciada; el contratista no debería recuperar la hoja de cálculo de salarios; el recién contratado no debería recuperar el documento marcado solo para directivos. En el momento en que tu índice de búsqueda ignora quién pregunta, se convierte en una máquina de fugas que responde con fluidez y amabilidad con información que quien pregunta nunca tuvo autorización para ver.

Acertar con esto es más difícil de lo que parece, porque el modelo se sitúa aguas abajo de la recuperación. Si la recuperación extrae un pasaje al que el usuario no puede acceder y se lo entrega al modelo, el modelo lo resumirá con gusto. Los permisos, por tanto, tienen que aplicarse en la capa de recuperación, por usuario, antes de que cualquier documento llegue al modelo, no añadirse después. Este es precisamente el tipo de control consciente de las consecuencias hacia el que existen marcos como el NIST AI Risk Management Framework para empujar a los equipos: el coste de una respuesta equivocada es leve; el coste de una fuga confidencial no lo es, y los controles deberían reflejar esa diferencia.

Las preguntas no son las de la demo

Las demos usan preguntas limpias y factuales con respuestas limpias y factuales. Las preguntas reales son más desordenadas. La gente pregunta cosas que abarcan muchos documentos, cosas que requieren sintetizar un estado actual a partir de un historial de cambios, cosas que en realidad tratan de conocimiento tribal que ningún documento capturó, y cosas que son genuinamente ambiguas. Un sistema afinado para encontrar y citar un solo pasaje tiene dificultades cuando la respuesta honesta es "esto está repartido en cinco documentos y dos de ellos se contradicen".

La otra sorpresa es que la gente hace preguntas esperando que el sistema admita su ignorancia con elegancia. Un sistema que siempre produce una respuesta, incluso cuando no tiene nada relevante, es peor que uno que dice "no encontré nada autorizado sobre esto". El vacío seguro destruye la confianza más rápido que los huecos honestos.

Por qué se abandonan estos proyectos

Los proyectos de búsqueda interna rara vez fracasan con estruendo. Fracasan en silencio: funciona en la demo, se despliega, la gente lo prueba, recibe unas cuantas respuestas equivocadas y seguras sobre preguntas cuya respuesta conocían, pierde la confianza y vuelve a preguntar a un colega. La herramienta no se elimina; simplemente ya no se abre. Una vez perdida la confianza, incluso las respuestas correctas dejan de creerse.

El patrón es evitable. La confianza se construye acertando primero en las preguntas fáciles y de alto tráfico, citando el documento de origen para que la gente pueda verificar, y diciendo "no lo sé" en lugar de adivinar. Un sistema que muestra su trabajo y admite sus límites se gana el beneficio de la duda; uno que responde todo con fluidez gasta su credibilidad en el primer error seguro.

Qué hacen los despliegues que funcionan

Los sistemas de búsqueda interna que sobreviven comparten un perfil. Tratan la limpieza del corpus como trabajo central, no como configuración. Aplican los permisos en la recuperación, por usuario. Miden la calidad de la recuperación directamente, no solo la fluidez de la respuesta. Citan las fuentes para que cada respuesta sea verificable. Diseñan a propósito el camino del "no lo sé". Y acotan las ambiciones: clavar las cien preguntas recurrentes principales supera responder a medias todo. Nada de esto es exótico, pero todo es trabajo que la demo te permite saltarte, que es exactamente por qué la demo es mucho más fácil que el despliegue.

En resumen

La búsqueda interna con IA promete convertir el conocimiento disperso de tu empresa en un único recurso consultable, y la demo hace que parezca sencillo. La realidad es más difícil en cuatro frentes: tus documentos son más desordenados de lo que crees, la recuperación y no la generación fija el techo de calidad, los permisos deben aplicarse por usuario en la capa de recuperación o el sistema filtra, y las preguntas reales no se parecen en nada a las de la demo. Limpia el corpus, mide la recuperación, controla el acceso, cita las fuentes y deja que el sistema admita su ignorancia. Haz eso y se convierte en el recurso que todos querían. Sáltatelo y publica la demo, y la herramienta será abandonada en silencio la primera semana en que la gente la pille equivocándose con seguridad.