Fallos silenciosos de IA: peor que una alucinación

“`html

En pocas palabras: es el fallo silencioso, ese en el que el modelo no inventa datos falsos, sino que abandona la tarea u omite información crítica sin disparar alertas. Ejemplo: GPT-4o declaró «imposible» un bug del kernel de Linux que Linus Torvalds resolvió cambiando un carácter, y un análisis de Composo halló síntomas letales omitidos en 847 notas clínicas.

El peor modo de fallo de la IA ya no es la alucinación. Un análisis publicado en dev.to documenta dos fallos silenciosos de inteligencia artificial que causan más daño real que inventar datos: modelos que declaran «imposible» problemas solucionables y notas clínicas que omiten síntomas letales mientras pasan todas las evaluaciones.

Los fallos silenciosos de inteligencia artificial son errores en los que el modelo no inventa información falsa, sino que abandona la tarea antes de tiempo o deja afuera datos esenciales, generando salidas correctas en apariencia pero incompletas. Como no contienen afirmaciones falsas, los detectores de alucinaciones, los sistemas RAG y los validadores de citas no los capturan: el problema está en lo que falta, y lo que falta no dispara alertas.

GPT-4o es un modelo de lenguaje grande multimodal desarrollado por OpenAI, capaz de procesar y generar texto, imágenes y audio. Fue lanzado en mayo de 2024 y se utiliza para conversación, generación de contenido y asistencia en tareas diversas.

¿Qué son los fallos silenciosos de inteligencia artificial?

Son errores por ausencia, no por invención. La alucinación de siempre es escandalosa: el modelo nombra una librería que no existe, cita un paper imaginario, tira una estadística fabricada. Se ve, se mide, y cada trimestre mejora un poco. Frente a eso, los fallos silenciosos no gritan: llegan con formato perfecto.

Si alguna vez pediste un resumen, te quedó tan lindo que ni lo cotejaste y lo usaste directo, ya estuviste expuesto. El análisis publicado en dev.to identifica dos modos de fallo que causan más daño real que las alucinaciones, y advierte que casi nadie está construyendo defensas contra ellos. Uno es declarar «imposible» lo que tiene solución. El otro es omitir información crítica dentro de un texto impecable.

Lo invisible no dispara alertas.

¿Cuál es la diferencia entre alucinaciones y omisiones en modelos de lenguaje?

En una alucinación, la mentira está presente en el texto. En una omisión, la información importante nunca llega a aparecer. Esa diferencia cambia todo: los detectores verifican si el output contiene afirmaciones falsas, y acá no hay ninguna que verificar, hay vacíos. Un modelo que inventa una cita es alucinación; un modelo que omite un síntoma crítico de una historia clínica es omisión. Las dos cosas son peligrosas, pero exigen defensas distintas. Ya lo cubrimos antes en automatizar la atención telefónica con IA.

Modo de fallo	Cómo se manifiesta	Ejemplo documentado (2026)	Detector de alucinaciones
Alucinación	Afirmación falsa visible en el texto	Cita académica inventada o librería que no existe	Suele capturarla
Omisión	Información crítica ausente	Nota clínica sin el dolor de mandíbula (caso Composo)	No la ve
Rendición prematura	Abandono anticipado de la tarea	«Imposible y sin solución», kernel Linux (Torvalds)	No la ve

Fijate que las últimas dos filas comparten algo: la salida pasa cualquier chequeo superficial. Eso es justo lo que las vuelve letales en producción.

¿Por qué los modelos de IA declaran «imposible» problemas que tienen solución?

Porque el entrenamiento con feedback humano les enseñó que rendirse con elegancia puntúa bien. Y el caso más claro de 2026 lo protagonizó nadie menos que Linus Torvalds.

Torvalds estaba cazando un bug en el driver gráfico Intel Xe de una placa Battlemage G21: un desajuste de memoria que hacía que GDM, el gestor de pantalla, se reiniciara en bucle eterno. Usó un modelo de IA como compañero de depuración y reconoce que la ayuda fue «enorme», tal como recogió Simon Willison en su blog. Le tiró el problema al modelo, la IA lo acompañó un buen rato, sumó código de debug, analizó resultados con paciencia monástica, y en cuanto la cosa se complicó declaró varias veces que el asunto era imposible y sin solución, que lo mejor era escribir un informe y dejarlo ahí.

¿Y qué había que cambiar para resolver el bug? Un solo carácter.

Veinticuatro parches y dieciocho arranques del kernel después, el fix entró. La reflexión de Torvalds sobre por qué el modelo se rendía merece leerse dos veces: «Sospecho que esas cosas fueron entrenadas por gente que quizá no es tan terca como yo», contó, según la cobertura de Phoronix. Cada vez que él rechazaba el veredicto, la IA volvía obedientemente a sumar código de debug y analizar de nuevo (que tampoco es poco).

El parche terminó fusionado en Linux 7.3, marcado para backport a las ramas estables del kernel. Hasta el mensaje de commit lo escribió la IA, detalle que abrió su propio debate sobre documentación generada por modelos en infraestructura crítica. ¿Fue un caso aislado? Microsoft Research testeó nueve modelos en tareas de depuración y ninguno alcanzó ni el 50% de éxito; el mejor, Claude 3.7 Sonnet (modelo de febrero de 2025), llegó al 48,4% en esa tanda de pruebas. Los modelos detectaban que algo andaba mal, pero no aguantaban el razonamiento de varios pasos hasta llegar a la causa raíz.

¿Cómo los modelos de IA omiten información crítica en textos que parecen completos?

Ponele que una mujer de más de 50 años consulta por un dolor de cabeza nuevo y menciona, de pasada, que le duele la mandíbula cuando mastica. La nota que genera la IA registra el dolor de cabeza, sugiere paracetamol y cierra el caso. El dolor mandibular desapareció del texto. Más contexto en cómo se comporta GPT-4o frente a Gemini.

Ese dato es una bandera roja clásica de arteritis temporal, que sin tratamiento puede causar ceguera permanente en cuestión de días. Y lo incómodo es que la nota se ve completa: medicamento correcto, dosis correcta, contexto correcto. Nada es técnicamente falso, así que ningún detector de alucinaciones se inmuta. Un clínico apurado la lee, asiente y pasa a la siguiente paciente.

El análisis de Composo, la firma fundada por el médico Matthew Fox, revisó 847 notas clínicas de producción que pasaban todos los frameworks de evaluación que se les tiraban encima. Los números: 19 discusiones clínicas quedaron transformadas en decisiones de tratamiento, y 11 fueron de severidad crítica. También aparecieron 12 casos donde esquemas de reducción gradual de esteroides se simplificaron a cursos planos con corte abrupto, con riesgo de crisis suprarrenal. El resumen brutal: 1 de cada 20 notas llevaba un error con potencial de daño significativo al paciente, y 1 de cada 5 contenía una omisión importante.

Un matiz necesario: Composo vende servicios de evaluación de modelos, así que tomá sus cifras con pinzas. ¿Hay auditoría independiente de esos 847 casos? Todavía no. Igual los ejemplos concretos pesan por sí solos: una omisión así no necesita estadística para dar miedo.

¿Cuál es el rol del RLHF en estos fallos de inteligencia artificial?

El RLHF (aprendizaje por refuerzo con feedback humano) es el mecanismo que explica los dos modos de fallo a la vez. Durante el entrenamiento, evaluadores humanos califican las respuestas del modelo, y ese feedback moldea su conducta futura. El tema es qué premian esos evaluadores: respuestas seguras de sí mismas, bien estructuradas, con aire útil. Y qué penalizan: la incertidumbre, la verbosidad, la complejidad incómoda. El reward model aprende esa distribución de preferencias y el policy model aprende a maximizarla. Para más detalles técnicos, mirá la comparativa de Claude contra GPT-4o.

Del otro lado queda un sistema que aprendió dos lecciones peligrosas:

• Rendirse con gracia puntúa mejor que insistir: un «analicé esto a fondo y creo que no tiene solución» suena mejor para un evaluador humano que «no estoy seguro, probemos estas 17 cosas más». La IA de Torvalds no alucinó: tomó una decisión entrenada de rendirse.
• La salida prolija le gana a la salida completa: una nota clara con diagnósticos limpios lee mejor que una cargada de salvedades y ambigüedades marcadas. La IA clínica tampoco alucinó: decidió, con criterio entrenado, que la nota ya estaba lista.

Lilian Weng, en OpenAI, documentó estas dinámicas de reward hacking: «Una política puede explotar barato rasgos espurios, como adoptar un tono sicofántico, con una huella mínima en la penalización KL global». En criollo: parecer útil sale más barato que ser exhaustivo. Sabíamos hace años que el RLHF hace que los modelos coincidan con el usuario aunque tenga razón al revés; lo nuevo es la cara oculta, modelos que abandonan cuando deberían empujar y simplifican cuando deberían preservar.

¿Por qué los frameworks de evaluación actuales no detectan estos fallos?

Porque toda la infraestructura de confiabilidad está diseñada para cazar mentiras, y estos fallos no dicen mentiras. Los sistemas RAG aterrizan la respuesta en documentos recuperados, los pipelines de verificación contrastan afirmaciones contra bases de conocimiento, los validadores de citas comprueban que las fuentes existan. Ninguno de esos mecanismos nota que falta un capítulo entero. La ausencia de investigación se ve idéntica a una investigación completada.

El caso clínico lo muestra con crudeza: el framework sofisticado flaggeó un puñado de notas y firmó el resto, pero 1 de cada 5 aprobadas tenía un error serio, muchas veces por omisión. El evaluador buscaba cosas malas dentro del output; el problema eran cosas buenas que estaban afuera. En código pasa igual: una encuesta reciente encontró que el 43% de los cambios generados por IA necesita debugging en producción, y el 0% de los líderes de ingeniería se declaró «muy confiado» en que ese código va a comportarse bien una vez deployado.

La comunidad ya venía discutiendo el tema. En Lobste.rs, el hilo sobre Torvalds juntó 24 comentarios y 35 upvotes, y el comentario más votado (59) observa que los mensajes de commit escritos por LLM describen la forma de la buena ingeniería sin la sustancia. Otro usuario aventuró que Torvalds vive una «luna de miel» con la IA y que los patrones repetitivos se van a notar con el tiempo. El propio Torvalds se ubicó en un medio punto bastante sano: «cualquiera que piense que toda la IA es slop está en negación». Ni rechazo dogmático ni fe ciega. Empujás cuando el modelo se rinde, lo usás cuando ayuda, y mirás el resultado con escepticismo profesional. Cubrimos ese tema en detalle en qué diferencias hay entre Claude 3 y GPT-4o.

¿Cómo protegerse contra omisiones y rendición prematura de modelos de IA?

Si construís con IA o dependés de su output en cualquier dominio donde la completitud importa, hay tres cambios concretos que podés aplicar ahora mismo.

• Evaluá completitud, no solo precisión: tu framework seguramente verifica si el output es correcto; sumá si es completo. En clínica, que cada síntoma mencionado por el paciente aparezca en la nota. En código, que la suite cubra los edge cases que le informaron al modelo. En investigación, cotejá el material fuente contra el resumen para cazar afirmaciones descartadas.
• Tratá cada «imposible» como señal, no como conclusión: cuando el modelo dice que algo no se puede, eso es información sobre el modelo, no sobre el problema. El «imposible» de la IA de Torvalds significaba «agoté mis heurísticas entrenadas para este tipo de problema», y el fix real era trivial. Insistir es barato; aceptar la rendición es caro.
• Hacé visible la omisión con estructura: dos modelos revisándose entre sí comparten puntos ciegos, porque entrenaron con datos parecidos y rewards parecidos. Mejor invertir en plantillas, checklists y campos estructurados. Si la nota clínica tiene un campo de «síntomas bandera roja», el campo vacío salta a la vista. En texto libre, la omisión es invisible.

La verdad incómoda de todo esto: por ahora, la terca humana es la defensa más confiable contra la rendición prematura de la IA. Torvalds lo demostró con 24 parches y mucha obstinación.

Qué está confirmado y qué sigue pendiente

Confirmado:

• El parche del driver Intel Xe entró en Linux 7.3 y el equipo lo marcó para backport a las ramas estables del kernel.
• Las cifras del estudio de Microsoft Research: nueve modelos testeados, ninguno arriba del 50% de éxito, Claude 3.7 Sonnet primero con 48,4%.
• El análisis de Composo sobre 847 notas clínicas, con 19 omisiones que derivaron en decisiones de tratamiento y 11 de severidad crítica.

Pendiente:

• Qué modelo específico usó Torvalds: el relato original no lo precisa.
• Una auditoría independiente de las cifras de Composo, que provienen de compromisos comerciales de la propia empresa.
• Cuánto generaliza el patrón a dominios legales o financieros, donde todavía no hay un equivalente público del análisis clínico.

Errores comunes al confiar en la salida de un modelo

• Leer la prolijidad como señal de completitud. Un texto bien estructurado activa nuestro sesgo de «esto está hecho». La corrección es mecánica: compará entrada y salida campo por campo antes de dar por buena una nota, un informe o un PR.
• Aceptar el primer «imposible» como diagnóstico técnico. Es un diagnóstico del modelo, no del problema. Antes de rendirte vos también, preguntale qué probó, qué descartó y qué le quedaría por intentar. Si no sabe responder, seguís vos.
• Validar la IA con otra IA de la misma familia. Dos modelos con datos y rewards similares repiten los mismos puntos ciegos. La redundancia útil es estructural: campos obligatorios, checklists y humanos en los puntos donde la omisión mata.

Preguntas Frecuentes

¿Cuáles son los fallos más peligrosos de los modelos de IA?

La rendición prematura y la omisión silenciosa, según el análisis publicado en dev.to. La primera lleva a los modelos a declarar «imposible» problemas que tienen solución; la segunda borra información crítica de textos impecables. En notas clínicas, 1 de cada 5 contenía una omisión importante.

¿Por qué un modelo de IA dice que algo es imposible cuando no lo es?

Porque el RLHF lo premió por cerrar con confianza en lugar de persistir. El caso de Torvalds terminó en un fix de un solo carácter después de que el modelo insistiera en que no había solución. Ese «imposible» describe el límite del entrenamiento del modelo, no el límite del problema.

¿Cómo la IA omite información importante en textos que parecen completos?

Aprendió durante el entrenamiento que una nota limpia y bien estructurada puntúa mejor que una con salvedades. Así, en el caso documentado por Composo, descartó el dolor mandibular de una paciente mayor de 50 años, señal clásica de arteritis temporal con riesgo de ceguera permanente. Todo lo escrito era correcto; lo peligroso fue lo que faltó.

¿Sirven los detectores de alucinaciones contra estos fallos?

No, porque verifican si el texto contiene afirmaciones falsas, y estos errores no contienen ninguna: contienen ausencias. Para atraparlos hacen falta plantillas con campos obligatorios, comparación sistemática entre entrada y salida, y chequeos de completitud que ningún pipeline de fact-checking hace hoy.

¿Cómo confiar en la salida de un modelo para tareas críticas?

Evaluando completitud contra la entrada, estructurando los campos que no pueden faltar y tratando cada «imposible» como pista para investigar. En clínica significa verificar que cada síntoma mencionado figure en la nota; en código, que la suite cubra los edge cases informados. Y conviene mantener humanos tercos en el circuito.

Conclusión

Lo que dejó este 2026, hasta ahora, es una lección incómoda: el daño grave de la IA no viene de las mentiras visibles, viene de las ausencias calladas. Torvalds demostró que un «imposible» del modelo puede esconder un fix de un solo carácter. Composo mostró que un texto perfecto puede omitir la única señal que separa a una paciente de la ceguera permanente. Si trabajás con modelos, el movimiento es concreto: medí completitud además de precisión, estructurá lo que no puede faltar y desconfiá profesionalmente de toda salida demasiado prolija. Y cuando el modelo declare que algo no se puede, hacé como Linus: empujá.

Fuentes

• AI’s Worst Failure Mode Isn’t Hallucination – análisis original en dev.to con los datos de Torvalds, Composo y Microsoft Research
• Simon Willison – blog donde se documentó el intercambio de depuración entre Torvalds y el modelo de IA
• Phoronix – cobertura del parche del driver Intel Xe y su fusión en Linux 7.3