Bir yapay zekâ ajanı bir şey yaptı. Sonra işler karıştı. Hani şu klasik “loglara bakarız” rahatlığı var ya… işte tam o an çöpe gidiyor. Çünkü mesele artık sadece ne yaptığını bilmek değil; neden yaptığını, hangi girdiden etkilendiğini ve aynı adımları birebir tekrar edip edemeyeceğini de kanıtlamak zorundasın.
Geçen ay, İstanbul’daki bir ürün ekibinin toplantısında tam bu konu açıldı. Bir ajan yanlış bir API çağrısı yapmıştı ve ekip “tam olarak hangi istem bunu tetikledi?” sorusuna net cevap veremeyince konu teknik olmaktan çıkıp denetim meselesine döndü. Açık konuşayım — bu tarz anlarda sorun kod değil, güvenin kendisi oluyor. Ve o güveni yeniden inşa etmek, kodu düzeltmekten çok daha zor.
İşin aslı şu ki çoğu agent altyapısı “işi halletsin yeter” mantığıyla kuruluyor. Fena değil, hızlı prototip için baya işe yarıyor açıkçası. Ama hukuk ekibi kapıyı çaldığında ya da güvenlik birimi “bu karar nasıl çıktı?” dediğinde sistemlerin çoğu omuz silkiyor (evet, doğru duydunuz). Tam burada ExoArmur gibi governance katmanları devreye giriyor.
Sorun Nerede Başlıyor?
Bak şimdi, problem sadece hata yapmak değil. Hata her yazılımda olur. Asıl mesele şu: o hatayı geriye dönük olarak yeniden kurabiliyor musun? Aynı girdiyle aynı çıktıyı alabiliyor musun? Yoksa elinde yalnızca dağınık loglar mı var, her biri yarım hikâye anlatıyor?
Küçük bir detay: 2023 sonbaharında Berlin’de katıldığım bir güvenlik etkinliğinde benzer bir tartışma olmuştu. Bir ekip “bizde trace var” diye gururlanıyordu, sonra biri çok basit bir soru sordu: “Peki deterministik replay var mı?” Salonda kısa bir sessizlik oldu. Evet, aynen öyle. Trace görmek güzel ama aynı akışı tekrar üretmek başka oyun — ikisini birbirine karıştırmamak lazım.
Bu fark küçük görünür ama pratikte uçurum kadar büyük. Çünkü agent dünyasında karar zinciri uzuyor: niyet oluşuyor, politika kontrolü geçiliyor, araç seçiliyor, dış servis çağrılıyor, sonra sonuç geliyor. Araya bir tokenizasyon farkı, rastgele seçim ya da zamanlamaya bağlı ufak bir oynama girerse bütün hikâye kayıyor. Sessizce.
ExoArmur Ne Yapıyor?
ExoArmur’un yaklaşımı ilginç çünkü ajanı değiştirmeye çalışmıyor. Onun üstüne bir governance katmanı koyuyor, yani çekirdeği bozmadan çevresine kontrol halkası örüyor. Bu bence doğru yönelim — çünkü her framework’ü baştan yazmaya kalkarsan proje mezarlığına gidersin. Bu ne anlama geliyor? Bunu zor yoldan öğrendim.
Sistem kabaca şöyle çalışıyor: karar kaynağı bir eylem niyeti üretiyor, policy decision point bunu kontrol ediyor, safety gate aradan geçmesine izin verirse executor çalışıyor — dürüst olayım, biraz hayal kırıklığı —. Sonunda imzalanmış gibi düşünebileceğin bir audit bundle oluşuyor. Güzel tarafı şu: executor’lar güvenilmeyen eklentiler gibi görülüyor; merkez ise sabit kalıyor. Bu ne anlama geliyor? Sabitlik burada bir zayıflık değil, tam tersine. SolidForge: MagSafe’li dayanıklı power bank neden konuşuluyor? yazımızda bu konuya da değinmiştik.
Decision Source → ActionIntent → PolicyDecisionPoint → SafetyGate → Approval? → Executor → ExecutionProofBundleBunu ilk okuduğumda aklıma hemen eski sistem yönetimi günleri geldi. 2018’de Ankara’da çalıştığım küçük SaaS takımında prod’a çıkan her değişiklik için ayrı onay süreci vardı ve herkes bundan şikâyet ederdi; ama geri dönüp bakınca en azından kimin neyi ne zaman yaptığını biliyorduk. Agent’lerde de benzer disiplin gerekiyor gibi duruyor. Maalesef.
Neden sıradan log yetmiyor?
Sıradan log sana olayların sırasını veriyor (yanlış duymadınız). bazen de eksik veriyor. Tracing daha geniş resim sunuyor ama yine de kesin kanıt sunmuyor. Çünkü aradığın şey sadece gözlem değil; yeniden üretilebilirlik. İkisi çok farklı şeyler.
| Kabaca araç | Ne verir? | Neyi vermez? |
|---|---|---|
| Log | Zaman damgası ve olay metni | Aynı akışın birebir yeniden üretimi |
| Trace | Bileşenler arası yolculuk | Kanonik kanıt paketi |
| Deterministic replay | Aynı girdiden aynı sonucu | Tahmin alanını bırakmaz |
Kritik Fikir: Kanıtlanabilirlik
Lafı gevelemeden söyleyeyim: bu konunun kalbi teknik olduğu kadar hukuki de. Neyse, bir yapay zekâ ajanının yaptığı işten sonra “emin değiliz” cümlesi kuruyorsan ortada operasyonel değil yönetsel sorun vardır. Ve evet, bu cümle bazen startup’ta da çıkar, kurumsalda da. Fark etmiyor. Butterfly CSS: 2026’da Dikkat Çeken Hafif Bir Seçenek yazımızda bu konuya da değinmiştik.
“Eğer ‘ne yaptı?’ sorusunun cevabı net değilse, elindeki sistem otomasyon değil belirsizlik üretiyor demektir.”
Bana göre burada en önemli ayrım şu: hızlı çalışan sistem ile denetlenebilir sistem aynı şey değil. Biri demo günü parlıyor, diğeri kriz gecesinde kurtarıyor seni — bence çok yerinde bir karar —. Ve açıkçası bazı ekipler demo gününde aşırı mutlu olup o geceyi hiç düşünmüyor — sonra sabaha karşı alarm çalıyor, herkes birbirine bakıyor. Tahmin eder misiniz? O geceyi yaşayanlar bilir. Daha fazla bilgi için Nintendo Wii’ye Mac OS X Yüklemek: İmkânsızın Sınırları yazımıza bakabilirsiniz.
Peki neden? PDF Dünyasında Bir Nefes: Ücretsiz ve Limitsiz Araçlar yazımızda bu konuya da değinmiştik.
Küçük startup ile enterprise arasında fark ne?
Küçük bir startup’ta mesele genelde hızdır; birkaç kişiyle ilerliyorsundur ve risk daha çok ürün kalitesine vurur. Enterprise seviyede ise tablo değişiyor — uyumluluk, iç denetim, veri sınırları. Insan onayı devreye giriyor, üstelik aynı anda. Küçük ekipte iyi tasarlanmış bir replay sistemi seni erken felaketten korur. Kurumsalda ise resmen sigorta poliçesi gibi davranır; kimse kullanmak istemez ama olmasa çıldırırsın (ki bu çoğu kişinin gözünden kaçıyor)
Deterministik Replay Neden Bu Kadar Önemli?
Kulağa biraz akademik geliyor, biliyorum. Ama sahada baya somut karşılığı var. Bilhassa finans, sağlık ve kamuya yakın projelerde bu konu lüks değil ihtiyaç — tartışmaya bile gerek yok. Sam Altman’in Ev Saldırısı ve Güven Krizi: Perde Arkası yazımızda bu konuya da değinmiştik.
Ben geçen sene İzmir’de görüştüğüm bir fintech ekibinde buna benzer bir boşluk görmüştüm. Sistem güzel çalışıyordu ama modelin hangi araç çağrısını neden seçtiği tam izlenemiyordu. Takım lideri bana düz şekilde şunu söyledi: “Sorun olunca debug ediyoruz ama audit sırasında tıkıyoruz.” İşte can sıkıcı nokta tam buydu — sorun teknik değil, kanıtlanabilirlik meselesiydi.
- Tespite yardımcı olur: Hangi giriş zinciri hatayı doğurduğunu görürsün. (bence en önemlisi)
- Dava/uyum tarafında güç verir: “Böyle olduğunu düşünüyoruz” yerine kaydı gösterirsin. (bu kritik)
- Mühendisliği sakinleştirir: Aynı senaryoyu tekrar koşup kıyas yaparsın.
Peki ExoArmur’un Güzel Tarafları Nerede Bitiyor?
Garip gelecek ama, Şimdi gelelim madalyonun diğer yüzüne. Kağıt üstünde müthiş duran her governance sistemi pratikte biraz sürtünme yaratır. Approval akışı varsa gecikme olur, deterministik katman varsa esneklik azalabilir. Bu kötü mü? Hayır, ama bedeli var. Bedelsiz güvenlik diye bir şey yok.
Açıkçası, Bazen ekipler güvenlik için o kadar çok bariyer koyuyor ki ajan kullanmanın anlamı azalıyor. Yani aslında otomasyon yapacağım derken yarım manuel süreç yaratıyorsun. Siz ne dersiniz? Bu noktada denge şart; yoksa kullanıcı deneyimi sertleşiyor, ürün hantallaşıyor ve bir süre sonra herkes o sistemi bypass etmenin yolunu arıyor.
Şuna dikkat: eksikler
- Aşırı katılık bazı gerçek dünya durumlarında yavaşlatabilir. (bu kritik)
- Eğer canonical event modeli iyi tanımlanmazsa replay değeri düşer. (bence en önemlisi)
- Ekip kültürü zayıfsa insanlar sistemi bypass etmeye kalkar — işte asıl hayal kırıklığı burada başlar!
Sistem Mimarisi Nasıl Okunmalı?
Ajan mimarisini düşünürken ben hep mutfak benzetmesi yapıyorum. Siparişi alan garson niyet kısmıdır, mutfak politikadır, pişiren aşçı executor’dır, servis edilen tabak ise execution proof bundle gibidir. Ama mutfağın kapısı kilitliyse kimsenin tabağa kafasına göre ekstra sos sıkması mümkün olmaz. Basit ama işe yarıyor bu benzetme.
Bakın, burayı atlarsanız yazının kalanı anlamsız kalır.
Vallahi, Tam burada immutable core fikri önemli hale geliyor. Çekirdek değişmiyorsa test etmek kolaylaşıyor, denetlemek kolaylaşıyor ve yeni gelen geliştirici bile üç gün içinde sistemin nereden aktığını kavrayabiliyor. Ben bunu özellikle Mart 2024’te kendi not defterimde işaretlemiştim; çünkü bakım yükünü en çok azaltan şeylerden biri budur. Siz ne dersiniz? Gerçekten.
Nerede Kullanılır?
Açık konuşayım, Kullanım alanları tahmin ettiğinden geniş olabilir. Mesela ödeme tetikleyen agent’ler, otomatik müşteri iletişimi yapan botlar, kurumsal veri üzerinde işlem yapan asistanlar… Bunların hepsi görünürde farklı ama özünde ortak riske sahip: geri alınamaz aksiyon üretmek. Ve o aksiyonu sonradan açıklayamamak.
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
