Yapay zeka ajanları artık e-posta göndermekten finansal işlem yapmaya kadar pek çok kritik görevi üstleniyor. Ancak her kararı otomatikleştirmek, ciddi hatalara kapı aralayabilir. Ajanın hangi durumda insan onayı istemesi gerektiğini belirleme süreci, hem güvenliği hem de verimliliği doğrudan etkileyen stratejik bir tasarım kararıdır. Yanlış yapılandırılmış bir ajan, ya sürekli onay isteyerek iş akışını tıkar ya da hiç sormadan riskli adımlar atar.
Kilit Çıkarım: İnsan onayı (Human-in-the-Loop) mekanizması, ajanın özerklik seviyesiyle doğru orantılı şekilde tasarlanmalıdır. Ne çok gevşek ne çok sıkı—tam ortası.
Başlamadan Önce
Ajan sistemine onay mekanizması eklemeden önce bazı hazırlıkları tamamlaman gerekiyor. Eksik bir altyapıyla başlamak, sonradan ciddi refaktör maliyeti çıkarır.
Gerekenler
- Çalışan bir LLM tabanlı ajan altyapısı (LangChain, AutoGen, CrewAI vb.)
- Onay iş akışı için bildirim kanalı (Slack, e-posta, webhook)
- Eylem loglama sistemi (hangi aksiyonun ne zaman tetiklendiğini kaydetmek için)
- Rol tabanlı yetkilendirme yapısı (kim neyi onaylayabilir?)
Ön Koşullar
- Ajanın gerçekleştireceği tüm aksiyonların listesi çıkarılmış olmalı
- Her aksiyonun potansiyel etki seviyesi belirlenmiş olmalı
- Onay beklerken ajanın nasıl davranacağı (timeout, fallback) planlanmış olmalı
Onay Gerektiren Durumları Belirleme Kriterleri
Her aksiyon için “Bu işlem geri alınabilir mi?” sorusuyla başla. Geri alınamayan işlemler, varsayılan olarak onay kapsamına girmeli. Ancak tek kriter bu değil.
Risk Matrisi Oluşturma
Pratikte en sık kullanılan yöntem, aksiyonları iki eksende değerlendirmektir: Etki Büyüklüğü ve Geri Dönüşüm Zorluğu.
| Aksiyon Türü | Etki Seviyesi | Geri Alınabilir mi? | Onay Gerekli mi? |
|---|---|---|---|
| Bilgi sorgulama (read-only) | Düşük | Evet | Hayır |
| Taslak oluşturma | Düşük | Evet | Hayır |
| E-posta gönderme | Orta | Hayır | Evet |
| Dosya silme | Yüksek | Zor | Evet |
| Finansal işlem | Kritik | Hayır | Kesinlikle Evet |
| API anahtarı oluşturma/silme | Kritik | Hayır | Kesinlikle Evet |
| Kullanıcı yetkisi değiştirme | Kritik | Evet ama riskli | Kesinlikle Evet |
Pro İpucu: Yeni bir aksiyon eklediğinde, varsayılan olarak “onay gerekli” modunda başlat. Güven oluştukça gevşetebilirsin. Tersi çok daha tehlikeli.
Adım Adım Onay Mekanizması Kurulumu
Aşağıdaki adımlar, çoğu ajan framework’ünde uygulanabilir genel bir yaklaşım sunuyor. Spesifik implementasyon, kullandığın araca göre değişecektir.
- Aksiyon envanteri çıkar: Ajanın erişebildiği tüm tool’ları ve fonksiyonları listele. Her birinin ne yaptığını tek cümleyle tanımla.
- Risk kategorileri ata: Yukarıdaki matrisi kullanarak her aksiyona “Düşük”, “Orta”, “Yüksek” veya “Kritik” etiketi ver.
- Onay eşiklerini belirle: Hangi kategoriden itibaren onay isteneceğine karar ver. Başlangıç için “Orta ve üzeri” mantıklı bir tercih.
- Onay iş akışını tasarla: Ajan onay istediğinde bildirim nereye gidecek? Kim onaylayacak? Timeout süresi ne kadar?
- Fallback senaryolarını kodla: Onay gelmezse ajan ne yapacak? İşlemi iptal mi edecek, yoksa alternatif bir yol mu deneyecek?
- Loglama ve audit trail ekle: Her onay talebi, onay/red kararı ve gerekçesi kayıt altına alınmalı.
- Test et ve iterate et: Gerçek senaryolarla test yap. Çok fazla onay talebi geliyorsa eşikleri ayarla.
Dinamik Onay: Bağlama Göre Karar Verme
Statik kurallar her zaman yeterli olmaz. Bazı durumlarda aynı aksiyon, bağlama göre farklı risk taşır.
Bağlamsal Faktörler
- Tutar eşikleri: 100 TL’lik ödeme otomatik, 10.000 TL’lik ödeme onaylı.
- Alıcı güvenilirliği: Daha önce iletişim kurulan kişiye e-posta otomatik, yeni alıcıya onaylı.
- Zaman hassasiyeti: Mesai saatleri dışında yapılan kritik işlemler ekstra onay gerektirebilir.
- Ardışık işlem sayısı: Kısa sürede çok sayıda benzer işlem, anomali olarak işaretlenebilir.
Mini Senaryo: Diyelim ki ajanın müşteri destek e-postalarını yanıtlıyor. Standart bir “Siparişiniz kargoya verildi” mesajı için onay gerekmez. Ama ajan “İade talebiniz onaylandı, 500 TL hesabınıza aktarılacak” gibi finansal taahhüt içeren bir yanıt üretirse? İşte o noktada insan denetimi devreye girmeli.
Yaygın Hatalar ve Kaçınılması Gerekenler
Onay mekanizması kurarken sık yapılan hatalar, sistemin ya işlevsiz kalmasına ya da kullanıcı deneyimini mahvetmesine yol açar.
- Her şeyi onaya bağlamak: “Onay yorgunluğu” yaratır. Kullanıcılar düşünmeden onaylamaya başlar, mekanizma anlamsızlaşır.
- Onay süresini belirsiz bırakmak: Timeout olmadan bekleyen ajan, iş akışını tamamen durdurabilir.
- Tek onaylayıcıya bağımlılık: O kişi tatildeyken sistem kilitlenir. Yedek onaylayıcı veya eskalasyon zinciri şart.
- Onay gerekçesini sormamak: “Red” kararı verildiğinde neden reddedildiği kaydedilmezse, ajan öğrenemez.
- Read-only işlemleri onaya almak: Veri okuma işlemleri genellikle güvenlidir. Gereksiz onay talebi, güveni aşındırır.
Güven Seviyesine Göre Kademeli Özerklik
OpenAI’ın ajan geliştirme rehberinde vurgulanan bir yaklaşım: Ajanın güvenilirliği kanıtlandıkça, onay eşiklerini kademeli olarak gevşetmek. Bu, “earned autonomy” (kazanılmış özerklik) modeli olarak adlandırılıyor.
Uygulama önerisi:
- Seviye 1 (Başlangıç): Tüm dış etkileşimler onay gerektirir.
- Seviye 2 (Güven inşası): Düşük riskli işlemler otomatik, orta risk onaylı.
- Seviye 3 (Olgunluk): Sadece yüksek ve kritik işlemler onaylı.
- Seviye 4 (Tam güven): Sadece kritik işlemler ve anomaliler onaylı.
Her seviyeye geçiş, belirli bir başarı oranı ve hatasız işlem sayısına bağlanabilir. Örneğin: “Son 100 işlemde %98 doğruluk → Seviye 2’ye geç.”
Sıkça Sorulan Sorular
İnsan onayı beklerken ajan ne yapmalı?
İdeal yaklaşım, ajanın diğer bağımsız görevlere devam etmesi ve onay gerektiren işlemi “beklemede” tutmasıdır. Timeout süresi dolduğunda, işlemi iptal edip kullanıcıyı bilgilendirmeli.
Onay mekanizması performansı ne kadar etkiler?
Doğru tasarlanmış bir sistemde, düşük riskli işlemler hiç etkilenmez. Yüksek riskli işlemlerdeki gecikme ise bilinçli bir güvenlik tercihidir. Kritik olan, onay süresinin öngörülebilir olmasıdır.
Birden fazla onaylayıcı gerekli mi?
Kritik işlemler için “dört göz prensibi” (iki kişi onayı) uygulanabilir. Ancak bu, iş akışını yavaşlatır. Risk seviyesine göre karar verilmeli.
Ajan yanlış onay talebi gönderirse ne olur?
Bu, sistemin öğrenmesi için bir fırsat. Gereksiz onay talepleri loglanmalı ve periyodik olarak analiz edilmeli. Kurallar buna göre güncellenmeli.
Sonuç
Yapay zeka ajanlarında insan onayı mekanizması, “ya hep ya hiç” değil, kademeli ve bağlama duyarlı bir yapı olmalı. Temel prensipler şöyle özetlenebilir:
- Geri alınamayan ve yüksek etkili işlemler varsayılan olarak onay gerektirmeli.
- Onay yorgunluğundan kaçınmak için eşikler dikkatli belirlenmeli.
- Dinamik kurallar, statik listelerden daha etkili çalışır.
- Güven inşa edildikçe özerklik kademeli olarak artırılabilir.
- Her onay kararı loglanmalı ve sistemin iyileştirilmesi için kullanılmalı.
Risk Seviyesi: Yanlış yapılandırma orta-yüksek risk taşır. Çok gevşek kurallar güvenlik açığı, çok sıkı kurallar ise kullanılabilirlik sorunu yaratır. Dengeli başla, veriye göre ayarla.