กรณี Therac-25 (2021)

 (thedailywtf.com)
2 คะแนน โดย GN⁺ 2025-08-28 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • เกิดอุบัติเหตุร้ายแรงกับ เครื่องฉายรังสีทางการแพทย์ Therac-25
  • ผู้ป่วยหลายรายได้รับรังสีเกินขนาดอย่างรุนแรงจาก ข้อบกพร่องของซอฟต์แวร์
  • ปัญหาเกิดขึ้นหลังจากแทนที่ระบบความปลอดภัยเดิมด้วย ระบบควบคุมดิจิทัล
  • การขาด การวินิจฉัยข้อบกพร่องและการสื่อสาร ทำให้การระบุสาเหตุของอุบัติเหตุล่าช้า
  • เหตุการณ์นี้ตอกย้ำความสำคัญของ ความน่าเชื่อถือของอัลกอริทึม และการทดสอบอย่างรัดกุมในฐานะบทเรียนด้านความปลอดภัยสำคัญ

ภาพรวมกรณี Therac-25

  • Therac-25 ถูกใช้อย่างแพร่หลายในฐานะ อุปกรณ์การแพทย์สำหรับการฉายรังสีรักษา
  • อุปกรณ์นี้มีหน้าที่ฉาย รังสีในปริมาณสูง ให้แก่ผู้ป่วยมะเร็ง
  • ระบบความปลอดภัยแบบ interlock เชิงกลในอดีตถูกแทนที่ด้วย ระบบควบคุมบนพื้นฐานซอฟต์แวร์
  • แต่การเปลี่ยนแปลงนี้ทำให้ความเสี่ยงของ ข้อผิดพลาดของซอฟต์แวร์ เพิ่มสูงขึ้น

ลำดับการเกิดอุบัติเหตุ

  • โปรแกรมเกิดข้อบกพร่องเมื่อมีลำดับการทำงานบางแบบหรือ การป้อนข้อมูลต่อเนื่องอย่างรวดเร็ว
  • ส่งผลให้ ระบบความปลอดภัยทำงานได้ไม่ถูกต้อง และผู้ป่วยได้รับรังสีที่มีความเข้มเกินกว่าที่ออกแบบไว้
  • ระหว่างปี 1985~1987 เกิด กรณีได้รับรังสีเกินขนาดอย่างรุนแรงในผู้ป่วยหลายราย และมีผู้เสียชีวิตบางส่วน
  • ในระยะแรกมีแนวโน้มที่จะมองข้าม ปัญหาซอฟต์แวร์ ว่าเป็นสาเหตุของความขัดข้องของเครื่องฉายรังสี

สาเหตุของปัญหา

  • ในกระบวนการตรวจสอบความน่าเชื่อถือ มีเพียง การทดสอบแบบง่ายที่ไม่สะท้อนสภาพแวดล้อมทางคลินิกจริง
  • เกิดข้อผิดพลาดของอัลกอริทึมในสถานการณ์สุดขั้วจาก การจัดการข้อผิดพลาดและการดูแล interlock ที่ไม่เพียงพอ
  • การไม่มี ระบบรายงานปัญหาและการสื่อสาร ที่ชัดเจนระหว่างผู้ผลิตกับโรงพยาบาล ทำให้การรับรู้และแก้ไขข้อบกพร่องล่าช้า
  • เหตุการณ์นี้ถูกประเมินว่าเป็นความล้มเหลวของ การออกแบบซอฟต์แวร์ที่ยึดความปลอดภัยเป็นศูนย์กลาง

บทเรียนสำคัญ

  • ในการออกแบบอัลกอริทึมที่เกี่ยวข้องโดยตรงกับความปลอดภัย จำเป็นต้องมี การตรวจสอบอย่างเข้มงวดและ defensive programming
  • ต้องมี การทำชุดกรณีทดสอบให้หลากหลาย และการจำลองตามสถานการณ์การใช้งานจริง
  • เน้นการนำ ลูปจัดการข้อผิดพลาดและระบบบันทึก log ไปใช้อย่างเป็นระบบ
  • ในสาขาที่ต้องการความน่าเชื่อถือสูง ต้องตระหนักถึง ความเสี่ยงจากการพึ่งพาการควบคุมด้วยซอฟต์แวร์เพียงอย่างเดียว
  • กรณีนี้เป็นตัวอย่างสำคัญที่เตือนให้วงการวิศวกรรมซอฟต์แวร์และอุตสาหกรรมอุปกรณ์การแพทย์ทั่วโลกเห็นถึงความสำคัญของ ความน่าเชื่อถือของอัลกอริทึม การจัดการความปลอดภัย และระบบการสื่อสาร

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2025-08-28
ความคิดเห็นจาก Hacker News

  • ข้อนี้เน้นว่า คุณภาพซอฟต์แวร์ไม่ได้เกิดขึ้นเพียงเพราะมีนักพัฒนาที่เก่ง แต่เป็นผลลัพธ์สุดท้ายของกระบวนการทั้งองค์กร ซึ่งกระบวนการนี้ส่งผลไม่ใช่แค่ต่อแนวปฏิบัติด้านการพัฒนาเท่านั้น แต่รวมถึงการทดสอบ ผู้บริหาร ไปจนถึงฝ่ายขายและงานบริการด้วย บทเรียนที่เราได้จากกรณี Therac-25 คือ ระบบชนิดข้อมูล, unit test หรือการเขียนโค้ดเชิงป้องกันอย่างเดียว ไม่ได้แก้ปัญหาทุกอย่าง ผมคิดว่าความล้มเหลวที่แท้จริงคือการใช้เวลานานเกินไปกว่าจะมีการรายงานอุบัติเหตุ สอบสวน และแก้ไข ล่าสุดพอดแคสต์ Cautionary Tales ก็พูดถึงเรื่องนี้ด้วย โดยประเด็นที่น่าประทับใจคือ ใน Therac-25 ผู้ใช้เจอข้อผิดพลาดที่ไม่ทราบสาเหตุซ้ำๆ แต่ข้อมูลนั้นกลับไม่ถูกส่งต่อไปถึงคนที่สามารถแก้ไขได้อย่างเหมาะสม (ลิงก์พอดแคสต์)

    • ผมไม่เห็นด้วยกับความเห็นนี้ ผมมีประสบการณ์ออกแบบชิ้นส่วนอากาศยานมานาน และหลักการสำคัญมีเพียงข้อเดียวคือ ความล้มเหลวเพียงจุดเดียวต้องไม่สามารถนำไปสู่อุบัติเหตุได้ วิธีทำให้เป็นจริงไม่ใช่การ "เขียนซอฟต์แวร์ให้ดี" หรือ "ทดสอบให้พอ" แต่คือการมี "ระบบอิสระที่สามารถป้องกันได้ แม้ซอฟต์แวร์จะทำงานแย่ที่สุด" สำหรับกรณี Therac-25 จำเป็นต้องมีอุปกรณ์ตรวจจับรังสีที่ตัดการทำงานอัตโนมัติเมื่อเกินค่าความปลอดภัย และต้องออกแบบทางกายภาพให้ไม่สามารถปล่อยรังสีเกินขนาดได้ตั้งแต่ต้น

    • ผมเองก็กำลังจะมาแนะนำพอดแคสต์นั้นเหมือนกัน โดยเฉพาะถ้าคุณสนใจบั๊กซอฟต์แวร์ก็น่าฟังมาก เรื่องที่น่าสนใจคือ แม้แต่เครื่องรุ่นแรกๆ ที่ยังควบคุมแบบแมนนวลก็มีข้อบกพร่องแบบเดียวกัน แต่ฟิวส์ลัดวงจรทำให้ข้อบกพร่องนั้นไม่กลายเป็นเหตุจริง จึงนับเป็นตัวอย่างที่ยอดเยี่ยมของ Swiss Cheese Model (ดู Swiss Cheese Model)

    • ผมอยากย้ำว่าซอฟต์แวร์ส่วนใหญ่ไม่ได้เกี่ยวข้องกับชีวิตคนโดยตรง ในกรณีส่วนมาก ถ้าพัง ผลก็แค่หน้าเว็บโหลดช้า รายงานเต็มไปด้วย NaN หรือไม่ก็ต้องเริ่มงานแบตช์ด้วยมือ การที่คนเสียชีวิตจากปัญหาคุณภาพซอฟต์แวร์นั้นพบได้น้อย และผมคิดว่านักพัฒนาที่ทำซอฟต์แวร์ประเภทนั้นก็น่าจะตระหนักถึงความรับผิดชอบของตัวเองดี

    • บริษัทที่ผมเคยทำงานด้วยผลิตอุปกรณ์ถ่ายภาพและอุปกรณ์วิทยาศาสตร์ที่ขึ้นชื่อเรื่องคุณภาพสูงสุด มันแพงมาก แต่ลูกค้าก็ยอมรับว่าคุ้มค่า ผมได้สัมผัสจริงว่าคุณภาพไม่ได้เป็นแค่ผลของกระบวนการ แต่ท้ายที่สุดแล้วมาจาก "วัฒนธรรม" ขององค์กร

    • นักพัฒนาหลายคนคิดว่าถ้าไม่ได้ทำระบบที่ต้องการความเชื่อถือสูง ปัญหาเรื่องคุณภาพก็ไม่เกี่ยวกับตน ซึ่งเป็นความคิดที่ผิดอย่างสิ้นเชิง ความล้มเหลวของซอฟต์แวร์ที่ดูเล็กน้อยก็อาจส่งผลมหาศาลต่อชีวิตคนหรือบริษัทใดบริษัทหนึ่งได้ เช่น ไปขวางกระบวนการสำคัญ ทำให้ข้อมูลชีวิตหรือข้อมูลเวชระเบียนเสียหาย หรือทำให้จ่ายเงินซื้อสินค้าที่จำเป็นมากไม่ได้

  • มีคนหนึ่งในคอมเมนต์ของบทความกล่าวว่า ในวงการแพทย์ช่วงยุค 80–90 มีการรับรู้กันแรงมากว่าคอมพิวเตอร์เป็นสิ่งอันตราย แม้ถึงต้นถึงกลางยุค 2000 เวชระเบียนก็ยังเขียนด้วยมือบนกระดาษ ตอนที่ผมเคยเข้าไปร่วมโครงการทดลองเวชระเบียนอิเล็กทรอนิกส์ใน ICU ชั่วคราว ผมทำหน้าที่ดูแลเซิร์ฟเวอร์ และบุคลากรทางการแพทย์ทุกคนเกลียดระบบนี้มาก สมัยนั้นยังไม่มีแท็บเล็ตด้วยซ้ำ การเปิดดูหรือแก้ไขบันทึกผ่านคอมพิวเตอร์จึงไม่สะดวก ทุกคนคุ้นกับการเขียนคำสั่งยาลงในชาร์ตข้างเตียงทันที และตรวจหรือแก้ได้เดี๋ยวนั้น การสูญหายของข้อมูลหรือการเข้าถึงที่ล่าช้าอาจถึงตายได้ ดังนั้นแพทย์ไม่ได้เกลียดคอมพิวเตอร์แบบไร้เหตุผล แต่รู้สึกว่ามันอันตรายกว่าปากกากับกระดาษจริงๆ ผมคิดว่าหลังจากนั้นสถานการณ์คงดีขึ้น แต่ก็ยังเป็นสิ่งที่ควรระวังอยู่

    • ตอนนี้บริษัทอย่าง Chipsoft แทบผูกขาดโลก IT โรงพยาบาลอยู่แล้ว เก็บเงินแพงมาก แต่คุณภาพซอฟต์แวร์กลับย่ำแย่ และยิ่งผู้ขายใหญ่ขึ้น ทางเลือกก็ยิ่งน้อยลง ผมไม่เข้าใจว่าทำไมเราถึงยอมให้มีผู้ขายที่เป็นปฏิปักษ์แบบนี้ได้

    • ทุกวันนี้ก็ยังมีกรณีที่ระบบสารสนเทศล่มจนบุคลากรทางการแพทย์ต้องกลับไปใช้ปากกากับกระดาษอยู่ ผมไม่เข้าใจว่าทำไมระบบเหล่านี้ถึงไม่มี redundancy นี่แหละที่น่าตกใจว่าเป็นสินค้าที่ขายเชิงพาณิชย์อยู่ในตอนนี้

    • ในสหรัฐฯ และยุโรป EMR (เวชระเบียนอิเล็กทรอนิกส์) ไม่ถูกจัดเป็นอุปกรณ์การแพทย์ จึงหลุดพ้นจากกฎระเบียบจำนวนมาก ลิงก์บทความที่เกี่ยวข้อง

  • ถ้าเทียบกับคดีอื้อฉาวของไปรษณีย์อังกฤษก็น่าสนใจ แม้จะเป็นคนละกรณีกันโดยสิ้นเชิง แต่ทั้งสองกรณีมีจุดร่วมคือสมมติฐานที่ผิดว่า "ซอฟต์แวร์ไม่มีทางผิด" จากมุมมองนักพัฒนา นี่เป็นความคิดที่น่าขำมาก แต่สำหรับคนที่ไม่ใช่ผู้เชี่ยวชาญ ความเปราะบางของซอฟต์แวร์เป็นเรื่องเข้าใจได้ยาก มีวัฒนธรรมที่ตั้งต้นจากการเชื่อว่าซอฟต์แวร์ไม่น่าจะมีข้อบกพร่อง และจึงแทบไม่ทดสอบกันอย่างจริงจังด้วยซ้ำ

    • อันที่จริงแม้แต่นักพัฒนาก็มักเชื่อมั่นในซอฟต์แวร์มากเกินไป ผมคิดเสมอว่าระบบทุกตัวที่ผมพัฒนาขึ้นสามารถพังได้ทุกเมื่อ เพราะแบบนั้นผมจึงจะไม่ขึ้นรถไร้คนขับเด็ดขาด ผมแปลกใจที่ผู้ใช้ HN ดูจะชอบการเป็นเบต้าเทสเตอร์ของเทคโนโลยีใหม่กันมาก แน่นอนว่ามีคนบอกว่ารถไร้คนขับปลอดภัยกว่าในเชิงสถิติ แต่เหตุผลหนึ่งก็เพราะคนขับรอบข้างต่างหากที่ขับอย่างระมัดระวังให้ นอกจากนี้รถไร้คนขับยังเป็นระบบใหม่ที่ไม่มีการกำกับดูแลโดยมนุษย์และความสามารถในการแทรกแซงโดยตรง หรือมาตรฐานที่เข้มงวดพอ และผมคิดว่านั่นคือปัญหา

    • ผมคิดว่าในเครื่องจักรไฟฟ้าหรือเครื่องกลแบบดั้งเดิมส่วนใหญ่ การสึกหรอของชิ้นส่วนเป็นสาเหตุหลักของความขัดข้อง และเพราะซอฟต์แวร์ไม่สึกหรอ ผู้คนจึงค่อยๆ หลงเชื่อผิดๆ ว่ามันย่อมเชื่อถือได้มากกว่า

    • ผมคิดว่าคดีไปรษณีย์ร้ายนั้นมีเจตนาร้ายกว่ามาก ผู้บริหารระดับสูงได้รับแรงจูงใจตามจำนวนเงินที่เก็บจากเจ้าของสาขาได้ และยังโกหกศาลกับรัฐมนตรีเรื่องความน่าเชื่อถือของซอฟต์แวร์ด้วย เมื่อเทียบกันแล้ว Therac-25 ใกล้เคียงกับความผิดพลาดโดยสุจริตมากกว่า

  • ผมมีลางสังหรณ์ว่าเหตุการณ์คล้าย Therac-25 จะเกิดขึ้นอีกในไม่ช้า มีคนจำนวนมากเกินไปที่ปล่อย AI agent ทำงานแบบ YOLO และถ้าโมเดลอย่าง Claude หรือ Gemini ถูกต่อเข้ากับฮาร์ดแวร์จริงผิดๆ วันหนึ่งก็น่าจะเกิดอุบัติเหตุแน่ AI แบบ agent ยังไม่พร้อมสำหรับโลก embedded systems และพอจินตนาการถึงการนำ AI ไปใช้กับอุปกรณ์อย่างเครื่องฉายรังสีแบบไม่รับผิดชอบ ก็มีแต่จะรู้สึกน่ากลัว

    • ในคดี Horizon ของไปรษณีย์อังกฤษ มีเจ้าของสาขาหลายคนฆ่าตัวตาย และชีวิตของคนอีกหลายสิบคนพังทลาย ผมคิดว่าเราควรเรียนรู้จาก Therac-25 ว่าซอฟต์แวร์ทุกตัวสำคัญ ซอฟต์แวร์ทุกตัวมีความเสี่ยงที่จะทำร้ายใครบางคนได้ จึงต้องระมัดระวังอยู่เสมอ

    • AI ที่ไม่ใช่ agent ก็ "กำลังฆ่าคนอยู่แล้ว" ตามนิยามบางแบบ กรณีล่าสุดที่แชตบอต AI นำไปสู่การฆ่าตัวตายกลายเป็นประเด็นใหญ่ และหากต่อไปมีการใช้ AI ในพื้นที่ตัดสินใจสำคัญอย่างประกันสุขภาพ ก็มีโอกาสมากขึ้นที่เราจะเห็นคน "เสียชีวิตเพราะ AI" รถไร้คนขับและระบบอื่นๆ ก็ทำให้เกิดอุบัติเหตุถึงชีวิตมาแล้วหลายแห่ง แม้แต่บั๊กเล็กน้อยอย่างข้อผิดพลาดใน Excel ก็เคยส่งผลต่อสังคมในระดับหลายหมื่นหรือหลายแสนคนมาแล้ว แต่ AI เองก็น่าจะมีพื้นที่ให้หลบเลี่ยงความรับผิดได้มากเหมือนคดี Horizon เพราะหาตัวผู้รับผิดชอบได้ไม่ชัดเจน ผมยังรู้สึกว่าเครื่องมือ AI copilot ก็ยังอ่อนในงาน embedded อยู่ดี

    • เหตุการณ์ 737 MAX MCAS แม้จะเป็นความล้มเหลวในระดับระบบ แต่ก็เป็นตัวอย่างชัดเจนของปัญหาคุณภาพซอฟต์แวร์ขนาดใหญ่แบบนี้ ผมคิดว่าภัยพิบัติทำนองนี้จะเกิดซ้ำอีกในอนาคต

    • อุบัติเหตุเครื่องบินตกของ Boeing 737 MAX ก็เป็นตัวอย่างเด่นที่ซอฟต์แวร์คุณภาพต่ำคร่าชีวิตผู้คนไปราว 350 คน (ข้อมูล MCAS)

    • ตอนที่ผมลองใช้งาน embedded ด้วย AI agent รุ่นล่าสุด ผลลัพธ์ต่ำกว่าที่คาดมาก แม้แต่เว็บแอป CRUD ธรรมดา ถ้าโมเดลข้อมูลซับซ้อนขึ้น พอแปลงข้อมูลแค่สองสามชั้น LLM ก็สับสนบ่อยแล้ว เช่น อินพุตใช้ created_at, ตอนบันทึกใช้ created_on, และตอนส่งออกไปยังระบบภายนอกใช้ last_modified ถ้าชื่อฟิลด์ต่างกันแบบนี้ก็มักมีปัญหา

  • เรื่องเล่าที่ว่าในเครื่อง Therac-25 หากกดคีย์บางชุดผ่านเทอร์มินัล VT100 อาจทำให้เกิดการได้รับรังสีเกินขนาดภายในเสี้ยววินาทีนั้นชวนสะดุดใจมาก ผู้ใช้ที่ชำนาญสามารถกดคีย์ได้เร็วภายใน 8 วินาที และในกรณีนั้นอินพุตอาจไม่ถูกนำไปใช้ตามปกติ จนนำไปสู่อุบัติเหตุร้ายแรง พอเห็นปัญหาแบบนี้แล้วก็อดรู้สึกกังวลไม่ได้กับแนวโน้มปัจจุบันที่แม้แต่อินเทอร์เฟซอุตสาหกรรมหรือในรถยนต์ก็มุ่งไปทางหน้าจอสัมผัส

    • ใน UI เรามักใช้วิธีที่เรียกว่า optimistic update เพื่อปรับปรุงประสบการณ์ผู้ใช้ ทำให้หน้าจอดูตอบสนองเร็ว แต่การสะท้อนผลจริงจะไปซิงก์ทีหลัง ผมหวังว่าคนจะตระหนักให้ชัดว่าวิธีนี้ไม่ควรถูกใช้ในบริบทใดบ้าง

    • ในเครื่องคิดเลขของ iOS 11 เคยมีกรณีที่ถ้ากด "1+2+3" เร็วๆ จะคำนวณผิด (กรณีใน HN ที่เกี่ยวข้อง) แม้แต่เครื่องคิดเลขที่ดูเหมือนเล็กน้อยก็ยังมีรูปแบบความล้มเหลวแบบเดียวกันนี้

  • ผมสงสัยว่าในมหาวิทยาลัยยังมีการสอนกรณีอย่าง Therac-25 หรือกรณีด้านความปลอดภัย/จริยธรรมแบบนี้อยู่หรือไม่ ตัวผมเองเคยเรียนเรื่องนี้ในวิชาวิศวกรรมทั่วไป พร้อมกับเส้นโค้งอ่างอาบน้ำและวิธีคำนวณปั๊มหล่อเย็นซ้ำซ้อน จึงสงสัยว่าทุกวันนี้ยังอยู่ในหลักสูตรหรือเปล่า

    • ในชั้นเรียน machine interface ที่ Purdue ช่วงต้นยุค 90 มีการเน้นแนวคิดเรื่อง "hysteresis" (การตอบสนองหน่วง) อย่างมาก ต้องคำนึงเสมอว่าระบบอนาล็อกไม่ได้หยุดได้ทันทีแบบคอมพิวเตอร์ แต่มีพฤติกรรมหลากหลายได้ภายในช่วงการทำงาน

    • มีการพูดถึงหัวข้อคล้ายกันในวิชา systems engineering (ลิงก์วิชา MIT)

    • ผมได้เรียนกรณีแบบนี้ในหลักสูตรวิทยาการคอมพิวเตอร์ระดับมหาวิทยาลัยขึ้นไป และหลังจากนั้นพอไปทำงานใน medtech เรื่องนี้ก็ยังย้อนกลับมาอยู่ในหัวเสมอ

    • ผมจำได้ว่าในวิชาจริยธรรมวิศวกรรมเรียนจริงๆ แค่ Tacoma Narrows กับ Therac-25 เท่านั้น แถมจบในเลกเชอร์ชั่วโมงเดียว

    • เกิดความสงสัยขึ้นมาเลยลองทำแบบสำรวจเอง อยากรู้ว่าคนอื่นเคยเรียนวิชาแนวนี้ไหม (ลิงก์แบบสำรวจ)

  • เครื่องรุ่นก่อนหน้านี้มี hardware interlock อยู่ ต่อให้ซอฟต์แวร์มีปัญหา ผลก็จบแค่ความไม่สะดวก แต่เพราะมั่นใจเกินไปว่าซอฟต์แวร์เสถียร จึงถอด hardware interlock ออกเพื่อลดต้นทุน แล้วปล่อยให้มีแต่ซอฟต์แวร์คอยเฝ้าระวัง สุดท้ายปัญหาเล็กน้อยจึงลุกลามเป็นโศกนาฏกรรมร้ายแรง นี่เป็นตัวอย่างชัดเจนของความไม่สอดประสานกันจากหลายตำแหน่งหน้าที่

  • ผู้เขียนคอมเมนต์แรกของบทความเป็นทั้งแพทย์และผู้จบด้านวิทยาการคอมพิวเตอร์ และยังเป็นประธานของสมาคมวิชาชีพด้านการป้องกันการทารุณกรรมเด็ก (ลิงก์ประวัติ) แต่ในการวินิจฉัยการทารุณกรรมเด็กทางการแพทย์ ทุกวันนี้ก็ยังมีช่องโหว่มากจากข้อมูลและหลักฐานที่ผิดพลาด รวมถึงการให้เหตุผลแบบวนกลับเชิงสำรวจ การเข้าถึงความจริงเชิงวัตถุทำได้ยาก และในภาคปฏิบัติก็มักมีแนวโน้มจะมองเพียงข้อสังเกตไม่กี่อย่างว่าเป็น "การทารุณกรรมเด็กที่ไม่ต้องสงสัย" ช่วงหลังยังมี AI แบบกล่องดำที่อ้างว่าตรวจจับได้อย่างแม่นยำสูง ทั้งที่ตั้งอยู่บนข้อมูลที่ไม่สมบูรณ์ แต่ไม่สามารถได้คำทำนายที่ถูกต้องจากข้อมูลที่ผิดพลาดได้อยู่ดี (garbage in, garbage out) ผมกังวลว่าการวินิจฉัยด้วย AI ที่ไม่แม่นยำอาจนำไปสู่การถูกกล่าวหาว่าทารุณกรรมเด็กโดยไม่เป็นธรรม ครอบครัวแตกสลาย หรือการลงโทษที่ผิดพลาด (ข้อมูลอ้างอิงที่เกี่ยวข้อง, บทความทางคลินิก, AI และปัญหาข้อมูล, ลิงก์งานวิจัย)

  • ในรายงานปี 1993 มีการพูดถึงความจำเป็นของคุณสมบัติวิศวกรซอฟต์แวร์ด้านความปลอดภัยวิกฤต โดยระบุว่าไม่ควรมีใครเรียกตัวเองว่านักพัฒนาซอฟต์แวร์ด้านความปลอดภัยวิกฤตได้ เพียงเพราะผ่านการเรียนเขียนโปรแกรมมาไม่กี่ครั้ง และคาดการณ์ว่าหากเกิดเหตุแบบ Therac-25 ซ้ำอีก การรับรองที่เกี่ยวข้องจะกลายเป็นข้อบังคับ ในสหราชอาณาจักรก็มีการหารือเรื่องการออกแบบหลักสูตรบังคับที่จำเป็นแล้ว แต่ผ่านมา 32 ปี วันนี้ความเป็นจริงกลับไม่เป็นไปตามที่คาด

    • ผมทำงานมา 15 ปีในแคนาดาในฐานะ professional software engineer ที่ขึ้นทะเบียน แต่ไม่เคยรู้สึกถึงประโยชน์ที่จับต้องได้ จึงตั้งใจว่าจะเลิกต่ออายุคุณวุฒินี้ในไม่ช้า เคยมีการถกเถียงกันว่าจะทำให้การพัฒนาซอฟต์แวร์กลายเป็นสาขาวิศวกรรมที่มีโครงสร้างมากขึ้น แต่ตอนนี้ดูเหมือนประเด็นนั้นแทบหายไปแล้ว

    • ซอฟต์แวร์ด้านความปลอดภัยวิกฤตไม่ได้เรียนรู้กันในห้องเรียน แต่สร้างขึ้นจากประสบการณ์ภาคปฏิบัติและการฝึกฝนยาวนาน แม้จะมีมาตรฐานอย่างการบิน (Do-178) หรือภาคอุตสาหกรรม (IEC 61508) แต่ระดับการนำไปใช้จริงก็ยังขึ้นอยู่กับงบประมาณและกำหนดการ อย่างไรก็ตาม เมื่อเกิดอุบัติเหตุ ต่อให้มีผลการตรวจสอบหรือหลักฐานการ audit ครบถ้วน สำหรับผู้เสียหายก็แทบไม่มีความหมาย กฎและข้อบังคับทั้งหมดล้วนเกิดขึ้นหลังจากมีใครสักคนต้องสังเวยไปแล้ว

  • ซอฟต์แวร์ของ Therac-25 ถูกเขียนทั้งหมดโดยนักพัฒนาเพียงคนเดียว และหลังจากเขาออกจากบริษัทในปี 1986 ตัวตนของเขาก็ไม่เคยถูกเปิดเผย นักอ่านจำนวนมากอาจจินตนาการว่า "นักพัฒนาคนนั้นรวยจากโศกนาฏกรรมนี้และใช้ชีวิตเกษียณอย่างหรูหรา" แต่ในเวลานั้นต่างจากทุกวันนี้ นักพัฒนาได้รับค่าจ้างต่ำและแทบไม่ได้รับการยอมรับเลย ในยุค 80 คนสำคัญของบริษัทเทคโนโลยีคือพนักงานขาย และมีความเป็นไปได้ว่าค่าคอมมิชชันจากการขาย Therac-25 จะมากกว่าเงินเดือนของนักพัฒนาเสียอีก โดยเฉพาะเมื่อดูจากที่ตั้งของ AECL ยุคสมัย ลักษณะความเป็นองค์กรภาครัฐ และการเป็นซอฟต์แวร์ฝังตัว ทั้งหมดนี้ชี้ไปที่ค่าจ้างต่ำ ระดับประมาณ 30,000–50,000 ดอลลาร์แคนาดาในปี 1986 และถึงแม้จะแปลงเป็นมูลค่าปัจจุบันก็อยู่ราว 78,000–129,000 ดอลลาร์สหรัฐ โดยไม่มี stock option ใดๆ