Yapay Zekânın Yeni Açığı: Bir Kararı Altı Ay Sonra Yeniden Kurabilir miyiz?

Yapay zekâ sistemlerini değerlendirirken uzun süredir aynı soruların peşinden gidiyoruz:

Model ne kadar doğru?

Ne kadar hızlı?

Ne kadar ucuz?

Hangi benchmark'ta kaç puan aldı?

Ne kadar iyi muhakeme yapabiliyor?

Kaç aracı aynı anda kullanabiliyor?

Fakat sistemler kurumların gerçek süreçlerine girdikçe başka bir soru giderek daha önemli hale geliyor:

Bugün alınan bir yapay zekâ kararının nasıl üretildiğini altı ay sonra gerçekten yeniden kurabilecek miyiz?

Bu soru özellikle bankacılık, sigorta, sağlık, işe alım, kamu hizmetleri, güvenlik, hukuk ve kurumsal otomasyon gibi alanlarda kritik.

Çünkü geleceğin sorunu yalnızca yapay zekânın yanlış karar vermesi olmayabilir.

Asıl sorun, yanlış veya tartışmalı bir karar ortaya çıktığında o kararın neden verildiğini artık kimsenin tam olarak bilememesi olabilir.

Bir model sürümünü saklamak artık yeterli değil

Geleneksel yazılım dünyasında geçmiş bir sistem davranışını incelemek nispeten daha kolaydı.

Kod sürümünü biliyordunuz.

Konfigürasyonu biliyordunuz.

Veritabanı kayıtlarını biliyordunuz.

Hangi uygulama sürümünün çalıştığını biliyordunuz.

Fakat modern yapay zekâ sistemlerinde sonuç yalnızca model tarafından belirlenmiyor.

Bir yapay zekâ işlemi sırasında aynı anda şunlar devreye girebilir:

• model sürümü,
• model endpoint'i,
• sistem prompt'u,
• kullanıcı girdisi,
• veri kaynağı,
• retrieval sonuçları,
• vektör veri tabanı,
• güvenlik politikası,
• araç bağlantıları,
• API sürümleri,
• ajan hafızası,
• çalışma zamanı ayarları,
• başka ajanlara yapılan delegasyonlar.

Üstelik bunların bazıları uygulama yayına alınırken değil, işlem gerçekleştiği anda seçiliyor.

Orijinal çalışmanın önemli tespitlerinden biri tam burada ortaya çıkıyor:

Bir yapay zekâ sisteminin gerçek konfigürasyonu artık deployment anında tamamen belirlenmiyor.

Sistemin bağımlılıklarının bir bölümü çalışma sırasında oluşuyor.

Deployment bize neyin planlandığını söylerRuntime ise gerçekte neyin kullanıldığını

Bir uygulamanın deployment kaydı bize şunu söyleyebilir:

Model: v17

Uygulama: 8f31c2

Ama aynı işlem sırasında sistem şunları kullanmış olabilir:

Prompt: h31

Retrieval index: r42

Belge: d182 sürüm 17

Belge: d761 sürüm 4

Policy: v8

Tool contract: h42

Ve işlemin sonunda dış dünyada bir aksiyon gerçekleşmiş olabilir:

Effect: e3

Altı ay sonra yalnızca uygulama ve model sürümlerini saklamak bu kararın nasıl oluştuğunu açıklamaya yetmez.

Çünkü esas bilgi şudur:

Bu işlem tam olarak hangi parçaları kullandı?

İşte yapay zekâ sistemlerinde kaybolmaya başlayan şey çoğu zaman verinin kendisi değil, parçalar arasındaki tarihsel ilişki.

Bir şeyin sistemde bulunması, kullanıldığı anlamına gelmez

Burada küçük görünen ama çok önemli bir ayrım var.

Bir belgenin sistemde mevcut olması başka şeydir.

Bir yapay zekâ kararında gerçekten kullanılmış olması başka şey.

Örneğin sistemde aynı anda üç farklı politika sürümü bulunabilir.

Bir cache eski bir veriyi döndürmüş olabilir.

Retrieval sistemi aynı sorguya farklı belgeler getirmiş olabilir.

Model endpoint'i arka planda değiştirilmiş olabilir.

Bir API yeni sürüme geçmiş olabilir.

Dolayısıyla altı ay sonra sisteme bakıp:

“Bu veri o tarihte vardı.”

demek,

“Yapay zekâ bu veriyi kullandı.”

anlamına gelmez.

İşte bu nedenle geçmişi yalnızca mevcut sistem durumundan çıkarmaya çalışmak giderek daha güvenilmez hale geliyor.

Log tutmak da tek başına çözüm değil

İlk refleks genellikle şu:

“Her şeyi loglarız.”

Fakat sorun bundan daha derin.

Bir distributed trace bize işlemin hangi servisten geçtiğini gösterebilir.

Bir log bize model kimliğini gösterebilir.

Bir registry bize model sürümünü gösterebilir.

Bir Git deposu bize kodu gösterebilir.

Ama bunların hiçbiri tek başına şu sorunun cevabını garanti etmez:

Bu spesifik işlem sırasında hangi model, hangi veri, hangi prompt, hangi politika ve hangi araç gerçekten birbirine bağlandı?

Gözlemlenebilirlik sistemleri metadata taşıyabilir. Örneğin modern tracing altyapıları trace ID, span ID ve çeşitli attributes üzerinden işlem bağlamı aktarabiliyor. Fakat bir kimliğin loglarda bulunması, o kimliğin işaret ettiği tarihsel durumun yıllar sonra hâlâ erişilebilir olmasını garanti etmiyor.

Yani:

Observability bize ne olduğunu gösterebilir.

Ama:

Preservation, bunu gelecekte de kanıtlayabilmemizi sağlar.

Bunlar aynı şey değil.

Yeni kavram: tarihsel yeniden kurulabilirlik

Burada önemli bir kavram ortaya çıkıyor:

Historical reconstructability.

Bunu Türkçede tarihsel yeniden kurulabilirlik olarak kullanabiliriz.

Reproducibility ile aynı şey değil.

Reproducibility şunu sorar:

Aynı koşulları oluşturursak aynı sonucu tekrar alabilir miyiz?

Reconstructability ise şunu sorar:

O gün gerçekte hangi koşullar altında bu sonuç üretildiğini belirleyebilir miyiz?

Yapay zekâ sistemleri deterministik olmadığı için aynı girdiyi tekrar çalıştırmak her zaman aynı sonucu vermeyebilir.

Bu nedenle bazı durumlarda aynı cevabı yeniden üretmekten daha önemli olan şey:

Orijinal cevabın hangi koşullarda üretildiğini kanıtlayabilmektir.

Asıl risk model değil, bağımlılık grafiği

Bugünün yapay zekâ uygulamalarını tek bir model olarak düşünmek giderek yanıltıcı.

Daha doğru metafor bir bağımlılık grafiği.

Bir kullanıcı sorusu sisteme giriyor.

Model seçiliyor.

Bir arama yapılıyor.

Bazı belgeler getiriliyor.

Bir politika kontrol ediliyor.

Bir araç çağrılıyor.

Başka bir ajan devreye giriyor.

Belki harici sistemde işlem gerçekleştiriliyor.

Ve bunların tamamı saniyeler içerisinde gerçekleşiyor.

Problem şu:

Bu grafiğin önemli bir bölümü çalışma sırasında oluşuyor.

Ve eğer sistem bu ilişkileri oluştuğu anda kaydetmezse daha sonra onları kesin biçimde geri getirmek mümkün olmayabilir.

Yapay zekâ sistemlerinde yeni bir altyapı katmanı gerekiyor

Buradan ilginç bir mimari sonuç çıkıyor.

Bugün AI stack içinde kabaca şunları düşünüyoruz:

Model katmanı

Data katmanı

Application katmanı

Observability katmanı

Security katmanı

Bunların yanına muhtemelen yeni bir katman eklemek gerekecek:

Preservation Plane

Yani sistemin tarihsel bağlamını koruyan bir altyapı katmanı.

Görevi yalnızca log toplamak değil.

Şunları korumak:

Hangi execution hangi modeli kullandı?

Hangi prompt kullanıldı?

Hangi belgeler retrieval sonucuna girdi?

Belgelerin hangi sürümleri kullanıldı?

Hangi politika geçerliydi?

Hangi araç sözleşmesi çalıştı?

Hangi konfigürasyon aktifti?

Hangi dış işlem gerçekleştirildi?

Ve en önemlisi:

Bu referans verilen tarihsel durumlara daha sonra gerçekten ulaşılabiliyor mu?

Orijinal çalışma bunu iki temel bütünlük ilkesiyle açıklıyor:

Binding integrity: Bir işlemin gerçekten hangi bağımlılıkları kullandığının korunması.

Resolution integrity: Kaydedilen bağımlılıkların tarihsel durumlarının daha sonra da çözümlenebilir olması.

Peki kayıt tutulamazsa sistem çalışmaya devam etmeli mi?

Belki de yazının en önemli mühendislik sorusu bu.

Bir yapay zekâ ajanının finansal işlem yaptığını düşünelim.

Ajan işlemi tamamladı.

Fakat işlemi açıklamak için gerekli geçmiş kaydı veri tabanına yazılamadı.

Ne olacak?

Bugünün sistemlerinin önemli bölümünde muhtemelen cevap:

İşlem devam eder.

Log hatası ayrı bir monitoring problemi olarak görülür.

Fakat kritik AI sistemlerinde bu yaklaşım yeterli olmayabilir.

Çünkü artık elimizde şöyle bir durum vardır:

Gerçek dünyadaki işlem gerçekleşmiştir.

Ama o işlemin neden gerçekleştiğini kanıtlayan tarihsel kayıt eksiktir.

Sistem davranışı ile sistem hafızası birbirinden ayrılmıştır.

Bunun çözümü bazı kritik sistemlerde çok daha sert olabilir:

Kayıt oluşmadan işlem gerçekleştirilemez.

Kayıt ile işlem aynı transaction içerisinde saklanır.

Kayıt başarısızsa işlem quarantine edilir.

Ya da sistem compensating action başlatır.

Kısacası log kaybı artık yalnızca monitoring problemi olmayabilir.

Bir iş sürekliliği ve yönetişim olayı haline gelebilir.

Regülasyonlar da aynı yöne ilerliyor

Bu tartışma yalnızca akademik veya mimari değil.

Avrupa Birliği'nin AI düzenlemesinde yüksek riskli yapay zekâ sistemlerinin sistem yaşam döngüsü boyunca olayları otomatik olarak kaydedebilmesi ve uygun düzeyde izlenebilirlik sağlaması isteniyor.

Düzenleme ayrıca bazı AI sistemlerinin otomatik ürettiği logların en az altı ay saklanmasını öngörüyor.

Benzer şekilde NIST'in AI Risk Management Framework yaklaşımı da güvenilir yapay zekâyı yalnızca model performansıyla değerlendirmiyor. Yönetişim, ölçüm, dokümantasyon, şeffaflık ve risk yönetimini sistem yaşam döngüsünün parçası olarak ele alıyor.

Dolayısıyla gelecekte AI yönetişiminin temel sorularından biri muhtemelen şu olmayacak:

Modeliniz hangi benchmark'ta kaç puan alıyor?

Daha çok şu olacak:

Bana 14 Mart 2026 saat 11:42'de verilen bu kararın hangi koşullarda üretildiğini gösterin.

Ve bu soruya cevap vermek için yalnızca modeli saklamak yetmeyecek.

Yapay zekânın paradoksu

Burada teknoloji dünyasının pek sevdiği türden bir ironi var.

Yapay zekâ sistemlerinin hafızası büyüyor.

Context window'ları büyüyor.

Modeller daha fazla veri işliyor.

Ajanlar daha fazla araç kullanıyor.

Sistemler daha fazla karar alıyor.

Ama aynı zamanda bir kararın tam olarak nasıl oluştuğunu hatırlamak giderek zorlaşıyor.

Yani yapay zekâ daha fazla şeyi hatırlayabiliyor olabilir.

Fakat kurumlar yapay zekânın ne yaptığını hatırlama yeteneğini kaybedebilir.

Capability yarışından accountability yarışına

Son birkaç yıldaki AI rekabetinin ana sorusu şuydu:

Kim daha yetenekli modeli geliştirecek?

Önümüzdeki dönemin kurumsal rekabeti ise başka bir soruya kayabilir:

Kim daha denetlenebilir sistemi kuracak?

Çünkü yüksek riskli süreçlerde asıl değer yalnızca doğru cevabı üretmek olmayacak.

Doğru cevabın:

hangi veriden,

hangi modelden,

hangi politikadan,

hangi araçtan,

hangi konfigürasyondan

geldiğini kanıtlayabilmek de gerekecek.

Başka bir ifadeyle:

Yapay zekânın geleceğinde güven, yalnızca ne yapabildiğiyle değil, geçmişte ne yaptığını ne kadar iyi kanıtlayabildiğiyle ölçülecek.

Ve bunun için sistemlerin yalnızca zekâya değil,

kurumsal hafızaya da ihtiyacı var.