Alucinaciones IA: cómo frenar respuestas sin respaldo

Un bot de soporte no debería inventar una excepción a una política. Un asistente de informes no debería improvisar un total. Un agente —software que utiliza un modelo para elegir acciones y llamar a herramientas— no debería adivinar qué registro de cliente debe modificar. El objetivo práctico es impedir que una respuesta o una acción sin respaldo salga de tu aplicación.

Verificado el 17 de octubre de 2026 con las guías de los proveedores de modelos, la documentación de API, los ejemplos de investigación y la resolución judicial enlazados. Los ejemplos que siguen son observaciones atribuidas a sus fuentes; el validador y el plan semanal son recomendaciones de implementación, no resultados obtenidos en producción.

¿Qué son las alucinaciones de los LLM y por qué ocurren?

Una alucinación de un LLM es una afirmación falsa o sin respaldo que el modelo presenta como respuesta. LLM significa modelo de lenguaje de gran tamaño: un modelo entrenado para generar lenguaje a partir de patrones presentes en el texto. Una afirmación también puede carecer de respaldo en los documentos que proporcionaste, aunque resulte cierta en otro contexto.

Imagina al modelo como un redactor hábil que completa un informe con el material que tiene sobre la mesa. Puede escribir un párrafo convincente para cubrir un hueco. Eso no demuestra que ese párrafo deba formar parte de los registros de tu empresa.

Predecir un texto verosímil no equivale a comprobar un hecho

La publicación de OpenAI sobre por qué alucinan los modelos de lenguaje, del 5 de septiembre de 2025, explica que durante el preentrenamiento el modelo aprende a predecir texto sin que cada afirmación lleve una etiqueta de verdadero o falso. Los datos poco frecuentes y arbitrarios son especialmente difíciles de reconstruir a partir de patrones. El entrenamiento posterior mejora el comportamiento, pero la fluidez no se convierte en garantía de veracidad.

Para quien desarrolla la aplicación, la consecuencia es clara: las políticas de producto, el estado de una cuenta y el inventario deben estar en fuentes autorizadas que la aplicación pueda consultar. Usar la respuesta que el modelo recuerda como si fuera la base de datos abre una vía de fallo evitable.

El contexto incompleto o desactualizado deja huecos

Es posible que el modelo nunca haya recibido el dato que necesita el cliente. Un documento cargado puede estar obsoleto; una búsqueda puede recuperar información de otra edición del producto; una consulta de cuenta puede fallar. La explicación de Anthropic sobre las respuestas incorrectas de Claude señala expresamente la falta de información reciente como una fuente de confusión.

Conviene distinguir dos incidentes. Si el asistente inventa una política, falló la generación. Si reproduce con exactitud una política que ya no está vigente, falló la gestión de las fuentes. En ambos casos el cliente recibe una respuesta incorrecta, pero cambiar el prompt no corrige ni un documento vencido ni una consulta de cuenta que no funciona.

La presión por responder premia la conducta equivocada

OpenAI sostiene que las evaluaciones basadas únicamente en la exactitud pueden premiar las conjeturas por encima de reconocer la incertidumbre. Tu propia métrica de éxito puede repetir ese error si cada respuesta completa cuenta como un acierto y cada derivación como un fallo.

Un cliente que pide una fecha de entrega garantizada necesita una estimación oficial del envío. Si la empresa de transporte no la ha facilitado, lo útil es explicar de forma concreta qué información falta. Premia ese resultado en las pruebas y en el panel operativo.

Alucinaciones IA: cuatro errores que conviene detectar

Clasifica los fallos según lo que deba verificar tu aplicación. Estas categorías se solapan, pero ofrecen a un equipo pequeño puntos concretos donde añadir comprobaciones.

Hechos inventados: los ejemplos de las tesis proceden de la investigación publicada por OpenAI. Reconocer un nombre no bastó para recuperar el título que faltaba. En una empresa, el equivalente sería inventar una función de un producto porque otros productos parecidos la tienen.

Cifras incorrectas: los ejemplos de las fechas de nacimiento de esa misma publicación muestran por qué una fecha que parece precisa no constituye evidencia. En tu aplicación, distingue las cifras sin respaldo de los errores de cálculo. Obtén las cantidades de los registros y calcula los totales con código convencional; pide al modelo que explique el resultado que recibe.

Citas falsas: la resolución del 20 de marzo de 2024 en United States v. Cohen describe tres casos inexistentes obtenidos de Google Bard, el nombre que entonces tenía el asistente generativo de Google. Una de las supuestas referencias era United States v. Figueroa-Florez. Un nombre de caso verosímil y un formato de cita correcto no remitían a una autoridad jurídica real.

Argumentos erróneos en llamadas a herramientas: los autores de Berkeley Function Calling Leaderboard muestran una llamada con annual_interest_rate: 5 para una tasa solicitada del 5%, junto a la representación decimal correcta, 0.05. Ambos valores son números. Una comprobación de tipos por sí sola no permite distinguirlos. Se trata de un error semántico en un argumento; no toda llamada incorrecta a una herramienta es un hecho inventado, pero debe pasar por la misma revisión previa a la ejecución.

Cómo reducir las alucinaciones antes de que lleguen al cliente

Incorpora evidencia y validaciones al proceso de generación, y define qué hará el sistema cuando falte cualquiera de las dos. Quien desarrolla se encarga de las comprobaciones; quien opera el servicio, de la fuente de referencia y la vía de escalamiento.

Basa las respuestas en fuentes pertinentes y vigentes

La generación aumentada por recuperación, o RAG, busca material externo y proporciona al modelo los pasajes pertinentes. Así, el redactor tiene material con el que trabajar. La explicación de Contextual Retrieval de Anthropic muestra por qué importa conservar el contexto de un pasaje recuperado: un fragmento aislado puede omitir la empresa, el período o el asunto que describe.

Para una función de soporte, elige la colección oficial de políticas e incorpora metadatos de producto, región, fecha de entrada en vigor y acceso. Filtra por esos campos antes de generar la respuesta. Recupera la norma de cancelación junto con sus excepciones; un párrafo separado de sus condiciones puede dar pie a una promesa incorrecta.

Para conocer datos actuales de una cuenta, consulta la base de datos o el servicio de la aplicación. Buscar en documentos no es una buena forma de saber si ya se envió el pedido de este cliente. Si esa consulta falla, devuelve un estado de información no disponible en lugar de sustituirla silenciosamente por conocimiento general.

Empieza con un flujo de recuperación sencillo. Utiliza RAG con agentes, en el que el modelo puede elegir pasos adicionales de recuperación, cuando las preguntas exijan búsquedas sucesivas en distintas fuentes. Esas búsquedas adicionales necesitan reglas de parada y las mismas comprobaciones de fuentes.

La pregunta útil para el diagnóstico es si el modelo recibió la evidencia correcta. Guarda los identificadores y las versiones de las fuentes junto con la respuesta, para que quien opere el sistema pueda distinguir un fallo de recuperación de una afirmación añadida sin respaldo.

Convierte «no lo sé» en un estado de la aplicación

La guía de Anthropic para reducir las alucinaciones recomienda permitir la incertidumbre, basar el trabajo en citas textuales, indicar las fuentes de respaldo y eliminar las afirmaciones no sustentadas. Traslada esas recomendaciones a un contrato de respuesta.

Define resultados explícitos para el modelo, como answered, needs_clarification e insufficient_evidence. No lo obligues a inventar una respuesta para completar un campo obligatorio cuando esa respuesta no existe. La interfaz debe convertir cada resultado en algo útil: una pregunta de seguimiento concreta, una explicación del registro que falta o una derivación con el contexto recuperado adjunto.

Una instrucción útil sería: «Utiliza únicamente las políticas y los registros de cuenta proporcionados. Si esos registros no permiten determinar la respuesta, identifica la información que falta. No deduzcas que el cliente cumple los requisitos a partir de casos similares». Ponla a prueba cuando falte evidencia, no solo con preguntas fáciles.

No disponer de una respuesta no es lo mismo que rechazar una solicitud por seguridad, agotar el tiempo de espera de una herramienta o recibir una solicitud no autorizada. Mantén esos estados separados en los registros para que el responsable adecuado pueda resolver cada problema.

Haz que las citas puedan comprobarse mediante código

Una cita debe identificar evidencia que tu aplicación ya conoce. Asigna identificadores a las fuentes durante la recuperación y resuélvelos en el servidor a URL aprobadas. Evita pedir al modelo que reconstruya de memoria una bibliografía o una URL de destino.

Comprueba tres propiedades distintas:

• Existencia: el identificador citado pertenece al material autorizado que se proporcionó para esta solicitud.
• Cita textual: el texto citado aparece en la versión exacta de la fuente utilizada para responder.
• Respaldo: ese pasaje sustenta la afirmación para la situación de este cliente.

Las dos primeras son comprobaciones sencillas mediante código. La tercera requiere una regla del dominio, un campo estructurado fiable o una revisión aparte de la relación entre afirmación y evidencia. Encontrar la expresión «cumple los requisitos» en un documento no demuestra que un cliente concreto los cumpla.

La documentación de citas de Anthropic describe citas vinculadas a documentos que ayudan a localizar la evidencia. Una referencia a la fuente facilita la auditoría de una respuesta; no resuelve si esa fuente está vigente, es autorizada o se interpretó correctamente.

Usa salidas estructuradas y después valida los valores

Las salidas estructuradas restringen la respuesta a un esquema: una definición de los campos y tipos de valores permitidos. Facilitan la creación de comprobaciones en la aplicación. La guía de Structured Outputs de OpenAI advierte expresamente que las respuestas aún pueden contener errores y que una entrada incompatible puede provocar alucinaciones si el contrato de respuesta no ofrece una alternativa adecuada.

Antes de ejecutar una llamada a una herramienta, valida la operación, los argumentos obligatorios, las unidades, los valores permitidos, la existencia del registro y los permisos de quien realiza la llamada. Determina la organización o cuenta cliente y el usuario autenticado en el código de la aplicación. Cuando corresponda, deja que el modelo elija entre los registros autorizados; nunca consideres que un identificador de cliente proporcionado por el modelo demuestra que existe permiso de acceso.

Una llamada exitosa a una herramienta también necesita una respuesta veraz para el cliente. No afirmes que una cancelación se completó si la herramienta devolvió un estado pendiente o un error. Usa el estado devuelto como referencia para el mensaje final. La guía del sitio sobre controles de seguridad para agentes de IA explica los límites que deben rodear esas acciones.

Cómo detectar alucinaciones en un LLM: una comprobación ejecutable

Para un campo factual bien delimitado, compara el valor propuesto con un registro aprobado y construye la respuesta desde la aplicación. Así obtienes una garantía más sólida para ese campo que evaluando si un texto libre parece coherente.

El siguiente ejemplo de Python utiliza datos ficticios de una política de soporte con fines ilustrativos, no una política empresarial real. Guárdalo como verify_answer.py y ejecuta python3 verify_answer.py. Solo utiliza la biblioteca estándar y no realiza llamadas a ninguna API.

# Records must be filtered for the caller's access and policy scope
# before reaching this function. These are illustrative fixtures.
records = {
    "support-policy": {
        "text": "The support channel for this workspace is email.",
        "current": True,
        "fields": {"support_channel": "email"},
    }
}


def validate(result, sources):
    keys = {"status", "field", "value", "source_id", "quote"}
    if not isinstance(result, dict) or set(result) != keys:
        return False
    if result["field"] != "support_channel":
        return False
    if result["status"] == "unknown":
        return all(result[k] is None
                   for k in ("value", "source_id", "quote"))
    if result["status"] != "answered":
        return False
    if not all(isinstance(result[k], str)
               for k in ("value", "source_id", "quote")):
        return False
    source = sources.get(result["source_id"])
    if source is None or source["current"] is not True:
        return False
    quote = result["quote"].strip()
    return (
        bool(quote)
        and quote in source["text"]
        and result["value"]
        == source["fields"].get(result["field"])
    )


proposal = {
    "status": "answered",
    "field": "support_channel",
    "value": "chat",
    "source_id": "support-policy",
    "quote": "The support channel for this workspace is email.",
}

if not validate(proposal, records):
    print("Hold: evidence or value check failed.")
elif proposal["status"] == "unknown":
    print("I cannot confirm the support channel from these records.")
else:
    print(f"Your support channel is {proposal['value']}.")

La respuesta propuesta, chat, no pasa la validación aunque la cita textual sea auténtica. Si el valor es email, sí pasa esta comprobación limitada. Es el campo fiable, y no solo la coincidencia de la cita, lo que permite determinar la respuesta.

Es importante entender el límite: este validador no puede establecer si una explicación de formato libre es verdadera, si la persona responsable de la política introdujo el dato correcto o si funcionó el filtro de acceso previo. Su rama unknown valida una estructura de respuesta permitida, no si era necesario abstenerse de responder. Evalúa esas cuestiones con comprobaciones y pruebas separadas. Para datos fijos de alto impacto, una plantilla completada con información fiable puede eliminar por completo la necesidad de generar texto.

Evaluaciones que premian tanto acertar como saber detenerse

Una evaluación, o eval, es una prueba repetible que compara tu aplicación con el comportamiento esperado. Diséñala a partir de los fallos que afectan a los clientes y ejecútala cuando cambie el modelo, el prompt, el índice de recuperación, el esquema de las herramientas o la política.

Registra los resultados por separado: respuesta correcta y respaldada, respuesta sin respaldo, abstención adecuada, abstención innecesaria y acción propuesta no válida. Un promedio único oculta si las mejoras provienen de una evidencia mejor o simplemente de rechazar más preguntas.

Utiliza código convencional para comprobar valores exactos, pertenencia de las fuentes al conjunto autorizado, campos obligatorios, permisos y resultados de herramientas. Recurre a un modelo evaluador para cuestiones que dependen del lenguaje, como determinar si un pasaje respalda una paráfrasis, y calibra sus decisiones con ejemplos revisados por personas. Un LLM como juez sigue siendo otro modelo falible, no una fuente independiente de hechos.

Promptfoo es una herramienta de evaluación cuyas aserciones evaluadas por modelos incluyen la exactitud factual frente a una referencia y la fidelidad al contexto proporcionado. Esa distinción es útil: una respuesta puede coincidir con un documento obsoleto y seguir siendo incorrecta hoy. Una vez definido qué significa superar una prueba, utiliza la guía de Promptfoo para preparar el entorno de evaluación.

Conserva juntos, en la traza de cada prueba, la solicitud, la evidencia recuperada, los argumentos propuestos, el resultado de la herramienta ejecutada y la respuesta final. Cuando un caso falle, ese registro indicará dónde intervenir. Marca como fallos explícitos las citas ausentes y los argumentos no válidos, aunque el texto reciba una valoración favorable del modelo evaluador.

¿Qué se está exagerando?

RAG no convierte todas las respuestas en verdaderas. Un pasaje útil puede recuperarse e interpretarse mal; uno desactualizado puede citarse a la perfección. Prueba la recuperación y la generación por separado, y asigna a alguien la responsabilidad sobre la colección de fuentes.

Una ventana de contexto más amplia no sustituye la selección de fuentes. La guía de Anthropic sobre ingeniería de contexto advierte que la capacidad de recuperar información y la precisión pueden deteriorarse a medida que aumenta el contexto. Incluye la norma pertinente, sus excepciones y la evidencia necesaria de la cuenta. Volcar todos los documentos en el prompt no es una política de actualización.

Que un segundo modelo diga «parece correcto» no constituye una verificación por sí solo. Proporciona a los revisores la evidencia real y un criterio claro. Sin evidencia independiente, la coincidencia entre modelos puede conservar la misma suposición sin respaldo.

Un JSON válido no certifica que la respuesta sea correcta. El esquema puede exigir un identificador de fuente y un argumento numérico; tu aplicación aún debe comprobar que la fuente existe y que el número tiene el significado adecuado.

Los límites que importan son las preguntas que tus fuentes no pueden responder, los campos que tus comprobaciones no pueden verificar y las acciones que no puedes revertir de forma segura. No existe un porcentaje universal de alucinaciones que indique si tu flujo de trabajo concreto está listo.

Un plan para que tu equipo pequeño empiece esta semana

Actúa ya si tu función hace promesas factuales a los clientes o modifica registros de negocio. Si solo prepara borradores que una persona responsable ya contrasta con las fuentes, empieza por el conjunto de evaluación y mejora esa revisión antes de añadir una arquitectura automatizada compleja. Una consulta determinista que ya devuelve campos de una fuente autorizada puede no necesitar ningún modelo.

Este es un plan inicial sugerido, no una prueba de que una semana de trabajo garantice la fiabilidad en producción.

La primera acción del lunes es tomar una respuesta incorrecta reciente y conservar su traza completa. Identifica si la evidencia faltaba, estaba desactualizada, se interpretó mal o se ignoró. Añade la comprobación más sencilla que detecte ese fallo y convierte el incidente en un caso permanente de regresión.

Preguntas frecuentes sobre las alucinaciones de los LLM

Para recibir guías prácticas sobre cómo crear flujos de trabajo fiables con IA, suscríbete al boletín.