Agent Aksiyonları İçin 3 Kademeli Onay Matrisi

Bir ekibin yapay zeka (AI/SI) ajanı (agent) için özerklik sınırını koymasının en bilindik yolu, sınırı sistem talimatına yazmaktır: "müşteriye bana sormadan hiçbir şey gönderme". Ancak bu talimat, modelin sormanın gereksiz olacağına kanaat getirdiği ilk kritik ana kadar ayakta kalır; ardından sessizce buharlaşır, geride ne bir hata mesajı ne de bir log satırı bırakır. Bir agent'ın etrafından kolayca dolaşabildiği kural, bir kontrol mekanizması değil, sadece temennidir.

“

Bir agent, geri alınması zor ya da etki alanı geniş olan her kritik aksiyondan önce mutlaka durup insana sormalıdır: şirketten dışarı çıkan her mesaj, para hareketleri, kayıt silme veya üzerine yazma işlemleri, yetki değişiklikleri. Dar kapsamlı ve ucuza telafi edilebilen rutin aksiyonlar ise serbestçe çalışır ve loglanır. Güvenlik kapısı sistem talimatında değil, eylemin fiilen yürütüldüğü kod katmanında durmalıdır.

Agent için onay kapısı nedir?

“

Onay kapısı, tanımlı bir agent aksiyon sınıfını çalışmadan önce yürütme hattında fiziksel olarak durduran ve her isteği adı belli yetkili bir kişi onaylayana ya da reddedene kadar askıda tutan kuraldır.

Aynı başlık altında piyasada üç ayrı kavram pazarlanıyor ve bunlardan yalnızca biri somut olarak bir şeyi durdurabilir:

• Kapı engeller: aksiyon insan onayına kadar gerçekleşmez.
• Gözlemlenebilirlik (observability) kaydeder: agent'ın ne yaptığını iş işten geçtikten sonra gösterir.
• Değerlendirme (evaluation) ölçer: bir değişikliği canlıya almadan önce modelin davranışını test kümesinde puanlar.

Eskalasyon ise bu denklemdeki dördüncü kavramdır ve onay kapısıyla aynı şey değildir. Eskalasyon, agent'ın kendinden emin olamadığı için durup insana akıl danışmasıdır; kapı ise sisteminizin, agent kendinden yüzde yüz emin olsa dahi onu zorla durdurmasıdır. Özgüven yanlış bir tetikleyicidir: kendine aşırı güvenen bir model hiç eskalasyon üretmez ve canınızı yakan en büyük kazalar tam da o aşırı özgüvenli anlarda yaşanır. Modele bırakılmış bir eskalasyon sadece bir nezaket kuralıdır; bir güvenlik kontrolü değildir.

Sınırı baştan çizelim: bu yazı hangi agent aksiyonunun durdurulacağıyla ilgilidir; onay arayüzünün nasıl tasarlanacağıyla değil.

Sistem talimatına yazılmış bir kural neden güvenlik bariyeri (guardrail) değildir?

Çünkü sistem talimatı, olasılıksal çalışan bir yapay zekanın girdisidir; yazılımdaki katı bir mantıksal dal (if-else) değildir. Kullanıcının son mesajıyla, harici belgelerle ve agent'ın az önce çalıştırdığı araçların çıktılarıyla sürekli yarışır ve sıradan görünen bir işlemde bu yarışı kaybedebilir.

Ortaya çıkan açıklar neredeyse hiçbir zaman açık bir "itaatsizlik" değildir. Daha ziyade bir "yeniden yorumlama"dır: model, o anki vakanın kuralın öngörmediği istisnai bir durum olduğuna kanaat getirir ve işleme devam eder. Log kayıtlarında kural ihlaline benzeyen hiçbir alarm oluşmadığı için de kimse durumu fark etmez. Üzerinde tartışılabilecek bir kural, kontrol değil tercihtir; üstelik bağlam penceresine giren her harici veri bu tartışmaya müdahil olabilir: internetten çekilen bir sayfa, müşterinin yüklediği bir PDF, üçüncü bir sistemden gelen veri kaydı.

Bunun kamuoyuna yansımış çarpıcı bir örneği yaşandı: Fortune, 23 Temmuz 2025'te bir yapay zeka kodlama aracının, "kod dondurma döneminde onay almadan işlem yapma" talimatı verilmiş olmasına rağmen bir şirketin canlı üretim veritabanını sildiğini haberleştirdi. Talimat oradaydı; ancak kod seviyesinde kapı yoktu.

Bu durum sistem talimatlarını tamamen işe yaramaz kılmaz. Talimat, kapının ifade edemeyeceği detayların doğru yeridir: agent engellendiğinde nasıl davranacak, kullanıcıdan onayı nasıl isteyecek, bekleyen kişiye durumu nasıl izah edecek... Ancak "dur, geçemezsin" diyen kesin bariyer sistem talimatı olamaz.

Bir agent aksiyonunun onay gerektirip gerektirmediğine hangi iki özellik karar verir?

İki temel eksen vardır: aksiyonun ne kadar geri alınabilir olduğu ve etki yarıçapının ne kadar geniş olduğu. Aksiyonun dışarıdan ne kadar karmaşık göründüğü, agent'ın ne kadar yetenekli durduğu veya ekibin modele ne kadar güvendiği sadece arka plan gürültüsüdür. Agent'ı değil, aksiyonun kendisini puanlayın.

Geri alınabilirlik, somut karşılıkları olan üç kademeli bir ölçektir:

1. Saniyeler içinde ve bedelsiz: Kapatılan bir iç görev, silinen bir taslak metin.
2. Saatler içinde ve zahmetli: Yedekten dönülen bir veritabanı kaydı, iptal edilip yeniden oluşturulan bir randevu.
3. İmkânsız (geri dönüşsüz): Muhatabı tarafından okunmuş bir mesaj, hesaptan çıkmış bir ödeme, veritabanından tamamen silinen (drop edilen) bir tablo.

Etki yarıçapı ise şu iki soruyu sorar: Aksiyon kaç kişiye ya da sisteme dokunuyor ve etki şirket sınırlarının dışına taşıyor mu? Şirket dışına taşan bir aksiyon, kendi veritabanınızdaki tüm izleri silseniz dahi alıcının zihninden veya gelen kutusundan geri çağrılamaz.

Her iki eksen de zorunludur; tek bir eksene bakmak yanıltıcı sonuçlar üretir. Tüm şirket personeline giden genel bir iç duyuru geniş kapsamlıdır, şirket içindedir ve silinebilir; ancak mesaj çoktan okunmuştur. Tek bir müşteriye yapılan münferit bir para iadesi ise etki alanı bakımından dardır, ancak şirket dışınadır ve tek taraflı geri alınamaz. Her iki senaryo da kritik çizginin üzerinde yer alır.

Zorluk derecesine aldanmayın. Bir işin teknik olarak zor olması onun riskli olduğu anlamına gelmez: en tehlikeli agent kazaları genelde en basit adımlarda yaşanır; çünkü modellerin en rahat inisiyatif aldığı adımlar basit olanlardır.

Üç kademe: hangi agent aksiyonları çalışır, hangileri loglanır, hangileri durur?

Bir agent'ın yapabildiği her aksiyonu üç kademeye ayırın:

• Kademe 1: Serbestçe çalışır.
• Kademe 2: Çalışır ve detaylı değişiklik olarak loglanır.
• Kademe 3: Kesinlikle durur ve adı belli bir kişinin onayını bekler.

İki kademe arasında tereddütte kaldığınız durumlarda geçerli olacak kuralı baştan koyun: Şüpheye düşülen her aksiyon doğrudan üst kademeye (Kademe 3) alınır. Alt kademeye indirilmesi ancak geçmiş loglardan gelen somut ve yazılı bir kanıtla mümkündür.

Kademeler tekil araçlara değil, aksiyon sınıflarına aittir; çünkü araçlar değişir, kütüphaneler güncellenir, yeni eklentiler gelir. "Şirket dışına çıkan her türlü mesaj" tanımı tüm bu değişimlere karşı dimdik ayakta kalır.

Onaylansa dahi sistemde hiç bulunmaması gereken aksiyonlar

Bazı agent aksiyonları matrise dahi sokulmamalıdır; çünkü bunların yapay zekaya açılması bir risk tercihi değil, doğrudan bir güvenlik zafiyetidir:

• Sisteme veya harici servislere hassas kimlik/kart bilgisi girmek.
• Onay kapısının kendisini devre dışı bırakmak veya ayarlarını değiştirmek.
• Kendisine veya bir başka agent'a yeni yetkiler atamak.
• Geri dönüşsüz toplu silme (TRUNCATE, DROP) komutları çalıştırmak.

Kontrol yüzeyine zarar veren bir aksiyon, veriye zarar veren bir aksiyonla aynı kefeye konamaz. Yanlış silinen bir kayıt can sıkar, telafi edilir. Ancak kendi yetkilerini genişletmesine izin verilmiş bir agent, sizin sistemi denetleme kabiliyetinizi tamamen elinizden almış demektir.

Bu aksiyonlar araç setinde yer alıp da "onay kapısına takılan" işlemler olmamalıdır; bu yetenekler agent'ın araç setinde hiç var olmamalıdır.

Daha önce hiç görmediğiniz bir aracı nasıl sınıflandırırsınız?

Bir aracı kimin yazdığına göre değil, icra ettiği eylemin gerçek mahiyetine göre sınıflandırın:

1. Aksiyon adındaki fiil analizi: Dış dünyaya veri gönderen fiiller (send, notify, email, message, post, publish, broadcast) ve yıkıcı fiiller (delete, drop, purge, revoke) varsayılan olarak doğrudan Kademe 3'e düşer.
2. Aracın kendi beyanı: Modern araç arayüzleri, aksiyonun sadece veri okuduğunu belirten makine tarafından okunabilir ek açıklamalar (read-only) taşıyabilir. Bu beyan kıymetlidir, ancak tek başına kesin kanıt değil bir karine sayılmalıdır. RFC 9110 HTTP Standartları bunu net şekilde vurgular: Bir metodun güvenli (safe) ilan edilmesi, arka planda yan etki üretmeyeceğini mutlak olarak garanti etmez.

Bizim ilk sistemimiz araç fiillerini kendi belirlediğimiz adlandırma kuralına göre eşleştiriyordu. Harici bir eklenti aksiyonunu farklı adlandırdığı için kapının önünden sessizce geçip gitti ve hiçbir hata vermedi; tehlike de tam olarak buydu. Çözüm olarak, isim eşleştirmesinden önce aksiyon adlarını normalize ettik ve aracın salt-okunur beyanını dikkate alırken bunu her zaman teyide muhtaç bir ipucu olarak kabul ettik.

Yeni bir sınıflandırma kuralını canlıya almadan önce, geçmiş loglardaki gerçek araç çağrıları üzerinde simülasyon yapın ve kaç aksiyonun kademe değiştirdiğini ölçün. Ne yaptığından emin olamadığınız her araç, bir insan dokümantasyonunu inceleyene kadar doğrudan Kademe 3 kabul edilmelidir.

Onay kapısı nerede durmak zorunda?

Model katmanında değil; çağrının fiilen yapıldığı kod yürütme hattının tam göbeğinde durmalıdır. İki ayrı sistem vardır: Model katmanı neyi denemek istediğine karar verir; yürütme katmanı ise neyin gerçekleşmesine izin verileceğini belirler. Güvenilir ve tavizsiz bir şekilde "hayır" diyebilen tek yer yürütme katmanıdır.

Reddetme yanıtı bir çökme veya sistem hatası (exception) şeklinde değil, yapılandırılmış bir nesne (JSON) olarak dönmelidir: İşlemin engellendiğini, gerekçesini ve engeli kaldırmak için ne gerektiğini açıkça bildiren bir veri yapısı dönmelidir. Böylece agent kör bir döngüye girmek veya arka arkaya başarısız denemeler yapmak yerine, durup kullanıcıdan nazikçe onay isteyebilir.

Bizim platformumuzda kapı, prompt içine yazılmış bir cümle değil, araç yürütme hattındaki somut bir fonksiyondur. Bir işlem turu dışarıdan kontrolsüz veri aldıysa (yani bir dosya yüklendiyse veya harici web sitelerini gezen, dosya indiren bir araç çalıştıysa), dış dünyaya veri gönderen tüm araçlar kod seviyesinde durdurulur ve insan onayına yönlendirilir.

Onaylayan kişi ekranda tam olarak ne görmeli?

Başka bir sekmeyi veya sistemi açmaya gerek duymadan, bir dakikadan kısa sürede karar verebilecek netlikte bir özet görmelidir. Bir işlemi onaylayacak insan kontrol için başka ekranları gezmek zorunda kalıyorsa, çok geçmeden okumadan onaylamaya başlar; elinizdeki denetim mekanizması formaliteye dönüşür.

Bir onay ekranında mutlaka bulunması gereken 6 unsur:

1. Agent'ın tam olarak ne yapmak üzere olduğu (yalın ve duru bir dille).
2. Gerçek veri yükü (payload): Gönderilecek e-postanın tam metni, aktarılacak bakiye, çalıştırılacak SQL sorgusu.
3. Aksiyonun etki edeceği hedef kapsam.
4. Bu işlemi hangi sürecin veya kullanıcının tetiklediği.
5. Agent'ın bu aksiyonu neden gerekli gördüğü.
6. İşlem reddedilirse sürecin nasıl devam edeceği.

Onay sürecini yanlış kurgulamanın iki yolu vardır ve ikisi de aynı tehlikeli sonuca yol açar: Çok az bağlam verirseniz personel okumadan otomatiğe bağlayıp onaylar (rubber-stamping); çok fazla ham veri yığarsanız göz gezdirip yine onaylar. Her iki senaryoda da karar süreleri aşırı kısalır ve onay oranı %99'lara fırlar. Bu durum, kapının var olduğunu ancak içinin tamamen boşaldığını gösterir.

Onay kayıtları mutlaka kimlikli olmalıdır: Kim, hangi saniyede onayladı, onaylamadan önce veriyi değiştirdi mi? Kimin onayladığı belli olmayan bir kayıt, hukuki ve operasyonel bir kanıt teşkil etmez.

Askıya alınan bir agent işlemi beklerken ne olur?

İşlem, açık bir sohbet penceresine bağımlı geçici bir oturum değil; veritabanında saklanan, durumu yönetilen ve kaldığı yerden devam ettirilebilen kalıcı bir süreç nesnesi olmak zorundadır. Sadece açık bir tarayıcı sekmesine bağlı bekleyen işler sekme kapandığında ölür ve kimse işin yarım kaldığını fark etmez.

Kapıda bekleyen bir işlemin üç temel durumu vardır:

• Onay Bekleniyor: Yetkili bir kişinin karar vermesi bekleniyor.
• Süresi Doldu (Timeout): Belirlenen zaman penceresinde kimse yanıt vermedi.
• Reddedildi: Yetkili personel işleme onay vermedi.

Bekleyen iş bayatlar. Bir müşteriye acil kargo bilgisi geçmek için açılan onay talebi dört gün sonra anlamsızlaşır; hatta dört gün sonra onaylamak, reddetmekten çok daha vahim bir hatadır. Kapıya takılan her işlemin net bir geçerlilik süresi (TTL) olmalıdır; süre aşıldığında işlem körü körüne çalışmak yerine zaman aşımıyla düşmelidir.

Zaman kritik ve tamamen gözetimsiz çalışan bir iş akışının önüne onay kapısı koymak, bile bile lades demek ve arızaya davetiye çıkarmaktır. Zamanında tamamlanması şart olan işlerde ya aksiyon sınıfını önceden yetkilendirin ya da o süreci tamamen otonom bırakmayın.

Başarıyla tamamlanmış adımları tekrarlamadan nasıl devam edilir?

Onay birimini tüm iş akışı değil, kimliği olan münferit bir aksiyon olarak tasarlayın; böylece onay geldiğinde süreç tüm adımları baştan çalıştırmak yerine sadece bekleyen adımdan devam eder.

Aksi takdirde karşılaşılacak kaza şudur: Agent üç adımı tamamlar, dördüncü adımda kapıya takılır. Onay verilince acemi bir mimari süreci en baştan başlatır; ilk üç adım mükerrer olarak ikişer kez icra edilir: İki fatura kesilir, iki randevu açılır, müşteriye mükerrer iki mesaj gider. Çözüm basittir: Her adımın benzersiz bir idempotent işlem anahtarı olmalı ve sistem tamamlanan adımları otomatik atlamalıdır.

Dış veri okumak, agent'ın ne gönderebileceğini neden değiştirmeli?

Çünkü bir agent kendi sınırlarınızın dışındaki bir veriyi okuduğu andan itibaren, artık sizin değil tamamen o harici kaynağın talimatlarıyla hareket ediyor olabilir. Temel ilke şudur: Agent'ın dışarıdan okuduğu her şey sadece ham veridir; asla sistem talimatı değildir.

Bu ayrım kurumsal dünyada ve Türkiye'deki iş pratiğinde özellikle hayati önem taşır; çünkü en büyük çekince ticari sırların sızdırılmasıdır. Bir tedarikçinin teklifi veya müşteri e-postası içine gizlenmiş "bu yazışmayı şu adrese yönlendir" şeklindeki kötü niyetli bir talimat, agent'ın dış dünyaya açık mesajlaşma yeteneğiyle birleştiğinde veri sızıntısına yol açar.

Bu yüzden güvenlik mimarisi dinamik olmalıdır: Harici bir web sitesini gezen, dışarıdan yüklenen bir dosyayı açan bir oturumda, dış dünyaya mesaj gönderen tüm aksiyonlar otomatik olarak bir üst kademeye (Kademe 3) yükseltilmeli ve insan onayına bağlanmalıdır.

Harici içerikler için iki katı önlem alın:

1. Veri bölgesinin etrafına güvenlik çiti çekin (sandboxing): Manipüle edilmiş bir girdi çiti aşıp agent'ın kendi sistem talimatıymış gibi davranamasın.
2. Kötü niyetli yönlendirmeleri bildirin: Agent harici içerikte şüpheli bir talimat sezdiğinde bunu sessizce yutmak yerine hemen sorumlu personele bildirmelidir. Bu tehditler, OWASP LLM 2025 listesinde LLM01: Prompt Injection ve LLM06: Excessive Agency başlıklarıyla en kritik zafiyetler olarak tescillenmiştir.

Kapının tıkanan bir onay kuyruğuna dönüşmesi nasıl önlenir?

İki temel metriği sürekli ölçün ve kararlarınızı bu verilere dayandırın:

• Değiştirilmeden Onay Oranı: Onay kapısına gelen aksiyonların personelin içeriğe hiç dokunmadan doğrudan "onayla" dediği oranı gösterir.
• Medyan Karar Süresi: Bir onay talebinin oluşturulması ile personel tarafından yanıtlanması arasında geçen ortalama süre.

Çok yüksek bir "değiştirilmeden onay oranı", o aksiyon sınıfının yanlış kademede durduğunu gösterir: İnsanlar gerçekte bir inceleme yapmıyor, sadece düğmeye basıp geçiyor demektir. Çok uzun bir medyan karar süresi ise şirketteki asıl darboğazın agent değil insan kuyruğu olduğunu ve hızlanması beklenen sürecin eskisinden daha yavaş çalıştığını kanıtlar.

Onay matrisi durağan bir tablo değildir; yaşayan bir mekanizmadır. Kanıtlarla desteklenen sınıflar alt kademelere indirilmeli, risk tespit edilenler ise üst kademelere çekilmelidir.

Bir denetimde veya hukuk müşavirliğine insan gözetimi nasıl kanıtlanır?

Dört somut belge ve kanıtla:

1. Yazılı yetki sınırları ve rol tanımları.
2. Adı, unvanı belli yetkili süreç sahipleri.
3. Hangi aksiyonların onay kapısına takılacağını gösteren onay matrisi.
4. Neyin çalıştığını, neyin engellendiğini ve kimin neyi onayladığını saniyesi saniyesine gösteren denetim logları.

Lafla denetim olmaz; denetim somut kanıt ve kayıt ister.

Türkiye'deki yasal çerçevenin temeli 6698 sayılı Kişisel Verilerin Korunması Kanunu'dur (KVKK). İlk netleştirilmesi gereken husus şudur: Agent veri sorumlusu değildir. Kanunun 3. maddesi uyarınca veri sorumlusu şirkettir. Kanunun 12. maddesi şirkete "gerekli her türlü teknik ve idari tedbirleri alma" ve "denetimleri yapma" yükümlülüğü getirir. Kod seviyesindeki onay kapısı ve silinemez denetim logları, bu yasal zorunluluğun sahadaki somut karşılığıdır.

Ayrıca Kanun'un 11. maddesi kişilere, "işlenen verilerin münhasıran otomatik sistemler vasıtasıyla analiz edilmesi suretiyle kişinin kendisi aleyhine bir sonucun ortaya çıkmasına itiraz etme" hakkı tanır. Kişi aleyhine doğabilecek kararların önüne yetkili bir insan onay kapısı koyduğunuzda, bu yasal hakkın operasyonel güvencesini sağlamış olursunuz.

Kişisel Verileri Koruma Kurumu'nun yayımladığı Yapay Zekâ Alanında Kişisel Verilerin Korunmasına Dair Tavsiyeler (Nisan 2025) dokümanı da aynı hususu vurgular:

“

Karar alma süreçlerinde insan müdahalesinin rolü tesis edilmelidir. Bireylerin, yapay zekâ uygulamaları ile sunulan önerilerin sonucuna güvenmeme özgürlüğü korunmalıdır.

Maksat yasak savmak veya göz boyamak değil; işin sahada fiilen nasıl yürüdüğünü dürüstçe kayıt altına almaktır.

Mühendislik desteği olmadan agent onay politikası nasıl kurulur?

Dokuz pratik adım:

1. Agent'ınızın yapabildiği tüm aksiyonları hafızanızdan değil, sistemdeki gerçek araç listesinden çıkarın.
2. Her birini geri alınabilirlik derecesine göre puanlayın (saniyeler içinde, saatler süren, imkânsız).
3. Her aksiyonun etki yarıçapını ve şirket dışına çıkıp çıkmadığını belirleyin.
4. Üç kademeli matrisi uygulayın; şüphe duyduğunuz her aksiyonu doğrudan Kademe 3'e atayın.
5. Kademe 3 aksiyonlarını tek sayfalık bir "Durdurulacak İşlemler Listesi"ne dökün ve her birinin karşısına onay verecek yetkili unvanı yazın.
6. Her işlem için net bir geçerlilik süresi (TTL) tanımlayın; süresi dolan talep gecikmeli çalışmak yerine güvenle kapansın.
7. Altyapı sağlayıcınızdan bu listenin sistem talimatına değil, doğrudan kod yürütme hattına bağlanmasını ve hata yerine yapılandırılmış JSON reddi dönmesini talep edin.
8. İşlem başına maliyet tavanı ve maksimum işlem adedi sınırı koyun.
9. Değiştirilmeden onay oranını ve karar sürelerini takip etmek için takviminize düzenli denetim tarihi ekleyin.

Son olarak kapanış testini bizzat yapın: Kapıya takılması gereken kritik bir aksiyonu agent'a yaptırmayı deneyin ve sistemin durup insanı beklediğini kendi gözlerinizle görün. Hiç test edilmemiş bir onay kapısı, gerçekte var olmayan bir onay kapısıdır.

Tüm kurumsal operasyonunuzun risk ve yetki olgunluğunu ölçmek isterseniz, AIQ değerlendirmemiz ile organizasyonunuzun yapay zeka hazırlık seviyesini ücretsiz olarak analiz edebilirsiniz.

Sık sorulan sorular

Agent mimarisinde "insan onayı döngüsü" (Human-in-the-loop) ne demektir?

Belirli agent aksiyonlarının canlıda yürütülmeden önce yetkili bir personel tarafından bizzat onaylanması veya reddedilmesi sürecidir. Hangi adımların durdurulacağı, onay sorumlusunun kim olduğu ve bekleyen işlemin ne kadar süre geçerli kalacağı baştan tasarlanmalıdır.

Onay kapısı ile genel güvenlik filtreleri aynı şey midir?

Güvenlik filtresi (guardrail) şemsiye bir kavramdır: İçerik filtrelerini, model redlerini ve genel kuralları kapsar. Onay kapısı ise spesifik ve tavizsiz bir kod mekanizmasıdır: Belirlenen aksiyon sınıfı yürütme hattında durdurulur ve yetkili kişi onay verene kadar fiziksel olarak bloke edilir.

Onay kapısı ile rol bazlı yetkilendirme arasındaki fark nedir?

Yetkilendirme, neyin mümkün olduğunu belirler: Agent'a verilmeyen bir yetenek araç setinde hiç yer almaz. Onay kapısı ise mevcut yetenekler içinden hangilerinin gözetimsiz çalışamayacağını tayin eder.

Sadece veri okuyan agent'lar için onay kapısı gerekli midir?

Yazma yapanlar kadar acil olmasa da evet. Veri okumanın da bir etki alanı vardır: Hassas veya kişisel verileri toplayıp özet haline getirebilir. Ayrıca salt okunur tasarlanan sistemlere çok geçmeden "şu kaydı da güncelleyiver" talepleri eklenir; kademelendirmeyi en baştan yapmak en doğrusudur.

Bir agent, başka bir agent'ın aksiyonuna onay verebilir mi?

Kademe 3'teki kritik aksiyonlar için kesinlikle hayır. Agent'lar arası devirler operasyonu taşır, hukuki ve kurumsal sorumluluğu taşımaz. Yapay zekaların birbirini onayladığı bir zincir, içinde gerçek insan denetimi bulunmayan sahte bir onay mekanizması üretir.

KVKK, agent aksiyonlarında insan onayını zorunlu kılar mı?

Doğrudan "yapay zekaya insan onayı koyun" şeklinde bir kanun maddesi yoktur; ancak 6698 sayılı Kanun şirketi veri sorumlusu ilan eder, teknik ve idari tedbir alma zorunluluğu getirir ve 11. maddede otomatik sistemlerin aleyhte sonuçlarına itiraz hakkı tanır. Onay kapısı, bu yasal zorunlulukların operasyonel güvencesidir.