No voy a pedirte que imagines una escena. Voy a contarte una que viví esta misma semana.
Tenía un sistema de documentación que llevaba meses construyendo —reglas, procesos, criterios, todo lo que un agente necesitaba consultar para saber cómo comportarse.
Un día tocó hacer un cambio grande. Algo de fondo, no un detalle.
Fui a tocarlo, y descubrí que no podía.
Había tantos puntos donde ese cambio afectaba —un poco aquí, un matiz allá, una referencia cruzada más allá— que aislarlo era casi imposible. Cada documento tenía demasiados conceptos mezclados dentro, y tirar de uno significaba arrastrar los demás.
Hice la cuenta, y la cuenta no salía. Era más rentable tirarlo todo y empezar de cero que intentar arreglarlo pieza a pieza.
Y lo hice.
Reconstruí el sistema entero en un par de horas —mucho menos de lo que había costado construirlo la primera vez, porque ya sabía qué preguntas hacer.
Pero el hecho de tener que tirarlo entero seguía siendo la señal de que algo, en el diseño original, estaba mal.
Ese "algo" es exactamente lo mismo que está haciendo fracasar a la mayoría de los proyectos de IA generativa en las empresas. Y casi nadie le está prestando atención.
El síntoma que todos diagnostican mal
Cuando algo falla en un asistente de IA en producción, el diagnóstico fácil es siempre el mismo:
"Es que el modelo alucina."
Y la mayoría de las veces, no es verdad. Lo que falla no es el modelo. Es lo que le has dado de comer. Y falla por dos leyes muy distintas que casi nunca se separan.
Metemos gigas de PDFs sin curar, esperando que el modelo haga magia con ellos. Y el resultado es el mismo de siempre: el modelo responde, con toda la seguridad del mundo, apoyado en algo que nadie ha revisado ni podría cambiar sin romper media docena de cosas más.
¿Por qué, con toda la potencia técnica que tenemos hoy, seguimos tropezando con lo mismo?
El problema no es la tecnología. El problema es que casi nadie está gobernando lo que le da de comer al modelo. Lo llamamos Gobierno de la IA —y hoy, en la mayoría de las empresas, no existe.
Ley 1: El rendimiento decreciente
En economía existe un principio con más de un siglo de historia: el primer trabajador que añades a una fábrica aumenta la producción. El décimo, también.
Pero llega un punto en que cada trabajador nuevo empieza a estorbar, porque el recurso fijo —el espacio, las máquinas— no crece con ellos. A partir de ahí, cada trabajador adicional no suma: resta.
Con los modelos de lenguaje pasa exactamente lo mismo. Metemos todo "por si acaso lo usamos algún día". El volumen crece sin criterio porque más información suena a seguro, nunca a riesgo. Y cuanto más crece, más difícil es de gobernar.
Esto ya nos pasó antes. Con el Big Data lo llamábamos la ciénaga (data swamp): un almacén que empieza siendo prometedor y termina siendo un lugar donde nadie encuentra nada. El nombre cambió —hoy es un RAG, no un Data Lake— pero el mecanismo es idéntico.
Piensa en una despensa de cocina. Al principio está ordenada: las especias en un estante, los cereales en otro. El cocinero entra, coge lo que necesita, cocina.
Ahora imagina que durante tres años nadie ha tirado nada. Botes caducados en el fondo. Tres marcas distintas de lo mismo, abiertas, a medio usar. Dos versiones del mismo producto, una vieja y otra nueva, y nadie sabe cuál es la buena.
El cocinero entra a preparar la cena. Y aunque sea el mejor cocinero del mundo, va a tardar el triple, y puede que confunda la sal con el azúcar porque nada está etiquetado.
No le estás dando una despensa a tu IA. Le estás dando un trastero.
Ley 2: La fragmentación de conceptos
Este problema es más sutil: no tiene que ver con cuánto volumen hay, sino con cómo está repartido.
El problema no es que los documentos estén fragmentados. El problema es que el mismo concepto de negocio aparece repetido y disperso en varios sitios a la vez, sin que nadie haya decidido cuál es su lugar único de verdad (Single Source of Truth).
Pongamos un ejemplo real, de esos que se repiten en cualquier empresa mediana. La palabra "Cliente" está definida de tres formas distintas en tres departamentos:
- Marketing la define como cualquiera que ha interactuado con una campaña, compre o no.
- Riesgos la define como el titular de un contrato activo.
- Ventas la define como alguien con actividad reciente.
Las tres definiciones son correctas dentro de su contexto. Ninguna está mal. Pero si le preguntas a la IA "¿cuántos clientes tenemos?", el modelo tiene tres verdades delante y ninguna forma de decidir cuál es la buena.
El modelo no falla porque sea tonto. Falla porque le has puesto tres verdades contradictorias delante y le has pedido que elija. Cuando un concepto vive en tres sitios a la vez, ni el modelo ni la persona más disciplinada del mundo pueden saber cuál manda.
La factura que pagan las dos
Aquí está el efecto que casi nadie ve venir: aunque los modelos sean cada vez más potentes, el coste no baja. Sube.
El volumen sin criterio dispara el coste de forma directa: cada token extra se paga, sin excepción.
Y la fragmentación de conceptos lo dispara de forma indirecta y más traicionera todavía: el modelo acaba leyendo basura que ni siquiera debería estar en su alcance —versiones dadas de baja, definiciones repetidas, contenido fuera de ámbito— y paga por procesarlo igual que pagaría por lo que sí importa.
Pero el coste económico no es el peor. El peor es el coste de confianza.
Cuando alguien pregunta a la IA algo que debería tener una sola respuesta clara, y la IA da un número que no cuadra con el de nadie más, la confianza se rompe. Y una vez rota, es muy difícil de reconstruir.
Por qué a esto no hay que llamarlo "alucinación"
La palabra "alucinación" es cómoda porque sugiere que el modelo ha inventado algo de la nada, como si tuviera fiebre. Pero eso no es lo que pasa.
Si le metes a un modelo incoherencias, ambigüedades y versiones muertas, el modelo no alucina por capricho: intenta conciliar varias mentiras que tú le has puesto delante.
"La IA no inventa el caos. Lo hereda, y lo proyecta con la misma seguridad con la que diría la verdad."
Llamarlo "alucinación" es cómodo. Nos permite culpar al modelo y seguir metiendo basura en la despensa. Pero no es honesto, y sobre todo, no es útil: no puedes arreglar un problema que has diagnosticado mal.
La trampa: "pues metamos todo a un RAG y ya veremos"
Llegados a este punto, alguien dice la frase mágica: "metamos todo a un RAG (un sistema de búsqueda para IA) y que el modelo se apañe."
Suena bien. Resuelve el problema de un plumazo: no curas nada, no ordenas nada, no decides nada. Metes todo y el modelo hace la magia.
Pero cuando se lleva esto a la práctica, aparece un enemigo peor que la desorganización: la falsa sensación de que ya está resuelto. El sistema responde. Genera texto. Parece que sabe. Durante las primeras semanas, todo el mundo está encantado.
Hasta que alguien pregunta algo importante. Hasta que el número que da la IA no coincide con el que da el sistema oficial. Y entonces llega la pregunta incómoda: "¿de dónde ha sacado esto?"
Y nadie lo sabe.
Lo que viene
Estas dos leyes explican por qué el problema existe. No explican todavía cómo se resuelve.
La buena noticia es que no hay que inventar nada nuevo. El mundo del dato lleva treinta años peleándose con exactamente este problema —volumen sin criterio, información sin gobierno— y ya tiene una respuesta madura. Solo hace falta aplicarla a lo que hoy le damos de comer a un LLM.
De eso trata lo que viene.
Si miras hoy las fuentes y documentos de tu propio RAG, ¿eres capaz de encontrar lo que buscas a la primera? ¿Por qué crees que un modelo va a poder hacerlo mejor que tú?