Yapay zekada insan onayı: hangi işlem onaysız ilerlemeli?

Bir yapay zeka ajanının şirket sistemlerinde işlem yapabilmesi, "Hangi işlemi kendi başına yapabilir, hangisinde bir insanın onayını beklemeli?" sorusunu kaçınılmaz kılar. Bu soruya verilen cevap, ajanın hem ne kadar faydalı hem de ne kadar güvenli olacağını belirler.

Okuma ve geri alınabilir dahili işlemler genellikle onaysız ilerleyebilir. Dışa dönük, finansal etkisi olan veya geri alınması zor işlemler insan onayına bağlanmalıdır. Arada kalan işlemler için tutar, müşteri tipi veya güven düzeyi gibi eşikler tanımlanır. Bu yaklaşıma human-in-the-loop (insan döngüde) denir.

Bu yazıda onay noktalarını belirlemek için kullanabileceğiniz bir risk matrisini, fiyat istisnası ve satın alma örnekleriyle onay eşiklerini ve bekleyen onayların nasıl takip edileceğini anlatıyoruz.

Neden her şeyi onaya bağlamıyoruz?

İlk bakışta en güvenli yaklaşım, ajanın her işleminde onay istemek gibi görünür. Pratikte bu üç sorun yaratır:

1. Onay yorgunluğu: Günde yüzlerce onay isteği alan bir kişi, bir süre sonra içeriği okumadan onaylamaya başlar. Onay, bir kontrol mekanizması olmaktan çıkar.
2. Kazanımın kaybolması: Ajanın hızlandırması beklenen iş, onay kuyruğunda bekler. Çalışanlar ajanı kullanmayı bırakır.
3. Sorumluluğun bulanıklaşması: Her şey onaylandığında, gerçekten riskli işlemler rutin işlemlerin arasında kaybolur.

Tersine, hiçbir işlemi onaya bağlamamak da açık bir risk taşır: yanlış anlaşılmış bir talep, hatalı bir veri veya beklenmeyen bir durum doğrudan müşteriye veya şirket kayıtlarına yansır.

Doğru tasarım, onayı riskin gerçekten bulunduğu yere yerleştirmektir.

Hangi işlemler onaysız ilerleyebilir?

Bir işlemin risk seviyesini belirlemek için dört soru sorun:

1. Geri alınabilir mi? Hata fark edildiğinde işlem kolayca düzeltilebilir mi?
2. Kimi etkiliyor? Yalnızca şirket içini mi, yoksa müşteri, tedarikçi veya kamuyu mu?
3. Maddi etkisi var mı? Para hareketi, fiyat değişikliği veya taahhüt içeriyor mu?
4. Hassas veri içeriyor mu? Kişisel veri, ticari sır veya gizli bilgi paylaşılıyor mu?

Risk matrisi

Bu sorulara göre işlemleri dört seviyede sınıflandırabilirsiniz:

Aynı işlem, farklı bağlam

Bir işlemin risk seviyesi her zaman sabit değildir. Aynı işlem bağlama göre farklı seviyelere düşebilir:

Onay noktası nasıl belirlenir?

Adım 1: İşlemleri listeleyin

Ajanın yapabileceği bütün işlemleri yazın. Her araç (CRM, ERP, e-posta, kargo) için hangi işlemlere erişimi olacağını belirleyin. Bu liste, ajanın yetki tanımının da temelidir.

Adım 2: Her işleme bir seviye atayın

Risk matrisini kullanarak her işleme varsayılan bir seviye verin.

Adım 3: Seviye 3 işlemler için eşikleri tanımlayın

Eşikler, işlemin onaysız ilerleyebileceği sınırları belirler. Eşik türleri:

• Tutar eşiği: "1.000 TL'nin altındaki iade kodları onaysız"
• Müşteri eşiği: "Kurumsal anlaşmalı müşterilerde her iletişim onaylı"
• Sıklık eşiği: "Aynı müşteriye 30 gün içinde ikinci iade onaylı"
• Güven eşiği: "Ajan talebi sınıflandırmada emin değilse onaylı"
• Şablon eşiği: "Onaylı şablon dışındaki her müşteri mesajı onaylı"

Adım 4: Onaycıları belirleyin

Her onay türü için kimin onay vereceğini ve bu kişi yoksa kimin devralacağını yazın. Onaycı belirsizse onay isteği kimsenin sorumluluğunda olmayan bir kuyrukta bekler.

Örnek: fiyat istisnası talebi

Aşağıdaki senaryo temsilidir; oranlar ve eşikler kurgusaldır.

Bir yapı malzemeleri toptancısında bayi, satış temsilcisine WhatsApp'tan yazıyor: "Bu ay 400 torba çimento alacağız, fiyat listesine göre yüzde 8 ek iskonto yapabilir misiniz?"

Temsilci talebi şirketin ajanına iletir. Ajan:

1. Bayinin son 6 aylık alımlarını CRM'den çeker.
2. Fiyat politikasında bu ürün grubu için temsilci yetkisinin yüzde 3, bölge müdürü yetkisinin yüzde 7 olduğunu bulur.
3. Talep edilen yüzde 8'in iki yetki seviyesini de aştığını tespit eder; politikaya göre bu durumda satış direktörü onayı gerekir.
4. Satış direktörüne bayinin alım geçmişi, talep edilen iskonto, politika maddeleri ve temsilcinin notunu içeren bir onay isteği hazırlar.
5. Temsilciye "Talep satış direktörü onayına gönderildi. Politikaya göre sizin yetkiniz yüzde 3, bölge müdürünüzün yüzde 7" bilgisini verir.

Ajan burada iskonto kararı vermedi; kararın kime ait olduğunu buldu ve karar vericiyi hazırlıklı hâle getirdi.

Bekleyen iş nasıl takip edilir?

Onay mekanizmasının en zayıf halkası genellikle onayın kendisi değil, bekleyen onaylardır. Bir onay isteği gönderildikten sonra ne olduğu bilinmezse, süreç sessizce durur.

Bekleyen onaylar için beş kural

1. Tek bir görünüm: Bütün bekleyen onaylar tek bir listede görünmeli. Onaycı e-posta, sohbet ve sistem bildirimleri arasında dağılmış istekleri takip etmek zorunda kalmamalı.
2. Bağlam: Onay isteği, karar için gereken bütün bilgiyi içermeli: talep, gerekçe, ilgili kayıtlar, politika maddesi, ajanın önerisi.
3. Hatırlatma: Belirli bir süre içinde yanıtlanmayan onaylar için hatırlatma gönderilmeli.
4. Vekâlet ve üst seviye: Onaycı izinde veya ulaşılamıyorsa onay vekile veya üst yöneticiye geçmeli.
5. Talep sahibine görünürlük: Talep sahibi, talebinin hangi onayda beklediğini görebilmeli.

Örnek zaman kuralları

Onay kaydı

Her onay veya ret kararı şu bilgilerle kaydedilmelidir:

• Onay istenen işlem ve parametreleri
• Onaya sunulan bilgi (özet, kaynaklar)
• Onaycı ve karar zamanı
• Karar ve varsa gerekçe
• İşlemin sonucu

Bu kayıt; iç denetimde, müşteri itirazlarında ve ajanın iyileştirilmesinde kullanılır. Örneğin sürekli onaylanan bir işlem türü, eşiğin gözden geçirilmesi gerektiğini gösterebilir; sürekli reddedilen bir işlem türü ise ajanın talebi yanlış yorumladığını.

Onay tasarımı için kontrol listesi

• Ajanın yapabileceği bütün işlemler listelendi
• Her işleme risk seviyesi atandı
• Seviye 3 işlemler için eşikler tanımlandı
• Seviye 4 işlemlerin tamamı onaya bağlandı
• Her onay türünün onaycısı ve vekili belirlendi
• Hatırlatma ve üst seviyeye taşıma süreleri yazıldı
• Onay isteğinin içereceği bilgiler belirlendi
• Onay ve ret kararlarının kaydedildiği doğrulandı
• Eşiklerin ne sıklıkla gözden geçirileceği kararlaştırıldı

ajan.io'da onay noktaları

ajan.io'da ajanların kullanabileceği işlemleri tanımlarken, seçtiğiniz adımlar için onay isteyebilirsiniz. İş akışlarında insan onayı ayrı bir adım olarak yer alır; bekleyen onaylar ve akışın durumu izlenebilir. Ajanın yaptığı işlemler kayıt altında tutulur. Onay kapsamını siz belirlersiniz; platform bütün işlemleri kendiliğinden onaya bağlamaz.

Kontrollü iş akışlarının örneklerini İş akışları sayfasında, kurumsal kontrol başlıklarını Platform sayfasında bulabilirsiniz.

Sık sorulan sorular

Human-in-the-loop ne demek?

Human-in-the-loop (insan döngüde), yapay zeka sisteminin belirli kararlarda veya işlemlerde bir insanın onayını, düzeltmesini veya girdisini beklediği tasarım yaklaşımıdır. Amaç, yapay zekanın hızından yararlanırken kritik kararların sorumluluğunu insanda tutmaktır.

Onay eşiklerini ne sıklıkla gözden geçirmeliyiz?

İlk kurulumdan sonraki birkaç ay içinde, onay kayıtları birikmeye başladığında bir gözden geçirme yapmak faydalıdır. Sürekli onaylanan işlemler ve sürekli reddedilen işlemler, eşiklerin ayarlanması gerektiğine işaret eder. Sonrasında politika değişikliklerinde veya belirli aralıklarla gözden geçirme yeterlidir.

Ajan onay beklerken kullanıcı ne görür?

İyi bir tasarımda kullanıcı, talebinin onayda olduğunu, kimin onayını beklediğini ve yaklaşık ne zaman sonuç alacağını görür. Onay geldiğinde veya talep reddedildiğinde bilgilendirilir. Bu görünürlük, kullanıcının aynı talebi farklı kanallardan tekrar göndermesini önler.

Bütün müşteri mesajlarını onaya bağlamalı mıyız?

Genellikle hayır. Kargo durumu veya randevu hatırlatması gibi önceden onaylanmış şablonlara dayanan mesajlar onaysız gönderilebilir. Şikâyet cevapları, tazminat teklifleri veya şablon dışındaki hassas iletişim ise onaylı olmalıdır. Hangi mesajların şablona bağlanacağı, müşteri hizmetleri yönetimiyle birlikte belirlenmelidir.