Yapay zeka ajanları ne zaman kendi başlarına işlem yapmalı, ne zaman yapmamalı?

“Ajan” kelimesi çok geniş bir alanı kapsıyor. Bu notta ajan derken, bir sonraki adımına bir modelle karar veren ve o adımı atan yazılımı kastediyoruz: bir talebi okur, bilgi arar, araçları çağırır ve başka bir sistemde bir şeyi değiştirir. Ajanları faydalı kılan da riskli kılan da bu son kısımdır.

Yetenekli modeller çok adımlı işleri şaşırtıcı derecede iyi planlayabilir. Bu yüzden yapay zeka ajanı özerkliğinde pratik soru, bir ajanın bir görevi yapıp yapamayacağı değildir (ya da bir ajana gerçekten ihtiyacınız olup olmadığı). Asıl soru, ajanın nerede sormadan işlem yapacağı, nerede işi hazırlayıp kararı bir insana bırakacağıdır. Bunun için basit bir test kullanırız.

Bir işlemi güvenle otomatikleştirmek için ne gerekir?

Dört özelliğe bakarız. Dördünü de taşıyan bir işlem özerklik için adaydır. Herhangi birini taşımayan bir işlem ise bir insanı beklemelidir.

• Geri alınabilir. Hızlıca ve tamamen geri alınabilir mi? Bir destek talebini etiketlemek, bir taslak alanını doldurmak ya da bir vakayı bir kuyruktan diğerine taşımak geri alınabilir. Bir tedarikçiye ödeme yapmak, bir kaydı silmek ya da bir müşteriye e-posta göndermek geri alınamaz.
• Düşük maliyetli. Ters giderse zarar küçük mü? Yanlış yere yönlendirilmiş bir iç talep birkaç dakikaya mal olur. Yanlış bir para iadesi, yanlış bir fiyat ya da kaçırılmış bir yasal süre ise çok daha pahalıya gelir.
• Kayıt altında. Her adım, ajanın gördüğü girdilerle ve belirttiği gerekçeyle birlikte kaydediliyor mu? Ne olduğunu yeniden kuramıyorsanız bir hatadan ders çıkaramaz, neyin doğru gittiğini de gösteremezsiniz.
• Dar kapsamlı. Kapsam, bilinen bir araç seti ve bilinen bir vaka türüyle sıkı biçimde tanımlanmış mı? “Teslimat sorularını doğru kuyruğa yönlendirmek” dar kapsamlıdır. “Müşteri hizmetlerini yürütmek” değildir.

Test bilerek temkinlidir. Bir ajana sonradan daha fazla alan tanımak, pahalı bir hatadan sonra güveni onarmaktan daha kolaydır.

Özerkliğin düzeyleri nelerdir?

Özerklik bir açma-kapama düğmesi değildir. Her görevi dört düzeyden birinde tasarlarız; aynı iş akışındaki farklı görevler de çoğu zaman farklı düzeylerde durur.

1. Öneri. Ajan önerir, insan uygular. Örneğin bir talep için kategori önerir, seçimi bir insan yapar.
2. Taslak. Ajan işin tamamını hazırlar, bir insan gözden geçirir. Örneğin sipariş verisi ve politika paragrafı eklenmiş, bir müşteri temsilcisinin göndermesini bekleyen bir yanıt.
3. Onaylı işlem. Ajan, bir insan onayladığında işlemi yürütür; onay çoğu zaman tek tıktır. Örneğin bir muhasebecinin taslağı onaylamasının ardından ERP’ye işlenen bir kayıt.
4. İşlem ve raporlama. Ajan kendi başına işlem yapar ve ne yaptığını kaydeder; insanlar örneklemleri ve istisnaları inceler. Örneğin gelen talepleri etiketlemek ve yönlendirmek.

İlk projelerin çoğu ikinci ve üçüncü düzeyde durur. Dördüncü düzey kazanılır, her seferinde tek bir dar görev için.

Tek bir iş akışında bu neye benzer?

Temsili bir örnek ele alalım: gelen tedarikçi faturalarını bir ajanın işlediği bir borçlar muhasebesi iş akışı. İçindeki görevler farklı düzeylerde durur:

• Faturayı okumak ve sınıflandırmak: işlem ve raporlama. Geri alınabilir, kayıt altındadır ve sonucu bir insan zaten daha sonra görür.
• Faturayı satın alma siparişi ve irsaliyeyle eşleştirmek: taslak. Ajan eşleşmeyi önerir ve her uyuşmazlığı açıklar; bir muhasebe çalışanı onaylar.
• ERP kaydını hazırlamak: onaylı işlem. Kayıt ancak bir muhasebeci onayladıktan sonra işlenir.
• Tedarikçi banka bilgilerini değiştirmek: asla otomatikleştirilmez. Bu tür her talep, bilinen bir dolandırıcılık örüntüsü olarak işaretlenip bir insana gider.
• Ödeme: tamamen ajanın yetkileri dışındadır.

Tek iş akışı, beş görev, dört farklı yanıt. Hata, “fatura ajanının” özerk olup olmayacağını sormaktır. Doğru soru şudur: hangi görev, hangi sınırlar içinde?

Ajan özerkliği görev görev kazanmalı ve bunu kayıtlarla kanıtlamalıdır.

Hangi kararlar her zaman insanda kalmalı?

Bazı kararlar, ajan ne kadar iyi olursa olsun insanlarda kalır:

• üzerinde anlaşılmış bir eşiğin üzerinde para hareket ettiren her şey;
• müşterilere, tedarikçilere ya da başka şirketlere verilen taahhütler: fiyatlar, teslim tarihleri ya da sözleşme koşulları gibi;
• işe alım, performans ve erişim hakları dahil, insanlarla ilgili kararlar;
• veri silen ya da geri alınamayan her şey;
• hukuki, mevzuata ya da güvenliğe ilişkin değerlendirmeler;
• ajanın düşük güven bildirdiği ya da girdinin olağan dışı göründüğü her vaka.

Bu, modellerin kalitesi hakkında bir yorum değildir; hesap verebilirlikle ilgilidir. Bu alanlarda bir şey ters gittiğinde kurumun, kararı kanıtlar önündeyken veren, adı belli bir kişiye ihtiyacı vardır.

Bir insana aktarılan vakada neler olmalı?

Ajan durup bir vakayı bir insana aktardığında, ajanın zaman mı kazandırdığını yoksa iş mi çıkardığını bu aktarım belirler. İyi bir aktarım; talebin ne olduğunu, ajanın neleri kontrol ettiğini, ne bulduğunu, hangi kaynakları kullandığını, neden durduğunu ve bir sonraki adım için ne önerdiğini söyler. Kişi, aramayı baştan yapmadan tek bir ekrandan karar verebilmelidir. Aktarımlar sık sık yeniden işlem gerektiriyorsa bu, ajanın rolü büyümeden önce çözülmesi gereken bir tasarım sorunudur.

Hangi koruma önlemleri modele bağlı değildir?

Bir model ikna edilebilir, kafası karışabilir ya da düpedüz yanılabilir. Bu yüzden en önemli koruma önlemleri modelin dışında, sıradan yazılımda durur:

• En az yetki. Ajan yalnızca görevinin gerektirdiği yetkileri alır: okumanın yettiği yerde okuma erişimi, belirli alanlara yazma erişimi, asla yönetici hesabı.
• İzin verilen işlemler. Ajanın kullanabileceği araçların ve işlemlerin sabit bir listesi. Listede olmayan her şeyi prompt değil, sistem reddeder.
• Bütçeler ve hız sınırları. Harcamaya, saat başına işlem sayısına ve tek bir işlemin büyüklüğüne tavan konur.
• Durdurma anahtarı. Süreç sahibi ajanı anında duraklatabilir; ajanın vakaları bu durumda insanlara geri döner.
• Kendi kimliği. Ajan kendi servis hesabıyla çalışır; böylece her sistemdeki her değişiklik ona kadar izlenebilir.
• Tekrarda zarar vermeyen işlemler. İşlemler, yanlışlıkla iki kez çalıştırıldığında zarar vermeyecek biçimde tasarlanır; örneğin ödeme göndermek yerine bir taslağı güncellemek.
• Denetim kaydı. Her girdi, adım, araç çağrısı ve çıktı kaydedilir ve aranabilir.
• Önce test ortamı (sandbox). Yeni görevler, canlı sistemlere dokunmadan önce test sistemlerinde çalışır.

Bunlar yerinde olduğunda, model ne karar verirse versin ajanın yapabileceği en kötü şey tasarım gereği sınırlıdır.

Ajanın okuduğu her şeye neden güvenilmemeli?

Ajanlar başkalarının yazdığı metinleri okur: e-postalar, belgeler, web sayfaları, form alanları. Bunların herhangi biri talimat içerebilir. Bir faturada, ajandan tedarikçinin banka bilgilerini değiştirmesini isteyen gizli bir metin olabilir. Bir müşteri e-postası, başka bir hesabın sipariş geçmişini iletmesini isteyebilir. Buna prompt enjeksiyonu (prompt injection) denir ve ajanlar için sohbet asistanlarından daha önemlidir, çünkü ajanlar işlem yapabilir. İnternette gezinen ajanlar ayrıca dikkat ister: bir sayfa özellikle onları yönlendirmek için yazılmış olabilir.

Savunmalar pratiktir. Talimatları ve veriyi ayrı tutun; ajan bir belgeyi itaat edilecek bir şey olarak değil, analiz edilecek bir şey olarak ele alsın. Araçları ve yetkileri sınırlayın; enjekte edilen bir talimatın gidebileceği bir yer kalmasın. Hassas işlemler için onay isteyin; enjekte edilen bir talep bir insanla karşılaşsın. Son olarak bunu test edin: saldırı örnekleri değerlendirme setine girer ve her değişiklikten sonra yeniden çalışır.

Özerklik kanıta dayanarak nasıl genişletilir?

Ajan canlı işe dokunmadan önce onu gölge modda çalıştırın: ekiple yan yana gerçek vakaları işler ama işlemleri hiçbir yere gitmez. Önerilerini insanların gerçekte yaptıklarıyla karşılaştırmak, var olan en ucuz testtir.

Ardından her yeni göreve öneri ya da taslak düzeyinde başlayın. Ajanın ne önerdiğini ve kişinin neye karar verdiğini kaydedin. Yeterli sayıda vakadan sonra elinizde o belirli görev için, vaka türüne göre ayrıştırılmış, ölçülmüş bir uyum oranı olur.

Uyum işin dar bir diliminde sürekli yüksekse, örneğin tek bir kanaldaki teslimat sorularının yönlendirilmesinde, o dilim bir düzey yukarı çıkabilir. Geri kalanı olduğu yerde kalır. Değişiklikten sonra da örneklem almayı sürdürün; kalite düşerse ya da girdiler değişirse görevi bir düzey aşağı indirin. Bu şekilde verilen özerklik belirli, geri alınabilir ve belgelenmiştir. Yani ajanın kendisinden bekleyeceğiniz niteliklerin aynısını taşır.

Kısacası ne yapmalı?

İşlemlerin geri alınabilir, düşük maliyetli, kayıt altında ve dar kapsamlı olduğu yerlerde ajanların tek başına çalışmasına izin verin. Diğer her yerde bilgi toplamayı, kontrol etmeyi ve taslak hazırlamayı, yani çoğu zaman işin büyük kısmını ajana bırakın; kararı bir insan versin. Bu iş bölümü bir kısıtlama değildir. Müşterilerinizin ve düzenleyici kurumların beklediği muhakemeden vazgeçmeden otomasyonun hızını böyle elde edersiniz. Bir görevin hangi düzeye ait olduğundan emin değilseniz onu düşündüğünüzden bir düzey aşağıya koyun, bir ay boyunca ölçün ve kararı kayıtlara bırakın.

Kaynaklar

1. LLM06:2025 Excessive Agency OWASP Gen AI Security Project genai.owasp.org/llmrisk/llm062025-excessive-agency
2. LLM01:2025 Prompt Injection OWASP Gen AI Security Project genai.owasp.org/llmrisk/llm01-prompt-injection