Una alucinación de IA es un resultado que un sistema de IA presenta como plausible o fáctico, pero que es falso, no está respaldado o es incoherente con su material fuente. En los modelos de lenguaje generativo, una redacción fluida puede hacer que un detalle inventado parezca fiable, incluso cuando el modelo no tiene una base fiable para él.

Los modelos de lenguaje generan texto estimando continuaciones probables a partir de patrones en su entrenamiento y contexto. No comprueban automáticamente cada afirmación con una fuente verificada. Por lo tanto, una solicitud de una cita precisa, un dato que falte en la instrucción o una pregunta inusual pueden producir un contenido seguro pero incorrecto. Las herramientas de recuperación, la conexión a tierra y la validación pueden reducir algunos errores, pero cada una tiene límites y puede fallar a su manera.

Arquitectura y gobernanza

La alucinación es una propiedad de la arquitectura, no un fallo de esta. Esto no significa que cada resultado inexacto sea inofensivo o que las organizaciones deban aceptarlo sin controles. Significa que la gobernanza debe planificar los errores plausibles como un comportamiento esperado del sistema, en lugar de tratar un modelo como una base de datos que solo necesita corrección ocasional.

El nivel de verificación debe corresponderse con las consecuencias del uso. Un asistente para generar ideas puede necesitar un recordatorio claro de que las sugerencias requieren revisión. Un sistema utilizado para decisiones médicas, legales, financieras o de empleo necesita una validación más sólida, fuentes autorizadas, revisión documentada y un límite claro sobre lo que puede decidir. Un revisor humano debe tener la información y el tiempo para comprobar la respuesta, en lugar de limitarse a aprobar una pantalla llena de texto fluido.

Reducir la exposición y hacer visibles los errores

Las organizaciones pueden probar posibles modos de fallo antes de la implementación, incluidos datos faltantes, indicaciones ambiguas y entradas adversarias. Deben medir la precisión fáctica en tareas representativas, inspeccionar citas y enlaces de origen, y comprobar si el sistema señala la incertidumbre de forma adecuada. La evaluación debe continuar tras el lanzamiento, ya que los cambios en las indicaciones, modelos, fuentes de recuperación y el comportamiento del usuario pueden alterar los resultados.

El diseño puede facilitar la verificación: mostrar el material de origen, distinguir los hechos recuperados de la redacción generada y ofrecer a los usuarios una forma sencilla de señalar errores. Las políticas deben determinar qué resultados exigen confirmación independiente y prohibir que se utilicen respuestas sin respaldo como base única para decisiones de alto impacto. El registro de incidentes puede revelar patrones recurrentes y fundamentar actualizaciones en la formación, indicaciones, controles o el uso previsto.

Los usuarios también necesitan orientación sobre el hecho de que la fluidez no es prueba. Si un resultado afecta a otra persona, dinero, seguridad o un registro formal, la responsabilidad recae en las personas y la organización que utilizan el sistema. La pregunta relevante no es si un modelo puede equivocarse a veces, sino si el sistema está diseñado para que los errores puedan encontrarse, contenerse y corregirse antes de causar daños evitables.