Human-in-the-Loop (HITL) Nedir? AI Ajan Güvenlik Katmanı
Otonom yapay zeka ajanlarında insan onayı (HITL) nedir? Riskli otomasyon eylemlerinde onay kapısı tasarımı ve mimari güvenlik rehberi.

İçindekiler
Kısa cevap: Otonom yapay zeka ajanlarında insan onayı (Human-in-the-Loop / HITL), riskli ve geri alınamaz eylemler öncesinde sistemin insan müdahalesi veya onayı almasını sağlayan güvenlik mimarisidir. Bir otomasyonun en tehlikeli anı, çalışmadığı an değil; kimse bakmadan yanlış olanı büyük bir güvenle, hızla ve tekrar tekrar yaptığı andır. Yapay zekâ ajanları artık sadece metin üretmiyor; mail gönderiyor, CRM kaydı açıyor, ödeme başlatıyor, kayıt siliyor. Bu güç, doğru sınırlarla kurulmadığında hızla bir yükümlülüğe dönüşür. İnsan onaylı (human-in-the-loop) mimari tam da burada devreye girer: otomasyonun hızını korurken, geri alınamaz kararları bir insan onayına bağlar. Bu yazıda bu dengeyi pratikte nasıl kuracağınızı anlatıyorum.
Neden Tam Otonom Otomasyon Bir Tuzaktır?
"Her şeyi yapay zekâ halletsin" cazip gelir, çünkü ilk demoda kusursuz görünür. Ama üretim ortamında bir ajan, eğitim verisinde hiç görmediği bir durumla karşılaştığında da bir karar verir — ve o kararı sizin adınıza, sizin yetkinizle uygular. Yanlış müşteriye giden bir fiyat teklifi, sehven silinen bir kayıt ya da yanlış hesaba başlatılan bir işlem, kurtarılması saatler süren bir itibar ve para kaybına dönüşür. Sorun ajanın zekâsı değil; hatasının otonom biçimde ölçeklenmesidir. Bir insanın yaptığı hata sınırlı kalabilir; denetimsiz bir ajan aynı hatayı çok kısa sürede tekrar tekrar uygulayabilir.
Doğru soru "otomasyonu tamamen ajana mı bırakmalıyım" değil, "hangi kararı ajana bırakmak güvenli" sorusudur. Bu ayrımı yapmadan kurulan her sistem, ya aşırı temkinli olup hiçbir işi bitiremez ya da aşırı cesur olup ilk ciddi hatada güveni yok eder.
Kritik Ayrım: Geri Alınabilir mi, Geri Alınamaz mı?
Kurduğum her otonom sistemin merkezinde tek bir soru var: bu eylem geri alınabilir mi? Cevap, ajanın ne kadar özgür bırakılacağını belirler. Taslak hazırlamak, dahili bir not düşmek, veriyi sınıflandırmak, bir raporu güncellemek geri alınabilir işlerdir — bunlarda ajan sormadan çalışır, çünkü bir hata anında düzeltilebilir. Ama üçüncü bir kişiye mesaj göndermek, kalıcı silme, ödeme/transfer, canlıya yayın geri alınamaz işlerdir — bunlarda ajan yalnızca hazırlar, uygulamaz.
| Eylem Türü | Tam Otonom (Onaysız) | İnsan Onaylı (Human-in-the-Loop) |
|---|---|---|
| Taslak / not / sınıflandırma | Uygun — anında düzeltilebilir | Gereksiz yavaşlatma |
| Dış kişiye mesaj / mail | Yüksek risk — itibar kaybı | Ajan hazırlar, insan onaylar |
| Kalıcı silme / ödeme / yayın | Kabul edilemez risk | Zorunlu onay + yedek doğrulama |
Bu tabloyu ekiple birlikte doldurmak, çoğu projede otomasyon stratejisinin en kritik yarım saatidir. Çünkü riski sonradan değil, tasarım anında sınıflandırırsınız.
Onay Kapısı (Approval Gate) Mimarisi Nasıl Kurulur?
Human-in-the-loop, "her şeyi insan onaylasın" demek değildir; öyle olsaydı otomasyonun anlamı kalmazdı. Amaç, insan dikkatini yalnızca gerçekten önemli olan yere odaklamaktır. Kurduğum sistemlerde üç katman işler:
- Otonom bant: Geri alınabilir işler sorulmadan yapılır ve sonucu tek satırda bildirilir. İnsan yükü sıfırdır.
- Onay kapısı: Geri alınamaz bir eylemde ajan durur, ne yapacağının kısa özetini ve bir tek dokunuşluk onay sunar (örneğin WhatsApp/Telegram üzerinden "Onayla" butonu). İnsan üç saniyede karar verir, ajan uygular.
- Denetim izi: Her onaylı eylem, kim-neyi-ne zaman onayladı bilgisiyle kaydedilir. Bir şey ters gittiğinde tahmin değil, kayıt konuşur.
Bu mimarinin gücü, onay isteme sıklığını zamanla düşürebilmenizdir: ajan güven kazandıkça, düşük riskli kategoriler otonom banda taşınır. Yani sistem sizinle birlikte olgunlaşır. Aynı yaklaşımı çok ajanlı kurulumlarda nasıl kararlı hale getirdiğimizi Üretim Ortamında Çoklu Ajan Mimarisi yazısında; CRM tarafındaki onaylı otomasyon akışını ise CRM ve Kurumsal Otomasyon rehberinde ele alıyorum. Bu prensiplerin uçtan uca bir kurumsal kuruluma nasıl döküldüğünü görmek isterseniz Yapay Zekâ ve İş Akışı Otomasyonu çözüm sayfamız iyi bir başlangıç noktasıdır.
Mevzuat İnsan Gözetimini Ne Zaman Zorunlu Kılar?
İnsan onayı yalnızca bir mühendislik tercihi değildir; belirli sistem sınıflarında yazılı bir yükümlülüktür. Avrupa Birliği'nin Yapay Zekâ Tüzüğü (Regulation (EU) 2024/1689), yüksek riskli sistemler için 14. maddede insan gözetimini şart koşar: sistem, kullanımda olduğu süre boyunca gerçek kişiler tarafından etkin biçimde gözetilebilecek şekilde tasarlanmak zorundadır. Tüzük gözetimin içini de doldurur. Gözetimi üstlenen kişi sistemin yeteneklerini ve sınırlarını doğru anlayabilmeli, anormallikleri ve beklenmedik davranışı fark edebilmeli, çıktıyı doğru yorumlayabilmeli, gerektiğinde sistemi kullanmama, çıktıyı yok sayma, geçersiz kılma veya tersine çevirme kararını verebilmeli ve sistemi güvenli bir duruma getiren bir durdurma düğmesiyle işleyişe müdahale edebilmelidir.
Tüzüğün 14(5) fıkrası bir adım daha ileri gider: Ek III'ün 1(a) bendindeki uzaktan biyometrik kimlik tespiti sistemlerinde, sistemin ürettiği eşleşmeye dayanılarak işlem yapılabilmesi için kimliğin en az iki yetkin gerçek kişi tarafından ayrı ayrı doğrulanması gerekir. Yani risk yükseldiğinde mevzuat tek onaycıyı bile yeterli görmez; onayın kendisi de çoğaltılır.
Aynı ilke ajan protokollerinin teknik standardında da yazılıdır. Model Context Protocol'ün güncel revizyonu olan 2025-11-25 sürümü, araç çağrıları için açık bir uyarı taşır: güven ve güvenlik gerekçesiyle, araç çağrılarını reddetme yetkisine sahip bir insanın her zaman döngüde olması beklenir. Aynı bölüm istemcilere iki pratik kural daha verir: hassas işlemlerde kullanıcı onayı iste ve aracın girdilerini sunucuya gönderilmeden önce kullanıcıya göster. İkinci kural kritiktir, çünkü ne onaylandığı görülmeden verilen onay, onay değil imzadır.
Uçtan Uca Örnek: Dışa Giden Mesajda Onay Kapısı
Soyut kalmamak için tek bir geri alınamaz eylemi baştan sona izleyelim: bir müşteri adayına dışarıya gidecek mesaj. Ajan bu mesajı hazırlar, ama göndermez; kapı burada açılır.
| Aşama | Sistemde fiilen ne oluşur |
|---|---|
| 1. Tetikleyici | Form kaydı lead.created olayını üretir; taşıdığı alanlar ad, iletişim kanalı ve talep metnidir. |
| 2. Ajan taslağı | Ajan bir araç çağrısı hazırlar: araç adı, şablon adı ve şablon değişkenlerinin son hâli. Çağrı yürütülmez, onay kuyruğuna yazılır. |
| 3. Onay kartı | Onaycıya giden kartta hedef kanal (maskeli), şablon adı, değişkenlerin son hâli ve üç seçenek bulunur: onayla, düzelt, reddet. |
| 4. Karar | Karar kaydı yazılır: kimin onayladığı, ne zaman onayladığı ve hangi seçeneği kullandığı. |
| 5. Yürütme | Yalnız onay sonrası çağrı sunucuya iletilir; sonuç, hata bayrağı taşıyan bir yanıtla geri döner ve başarısızlık sessizce yutulmaz. |
| 6. Denetim izi | Taslak, karar ve sonuç tek bir ilişkilendirme kimliği altında saklanır; ay sonunda bir mesaj sorgulandığında tahmin değil kayıt konuşur. |
Bu akışın taşıyıcı ayrıntısı üçüncü satırdadır: onaycı sonucu değil, gönderilecek girdinin kendisini görür. Ajanın kararını değil çıktısını onaylamak, protokol standardının da altını çizdiği noktadır. Dördüncü satır ise kapının varlık sebebidir; onay bir kayıt üretmiyorsa, o kapı yalnızca bir gecikmedir.
Ölçüm Sözleşmesi: Onay Kapısı Hangi Sayılarla İzlenir?
Onay kapısı kurmak kolaydır; kapıyı zamanla daraltıp genişletmek ölçüm ister. Burada bir sektör ortalaması vermiyorum, çünkü onay oranı iş akışına, şablon kalitesine ve onaycı sayısına göre değişir; uydurma bir yüzde, kurulumun kendi gerçeğini gizler. Bunun yerine hangi büyüklüğün nasıl ölçüleceğini sabitleyen bir sözleşme kurun.
- Onay bekleme süresi: taslağın kuyruğa girmesiyle kararın verilmesi arasındaki süre; ortanca ve uç değer birlikte okunur. Uç değer büyüyorsa kapı darboğaza dönüşmüştür.
- Düzeltme oranı: onaylanmadan önce elle değiştirilen taslakların payı. Bu oran düşerken kalite sabit kalıyorsa, o kategori otonom banda taşınmaya hazırdır.
- Reddetme oranı: tümüyle geri çevrilen taslaklar. Yükseliyorsa sorun onay kapısında değil, ajanın girdisindedir.
- Kapı sıklığı: koşum başına kaç kez onay istendiği. Sıklık, geri alınamaz eylem sayısıyla orantılı değilse kapı yanlış yere kurulmuştur.
- Kaçak eylem: kapıdan geçmeden yürütülmüş geri alınamaz eylem sayısı. Hedef sıfırdır ve bu tek sayı, mimarinin sağlığını diğer hepsinden daha iyi anlatır.
Başlangıç değerini iki haftalık bir gölge koşumla alın: ajan taslağı hazırlar, insan işi zaten yapmaktadır ve iki çıktı karşılaştırılır. Böylece kapının maliyeti ile kazancı aynı ölçekte konuşulur. Bu disiplinin ticari karşılığı da var: TÜİK'in Yapay Zeka İstatistikleri, 2025 bülteninde (01 Ekim 2025), yapay zekâ kullanmayı düşündüğü hâlde kullanmayan girişimlerin %62,4'ü gerekçe olarak zarar durumunda sorumluluğun kimde olacağına dair hukuki belirsizliği gösteriyor. Denetim izi üreten bir onay kapısı, tam olarak bu belirsizliği kapatan mühendislik cevabıdır.
Hata Desenleri: Onay Yorgunluğu ve Otomasyon Yanlılığı
İnsan onaylı mimarinin başarısızlıkları çoğunlukla teknik değil, davranışsaldır. En sık görülen dört desen şudur.
Otomasyon yanlılığı. Yapay Zekâ Tüzüğü bu riski adıyla sayar: gözetimi üstlenen kişi, sistemin çıktısına otomatik olarak veya aşırı ölçüde güvenme eğiliminin farkında olmalıdır. Uygulamada bu, onay kartına bakmadan onaylamak demektir. Panzehiri kartın içeriğidir: karar için gereken alanı göstermeyen bir kart, yanlılığı üretir.
Onay yorgunluğu. Kapı çok sık açılırsa onay bir refleks hâline gelir ve koruma değeri sıfıra iner. Çözüm kapıyı kapatmak değil, doğru yere kurmaktır: eşik sıklık değil geri alınamazlık olmalıdır. Geri alınabilir işler otonom bantta kalmalı, kapı yalnız kalıcı sonuç doğuran eylemlerde açılmalıdır.
Bağlamsız onay. Yalnızca onaylıyor musunuz sorusunu soran bir kart, denetimi biçimsel hâle getirir. Protokol standardının araç girdilerini önceden gösterme kuralı bunun içindir; onaycı neyi onayladığını görmelidir.
İzsiz onay ve tek onaycı. Kim, ne zaman, neyi onayladı sorusunun cevabı kayıtta yoksa sorumluluk kanıtlanamaz. Yüksek riskli sınıflarda ise tek onaycı yetmez; tüzüğün 14(5) fıkrası bu durumda iki ayrı kişinin doğrulamasını arar. Kural basittir: eylemin geri dönüşü ne kadar zorsa, onayın kanıtı o kadar güçlü olmalıdır.
Sıkça Sorulan Sorular
İnsan onayı otomasyonu yavaşlatmaz mı?
Sadece geri alınamaz kararlarda onay istenir; taslak, sınıflandırma ve dahili işler otonom biçimde, sorulmadan yapılır. Doğru kurulmuş bir sistemde insan dikkati yalnızca gerçekten kritik ana odaklanır, geri kalan her şey saniyeler içinde otomatik akar.
Onay her seferinde manuel mi, yoksa zamanla azalır mı?
Azalır. Sistem güven kazandıkça, başlangıçta onaya bağlı tutulan düşük riskli kategoriler kademeli olarak otonom banda taşınır. Böylece otomasyon ekiple birlikte olgunlaşır ve manuel onay yükü sürekli düşer.
Human-in-the-loop mimari hangi sektörler için gereklidir?
Geri alınamaz eylemlerin bulunduğu her sektör için: sağlık turizmi (hastaya giden mesaj), finans (ödeme/transfer), hukuk (resmi evrak) ve e-ticaret (fiyat/stok güncelleme) başta gelir. Kural sektöre değil, eylemin geri alınabilirliğine bağlıdır.
İnsan onayı yasal olarak zorunlu mu?
Yüksek riskli sistemler için evet. AB Yapay Zekâ Tüzüğü'nün (Regulation (EU) 2024/1689) 14. maddesi, yüksek riskli yapay zekâ sistemlerinin kullanımda olduğu süre boyunca gerçek kişilerce etkin biçimde gözetilebilecek şekilde tasarlanmasını şart koşar; gözetimi üstlenen kişi çıktıyı yok sayabilmeli, geçersiz kılabilmeli ve sistemi güvenli biçimde durdurabilmelidir.
Onay kapısı hangi eylemlerde açılmalı?
Eşik sıklık değil geri alınamazlıktır. Taslak, sınıflandırma ve dahili not gibi anında düzeltilebilir işler otonom bantta kalır; dış kişiye mesaj, kalıcı silme, ödeme ve canlıya yayın gibi geri alınamaz eylemlerde kapı açılır. Kapıyı sıklığa göre kurmak onay yorgunluğu üretir ve korumayı işlevsizleştirir.
Onay kapısının işe yaradığını nasıl ölçerim?
Beş büyüklükle: onay bekleme süresi (ortanca ve uç değer), düzeltme oranı, reddetme oranı, koşum başına kapı sıklığı ve kapıdan geçmeden yürütülmüş geri alınamaz eylem sayısı. Son büyüklüğün hedefi sıfırdır. Başlangıç değeri, ajanın taslak hazırlayıp insanın işi yapmaya devam ettiği iki haftalık bir gölge koşumla alınır.