← Blog'a geri dön

AI her yerdeyken öndeki trene arkadan gelen tren nasıl çarpabilir?

Yapay zekâ çağında tren güvenliği, erken uyarı ve şirketler için ölçülebilir AI dönüşümü üzerine.

Turkuaz sensör ve sinyal çizimleriyle çevrili hızlı trenin demiryolunda ilerleyişini gösteren temsili görsel.
Yapay zekâ ile oluşturulmuş temsili görsel; gerçek kaza görüntüsü değildir.

Kısa yanıt: Yapay zekânın yaygınlaşması, bütün kritik altyapıların onu kullandığı veya kazaların artık imkânsız olduğu anlamına gelmiyor. Trenlerin güvenli biçimde ayrılması; tren algılama, sinyalizasyon, hareket izinleri, hız denetimi, frenleme ve işletme kurallarının birlikte çalışmasına bağlı. Bu işlevlerin önemli bir bölümü üretken yapay zekâ gerektirmiyor. AI ise uygun veriler ve doğrulanmış uygulamalarla bakım ihtiyacını erken fark etmeye, sıra dışı durumları belirlemeye ve ekiplerin kararlarını desteklemeye yardımcı olabilir.

Telefonumuzdaki bir uygulama saniyeler içinde video üretebiliyorsa, aynı çağda iki trenin çarpışabilmesi insana anlaşılmaz geliyor. Bu tepkinin arkasında makul bir beklenti var: Bu kadar gelişmiş teknoloji, en temel tehlikeleri de önleyebilmeli. Ancak içerik üreten bir model ile fiziksel bir sistemi güvenli sınırlar içinde tutan mühendislik arasında ciddi bir fark bulunuyor.

Bu farkı anlamak, yalnızca demiryollarını konuşurken işe yaramıyor. Şirketinde yapay zekâ kullanmak isteyen herkes için aynı mesele gündeme geliyor: Yazılım hangi veriyi görüyor, neye karar verebiliyor ve yanlış yaptığında kim, nasıl müdahale ediyor?

İspanya’daki olay hakkında ne biliyoruz?

28 Ekim 2026’da İspanya’nın Madrid–Sevilla yüksek hızlı demiryolu hattında, Urda yakınlarında Renfe ve Iryo trenlerinin karıştığı bir çarpışma bildirildi. Altyapı işletmecisi Adif, Mora y Orgaz–Urda arasındaki olayı ilk bilgilendirmesinde arkadan çarpışmayı ifade eden “alcance” sözcüğüyle duyurdu. Renfe de olay hakkında resmî bir açıklama yayımladı. İlk operasyonel duyurular Adif’in şebeke durumu sayfasında yer aldı.

Bu bilgiler, çarpışmanın teknik nedenini açıklamıyor. Hangi koruma sisteminin hangi modda çalıştığı, trenlerin hareket sırası, verilen izinler ve frenleme süreci ayrı ayrı incelenmesi gereken konular. Olayı bir “AI eksikliği”, “ETCS arızası” veya belirli bir kişinin hatası olarak nitelemek için bu açıklamalar yeterli değil.

Öncelik, olaydan etkilenen yolcular ve çalışanlar. Buradaki değerlendirme bir kaza incelemesi değil; olayın gündeme getirdiği teknoloji sorusunu anlamaya yönelik genel bir analiz. Hızla değişebilen yaralı sayıları yerine, doğrulanabilen çerçeveye ve daha kalıcı teknik sorulara odaklanıyoruz.

Trenlerin çarpışmasını önlemek için hangi sistemler çalışır?

Demiryolu güvenliğini yalnızca makinistin önündeki ışık veya tek bir bilgisayar üzerinden düşünmek eksik kalır. Bir trenin ilerleyebilmesi için farklı sistemlerin birbiriyle tutarlı bilgi üretmesi gerekir. Hattın ve araçların donanımına göre uygulama değişse de temel görevler şöyle özetlenebilir:

  • Trenin varlığını ve konumunu belirlemek: Bir hat kesiminin dolu olup olmadığını bilmek, güvenli hareketin başlangıç noktasıdır.
  • Uygun güzergâhı oluşturmak: Makasların konumu ve izin verilen hareketler birbirleriyle çelişmemelidir. Sinyaller ile makaslar arasındaki güvenlik bağı bu nedenle önemlidir.
  • Hareket iznini iletmek: Trenin nereye kadar ve hangi koşullarla ilerleyebileceği, ilgili sistem ve işletme kuralları üzerinden belirlenir.
  • Hız sınırlarını denetlemek: Donanıma bağlı olarak tren koruma sistemi, izin verilen sınırlar aşılmadan uyarı veya fren müdahalesi sağlayabilir.
  • Fiziksel olarak durabilmek: Fren sisteminin durumu, hız, tren özellikleri ve hat koşulları, durma davranışını etkiler.

Network Rail’in sinyalizasyon açıklaması, bu yapının çok sayıda parçadan oluştuğunu ve arıza durumlarında güvenli duruma geçmenin tasarımın temel hedeflerinden biri olduğunu anlatıyor. Bu yüzden bir sinyal arızası bazen trafiğin durması veya gecikmesiyle sonuçlanır. Yolcunun gördüğü gecikme, bazı durumlarda güvenlik mekanizmasının devreye girmesidir.

Buradan herhangi bir kazanın nedeni çıkarılamaz. Sistemlerin tasarımı kadar bakımı, yapılandırılması, değişiklik yönetimi ve olağan dışı koşullardaki işletilmesi de incelenir. “Bilgisayar vardı, neden engellemedi?” sorusunun yanıtı, ancak olay kayıtlarıyla ortaya konabilir.

Otomatik tren koruması ile yapay zekâ aynı şey mi?

Otomatik çalışan her sistem yapay zekâ değildir. Özellikle üretken AI ile güvenlik amaçlı kontrol işlevlerini birbirinden ayırmak gerekir. Bir dil modeli açıklama yazabilir, belgelerde arama yapabilir ve olay kayıtlarını özetleyebilir. Tren koruma sistemi ise tanımlanmış işletme ve güvenlik koşulları içinde çalışmak üzere tasarlanır.

Genel bir örnek olarak Avrupa Tren Kontrol Sistemi, yani ETCS, trenin hızını ve konumunu izin verilen sınırlar açısından denetler. Avrupa Birliği Demiryolları Ajansının frenleme eğrileri açıklamasına göre araç üstü bilgisayar, trenin frenleme özellikleri ve önündeki hatla ilgili verilerden yararlanarak frenleme mesafelerini hesaplar. Gerektiğinde ayrı bir sistem olan tren frenlerine müdahale komutu verir.

Bu hesaplamanın varlığı, bir sohbet modelinin kullanıldığı anlamına gelmez. Ayrıca ETCS’yi burada çalışma mantığını açıklamak için örnek veriyoruz; bu, İspanya’daki olay anında ETCS’nin devrede olduğu veya başarısız olduğu iddiası değildir.

Dolayısıyla arkadan çarpışmayı önlemek için önce üretken AI beklemek gerekmiyor. Mevcut güvenlik işlevlerinin doğru çalışması başlı başına zorunlu. Yapay zekâ projeleri, bu sorumluluğu belirsizleştirmek yerine, hangi ek faydayı sağlayacaklarını açıkça ortaya koymalı.

Yapay zekâ demiryollarında nerede fayda sağlayabilir?

En somut fırsatlar, çok miktarda verinin düzenli incelenmesi gereken işlerde ortaya çıkıyor. Aşağıdaki örnekler olası uygulama alanlarıdır; belirli bir hattın mevcut yetenekleri veya herhangi bir kazanın kesin çözümü olarak okunmamalıdır.

Sensör verilerindeki sıra dışı değişimleri fark etmek

Sıcaklık, titreşim, elektriksel ölçümler ve bakım kayıtları birlikte ele alındığında tek bir ölçümde görünmeyen değişimler araştırılabilir. Örneğin bir ekipmanın benzer çalışma koşullarındaki geçmiş davranışından uzaklaşması, kontrol edilmesi gereken bir durum olarak işaretlenebilir.

Anomali tespiti, tek başına arıza teşhisi değildir. Sensör bozulmuş, çalışma koşulu değişmiş veya kayıt yanlış eşleştirilmiş olabilir. Bu nedenle uyarının yanında hangi verilerin kullanıldığı, zaman bilgisi ve kontrol gerekçesi bulunmalı; sonuç ilgili uzmanın incelemesine aktarılmalıdır.

Kestirimci bakım için öncelik oluşturmak

Kestirimci bakım, ekipmanın durumunu izleyerek bakım ihtiyacını daha erken değerlendirmeyi amaçlar. AI, geçmiş arızalarla ölçümler arasındaki örüntüleri araştırabilir ve bakım ekiplerine öncelik önerileri sunabilir. Bunun yararı, yalnızca modelin tahmininde değil; önerinin iş emrine, incelemeye ve kayda dönüşmesinde görülür.

Bu alandaki çalışmaların olgunluk düzeyini de ayırt etmek gerekiyor. Europe’s Rail’in dinamik bakım çözümü, farklı kaynaklardan gelen durum ve bakım verilerini birleştiren karar desteğini anlatıyor. Sayfada çözüm, ilgili ortamda gösterilmiş TRL 6 düzeyinde bir prototip olarak tanımlanıyor; pilot uygulama ve ileri doğrulama ihtiyacı belirtiliyor. Araştırma sonucu, her yerde kullanıma hazır bir güvenlik garantisi olarak sunulmamalı.

Görüntülerle yapılan kontrolleri desteklemek

Görüntü işleme modelleri, inceleme görüntülerinde uzmanların bakmasını gerektiren bölgeleri öne çıkarabilir. Amaç, çok sayıda görüntü içinden dikkat gerektiren örnekleri seçmeyi kolaylaştırmaktır. Işık, hava, kamera açısı ve görüntü kalitesi değiştiğinde performansın yeniden değerlendirilmesi gerekir.

Avrupa Komisyonunun RAILS proje sonuçları, kamera tabanlı engel algılama, altyapı incelemesi ve kestirimci bakım için dijital ikizler gibi araştırma yönlerini içeriyor. Bunlar umut verici çalışma alanları; her senaryoda aynı başarıyı gösteren tamamlanmış çözümler olarak değerlendirilmemeli.

Dağınık bilgileri karar verecek ekibe ulaştırmak

Bir uyarı başka ekranda, bakım geçmişi başka uygulamada, saha notu ise bir mesaj zincirinde kaldığında ekiplerin durumu anlaması zorlaşır. Entegrasyon katmanı, aynı varlığa ait kayıtları bir araya getirebilir. AI da bu kayıtların sınıflandırılmasına veya özetlenmesine yardımcı olabilir.

Burada kritik ayrıntı veri eşleştirmesidir. Farklı sistemlerdeki ekipman kimlikleri, saatler ve kayıt sürümleri uyuşmuyorsa, düzgün yazılmış bir özet hatalı bir tablo sunabilir. Kaynak bağlantıları ve eksik veri işaretleri, akıcı bir açıklamadan daha değerli olabilir.

Belgelerde arama ve olay sonrası analiz

Üretken yapay zekâ, onaylı teknik belgelerde arama yapan veya uzun kayıtları ilk inceleme için düzenleyen bir yardımcı olarak kullanılabilir. Yanıtın hangi belgeye ve hangi sürüme dayandığını göstermek, yetkisiz bilgilere erişimi engellemek ve belirsiz durumları uzmana bırakmak gerekir.

Bu yardımcıya operasyonel bir talimatı kendi başına değiştirme yetkisi vermek farklı bir risk seviyesidir. Doküman bulmakla fiziksel bir sistem üzerinde işlem yapmak aynı proje kapsamına sıkıştırılmamalı. Yetkiler, kullanım amacına göre ayrı ayrı tanımlanmalıdır.

Daha fazla AI neden tek başına daha fazla güvenlik getirmez?

Bir modelin ortalama başarısı yüksek olsa bile, kritik senaryolardaki performansı yetersiz kalabilir. Nadir görülen bir durum, eğitim verisinde çok az temsil edilmiş olabilir. Başka bir hat, ekipman tipi veya mevsimde elde edilen sonuçların yeni koşullarda da geçerli olduğu varsayılamaz.

İki hata türünün bedeli de farklıdır. Gerçek bir sorunu kaçırmak geç müdahaleye neden olabilir. Sorun olmadığı hâlde sürekli alarm üretmek ise inceleme yükünü artırabilir ve uyarıların ciddiye alınmasını zorlaştırabilir. Değerlendirme, yalnızca toplam doğruluk oranını değil, bu iki sonucu ve operasyonel etkilerini ayrı göstermelidir.

Aynı dikkat değişikliklerde de gerekir. Sensörün değiştirilmesi, veri alanının yeniden adlandırılması veya modelin güncellenmesi daha önce test edilmiş davranışı etkileyebilir. Kimin değişiklik yapabildiği, neyin yeniden sınanacağı ve gerektiğinde önceki sürüme nasıl dönüleceği belirli olmalıdır.

Birleşik Krallık demiryolu düzenleyicisi ORR, dijital güvenlik değerlendirmesinde risklerin yalnızca tek tek sistemlerden değil, sistemlerin bütünleştirilmesi, değiştirilmesi ve işletilmesi sırasında da doğabildiğini vurguluyor. İnsanların karar süreçleri ve tedarik zinciri de bu resmin içinde.

Bu nedenle “insan onayı var” demek de tek başına yeterli olmaz. Onay verecek kişinin kaynağı görebilmesi, uyarıyı anlayabilmesi, gerektiğinde reddedebilmesi ve bunun için yeterli zamana sahip olması gerekir. Müdahale yetkisi bulunmayan veya neyi onayladığını göremeyen bir kişinin ekranda bulunması, güçlü bir kontrol tasarımı sayılmaz.

Bu tartışmanın şirketlerdeki AI projeleriyle ilgisi ne?

Bir e-ticaret stok hatasının sonuçları ile demiryolu kazasının sonuçları elbette aynı değil. Yine de teknoloji uygulamalarını değerlendirirken sorulacak bazı sorular ortak: Veri güncel mi? Karar yetkisi kimde? Yanlış işlem nasıl fark ediliyor? Sistem durursa ekip çalışmaya nasıl devam ediyor?

Örneğin müşteri hizmetleri asistanı, iade politikasının eski sürümünü kullanıyorsa daha akıcı konuşması sorunu çözmez. Stok entegrasyonu gecikiyorsa bir satış öneri modeli, elde olmayan ürünü daha başarılı biçimde önerebilir. Bir otelde misafir mesajını doğru sınıflandırmak da görevin doğru ekibe ulaştığı ve tamamlandığı doğrulanmadığında yarım kalır.

Bu örnekler, AI danışmanlığında neden model seçmeden önce iş akışına bakılması gerektiğini gösteriyor. Başlangıç noktası, ekiplerin tekrar tekrar zaman kaybettiği veya hata yaptığı belirli bir işlem olmalı. Ardından veri kaynağı, karar sınırı, insan kontrolü ve başarı ölçüsü birlikte tasarlanmalı.

Bazı sorunlar için yeni bir model bile gerekmeyebilir. Temiz bir veri bağlantısı, açık bir kural veya onay akışı daha basit ve denetlenebilir bir çözüm sunabilir. Yapay zekânın ek değeri, bu alternatiflerle karşılaştırıldığında ortaya çıkar.

Ölçülebilir bir yapay zekâ pilotu nasıl tasarlanır?

Aşağıdaki plan, şirketlerin operasyonel AI projelerine başlaması için önerdiğimiz bir çalışma çerçevesidir. Demiryolu güvenlik mühendisliği, uygunluk değerlendirmesi veya sektöre özgü izin süreçlerinin yerine geçmez. Genel risk yaklaşımı için NIST AI Risk Management Framework yararlı bir başvuru kaynağıdır; çerçeve risk yönetimini sistemin yaşam döngüsü boyunca ele alır.

1. Tek bir iş akışını ve sınırlarını seçin

“Şirketi AI ile dönüştürmek” yerine, örneğin destek taleplerinin doğru ekibe yönlendirilmesini seçin. Sistemin yalnızca öneri mi vereceğini, kayıt mı açacağını, yoksa işlem de mi yapacağını yazın. Müşteriye mesaj gönderme, ödeme veya veri silme gibi yetkileri ayrıca değerlendirin.

2. Mevcut performansı kaydedin

Pilot öncesindeki işlem süresini, hata oranını ve ekip yükünü ölçün. Bugünkü durum bilinmeden iyileşme iddiasını sınamak zorlaşır. Karşılaştırmayı benzer iş hacmi ve koşullarda yapın; kampanya dönemiyle sakin dönemi doğrudan kıyaslamak yanıltıcı olabilir.

3. Veriyi ve test örneklerini ayırın

Hangi kaynağın yetkili olduğunu, güncellik sınırını ve erişim izinlerini belirleyin. Başarıyı yalnızca sistemi hazırlarken kullanılan örneklerde ölçmeyin. Ayrı test örnekleriyle birlikte eksik kayıt, çelişkili bilgi, beklenmedik talep ve bağlantı kesintisi gibi durumları da sınayın.

4. Önce işlem yaptırmadan deneyin

Gölge çalışma, sistemin öneri üretip gerçek kararı değiştirmediği bir deneme biçimidir. Böylece öneriler mevcut süreçle karşılaştırılabilir. Başarısız örnekler incelenip kapsam daraltılabilir. Sonraki aşamada sınırlı yetki ve insan onayıyla ilerlemek, sorunların daha kontrollü görülmesini sağlar.

5. Devam ve durdurma ölçütlerini önceden belirleyin

Pilot başlamadan hangi sonuçta genişletileceğini, hangi hatada durdurulacağını ve sorumlunun kim olduğunu yazın. Bir hedefi tutturmak başka bir riski gizlememeli. Hız artarken yanlış işlem veya inceleme yükü yükseliyorsa, uygulama henüz beklenen faydayı sağlamıyor olabilir.

Sonuç raporunda en az şu ölçüler yan yana görülmeli:

  • İş sonucu: İşlem süresi, doğru yönlendirme veya zamanında tamamlama gibi seçilen hedef.
  • Hata dağılımı: Kaçırılan sorunlar, yanlış alarmlar ve kritik hata örnekleri.
  • İnsan emeği: Kontrol, düzeltme ve istisna yönetimi için harcanan süre.
  • Toplam maliyet: Model kullanımıyla birlikte entegrasyon, bakım ve inceleme maliyeti.
  • İşletilebilirlik: İzlenebilir kayıtlar, veri güncelliği, kesinti davranışı ve geri dönüşün çalışması.

İyi bir pilotun sonucu her zaman “daha büyük kurulum” olmaz. Veri yetersizse hazırlık çalışmasına dönmek, fayda sınırlıysa kural tabanlı çözümü korumak veya risk yüksekse projeyi durdurmak da değerli bir sonuçtur.

Sık sorulan sorular

Yapay zekâ tren kazalarını tamamen önleyebilir mi?

Böyle bir garanti verilemez. AI, belirli görevlerde erken tespit ve karar desteği sağlayabilir; güvenlik ise altyapı, tren koruma, bakım, işletme ve insan faktörlerinin birlikte ele alınmasını gerektirir. Her uygulamanın kendi koşullarında doğrulanması gerekir.

ETCS bir yapay zekâ sistemi mi?

ETCS, trenin izin verilen hız ve mesafe sınırları içinde kalmasını denetleyen Avrupa tren kontrol sistemidir. Frenleme eğrileri gibi matematiksel hesaplamalar kullanması, onu üretken yapay zekâ veya sohbet modeli yapmaz.

Kestirimci bakım mevcut bakımı ortadan kaldırır mı?

Kendiliğinden kaldırmaz. Veriye dayalı tahminler, bakım önceliklerini destekleyebilir. Mevcut bakım yükümlülükleri veya güvenlik prosedürleri, yalnızca bir model önerdi diye değiştirilmemeli; değişiklikler ilgili teknik değerlendirmeden geçmelidir.

Bir şirket AI projesine nereden başlamalı?

Verisine erişilebilen, sorumlusu belli ve sonucu ölçülebilen sınırlı bir iş akışından. Önce mevcut performansı kaydedin; ardından küçük bir pilotta faydayı, hataları ve insan kontrolünü birlikte değerlendirin.

AI danışmanlığı yalnızca araç seçmek midir?

Araç seçimi işin bir bölümüdür. Veri kaynakları, entegrasyonlar, erişim yetkileri, ekip eğitimi, onay süreçleri ve sonuçların ölçülmesi birlikte ele alınmadığında, iyi bir araç da günlük operasyonun dışında kalabilir.

İşletmenizde AI’ın nerede fayda sağlayacağını birlikte değerlendirelim

GadgetMall’da AI dönüşümünü; iş akışlarının ve veri kaynaklarının değerlendirilmesi, bir yol haritası oluşturulması, entegrasyon, ekip eğitimi ve sonuçların ölçülmesi kapsamında ele alıyoruz. Bu yaklaşım müşteri desteği, içerik, ticaret ve iç operasyonlar gibi şirket süreçlerine yöneliktir.

Başlamak için kapsamlı bir teknik şartname hazırlamanız gerekmiyor. Tekrarlayan bir işinizi, kullandığınız araçları ve iyileştirmek istediğiniz sonucu paylaşmanız yeterli. Hangi adımın otomasyona uygun olduğunu, nerede insan onayının kalması gerektiğini ve bir pilotun nasıl ölçülebileceğini konuşabiliriz.

GadgetMall ile AI dönüşümünü görüşün veya hello@gadgetmall.uk adresine yazın.

AI’ın her yerde görünmesi, bütün sistemlerin kendiliğinden daha iyi çalıştığını göstermiyor. Gerçek ilerleme; hangi sorunun çözüldüğünü, çözümün sınırlarını ve sahada elde edilen sonucu açıkça gösterebildiğimizde başlıyor.

Kaynaklar

Olay bilgileri 28 Ekim 2026 tarihli ilk resmî açıklamalarla sınırlıdır. Teknik kaynaklar genel açıklamalar için kullanılmıştır; olayın nedenine ilişkin bir bulgu olarak sunulmamaktadır.

  1. Adif — Şebeke durumu ve operasyonel duyurular.
  2. Renfe — Los Yébenes–Urda arasındaki kaza hakkında açıklama.
  3. Network Rail — Signals explained.
  4. European Union Agency for Railways — Braking curves.
  5. Europe’s Rail — Dynamic Maintenance Powered by Holistic Condition Monitoring.
  6. European Commission CORDIS — RAILS proje sonuçları.
  7. Office of Rail and Road — Digital safety.
  8. NIST — AI Risk Management Framework.