El incidente de Therac-25 (2021)

• Se produjo un accidente fatal con la máquina médica de radiación Therac-25
• Múltiples pacientes sufrieron sobreexposición severa a la radiación debido a un defecto de software
• El problema surgió tras reemplazar los sistemas de seguridad existentes por un sistema de control digital
• La falta de diagnóstico del defecto y de comunicación retrasó la identificación de la causa del accidente
• Como lección clave de seguridad, se subraya la importancia de la confiabilidad de los algoritmos y de las pruebas exhaustivas

---

Resumen del incidente de Therac-25

• Therac-25 fue un equipo médico de radiación terapéutica ampliamente utilizado
• Este equipo se encargaba de administrar radiación de alta dosis a pacientes con cáncer
• Sustituyó los dispositivos de seguridad mecánicos tipo interlock por un sistema de control basado en software
• Sin embargo, este cambio incrementó el riesgo de que se produjeran errores de software

Cómo ocurrió el accidente

• El programa presentaba fallas con ciertas secuencias de operación o con entradas rápidas y consecutivas
• Como resultado, los mecanismos de seguridad no funcionaban correctamente, y los pacientes recibían radiación con una intensidad superior a la prevista en el diseño
• Entre 1985 y 1987 se registraron varios casos de sobreexposición grave en pacientes, y algunos fallecieron
• Al inicio, existía una tendencia a pasar por alto los problemas de software como causa de las fallas en la máquina de radiación

Causas del problema

• En el proceso de validación de confiabilidad solo se realizaron pruebas simples que no reflejaban el entorno clínico real
• La gestión deficiente de errores e interlocks provocó fallas del algoritmo en situaciones extremas
• La falta de un sistema claro de reporte de problemas y comunicación entre el fabricante y los hospitales retrasó la detección y solución del defecto
• Este incidente se evalúa como un fracaso del diseño de software centrado en la seguridad

Lecciones principales

• Al diseñar algoritmos vinculados directamente con la seguridad, se requieren validación exhaustiva y programación defensiva
• Es indispensable diversificar los casos de prueba y realizar simulaciones basadas en escenarios de uso real
• Se enfatiza la implementación sistemática de distintos bucles de manejo de errores y sistemas de registro
• En áreas donde se exige alta confiabilidad, debe reconocerse el riesgo de depender únicamente del software para el control
• Este incidente es un caso representativo que recordó a la ingeniería de software y a la industria de dispositivos médicos en todo el mundo la importancia de la confiabilidad de los algoritmos, la gestión de la seguridad y los sistemas de comunicación

[GN⁺]

Opinión de Hacker News

• Se enfatiza que la calidad del software no surge simplemente por tener buenos desarrolladores, sino que es el producto final de procesos que atraviesan a toda la organización. Ese proceso afecta no solo las prácticas de desarrollo, sino también las pruebas, la dirección e incluso ventas y servicio. La lección del caso Therac-25 es que los sistemas de tipos, las pruebas unitarias o escribir código defensivo no resuelven todo por sí solos. El verdadero fracaso, en mi opinión, fue que se tardó demasiado en reportar, investigar y corregir los accidentes. También lo trataron hace poco en el pódcast Cautionary Tales, y me impresionó que en Therac-25 los usuarios sufrían errores desconocidos de forma continua, pero eso no llegaba correctamente a quienes podían arreglarlo. (enlace al pódcast)

  • No estoy de acuerdo con esta opinión. Tengo muchos años de experiencia diseñando componentes de aeronaves, y el principio clave es uno solo: una sola falla no debe poder causar un accidente. La forma de lograrlo no es “escribir software de calidad” ni “probar lo suficiente”, sino tener “sistemas independientes que lo impidan incluso si el software se comporta de la peor manera posible”. En el caso de Therac-25, hacían falta un detector de radiación que cortara automáticamente al superar umbrales de seguridad, y un diseño físico que hiciera imposible emitir radiación excesiva.

  • Justo iba a recomendar ese pódcast también. Vale mucho la pena, sobre todo si te interesan los bugs de software. Un dato interesante es que incluso los equipos iniciales operados manualmente tenían el mismo defecto, pero un fusible se quemaba por una fuga eléctrica y evitaba que el defecto se materializara. Es un gran ejemplo del Swiss Cheese Model (referencia sobre el Swiss Cheese Model)

  • Quiero subrayar que la mayor parte del software no está directamente ligada a la vida o la muerte. En la mayoría de los casos, si falla, lo peor que pasa es que una página carga lento, un reporte sale lleno de NaN, o hay que iniciar manualmente un batch job. Es raro que alguien muera realmente por un problema de calidad de software, y supongo que quienes desarrollan ese tipo de software sí son muy conscientes de su responsabilidad.

  • La empresa donde trabajé fabricaba equipos fotográficos y científicos de la más alta calidad. Eran muy caros, pero los clientes reconocían que valían lo que costaban. Lo viví de primera mano: la calidad no es solo resultado de un proceso, sino que en última instancia nace de la cultura.

  • Muchos desarrolladores creen que, si no trabajan con sistemas de alta confiabilidad, los temas de calidad no les competen, y eso es completamente equivocado. Incluso fallas de software que parecen menores pueden tener un impacto enorme en la vida de alguien o en una empresa. Por ejemplo, bloquear un flujo importante, arruinar datos de vida o historiales médicos, o impedir el pago de un producto realmente necesario.

• Un comentarista del artículo mencionó que en los años 80 y 90 en el ámbito médico había una percepción muy fuerte de que las computadoras eran peligrosas. Incluso hasta inicios o mediados de los 2000, los historiales médicos se escribían a mano en papel. Participé brevemente en un proyecto experimental de historia clínica electrónica en una UCI, donde mi rol era administrar los servidores, y a todo el personal médico le disgustaba mucho el sistema. En esa época ni siquiera había tablets, así que revisar o modificar registros en una computadora era incómodo. Estaban acostumbrados a escribir todas las prescripciones directamente en la hoja al lado de la cama, con verificación y corrección inmediata. Como la pérdida de información o el retraso en el acceso podían ser fatales, no era que los médicos odiaran las computadoras sin razón: realmente sentían que eran más peligrosas que el papel y el bolígrafo. Supongo que la situación mejoró desde entonces, pero sigue siendo algo a tener presente.

  • Hoy empresas como Chipsoft prácticamente monopolizan el ecosistema de TI hospitalaria. Cobran carísimo y aun así la calidad del software es pésima, y mientras más grandes se vuelven, menos alternativas quedan. No entiendo por qué permitimos proveedores tan hostiles.

  • Todavía hay casos en que el personal médico vuelve al papel y lápiz por caídas de sistemas informáticos. No entiendo cómo estos sistemas no tienen redundancia. Sorprende que eso sea lo que hoy se vende como producto comercial.

  • En Estados Unidos y Europa, los EMR (expedientes médicos electrónicos) no se clasifican como dispositivos médicos, así que quedan libres de muchas regulaciones. Enlace al artículo relacionado

• Es interesante compararlo con el escándalo del servicio postal británico. Son casos totalmente distintos, pero ambos comparten la misma premisa equivocada: “el software no puede estar mal”. Desde la perspectiva de un desarrollador, esa idea resulta ridícula, pero para alguien no técnico es difícil entender la fragilidad del software. Había una cultura de asumir que el software no podía tener defectos, y ni siquiera se hacían pruebas como correspondía.

  • De hecho, hasta los propios desarrolladores a veces confían demasiado en el software. Siempre pienso que cualquier sistema que yo haya construido puede colapsar. Por eso jamás me subiría a un auto autónomo. Me sorprende que a los usuarios de HN parezca encantarles ser beta testers de tecnología nueva. Claro, dicen que los autos autónomos son estadísticamente más seguros, pero una de las razones es que los conductores alrededor manejan con más cuidado por ellos. Además, los autos autónomos son sistemas nuevos sin supervisión humana ni capacidad de intervención directa, o sin estándares lo bastante estrictos, y creo que ahí está parte del problema.

  • Creo que en la mayoría de las máquinas eléctricas y mecánicas tradicionales, el desgaste de los componentes era la causa principal de fallas, y como el software no se desgasta, la gente terminó creyendo erróneamente que por eso era inherentemente más confiable.

  • Creo que el escándalo del servicio postal fue mucho más malicioso. Los altos ejecutivos recibían incentivos según el dinero cobrado a los encargados de sucursales, y además mintieron a los tribunales y a los ministros sobre la confiabilidad del software. Comparado con eso, Therac-25 se parece más a un error honesto.

• Tengo el presentimiento de que pronto veremos un caso parecido a Therac-25. Hay demasiada gente operando agentes de IA en modo YOLO, y si modelos como Claude o Gemini se conectan mal a hardware real, tarde o temprano eso va a causar un accidente. La IA basada en agentes todavía está verde para sistemas embebidos, y da miedo imaginar aplicaciones irresponsables de IA en áreas como equipos de radiación.

  • En el caso Horizon del servicio postal británico, varios encargados de sucursales se suicidaron y decenas de vidas quedaron destruidas. Creo que del caso Therac-25 debemos aprender que todo software importa. Todo software tiene el potencial de dañar a alguien, así que siempre hay que tener cuidado.

  • Incluso la IA no agéntica ya está, bajo algunas definiciones, “matando personas”. Hace poco hubo mucha atención por casos en los que chatbots de IA estuvieron vinculados a suicidios, y si en el futuro la IA se usa en decisiones críticas como los seguros médicos, es muy probable que veamos más muertes “causadas por IA”. La IA ya provoca accidentes fatales en varios ámbitos, como los autos autónomos. Incluso bugs aparentemente pequeños, como errores en Excel, han tenido efectos sociales sobre decenas o cientos de miles de personas. Pero con la IA probablemente también habrá mucho margen para esquivar responsabilidades, como pasó en el caso Horizon. Además, siento que las herramientas de AI copilot todavía son deficientes en el ámbito embebido.

  • El caso del MCAS del 737 MAX, aunque fue una falla a nivel de sistema, es un ejemplo representativo de este tipo de grandes problemas de calidad de software. Creo que seguiremos viendo desastres así en el futuro.

  • Los accidentes del Boeing 737 MAX también son un ejemplo emblemático de cómo software de mala calidad se cobró unas 350 vidas (enlace sobre MCAS)

  • Cuando intenté usar agentes de IA recientes para trabajo embebido, el rendimiento estuvo por debajo de lo esperado. Incluso en apps web CRUD simples, cuando el modelo de datos se vuelve complejo, muchas veces los LLM se confunden con solo dos o tres niveles de transformación. Por ejemplo, si en la entrada el campo es created_at, al guardar pasa a created_on, y al enviarlo a un sistema externo se convierte en last_modified, ahí empiezan los problemas.

• Me impresionó la anécdota de que en la Therac-25 una secuencia específica de teclas en una terminal VT100 podía causar en un instante una sobreexposición masiva a radiación. Un usuario con experiencia podía teclear rápido en menos de 8 segundos, y en ese caso la entrada no se reflejaba correctamente, lo que podía terminar en un accidente fatal. Al ver problemas así, me inquieta la tendencia actual de llevar incluso interfaces industriales o automotrices hacia pantallas táctiles.

  • En UI se usa mucho el enfoque de optimistic update para mejorar la experiencia del usuario, y eso hace que la pantalla se actualice rápido aunque el cambio real se sincronice después. Ojalá se entienda bien en qué contextos eso no debe usarse.

  • En la calculadora de iOS 11 había un caso en que, si uno ingresaba rápidamente “1+2+3”, no calculaba correctamente (caso relacionado en HN). Incluso una calculadora, que parece algo trivial, puede tener este mismo modo de falla.

• Me pregunto si en la universidad enseñan casos como Therac-25 o temas de seguridad y ética similares. Yo aprendí este caso en una materia general de ingeniería, junto con la curva de bañera y métodos para calcular redundancia en bombas de enfriamiento, pero no sé si hoy estos temas siguen en el plan de estudios.

  • En una clase sobre interfaces de máquinas en Purdue a inicios de los 90 se enfatizaba el concepto de “histéresis” (respuesta retardada). Había que tener siempre presente que los sistemas analógicos no se detienen al instante como una computadora, y que pueden mostrar diversos comportamientos dentro de su rango de operación.

  • En clases de ingeniería de sistemas se tratan temas parecidos. (enlace a una clase del MIT)

  • Aprendí sobre estos casos en estudios universitarios o superiores de ciencias de la computación. Después, trabajando en medtech, seguían volviendo a mi mente.

  • Recuerdo que en ética de ingeniería literalmente solo vimos Tacoma Narrows y Therac-25. Y eso en una sola clase de una hora.

  • Me dio curiosidad y armé una encuesta por mi cuenta. Me interesa saber quiénes tuvieron clases sobre esto. (enlace a la encuesta)

• Los equipos anteriores tenían interlocks de hardware. Aunque hubiera problemas de software, el resultado no pasaba de ser una simple molestia, pero por la excesiva confianza en la estabilidad del software, esos interlocks se eliminaron para ahorrar costos y se pasó a depender solo de supervisión por software. Al final, un problema menor terminó convirtiéndose en una tragedia mortal. Es un caso representativo de disonancias en distintos niveles.

• El autor del primer comentario del artículo es médico y graduado en ciencias de la computación, además de presidente de una sociedad profesional relacionada con la prevención del maltrato infantil (enlace a su perfil). Sin embargo, en la evaluación médica del maltrato infantil todavía hay muchas fallas derivadas de datos y evidencias erróneas, además de razonamientos circulares exploratorios. Es difícil encontrar una verdad objetiva, y en la práctica existe la tendencia a considerar “maltrato infantil sin lugar a dudas” con base en unos pocos indicios. Últimamente también han surgido IA de caja negra que afirman detectar estos casos con alta precisión a partir de datos imperfectos, pero es imposible obtener predicciones correctas a partir de datos incorrectos (garbage in, garbage out). Me preocupa que diagnósticos imprecisos de IA terminen provocando falsas acusaciones de maltrato infantil, destrucción de familias o castigos injustos. (referencia relacionada, artículo clínico, IA y problemas de datos, enlace al estudio)

• En un informe de 1993 se mencionaba la necesidad de certificar a los ingenieros de software de seguridad crítica. Se planteaba que no cualquiera podía llamarse desarrollador de software crítico para la seguridad solo por haber tomado unas cuantas clases de programación, y se predecía que, si se repetían casos como Therac-25, ese tipo de certificación acabaría siendo obligatoria. En el Reino Unido ya se discutía incluso el diseño de planes de formación obligatoria. Pero 32 años después, la realidad es muy distinta.

  • Llevo 15 años como ingeniero de software profesional registrado en Canadá, pero no he visto beneficios prácticos reales y probablemente dejaré de renovar la certificación pronto. Hubo conversaciones para convertir el desarrollo de software en una disciplina de ingeniería más estructurada, pero ahora parece que casi todo eso se desvaneció.

  • El software de seguridad crítica no se aprende en el aula, sino con mucha experiencia práctica y formación prolongada. Existen estándares como Do-178 en aviación o IEC 61508 en la industria, pero el nivel real de aplicación depende del presupuesto y del calendario. Aun así, cuando ocurre un accidente, da igual que exista un rastro de auditoría: para las víctimas no significa nada. Todas las regulaciones y reglas, al final, nacen después de que alguien ya fue sacrificado.

• Todo el software de Therac-25 fue escrito por una sola persona, y después de que dejó la empresa en 1986 nunca se reveló su identidad. Muchos lectores podrían imaginar que “el desarrollador ganó mucho dinero con esta tragedia y ahora vive una jubilación lujosa”, pero en esa época, a diferencia de hoy, los desarrolladores estaban mal pagados y poco valorados. En los 80, las figuras principales en las tecnológicas eran los vendedores, y es muy posible que la comisión por vender una Therac-25 superara el salario anual del desarrollador. En particular, la ubicación de AECL, el contexto de la época, su carácter gubernamental y el hecho de tratarse de software embebido apuntan todos a salarios bajos. En 1986 eso habría sido del orden de 30 mil a 50 mil dólares canadienses, que incluso ajustados al valor actual equivalen apenas a entre 78 mil y 129 mil dólares estadounidenses, sin stock options.