Author: Dominicode

Le pides las tres sentencias más relevantes sobre un asunto. Te devuelve tres: tribunal, número, año, en el formato exacto en que se citan estas cosas.

Dos existen.

La tercera no. Y es indistinguible de las otras dos.

No está peor escrita. No lleva una nota al pie que diga "esta me la he inventado". No hay cambio de tono, ni duda, ni titubeo. Tiene la misma pinta de ser verdad que las otras dos.

Y aquí está lo que casi nadie cuenta cuando explica por qué la IA se inventa cosas: no falló nada. El sistema hizo exactamente lo mismo que hace cuando acierta.

Esto no es un ejercicio teórico. El 22 de junio de 2023, el juez P. Kevin Castel impuso una sanción de 5.000 dólares —solidariamente a dos abogados y a su despacho— en el caso Mata v. Avianca, nº 1:22-cv-01461 del Distrito Sur de Nueva York (678 F. Supp. 3d 443). Habían presentado un escrito con seis sentencias inventadas de principio a fin, con citas internas a resoluciones que tampoco existen.

Lo mejor viene ahora: uno de ellos le preguntó a ChatGPT si esos casos eran reales. Respondió que sí, y añadió que podían encontrarse en Westlaw, LexisNexis y el Federal Reporter.

Y aquí está el detalle que casi nadie cuenta: el juez no sancionó por el error. Escribió que usar una herramienta de IA no tiene "nada de intrínsecamente impropio". Sancionó porque, después de que la parte contraria y dos órdenes del tribunal cuestionaran la existencia de esas sentencias, siguieron defendiéndolas.

Nadie hackeó nada. El modelo no se rompió. Solo hizo su trabajo.

---

¿Por qué la IA se inventa cosas?

Porque un modelo de lenguaje no busca la respuesta correcta: genera la continuación más probable, pieza a pieza, sobre una distribución de probabilidad aprendida en el entrenamiento. Cuando lo plausible coincide con lo cierto, decimos que acierta. Cuando no coincide, decimos que alucina. Es el mismo mecanismo, el mismo nivel de seguridad en el tono y el mismo aspecto en la pantalla.

Una alucinación de la IA es exactamente eso: una salida plausible y falsa —una cita, una fecha, un identificador, un método de librería— generada con el mismo procedimiento y con la misma confianza aparente que una salida correcta.

Lo importante es lo que no hay: en ningún punto del proceso existe un paso que pregunte "¿esto es verdad?".

No es que se salte la comprobación. Es que la comprobación no está en el diseño. Nadie la quitó porque nunca estuvo.

Si lo tienes claro en términos de predicción — la misma idea que hay detrás de cualquier algoritmo de machine learning — deja de ser sorprendente. Un sistema entrenado para que la salida sea verosímil produce salidas verosímiles. Ni más ni menos.

        el modelo optimiza UNA cosa:
     que la continuación sea plausible
                    │
        ┌───────────┴─────────────┐
   coincide con              no coincide
    la verdad                con la verdad
        │                         │
    "acierta"                 "alucina"
        └────── el mismo ─────────┘
               mecanismo
                    │
        y en ningún punto de este
        recorrido hay un paso que
        pregunte: ¿esto es verdad?

Dos nombres distintos para el mismo comportamiento. La diferencia no la pone el modelo: la pone el mundo, al coincidir o no con lo que salió.

---

Qué es una alucinación de la IA: el retrato robot que no se parece a nadie

La analogía que mejor me funciona cuando lo explico en una reunión: un dibujante de retratos robot buenísimo que nunca ha visto al sospechoso.

Tiene una técnica excelente. Conoce las proporciones, sabe qué rasgos aparecen juntos. Le das una descripción vaga y te devuelve un retrato limpio, coherente, con una nariz que encaja con esos pómulos.

El retrato está bien hecho. Es convincente. Y puede no parecerse a nadie.

Eso es una alucinación. No un borrón, no un garabato: un dibujo correcto de una persona que no existe.

---

Lo contraintuitivo: alucina más cuando la pregunta tiene forma de respuesta

Aquí es donde casi todo el mundo tiene el modelo mental invertido.

La intuición dice: alucina cuando no sabe. Falso. O al menos, insuficiente.

Alucina más cuando la pregunta parece tener una respuesta con una forma muy clara. Una referencia bibliográfica tiene una forma reconocible. Un artículo de una ley tiene una forma. Una fecha tiene una forma. Un número de sentencia tiene una forma.

Y lo plausible es exactamente lo que el modelo optimiza. Dale un hueco con forma nítida y lo rellenará con algo que tenga esa forma.

Corolario práctico y algo perverso: preguntar por una normativa que no existe es la manera más fiable de provocar una alucinación. No porque el modelo sea tonto, sino porque la pregunta le da la plantilla y él es muy bueno rellenando plantillas.

Hay datos que lo respaldan. En Why Language Models Hallucinate (Kalai, Nachum, Vempala y Zhang, 4 de septiembre de 2025) —tres de los cuatro autores firman por OpenAI; Vempala, por Georgia Tech— los autores le preguntaron tres veces a DeepSeek-V3 por el cumpleaños de uno de ellos, indicándole explícitamente que respondiera solo si lo sabía. Obtuvieron tres fechas: "03-07", "15-06" y "01-01". Ninguna correcta.

Con el título de su tesis doctoral, tres modelos distintos devolvieron tres títulos distintos. Ninguno acertó ni el título ni el año. Y el detalle que más dice: los tres inventados sonaban mejor que el de verdad.

Y por si crees que esto solo pasa con datos oscuros: al preguntar cuántas D hay en "DEEPSEEK", los modelos del estudio respondieron 2, 3, y en algunos casos 6 y 7. La respuesta es 1. No es un problema de que le falte información. Está delante.

---

No es mentir, y no es un disparate

Dos precisiones que cambian la conversación con cualquier stakeholder.

No es mentir. Mentir exige dos cosas: saber la verdad y decir otra cosa a propósito. Aquí no hay ninguna de las dos. No hay intención, y no hay una representación interna de "la verdad" separada de la salida que se pueda contradecir.

Y las alucinaciones nunca son disparates. Esto es lo que las hace peligrosas. Si el modelo te dijera que el artículo aplicable es el 4.912 de una ley con 90 artículos, lo cazarías al instante.

Lo que hace es devolverte el artículo 27.3. Verosímil. Bien formateado. En medio de tres párrafos que sí son correctos.

Ese es el riesgo real: no la barbaridad evidente, sino el dato razonable que sobrevive a la revisión rápida y acaba en producción, en un informe o delante de un cliente. Y se agrava con el tiempo, porque cuando la herramienta lleva doscientos aciertos seguidos, revisar se convierte en echar un vistazo.

---

Excelente cuando basta lo plausible. Peligroso cuando tiene que ser exacto

Esta es la línea que de verdad importa, y la que deberías tener pegada al monitor antes de decidir dónde metes un LLM.

Lo que le pides	¿Basta con que sea plausible?	Veredicto
Redactar, reformular, dar forma a un borrador	Sí — lo plausible es lo bueno	Úsalo sin miedo
Resumir un documento con datos dentro	La prosa sí; las cifras y los nombres, no	Comprueba cada dato contra el original
Traducir, ordenar ideas, dar nombre a cosas	Sí, con repaso	Úsalo
Generar código que luego compila y se testea	Sí — tienes verificador	Úsalo, el compilador es tu red
Una fecha, una cifra, un artículo de una ley	No	Verificador obligatorio
Una referencia, un ID, una versión de librería	No	Verificador obligatorio

Fíjate en la fila del código, porque es la que explica por qué los modelos funcionan tan bien escribiendo código y tan mal citando fuentes. En código tienes un verificador que se ejecuta: compilador, tipos, tests, linter. La alucinación se cae sola en dos segundos.

En una cita bibliográfica no hay compilador. Nadie la ejecuta. Solo alguien leyéndola y asintiendo.

Si tu caso de uso no tiene verificador, tú eres el verificador. Y tú te cansas.

---

¿Se arregla? El paper que medio internet cita al revés

Existe la versión pesimista: "es intrínseco, no esperes que se arregle". Y existe el paper de Kalai y compañía, que se cita constantemente para apoyar esa frase, diciendo lo contrario.

Lo que sostienen es esto: las alucinaciones no son un misterio. Empiezan como errores de clasificación binaria bajo presión estadística — si en los datos de entrenamiento un hecho aparece una sola vez, el modelo no tiene con qué distinguirlo de una invención. Su ejemplo: si el 20% de las fechas de nacimiento aparecen exactamente una vez en el preentrenamiento, cabe esperar que el modelo base alucine en al menos el 20% de esas fechas.

Y luego viene la parte incómoda. Persisten, dicen, por cómo se puntúa a los modelos. Los benchmarks que dominan los leaderboards corrigen en binario: acierto o fallo. Un "no lo sé" puntúa igual que un fallo — cero. Revisaron las diez evaluaciones que dominan esos leaderboards —GPQA, MMLU-Pro, IFEval, Omni-MATH, BBH, MATH, MuSR, SWE-bench, HLE y WildBench— y en nueve de las diez reconocer incertidumbre no da ningún crédito. La única que da algo es WildBench, y con un matiz cruel: su rúbrica puede puntuar más bajo un "no lo sé" que una respuesta mediocre con datos inventados.

Con esa regla, adivinar siempre es la estrategia óptima. Estamos entrenando buenos examinandos, no sistemas fiables.

Su propuesta es tan poco glamurosa que por eso nadie la tuitea: cambiar la puntuación de los benchmarks que ya existen, declarando en el enunciado el umbral de confianza — responde solo si tienes más de t de confianza, el fallo resta t/(1−t) puntos, el acierto suma 1 y el "no lo sé" suma 0. Con t = 0.9, cada fallo cuesta nueve.

Así que sí: la parte del problema que viene de los incentivos es corregible, y eso es una buena noticia.

Lo que no cambia es el diseño de fondo. Puedes premiar la abstención y conseguir que el modelo diga "no lo sé" muchísimo más a menudo. No conviertes eso en un paso de comprobación de hechos que antes no existía. Mientras la salida se genere por probabilidad, tu arquitectura tiene que contemplar que a veces será plausible y falsa.

No es una razón para no usarlo. Es una razón para diseñar con eso dentro.

---

Cómo evitar alucinaciones en tu código: 5 decisiones para mañana

Aquí es donde este post se separa de los cincuenta artículos que explican qué son las alucinaciones y terminan con un "revisa siempre las respuestas". Gracias, muy útil.

Cinco decisiones concretas. Y antes, lo que caza cada una — porque ninguna las caza todas:

Defensa	Qué caza	Qué NO caza
Schema de salida (Zod)	Respuestas con la forma equivocada	Un ID inventado con la forma correcta
Consulta a la fuente	SKUs, IDs y referencias que no existen	Datos que existen pero no aplican
Cita literal verificada	Atribuir algo real a una fuente que no lo dice	Una fuente que dice algo falso
Rama "no lo sé" en el schema	El relleno por campo obligatorio	La invención cuando el modelo "cree" saber
Test de abstención	Que el sistema invente en preguntas sin respuesta	Errores en preguntas que sí tienen respuesta

1. Verificar en lugar de confiar

Cada dato factual que salga del modelo y entre en tu sistema pasa por tres filtros, en este orden: schema, tipos, fuente.

El schema te da forma. Los tipos te dan garantías en compilación. Y la fuente te da la única cosa que el modelo no puede darte: verdad.

import { z } from 'zod';

// El schema valida la forma. NO valida que el ID exista.
const Producto = z.object({
  sku: z.string().regex(/^[A-Z]{3}-\d{6}$/),
  precio: z.number().positive(),
});

const extraido = Producto.parse(salidaDelModelo); // ✅ forma correcta
const real = await db.productos.findBySku(extraido.sku); // ✅ existencia
if (!real) throw new SkuInventadoError(extraido.sku); // error tuyo, no de Zod

Un SKU inventado pasa el regex sin problema. Tiene exactamente la forma de un SKU — recuerda: forma clara, invención fiable. La única defensa es la consulta.

2. Grounding: dale las fuentes delante y exígele la cita

Si el modelo tiene el texto real en la ventana de contexto, no necesita inventar. Eso es RAG y por qué gana a fine-tuning para problemas de conocimiento — y si quieres verlo montado con código, tienes la implementación completa aquí.

Pero pedir la cita no basta. Hay que comprobarla:

// Sin normalizar, un espacio doble o una tilde tumban la comprobación.
const normalizar = (s: string) =>
  s.normalize('NFD').replace(/[\u0300-\u036f]/g, '')
    .replace(/\s+/g, ' ')
    .trim()
    .toLowerCase();

const cita = normalizar(respuesta.citaLiteral);

// Ojo: includes('') es true. Una cita vacía "aparece" en cualquier documento.
const citaVerificada =
  cita.length >= 30 &&
  fuentes.some(f =>
    f.id === respuesta.fuenteId && normalizar(f.texto).includes(cita)
  );

Determinista, barato, sin llamadas extra. Si la cita literal no aparece en el documento que dice citar, la respuesta se descarta. Con esto cazas la clase de fallo más caro que existe: la respuesta correcta atribuida a una fuente que no dice eso.

3. Déjale una salida: "no lo sé" tiene que ser una opción legal

Este es el error más repetido en las integraciones que reviso: un schema con todos los campos obligatorios y ninguna rama para la ignorancia.

Cada campo obligatorio sin salida es una invitación a rellenar. Si tu tipo dice que articulo: string es obligatorio, has convertido "no lo sé" en una respuesta imposible de expresar.

const Respuesta = z.discriminatedUnion('estado', [
  z.object({
    estado: z.literal('encontrado'),
    articulo: z.string(),
    citaLiteral: z.string().min(30), // una cita de cinco caracteres "aparece" en casi cualquier documento
    fuenteId: z.string(),
  }),
  z.object({
    estado: z.literal('no_esta_en_las_fuentes'),
    queFaltaria: z.string(),
  }),
]);

Y dilo también en el prompt, explícito: si la información no está en los documentos proporcionados, responde con estado no_esta_en_las_fuentes. No completes con conocimiento propio.

Dos frases. Baja las invenciones de forma muy visible. Es la misma lógica de los umbrales de confianza del paper, aplicada a tu endpoint.

4. Dónde no lo metes sin verificador

Ninguna de estas cosas entra a un sistema por generación directa: identificadores, precios, cantidades, fechas límite, versiones de dependencias, nombres de métodos de una librería, artículos de normativa, referencias.

Lo de los nombres de métodos merece un párrafo. Cuando le pides código con una librería poco común, el modelo te devuelve el método que debería existir según todas las APIs parecidas que ha visto. Bien nombrado, con la firma coherente, perfectamente plausible. Y no existe.

Y hay una variante peor con los nombres de paquete: el compilador no te salva de un npm install de una dependencia que el modelo se ha inventado y que alguien ya ha registrado con ese nombre exacto, esperando precisamente eso.

Da igual que bajes la temperatura a 0. Eso te quita variabilidad, no te da verdad: te devuelve la misma respuesta plausible casi siempre. Si era falsa, ahora es falsa de forma reproducible. Y ni el "casi siempre" está garantizado: en una API la salida a temperatura 0 todavía puede cambiar según cómo se agrupen las peticiones concurrentes en el servidor.

5. Que los tests no comparen la salida literal

Un test que hace expect(salida).toBe("...") sobre una respuesta generada está roto de nacimiento. Cambias de modelo o de versión y se cae sin que nada haya empeorado.

Testea propiedades, no cadenas:

• La salida valida contra el schema, siempre.
• Toda cita literal aparece en la fuente que dice citar.
• Ningún fuenteId sale del conjunto de fuentes inyectadas.
• Y el que más información da: un conjunto de preguntas cuya respuesta no está en el corpus, donde lo que se comprueba es que el sistema se abstiene. Si tu tasa de abstención en ese conjunto es baja, tu sistema está inventando y todavía no lo sabes.

Esa cuarta propiedad es el equivalente en tu repo de lo que propone el paper para los benchmarks: dejar de premiar el acierto por adivinar.

Decidir esto antes de escribir código —qué salida es aceptable y cómo se comprueba— en lugar de parchearlo cuando ya ha explotado, es exactamente el trabajo que describo en Spec-Driven Development.

Y en el curso Construye con IA montamos estos verificadores dentro del flujo. Es la diferencia entre un prototipo que impresiona en la demo y algo que puedes dejar corriendo.

---

La única conclusión que importa

Deja de preguntarte si el modelo alucina. Alucina, porque es la misma operación con la que acierta.

Y no es que sea inevitable —el propio paper describe un sistema que puede abstenerse—. Es que tú no puedes construir asumiendo que ya está resuelto.

La pregunta correcta es otra: ¿en qué punto de mi sistema se detecta un dato falso, y qué pasa si ese punto no existe?

Si la respuesta es "lo detecta la persona que lo lea", no tienes un sistema. Tienes un borrador con muy buena presentación.

Elige hoy el dato factual más crítico que salga de un modelo en tu código y ponle un verificador determinista. Uno. Media hora de trabajo. Vas a dormir mejor.

Y si te has quedado con ganas de ordenar el resto del terreno — grounding, RAG, salida estructurada, evaluación y el resto de los 120 conceptos colocados por zonas, con sus conexiones dibujadas — tengo un mapa de la IA en una hoja para imprimir, gratis aquí. Funciona muy bien para pasársela a quien aprueba estos presupuestos.

---

Preguntas frecuentes

¿Por qué la IA se inventa cosas?

Porque un modelo de lenguaje genera la continuación más probable de un texto, token a token, sobre una distribución de probabilidad aprendida en el entrenamiento. Su objetivo es que la salida resulte plausible, no que sea verdadera. Cuando lo plausible coincide con lo cierto, acierta; cuando no coincide, alucina. En ningún momento del proceso hay un paso que verifique si lo generado es verdad: esa comprobación no forma parte del diseño, así que hay que añadirla fuera del modelo.

¿Qué son las alucinaciones de la IA exactamente?

Son salidas plausibles y falsas: una referencia con el formato exacto de una referencia real, una cifra verosímil, una cita bien construida, un método de librería que podría existir. Nunca son disparates evidentes, y por eso son peligrosas. El riesgo no es que el modelo diga algo absurdo, que cualquiera detectaría, sino que introduzca un dato razonable en medio de varios párrafos correctos y ese dato sobreviva a la revisión rápida hasta llegar a producción.

¿La IA miente cuando alucina?

No. Mentir exige saber la verdad y decir otra cosa de forma deliberada, y en un modelo de lenguaje no se da ninguna de las dos condiciones: no hay intención, y no existe una representación interna de la verdad separada de la salida que se pueda contradecir. Por eso tampoco sirve enfadarse con el modelo ni pedirle que "no invente". Lo que sirve es cambiar el diseño alrededor: darle las fuentes, exigirle cita y verificarla con código.

¿Cuándo alucina más un modelo de lenguaje?

Contra lo que parece, no solo cuando no sabe algo. Alucina más cuando la pregunta parece tener una respuesta con una forma muy clara y reconocible: una fecha, un artículo de una ley, un número de sentencia, una referencia bibliográfica. Como el modelo optimiza plausibilidad, un hueco con forma nítida se rellena con algo que tenga esa forma. Preguntar por una normativa que no existe es una de las maneras más fiables de provocar una invención.

¿Se pueden eliminar las alucinaciones del todo?

Se reducen mucho y no se eliminan. Funcionan tres palancas: grounding (darle las fuentes en el contexto), exigir cita literal y verificarla contra el documento, y permitir explícitamente "no lo sé" en el prompt y en el schema de salida. El paper Why Language Models Hallucinate (2025) añade una cuarta a nivel de industria: cambiar la puntuación de los benchmarks, que hoy casi todos dan cero tanto al fallo como al "no lo sé" y por tanto premian adivinar.

¿Bajar la temperatura a 0 evita las alucinaciones?

No. La temperatura controla cuánta variabilidad hay al muestrear el siguiente token, no si el contenido es cierto. Con temperatura 0 el modelo elige en cada paso el token más probable, así que tiendes a obtener siempre la misma respuesta —aunque ni eso está garantizado en una API, donde el resultado depende de cómo se agrupen las peticiones concurrentes—. Si esa respuesta es falsa, ahora es falsa de forma consistente, que engaña más porque parece estabilidad.

¿Alucinan menos los modelos de razonamiento?

Menos en lo que se puede calcular: si la respuesta se deduce paso a paso, más cómputo ayuda. Pero razonar no añade un paso de comprobación contra el mundo, así que en datos que solo se pueden saber —una fecha, una referencia, un identificador— el problema es idéntico. Why Language Models Hallucinate lo atribuye a los incentivos de evaluación, no a la capacidad: mientras un "no lo sé" puntúe igual que un fallo, adivinar sigue siendo la estrategia óptima para cualquier modelo, razone o no.

¿Cómo pruebo que mi integración con un LLM no inventa datos?

No compares la salida literal con una cadena esperada: se rompe en cada cambio de modelo sin que nada haya empeorado. Testea propiedades. Que la salida valide contra el schema, que toda cita literal aparezca en la fuente que dice citar, que ningún identificador de fuente esté fuera del conjunto inyectado, y sobre todo mantén un conjunto de preguntas cuya respuesta no exista en tu corpus, midiendo que el sistema se abstiene en lugar de rellenar.

---

Si quieres ver estos verificadores funcionando dentro de proyectos reales, con la arquitectura y el código completos, es parte de lo que trabajamos en Dominicode Labs. Problemas de producción, decisiones que puedes aplicar esta semana.

---

Por Bezael Pérez — Developer senior con más de 15 años de experiencia y fundador de Dominicode.