Yazılımın hayatımızdaki yeri her geçen gün artarken, bilgisayar kontrollü sistemlerin karmaşıklığı ve olası hataları da önem kazanıyor. Özellikle insan sağlığı gibi kritik alanlarda, en küçük bir yazılım hatası dahi telafisi mümkün olmayan sonuçlar doğurabilir. 1980’li yıllarda Kanada ve Amerika Birleşik Devletleri’nde yaşanan Therac-25 vakası, bu gerçeği en acı şekilde gözler önüne seren, tıp teknolojileri ve yazılım mühendisliği tarihinde bir dönüm noktası olarak kabul edilen bir olaydır.
Bu makine, 1985-1987 yılları arasında altı hastanın aşırı radyasyon dozu alarak ciddi şekilde yaralanmasına, hatta dördünün ölümüne neden oldu. Peki, son teknoloji ürünü olarak tanıtılan bu cihaz, nasıl bir “katil makineye” dönüştü?
Therac-25’in Doğuşu: Daha Hızlı, Daha Ekonomik, Ama Daha Güvenli Mi?
Therac-25, Kanada merkezli Atomic Energy of Canada Limited (AECL) şirketi tarafından geliştirilen, kanser tedavisinde kullanılan bir radyoterapi cihazıydı. Cihazın temel amacı tümörleri hedef alarak çevredeki sağlıklı dokuya en az zararı vererek yüksek enerjili elektron ışınları veya X-ışınları (fotonlar) ile yok etmekti.
AECL, Therac-25’ten önce Therac-6 ve Therac-20 adında iki farklı model geliştirmişti. Bu önceki modeller, Fransız CGR şirketiyle işbirliği içinde üretilmiş ve bilgisayar kontrolünü mevcut donanıma bir “kolaylık” olarak eklemişti. Yani, bilgisayar olmasa bile makine kendi başına çalışabilen, donanım tabanlı güvenlik kilitlerine sahip sistemlerdi. Bir hata durumunda (örneğin yanlış mod seçimi), bu donanım kilitleri devreye girerek makinenin çalışmasını durdurur, hatta sigortasını attırırdı. Bu, operasyonel olarak zahmetli olsa da, hasta güvenliğini ön planda tutan bir yaklaşımdı.
Ancak, 1981’de AECL ve CGR arasındaki işbirliği sona erdiğinde, AECL Therac-25’i kendi başına tasarlamaya başladı. Therac-25’in en büyük yeniliklerinden biri, daha güçlü bir hızlandırıcıyı daha küçük bir alana, daha düşük maliyetle sığdırmayı sağlayan “çift geçişli hızlandırıcı” konseptiydi. En önemlisi, Therac-25 tamamen bilgisayar kontrollü olacak şekilde tasarlandı. Bu durum, operatörlerin makineyi daha hızlı kurmasını, hastalarla daha fazla zaman geçirmesini ve günde daha fazla hasta tedavi etmesini sağlıyordu. Ancak, bu bilgisayar kontrolüne geçişle birlikte, makinenin birçok donanım tabanlı güvenlik kilidi kaldırıldı ve bunların yerini yazılım tabanlı güvenlik kontrolleri aldı. Şirket, donanım kilitlerinin maliyetinden tasarruf etmek ve yazılıma olan güvenini artırmak amacıyla bu kararı almıştı.
Yazılımın geliştirme süreci de sorunluydu: Therac-25 yazılımı, tek bir kişi tarafından yıllar içinde PDP-11 assembly dili kullanılarak geliştirilmişti. Önceki Therac-6 ve Therac-20 sistemlerinin yazılımlarından parçalar kullanılmış olsa da, bu yeniden kullanılan yazılımların yeni sistemdeki davranışları yeterince test edilmemişti. Ayrıca, yazılıma ait neredeyse hiçbir dokümantasyon bulunmuyordu ve sistemin güvenlik analizi yapılırken yazılım neredeyse tamamen göz ardı edilmişti. Analistler, önceki yazılımların yıllarca hatasız çalışmasına dayanarak, yazılımda tasarım hatası olmadığını varsaymışlardı.
Korkunç Kazalar Zinciri Başlıyor
Therac-25, 1983 yılında piyasaya sürüldü. İlk birkaç yıl binlerce hasta için sorunsuz çalıştığı düşünüldü. Ancak 1985 ile 1987 yılları arasında altı vaka, makinenin ölümcül hatalarını ortaya çıkardı:
1. Marietta, Georgia (3 Haziran 1985): Göğüs kanseri tedavisi gören Katie Yarbrough, 10 MeV elektron tedavisi alırken “müthiş bir sıcaklık” hissetti. Teknisyen bunun imkansız olduğunu söylese de, birkaç hafta sonra hastanın sol göğsü alınmak zorunda kaldı ve sol kolu felç oldu. Hastanın 200 rad alması gerekirken, tahmini olarak 15.000 ila 20.000 rad radyasyon aldığı anlaşıldı. Bu olay, şirkete bir dava açılmasına rağmen AECL tarafından başlangıçta önemsenmedi.
2. Hamilton, Ontario (26 Temmuz 1985): Serviks kanseri tedavisi gören 40 yaşındaki bir kadın, beş saniye sonra “H-tilt” hatası veren makineden tedavi aldı. Operatör, “P” (Devam et) tuşuna beş kez basarak tedaviyi sürdürmeye çalıştı, ancak her seferinde makine durdu. Hasta, tedavi sonrası “elektrik çarpması” benzeri bir yanma hissi bildirdi. Hasta, aynı yılın Kasım ayında kanser nedeniyle hayatını kaybetse de, otopsi raporunda, ölmeseydi radyasyon nedeniyle kalça protezine ihtiyaç duyacağı belirtildi. Tahmini olarak 13.000 ila 17.000 rad radyasyon aldığı belirlendi. AECL, bu olayın nedenini mikro anahtar arızasına bağlayarak donanımda değişiklikler yaptığını ve güvenliği “beş kat artırdığını” iddia etti.
3. Yakima, Washington (Aralık 1985): Bir kadın hasta, Therac-25 ile tedavi gördükten sonra kalçasında paralel çizgili bir yanık deseni geliştirdi. Hastane personeli AECL’e durumu bildirdi, ancak şirket 24 Şubat 1986’da “bu hasarın Therac-25’in bir arızasından veya operatör hatasından kaynaklanmasının imkansız olduğu” yanıtını verdi. Hasta daha sonra cilt greftleri gerektiren doku nekrozu geliştirdi.
4. Tyler, Teksas (21 Mart 1986): Sırtındaki tümör için dokuzuncu tedavisini alan bir erkek hasta, operatörün yanlışlıkla “X-ışını” modunu seçip hızla “elektron” moduna geçmesiyle aşırı doz aldı. Makine “Malfunction 54” (Hata 54) mesajı verse de, operatör bu tür mesajlara alıştığı için “P” tuşuna basarak devam etti. Hasta, tedavi sırasında elektrik çarpması hissi ve yanık bildirdi. Video monitör ve dahili telefonun arızalı olması nedeniyle operatör hastanın zor durumda olduğunu hemen anlayamadı. Hasta, 16.500 ila 25.000 rad gibi devasa bir doz aldığı ve beş ay sonra aşırı dozun komplikasyonları nedeniyle hayatını kaybettiği anlaşıldı.
5. Tyler, Teksas (11 Nisan 1986): Önceki kazanın üzerinden sadece üç hafta sonra, aynı operatör, benzer bir senaryoda yüzündeki cilt kanseri için tedavi gören başka bir hastaya aşırı doz verdi. Hasta “yüzünün yandığını” hissettiğini bildirdi ve üç hafta sonra radyasyon yanıkları nedeniyle hayatını kaybetti.
Tyler hastanesi fizikçisi Fritz Hager ve operatör, veri giriş hızının hatayı tetiklediğini keşfetti. AECL, bu bulgular üzerine kendi makinesinde hatayı yeniden üretebildi ve 25.000 rad’lık bir dozaj ölçtü.
6. Yakima, Washington (17 Ocak 1987): Bir yıl sonra, Yakima’da başka bir hasta aşırı doz aldı. Operatörün “set” komutunu verme anı ile yazılımdaki bir sayaç taşmasının (integer overflow) çakışması sonucunda, makine ışın dağıtıcı cihazı yerleştirmeden yüksek enerjili elektron ışını verdi. Hasta göğsünde yanma hissetti ve iki denemede 86 rad yerine 8.000 ila 10.000 rad radyasyon aldı. Bu hasta da Nisan ayında aşırı dozun komplikasyonları nedeniyle yaşamını yitirdi.
Kazaların Ardındaki Temel Nedenler: Çok Yönlü Bir Başarısızlık
Therac-25 kazaları, tek bir hataya bağlanamayacak karmaşık bir olaylar zincirini temsil ediyordu. Araştırmacılar, olayların kökeninde yatan birçok kurumsal ve mühendislik sorununu ortaya çıkardı.
Yazılıma Aşırı Güven ve Donanım Kilitlerinin Kaldırılması: Therac-25’in en kritik tasarım hatalarından biri, önceki modellerdeki sağlam donanım güvenlik kilitlerinin kaldırılması ve tüm güvenliğin yazılıma devredilmesiydi. Yazılımın “kusursuz” olduğu varsayımıyla, tek bir yazılım hatasının tüm sistemi felakete sürükleyebileceği bir yapı oluşturulmuştu.
Yetersiz Yazılım Mühendisliği Uygulamaları: Yazılımın tek bir programcı tarafından yazılması, kapsamlı dokümantasyon eksikliği, birim testlerinin ve kapsamlı sistem testlerinin yetersizliği önemli sorunlardı. Yazılımın, üzerinde kapsamlı bir zamanlama analizi yapılmadan, gerçek zamanlı sistemler için programlama deneyimi az olan bir kişi tarafından geliştirildiği düşünülüyordu.
Anlamsız Hata Mesajları: Makinenin gösterdiği “Malfunction 54” gibi hata kodları, operatör kılavuzunda açıklanmıyordu ve tehlikenin ciddiyetini yansıtmıyordu. Operatörler, sürekli ortaya çıkan bu “düşük öncelikli” hata mesajlarına alıştıkları için, ciddi bir sorun olduğunda bile “P” tuşuna basarak devam etme eğilimine girdiler.
Yazılımın Hatalı Yeniden Kullanımı: Therac-6 ve Therac-20’den alınan yazılım modülleri, yeni ve farklı bir donanım ortamında kullanıldığında beklenmedik davranışlara yol açtı. Önceki makinelerdeki donanım kilitleri, bu yazılım hatalarını maskelemişti, ancak Therac-25’te bu kilitler olmayınca hatalar ölümcül hale geldi.
Yetersiz Risk Değerlendirmesi: AECL tarafından yapılan güvenlik analizleri (Fault Tree Analysis), sistemin yazılım bileşenlerini neredeyse tamamen göz ardı etmişti. Fault Tree Analysis, olası arıza ve kazaların kök nedenlerini sistematik olarak ortaya çıkararak riskleri önceden belirlemek ve güvenliği artırmak için önemlidir. Yazılım hatalarına çok düşük olasılıklar atanmış, tasarım hataları veya yarış durumları gibi yazılıma özgü riskler hesaba katılmamıştı.
Yarış durumu (race condition), birden fazla işlemin aynı anda ortak bir kaynağa erişmesi nedeniyle sıraya bağlı olarak farklı sonuçlar doğurabilen bir eşzamanlılık hatasıyken, sayaç taşması (counter overflow) ise bir sayacın alabileceği en büyük değeri aşıp sıfırlanması sonucu sistemin hatalı sonuçlar üretmesine yol açan hata türüdür.
Gecikmeli ve Yetersiz Tepki: AECL, ilk olay raporlarını ve davaları yeterince ciddiye almadı. İç iletişim eksikliği ve sorunları takip etme mekanizmalarının bulunmaması, şirketin tekrarlayan kazaları anlamasını ve önlemesini geciktirdi. FDA da o dönemde yaralanmaların raporlanması konusunda yeterli yetkiye sahip değildi.
Sonuç ve Alınan Dersler: Daha Güvenli Bir Gelecek İçin
FDA, Therac’ın ABD yasalarına göre kusurlu olduğuna karar verdi ve tüm ünitelerin kullanımdan kaldırılmasını önerdi. Öte yandan Therac-25 faciası, teknoloji dünyası için çok değerli dersler de sağladı. Bu olaylar, yazılımın kritik sistemlerdeki rolünün ne kadar dikkatli ele alınması gerektiğini gösterdi:
Sistem Mühendisliği Odaklı Yaklaşım: Kazaların, yazılım hatalarından çok, sistemin genel tasarımına yönelik sorunlardan kaynaklandığı anlaşıldı. Güvenli sistemler tasarlarken, tüm bileşenlerin (donanım, yazılım, insan faktörü) etkileşimini dikkate alan bütünsel bir sistem mühendisliği yaklaşımı şarttır.
Donanım ve Yazılım Kilitlerinin Birlikteliği: Güvenlik kritik sistemlerde, yazılıma tek başına güvenmek yerine, donanım tabanlı bağımsız güvenlik kilitlerinin de mutlaka bulunması gerektiği vurgulandı. Bu kilitler, yazılım hatalarını telafi edebilen ek bir güvenlik katmanı sağlar.
Kapsamlı Test ve Dokümantasyon: Yazılımın her seviyesinde (birim, entegrasyon, sistem) kapsamlı testler yapılması, olası yarış durumları ve hata senaryolarının belirlenmesi hayati önem taşır. Ayrıca, yazılım gereksinimlerinin, tasarımının ve test planlarının detaylı bir şekilde belgelenmesi, gelecekteki değişiklikler ve sorun giderme için kritik öneme sahiptir.
Anlaşılır Hata Mesajları ve Operatör Eğitimi: Sistem, operatörleri açık ve anlamlı hata mesajlarıyla bilgilendirmeli, potansiyel tehlikeleri net bir şekilde belirtmelidir. Operatörlerin eğitimli ve sistemin sınırları hakkında tam bilgi sahibi olmaları, “kullanıcı dostu” arayüzler tasarlanırken güvenlikten ödün verilmemesi gerektiği unutulmamalıdır.
Yazılım Yeniden Kullanımına Dikkat: Yazılım modüllerinin yeniden kullanımı, geliştirme süresini kısaltabilir, ancak her yeni sistemde yeniden güvenlik analizi ve testlerinin yapılması zorunludur. Bir yazılımın başka bir sistemde güvenli çalıştığı varsayımı, yeni bir ortamda felaketlere yol açabilir.
Bu kazaların ardından FDA ve diğer düzenleyici kurumlar, tıbbi cihaz olaylarının raporlanması ve yazılım güvenliği standartları konusunda önemli düzenlemeler yaptı. Therac-25 vakası, teknoloji geliştiricileri, mühendisler ve düzenleyiciler için, karmaşık sistemlerde güvenliğin bir öncelik olması gerektiğini ve bu konuda asla taviz verilmemesi gerektiğini gösteren kalıcı bir uyarı niteliğindedir. Tıpkı bir köprü inşaatında temel statik hesaplamaların göz ardı edilemeyeceği gibi, bir yazılım sisteminin de temel güvenlik ilkeleri üzerine inşa edilmesi zaruridir.
Yapay Zeka Çağında Yazılım Güvenliği: Therac-25 Gibi Vakalar Yeniden Yaşanır mı?
Teknolojinin gelişimi hız kesmeden devam ederken, günümüzde yazılım geliştirme süreçleri de büyük bir dönüşüm yaşıyor. Yapay zeka destekli kod üretimi, geliştiricilerin iş akışını hızlandırarak, kısa sürede fonksiyonel ve çalışan kodlar ortaya koyma kabiliyetiyle dikkat çekiyor. Birçok şirket, bu teknolojinin sunduğu hız ve verimlilik avantajlarından faydalanarak personel maliyetlerini düşürme yoluna giderken, AI’ın “hızla ve hatasız” kod üretebildiği algısı giderek yaygınlaşıyor. Ancak, bu durum, Therac-25 faciasından çıkarılan acı derslerle tehlikeli bir şekilde çakışan yeni güvenlik risklerini beraberinde getirme potansiyeli taşıyor.
Therac-25, yazılıma duyulan aşırı güvenin ve temel mühendislik ilkelerinden sapmanın nelere mal olabileceğini gösteren yıkıcı bir örnektir. O dönemde, geliştiriciler yazılımın “kusursuz” olduğu varsayımıyla, önceki modellerdeki donanım tabanlı güvenlik kilitlerini kaldırmış ve tüm sorumluluğu yazılıma yüklemişlerdi. AI’ın hızlı ve etkileyici kod üretim yetenekleri karşısında, günümüz şirketlerinin de benzer bir aşırı güven tuzağına düşme riski bulunuyor. Eğer AI tarafından üretilen kodlar, geleneksel yazılım mühendisliği prensipleri göz ardı edilerek, kapsamlı insan incelemesi ve bağımsız güvenlik mekanizmaları olmadan kritik sistemlerde kullanılırsa, Therac-25’in tekrarlayan felaketlerinin yolu açılabilir.
Therac-25 yazılımının tek bir programcı tarafından, neredeyse hiç dokümantasyon olmadan ve yetersiz testlerle geliştirildiği ortaya çıkmıştı. Bugün AI sistemleri, binlerce satır kodu saniyeler içinde üretebilirken, bu kodların arkasındaki gereksinim analizleri, tasarım kararları, birim testleri ve kapsamlı dokümantasyon süreçleri genellikle otomatik olarak karşılanmıyor. Therac-25 vakasında olduğu gibi, yazılım hatalarına “çok düşük olasılıklar” atanması veya yazılımın güvenlik analizlerinde neredeyse tamamen göz ardı edilmesi, AI’ın “hata yapmayacağı” yanılgısıyla günümüzde de tekrarlanabilir.
Ayrıca, Therac-25’in kodunun önceki modellerden “evrimleştiği” ve yeniden kullanıldığı ancak yeni donanım ortamında yeterince test edilmediği biliniyordu. AI modelleri de mevcut kod tabanlarından öğrenir ve bu kodlardaki ince hataları veya varsayımları farkında olmadan yeni nesil kodlara taşıyabilir. Bu durum, yazılımın yeniden kullanımındaki güvenlik derslerini AI çağında daha da kritik hale getiriyor: Bir kod modülünün bir sistemde güvenli çalıştığı, başka bir sistemde de aynı güvenliği sağlayacağı anlamına gelmez; her yeni kullanım ortamı için yeniden detaylı güvenlik analizi ve testleri zorunludur.
Therac-25 kazaları karmaşık yazılım hatalarından kaynaklanmıştır. AI’ın ürettiği kodlar da, insan gözüyle veya geleneksel test yöntemleriyle kolayca tespit edilemeyen bu tür karmaşık etkileşimleri barındırabilir. Makinenin “Malfunction 54” gibi anlamsız hata mesajları vermesi ve operatörlerin bu mesajlara aldanarak tedaviyi sürdürmesi, sistemin şeffaflık ve insan-makine etkileşimi konularındaki eksikliklerini göstermiştir. AI’ın ürettiği sistemlerde de, arızaların nasıl meydana geldiğine dair yeterli açıklama ve anlamlı hata mesajları olmadan, benzer riskler ortaya çıkabilir.
Therac-25 faciası, tek bir “yazılım hatasına” odaklanmak yerine, olayın kökeninde yatan yetersiz yönetim, kurumsal iletişim eksikliği ve yetersiz risk değerlendirmesi gibi çok yönlü faktörleri ele almanın önemini vurgulamıştır. AI’ın yazılım geliştirme süreçlerine entegrasyonu, bu “birçok elin sorunu”nu daha da karmaşık hale getirebilir; zira kodun üreticisi yapay zeka olduğunda, olası bir felaket durumunda sorumluluğu kimin veya neyin taşıyacağı sorusu belirsizleşebilir.
Unutmayalım ki, bir sistemin güvenliği, sadece yazılımının hızı veya verimliliğiyle değil, aynı zamanda tasarımının sağlamlığı ve insan yaşamına verdiği değerle ölçülür. Tıpkı bir uçağın otomatik pilot yazılımının, pilotlar tarafından her zaman gözden geçirildiği ve yedek sistemlerle desteklendiği gibi, yapay zeka tarafından üretilen kodların da en yüksek güvenlik standartlarına tabi tutulması gerekmektedir. Bu nedenle, yapay zeka destekli kod üretimi ne kadar cazip olursa olsun, Therac-25’ten çıkardığımız dersleri unutmamalıyız.
Bu konu hakkında siz ne düşünüyorsunuz? Yorum yazarak fikirlerinizi bizimle paylaşın!
Kaynak
1. Huff, C. A History of the Introduction and Shut Down of Therac-25. Online Ethics Center for Engineering and Science (2003). https://onlineethics.org/cases/therac-25/history-introduction-and-shut-down-therac-25.
2. Leveson, N. G. & Turner, C. S. An Investigation of the Therac-25 Accidents. Computer 26, 18–41 (1993).
3. Fabio, A. Killed by a Machine: The Therac-25. Hackaday (2015).
4. Therac-25. Wikipedia (2025). https://en.wikipedia.org/wiki/Therac-25.
5. Therac-25. Ethics Unwrapped, McCombs School of Business – The University of Texas at Austin (2025).