Yapay Zekâ Ajanlarınızın Daha İyi İstemlere Değil, İş Tanımlarına İhtiyacı Var

Bir şirkete yeni işe alınan bir borç hesapları analistinin neler yapmaya yetkili olduğunu sorun; size net bir yanıt verir. Analist bu sistemlerde ve bu tedarikçilerle çalışır; örneğin 10.000 $’lık onay sınırını aşan her işlem, imza için yöneticisine gider. İlk birkaç ayında deneme süresindedir. Bunların tümü genellikle iç denetimin her yıl kontrol ettiği yetki devri tablosunda yer alır.

Aynı şirkete yeni fatura ajanının neler yapmaya yetkili olduğunu sorun; çoğu zaman size bir istemin ekran görüntüsünü gösterir.

Bu uçurum beni, herhangi bir model kıyaslamasından daha fazla rahatsız ediyor. İnsanlar için bir yüzyılda kurduğumuz yönetim sistemi olmadan dijital bir iş gücü oluşturuyoruz: kimse bu iş gücünün yetkilerini yazılı hâle getirmiyor, işe başlamadan önce muhakemesini sınamıyor ve onu nasıl devre dışı bırakacağını prova etmiyor.

İstem Neden İşin Yerini Tutamaz

İstem, niyeti açıklar. Ajanın ne için olduğunu söyler. Ancak ajanın neleri asla yapamayacağını, sınırlarının nerede olduğunu ya da ne zaman durup kararı bir insana devretmesi gerektiğini nadiren belirtir.

Üstelik istem bunları belirtse bile hiçbir şey bu kuralları uygulamaya koymaz. Ajanın 500 $’ı aşan tutarlarda geri ödeme yapmamasını söyleyen bir satır, olasılıksal bir sisteme yöneltilmiş bir istektir. Hiçbir denetçi, bir insan için kontrol olarak “analiste nazikçe rica ettik” ifadesini onaylamaz; öyleyse yazılımlar için bunu neden kabul ettiğimizi anlamıyorum.

Güvenlik uzmanlarının bu sonucun adını koymuşluğu var. OWASP Top 10 for LLM Applications, aşırı işlevsellikten, aşırı izinlerden veya aşırı özerklikten kaynaklanan temel risklerden biri olarak Aşırı Özerkliği sıralıyor. Açıkça söylemek gerekirse, bu, daha ilk günden her şeyin anahtarı eline verilmiş bir çalışan demek. OWASP’ın yönergeleri, iyi bir yöneticinin kontrol listesi gibi: ajana yalnızca ihtiyaç duyduğu araçları verin, izinlerinin kapsamını sınırlayın, etkisi yüksek eylemler için insan onayı isteyin ve yetkilendirmeyi modelin kendi kendini denetlemesine güvenmek yerine sonraki sistemlerde uygulayın.

Son maddeyi özellikle vurgulamak isterim. Yetki, eylemin gerçekleştiği yerde tanımlanmalı: ajanın kendi hizmet kimliğinde, araç izinlerinde ve API ağ geçidindeki harcama sınırında. Ajanları ortak bir hizmet hesabıyla çalıştırmak, beş kişinin tek bir yaka kartını paylaşmasına benzer. Bir şeyler ters gittiğinde denetim kaydı, bunu hizmet hesabının yaptığını gösterir; hangi ajanın yaptığını ise tahmin etmek zorunda kalırsınız.

İptaller Yönetim Sorununa İşaret Ediyor

Gartner, artan maliyetleri, belirsiz iş değerini ve yetersiz risk kontrollerini gerekçe göstererek 2027’nin sonuna kadar ajan tabanlı yapay zekâ projelerinin %40’ından fazlasının iptal edileceğini öngörüyor.

Abartılı beklentiler ve olgunlaşmamış ürünler de bu tablonun bir parçası. Yine de bu üç nedeni bir operasyon direktörünün gözünden değerlendirmeyi deneyin. Kimse bütçe belirlemediğinde maliyetler artar. Yapılması gereken işin ne sonuç vermesi gerektiği yazılı hâle getirilmediğinde değer belirsiz kalır. Sınırlar, incelemeler ve hesap vereceği açıkça belirlenmiş kimse olmadığında risk kontrolleri yetersiz kalır. Gartner konuyu bu şekilde çerçevelemiyor; bu, benim yorumum. Bu, insanlar bir yönetim sistemi olmadan başıboş bırakıldığında yaşananlarla aynı şey ve bu sorun yapay zekâdan çok daha eski.

Çerçeveler de aynı boşluğu görüyor. NIST Yapay Zekâ Risk Yönetimi Çerçevesi, Yönetişim işlevinin Haritalama, Ölçme ve Yönetme aşamalarının tümünde işlediğini kabul ediyor; Üretken Yapay Zekâ Profili de bunu üretken sistemlere taşıyor. Ancak çerçeveler size, bir ekibin sıradan bir salı günü gerçekten kullandığı işleyiş mekanizmasını; yani yetki tanımlarını, testleri ve incelemeleri sağlayamaz. Bunlar olmadığında yönetişim, ortak sürücüde duran bir PDF’den ibaret kalır.

Geleneksel Yönetim Araçlarını Ajanlara Uyarlamak

İş tanımıyla başlayın; ajanlar söz konusu olduğunda bu, bir yetki tanımına dönüşür. Bir ajan canlı bir sisteme erişmeden önce biri, neleri yapabileceğini, neleri asla yapamayacağını, onay eşiklerini, ajandan kimin sorumlu olduğunu ve sınırlarını kimin genişletebileceğini tek sayfada yazabilmelidir. RACI matrisinde hesap verecek taraf bir kişidir. Bu sayfayı yazamıyorsanız rolü doldurmaya hazır değilsiniz demektir; bir insanı işe alırken de aynı şeyi söylersiniz.

Yetki devrine ilişkin iki eski kural burada da geçerliliğini koruyor. Sahip olmadığınız bir yetkiyi devredemezsiniz; bu nedenle bir alt ajan, kendisini oluşturan ajandan daha geniş yetkilere asla sahip olmamalıdır. Görevlerin ayrılığı ilkesi de geçerlidir. Hem tedarikçi kaydı oluşturabilen hem de o tedarikçiye ödeme yapabilen bir ajan, bir insanda da aynı denetim bulgusuna yol açardı.

Ardından işe alım testi gelir. Ajanları çoğunlukla hesap makinesini sınar gibi, yanıtın doğru olup olmadığına bakarak test ediyoruz. Bir çalışan için yapılacak testse ajanın yetki sınırları içinde kalıp kalmadığını, gerektiğinde onay isteyip istemediğini, durum görev tanımını aştığında konuyu üst kademeye taşıyıp taşımadığını ve yapması gereken yerde durup durmadığını ölçer.

Kendi araştırmamda, tam da bu tür hataları ele alan 50 senaryoluk bir kıyaslama seti hazırlıyorum: onay sınırlarını aşmak, güncelliğini yitirmiş verilerle işlem yapmak, kapsamı genişleten enjekte edilmiş talimatları izlemek ve rol değişikliğinden sonra erişimi sürdürmek. Şimdiye kadar bunu yalnızca senaryoların tasarlandığı gibi işlediğini kontrol etmek için betiklerle çalışan ajanlarda denedim; dolayısıyla paylaşabileceğim model sonucu yok. Senaryoları yazarken beni şaşırtan, ne kadar sıradan olduklarıydı. Bunlar, çalışanların görev tanımlarının dışına çıkmasının olağan yolları; yalnızca yazılıma uyarlanmış hâlleri. Kamuya açık liderlik tablolarının çoğu hâlâ görevin tamamlanıp tamamlanmadığını puanlıyor; ajanın yetkilerine uyup uymadığını puanlayanların sayısıysa çok az.

Deneme süreci ve terfi kavramlarını aktarmak oldukça kolay. İnsanları işe alırken kapsamı dar tutar, muhakeme yeteneklerini kanıtladıkça yetkilerini genişletiriz. Ajanlar da aynı şekilde, yetki sınırları içinde kaldıklarını, gerektiğinde konuyu uygun biçimde üst makamlara taşıdıklarını ve işleri sorunsuz biçimde durdurduklarını gösteren bir sicil oluşturarak sınırlarını genişletebilir. Aynı sicil, verilen yetkinin daraltılmasını da rahatlıkla haklı çıkarabilir.

Ajanlarda, insanlarda olmayan bir karmaşıklık daha var. Bir tedarikçi temel modeli yükselttiğinde, eski kimlik kartını takan yeni bir çalışanınız olmuş gibi oluyor. Bunu bir değişiklik olayı olarak ele alır ve verilen yetkiyi devretmeden önce yeniden test ederdim.

İşten çıkarma süreci, gerekmeden önce prova edilmelidir. Bu ajanı durdurup erişimini önümüzdeki bir saat içinde kaldırmanız gerekse, bunu yapabilir miydiniz? Bu kararı gece 2’de verme yetkisi kimde? Sonraki aşamalarda neler aksar ve devam eden hangi taahhütleri birilerinin elle geri alması gerekir? Kimse bu tatbikatı yapmadıysa, acil durdurma anahtarının işe yarayacağını umuyorsunuz demektir.

Bir çalışanı sorumlu tutabilirsiniz. Bir ajanı hiçbir şeyden sorumlu tutamazsınız; karşılaştırmanın geçerliliğini yitirdiği nokta da budur. Yetkinin sistemler tarafından uygulanması ve her ajanın sorumluluğunu üstlenen, adı belirli bir kişinin bulunması da bu yüzden gerekir. Her durumda birinin hesap vermesi gerekir. Genellikle bu kişi, imza attığının farkında olsun ya da olmasın, onayı veren kişidir.

Olay İncelemesinde Sorulacaklar

Bu ajanlardan bazıları er ya da geç yapmamaları gereken bir şeyi yapacak. Bu olduğunda, olay sonrası incelemede insanlarla ilgili olarak zaten sorulan sorular sorulacak. Ne yapmasına izin verilmişti ve bu izin nerede yazılı? Erişimini genişletmeyi kim onayladı? Durdurulması ne kadar sürdü? Sorumlusu kimdi?

Dürüst yanıtlar “bir istem”, “kimse hatırlamıyor”, “saatler” ve “belirsiz” ise, daha iyi bir model sizi kurtarmazdı.

Avantajın Asıl Ortaya Çıktığı Yer

Modeller, tedarikçilerin takvimine göre değiştirilen ve yükseltilen, kiralık girdilere dönüşüyor. İki şirket aynı modeli kullanıp birbirinden çok farklı sonuçlara ulaşabilir. Birinin bütçeleri, sınırları ve sorumluları belirlenmiş ajanları, ayrıca sonuç doğuran her eylem için bir denetim izi vardır; diğerinin elindeyse birilerinin iptal istatistiklerine girmeye aday, pahalı bir pilot uygulama vardır.

Farkı yaratan, modelin çevresindeki yönetim sistemidir. Bu sistem yavaş yavaş, çoğunlukla daha önce kurum yönetmiş kişiler tarafından kurulur.

En yeni ajanınız yarın yetkisini aşsa, şirketinizde bunu fark edecek herhangi bir şey olur muydu? Sınırın nerede olduğunu bir denetçiye yazılı olarak gösterebilir miydiniz?