Sistemlerinizin İçinde Yapay Zekâ Ajanları: Bir Ajan Tek Başına Ne Yapabilir, Bir Kişi Neyi Onaylamalı ve Kontrolü Kaybetmeden Nasıl Başlanır

Yapay zekâ ajanı, yazılımınızdan fonksiyon çalıştırmasını isteyebilen bir dil modelidir; fonksiyon burada bir ödemeyi sorgulamak, bir destek talebini güncellemek ya da iade yapmak gibi eylemler demektir. Model yalnızca isteği iletir. Bunun yerine getirilip getirilmeyeceğine sistemleriniz karar verir ve kontrolü elinizde tuttuğunuz yer de burasıdır. Ajanın veriyi okuyup taslakları kendi başına hazırladığı dar bir görevle başlayın. Para hareket ettiren, bir müşterinin kaydını değiştiren ya da şirketin dışına çıkan her şeyi adı belirlenmiş bir kişi onaylar.

Sade bir dille yapay zekâ ajanı nedir?

ChatGPT'nin arkasındaki türden bir yapay zekâ olan dil modeli metin üretir. Ajan ise sistemlerinizdeki fonksiyonlara bağlanmış bir dil modelidir; bu yüzden çıktısı bir yanıt olabileceği gibi bir eylem de olabilir.

Anthropic'in Claude modelleri için hazırladığı dokümantasyon şöyle diyor: “Araç kullanımı (fonksiyon çağırma olarak da adlandırılır), Claude'un sizin tanımladığınız ya da Anthropic'in sağladığı fonksiyonları çağırmasını sağlar.” Sizin tanımladığınız fonksiyonlar için model, “uygulamanızın çalıştırdığı yapılandırılmış bir çağrı döndürür”. Model isteği yazar; yazılımınız da onu çalıştırır ya da reddeder. Bu yazıdaki tüm kaynaklara 2 Kasım 2026'da erişildi.

Ajan bunu bir döngü içinde tekrarlar. Görev bitene kadar bir fonksiyonu çağırır, sonucu okur ve bir sonraki adımı seçer. Anthropic'in mühendislik blogundaki 2024 tarihli bir yazı ajanları “genellikle, ortamdan gelen geri bildirime dayanarak araçları bir döngü içinde kullanan LLM'lerden ibaret” olarak tanımlıyor. LLM, büyük dil modelinin (large language model) kısaltmasıdır; araçlar ise modelin çağırabildiği fonksiyonlardır.

Yani bir ajan yalnızca fonksiyonlarının izin verdiğini yapabilir. Fonksiyon listesi ajanın görev tanımıdır ve istemeniz gereken ilk belgedir.

Ajanın veriyi okuması ya da değiştirmesi neden fark eder?

Çünkü okumak hiçbir şeyi değiştirmez. Ajan bir müşterinin son beş ödemesini çeker ve birini yanlış getirirse, sonuç yanlış bir taslaktır ve bunu bir kişi yakalayabilir.

Yazma, modelin dışında bir şeyi değiştirir: bir iade ödenir ya da bir e-posta müşteriye ulaşır. Bu değişikliklerin bazıları geri alınamaz.

OpenAI'ın ajan geliştirme rehberi, her fonksiyonu “salt okuma ya da yazma erişimi, geri alınabilirlik, gereken hesap izinleri ve finansal etki gibi etkenlere göre” düşük, orta ya da yüksek riskli olarak derecelendirmeyi öneriyor. Okuma, ancak ajan okuduğunu hiçbir yere gönderemediği sürece düşük riskli kalır. Bir e-postaya ya da belgeye talimat yerleştiren bir hile olan prompt injection'la ilgili bölüm bunun nedenini gösteriyor.

Ajan hangi eylemleri tek başına yapabilir, hangileri bir kişiyi gerektirir?

Her fonksiyonu üç gruptan birine ayırın:

• Ajan tek başına: veri okuma, belgelerde arama, etiketleme ve biri kullanana kadar sistemlerinizin içinde kalan taslaklar yazma
• Ajan önerir, bir kişi onaylar: para hareket ettiren, bir müşterinin kaydını ya da statüsünü değiştiren veya şirket dışına mesaj gönderen her şey
• Asla: erişim haklarında, limitlerde ya da banka bilgilerinde değişiklikler ve düzenleyicinizin adı belirlenmiş bir kişinin vermesini beklediği kararlar

Çoğu fonksiyonun hangi grupta olacağını dört soru belirler:

• Eylem geri alınabilir mi, alınabilirse kim tarafından?
• Para hareket ettiriyor mu ya da bir müşterinin borcunu değiştiriyor mu?
• Sonucu bir müşteri, bir iş ortağı ya da bir düzenleyici görecek mi?
• Bir kanun, bir lisans koşulu ya da kendi politikanız kararı bir kişinin vermesi gerektiğini söylüyor mu?

OpenAI'ın rehberi ortadaki grup için aynı tavsiyeyi veriyor: “Hassas, geri alınamaz ya da yüksek risk taşıyan eylemler, ajanın güvenilirliğine duyulan güven artana kadar insan gözetimini tetiklemelidir.” Rehberin örnekleri arasında “kullanıcı siparişlerini iptal etmek, büyük iadeleri onaylamak ya da ödeme yapmak” var.

OWASP güvenlik projesinin yayımladığı bir risk listesi olan OWASP Top 10 for LLM Applications 2025'te aşırı yetki (excessive agency) adlı bir madde var. Madde, bir ajanın görevinin gerektirdiğinden fazla fonksiyona, hakka ya da serbestliğe sahip olduğunda verebileceği zararı ele alıyor. Saydığı kontrollerden biri, “yüksek etkili eylemler gerçekleştirilmeden önce bunların bir insan tarafından onaylanmasını şart koşmak”.

Destek, müşteri kabulü, ödemeler ve raporlamada bu nasıl görünür?

Her alanda ajan okur ve taslak hazırlar, kararlar ise bir kişide kalır. Sizin listeniz sistemlerinize ve düzenleyicinizin beklentilerine bağlıdır.

• Destek: ajan destek taleplerini etiketler ve yanıt taslakları hazırlar. Başlangıçta her yanıtı bir kişi onaylar; iadeler ve ücret muafiyetleri ise her zaman onay gerektirir. Ajan bir müşterinin e-posta adresini ya da telefon numarasını asla değiştirmez, çünkü bunları kontrol eden kişi müşterinin giriş bilgilerini sıfırlayabilir
• Müşteri kabulü (onboarding): ajan belgelerde eksik alan olup olmadığını kontrol eder ve belgeleri analist için özetler. Risk derecesindeki bir değişiklik onay bekler, bir müşteriyi kabul etme kararı ise bir kişide kalır
• Ödemeler: ajan banka ekstresi satırlarını faturalarla eşleştirir ve eksikleri işaretler. Bekletilen bir ödemenin serbest bırakılması onay bekler; alıcının banka bilgilerini değiştirmek ise hiçbir zaman ajanın işi değildir
• Raporlama: ajan aylık raporun taslağını her rakamın kaynağıyla birlikte hazırlar. Bir müşteriye, yönetim kuruluna ya da bir düzenleyiciye gönderilen her şeyi bir kişi onaylar

Onay adımı nerede yer almalı?

Onayı yalnızca prompt'a, yani modelin aldığı talimatlara değil, fonksiyonu çalıştıran yazılıma koyun. Bir model prompt'undaki bir satırı görmezden gelebilir ya da ikna edilerek ondan vazgeçirilebilir. Onaylayan kişi tıklamadıkça çalışmayan bir iade fonksiyonu ise hiçbir sözle ikna edilemez.

OWASP'ın rehberi de aynı görüşte: “Bir eylemin izinli olup olmadığına karar vermesi için bir LLM'e güvenmek yerine, yetkilendirmeyi alt akıştaki (downstream) sistemlerde uygulayın.”

Kullanışlı bir onay ekranı, onaylayan kişiye şunları gösterir:

• Eylem, eylemin değiştirdiği kayıt ve tutar
• Kaydın değişiklikten önceki ve sonraki hâli
• Ajanın kullandığı kanıt, örneğin destek talebi ya da ekstre satırı
• Onaylayan kişi her reddettiğinde yazması zorunlu bir gerekçe

Her öneri saniyeler içinde onaylanıyorsa, insanlar kontrol etmeyi bırakmıştır. AB Yapay Zekâ Yasası'nda bunun bir adı var: otomasyon yanlılığı. Yasa'nın insan gözetimine ilişkin maddesi, yüksek riskli bir sistemi gözeten kişilerin “çıktıya otomatik olarak güvenme ya da aşırı güvenme yönündeki olası eğilimin” farkında kalabilmesi gerektiğini söyler. Onaylanmış eylemlerden bir örneklemi her hafta yeniden kontrol edin.

Ajanın hesabının hangi hakları olmalı?

Ajanın hesabı listesindeki fonksiyonlara izin vermeli, başka hiçbir şeye vermemelidir. Her ajana dokunduğu her sistemde kendi hesabını verin; asla bir yönetici hesabı ya da bir çalışanın giriş bilgilerini vermeyin. Bu hakları modelin değiştiremeyeceği yerde, yani sistemin kendisinde tanımlayın. Parolalar ve anahtarlar modelin göremeyeceği şekilde yazılımınızda kalır.

OWASP'ın örneği, ürün öneren ve “yalnızca bir ‘ürünler’ tablosuna okuma erişimine ihtiyaç duyabilecek” bir ajandır. OWASP ayrıca bir sunucuda herhangi bir komutu çalıştırmak gibi sınırı belirsiz fonksiyonlara karşı uyarıyor ve her biri tek bir iş yapan dar fonksiyonları tercih ediyor.

Ajan tek bir çalışan için çalıştığında, OWASP'ın ifadesiyle “o belirli kullanıcının bağlamında ve gereken asgari yetkilerle” hareket etmelidir. Böylece o kişiden fazlasını göremez ve yapamaz.

Prompt injection nedir ve ajanlar için neden daha önemlidir?

Prompt injection, ajanın okuduğu bir metne, örneğin bir e-postaya, bir destek talebine ya da yüklenen bir belgeye talimat yerleştirmek demektir. Model bu talimatları sizden geliyormuş gibi uygulayabilir. Talimatlar bir insan okuyucudan gizlenebilir ve bir ajan söz konusu olduğunda eylemlere dönüşebilir. OWASP, 2025 listesinde prompt injection'ı ilk sıraya koyuyor ve “prompt injection'ı önlemenin kesin yöntemleri olup olmadığının belirsiz olduğunu” söylüyor.

OWASP'ın aşırı yetki maddesi, gelen e-postaları özetlemek için bir posta kutusunu okuyan bir asistanı anlatıyor. Asistanın kullandığı eklenti e-posta da gönderebiliyor. Özel olarak hazırlanmış bir e-posta, asistanı kandırarak gelen kutusunda hassas bilgileri aramasını ve bunları saldırgana iletmesini sağlıyor.

OWASP'ın çözümleri, yalnızca e-posta okuyabilen bir fonksiyonla ve posta kutusuna salt okuma erişimiyle başlıyor. Ayrıca bir kişinin “LLM eklentisinin hazırladığı her e-postayı elle incelemesi ve ‘gönder’ düğmesine basması” gerekiyor. Prompt injection ihtimali dışlanamayacağı için kandırılmış bir ajanı hesaba katarak plan yapın ve verebileceği zararı küçük tutun.

Neleri loglara kaydetmeliyiz ve bir hatayı nasıl geri alırız?

Her fonksiyon çağrısını loglara kaydedin. Her kayıtta şunlar görünür: ajan, fonksiyon ve girdileri, sonuç, çağrıya yol açan metin, model ve prompt sürümü ve çağrıyı kimin, ne zaman onayladığı. Geliştirme ekibinin dışından biri logları okuyup belirli bir müşteriye ne olduğunu anlayabilmelidir.

OWASP, loglama ve hız sınırlarının aşırı yetkiyi önlemeyeceğini, “ancak verilen zararın düzeyini sınırlayabileceğini” not ediyor. Hız sınırı, ajanın belirli bir sürede aynı türden kaç eylem yapabileceğine bir üst sınır koyar; böylece art arda gelen hatalı eylemler erken durur.

Lansmandan önce, veri değiştiren her fonksiyonun nasıl geri alındığını ve bunu kimin yaptığını yazın. Kuyrukta bekleyen bir iade gibi, beklemede bir kayıt oluşturan fonksiyonları tercih edin. Beklemedeki bir kayıt silinebilir, gönderilmiş bir ödemeyi geri almak ise zordur. Ajanın fonksiyonlarını bir yazılım sürümü çıkarmadan anında kapatan bir düğme bulundurun ve bunu canlıya geçmeden önce test edin.

Kanun bir kişinin onaylaması gerektiğini söylüyor mu?

AB'de Yapay Zekâ Yasası, yüksek riskli olarak sınıflandırdığı yapay zekâ sistemlerinin insan gözetimine ilişkin kurallar koyar. Bu kurallar Madde 14'te yer alır, yüksek riskli kullanımları ise Ek III listeler. Listede gerçek kişilerin kredi değerliliğinin değerlendirilmesi ya da kredi puanlarının belirlenmesi yer alır; ancak finansal dolandırıcılığı tespit eden sistemler bunun dışındadır. Listede ayrıca hayat ve sağlık sigortasında gerçek kişiler için risk değerlendirmesi ve fiyatlandırma da yer alır. Avrupa Komisyonu'nun AI Act Service Desk'i, Ek III'teki yüksek riskli sistemlere ilişkin kuralların uygulanmaya başlayacağı tarih olarak 2 Aralık 2027'yi veriyor. Bu tarih, Digital Omnibus on AI ile yapılan değişiklikleri yansıtıyor. Bu tür tarihler değişebilir; bu yüzden plan yapmadan önce güncel takvimi kontrol edin.

Madde 14, gözetim önlemlerinin sistemin “riskleri, özerklik düzeyi ve kullanım bağlamıyla orantılı olması” gerektiğini söyler. Sistemi gözeten kişiler, “herhangi bir durumda, yüksek riskli yapay zekâ sistemini kullanmamaya ya da çıktısını başka bir şekilde göz ardı etmeye, geçersiz kılmaya veya tersine çevirmeye karar” verebilmelidir. Sistemi “bir ‘durdur’ düğmesi ya da benzer bir prosedürle” durdurabilmeleri de gerekir.

Bu kurallar yalnızca Yasa'nın listelediği yüksek riskli sistemlere uygulanır ve destek ile operasyon alanındaki birçok ajan bunların arasında olmayacaktır. Yine de aynı kontroller bu ajanlar için de mantıklıdır. Sisteminizin bu kuralların kapsamına girip girmediği avukatlarınızın yanıtlayacağı bir sorudur. Bu yazı hukuki tavsiye değildir ve yalnızca AB kurallarını ele alır.

Kontrolü kaybetmeden nasıl başlarız?

İşe, görevin bir ajana gerçekten ihtiyaç duyup duymadığını sorarak başlayın. Anthropic'in mühendislik yazısı “mümkün olan en basit çözümü bulmayı ve karmaşıklığı yalnızca gerektiğinde artırmayı” öneriyor ve ekliyor: “Bu, ajan tabanlı sistemleri hiç kurmamak anlamına da gelebilir.” Birçok görev için modele tek bir istek ya da sabit bir adım dizisi işi görür. Sabit bir dizi, kendi adımlarını seçen bir ajana göre daha öngörülebilir de davranır.

Haftada çok sayıda vakası olan, kuralları net ve hataları ucuza düzeltilebilen tek bir iş akışı seçin; örneğin destek taleplerini sınıflandırmak ve yanıt taslakları hazırlamak. Ardından aşama aşama ilerleyin:

• İş akışını bugün işlediği hâliyle ölçün: vaka başına süre, yeniden yapılan vakaların oranı ve haftalık birikmiş iş
• Ajanı gerçek vakalarda gölge modda çalıştırın. Ajan önerir, insanlar eskisi gibi çalışır ve siz ikisini karşılaştırırsınız
• Her eylemi bir kişinin onayladığı onay moduna geçin ve onaylayanların ne sıklıkla düzenleme yaptığını ya da reddettiğini kaydedin
• Ajanın yalnızca en az düzeltme gerektiren eylem türlerinde tek başına hareket etmesine izin verin ve haftalık bir örneklemi kontrol etmeyi sürdürün

Ajanı bir sonraki aşamaya hangi rakamların taşıyacağını ve buna kimin karar vereceğini önceden kararlaştırın. OpenAI'ın rehberi şu sözlerle bitiyor: “Küçük başlayın, gerçek kullanıcılarla doğrulayın ve yetenekleri zamanla artırın.” Anthropic'in yazısı “korumalı ortamlarda (sandbox) kapsamlı testler” öneriyor; bu, sistemlerinizin hataların hiçbir bedeli olmadığı bir kopyası demektir.

Ajan canlıya geçmeden önce neleri kontrol etmeliyiz?

• Her fonksiyon üç gruptan birindedir ve sizin tarafınızda adı belirlenmiş bir sorumlusu vardır
• Biri her sistemde ajanın hesabıyla yasak bir eylemi denedi ve bunun başarısız olduğunu gördü
• İçine talimat yerleştirilmiş destek talepleri ve belgeler ajandan geçirildi ve grupların izin verdiğinin dışında hiçbir şey olmadı
• Herhangi bir müşteri için loglar, ajanın ne yaptığını ve bunu kimin onayladığını gösterir
• Yeni bir model sürümü ancak aynı testler yeniden çalıştırıldıktan sonra canlıya geçer

Kodun, prompt'ların ve logların sahibi kim?

Sahibi şirketiniz olmalı ve sözleşme de bunu söylemeli. Kod, ajanın yalnızca bir parçasıdır. Ajanın nasıl davranacağını prompt'lar, fonksiyon listesi, onay kuralları ve test senaryoları belirler. Hepsini, şirketinizin kontrol ettiği depolama alanında tutulan teslimatlar olarak sözleşmede sayın.

Loglar müşteri verisi içerir; bu yüzden anlattıkları kayıtlarla aynı erişim kurallarına ve saklama süresine tabi olmalıdır. Model dışarıdaki bir sağlayıcıda çalışıyorsa, bu sağlayıcının ajanın gönderdiklerini saklayıp saklamadığını ve ne kadar süreyle sakladığını sorun.

Bunu geliştirecek bir firmaya neler sormalıyız?

• Ajanın çağıracağı her fonksiyonu, her birinin hangi grupta olduğuyla birlikte görebilir miyiz?
• Onaylar nerede uygulanıyor: bizim sistemlerimizde mi, sizin kodunuzda mı, yoksa yalnızca prompt'ta mı?
• Ajan her sistemde hangi hesabı kullanıyor ve bundan fazlasını yapamadığını nasıl test ettiniz?
• Prompt injection'a karşı nasıl test yapıyorsunuz ve bir test başarılı olduğunda ne oluyor?
• Uyum ekibimiz logları sizin yardımınız olmadan okuyabilir mi?
• Her eylem nasıl geri alınıyor ve ajanı ne kadar hızlı kapatabiliriz?
• Sonunda neyin sahibi oluyoruz: kod, prompt'lar, fonksiyon tanımları, test senaryoları ve loglar?

amBrain nerede devreye girer?

amBrain kendi ürününde ajanlar kullanıyor. Bu ürünle ilgili satırı şöyle: “Kendi ürünümüz shyash.ai, şirket bilgilerinin tek bir ortak belleğinden araştıran, yazan, kontrol eden ve ölçen yapay zekâ ajanları üzerinde çalışır. Yayınlanan her şeyi bir kişi onaylar.”

amBrain'in kamuya açık olarak anlattığı, dil modeli kullanılan tek müşteri projesi şu: “Bir müşterinin FinTech perimetresi içinde bir LLM entegrasyonunu üretime aldık: yapılandırılmamış broker ve işlem yeri bildirimlerinin — kurumsal işlemler (corporate actions), enstrüman ve teminat değişiklikleri — çıkarılıp normalize edilerek trading sisteminin tükettiği yapılandırılmış kayıtlara dönüştürülmesi.”

Bu yazı bir vaka çalışması değildir ve yukarıdaki satırın ötesinde hiçbir müşteri çalışmasını anlatmaz. O satır ajanlar ya da onaylar hakkında hiçbir şey söylemez ve yazı amBrain'in müşteriler için ajan sistemleri geliştirdiğini söylemez. Destek, müşteri kabulü, ödemeler ve raporlama örnekleri geneldir, amBrain'in çalışmalarından alınmamıştır.

Burada adı geçen şirketler ve kuruluşlar yayımlanmış sayfalarından alıntılanmıştır. Yazı, amBrain ile bunların herhangi biri arasında bir ilişki iddia etmez ve amBrain'e ait fiyat ya da takvim vermez.

amBrain 2019'dan bu yana yazılım geliştiriyor. Üç formatta çalışıyor: tam teslim, özel ekip ya da sizin ekibinize yerleşen mühendisler. Mülkiyet konusundaki satırı ise şöyle: “Müşteri, yeniden kullanılabilir bileşenlerimiz dışında ürünün ve kodun tam mülkiyetini elinde tutar.” Yukarıdaki sorular, değerlendirdiğiniz her firma için geçerlidir.