AI Ajan Pilotları Neden Üretime Geçemiyor? 2026 Saha Raporu

TL;DR — Sahada gördüğüm tablo net: AI ajan pilotlarının büyük çoğunluğu üretime geçemeden ölüyor. Sektör raporları bu oranı %86–89 aralığında gösteriyor ve sebep neredeyse hiçbir zaman modelin yetersizliği değil. Asıl katiller yönetişim boşlukları, ajanların ne yaptığını envanterleyip izleyememe, yetersiz gözlemlenebilirlik ve dağınık sahiplik. Bu yazıda pilotların neden öldüğünü tek tek açıyorum; ardından paylaşılan bağlam katmanı, kapsamı daraltılmış araçlar, uçtan uca izlenebilirlik, insan onayı ve değerlendirme (eval) döngüsünden oluşan bir referans mimari veriyorum. Sonunda üretime geçiş kontrol listesi, izlemeniz gereken metrikler ve KVKK açısından dikkat etmeniz gerekenleri koyuyorum. Amaç tek: pilotu slayttan çıkarıp üretimde ayakta tutmak.

Son on sekiz ayda masama gelen taleplerin niteliği değişti. Artık kimse "acaba ajan mimarisi işe yarar mı" diye sormuyor. Herkes bir pilot çalıştırmış, demoda göz kamaştırıcı bir sonuç almış ve sonra o pilotu üretime taşımaya çalışırken duvara toslamış durumda. Gartner'ın rakamı bu ilgiyi çok iyi özetliyor: çok ajanlı sistemlere dair sorgular 2024'ün ilk çeyreğinden 2025'in ikinci çeyreğine yüzde 1.445 arttı. Bu, bir merakın patlaması. Ama merakın patlaması ile üretime geçmiş sistem sayısı arasında derin bir uçurum var.

Sahada gördüğüm ve sektör raporlarının da doğruladığı gerçek şu: AI ajan pilotlarının kabaca yüzde 86 ila 89'u üretime ulaşamadan ölüyor. İlk duyduğunuzda bu rakam sizi modelden şüphelenmeye itebilir. "Demek ki modeller henüz yeterince iyi değil" dersiniz. Yıllardır bu işin içindeyim ve size net söyleyeyim: neredeyse hiçbir pilot model yetersizliğinden ölmüyor. Modeller şaşırtıcı derecede yetenekli. Pilotları öldüren şey mühendislik ve organizasyon disiplininin eksikliği.

"

Bir demo, kontrollü bir ortamda tek bir mutlu senaryoyu çalıştırmaktır. Üretim ise binlerce mutsuz senaryonun, kenar durumun, yetki sorusunun ve denetim talebinin aynı anda üstünüze geldiği yerdir. Demo ile üretim arasındaki fark, model kalitesi değil; sistemin çevresine ördüğünüz disiplindir.

Bu yazıyı yazma sebebim, aynı hikâyeyi onlarca kez farklı şirketlerde izlemiş olmam. Kurum heyecanla bir ajan projesi başlatıyor. İki hafta içinde etkileyici bir demo çıkıyor. Yönetim mutlu, bütçe akıyor. Sonra "bunu gerçek müşterilere / gerçek verilere / gerçek sistemlere bağlayalım" dendiği an her şey yavaşlıyor. Altı ay sonra proje sessizce rafa kalkıyor. Kimse "başarısız oldu" demiyor; sadece "önceliklerimiz değişti" deniyor. Bu yazı, o sessiz ölümlerin anatomisi ve onları önlemenin saha rehberi.

Demoların bu kadar aldatıcı olmasının bir sebebi var. Demo ortamında bağlam küçüktür, veri temizdir, kullanıcı iş birliği yapar ve hata olduğunda demoyu yapan kişi araya girip düzeltir. Üretimde bunların hiçbiri yoktur. Kullanıcı ajanı köşeye sıkıştırır, veri kirlidir, sistemler yavaş cevap verir, üçüncü bir servis çöker ve ajan bir anda öngörülemeyen bir davranış sergiler.

Modelin yetenekli olması burada yeterli değil. Yetenekli bir modeli disiplinsiz bir sisteme koyduğunuzda, o yetenek sizin aleyhinize çalışmaya başlar. Çünkü model her adımda bir karar veriyor, her karar bir aksiyona dönüşüyor ve o aksiyonların hiçbirini göremiyor, izleyemiyor, geri alamıyorsanız, elinizde bir kara kutu vardır. Kurumlar kara kutuyu üretime almaz. Almamalıdır da.

Bu yüzden "hangi modeli seçmeliyim" sorusu, pilotun kaderini belirleyen soru değil. Belirleyen soru şudur: Bu ajan üretimde bir hata yaptığında, ne olduğunu ne kadar hızlı anlayabilir, ne kadar hızlı durdurabilir ve ne kadar hızlı düzeltebilirim? Bu sorunun cevabı zayıfsa, en güçlü modeli de koysanız pilot ölür.

Sahadan biriktirdiğim gözlemleri beş başlıkta topluyorum. Bunlar ayrı ayrı değil, birlikte çalışır ve birbirini besler. Ama her birini ayrı görmezseniz çözemezsiniz.

1. Bağlam tutarsızlığı: en sinsi katil

Çok ajanlı sistemlerin üretimde çökmesinin birincil sebebi, çoğu insanın sandığı gibi orkestrasyon deseninin yanlış seçilmesi değil. Birincil sebep bağlam tutarsızlığı. Bunu vurgulamak istiyorum çünkü ekiplerin çoğu haftalarını "hangi orkestrasyon deseni daha iyi" tartışmasında harcıyor, oysa asıl sorun başka yerde.

Ajanların hafızası uçucudur. Bir ajan bir görevi tamamlar, sonuç üretir ve o bağlam kaybolur. İkinci ajan devreye girdiğinde birincinin ne gördüğünü, hangi varsayımla hareket ettiğini bilmez. Üç ajan birbirine görev devrederken, her biri kendi kısmi ve zaman zaman çelişen dünya görüşüyle çalışır. Sonuç: bir ajan müşterinin adresini "güncellendi" sayarken diğeri eski adresle işlem yapar. Demoda bu görünmez çünkü tek bir akış vardır. Üretimde bu, tutarsız kararların ve sessiz hataların kaynağıdır.

Çözüm, ajanlara daha fazla hafıza vermek değil; paylaşılan, kalıcı bir bağlam katmanı kurmaktır. Tüm ajanların aynı gerçeğe baktığı, durumun tek bir yerde tutulduğu, her ajanın oradan okuyup oraya yazdığı bir katman. Bu olmadan çok ajanlı sistem, her biri farklı bir kitabı okumuş insanların aynı toplantıda karar vermeye çalışması gibidir.

Bu noktada ekiplerin sık düştüğü bir tuzağı da anmadan geçmeyeyim: bağlamı ajanların birbirine ilettiği mesajların içine gömmek. Yani bir ajanın diğerine "şu ana kadar şunları biliyorum" diye uzun bir özet geçmesi. Bu, kısa vadede çalışıyormuş gibi görünür ama ölçek büyüdükçe çöker. Çünkü her devir teslimde özet ya kısalır ve bilgi kaybolur, ya uzar ve maliyet patlar; üstelik hangi özetin güncel olduğunu kimse bilemez. Bağlamı mesajların içinde taşımak yerine, dışarıda paylaşılan bir katmanda tutmak ve mesajları yalnızca o katmana işaret eden hafif referanslar hâline getirmek çok daha sağlıklıdır. Sahada bu ayrımı yapan ekiplerle yapmayanlar arasındaki fark, üretime geçiş anında net biçimde ortaya çıkıyor.

2. Orkestrasyon karmaşıklığının katlanarak büyümesi

Ajanlar ajanlara görev devrettikçe, başarısız olunca yeniden denedikçe ve dinamik olarak araç seçtikçe, sistemin karmaşıklığı neredeyse üssel biçimde büyür. Tek bir ajan ve üç araçla başlarsınız; kısa süre sonra beş ajan, on beş araç, dinamik yönlendirme ve iç içe geçmiş yeniden deneme döngüleriyle uğraşıyorsunuzdur.

Bu karmaşıklık, test edilebilirliği öldürür. Tek bir girdi için sistemin izleyebileceği yol sayısı o kadar artar ki, hangi senaryoyu test ettiğinizden emin olamazsınız. Bir ajanın bir aracı beklenmedik bir sırayla çağırması, başka bir ajanın sonsuz yeniden deneme döngüsüne girmesi, iki ajanın birbirini tetikleyerek maliyeti patlatması... Bunların hepsi üretimde başınıza gelir ve hiçbirini demoda görmezsiniz.

"

Karmaşıklığı yönetmenin yolu daha zeki bir model değil, daha dar bir kapsamdır. Her ajanın yapabileceklerini bilinçli olarak sınırlarsanız, sistemin davranış uzayını küçültürsünüz ve ancak o zaman test edilebilir, öngörülebilir bir sistem elde edersiniz.

3. Yönetişim boşlukları ve envanter eksikliği

Bu, kurumsal ölçekte en ölümcül olanı. Bir ajan üretimde çalışıyor ve şu soruları soruyorum: Bu ajan hangi sistemlere erişebiliyor? Dün hangi aksiyonları aldı? Kim onayladı bu erişimi? Bir yanlış işlem yaparsa sorumlusu kim? Çoğu kurumda bu soruların cevabı yok. Ajanlar bir envanterde kayıtlı değil, aksiyonları izlenmiyor, erişimleri merkezi bir yerden yönetilmiyor.

Sektör raporlarının pilotların ölüm sebebi olarak en sık işaret ettiği şey tam da bu: yönetişim boşlukları, ajan aksiyonlarını envanterleyip izleyememe, yetersiz izleme ve parçalanmış sahiplik. Bir kurum, ne yaptığını bilmediği bir yazılımı üretime almaz. Ajan da bir yazılımdır; üstelik karar veren, aksiyon alan, kendi kendine yol seçen bir yazılım. Bu, denetim ihtiyacını azaltmaz, katlar.

4. Gözlemlenebilirlik eksikliği: göremediğinizi yönetemezsiniz

Klasik yazılımda bir hata olduğunda log'lara bakarsınız, stack trace okursunuz, sorunu bulursunuz. Ajan sistemlerinde çoğu ekip bu altyapıyı kurmadan üretime kalkışıyor. Ajan bir karar veriyor ama o kararın neden verildiğini, hangi bağlamla, hangi araç çıktısıyla verildiğini kaydeden bir iz yok.

Üretimde bir ajan yanlış bir şey yaptığında, "neden böyle yaptı" sorusuna saatlerce cevap arıyorsunuz çünkü ortada iz yok. Her adımın, her araç çağrısının, her model kararının, her bağlam okumasının kaydedildiği uçtan uca bir izleme (tracing) altyapısı olmadan ajan sistemi işletmek, gözleri kapalı araba kullanmaya benzer. Bir süre gider, sonra kaza yaparsınız.

5. Entegrasyon ve güvenlik direnci

Ajanın değer üretmesi için mevcut sistemlerinize bağlanması gerekir; CRM'e, ERP'ye, veritabanına, iç servislere. İşte pilotların en sık burada takıldığını görüyorum. Güvenlik ekipleri, kontroller olmadan API'leri ajanlara açmaya haklı olarak direniyor. "Bu ajan bizim üretim veritabanımıza yazabilecek mi? Hangi güvenceyle?" sorusu, birçok pilotu tam da üretime geçiş anında donduruyor.

Bu bir dirençsizlik değil, sağlıklı bir refleks. Kurumların yüzde 75'inden fazlası tedarikçi ve API bağımlılığı riskinden endişe ediyor. Ajan mimarisi bu endişeyi hafifletmiyor, artırıyor; çünkü artık kararı bir insan değil, otonom bir sistem veriyor. Entegrasyonu güvenli, kapsamı dar ve denetlenebilir biçimde tasarlamazsanız, güvenlik ekibi pilotunuzu üretim kapısında durdurur. Ve haklıdır.

Aşağıdaki tabloyu, sahada gördüğüm başarısızlık sebeplerini karşılık gelen çözümlerle eşleştirmek için hazırladım. Bir pilotu değerlendirirken bu tabloyu bir teşhis aracı gibi kullanabilirsiniz.

Başarısızlık Sebebi	Belirtisi	Çözüm
Bağlam tutarsızlığı	Ajanlar çelişen kararlar veriyor, "hangi veri doğru" belirsiz	Paylaşılan, kalıcı bağlam katmanı; tek gerçek kaynağı
Orkestrasyon karmaşıklığı	Test edilemeyen davranışlar, sonsuz yeniden deneme, maliyet patlaması	Kapsamı daraltılmış araçlar, adım/derinlik sınırları, deterministik sınırlar
Yönetişim boşluğu	"Bu ajan ne yapabiliyor" sorusuna cevap yok	Ajan envanteri, erişim politikaları, net sahiplik
Gözlemlenebilirlik eksikliği	Hata olunca "neden" sorusu saatlerce cevapsız	Uçtan uca izleme, her karar ve araç çağrısının kaydı
Entegrasyon/güvenlik direnci	Güvenlik ekibi API açmayı reddediyor	Dar kapsamlı yetkiler, onay katmanları, denetim izi
İnsan onayının eksikliği	Yüksek riskli aksiyonlar denetimsiz gidiyor	Kritik adımlarda human-in-the-loop kapıları
Değerlendirme (eval) eksikliği	"Daha iyi mi oldu" sorusu ölçülemiyor	Otomatik eval seti, regresyon testleri, kalite metrikleri

Şimdi işin çözüm tarafına geçelim. Yıllardır farklı kurumlarda uyguladığım ve işe yaradığını gördüğüm bir referans mimari var. Bunu bir ürün değil, bir düşünme çerçevesi olarak sunuyorum. Beş katmandan oluşuyor ve her katman yukarıda saydığım katillerden birini doğrudan etkisiz hâle getiriyor.

Katman 1: Paylaşılan bağlam katmanı

Mimarinin kalbi burası. Tüm ajanların okuyup yazdığı, durumun tek bir yerde tutulduğu kalıcı bir bağlam deposu kuruyorsunuz. Bu, bir ajanın ürettiği bilginin diğer ajanlar tarafından tutarlı biçimde görülmesini sağlar. Ajan hafızasının uçucu olduğunu kabul ediyor ve bu uçuculuğu paylaşılan bir katmanla telafi ediyorsunuz.

Pratikte bu katman şunları içerir: görevin mevcut durumu, ajanların ürettiği ara sonuçlar, kullanıcı ve oturum bağlamı, ve hangi verinin ne zaman güncellendiğini gösteren bir sürüm bilgisi. Kritik nokta, her ajanın kendi kopyasını değil, bu ortak katmanı tek gerçek kaynağı olarak kullanmasıdır. Bir ajan adresi güncellediğinde, diğer ajanlar aynı anda güncel adresi görür. Bağlam tutarsızlığı katilini tam da burada öldürürsünüz.

Katman 2: Kapsamı daraltılmış araçlar

Her ajana verdiğiniz araçları bilinçli olarak sınırlandırın. Bir ajanın "her şeyi yapabilen" bir araç setine sahip olması cazip görünür ama felakete davetiyedir. Bunun yerine her ajana yalnızca görevi için gereken minimum aracı verin ve o araçların yetkisini de daraltın.

Örneğin bir müşteri sorgu ajanına yalnızca okuma yetkisi verirsiniz; yazma yetkisi ayrı, denetlenen bir ajanda olur. Bir aracın kaç kez, hangi limitlerle çağrılabileceğini tanımlarsınız. Yeniden deneme sayısına, delegasyon derinliğine ve toplam adım sayısına sert sınırlar koyarsınız. Bu, orkestrasyon karmaşıklığının üssel büyümesini frenler ve sistemi test edilebilir kılar. Kapsam ne kadar dar olursa, davranış uzayı o kadar küçük, öngörülebilirlik o kadar yüksek olur.

Katman 3: Gözlemlenebilirlik ve izleme

Her adımı kaydedin. Her model kararını, her araç çağrısını, girdisini ve çıktısını, her bağlam okuma ve yazmasını uçtan uca bir iz olarak saklayın. Bir görev başladığında ona bir iz kimliği (trace ID) atayın ve o görevin dokunduğu her şeyi bu kimlik altında toplayın.

Bu altyapı size iki şey kazandırır. Birincisi, bir hata olduğunda "neden böyle oldu" sorusunu saatler değil dakikalar içinde cevaplarsınız. İkincisi, sistemi zaman içinde iyileştirmek için gereken veriyi biriktirirsiniz. Gözlemlenebilirlik olmadan ajan sistemini iyileştiremezsiniz çünkü neyin çalışıp neyin çalışmadığını bilemezsiniz. Bu katman, hem gözlemlenebilirlik eksikliği katilini hem de yönetişimin denetim ayağını doğrudan karşılar.

Katman 4: İnsan onayı (human-in-the-loop)

Her aksiyon otomatik gitmez. Yüksek riskli, geri döndürülemez veya düzenlemeye tabi aksiyonlar için insan onay kapıları koyarsınız. Ajan aksiyonu hazırlar, ama tetiği bir insan çeker. Hangi aksiyonların onay gerektireceğini risk seviyesine göre belirlersiniz.

Bu, hem güvenlik ekibinin direncini çözer hem de düzenleyici uyum için gereken denetlenebilirliği sağlar. Kritik nokta, onay kapılarını her yere değil, doğru yerlere koymaktır. Her adıma onay koyarsanız otomasyonun değerini öldürürsünüz; hiçbir yere koymazsanız güveni öldürürsünüz. Doğru denge, aksiyonun riskiyle orantılı bir onay tasarımıdır.

Katman 5: Değerlendirme (eval) döngüsü

Son katman, çoğu ekibin atladığı ama en çok fark yaratan katman. Ajanınızın kalitesini otomatik ölçen bir değerlendirme seti kurarsınız. Gerçek senaryolardan türetilmiş bir test kümesi, beklenen davranışlar ve otomatik puanlama. Her değişiklikten sonra bu seti çalıştırır, regresyon olup olmadığını görürsünüz.

Eval olmadan "daha iyi mi oldu" sorusunu his ile cevaplarsınız ve his üretimde para kaybettirir. Eval ile bir prompt değişikliğinin, model güncellemesinin veya araç eklemenin sistemi iyileştirip iyileştirmediğini nesnel olarak ölçersiniz. Bu döngü, pilotu tek seferlik bir başarıdan sürekli iyileşen bir sisteme dönüştürür.

Bir pilotu üretime almadan önce şu listeyi bir kapı olarak kullanın. Maddelerin çoğuna "evet" diyemiyorsanız, pilotunuz henüz hazır değildir. Bu listeyi sahada onlarca projede süzerek oluşturdum.

Bağlam ve durum:

• Tüm ajanların okuyup yazdığı paylaşılan bir bağlam katmanı var mı?
• Durumun tek bir gerçek kaynağı tanımlı mı?
• Verinin ne zaman güncellendiği izlenebiliyor mu?

Kapsam ve kontrol:

• Her ajanın araç seti minimuma indirildi mi?
• Yeniden deneme, delegasyon derinliği ve adım sayısı için sert sınırlar var mı?
• Ajanların erişebileceği sistemler açıkça tanımlandı mı?

Yönetişim:

• Tüm ajanların bir envanteri var mı?
• Her ajanın net bir sahibi var mı?
• Erişim politikaları merkezi olarak yönetiliyor mu?

Gözlemlenebilirlik:

• Her karar ve araç çağrısı izleniyor mu?
• Bir hatayı iz kimliğiyle uçtan uca takip edebiliyor musunuz?
• Anormal davranış için uyarı mekanizması var mı?

İnsan onayı ve güvenlik:

• Yüksek riskli aksiyonlar için onay kapıları var mı?
• Güvenlik ekibi entegrasyonu onayladı mı?
• Denetim izi (audit trail) tutuluyor mu?

Değerlendirme:

• Otomatik bir eval seti var mı?
• Regresyon testleri çalışıyor mu?
• Kalite metrikleri tanımlı ve izleniyor mu?

Üretimde bir ajan sistemini sağlıklı tutmak için hangi metrikleri izlediğiniz, sistemin kaderini belirler. İşte sahada değerli bulduğum başlıklar.

Görev tamamlama oranı. Ajanın başlattığı görevlerin ne kadarını insan müdahalesi olmadan doğru şekilde tamamladığı. Bu, sistemin gerçek otonomi seviyesini gösterir.

İnsan devralma oranı (intervention rate). Kaç görevde insanın araya girmesi gerekti. Bu oran zamanla düşmüyorsa, sistem öğrenmiyor ya da yanlış yerde otonomi veriyorsunuz demektir.

Adım başına maliyet ve gecikme. Her görevin kaç model çağrısı, kaç araç çağrısı ve ne kadar süre tükettiği. Orkestrasyon karmaşıklığı ilk olarak burada patlar; maliyet sessizce tırmanır.

Hata ve geri alma oranı. Ajanın kaç aksiyonunun sonradan geri alınması gerekti. Bu, güven için en kritik metriktir.

Bağlam tutarlılığı ihlalleri. Ajanların çelişen kararlar verdiği durumların sayısı. Paylaşılan bağlam katmanınızın işe yarayıp yaramadığını gösterir.

Eval skoru trendi. Zaman içinde değerlendirme setindeki puanın nasıl değiştiği. Bu trend yukarı gitmiyorsa, yaptığınız değişiklikler gerçek bir iyileşme üretmiyor demektir.

"

Ölçmediğiniz şeyi yönetemezsiniz. Ajan sistemlerinde bu klişe, çift katmanlı doğru: hem klasik sistem metriklerini hem de ajana özgü davranış metriklerini izlemeniz gerekir. Birini atlarsanız kör noktanız üretimde sizi vurur.

Bu metriklerle ilgili bir uyarım daha var. Metrikleri sadece toplamak yetmez; onlara bir eşik ve bir sahip atamanız gerekir. "Geri alma oranı yüzde şu değerin üstüne çıkarsa şu ekip uyarılır ve şu aksiyon alınır" diye önceden yazılmış bir kural olmadan, metrik sadece bir gösterge panosunda güzel duran bir sayıdır. Sahada gördüğüm en yaygın hata, kurumların gösterge panosu kurup sonra ona kimsenin bakmamasıdır. Metrik, bir karar tetiklemiyorsa ölü metriktir. Her kritik metriğin bir eşiği, bir sahibi ve o eşik aşıldığında ne olacağını tanımlayan bir müdahale planı olmalı. Ancak o zaman metrikler sizi üretimde ayakta tutar.

Bir gözlemi paylaşmadan geçemeyeceğim, çünkü tekrar tekrar aynı örüntüyü görüyorum. Pilotları en çok öldüren şey başarısızlık değil, erken başarıdır. Ekip iki haftada göz kamaştırıcı bir demo çıkarır, yönetim heyecanlanır ve herkesin beklentisi bir anda tavana vurur. "Madem bu kadar iyi çalışıyor, hemen üretime alalım ve kapsamı da genişletelim" denir. İşte tam bu noktada, yukarıda saydığım beş katilin hiçbiri henüz adreslenmemişken sistem üretim yüküyle karşılaşır ve çöker.

Erken başarının yarattığı tehlike, disiplin kurmaya vakit bırakmamasıdır. Demo başarısı, altyapının hazır olduğu yanılsamasını yaratır. Oysa demo, sistemin kolay yüzde onunu çözer; üretimin gerçek zorluğu kalan yüzde doksandadır. Kenar durumlar, eşzamanlı kullanıcılar, kirli veri, sistem kesintileri ve denetim talepleri hep o yüzde doksanda saklanır. Ekip erken başarının rüzgârıyla o yüzde doksanı atlayınca, üretim onları en kötü anda yakalar.

"

Bir pilotun demo başarısını üretim hazırlığıyla karıştırmayın. Demo, "yapılabilir mi" sorusunu cevaplar. Üretim, "her gün, her koşulda, denetlenebilir biçimde yapılabilir mi" sorusunu cevaplar. Bu ikisi arasındaki mesafe, çoğu ekibin sandığından çok daha uzundur.

Benim önerim, demo başarısının hemen ardından tempoyu bilinçli olarak yavaşlatmak ve o coşkuyu disiplin kurmaya yatırmaktır. Başarı anını "hızlanma" değil, "sağlamlaştırma" fırsatı olarak görün. Kapsamı genişletmeden önce bu yazıdaki beş katmanı inşa edin. Yavaşlamak burada gerilemek değil, üretimde ayakta kalmanın tek yoludur.

Türkiye'de faaliyet gösteren kurumlar için ajan mimarisinin uyum boyutu, sonradan eklenen bir katman değil, en baştan tasarıma gömülmesi gereken bir gerçekliktir. KVKK çerçevesinde birkaç konu doğrudan yukarıda anlattığım mimariyle örtüşüyor ve bu bir tesadüf değil; iyi mimari zaten uyumu kolaylaştırır.

Denetim izleri. Bir ajan kişisel veri işliyorsa, o işlemenin kaydı tutulmalı. Katman 3'te anlattığım uçtan uca izleme, tam da bu denetim izini doğal olarak üretir. İyi haber şu: gözlemlenebilirliği doğru kurduysanız, KVKK'nın istediği denetlenebilirliğin büyük kısmını zaten karşılamış olursunuz.

Veri erişim kontrolleri. Ajanların hangi veriye erişebileceği net biçimde sınırlandırılmalı. Katman 2'deki kapsam daraltma ve Katman 1'deki merkezi bağlam yönetimi, bu kontrolleri uygulanabilir kılar. Bir ajanın "gerektiğinden fazla veriye" erişmesi hem güvenlik hem uyum açısından risktir; dar kapsam bunu baştan engeller.

Açıklanabilirlik. Bir ajan bir kişi hakkında karar verdiğinde, o kararın nasıl alındığını açıklayabilmeniz gerekir. İzleme altyapınız her kararın hangi bağlamla ve hangi girdiyle verildiğini sakladığı için, açıklanabilirlik talebine cevap verebilirsiniz. İz olmadan bu talebe cevap vermek imkânsızdır.

İnsan onayı. Özellikle düzenlemeye tabi sektörlerde (finans, sağlık, sigorta) yüksek etkili kararlarda insanın döngüde olması hem beklenir hem çoğu zaman gereklidir. Katman 4'teki human-in-the-loop kapıları bu ihtiyacı doğrudan karşılar. Otonomi ile denetim arasındaki dengeyi burada kurumun risk iştahına ve sektörün düzenleyici çerçevesine göre ayarlarsınız.

Buradaki mesajım şu: uyumu bir enge

Bu yazı boyunca mimariden, katmanlardan ve metriklerden konuştum. Ama sahada gördüğüm en büyük gerçeği en sona sakladım: ajan pilotlarının çoğu teknik bir sebeple değil, organizasyonel bir sebeple ölür. Teknoloji çözülebilir bir problemdir; bir ekip yeterince zaman ve odakla neredeyse her teknik engeli aşar. Çözülemeyen şey, sahipliğin belirsiz olması, ekipler arası sorumluluğun dağılması ve kimsenin "bu ajan benim" diyememesidir.

Parçalanmış sahiplik neden bu kadar öldürücü? Çünkü bir ajan üretimde bir sorun çıkardığında, sorunu kimin çözeceği belli değilse çözülmez. Veri ekibi "bu bir model sorunu" der, model ekibi "bu bir entegrasyon sorunu" der, entegrasyon ekibi "bu bir yönetişim sorunu" der ve top sürekli birinden diğerine atılır. Bu arada ajan üretimde yanlış işler yapmaya devam eder ve güven erozyona uğrar. Bir süre sonra kurum, en güvenli seçeneğin ajanı kapatmak olduğuna karar verir. Pilot böyle ölür; bir teknik hatadan değil, bir sahiplik boşluğundan.

Bunu önlemenin yolu, projeyi başlatırken üç soruyu net cevaplamaktır. Birincisi: her ajanın tek bir sahibi kim? Bir isim, bir ekip; belirsizlik değil. İkincisi: bir ajan bir hata yaptığında ilk 30 dakikada kim müdahale eder? Bir nöbet ve eskalasyon zinciri tanımlı mı? Üçüncüsü: ajanı üretime alma kararını kim verir ve hangi kriterlere göre verir? Bu kararın bir sahibi ve bir kapısı var mı? Bu üç sorunun cevabı netse, teknik engelleri aşmak çok daha kolaylaşır. Cevabı belirsizse, en iyi mimari bile sizi kurtarmaz.

Son olarak, ajan projelerinde iş birimi ile teknik ekip arasındaki köprüyü ihmal etmeyin. Ajanın ürettiği değeri iş birimi tanımlar; onun kalitesini iş birimi değerlendirir. Eğer eval setinizi iş biriminin gerçek beklentileriyle hizalamazsanız, teknik olarak "başarılı" ama iş açısından değersiz bir ajan üretirsiniz. Sahada en sürdürülebilir ajan sistemlerini, teknik ekiple iş biriminin aynı masada oturduğu, aynı metriklere baktığı ve sahipliği paylaştığı kurumlarda gördüm. Teknoloji orada sadece bir araçtı; asıl fark, disiplin ve ortak sahiplikti.