Ajan akışlarına insan onayı (human-in-the-loop) ekleme

İnsan onayı neden gerekir?

Yapay zeka ajanları araç çağırabilir, veri yazabilir, e-posta gönderebilir, ödeme başlatabilir. Model çıktısı çoğu zaman doğrudur, ama yanlış anlama, eksik bağlam ya da kötü niyetli girdi yüzünden hatalı bir eylem de üretebilir. Eylemin sonucu geri alınamaz ya da maliyetliyse, hatanın bedelini son kullanıcı veya kurum öder.

İnsan onayı (human-in-the-loop) bu riski, otomasyondan vazgeçmeden yönetmenin yoludur. Ajan, işin büyük kısmını kendi yürütür; yalnız belirlenen kritik noktalarda durur, durumu bir insana sunar ve devam etmek için onay, düzeltme ya da ret yanıtı bekler. Amaç her adımı insana göstermek değildir; doğru yerde, doğru bilgiyle, doğru kişiye sormaktır.

Hangi eylemler onaya bağlanmalı?

İlk iş, eylemleri risk düzeyine göre sınıflandırmaktır. Yaygın bir yaklaşım şöyledir:

• Salt okunur eylemler: veri sorgulamak, belge okumak, arama yapmak. Genellikle onaysız bırakılabilir; ancak hassas veriye erişim ayrıca değerlendirilir.
• Geri alınabilir yazma eylemleri: taslak oluşturmak, kayıt etiketlemek, iç not eklemek. Düşük risklidir; sonradan denetimle yetinilebilir.
• Geri alınması zor ya da dış etkili eylemler: müşteriye e-posta göndermek, kayıt silmek, sözleşme güncellemek, ödeme ve iade yapmak, izin değiştirmek. Bunlar onay kapısının asıl alanıdır.

Sınıflandırma, yalnız eylem türüne değil bağlama da bakmalıdır. Aynı iade eylemi küçük tutarda otomatik, belirli bir eşiğin üzerinde onaya bağlı olabilir; eşik değerleri kurumun risk politikasından gelir. Model belirsizlik belirtiyorsa ya da araç çıktısı beklenmedikse de akışın insana devredilmesi iyi bir tetikleyicidir.

Onay adımı nasıl tasarlanır?

İyi bir onay adımı, onaycının karar vermek için ihtiyaç duyduğu her şeyi tek bakışta sunar:

• Ajanın yapmak istediği eylem, hedef sistem ve tam parametreler (kime, ne, hangi içerikle).
• Eylemin gerekçesi: ajan hangi bilgiye dayanarak bu sonuca vardı?
• Etki özeti: ne değişecek, geri alınabilir mi?
• Seçenekler: onayla, düzenleyerek onayla, reddet ve gerekçe yaz.

Düzenleyerek onaylama özellikle değerlidir. Onaycı, ajanın hazırladığı e-posta taslağındaki bir cümleyi değiştirir ve gönderimi sürdürür; böylece ret ve baştan yazma döngüsüne gerek kalmaz. Ret kararı da ajana geri bildirim olarak döner: ajan nedenini okuyup alternatif öneri üretebilir. Onay arayüzü, ajanın çalıştığı ortamda (sohbet, e-posta, iş takip aracı) bulunmalı; onaycının ayrı bir panele gitmesi gecikme yaratır.

Beklerken durumu korumak

Onay beklemek, akışın uzun süre duraklaması anlamına gelebilir. Onaycı dakikalar ya da saatler sonra yanıt verebilir. Bu nedenle akışın durumu kalıcı biçimde saklanmalıdır: hangi adımdaydı, hangi ara sonuçlar vardı, hangi eylem onay bekliyor. Yanıt geldiğinde akış bellekten değil, saklanan durumdan devam eder.

Bekleme için de kurallar gerekir. Yanıt gelmezse ne olur? Yaygın seçenekler: süre dolunca hatırlatma göndermek, ikinci bir onaycıya yükseltmek veya eylemi iptal edip kullanıcıya bildirmek. Süre aşımında eylemin otomatik onaylanması güvenlik açısından genelde tercih edilmez. Ayrıca onay verildiğinde bağlamın değişmediğini doğrulamak gerekir: arada kayıt güncellenmişse ya da müşteri siparişi iptal etmişse, eski onay geçersiz sayılmalıdır.

Örnek senaryo: iade talebi işleyen ajan

Örneğin bir e-ticaret şirketinde iade taleplerini işleyen bir ajan var. Talebi okur, sipariş ve kargo kayıtlarını sorgular, politikaya uygunluğu kontrol eder. Bu adımlar salt okunurdur ve onay gerektirmez.

İade tutarı belirlenen eşiğin altında ve politikaya tam uygunsa ajan iadeyi kendisi başlatır; işlem kayda geçer ve sonradan örnekleme yoluyla denetlenir. Tutar eşiği aşıyorsa ya da talep politika dışıysa ajan durur, onaycıya talep özetini, gerekçesini ve önerdiği kararı sunar. Yetkili çalışan onaylar, düzeltir veya reddeder. Reddedilen vakalar, ajanın talimatlarını iyileştirmek için bir geri bildirim havuzuna eklenir. Böylece insan, hem güvenlik katmanı hem de sistemin öğrenme kaynağı olur.

Denetim izi ve onay yorgunluğu

Onay mekanizması, kimin neyi ne zaman onayladığını kaydetmeden eksiktir. Kayıtta ajanın önerisi, onaycının kararı, yapılan düzenlemeler ve nihai eylem yer almalıdır. Bu iz, hem olay sonrası inceleme hem de uyum denetimleri için temel kanıttır.

Bir diğer tehlike onay yorgunluğudur. Her küçük eylem için onay isteyen sistem, onaycıyı otomatik tıklamaya iter ve kontrol aslında işlevsizleşir. Çözüm, onay kapılarını seyrek ama anlamlı tutmak, benzer talepleri toplu onaya sunmak ve düşük riskli eylemleri sonradan örneklemeli denetimle izlemektir. Onay oranlarını izlemek de yararlıdır: neredeyse her zaman onaylanan bir kapı otomasyona alınabilir; sık reddedilen bir kapı ise ajanın talimatlarının ya da yetkilerinin gözden geçirilmesi gerektiğini gösterir.

Sık yapılan hatalar

Birinci hata, onayı yalnızca arayüz düzeyinde bırakmaktır: ajan, onay ekranı atlanabilen bir araçla doğrudan işlem yapabiliyorsa kontrol işlevsizdir. Onay, aracın kendisine, yani eylem katmanına bağlanmalıdır. İkinci hata, onaycıya yetersiz bilgi göstermektir; ham araç çıktısı yerine anlaşılır bir özet sunulmalıdır.

Üçüncü hata, onay ve yetki sınırlarını birbirinden ayırmamaktır. Ajanın hesabı zaten gereğinden geniş izinlere sahipse, onay adımı tek koruma hattı olur. En az ayrıcalık ilkesi ile onay kapıları birlikte tasarlanmalıdır. Son olarak, onay akışını test etmemek sık görülür: ret, süre aşımı, çift tıklama ve bağlam değişimi gibi uç durumlar önceden denenmelidir.

Mindset programlarında nerede çalışılır?

Mindset kataloğunda Agentic Workflows Mimarisi eğitiminin modül başlıkları arasında Güvenlik, Yönetişim ve Uyum ile Durum Yönetimi ve Kalıcılık bulunur. Yapay Zeka Ajanları ile Kurumsal Otomasyon eğitiminde ise Üretim Ortamında Ajan Yönetimi ve Kurumsal Süreç Analizi ve Otomasyon Haritası başlıkları yer alır.

Bu içerik, otomasyon sorumluları, yazılım ekipleri ve süreç sahipleri için uygundur; kurumsal ekiplerde hangi süreçlerin hangi onay düzeyine bağlanacağı sorusunu birlikte ele almak isteyen gruplara da yarar.