El grounding no es una funcionalidad. Es una restricción.

Le haces una pregunta factual a un asistente. Responde con una prosa limpia y segura — nombres, números, una cita. Se lee como la verdad. Está completamente equivocado. Sin error, sin advertencia, sin el más mínimo asomo de duda. Solo una respuesta fluida, bien estructurada e inventada, entregada con exactamente la misma seguridad que una correcta.

Cualquiera que haya usado un LLM ha vivido este momento. El instinto es tratarlo como un bug — algo que un modelo mejor, o un prompt más astuto, terminará por arreglar. No lo hará. Y entender por qué es justo la razón por la que el grounding (anclaje) tiene que ser una decisión arquitectónica, no una funcionalidad que espolvoreas al final.

La alucinación no es un bug. Es el mecanismo.

Un modelo de lenguaje no almacena hechos y los consulta. Predice el siguiente token plausible, una y otra vez, a partir de patrones en sus datos de entrenamiento. Cuando sabe la respuesta, la continuación más plausible resulta ser verdadera. Cuando no la sabe, no se detiene — produce la continuación más plausible de todos modos, que es fluida, segura e inventada.

Andrej Karpathy lo dijo de forma más directa de lo que yo podría (fuente):

En cierto sentido, alucinar es todo lo que hacen los LLM. Son máquinas de soñar... Solo cuando los sueños entran en territorio que consideramos factualmente incorrecto los etiquetamos como una "alucinación". La alucinación no es un bug, es la mayor virtud del LLM.

Esa misma maquinaria es lo que le permite a un modelo escribir un poema, refactorizar tu código o explicar un concepto de tres maneras distintas. No puedes quitar la adivinación sin quitar lo que lo hace útil. El soñar es el motor.

Y no desaparece con la escala. El Stanford AI Index 2026 midió las tasas de alucinación en 26 modelos líderes y las encontró en un rango de 22% a 94% según la tarea. Los mejores modelos son muchísimo mejores que los peores, pero ninguno es cero, y ninguno lo será jamás — porque no es un defecto que parchar. Es la naturaleza de una máquina de adivinar.

Así que deja de tratar de arreglar el modelo. Arregla el sistema que lo rodea.

La jugada arquitectónica: no le confíes los hechos a la máquina de adivinar

Aquí está la idea completa en una sola frase: el modelo puede formular la verdad, pero nunca puede crearla.

Si la alucinación es lo que el modelo hace cada vez que tiene que producir un hecho, entonces el arreglo es nunca ponerlo en esa posición. No le preguntes al modelo qué es verdad. Calcula o consulta qué es verdad con algo determinista — una base de datos, un cálculo, una API, un motor de reglas — y entrégale esos hechos al modelo con una sola tarea: decirlos bien. En el instante en que el modelo solo está reformulando hechos que le fueron dados, ya no le queda nada que inventar.

Eso es grounding. No "el modelo es lo bastante listo para tener razón", sino "el modelo, por estructura, no está a cargo de tener razón".

"Agregar RAG" no es grounding

Aquí es donde la mayoría de los equipos cree que lo resolvió y no es así. Retrieval-Augmented Generation — recuperar algunos documentos relevantes, meterlos en el contexto y esperar que el modelo los use — es el intento más común de grounding. Ayuda. No es lo mismo, y tratarlo como una funcionalidad que atornillas encima es exactamente la trampa.

RAG ancla el sueño; no lo prohíbe. El modelo sigue decidiendo qué decir, sigue rellenando huecos cuando la recuperación se queda corta, y la recuperación se queda corta constantemente. Un análisis de la industria en 2026 encontró que los pipelines de RAG ingenuos fallan en la recuperación cerca del 40% de las veces, y que cuando un sistema RAG da una respuesta equivocada, la falla está en la recuperación — no en la generación — el 73% de las veces. El modelo, obediente, escribió una respuesta segura y con aire de bien anclada encima de los documentos equivocados. No sorprende que el 77% de los líderes de datos diga que RAG por sí solo no es lo bastante confiable para producción.

La diferencia que importa no es "¿recuperas o no?". Es qué tiene permitido hacer el modelo cuando los hechos no están ahí. El RAG atornillado lo deja adivinar. El grounding de verdad no — el hecho o viene de la fuente o no se enuncia. Eso no es una instrucción en el prompt. Es una propiedad de cómo está construido el sistema.

Cómo se ve cuando de verdad lo haces cumplir

Construyo esto para ganarme la vida, así que déjame hacerlo concreto. Opero una API de astrología, Astrolinkers, y un producto de consumo encima de ella, Alwenna. La astrología es una prueba de estrés perfecta para el grounding: es todo posiciones específicas, puntajes y relaciones, y un modelo está más que feliz de inventar una lectura segura, plausible y completamente fabricada.

Así que el modelo nunca llega a hacerlo. Astrolinkers calcula la carta de forma determinista — posiciones reales, sinastría real, números reales, ningún LLM cerca de las matemáticas. Solo entonces entra el modelo de lenguaje, con una sola tarea: tomar esos hechos calculados y formularlos con una voz cálida y sencilla. Nunca se le pregunta qué dice tu carta; se le dice, y se le pide que lo diga bien. Cada afirmación que hace Alwenna se remonta a un valor real, calculado. Si el motor no produjo un hecho, el modelo no tiene nada que decir al respecto — y no "inventa algo que suene bien".

Esa regla — el modelo reformula, el motor decide — está cableada en el diseño, no escrita en un prompt. Al modelo no se le pide que se porte bien; es estructuralmente incapaz de crear un hecho, porque los hechos llegan precalculados y él se ubica aguas abajo de ellos. Esa es la diferencia entre esperar y hacer cumplir.

Por qué "restricción", no "funcionalidad"

Esta es la distinción de la que trata el título, y no es pedantería.

Una funcionalidad es algo que agregas y puedes apagar. Vive en un prompt ("por favor usa solo el contexto provisto"), es opcional y se degrada en silencio — el día que la recuperación falla, el modelo adivina calladamente y nadie se entera hasta que lo hace un cliente. Un prompt es una petición cortés a un sistema cuya naturaleza entera es producir texto plausible. Lo plausible no es lo verdadero.

Una restricción la impone la forma del sistema. El modelo está aguas abajo de una fuente de verdad, y no existe ningún camino por el cual pueda enunciar un hecho que la fuente no proporcionó — no porque lo pedimos con amabilidad, sino porque la arquitectura no ofrece uno. No esperas que se mantenga anclado; no puede despegarse del suelo.

Es la misma disciplina que en cualquier otra parte de la ingeniería. No previenes una clase de bugs pidiéndoles a los desarrolladores que tengan cuidado; haces que el bug sea irrepresentable — con un tipo, una frontera, un invariante que el código no puede violar. El grounding es esa misma jugada aplicada al único componente que te va a mentir con total seguridad. Pon el invariante en la arquitectura, donde se sostiene, no en el prompt, donde es una sugerencia.

La recompensa

Haz esto y algo cambia en silencio. El LLM deja de ser la parte de tu sistema que tienes que cuestionar y pasa a ser la parte en la que puedes confiar — porque le redujiste el trabajo a la única cosa en la que es genuinamente excelente (el lenguaje) y le quitaste la única cosa en la que es estructuralmente malo (saber qué es verdad).

De eso se trata todo. Un LLM es más útil precisamente cuando menos se le confían los hechos — cuando una fuente determinista es dueña de la verdad y al modelo se le deja hacer aquello en lo que es brillante: hacer que esa verdad suene humana.

El grounding no es una funcionalidad que agregas para hacer mejor al modelo. Es una restricción que haces cumplir para que el modelo no pueda equivocarse de la manera en que más quiere hacerlo.