Human in the loop nedir, yapay zekâ ajanlarında neden gerekir?
Yapay zekâ ajanı, bir dil modelinin yalnızca metin üretmekle kalmayıp araç çağırarak iş yaptığı sistemdir: sipariş kaydını okur, müşteriye e-posta yazar, iade başlatır, bir dosyayı siler. "Human in the loop" ya da Türkçesiyle insan onayı, ajanın önerdiği bir eylemin, gerçekleşmeden önce yetkili bir kişinin kararına bağlanmasıdır. Amaç ajanı yavaşlatmak değil; hatası pahalıya patlayacak ya da geri alınamayacak eylemlerde son sözü bir insana bırakmaktır.
OWASP'ın büyük dil modeli uygulamaları risk listesinde bu konu aşırı ajans (excessive agency) başlığıyla geçer: ajana gereğinden fazla işlev, yetki ya da özerklik vermek. Önerilen önlemlerden biri, etkisi yüksek eylemlerde insan onayı istemektir. Model bir belgedeki gizli talimatla yönlendirilmiş, yanlış müşteriyi seçmiş ya da tutarı yanlış okumuş olabilir. Onay adımı bu hatanın dış dünyaya ulaşmadan yakalandığı yerdir.
Hangi eylemler onay gerektirir?
Her eylemi onaya bağlamak, inceleyen kişiyi kısa sürede "onayla" düğmesine basan birine dönüştürür. Bunun yerine araçları etkisine göre sınıflandırın:
| Eylem | Örnek | Öneri |
|---|---|---|
| Yalnızca okuma | Sipariş durumunu sorgulamak | Otomatik |
| Taslak üretme | Yanıt e-postası taslağı hazırlamak | Otomatik, gönderim ayrı adım |
| Dışarıya iletişim | Müşteriye e-posta göndermek | Onay ya da önceden onaylı şablon |
| Kayıt değiştirme | CRM'de adres güncellemek | Tutar ve alana göre onay |
| Para hareketi | İade veya ödeme başlatmak | Her zaman onay, eşik üstünde iki kişi |
| Geri alınamaz | Kayıt veya dosya silmek | Her zaman onay |
Sınırı tutar, geri alınabilirlik, etkilenen kişi sayısı ve mevzuat belirler. Kişisel veriyi değiştiren ya da paylaşan eylemlerde KVKK kapsamındaki yükümlülükler de bu sınıflandırmaya girer. Hangi kimliği doğrulanmış rolün öneri yapabildiğini, hangisinin onay verebildiğini ayrıca tanımlayın; aynı kişinin hem önerip hem onaylaması kritik eylemlerde engellenmelidir.
Onay neden sunucuda zorlanmalı?
En sık yapılan hata, onayı modele verilen bir talimat olarak bırakmaktır: "İade yapmadan önce kullanıcıdan onay al." Model bu talimatı atlayabilir, yanlış anlayabilir ya da bir belgedeki saldırı metniyle yok saymaya ikna edilebilir. Onay, modelin dışında, eylemi uygulayan sunucu kodunda bir kapı olmalıdır: araç çağrısı onaylı bir kayıt olmadan hiç çalışmaz.
Ajan çatıları bunun için yapı sunar. Örneğin LangGraph'ta akış, onay gereken noktada interrupt ile durdurulur; durum bir kayıt deposuna yazılır ve karar geldiğinde kaldığı yerden devam eder. Hangi çatıyı kullanırsanız kullanın, onay kaydını kendi veritabanınızda tutmanız ve uygulamayı ona bağlamanız gerekir.
Onay için durum makinesi kurun
Her eylem isteğini açık durumlarla izleyin: önerildi, bekliyor, onaylandı, reddedildi, süresi doldu, uygulandı, başarısız. Her kayıtta şunlar bulunsun:
- Kalıcı eylem kimliği ve oluşturma zamanı.
- Hedef (sipariş, müşteri, dosya) ve tam parametreler: tutar, para birimi, alıcı.
- Öneriyi yapan ajan oturumu ve dayandığı kanıtlar: kaynak kayıtlar, ilgili politika maddesi.
- Risk gerekçesi: bu eylem neden onaya düştü.
- Onaylayan kişi, karar, karar zamanı ve varsa gerekçe.
Uygulayıcı kod, onayın tam olarak aynı değişmez eylem yüküne ait olduğunu doğrulasın. Ajan tutarı ya da alıcıyı değiştirirse bu yeni bir öneridir ve yeni onay ister. Onaylara bir son kullanma süresi koyun; dün verilen onay, bugün değişmiş bir hesap ya da belge üzerinde yetki sayılmamalıdır.
Örnek: hasarlı kargo için iade
Ajan bir müşteri şikâyetini inceliyor: kargo hasarlı gelmiş, fotoğraf ve kargo kaydı var. Politika, 50 avronun altındaki hasar iadelerinin destek ekibince, üstündekilerin ise ekip lideriyle birlikte onaylanmasını söylüyor. Ajan siparişin özgün ödeme yöntemine 40 avro iade öneriyor. İnceleme ekranında sipariş kimliği, tutar, para birimi, gerekçe, fotoğraf, kargo kaydı ve ilgili politika maddesi yan yana görünüyor. Destek çalışanı onaylıyor; ajan onaydan sonra öneriyi değiştiremiyor.
Uygulama, ağ hatası yüzünden istek tekrarlanırsa ikinci bir iade oluşmasın diye onaylı eylem kimliğini tekrara dayanıklı bir istek anahtarı olarak ödeme sağlayıcısına gönderiyor. Başarı mesajıyla yetinilmiyor; ödeme sağlayıcısındaki son durum sorgulanıp kayıtla eşleştiriliyor. Aynı ajan 120 avroluk bir iade önerdiğinde ise kayıt iki onaylı akışa düşüyor ve ikinci onay gelmeden süre dolarsa öneri kendiliğinden kapanıyor.
İyi bir onay ekranında neler olmalı?
İnceleyen kişi yalnızca ekranda gördüğü kadar iyi karar verebilir. AB Yapay Zekâ Yasası, yüksek riskli sistemler için insan gözetimini düzenleyen 14. maddesinde, gözetimi yapan kişinin sistemin çıktısına aşırı güvenme eğilimine, yani otomasyon yanlılığına karşı farkında olmasını ve gerektiğinde çıktıyı göz ardı edip sistemi durdurabilmesini ister. Ajanınız yüksek riskli sınıfta olmasa bile bu ilkeler iyi bir ekranı tarif eder:
- Eylemin kendisi, insanın okuyacağı dilde: "Sipariş 48213 için 40 EUR iade, özgün karta."
- Ajanın gerekçesi ve dayandığı kaynaklar, tıklanabilir bağlantılarla.
- Eylemin neden onaya düştüğü: tutar eşiği, kişisel veri, geri alınamazlık.
- Onayla, reddet ve gerekçe yaz seçenekleri; tek tıkla toplu onay yok.
- Eylemi ve aynı türdeki bekleyenleri durdurma seçeneği.
Yüksek riskli sistemlere ilişkin kuralların takvimini AB Yapay Zekâ Yasası 2026 takvimi yazımızda ele alıyoruz.
Ret, hata ve tekrar denemeleri
Ret gerekçesi iş akışına geri dönsün, ama modele aynı eylemi başka bir adla yeniden deneme yolu açmasın. Başarısız bir uygulama yalnızca araç sözleşmesi güvenli tekrarı garanti ediyorsa yinelensin. Dış hizmet zaman aşımına uğrasa bile işlemi yapmış olabilir; yeniden denemeden önce durumunu sorgulayın. Öneri, inceleyen, karar, uygulama sonucu ve sonradan yapılan düzeltmelerin kaydını tutun. OWASP'ın yapay zekâ ajanı güvenlik rehberi en az yetki, izleme ve araç kullanımı etrafında açık sınırlar için daha geniş bir çerçeve verir.
İnceleme kalitesini ölçün
Onay adımının gerçekten işe yarayıp yaramadığını şu göstergelerle izleyin:
- Onay oranı: Önerilerin yüzde kaçı onaylanıyor? Neredeyse hepsi anında onaylanıyorsa ya ekran yetersizdir ya da bu eylem otomatiğe alınabilir.
- Karar süresi: Ortanca ve en yavaş yüzde 10'luk dilim. Uzun bekleyen onaylar müşteri deneyimini bozar.
- Ret gerekçeleri: En sık nedenler, ajanın hangi konuda yanıldığını gösterir.
- Onay sonrası olaylar: Onaylandığı hâlde yanlış çıkan eylemler, inceleme ekranındaki eksikleri gösterir.
- Yetkisiz uygulama denemeleri: Onaysız çalıştırılmaya çalışılan araç çağrıları sıfır olmalıdır.
Düşük riskli rutin eylemler çoğunluktaysa politikayı gözlenen veriye dayanarak bilinçli olarak değiştirin. Model güvenli konuşuyor diye bir eylemi sessizce otomatiğe almayın.
Sık yapılan hatalar
- Onayı yalnızca modele verilen talimatla sağlamak.
- İnceleyiciye eylemin özetini gösterip tam parametreleri göstermemek.
- Onaydan sonra ajanın eylemi değiştirmesine izin vermek.
- Onaylara süre sınırı koymamak.
- Her şeyi onaya bağlayıp inceleyiciyi yormak, sonra toplu onaya geçmek.
Hatson Tech bunu nasıl kuruyor?
Onay kuyrukları, inceleme ekranları ve denetim kayıtları, bir ajanı canlıya almanın ayrılmaz parçalarıdır. Bunları ajanların çevresine nasıl kurduğumuzu yapay zekâ ajanı geliştirme sayfamızda anlatıyoruz. Ajanları üretim ortamında çalıştırmanın maliyet, izleme ve hata yönetimi tarafı için üretimde yapay zekâ ajanları rehberimize, temel kavramlar için yapay zekâ ajanları nedir yazımıza bakabilirsiniz. Bu yaklaşımı uygulamadan önce kaynakları kendi süreçleriniz, yetkileriniz ve kullandığınız ürün sürümleriyle karşılaştırın.