Yapay Zekâya Ne Kadar Yetki Vermeliyiz?

💡 Özet: Ana Çıkarımlar

• Bir modelin doğru işlemi önermesi, o işlemi yapmaya yetkili olduğu anlamına gelmez. İş kuralları ve erişim kontrolleri, öneri gerçek işleme dönüşürken ayrıca uygulanmalıdır.
• Taslak, ön izleme ve gerçek işlem farklı risk taşır. Modele verilecek hareket alanı, işlemin para, müşteri, erişim veya dış iletişim üzerindeki etkisine göre daraltılmalıdır.
• İnsan onayı ancak kararı değiştirebiliyorsa gerçektir. İşlemler tekrar denemelerde çoğalmamalı ve sonuç, modelin cevabından değil değişikliğin tutulduğu yetkili kaynaktan doğrulanmalıdır.

Bir müşteri destek sistemi, müşterinin iki kez tahsil edilen siparişi için iade istediğini anlıyor. Sipariş kaydını buluyor, iade tutarını hazırlıyor ve müşteriye “İadeniz yapıldı” diye cevap veriyor.

Bu cümle doğru olabilir. Fakat tek başına hiçbir işlemin yapıldığını göstermez.

Model müşterinin talebini doğru anlamış olabilir. Sipariş gerçekten iadeye uygun olabilir. İade tutarı doğru hesaplanmış olabilir. Yine de bu müşterinin o sipariş için talepte bulunmaya yetkili olup olmadığı, iadenin şirket politikasına uyup uymadığı ve ödeme sisteminde gerçekten gerçekleşip gerçekleşmediği ayrı ayrı kontrol edilmelidir.

Bir modelin doğru işlem önermesiyle şirket adına o işlemi yapabilmesi aynı karar değildir.

Bir işlemi önermek, o işlemi yapmaya yetmek değildir

Bir dil modeli artık yalnızca metin üretmiyor. Sipariş sisteminden kayıt okuyabilir, e-posta hazırlayabilir, takvime toplantı ekleyebilir veya bir erişim yönetimi sistemine talep gönderebilir. Modelin bağlandığı bu API ve yazılım işlevlerine genellikle araç deniyor.

Araca erişebilmek ise yetki sahibi olmak anlamına gelmez.

Bir satış asistanı müşteriye gönderilecek e-postayı hazırlayabilir. Hatta CRM kaydından doğru kişiyi de bulabilir. Fakat mesajın kimin adına gönderileceği, alıcının doğru kişi olup olmadığı ve hangi müşteri bilgisinin dışarı çıkabileceği modelin serbestçe vereceği kararlar değildir.

Aynı ayrım çalışan erişimlerinde daha görünür hâle gelir. Model yeni çalışanın görevine bakıp ihtiyaç duyabileceği sistemleri önerebilir. Finans sisteminde yönetici yetkisi vermek ise önerinin doğal devamı sayılmaz. Şirketin erişim politikası, yöneticinin onayı ve mevcut rol sınırları ayrıca uygulanmalıdır.

OWASP, AI sistemlerindeki “aşırı yetki” riskini tam olarak bu nedenle yalnızca model davranışı üzerinden tanımlamıyor. Aracın yapabildiklerini, sahip olduğu izinleri ve kendi başına hareket edebildiği alanı ayrı ayrı sınırlamayı öneriyor.

Taslak, ön izleme ve gerçek işlem aynı riskte değildir

Bir satın alma sistemi, tedarikçi tekliflerini karşılaştırıp satın alma emri taslağı hazırlayabilir. Bu taslak bütçe kodunu, miktarı ve teslimat koşullarını gösterebilir. Şirket henüz tedarikçiye karşı bir taahhüde girmiş olmaz.

Bir sonraki adım ön izleme olabilir. Sistem, işlem yapılırsa hangi bütçenin kullanılacağını ve hangi kaydın değişeceğini gösterir. Yetkili kişi neye onay verdiğini görür.

Satın alma emri ERP'de kesinleşip tedarikçiye iletildiğinde ise dış dünyada sonuç doğuran bir işlem gerçekleşir. Aynı model üç aşamada da yardımcı olabilir. Fakat her aşamada aynı hareket alanına sahip olması gerekmez.

Bu ayrım, sistemi her işlem için insan bekleyen ağır bir onay zincirine dönüştürmek için yapılmıyor. İç not taslağı hazırlamakla para iadesi yapmak, müşteriye e-posta göndermekle şirket adına resmî başvuru yapmak aynı riskte değildir. Yetki, işlemin gerçek etkisine göre daraltılmalıdır.

Mevcut yetkilendirme doğru sınırda çalışmalı

Şirketlerin bunun için ayrı bir “AI yetkilendirme sistemi” kurması şart değil. Mevcut uygulama zaten kullanıcının hangi müşteri kaydını görebildiğini, ne kadar iade yapabildiğini veya hangi bütçeden harcama yapabildiğini güvenilir biçimde denetliyorsa aynı kontroller kullanılabilir.

Önemli olan kontrolün, modelin önerisi gerçek işleme dönüşürken uygulanmasıdır. Prompt içine “yalnızca yetkili işlemleri yap” yazmak bu kontrolün yerini tutmaz.

İnsan onayı ancak kararı değiştirebiliyorsa kontroldür

Riskli bir işlemin önüne onay düğmesi koymak güven verici görünür. Fakat onay veren kişi yalnızca modelin hazırladığı kısa özeti görüyorsa, yüzlerce talebi hızla geçmesi bekleniyorsa veya işlemi durduracak yetkisi yoksa gerçek bir kontrol kurulmuş sayılmaz.

İade örneğinde temsilci en azından müşteriyi, siparişi, tutarı, iade gerekçesini ve politikanın hangi koşulunun karşılandığını görebilmelidir. Yanlışlık varsa tutarı değiştirebilmeli, işlemi reddedebilmeli veya başka birine aktarabilmelidir. Üstelik bunu iade yapıldıktan sonra değil, para hareketinden önce yapmalıdır.

OpenAI'ın bilgisayar kullanabilen modeller için yayımladığı güvenlik rehberi de hassas işlemlerde onayın riskin ortaya çıktığı anda alınmasını öneriyor. Bir kullanıcının genel hedefi söylemiş olması, sonradan karşılaşılan her alıcıya, dosyaya veya işleme peşinen izin verdiği anlamına gelmiyor.

Her işlem için insan onayı istemek de iyi bir varsayılan değil. Düşük etkili ve kolayca izlenebilen işler açık kurallarla otomatik ilerleyebilir. İnsan dikkatini her küçük adıma dağıtırsanız gerçekten önemli onaylar da alışkanlıkla geçilmeye başlar.

Aynı talep ikinci kez işlem yaratmamalı

İade talebi ödeme sistemine gönderildikten sonra bağlantı kesilebilir. Destek sistemi yanıt alamadığı için işlemin başarısız olduğunu sanıp aynı isteği tekrar gönderirse müşteriye iki kez para iadesi yapılabilir.

Bu sorun AI ile başlamadı. Ödeme, sipariş ve rezervasyon sistemleri yıllardır aynı belirsizlikle uğraşıyor. Çözüm de modele “dikkatli ol” demek değildir. Sistem aynı iş niyetini tanıyan bir işlem kimliği kullanmalı, tekrar gelen talebi yeni bir işlem gibi çalıştırmamalı ve sonucu ödeme kaydından kontrol etmelidir.

AWS'nin güvenli tekrar denemeleri üzerine mühendislik notu, istemcinin aynı talebi yeniden gönderdiğinde ek bir sonuç oluşmaması için bu niyetin açık bir kimlikle taşınmasını öneriyor. Modelin iade talebini hazırlaması bu işlem kuralını değiştirmiyor.

Her işlemi geri almak da mümkün değildir. Yanlış erişim kaldırılabilir. Yanlış rezervasyon bazen iptal edilebilir. Müşteriye gönderilmiş bir e-posta veya kuruma yapılmış resmî başvuru ise sonradan düzeltilebilir ama hiç yapılmamış hâle getirilemez. Bu nedenle sistemin “geri alabiliriz” dediği yerde gerçekten neyin geri alınabildiği açık olmalıdır.

Başarılı araç çağrısı, tamamlanmış iş değildir

Model doğru aracı seçmiş, doğru alanları doldurmuş ve araç “başarılı” cevabı vermiş olabilir. İşin tamamlandığını yine de asıl kaynaktan doğrulamak gerekir.

İade için ödeme sağlayıcısındaki işlem kimliği ve sipariş sistemindeki güncel kayıt kontrol edilebilir. E-posta için gönderim kaydı, erişim yetkisi için kimlik sistemindeki rol, satın alma emri için ERP'deki kesin durum doğrulanabilir.

RAG yazısında doğru bilginin hangi kaynaktan alınacağını ayırmıştım. İşlem tarafında da benzer bir kural var: Sistemin ne söylediğine değil, değişikliğin yaşadığı yetkili kaynağa bakmak gerekir.

Yapay zekâ sisteminin hareket alanını belirlerken asıl karar “modele güveniyor muyuz?” değildir. Hangi aşamada öneri hazırladığını, hangi aşamada şirket politikalarının devreye girdiğini, işlemi kimin yetkisiyle yaptığını ve sonucun nereden doğrulanacağını ayrı ayrı belirlemek gerekir.

Model geniş bir muhakeme alanına sahip olurken dar bir işlem yetkisiyle çalışabilir. Bu bir çelişki değil. İşletme içinde güvenilir biçimde hareket edebilmesinin koşuludur.

Modelin yalnızca cevap üretmek yerine sıradaki adımı da seçtiği sistemlerde workflow ile agent arasındaki farkı önceki yazıda ele aldım.

Model, bilgi, yetki ve ölçümle ilgili diğer kararları yapay zekâ sistemi tasarlama rehberinde bir arada görebilirsiniz.