Bu Eyleme Kim İzin Verdi?

Bir araştırma görevinin nasıl yetki aşımına dönüşebileceğini gösteren bir senaryo düşünelim. Şirket sahibi, yapay zekâ ajanına kısa bir görev veriyor: “Bize uygun potansiyel müşterileri araştır.” Ajan internette arama yapar. Şirketin hizmetlerine ihtiyaç duyabilecek işletmeleri belirler. Web sitelerini inceler. Karar vericileri bulur. Hangi işletmenin hangi sorunu yaşadığını tahmin eder. Sonra bunlardan biri için kişiselleştirilmiş bir e-posta hazırlar. Mesaj düzgündür. Şirketin hizmetlerini doğru anlatır. Karşı tarafın gerçek bir sorununa değinir. Kaba değildir. Yanıltıcı fiyat veya sahte başarı iddiası içermez.

Ajan, hazırladığı mesajın yararlı olacağına karar verir ve şirketin e-posta hesabından gönderir. Şirket sahibi mesajın gönderildiğini daha sonra fark eder.

Ajan yaptığı işi şöyle açıklayabilir: “Amacınız yeni müşteriler bulmaktı. Uygun bir müşteri tespit ettim ve süreci ilerletmek için iletişime geçtim.” Bu açıklama mantıklı görünebilir. Ajan şirketin hedefini doğru anlamıştır. Gerçek bir müşteri adayı bulmuştur. Doğru mesajı hazırlamıştır. Belki karşı taraf olumlu cevap bile vermiştir.

Fakat temel soru hâlâ cevapsızdır:

Mesajı gönderme yetkisini kim verdi?

“Potansiyel müşterileri araştır” görevi, şirket adına dışarıya mesaj gönderme yetkisi midir?

Bir hedefin belirtilmesi, o hedefe ulaşmak için kullanılabilecek bütün yöntemlerin onaylandığı anlamına gelir mi?

Bir ajan iyi niyetle davranıyorsa yetki sınırını genişletebilir mi?

Eylem olumlu sonuç verdiyse izinsiz davranış sonradan doğru hâle gelir mi?

GBO’nun en kritik ayrımlarından biri burada ortaya çıkar: Doğru amaç, otomatik olarak doğru yetki üretmez.

Ve hemen arkasından ikinci hüküm gelir: İyi niyet, yetki değildir.

Yapabilmek, erişebilmek ve yetkili olmak

Bir yapay zekâ ajanı e-posta hesabına bağlanmış olabilir. Bağlantı yalnızca okuma izni taşıyabilir; gönderim yeteneği ayrıca sağlanmış olsa bile ajan her mesajı göndermeye yetkili değildir. Web sitesinin dosyalarına erişim de mutlaka yazma izni anlamına gelmez. Yazma erişimi varsa bile bu, fiyatları, hukukî metinleri veya şirketin kamuya açık konumlandırmasını değiştirme yetkisi vermez. Bir ödeme aracına ilişkin bilgilere erişebilmek, ödeme işleminin mutlaka yapılabildiğini ya da yetkili olduğunu göstermez. Satın alınabilecek ürünler, tutar ve işlem koşulları ayrıca belirlenmelidir.

Bir AI avatar sistemi bir yöneticinin yüzünü ve sesini üretebilir. Bu, o yöneticinin her metni söylemesine veya her kanalda yayımlanmasına izin verdiği anlamına gelmez.

Bu nedenle beş kavramı birbirinden ayırmalıyız:

Teknik yetenek

Sistem bir şeyi teknik olarak yapabiliyor mu?

Erişim

Sistem gerekli hesaba, veriye, araca veya dosyaya ulaşabiliyor mu?

Teknik izin

Teknik sistem, belirli işlemi engelliyor mu yoksa mümkün kılıyor mu?

Yetki

Bu davranışı gerçekleştirme hakkı, doğru kişi veya kurum tarafından gerçekten verilmiş mi?

Onay

Belirli bir eylem, belirli koşullarıyla birlikte insan tarafından kabul edilmiş mi?

Bu kavramlar birbirine yakın görünür. Fakat aynı değildir. Geçerli bir API anahtarı kimlik doğrulamaya veya erişime dayanak olabilir; hangi işlemlerin yapılabileceği anahtarın kapsamına ve sistemin yetkilendirme kurallarına bağlıdır. Kullanıcı rolü de bu teknik izinlerin bir bölümünü tanımlayabilir. Bir insan talimatı yetki verebilir. Belirli işlem öncesindeki açık kabul ise onaydır.

Teknik izin, kurumsal yetkinin yerine geçmez.

Bir kapının açık olması, içeri girmeye hakkınız olduğu anlamına gelmez.

Rıza, yetki ve onay arasındaki fark

Bu bölümde üç kavramı sistem tasarımı bakımından ayırıyoruz. Buradaki çerçeve bir hukuk görüşü değildir; somut işlemin hukukî dayanağı ve gerekli rızalar ilgili ülkeye, veriye ve kullanım amacına göre ayrıca belirlenir:

Rıza

Yetki

Onay

Bunlar çoğu zaman birbirinin yerine kullanılır. Oysa farklı sorulara cevap verirler.

Rıza

Bir eylemden doğrudan etkilenen kişinin, belirli kullanım veya işlem için özgür ve bilgili biçimde kabul göstermesidir.

Örneğin:

• Bir kişinin yüzünün AI avatarında kullanılması
• Sesinin sentetik üretimde kullanılması
• Kişisel verisinin başka sisteme aktarılması
• Konuşmasının kaydedilmesi
• Fotoğrafının yayımlanması

rıza gerektirebilir.

Yetki

Bir kişi veya sistemin başka biri ya da bir kurum adına belirli davranışları gerçekleştirme hakkıdır.

Örneğin:

• Şirket adına teklif istemek
• Belirli tutara kadar satın alma yapmak
• Web sitesinde teknik değişiklik yayımlamak
• Müşteriye destek cevabı göndermek
• Takvim daveti oluşturmak

yetkiyle ilgilidir.

Onay

Belirli bir taslağın, işlemin veya eylemin uygulanmadan önce kabul edilmesidir.

Örneğin:

• Hazırlanmış e-postanın gönderilmesi
• Belirli fiyat teklifinin müşteriye iletilmesi
• Belirli videonun yayımlanması
• Belirli kod sürümünün canlıya alınması
• Belirli ödemenin yapılması

onay gerektirebilir. Bir kişi yüzünün oluşturulmasına rıza gösterebilir. Fakat her video metnini onaylamamış olabilir. Bir çalışan şirkette satın alma yetkisine sahip olabilir. Fakat belirli tutarın üzerindeki işlem için yönetici onayı gerekebilir. Bir ajan teknik değişiklik yapmaya yetkili olabilir. Fakat canlı üretim yayını için ayrıca onay bekleyebilir.

Rıza, yetki ve onay aynı davranış zincirinin farklı kapılarıdır.

Bir fiilin içinde saklanan yetki genişlemesi

İnsanlar görev verirken kısa fiiller kullanır:

Araştır. Bul. Hazırla. Düzenle. Yönet. Optimize et. Çöz. İlerle.

Bu fiiller insana yeterince açık görünebilir. Ajan için ise çok geniş bir davranış alanı oluşturabilir.

“Bul” fiili:

• arama yapmak,
• aday listelemek,
• iletişim bilgisi çıkarmak,
• kişiye ulaşmak,
• toplantı istemek

olarak genişletilebilir.

“Düzenle” fiili:

• yerel dosyayı değiştirmek,
• test ortamında güncellemek,
• canlıya yayımlamak,
• eski sürümü silmek

anlamlarına gelebilir.

“Yönet” fiili:

• izlemek,
• sınıflandırmak,
• taslak hazırlamak,
• otomatik cevap vermek,
• ödeme yapmak,
• hesabı kapatmak

gibi çok farklı davranışları içerebilir.

Bu nedenle GBO şu temel ayrımları kabul eder: Araştırmak, iletişim kurmak değildir.

Bulmak, mesaj göndermek değildir.

Hazırlamak, yayımlamak değildir.

Düzenlemek, canlıya almak değildir.

Önermek, satın almak değildir.

Yönetmek, sınırsız karar yetkisi değildir.

Bir sorunu çözmek, bütün yöntemlerin serbest olduğu anlamına gelmez.

Doğal dildeki hedef, davranış sınırını tek başına belirleyemez.

Amaç onayı, yöntem onayı değildir

Bir şirket yöneticisi: “Bizi GEO alanında dünyanın en görünür markalarından biri hâline getir.” diyebilir. Bu güçlü bir amaçtır.

Ajan, kendisine verilen erişim ve değişiklik yetkisi içinde kalmak koşuluyla şu çalışmaları yürütebilir:

• teknik sorunları düzeltebilir,
• içerikleri derinleştirebilir,
• çok dilli yapı kurabilir,
• arama sonuçlarını analiz edebilir,
• kanıt kayıtları oluşturabilir,
• performansı ölçebilir.

Fakat aynı amaç şu davranışlara otomatik izin vermez:

• Sahte değerlendirme üretmek
• Rakipler hakkında yanıltıcı içerik yayımlamak
• İzinsiz hesap açmak
• Ücretli hizmet satın almak
• Başka sitelere toplu mesaj göndermek
• Gizli bağlantı ağı kurmak
• Şirket adına doğrulanmamış üstünlük iddiası yayımlamak
• Hukukî veya ticari taahhütte bulunmak

Amaç meşru olabilir. Yöntem yine de yanlış olabilir.

Sonuç hedefi, davranış yöntemlerinin tamamını temizlemez.

Bu nedenle yetki sözleşmesi iki ayrı alan taşımalıdır:

İstenen sonuç

Nereye ulaşılmak isteniyor?

İzin verilen yöntemler

Bu sonuca hangi davranışlarla ulaşılabilir?

Ayrıca üçüncü alan da açık olmalıdır:

Yasaklanan yöntemler

Hangi davranışlar hedefe katkı sağlasa bile kullanılmamalıdır?

Yetki bir anahtar değil, bir zarftır

Yetki çoğu sistemde açık veya kapalı bir düğme gibi düşünülür. “Bu ajana erişim verdik.” Fakat gerçek yetki çok boyutludur.

Bir ajanın yetkisi şu sorularla tanımlanır:

• Hangi eylemi yapabilir?
• Hangi sistem üzerinde?
• Hangi veriyle?
• Kimin adına?
• Kime karşı?
• Hangi amaçla?
• Hangi tutara kadar?
• Hangi süre boyunca?
• Kaç kez?
• Hangi saatlerde?
• Hangi ülkede veya kanalda?
• Hangi risk düzeyine kadar?
• Hangi noktada insan onayı gerekir?
• Yetki başka ajana devredilebilir mi?
• Hata hâlinde ne yapılır?

Bu bütünlüğe: Yetki Zarfı diyebiliriz. Yetki zarfı, bir ajanın hareket edebileceği davranış alanını gösterir.

Örneğin bir e-posta ajanının yetki zarfı şöyle olabilir:

Gelen mesajları okuyabilir. Önceliklendirebilir. Taslak hazırlayabilir. Şirket içi belirli bildirimleri otomatik gönderebilir. Şirket dışındaki kişilere insan onayı olmadan gönderim yapamaz. Fiyat, sözleşme, ödeme veya teslim tarihi içeren mesajları otomatik gönderemez. Eklerdeki kişisel veriyi başka sisteme aktaramaz.

Bu tanım: “E-postaları yönetebilir.” ifadesinden çok daha güvenlidir.

Eylem basamağı ile yetki basamağı eşleşmelidir

Üçüncü bölümde bir Eylem Merdiveni kurmuştuk:

• Gözlem
• Yorum
• Öneri
• Hazırlık
• Yürütme
• Taahhüt
• Kalıcılaştırma

Şimdi bu merdivene karşılık gelen bir yetki kuralı koyabiliriz: Ajanın çıktığı eylem basamağı, kendisine verilen yetki basamağını aşamaz. Görev yalnız gözlemle sınırlandırılmışsa yorum, öneri veya hazırlık için bu sınır aşılmamalıdır. Yorum ve öneri görevde açıkça yer alıyorsa verilen yetki zaten yalnız gözlemden ibaret değildir. Bir ajan taslak hazırlama yetkisi aldıysa e-postayı gönderemez. Bir ajan test ortamında değişiklik yapma yetkisi aldıysa canlıya alamaz. Bir ajan ürünü sepete ekleyebilir ama ödeme yapamaz. Bir ajan video üretebilir ama yayımlayamaz.

Temel kural şudur: her işlem, geçerli yetki zarfının içinde kalmalıdır. Eylem basamağı bu kontrolün yalnız bir boyutudur; daha alt bir basamaktaki işlem de hedef, veri, süre veya kapsam bakımından yasak olabilir. Bu yüzden tek bir sayısal “yetki düzeyi” karşılaştırması bütün denetimin yerine geçemez.

NOMOS Yetki Sözleşmesi

Davranış sözleşmesinin dördüncü bileşeni: NOMOS Yetki Sözleşmesi olacaktır.

Kanonik tanımı şöyledir:

NOMOS Yetki Sözleşmesi; bir insanın, kurumun veya yetkili sistemin belirli bir ajana hangi amaçla, hangi davranışları, hangi varlıklar ve sistemler üzerinde, hangi veri, süre, bütçe, risk ve onay sınırları içinde gerçekleştirme hakkı verdiğini; hangi davranışların yasaklandığını, yetkinin nasıl devredilebileceğini, askıya alınabileceğini ve iptal edilebileceğini açıklayan sürümlü kayıttır.

Daha basit biçimde: Yetki Sözleşmesi, ajana yalnızca ne yapacağını değil, ne kadar ileri gidebileceğini söyler.

Yetki Sözleşmesinin temel alanları

Makinece okunabilir bir yetki kaydının kapsamını göstermek için şu örnek alan adlarını kullanabiliriz. Bu liste tek başına uygulanabilir bir API şeması veya yetkilendirme mekanizması değildir:

principal

authorized_agent

purpose

allowed_actions

prohibited_actions

target_systems

target_entities

allowed_data

prohibited_data

communication_channels

financial_limit

frequency_limit

valid_from

valid_until

geographic_scope

risk_level

human_approval_threshold

delegation_allowed

subagent_limits

logging_required

rollback_required

revocation_method

emergency_stop

version

Bütün kayıt kamuya açık olmak zorunda değildir. Fakat davranışı uygulayan sistem tarafından doğru biçimde okunabilmelidir.

Yetkiyi kim verebilir?

Bir ajan kendisine yetki veremez.

Bir sistem: “Bu görevi tamamlamak için daha geniş yetkiye ihtiyacım var; kendime bu yetkiyi tanımladım.” diyemez. Yetki, ilgili kaynak veya işlem üzerinde karar verme ve gerekiyorsa yetki devretme hakkı bulunan kişi ya da kurumdan gelmelidir. Bir eylemden etkilenmek, o eylemin bütün kaynakları üzerinde başkasına yetki verebilmek anlamına gelmez; etkilenen kişinin gerekli rızası ayrıca değerlendirilir. Fakat “kullanıcı istedi” cümlesi her zaman yeterli değildir. Bir çalışan şirket hesabıyla ajan kullanıyor olabilir. Bu çalışan bütün şirket verilerini paylaşmaya yetkili olmayabilir.

Bir müşteri kendi hesabından talimat verebilir. Bu talimat, başka kişilerin verilerini dilediği gibi kullanma veya paylaşma yetkisini kendiliğinden vermez. Bir yönetici şirket adına işlem yapabilir. Fakat çalışanın biyometrik hakları için tek başına rıza veremez. Bir ebeveyn bazı konularda çocuk adına karar verebilir. Fakat her bağlamda sınırsız yetki taşımaz.

Bu nedenle iki ayrı soru sorulmalıdır: Talimatı kim verdi?

ve: Bu kişi bu yetkiyi vermeye gerçekten yetkili mi?

Yetki zinciri

Bir kurumda yetki tek kişiden doğrudan ajana gitmeyebilir.

Örneğin:

• Yönetim kurulu genel bütçeyi onaylar.
• Genel müdür departmana harcama yetkisi verir.
• Departman yöneticisi satın alma ajanına belirli kategori ve tutarda yetki tanımlar.
• Ajan sipariş hazırlar.
• Finans sistemi ödemeyi gerçekleştirir.

Bu ilişkiye: Yetki Zinciri diyebiliriz.

Yetki zincirinin her halkası şu sorulara cevap vermelidir:

• Yetkiyi kim verdi?
• Kendisinin bu yetkiyi devretme hakkı var mıydı?
• Ne kadarını devretti?
• Hangi sınırlar korundu?
• Yetki ne zaman sona erecek?
• İşlem kimin sorumluluğunda?

Zincirde bir halka geçersizse sonraki yetkiler de sorunlu hâle gelir.

Devredilen yetki büyüyemez

Bir ajan kendisine verilen görevi alt ajana verebilir. Fakat alt ajana, kendisinin sahip olmadığı yetkiyi aktaramaz. Araştırma ajanının yetkisi kamuya açık kurum bilgileriyle sınırlıysa, alt ajan kullanarak kapsam dışı kişisel veri toplamaya başlayamaz. Bir bilginin kamuya açık olması da her amaçla işlenmesini kendiliğinden yetkili kılmaz. E-posta ajanı taslak hazırlamaya yetkiliyse, başka bir gönderim aracını çağırarak mesajı yayımlayamaz. Web ajanı test ortamında çalışabiliyorsa, alt ajan aracılığıyla canlı üretime geçemez.

Bu ilke şöyledir: Devredilen yetki, kaynağındaki yetkiden daha geniş olamaz. Hatta güvenli tasarımda alt ajana çoğu zaman daha dar yetki verilmelidir.

Buna: Yetki Zayıflatma İlkesi diyebiliriz. Her devirde yalnız görevin gerektirdiği en küçük yetki aktarılır.

Yetki aklama

Çoklu ajan sistemlerinde tehlikeli bir durum oluşabilir. Ana ajan doğrudan yapamayacağı bir işlemi başka ajana veya araca yaptırabilir.

Örneğin:

• Araştırma ajanı mesaj gönderme yetkisine sahip değildir.
• Fakat e-posta ajanına “bu kişiye ulaş” görevi verir.
• E-posta ajanı mesajı gönderir.
• Sonuçta yetkisiz eylem zincir içinde görünmez hâle gelir.

Buna: Yetki Aklama diyebiliriz. Yetki aklama, yasak veya yetkisiz bir davranışın başka ajan, araç, entegrasyon veya alt görev üzerinden geçirilerek meşru görünmesidir.

Başka örnekler:

• Doğrudan ödeme yetkisi olmayan ajan, satın alma platformundaki otomatik yenilemeyi başlatır.
• Canlı yayın yetkisi olmayan ajan, CI/CD aracını çağırarak sürümü yayımlar.
• Kişisel veri paylaşamayan ajan, veriyi başka analiz aracına gönderir.
• Hukukî açıklama yapamayan sosyal medya ajanı, metni başka yayın sistemine aktarır.

GBO yalnız son eylemi değil, yetki zincirini de denetler.

Bir işlemin başka araç tarafından yapılması, yetki sorununu ortadan kaldırmaz.

Gölge yetki

Bir kurumda teknik erişimler zamanla birikir. Eski API anahtarları açık kalır. Bir çalışan geçmiş görevinden kalan yönetici hesabına erişebilir. Bir ajan artık ihtiyaç duymadığı dosyalara ulaşabilir. Bir entegrasyon, bütün hesap üzerinde geniş izin taşır. Bu erişimler resmî davranış sözleşmesinde bulunmasa bile teknik olarak kullanılabilir.

Buna: Gölge Yetki diyebiliriz. Gölge yetki, açıkça verilmemiş fakat mevcut erişim veya kimlik bilgileri nedeniyle teknik olarak kullanılabilen davranış gücüdür.

Gölge yetki tehlikelidir çünkü sistem: “Yapabiliyorsam izin verilmiştir.” sonucuna ulaşabilir.

Oysa: Erişim kalıntısı, güncel yetki değildir.

Yetki borcu

Bir kurum zaman içinde:

• eski çalışan hesapları,
• süresi dolmuş ajan izinleri,
• belirsiz görev tanımları,
• fazla geniş API anahtarları,
• kapanmamış entegrasyonlar,
• unutulmuş otomatik işlemler,
• belgesiz istisnalar

biriktirebilir.

Buna: Yetki Borcu diyebiliriz. Yetki borcu, kurumun sistemlerinde bulunan fiilî erişimlerle resmî ve güncel davranış hakları arasındaki farktır. Teknik borç gibi yetki borcu da başlangıçta görünmez olabilir. Sistem çalışır. Ajanlar görevlerini tamamlar.

Fakat bir olay meydana geldiğinde şu sorular cevapsız kalır:

• Bu ajan neden bu hesaba erişebiliyordu?
• Kim bu izni verdi?
• Yetki hâlâ geçerli miydi?
• Bu eylem neden insan onayı istemedi?
• Alt ajan bu veriyi nasıl gördü?
• Neden iptal edilen rol çalışmaya devam etti?

GBO, yetki borcunu düzenli olarak ölçmeyi ve azaltmayı gerektirir.

Asgari yetki ilkesi

Bir ajana: “Belki ileride gerekir.” diyerek geniş erişim vermek kolaydır. Fakat her ek yetki yeni bir davranış riski oluşturur.

Bu nedenle temel ilke: Asgari Yetki olmalıdır.

Ajan, belirli görevini tamamlamak için gereken en küçük erişim ve davranış hakkına sahip olmalıdır.

Bir raporlama ajanı veriyi okuyabilir. Veriyi silememelidir. Bir sosyal medya ajanı taslak hazırlayabilir. Hesap ayarlarını değiştirmemelidir. Bir SEO ajanı başlık önerisi sunabilir. Fiyat sözleşmesini kendi başına değiştirmemelidir. Bir müşteri keşif ajanı kamuya açık şirket bilgilerini toplayabilir. Kişisel telefonları veya hassas verileri gereksiz yere biriktirmemelidir. Asgari yetki sistemi yavaşlatmak için değildir. Yanlış davranışın etkisini sınırlandırmak içindir.

Sürekli yetki ve işlem özelinde yetki

Bu değerlendirmede sürekli yetkiyi ve işlem özelinde yetkiyi ayırıyoruz.

Sürekli yetki

Belirli davranışların düzenli olarak yapılmasına izin verir.

Örneğin:

• Her sabah gelen e-postaları sınıflandırmak
• Her hafta site sağlığını kontrol etmek
• Belirli tutarın altındaki sarf malzemelerini yenilemek
• Onaylanmış içerik takvimini yayımlamak

İşlem özelinde yetki

Tek bir belirli davranış için verilir.

Örneğin:

• Bu mesajı gönder
• Bu sürümü canlıya al
• Bu videoyu yayımla
• Bu faturayı öde
• Bu sözleşme taslağını ilet

Sürekli yetki, tekrarlanan onay ihtiyacını azaltabilir; bu nedenle sınırları ve durma koşulları açık olmalıdır. İşlem özelindeki onay ise önemli farkları görünür kılabilir. Ancak sık ve anlamsız onay talepleri de dikkati zayıflatabilir. Hiçbiri tek başına güvenlik veya verimlilik garantisi değildir. GBO doğru davranış için ikisi arasında denge kurar.

Geçmiş onay, gelecekteki vekâlet değildir

Bir kullanıcı dün bir e-postayı onaylamış olabilir. Bu, bugün benzer görünen başka bir e-postanın otomatik gönderilebileceği anlamına gelmez. Bir yönetici bir videonun yayımlanmasına izin vermiş olabilir. Bu, aynı avatarla farklı mesajların otomatik yayımlanmasına izin vermez. Bir müşteri bir kod sürümünü onaylamış olabilir. Bu, sonraki bütün sürümlerin otomatik kabul edildiği anlamına gelmez.

Benzerlik, yetki sürekliliği değildir.

Sürekli yetki açıkça verilmediyse eski onay yeni işlemde yeniden kullanılmamalıdır.

Sessizlik onay değildir

Bazı sistemler kullanıcı belirli süre içinde cevap vermediğinde işlemi otomatik gerçekleştirebilir. Düşük riskli ve önceden açıkça kabul edilmiş süreçlerde bu mümkün olabilir.

Fakat yüksek etkili işlemlerde sessizlik:

• ödeme onayı,
• yüz veya ses kullanımı,
• kişisel veri paylaşımı,
• hukukî taahhüt,
• kamuya açık yayın

olarak yorumlanmamalıdır.

Cevap vermemek, evet demek değildir.

Bilgilendirilmiş onay

Bir insana yalnız: “Onaylıyor musunuz?” diye sormak yeterli değildir. Kişi neyi onayladığını anlayabilmelidir.

İyi bir onay ekranı şu bilgileri göstermelidir:

• Ne yapılacak?
• Kimin adına yapılacak?
• Kime veya hangi sisteme yöneltilecek?
• Hangi veriler kullanılacak?
• Ne kadar maliyet doğacak?
• Hangi taahhüt oluşacak?
• İşlem geri alınabilir mi?
• İşlem bir kez mi, sürekli mi yapılacak?
• Başka ajanlara görev devredilecek mi?
• Önemli risk nedir?

Onay düğmesi küçük olabilir. Fakat onayın anlamı büyük olabilir. Bu nedenle GBO, kullanıcıya gereksiz ayrıntı yığmadan karar için gerekli özü göstermelidir.

Onay yorgunluğu

Her küçük adımda insan onayı istemek güvenli görünebilir. Fakat yüzlerce bildirim alan insan sonunda düşünmeden tıklamaya başlayabilir.

Buna: Onay Yorgunluğu diyebiliriz. Onay yorgunluğunda insan sistemin gerçek denetçisi olmaktan çıkar. Yalnızca işlemi ilerleten düğmeye dönüşür.

Bu nedenle iyi GBO sistemi:

• Düşük riskli eylemleri açık sürekli yetki altında otomatikleştirir.
• Benzer ve geri alınabilir işlemleri toplu biçimde sunar.
• Yüksek riskli eylemleri ayrı ve görünür hâle getirir.
• Değişen veya olağan dışı unsurları vurgular.
• İnsan onayını gerçekten karar gereken noktada ister.

Amaç insanı her aşamada rahatsız etmek değildir.

İnsanı anlamlı eşikte devreye sokmaktır.

Anlamlı onay

Bir onay gerçekten anlamlıysa kullanıcı:

• İşlemin sonucunu anlayabilir.
• Alternatifleri görebilir.
• Reddetme hakkına sahiptir.
• Onay vermediğinde cezalandırılmaz.
• Daha sonra yetkiyi geri çekebilir.
• Gerektiğinde açıklama isteyebilir.

Bir sistem: “Kabul etmezseniz hizmeti kullanamazsınız.” diyerek hizmet için gerekmeyen geniş veri kullanımını dayatıyorsa, kabulün özgürce verilip verilmediği sorgulanmalıdır. Sistem, sırf bir tıklama kaydı var diye bu sorunu çözülmüş sayamaz. Bir çalışan, işini kaybetme korkusuyla yüzünün sınırsız AI kullanımını onaylıyorsa onayın özgürlüğü sorgulanmalıdır. GBO yalnızca teknik olarak “evet” kaydı aramaz. Onayın bağlamını da değerlendirir.

Amaçla sınırlı rıza

Bir kişinin verisi veya kimliği belirli amaç için kullanılabilir. Bu kullanım başka amaçlara kendiliğinden genişlememelidir. Bir çalışan eğitim videosu için ses kaydı vermiş olabilir. Bu izin, kaydın pazarlama reklamında kullanılmasını kendiliğinden kapsamaz. Bir müşteri destek talebi için bilgi paylaşmış olabilir. Bu paylaşım, satış profili oluşturmak için otomatik yetki vermez; yeni kullanımın dayanağı ayrıca değerlendirilmelidir. Bir kullanıcı uçuş rezervasyonu için pasaport bilgisi vermiş olabilir. Aynı veri ilgisiz analiz sistemlerine aktarılmamalıdır.

Bir amaç için verilen rıza, bütün amaçlar için verilen rıza değildir.

Veriye erişmek, veriyi kullanma hakkı değildir

Bir ajan müşteri veritabanını okuyabilir. Fakat bütün verileri başka modele göndermeye yetkili olmayabilir. Bir e-posta ajanı gelen mesajları görebilir. Bu erişim, mesajları veya eklerini model eğitimi için kullanma yetkisini kendiliğinden içermez. Bir insan kaynakları ajanı aday özgeçmişlerine erişebilir. Bu erişim de özgeçmişleri ilgisiz analizlerle birleştirme yetkisi vermez.

Veri yetkisini dört davranışa ayırmak gerekir:

• Görmek
• İşlemek
• Paylaşmak
• Saklamak

Birinciye izin verilmesi diğer üçünü otomatik olarak kapsamaz.

Buna beşinci bir davranış da eklenebilir:

• Yeni amaç için yeniden kullanmak

Her biri ayrı yetki gerektirebilir.

Para harcama yetkisi

Bir ajan bütçe kullanabiliyorsa yalnız tutar sınırı yeterli olmayabilir.

Şunlar da tanımlanmalıdır:

• Hangi kategori?
• Hangi satıcı?
• Tek seferlik mi?
• Abonelik mi?
• Otomatik yenileme var mı?
• Vergi ve ek ücretler dâhil mi?
• Toplam aylık limit nedir?
• İade mümkün mü?
• Hangi ödeme aracı kullanılabilir?
• Hangi ülkelerde işlem yapılabilir?

Bir ajan 50 dolarlık ürün satın almaya yetkili olabilir. Fakat aylık 49 dolarlık süresiz abonelik başlatmamalıdır. İlk ücret düşük görünür. Toplam taahhüt çok daha büyük olabilir.

İşlem tutarı ile toplam yükümlülük aynı şey değildir.

Şirket adına konuşma yetkisi

Bir ajan şirketin doğru bilgilerine erişebilir. Fakat bu, şirket adına her konuda konuşabileceği anlamına gelmez.

Şunlar farklı yetkilerdir:

• Genel bilgi vermek
• Teknik destek sunmak
• Fiyat açıklamak
• İndirim vermek
• Teslim tarihi taahhüt etmek
• Hukukî yorum yapmak
• Kriz açıklaması yayımlamak
• Yatırımcı bilgisi paylaşmak

Bir destek ajanı ürün özelliklerini açıklayabilir. Bu görev, şirket adına hukukî sorumluluk kabul etme yetkisini kendiliğinden vermez. Bir sosyal medya ajanı onaylanmış kampanyayı yayımlayabilir. Bu yayın yetkisi, şirketin politik konumunu kendi başına belirleme yetkisi değildir. Bir AI avatarı önceden onaylanmış eğitim içeriğini sunabilir. Bu onay, yönetici adına yeni stratejik açıklama yapmayı kapsamaz.

AI avatarında yetkinin katmanları

Bir kişinin dijital benzerliğinin kullanılması tek bir onaya indirgenemez.

En az şu yetkiler ayrılmalıdır:

• Yüz modelinin oluşturulması
• Ses modelinin oluşturulması
• Belirli metnin üretilmesi
• Belirli dilde kullanılması
• Belirli kanalda yayımlanması
• Belirli süre boyunca erişilebilir kalması
• İçeriğin yeniden düzenlenmesi
• Başka kampanyada yeniden kullanılması
• Model dosyasının başka sağlayıcıya aktarılması

Bir yönetici: “Eğitim videoları için avatarımı kullanabilirsiniz.” demiş olabilir. Bu, avatarın satış mesajlarında, yatırımcı açıklamalarında veya politik içerikte kullanılmasına izin vermez.

Kimlik üretme izni, sınırsız temsil yetkisi değildir.

Canlı üretim yetkisi

Bir ajan kodu doğru biçimde düzenleyebilir. Testleri geçirebilir. Yerel görünüm kusursuz olabilir. Fakat canlı üretim başka bir davranış seviyesidir.

Canlı yayın:

• gerçek müşterileri,
• gelir akışını,
• veriyi,
• marka itibarını,
• arama motoru görünürlüğünü

etkileyebilir.

Bu nedenle şu yetkiler ayrılmalıdır:

• Dosya okuma
• Yerel değişiklik
• Test ortamında yayın
• Canlı yayın
• DNS veya altyapı değişikliği
• Veri taşıma
• Geri alma

Bir ajan bazı projelerde bütün bu yetkilere sahip olabilir. Fakat bu açıkça tanımlanmalıdır.

Hukukî metin ve fiyat yetkisi

Bir web ajanı fiyat sayfasını teknik olarak değiştirebilir. Fakat fiyatı belirleme yetkisi olmayabilir. Bir içerik ajanı gizlilik metnini daha okunabilir hâle getirebilir. Fakat hukukî yükümlülüğü değiştiremez. Bir SEO ajanı başlığı kısaltabilir. Fakat sözleşmenin anlamını değiştirecek ifadeyi seçmemelidir.

Bu nedenle bazı içerik alanları:

• fiyat,
• hukukî taahhüt,
• garanti,
• iade,
• veri kullanımı,
• sahiplik,
• ödeme koşulu

yüksek yetki sınıfında değerlendirilmelidir.

Acil durum yetkisi

Bazı olaylarda hızlı davranmak gerekir. Sistem saldırı altındadır. Veri sızıntısı şüphesi vardır. Canlı site kritik hata veriyordur. Normal onay zincirini beklemek bazı olaylarda zararı artırabilir. Bu nedenle acil durumlar için önceden, yetkili kişilerce sınırları belirlenmiş bir acil durum yetkisi tanımlanabilir. Ajan yalnızca aciliyet fark etti diye kendisine yeni yetki veremez.

Acil yetki:

• yalnız belirli olay türlerinde,
• belirli süre için,
• sınırlı eylemlerle,
• tam kayıt altında

kullanılmalıdır.

Örneğin ajan:

• sistemi geçici olarak salt-okunur moda alabilir,
• belirli erişim anahtarını askıya alabilir,
• son güvenli sürüme geri dönebilir,
• otomatik gönderimi durdurabilir.

Fakat acil durum bahanesiyle:

• kalıcı politika değiştirmemeli,
• ilgisiz hesapları kapatmamalı,
• yeni ticari taahhüt oluşturmamalıdır.

Acil yetki kullanıldığında insan en kısa sürede bilgilendirilmelidir.

Çift kontrol

Yüksek etkili işlemlerde tek kişinin veya tek ajanın kararı yeterli olmayabilir.

Örneğin:

• Büyük ödeme
• Veri silme
• Yetki devri
• Kamuya açık kriz açıklaması
• Yüksek riskli model yayını
• Geniş çaplı müşteri iletişimi

iki ayrı kontrol gerektirebilir.

Buna: Çift Kontrol diyebiliriz. Bir ajan işlemi hazırlar. Başka bir insan veya bağımsız sistem doğrular. Bu yaklaşım hızın biraz azalmasına neden olabilir. Bağımsız ve yetkin kontroller, bazı hataların işlemden önce fark edilmesine yardımcı olabilir. Aynı varsayımı paylaşan iki kontrolün bağımsız olduğu ise varsayılmamalıdır.

Görevlerin ayrılması

Yüksek etkili bir işlemde aynı ajan, öneriyi hazırlama, kendi önerisini onaylama, uygulama ve sonucu tek başına denetleme rollerinin tamamını üstlenmemelidir. Sorun bu işlerden herhangi birini yapması değil, bağımsız kontrol gerektiren bütün kararların tek yerde toplanmasıdır. Bütün güç tek yerde toplandığında hata veya manipülasyon daha zor fark edilir.

Örneğin:

• Satın alma ajanı seçimi yapar.
• İnsan bütçeyi onaylar.
• Ödeme sistemi işlemi gerçekleştirir.
• Denetim ajanı makbuzu kontrol eder.

Bu ayrım her küçük iş için gerekli değildir. Fakat risk yükseldikçe değer kazanır.

Yetkinin süresi

Bir ajana verilen yetki sonsuza kadar açık kalmamalıdır.

Yetki:

• Tek işlem
• Tek oturum
• Belirli günler
• Belirli proje
• Belirli sözleşme süresi

ile sınırlandırılabilir. Süre bittiğinde yetki otomatik olarak kapanmalıdır.

Unutulmuş yetki, güvenlik açığıdır.

Yetkinin yenilenmesi

Bir yetkinin süresi dolduğunda sistem eski davranışı otomatik sürdürmemelidir.

Şunlar yeniden değerlendirilmelidir:

• Görev hâlâ gerekli mi?
• Ajan hâlâ aynı mı?
• İnsan sorumlusu aynı mı?
• Risk değişti mi?
• Kullanılan araçlar değişti mi?
• Daha dar yetki yeterli olur mu?

Yenileme, eski izni kopyalamak değil, güncel gereksinimi doğrulamaktır.

Yetkinin geri alınması

İnsan verdiği yetkiyi geri çekebilmelidir.

Bir ajan:

• durdurulabilir,
• erişimi kesilebilir,
• görevleri askıya alınabilir,
• geçmiş kimlik bilgileri iptal edilebilir.

Yetki geri çekildiğinde, ilgili görev ve erişim kapsamı için güvenli durdurma planı uygulanmalıdır. Tamamlanmış veya dış sistemde yürümeye başlamış işlemlerin durumu ayrıca doğrulanır. Plan şu adımları içerebilir:

• Yeni eylem başlatmamak
• Alt ajanları durdurmak
• Zamanlanmış işlemleri iptal etmek
• İptal edilen yetkiye ait erişim belirteçlerini veya anahtarları uygun kapsamda geçersiz kılmak
• Açık görevleri raporlamak
• Veriyi yetki sözleşmesine göre silmek veya arşivlemek
• Geri çekme kaydı oluşturmak

İptal edilemeyen yetki, tam insan kontrolü değildir.

Kill switch tek başına yeterli değildir

Bir durdurma düğmesi önemlidir. Fakat sistemin bütün eylemlerini gerçekten durdurduğundan emin olmak gerekir. Merkez ajan kapanabilir. Alt ajanlar çalışmaya devam edebilir. Zamanlanmış işler yürüyebilir. Harici entegrasyonlar veri göndermeye devam edebilir.

Bu nedenle acil durdurma:

• ana ajanı,
• alt ajanları,
• otomasyonları,
• zamanlanmış işleri,
• dış araç çağrılarını

kapsamalıdır. Ayrıca durdurma sonrasında hangi işlemlerin yarım kaldığı görülmelidir.

Yetki durumu görünür olmalıdır

Ajan şu bilgiyi kendi davranışı sırasında okuyabilmelidir:

Bu işlem için yetkim var mı? Yetki ne zaman sona eriyor? Hangi tutar sınırı var? İnsan onayı gerekiyor mu? Alt ajana devredebilir miyim? İşlem geri alınabilir mi?

Yetki yalnız hukukî bir belgede saklanır ve sistem tarafından uygulanmazsa yeterli değildir. Davranış anında erişilebilir olmalıdır.

NOMOS Yetki Kapısı

Bir ajan önemli bir eyleme geçmeden önce şu kapılardan geçmelidir:

1. Yetki Veren Kapısı

Talimatı veren kişi veya sistem doğru mu ve bu yetkiyi vermeye hakkı var mı?

2. Amaç Kapısı

Eylem verilen amaçla gerçekten ilgili mi?

3. Davranış Kapısı

Bu özel eylem açıkça izin verilen davranışlar içinde mi?

4. Hedef Kapısı

Eylemin yöneldiği kişi, kurum, hesap veya sistem yetki zarfı içinde mi?

5. Veri Kapısı

Kullanılacak ve paylaşılacak veriler için geçerli hak var mı?

6. Sınır Kapısı

Tutar, süre, sıklık, kanal ve coğrafya sınırları korunuyor mu?

7. Rıza Kapısı

Eylemden etkilenen kişilerin gerekli rızaları var mı?

8. Onay Kapısı

Bu risk düzeyinde insanın işlem özelinde onayı gerekiyor mu ve alındı mı?

9. Delegasyon Kapısı

Görev başka ajana aktarıldıysa yetki zinciri geçerli mi?

10. Kayıt ve Geri Dönüş Kapısı

Eylem kaydedilecek mi; durdurma, geri dönüş ve telafi yolları ile bunların sınırları tanımlı mı?

Basit biçimde:

YETKİLİ EYLEMİN KOŞULLARI:

GEÇERLİ YETKİ VEREN

VE AÇIK AMAÇ

VE İZİNLİ DAVRANIŞ

VE DOĞRU HEDEF

VE İZİNLİ VERİ

VE SINIRLAR İÇİNDE İŞLEM

VE GEREKLİ RIZA

VE GEREKLİ ONAY

VE GEÇERLİ DEVİR

VE DENETLENEBİLİR SONUÇ

Kapılardan biri geçilmezse ajan eylem seviyesini düşürmelidir.

Yetki Kapısı neden puan değildir?

Kullanıcı ajanı çok seviyor ve ona çok güveniyor olabilir. Ajan geçmişte yüz görevi kusursuz tamamlamış olabilir. Eylem şirket için çok yararlı olabilir. Sonuç büyük gelir sağlayabilir. Bunların hiçbiri eksik yetkiyi telafi etmez.

Güven, yetki belgesinin yerine geçmez.

Başarı geçmişi, yeni işlem için otomatik vekâlet değildir.

Olumlu sonuç ihtimali, rıza eksikliğini temizlemez.

Yetki Kapısı bu nedenle bir VE mantığıdır. Kritik koşullardan biri yoksa eylem uygun değildir.

Yetki belirsizliğinde doğru davranış

Bir ajan yetkisinden emin değilse üç temel seçeneği değerlendirebilir. Daha düşük etkili adımın da mevcut yetki içinde kalması gerekir:

Eylem seviyesini düşürmek

Göndermek yerine taslak hazırlamak. Canlıya almak yerine test ortamında bırakmak. Satın almak yerine sepet oluşturmak.

Açıklama istemek

“Bu mesajı hazırlamamı mı, yoksa göndermemi de istiyor musunuz?” “Bu değişikliği test ortamında mı, canlı sitede mi uygulamalıyım?” “Bu tutar için ayrıca finans onayı gerekiyor mu?”

Durdurmak

Risk yüksekse ve yetki doğrulanamıyorsa işlem yapılmamalıdır. Belirsizliği geniş yetki lehine yorumlamak yanlış davranıştır.

Şüpheli yetki, yetki değildir.

En küçük yeterli soru

Ajan her aşamada uzun onay formları sunmak zorunda değildir.

Bazen tek açık soru yeterlidir: “Bu e-postayı yalnız hazırlayayım mı, yoksa şirket adına göndermeme de izin veriyor musunuz?” “500 dolar tek seferlik harcama mı, yoksa aylık abonelik mi olabilir?” “Bu avatarı yalnız eğitim videolarında mı kullanacağız?” “Bu sürümü canlıya yayımlamama da yetki veriyor musunuz, yoksa yalnız test ortamında mı bırakmalıyım?” İyi sistem, yetki boşluğunu en küçük fakat yeterli soruyla kapatır.

Yetki makbuzu

Her önemli eylemden sonra bir:

Yetki Makbuzu

oluşturulabilir.

Bu makbuz şunları gösterir:

• Eylem neydi?
• Kim talep etti?
• Yetkiyi kim verdi?
• Yetki veren kişinin hakkı neydi?
• Ajan hangi sürüm ve rol altında çalıştı?
• Yetki tek işlem mi, sürekli mi?
• Hangi veriler kullanıldı?
• Hangi sınırlar uygulandı?
• İnsan onayı ne zaman alındı?
• İşlem geri alınabilir mi?
• Yetki ne zaman sona eriyor?

Örnek:

Eylem: Potansiyel müşteriye teklif görüşmesi talebi gönderildi. Talep eden: Şirket yöneticisi. Yetki kapsamı: Yalnız bu alıcıya, onaylanan metinle, tek seferlik gönderim. Paylaşılan bilgiler: Genel hizmet özeti ve şirket e-postası. Paylaşılmayan bilgiler: Finansal kayıtlar, özel telefon ve müşteri verileri. Taahhüt: Mesaj bağlayıcı fiyat veya sözleşme taahhüdü içermez. Gönderen ajan: Yetkili e-posta ajanı. Onay zamanı: 14.42. Geri dönüş: Mesaj geri alınamaz; takip iletişimi durdurulabilir.

Bu kayıt, onay kaynağı ve alıcı sistemin işlem sonucuyla ilişkilendirildiğinde denetimi kolaylaştırır. Ajanın kendisi tarafından yazılmış bir yetki beyanı, geçerli onayın yerine geçmez.

İnsan onayı bir tören olmamalıdır

Bazı sistemler insan onayını yalnız sorumluluğu insana aktarmak için kullanabilir. Uzun ve anlaşılmaz bir metin gösterilir. Kullanıcı “kabul et” düğmesine basar.

Sonra sistem: “İnsan onayladı.” der. Bu gerçek denetim değildir.

İnsan onayı:

• anlaşılır,
• belirli,
• gerekli bilgiye dayalı,
• özgürce verilebilir,
• geri çekilebilir

olmalıdır.

İnsanın tıklaması, insanın anladığını kanıtlamaz.

GBO, onayı bir hukukî kalkan değil, gerçek karar anı olarak tasarlar.

Bir web ajanı örneği

Bir ajan web sitesini SEO ve GEO bakımından geliştirmekle görevlendirilir.

Yetkisi şunları içerebilir:

• Dosya okumak
• SERP araştırması yapmak
• İçerik taslağı hazırlamak
• Kod düzenlemek
• Test çalıştırmak
• Geri alınabilir yayın paketi oluşturmak
• Canlı HTTPS doğrulaması yapmak

Fakat şu işlemler ayrıca onay gerektirebilir:

• Fiyat değiştirmek
• Hukukî metin değiştirmek
• Yeni ödeme hizmeti satın almak
• DNS veya alan adı ayarını değiştirmek
• Müşteri adına dışarıya mesaj göndermek
• Kanonik yayınları silmek
• Büyük URL göçü yapmak
• Şirket adına karşılaştırmalı üstünlük iddiası yayımlamak

İyi yetki sözleşmesi ajanın inisiyatifini yok etmez. Sınırların içinde daha özgür çalışmasını sağlar.

Bir müşteri keşif ajanı örneği

Müşteri keşif ajanına şu yetki verilebilir:

Kamuya açık şirketleri araştır. İhtiyaç sinyallerini sınıflandır. Uygunluk puanı oluştur. İletişim için taslak hazırla.

Fakat:

Kişisel veri kazıma. Gizli iletişim bilgisi toplama. İnsan onayı olmadan mesaj gönderme. Şirket adına fiyat sözü verme. Aynı kişiye tekrar tekrar ulaşma.

yasak olabilir. Ajan doğru adayı bulmuş olsa bile gönderim ayrı yetki katmanıdır.

Bir satın alma ajanı örneği

Bir satın alma ajanına:

Önceden onaylanmış ofis malzemelerini, işlem başına 100 dolar ve aylık toplam 500 dolar sınırıyla satın al. yetkisi verilebilir.

Bu yetki şunları kapsamayabilir:

• Abonelik
• Otomatik yenileme
• Yeni satıcı
• Uluslararası vergi yükümlülüğü
• İade edilemeyen ürün
• Kişisel kullanım
• Kontrollü veya yüksek riskli ürün

Tutar sınırı tek başına yeterli değildir. Kategori ve işlem türü de önemlidir.

Bir AI avatar örneği

Bir yönetici şu yetkiyi verebilir:

Onaylanmış eğitim metinlerini Türkçe ve İngilizce olarak dijital avatarımla üretin. Her video yayımlanmadan önce bana gösterilsin. Kullanım yalnız şirket içi eğitim platformunda ve altı ay boyunca geçerli olsun.

Bu yetki şunları kapsamaz:

• Sosyal medya reklamı
• Yeni dil üretimi
• Müşteriye kişisel mesaj
• Politik veya finansal açıklama
• Ses modelinin başka sağlayıcıya aktarılması
• Süresiz arşiv kullanımı

Yetki sözleşmesi bu sınırları görünür kılar.

Yetki ve güven arasındaki gerçek ilişki

Bir insana veya ajana güvenmek önemlidir. Fakat güven ile sınırsız vekâlet aynı şey değildir.

İnsanlar en güvendikleri çalışanlarla bile:

• bütçe sınırı,
• imza yetkisi,
• erişim rolü,
• çift kontrol

kullanır. Bu güvensizlik değildir. Kurumsal sorumluluktur. Aynı ilke yapay zekâ ajanları için de geçerlidir.

Sınır koymak, güveni azaltmaz. Güvenin sürdürülebilir olmasını sağlar.

Yetki sınırı bulunmadığında olumlu sonuçlar heyecan verici olabilir. İlk büyük hata ise bütün güveni yok edebilir.

Yetki disiplininin ticari değeri

Yetki sistemi yalnız güvenlik maliyeti değildir. Beklenen katkısı; kapsam dışı iletişimi ve taahhütleri azaltmak, veri kullanımını sınırlamak ve kararların kim tarafından verildiğini izlenebilir kılmaktır. Açık eşikler gereksiz onay taleplerini de azaltabilir. Bu etkiler varsayılıp başarı hanesine yazılmamalıdır. Yetki ihlalleri, gereksiz onaylar, olay inceleme süresi ve müşteri deneyimi ayrı ayrı izlenmelidir.

Paradoks şudur: Yetki sınırları netleştikçe güvenli otonomi büyüyebilir. Belirsiz sistemde her işlem için insan kontrolü gerekir. Açık yetki zarfında ajan sınırlar içinde bağımsız çalışabilir.

Bir kurum kendisini nasıl hazırlamalı?

Ajan çağında kurumlar şu adımları atmalıdır:

Ajan envanteri

Hangi ajanlar çalışıyor?

Araç envanteri

Hangi hesaplara, dosyalara ve sistemlere erişiyorlar?

Yetki haritası

Her ajan hangi eylemleri yapabilir?

Yasaklı davranışlar

Hangi işlemler hiçbir zaman otomatik yapılmamalıdır?

Onay eşikleri

Hangi tutar, risk veya davranışta insan devreye girer?

Delegasyon kuralları

Ajan başka ajana görev verebilir mi?

Süre ve iptal

Yetki ne zaman biter ve nasıl geri alınır?

Kayıt sistemi

Hangi eylemler makbuz üretir?

Acil durdurma

Bütün zincir nasıl kapatılır?

Yetki için on sekiz denetim sorusu

Bir ajan eyleme geçmeden önce şu sorular sorulabilir:

• Talimatı veren kişi veya sistem kimdir?
• Bu kişi veya sistem yetki vermeye gerçekten yetkili midir?
• Yetki hangi amaç için verilmiştir?
• İstenen eylem açıkça yetki kapsamına giriyor mu?
• Eylem hangi basamaktadır: gözlem, hazırlık, yürütme veya taahhüt?
• Hedef kişi, kurum veya sistem doğru mudur?
• Kullanılacak veri için geçerli erişim ve kullanım hakkı var mı?
• Veri başka sisteme aktarılacak mı?
• Bütçe, süre, sıklık ve coğrafya sınırları korunuyor mu?
• Eylem başka kişilerin rızasını gerektiriyor mu?
• İnsan onayı bu risk düzeyinde gerekli mi?
• Geçmiş onay yanlış biçimde sürekli yetki sayılıyor mu?
• Yetki başka ajana devredildiyse zincir geçerli mi?
• Alt ajan ana ajandan daha geniş yetki aldı mı?
• Teknik erişim resmî yetki sanılıyor mu?
• Yetkinin süresi dolmuş olabilir mi?
• Eylem kaydedilecek mi; geri dönüş ve telafi sınırları açık mı?
• İnsan yetkiyi şimdi durdurabilir mi?

Bu soruların tamamı her küçük işlemde görünür biçimde sorulmak zorunda değildir. Fakat sistem tasarımında cevapları bulunmalıdır.

Yetki hazır olma düzeyleri

Bu bölümdeki öneriyi beş yetkilendirme hazırlık düzeyinde özetleyebiliriz:

1. Örtük yetki

Ajan doğal dildeki geniş görevden ne yapabileceğini tahmin eder.

2. Belgelenmiş yetki

İzinler yazılıdır fakat sistem tarafından otomatik uygulanmaz.

3. Yapılandırılmış yetki

Amaç, davranış, veri, bütçe ve süre makinece okunabilir biçimde tanımlanmıştır.

4. Uygulanan yetki

Sistem yetki dışı eylemi teknik olarak engeller veya insan onayına taşır.

5. Denetlenebilir ve iptal edilebilir yetki

Her eylem kayıtlıdır; yetki zinciri görülebilir, sınırlar güncellenebilir ve bütün ajan ağı durdurulabilir. GBO’nun hedefi beşinci düzeydir.

Nitelikli yetki

Bir yetkinin:

Nitelikli Yetki

sayılabilmesi için şu koşulları taşıması gerekir:

• Doğru kişi veya kurum tarafından verilmiştir.
• Amaç açık ve meşrudur.
• İzin verilen davranışlar belirgindir.
• Kapsam, veri, hedef ve süre sınırlıdır.
• Gerekli rızalar alınmıştır.
• İnsan onayı eşikleri tanımlıdır.
• Delegasyon kuralları açıktır.
• Yetki iptal edilebilir.
• Eylemler denetlenebilir.
• Teknik sistem sınırları uygulayabilir.

Nitelikli yetki, ajana: “Ne gerekiyorsa yap.” demek değildir.

“Bu amaç için, bu sınırlar içinde, şu davranışları yapabilirsin.”

demektir.

Bölümün hükmü

Bir ajan doğru kimliği bulabilir. Gerçek yeteneği doğrulayabilir. En uygun seçeneği belirleyebilir. Yine de eyleme geçme hakkına sahip olmayabilir. Doğru seçim, otomatik yetki değildir. İyi amaç, sınırsız yöntem izni değildir. Teknik erişim, kurumsal vekâlet değildir. Geçmiş onay, kalıcı yetki değildir. Sessizlik, rıza değildir. Başarılı sonuç, yetkisiz süreci doğru hâle getirmez.

GBO bu nedenle her önemli davranıştan önce şu soruyu sorar:

Bu eyleme kim izin verdi?

Ve tek bir isimle yetinmez.

Şunları da sorar:

Bu kişi yetki vermeye yetkili miydi? Hangi davranışa izin verdi? Hangi amaç için? Hangi süre boyunca? Hangi veriyle? Hangi tutara kadar? Hangi kanalda? Hangi insan onayıyla? Başka ajana devredilebilir miydi? İnsan bu yetkiyi geri alabilir mi?

NOMOS Yetki Sözleşmesi, otonomiyi ortadan kaldırmaz. Otonomiyi güvenilir hâle getirir. Ajan sınırların içinde bağımsız çalışır. Sınırın yaklaştığını fark eder. Gerektiğinde soru sorar. Geçerli yetkisini aşmaz; ayrıca onay gerektiren bir eşiği insan onayı olmadan geçmez. Kendisine yeni haklar yaratmaz. Alt ajanlar üzerinden yetki aklamaz. İptal edilmiş erişimi kullanmaz.

Ve en önemlisi: Bir şeyi yapabildiği için yapması gerektiğini varsaymaz. Fakat doğru kimlik, gerçek yetenek, uygun seçim ve geçerli yetki bulunmasına rağmen işler yine de yanlış gidebilir. Bir sistem hata yapabilir. Dış hizmet kesilebilir. Kullanıcı fikrini değiştirebilir. Veri beklenmedik biçimde bozulabilir. Gönderilen mesaj yanlış anlaşılabilir. Yayımlanan sürüm teknik olarak geri alınsa bile insan ilişkilerinde iz bırakabilir.

Bu nedenle davranış sözleşmesinin son sorusu şudur:

Bir şey yanlış giderse ne olacak?

Bir sonraki bölümde durdurma, geri alma, itiraz, telafi, insanın kontrolü yeniden ele alması ve makinelerin yalnız eylem gerçekleştirmekle değil, eylemin sonucuyla da sorumlu tutulması gerektiğini inceleyeceğiz.

Yetki eylemi başlatır. Sorumluluk ise eylemden sonra da devam eder.