Human in the Loop Bir Sistemdir, Acil Durdurma Düğmesi Değil

Gate'ler nasıl doğru tasarlanır?

"En sonunda yine bir insan bakacak." Bu cümle güven verici gelir. Fakat birçok yapay zekâ projesinde bu, gerçek bir güvenlik mimarisinden çok bir temennidir. Süreç büyük ölçüde otomatik ilerler, yapay zekâ kapsamlı çıktılar üretir, belki verileri değiştirir veya dış sistemlerde eylem tetikler; sonra da son aşamaya yakın bir noktada bir kişinin "her şey uygun" diye onay vermesi beklenir.

Bu, Human in the Loop'un ritüele dönüşmüş hâlidir. Sistem hâli değildir.

Etkili Human-in-the-Loop tasarımı, bir insan var mı? sorusuyla başlamaz. Daha kesin sorularla başlar:

Hangi durum sınırında insan otoritesi gerçekten devreye girmelidir?

O anda hangi kanıtlar hazır olmalıdır?

İnsan hangi kararı verme yetkisine sahiptir?

Bu karar yokken hangi işlem teknik olarak engellenmiştir?

Belirsizlik, ret, zaman aşımı veya çelişkili kanıt durumunda ne olur?

Karar nasıl kaydedilir, ne kadar süre geçerlidir ve gerekirse nasıl geri alınır?

Bu yaklaşım insan kontrolüne bakışı temelden değiştirir. İnsan, geri kalan her şeyi kontrolsüz çalışan bir sistemin acil durdurma düğmesi değildir. İnsan, bazı durum geçişlerinin bilinçli olarak yalnızca yapay zekâ tarafından gerçekleştirilemediği bir karar mimarisinin parçasıdır.

İyi bir gate bu nedenle yalnızca "Lütfen kontrol et" demez. Şunu söyler:

"Bu süreç ancak tanımlı koşullar sağlandığında, ilgili kanıt görünür olduğunda, yetkili kişi karar verebilecek durumda olduğunda ve sonuçlar anlaşıldığında devam edebilir."

Onay ile gerçek kontrol arasındaki fark budur.

Acil durdurma düğmesi geç devreye girer

Acil durdurma önemli bir güvenlik işlevidir. Ancak reaktiftir. Bir süreç zaten çalışmaktadır, tehlike fark edilir ve biri sistemi durdurur.

Gate farklıdır. Önleyicidir. Riskli veya etkisi yüksek bir durum geçişi, gerekli koşullar sağlanmadan mümkün hâle gelmez.

Ayrım basitçe şöyle kurulabilir:

Olgun bir sistem, riske göre bu mekanizmaların birkaçına birden ihtiyaç duyabilir. Birbirlerinin yerine geçmezler.

Örneğin yapay zekâ bir sosyal medya gönderisi oluşturuyorsa, insan yayından önce onay verebilir. Yayınlama teknik olarak bu onay gelene kadar engelliyse gerçek bir gate vardır. Sistem gönderiyi kendi başına yayınlayabiliyor ve insan yalnızca sonradan silebiliyorsa bu bir onay gate'i değildir. Monitoring ve sonradan düzeltmedir.

Düşük etkili hatalarda bu yeterli olabilir. Finansal, hukuki, itibari veya güvenlik açısından önemli sonuçlarda ise çok geç olabilir.

Human in the Loop bir süreç geometrisidir

"Human in the Loop" ifadesi kolayca yanlış bir görüntü üretir: Yapay zekâ çalışır, bir noktada insan döngüye girer, bir şeye bakar ve "Tamam" der.

Profesyonel tasarımda Human in the Loop tek bir rol veya tek bir buton değildir. Sürecin içindeki karar haklarının geometrisidir.

Bu geometri en az şu unsurları içerir:

1. Durumlar: Proje veya artefakt şu anda nerede?

2. Geçişler: Bir sonraki değişiklik ne olacak?

3. Tetikleyiciler: Neden tam şimdi bir kontrol gerekiyor?

4. Kanıt: Sağlıklı karar için hangi bilgi hazır olmalı?

5. Otorite: Bu geçişi kim meşru şekilde onaylayabilir?

6. Karar seçenekleri: Devam, geri dön, koşullu devam, durdur, eskale et?

7. Enforcement: Onay yoksa sistem geçişi gerçekten engelliyor mu?

8. İz: Sonradan neden böyle karar verildiği yeniden kurulabilir mi?

9. Geçerlilik süresi: Onay ne kadar geçerli ve ne zaman yeniden kontrol gerekir?

10. Recovery: Kararın sonradan yanlış olduğu anlaşılırsa ne olur?

Böylece insan kontrolü iyi niyet değil, bir sistem özelliği hâline gelir.

Gate, sözleşmesi olan bir durum geçişidir

Birçok proje planında "review", "onay" veya "kabul" adlı milestone'lar bulunur. Bu etiketler tek başına gate oluşturmaz.

Dayanıklı bir gate'in gate sözleşmesi vardır. Hangi koşullarda geçişe izin verileceğini tanımlar.

Minimum bir gate sözleşmesi şöyle olabilir:

Bu yapı yaygın bir hatayı önler: Ekip insan kontrolü koyduğunu düşünür ama insanın tam olarak neyi kontrol edeceğini kimse söyleyemez.

Görüşten önce kanıt

Bir gate, gate noktasındaki bilgi kadar iyidir.

Bir kişiye 60 sayfalık yapay zekâ çıktısı verilip on dakika içinde "onaylaması" bekleniyorsa süreçte biçimsel olarak insan vardır; fakat gerçek anlamda güvenilir insan kontrolü yoktur. Bilgi hacmi, gerçek inceleme kapasitesini aşar.

Bu nedenle gate ham veri yığınıyla değil, bir karar paketiyle başlamalıdır. İyi bir karar paketi örneğin şimdi verilmesi gereken somut kararı, mevcut proje/sistem durumunu, son onaydan bu yana önemli değişiklikleri, en önemli destekleyici kanıtları, açık belirsizlikleri, karşı argümanları veya reviewer itirazlarını, GO kararının sonuçlarını, NO-GO kararının sonuçlarını, geri alınabilir ve geri alınması zor etkileri, önerilen bir sonraki eylemi ve ayrıntılı artefaktlara referansları içerir.

Yapay zekâ bu paketi hazırlayabilir. Bilgiyi sıkıştırabilir, çelişkileri görünür kılabilir ve eksikleri toplayabilir. Fakat sunum kalitesi, kanıt kalitesiyle karıştırılmamalıdır.

İkna edici yazılmış bir gate raporu kanıt değildir.

Evidence Packet: insan gerçekte ne görmeli?

Daha karmaşık gate'lerde standart bir Evidence Packet, gerçekleri, değerlendirmeleri ve kararları ayırır.

1. Claims

Karar için kritik iddialar hangileridir?

2. Evidence

Bu iddiaları hangi kaynaklar, testler, ölçümler, loglar veya artefaktlar destekliyor?

3. Uncertainty

Neler bilinmiyor, belirsiz, eski, tahmini veya zayıf ölçülmüş?

4. Counterevidence

Tercih edilen seçeneğin aleyhine hangi bulgular var?

5. Impact

Varsayım yanlışsa ne olur?

6. Reversibility

Karar sonradan ne kadar kolay düzeltilebilir?

7. Recommendation

Sistem ne öneriyor ve neden?

8. Authority decision

Yetkili insan gerçekte neye karar verdi?

Bu ayrım tehlikeli bir karışmayı önler: Model analiz ve öneri üretir; insan farkında olmadan öneriyi gerçek kabul etmez.

Reviewer, Human Authority değildir

Agentic ekiplerde kolayca bulanıklaşan önemli bir fark vardır: kontrol etmek ile yetkilendirmek aynı iş değildir.

Reviewer şunları değerlendirebilir: Kaynaklar yeterli mi? Testler geçti mi? Eksik risk var mı? Çıktı tutarlı mı? Kabul kriteri sağlandı mı?

Human Authority ise şuna karar verir: Bağlayıcı durum gerçekten değiştirilebilir mi? Yayınlama, ödeme, silme veya deployment yapılabilir mi? Kalan risk kabul ediliyor mu? Bir kural için istisna tanınabilir mi? Açık görüş ayrılığına rağmen devam edilebilir mi?

Aynı kişi her iki rolü de taşıyabilir. Yine de işlevler ayrı kalmalıdır.

Aksi hâlde teknik review sessizce yetkilendirmeye dönüşür. Bir QA agent "Tüm testler geçti" diyebilir. Bu otomatik olarak "Deployment onaylandı" anlamına gelmez. İki ifade arasında bağlam, risk ve sorumlulukla ilgili bir karar vardır.

Reviewer karar kalitesini üretir. Human Authority kararın meşruiyetini üretir.

Gerçek bir gate bloklayabilmelidir

Human Gate'in en zayıf biçimi şöyledir:

"Yayınlamadan önce insana sor."

Bu bir talimattır. Çalışabilir. Ama unutulabilir, yanlış yorumlanabilir, başka bir tool yolu üzerinden aşılabilir veya hata nedeniyle atlanabilir.

Hard Gate teknik olarak uygulanır. Kritik eylem, onay olmadan erişilemez veya çalıştırılamaz.

Örnekler: Publishing API onaya kadar kilitli kalır; ödeme aracı ayrı ve yetkili bir doğrulama ister; production branch approval olmadan merge edilemez; bağlayıcı proje baseline'ına yazma yetkisi ancak GO durumundan sonra açılır; dış dağıtım aracı yalnızca geçerli release yetkisi bulunan artefaktı kabul eder.

Bunun yanında Soft Gate vardır. Uyarır, review ister veya gerekçe talep eder ama işlemi mutlak biçimde engellemez.

Her ikisi de gereklidir. Önemli olan birbirine karıştırmamaktır.

Geri alınması zor bir eylemden önce yalnızca kâğıt üzerinde bulunan gate, dayanıklı kontrol değildir.

Risk tabanlı Gate: her eylem için insan gerekmez

Çok fazla gate, çok az gate kadar sorunlu olabilir.

Her küçük araştırma, her cümle ve her geri alınabilir dosya adımı insan onayı bekliyorsa Human in the Loop, Human as Bottleneck hâline gelir. İnsan gerçek inceleme yapmadan onaylara tıklamaya başlar.

Hedef maksimum insan katılımı değil, riskle orantılı insan otoritesidir.

Dört boyut yardımcı olur:

Etki

Yanlış eylemin zararı ne kadar büyük olur?

Geri alınabilirlik

Durum hızlı, eksiksiz ve düşük maliyetle geri getirilebilir mi?

Dış etki

Eylem iç çalışma alanından çıkıyor mu? Örneğin yayın, mesaj, satın alma, sözleşme veya production değişikliği?

Belirsizlik

Bir sonraki adımın kanıtı ne kadar güçlü?

Basit desen:

düşük etki + yüksek reversibility + düşük belirsizlik: çoğu zaman Human Gate gerekmez.

orta etki veya artan belirsizlik: Conditional Gate veya review.

yüksek etki, düşük reversibility veya dış sonuç: Hard Human Gate.

yüksek etki + yüksek belirsizlik: yapay GO/NO-GO yerine eskalasyon daha iyidir.

Yedi Gate arketipi

Gate'ler farklı görevler yapar. Hepsine "onay" demek faydalı değildir.

1. Readiness Gate

Bir faz veya iş paketinin başlaması için yeterli hazırlık olup olmadığını kontrol eder.

Örnek: scope, hedef, veri erişimi ve acceptance criteria tanımlı.

2. Evidence Gate

Bir iddia veya kararın yeterince desteklenip desteklenmediğini kontrol eder.

Örnek: Teknik mimari, prototip beklenen faydayı göstermeden uygulanmaz.

3. Quality Gate

Ölçülebilir çıktı kalitesini kontrol eder.

Örnek: Testler, kaynak kontrolü, erişilebilirlik ve kalite kriterleri geçmeli.

4. Authority Gate

Yalnızca kaliteyi değil, yetkiyi kontrol eder.

Örnek: Yapay zekâ sözleşme değişikliği hazırlayabilir; bağlayıcı onayı yalnızca yetkili kişi verebilir.

5. Impact Gate

Dışa dönük veya geri alınması zor etkileri korur.

Örnek: yayınlama, ödeme, silme, deployment veya hassas veri erişimi.

6. Exception Gate

Normal yol artık geçerli olmadığında devreye girer.

Örnek: çelişkili kanıt, tool arızası, eksik veri, policy çatışması veya bütçe aşımı.

7. Release Gate

Önceki kontrolleri bir artefakt veya sistemin final yayına çıkış kararında birleştirir.

Bu sınıflandırma gate çoğalmasını azaltır. Her kontrol noktası aynı insanı, aynı kanıtı veya aynı enforcement mekanizmasını gerektirmez.

GO ve NO-GO yeterli değildir

İkili kararlar çekicidir. Gerçek projelerde kanıt çoğu zaman ikili değildir.

Bu nedenle dört gate durumu daha dayanıklı olabilir:

GO: Kriterler sağlandı; geçiş serbest.

NO-GO: Kriterler sağlanmadı; geçiş blokeli.

CONDITIONAL / PROVISIONAL: Geçiş yalnızca açıkça tanımlanmış koşullarla ve sınırlı süre için mümkün.

ESCALATE: Yetkili kişi mevcut kanıtla savunulabilir karar veremiyor veya gerekli otoriteye sahip değil.

Özellikle ESCALATE önemlidir. Bu seçenek yoksa belirsizlik yapay bir evet/hayıra sıkıştırılır veya zaman baskısıyla onay verilir.

Gate şunu söyleyebilmelidir: "Bu karar başka bir seviyeye aittir."

Gate'in sahibi olmalıdır

"İnsan kontrol eder" ifadesi, hangi insan olduğu bilinmiyorsa organizasyonel olarak anlamsızdır.

Önemli her gate'in bir Gate Owner'ı olmalıdır. Owner her şeyi kendisi analiz etmek zorunda değildir; kararın doğru şekilde oluşmasından sorumludur.

Görevleri örneğin: gerekli kanıtın mevcut olduğunu doğrulamak, eksik reviewer veya uzmanı dahil etmek, çıkar çatışmasını görmek, karar vermek veya eskale etmek, koşulları kaydetmek ve gerekiyorsa onayı geri çekmek.

Çok yüksek riskte dört göz ilkesi de uygun olabilir. Kritik olan kişi sayısı değil, otoritenin gate etkisiyle uyumlu olmasıdır.

Approval Fatigue: kontrol tıklama işine dönüşünce

Human in the Loop insan tarafında da bozulabilir.

Yaygın mekanizmalardan biri Approval Fatigue'dir. İnsan o kadar çok onay talebi alır ki tek tek kararlar yeterli dikkat görmez. Arayüz "Approve" der, rapor makul görünür, süreç bekliyordur; kişi tıklar.

Biçimsel olarak insan hâlâ sistemdedir. İşlevsel olarak kontrol kaybolmuştur.

Approval Fatigue genellikle çok fazla gate, birbirine benzeyen onaylar, çok uzun raporlar, risk önceliğinin olmaması, kararın etkisinin belirsiz olması, sürekli zaman baskısı ve rutin ile istisna arasındaki farkın görünmemesiyle oluşur.

İyi bir gate bu nedenle yalnızca AI riskini değil, insan inceleme yükünü de azaltır.

Örneğin: rutin vakaları otomatikleştirmek, yalnızca sapmaları öne çıkarmak, son onaydan beri değişenleri vurgulamak, riskleri önem sırasına koymak, karar sorusunu somutlaştırmak ve tam raporu onay ekranına dökmek yerine linklemek.

Automation Bias: insan nötr bir kontrol mekanizması değildir

Bir başka hata, insan kontrolünü otomatik olarak güvenilir kabul etmektir.

İnsanlar otomatik önerilere fazla güvenebilir; özellikle sistem daha önce sık sık doğruysa, çıktı profesyonel görünüyorsa veya kişi zaman baskısı altındaysa. Bu durum Automation Bias olarak tartışılır.

Gate tasarımı açısından, AI önerisini insana göstermek tek başına yeterli değildir.

Arayüz ve süreç aktif değerlendirmeyi desteklemelidir: belirsizliği ayrı göstermek, karşı argümanları görünür kılmak, kritik ham kanıta erişim sağlamak, önceki versiyona göre değişiklikleri vurgulamak, öneri ile kanıtı yapısal olarak ayırmak, kritik kararlarda insan gerekçesi istemek ve her default'u "Approve" yapmamak.

İnsanı esas olarak AI önerisini onaylamaya teşvik eden gate güçlü bir kontrol değildir.

Human Bandwidth bir sistem kaynağıdır

Agentic sistemler dakikalar içinde insanların saatlerce inceleyemeyeceği kadar malzeme üretebilir. Bu proje mimarisini değiştirir.

Human Oversight'un bir kapasite sınırı vardır.

Sistem on agent'ı paralel çalıştırıyorsa "İnsan her şeyi kontrol eder" demek yeterli değildir. Gerçek soru şudur:

Yetkili kişi saatte kaç kararı yeterli kaliteyle verebilir?

Böylece insan dikkati de bütçe, compute veya tool kotası gibi planlanması gereken bir kaynak olur.

Üç ilke çıkar:

Sıkıştırma

İnsana her ara adımı değil, karar için gerekli delta ve kanıtı göster.

Önceliklendirme

Yüksek etki ve yüksek belirsizlik önce dikkat alır.

Delegated Pre-Review

Reviewer'lar, testler ve otomatik kontroller rutin sorunları Human Authority'ye gelmeden filtreler.

Amaç insanı döngüden çıkarmak değil, kıt insan dikkatini doğru sınırda kullanmaktır.

Gate latency mimarinin parçasıdır

Her gate zaman harcar. Otomatik sistemlerde insan onayı en yavaş aşama hâline gelebilir.

Bu gecikme otomatik olarak kötü değildir. Bazen sorumlu bir etkinin bedelidir. Ancak planlanmalıdır.

Gate şu sorulara cevap vermelidir: Karar ne kadar hızlı verilmelidir? Kimse müsait değilse ne olur? Eşdeğer yetkili bir vekil var mı? Sistem güvenli bir ara durumda bekleyebilir mi? Talep ne zaman zaman aşımına uğrar? Eski onay tekrar kullanılabilir mi?

Bu, sistemin ya kilitlenmesini ya da kontrollerin pratikte aşılmasını önler.

Onayların son kullanma tarihi olmalıdır

Onayların sık unutulan özelliği zamansal geçerliliktir.

GO belirli bir duruma ve belirli bir kanıt tabanına dayanır. Durum anlamlı biçimde değişirse eski onay artık geçerli olmayabilir.

Örnekler: yeni veri risk değerlendirmesini değiştirir, tool veya model değiştirilir, artefakt onaydan sonra değiştirilir, budget veya scope değişir, dış kural veya deadline değişir, test güncel build'i temsil etmez.

Bu nedenle gate, hangi durumda Re-Gate gerektiğini tanımlamalıdır.

Onay kalıcı damga değildir. Belirli bir durum için verilen karardır.

Stale Approval: tehlikeli eski onay

Expiry mantığı yoksa Stale Approval oluşur.

Artefakt veya karar zemini değişmesine rağmen izin biçimsel olarak geçerli görünür.

Teknik olarak onayları belirli version, hash, build ID veya state ID'ye bağlamak bu riski azaltır. İlgili nesne değiştiğinde eski onay etkisini kaybeder.

Bu özellikle insan review'undan sonra çalışmaya devam eden agentic sistemlerde önemlidir. Aksi takdirde AI, onaydan sonra artefaktı değiştirip eski approval durumuna dayanabilir.

Onay faza değil, duruma bağlanmalıdır.

Rollback gate'in parçasıdır

Gate yalnızca ileri geçişi tanımlıyorsa eksiktir.

Dikkatli review sonrasında bile hata olabilir. Önemli gate'lerde önceden şunlar bilinmeli: son güvenli durum hangisi, hangi değişiklik geri alınabilir, hangi version veya data saklanmış, rollback'i kim tetikleyebilir, rollback sonrası hangi işler yapılmalı ve hangi etkiler tam geri alınamaz.

Bir eylemi geri almak ne kadar zorsa, eylemden önceki gate o kadar güçlü olmalıdır.

Bu, reversibility ile onay sertliğini doğrudan bağlar.

Eskalasyon ikinci sınıf hata yolu değildir

Birçok otomasyonda eskalasyon istisna gibi tasarlanır: AI devam edemezse insana gönder.

Daha olgun tasarım, eskalasyonu meşru bir sistem rotası olarak görür.

Tipik trigger'lar: çelişkili kanıt, minimum kriter ölçülemiyor, gerekli veri yok, tool tekrar tekrar hata veriyor, zaman veya budget bitti, roller veya policies çatışıyor, eylem yetki dışında, olası zarar eşik üzerinde, reviewer'lar anlaşamıyor, Human Authority gerekli teknik/hukuki uzmanlığa sahip değil.

Eskalasyon rotası nereye gittiğini bilmelidir. "Bir insana sor" çok belirsizdir. Veri koruma problemi finansal veya teknik problemden farklı bir yetkiliye gitmelidir.

İnsan müsait değilse ne olur?

Availability mantığı olmayan gate operasyonel baskı üretir. Yetkili kişi tatildeyse, hastaysa veya farklı zaman dilimindeyse informal bypass başlar: "Bu sefer devam et."

Bu nedenle gate'in No-Authority Policy'si olmalıdır.

Olası kurallar: süreç güvenli durumda bekler; eşdeğer yetkili vekil devralır; yalnızca geri alınabilir hazırlık işleri sürer; eylem otomatik ertelenir; zaman kritik vaka üst otoriteye eskale edilir; asla yalnızca süre dolduğu için kritik işlem otomatik onaylanmaz.

Son madde özellikle önemlidir. Timeout süreci durdurabilir veya eskale edebilir. Sessizce rıza üretmemelidir.

Pratik örnek: gerçek gate içeren Content Pipeline

Content akışı farkı görünür kılar.

Süreç şöyle olabilir:

Trend araştırması → konu önerileri → post üretimi → internal preview → onay → yayın

İlk aşamalar büyük ölçüde agentic ilerleyebilir. AI araştırır, varyantlar geliştirir, metin ve görsel üretir, kalite kriterlerini kontrol eder.

Yayınlama farklı bir etki alanıdır: Artefakt iç çalışma alanından çıkar ve bir kişi ya da kurum adına kamuya görünür olur.

Dayanıklı Release Gate şunları isteyebilir: final text/image version açıkça version'lanmış, kaynak ve hak kontrolü tamamlanmış, açık kritik reviewer bulgusu yok, marka/ton kontrolü geçmiş, hedef platform ve hesap belli, yayın zamanı görünür, Human Authority yayınlanacak tam versiyonu görüyor, publishing tool GO gelene kadar kilitli.

NO-GO durumunda artefakt revision'a döner. CONDITIONAL durumunda belirli düzeltmeden sonra tekrar sunulur. ESCALATE durumunda özel hukuk, marka veya alan review'u başlatılır.

İnsan kontrolü burada "bir daha bakmak" değildir. İç durumdan dış etkiye geçişi yetkilendirmektir.

İkinci örnek: proje baseline'ını değiştirmek

Agentic proje asistanı planlanan bir özelliğin teknik olarak sürdürülemez olduğunu fark eder. Scope, budget ve takvimin değişmesini önerir.

Analiz çok iyi olabilir. Yine de AI'nin bağlayıcı baseline'ı kendi başına değiştirmesi gerekmeyebilir.

Change Gate şu unsurları isteyebilir: problem ve kanıt, etkilenen varsayımlar, "hiçbir şey değiştirme" dahil üç seçenek, maliyet ve zaman etkisi, bağımlılıklara etkisi, reviewer görüşü, önerilen seçenek, baseline üzerinde yapılacak somut değişiklik.

Değişiklik yalnızca insan kararı sonrası uygulanır.

AI analiz ve hazırlıkta yüksek derecede agentic kalırken stratejik bağlayıcılık insanda kalır.

Progressive Autonomy: Gate'ler zamanla değişebilir

Pilot aşamasındaki sistem çoğu zaman uzun süre ölçülmüş ve güvenilirliği kanıtlanmış bir sistemden daha sıkı insan kontrolüne ihtiyaç duyar.

OpenAI, erken deployment'larda human intervention'ın hataları ve edge case'leri ortaya çıkarmak açısından özellikle önemli olduğunu vurgular. Buradan yararlı bir ilke çıkar: Gate'ler kanıtla olgunlaşabilir.

Örnek:

Faz 1: Her dış eylem insan onayı ister.

Faz 2: Dar limitlerdeki rutin eylemler otomatik olur; istisnalar gated kalır.

Faz 3: Yalnızca yüksek etki, yeni pattern veya düşük güven durumları eskale edilir.

Faz 4: Periyodik örnekleme ve devredilemeyen etkiler için Hard Gate.

Gerekçe "AI'ye artık daha çok güveniyoruz" olmamalıdır. Gerekçe "hangi hata sınıflarının hangi sınırlar içinde yeterince kontrol edildiğine dair kanıtımız var" olmalıdır.

Otonomi hissedilmez; kazanılır ve ölçülür.

Aynı instans gate'i icat edip kendisi geçmemeli

Kritik bir hata modeli şudur: Aynı agent işi yapar, kabul kriterlerini o anda kendisi üretir, kendi işini değerlendirir, kendini onaylar ve etkili eylemi kendisi uygular.

Bu fonksiyon ayrımı değildir. Kendi kendini sertifikalandırmadır.

Daha güçlü model:

Kriterler önceden tanımlanır veya bağımsız rol tarafından korunur.

Execution agent sonuç üretir.

Reviewer kriterlere göre kontrol eder.

Human Authority tanımlı etki sınırında karar verir.

Teknik yetkiler bu kararı uygular.

Her projede dört ayrı insan veya agent gerekmez. Ama fonksiyonlar ayrılabilir kalmalıdır.

Gate Provenance: neden onaylandı?

Hata sonrasında "Kim Approve'a tıkladı?" sorusu yetersizdir.

Daha önemli sorular: Hangi durum onaylandı? Hangi kanıt vardı? Hangi versiyonlar incelendi? Hangi açık riskler biliniyordu? Hangi reviewer'lar katıldı? Hangi koşullar kondu? Dissens var mıydı? O anda hangi policy geçerliydi?

Bunlar Gate Provenance oluşturur.

Bu yalnızca audit için değerli değildir. Projeyi de geliştirir. Belirli gate kararları tekrar tekrar yanlış çıkıyorsa sorun kanıtta mı, kriterde mi, rolde mi yoksa arayüzde mi incelenebilir.

Her onay bir öğrenme döngüsünün verisi olur.

Gate metrikleri: tıklamayı değil kontrol kalitesini ölç

Dashboard günde on onay gösterebilir. Bu, oversight'un kalitesi hakkında az şey söyler.

Daha yararlı metrikler: tam Evidence Packet bulunan gate oranı, risk sınıfına göre ortalama karar süresi, NO-GO ve ESCALATE oranı, Re-Gate sıklığı, sonradan iptal edilen onay sayısı, önce GO aldığı hâlde sonradan çıkan hata sayısı, reviewer anlaşmazlığı, rutin rubber-stamp oranı, risk sınıfına göre insan review zamanı, gerçek teknik bloklama uygulanan gate oranı.

Uzun süre %100 GO özellikle şüpheli sinyaldir. Ön kontrol gerçekten mükemmel olabilir. Daha sık olarak gate'in artık gerçek karar fonksiyonu taşımadığını gösterir.

Human-in-the-Loop için on Anti-Pattern

1. Paper Gate

Diyagramda "Human Approval" vardır ama agent teknik olarak devam edebilir.

2. Tek kontrol olarak Emergency Stop

İnsan durdurabilir ama kritik eylem başladıktan sonra.

3. Approval Fatigue

Fazla onay, review'u refleks tıklamaya dönüştürür.

4. Karar paketi yerine ham veri

İnsan gerçekte inceleyebileceğinden daha fazla materyal alır.

5. Recommendation = Evidence

AI özeti kanıt gibi kabul edilir.

6. Belirsiz otorite

Birçok kişi review yapabilir, ama bağlayıcı kararı kimin vereceği belli değildir.

7. Stale Approval

Artefakt değişmesine rağmen onay aktif kalır.

8. Rollback'siz Gate

Geçiş kontrollüdür, fakat hata sonrasında recovery yolu yoktur.

9. Timeout = Consent

Kimse cevap vermezse süreç otomatik devam eder.

10. Her yerde Gate

Her adım kontrol edilir ve oversight tıklama işine dönüşür.

Bu anti-pattern'ler süreçte daha fazla insan olmasının otomatik olarak daha fazla güvenlik üretmediğini gösterir.

Gate sistemi için dokuz stres testi

1. Missing-Evidence Test: Kritik kanıt yok. Gate gerçekten blokluyor mu?

2. Persuasion Test: AI raporu çok ikna edici, fakat temel kanıt zayıf. Bu görünür mü?

3. Stale-State Test: GO'dan sonra artefakt değişir. Onay geçersiz oluyor mu?

4. Absence Test: Human Authority yok. Süreç güvenli kalıyor mu?

5. Fatigue Test: Arka arkaya yirmi rutin onay geliyor. Kritik vakalar hâlâ öne çıkıyor mu?

6. Reviewer-Dissent Test: İki reviewer anlaşamıyor. Tanımlı eskalasyon yolu var mı?

7. Permission Test: Agent geçerli onay olmadan kritik tool'u çağırıyor. Bu teknik olarak imkânsız mı?

8. Rollback Test: GO'dan sonra hata bulunuyor. Son güvenli durum geri getirilebilir mi?

9. Automation-Bias Test: Sistem önerisi bilerek yanlış. İnsan sunulan bilgilerle bunu fark edebiliyor mu?

Gate yalnızca Happy Path çalışıyorsa dayanıklı değildir.

Sekiz adımda Gate tasarımı

Adım 1: Etkiyi belirle

Hangi durum geçişleri gerçek dış, geri alınması zor, finansal, hukuki veya stratejik etki üretir?

Adım 2: Gate sınırını yerleştir

Takvime veya toplantı ritmine göre değil, etkili geçişten önce.

Adım 3: Kriteri önceden tanımla

GO'nun savunulabilir olması için ne ölçülmüş veya kanıtlanmış olmalı?

Adım 4: Evidence Packet tasarla

Gerçek karar için insanın minimum hangi bilgiye ihtiyacı var?

Adım 5: Fonksiyonları ayır

Kim yürütür, kim review eder, kim yetkilendirir, eskalasyon kime gider?

Adım 6: Enforcement kur

Hangi izin veya teknik kilit bypass'ı engeller?

Adım 7: NO-GO, ESCALATE ve Rollback'i tasarla

Gate bir Approve butonu değildir. Tüm önemli çıkışların süreci olmalıdır.

Adım 8: Gate'in kendisini test et

Yalnızca AI'yi test etme. Gerçek zaman baskısı, eksik kanıt ve çelişkili bilgi altında insanın sağlıklı karar verip veremediğini test et.

EU AI Act gerçekte ne söylüyor – ne söylemiyor?

Human in the Loop tartışmalarında EU AI Act'in genel olarak tüm "AI" için insan onayı zorunlu kıldığı söylenebiliyor. Bu fazla geneldir.

EU AI Act Madde 14, yüksek riskli AI sistemleri için insan gözetimini düzenler.^[1] Oversight etkili olmalı ve sistemin riski, otonomi seviyesi ve kullanım bağlamıyla orantılı olmalıdır. Gözetim görevi verilen doğal kişiler uygun şekilde izleme ve müdahale imkânına sahip olmalıdır.

Gate tasarımı açısından önemli mimari sonuç şudur: Oversight sadece organizasyonel bir iddia olamaz. İnsan-makine arayüzü ve uygun teknik önlemler bunu pratikte mümkün kılmalıdır.

Madde 14 bu nedenle her küçük AI workflow'u için evrensel bir şablon değildir. Fakat temel ilkeyi güçlendirir: insan gözetimi, insanın gerektiğinde anlayabildiği, karar verebildiği, override edebildiği ve durdurabildiği yerde anlamlıdır.

NIST: Oversight tanımlanmalı, değerlendirilmeli ve belgelenmelidir

NIST AI Risk Management Framework^[2] aynı düşünceyi daha geniş bir risk yönetimi pratiği olarak ele alır. Human-AI konfigürasyonlarında roller ve sorumlulukların açık olmasını, insan gözetimi süreçlerinin tanımlanmasını, değerlendirilmesini ve belgelenmesini öngörür.

Burada governance, measurement ve management'ın bağlanması değerlidir. Oversight son anda yapılan bir kontrol değildir. Lifecycle boyunca yer alır, test edilir ve gerektiğinde değiştirilir.

Projeler için sonuç açıktır: Gate diyagramda bulunduğu için tamamlanmış sayılmaz. Kriterlerin, rollerin, bilgi akışının ve teknik etkinin operasyonda gerçekten çalıştığı gösterilmelidir.

OpenAI: Human intervention trigger ister

Pratik agent mimarisi de benzer bir desen izler. OpenAI^[3] özellikle iki trigger sınıfında insan müdahalesini önerir: hata veya retry eşiklerinin aşılması, yüksek riskli, hassas veya geri alınması zor eylemler.

Ayrıca tool risklerinin write erişimi, reversibility, hesap yetkileri veya finansal etki gibi faktörlerle değerlendirilmesi ve buna göre ek kontroller veya insan eskalasyonu uygulanması önerilir.

Buradaki önemli değişim şudur: Human in the Loop her adıma yapıştırılmaz. Somut risk sinyalleri tarafından tetiklenir.

Asıl tasarım sorusu "İnsan mı AI mı?" değildir

Daha üretken soru şudur:

Hangi karar, otomasyon, AI judgment, review, insan otoritesi ve teknik enforcement'ın hangi kombinasyonuna ihtiyaç duyar?

Bazı adımlar tamamen deterministik olabilir. Bazıları agentic ve otonom yürüyebilir. Bazıları yalnızca monitoring ister. Bazıları reviewer ister. Bazıları Hard Human Gate gerektirir. Bazı eylemler ise prensip olarak AI otoritesinin dışında kalmalıdır.

Bu ayrım, insanın ya her şeyi kontrol etmesi ya da tamamen ortadan kalkması ikileminden daha olgundur.

Human in the Loop bu nedenle organizasyon şemasındaki bir kutu değildir. Karar haklarının durum sınırları boyunca bilinçli şekilde dağıtılmasıdır.

Güven hissinden kontrol edilebilir mimariye

Kötü tasarlanmış gate kontrol hissi üretir. İyi gate kanıtlanabilir kontrol üretir.

Trigger'ını bilir. Kanıtını bilir. Yetkisini bilir. Olası kararlarını bilir. Bloklaması gereken yerde bloklar. Karar savunulamıyorsa eskale eder. Durum değiştiğinde süresi biter. Hata olduğunda nasıl geri dönüleceğini bilir.

Bu, insanı AI'nin sürekli mikroyöneticisi yapmaz. Tam tersine: iyi gate'ler, agentic sistemlerin anlamlı kontrol noktaları arasında bağımsız çalışabileceği alanı yaratır.

Görünürdeki çelişki ortadan kalkar:

Gate'ler ne kadar iyi tasarlanırsa, insan her adımı o kadar az denetlemek zorunda kalır.

Kontrol sürekli varlıktan değil, doğru sınırdaki doğru mimariden doğar.

Bir sonraki soru bu nedenle farklıdır: Gate'ler önemli durum geçişlerini güvenceye aldıktan sonra, bu gate'lerin arasındaki agentic çalışma nasıl kontrol edilebilir iş paketlerine bölünür? Burada Rolling Waves, Vertical Slices ve Work-in-Progress limitleri belirleyici hâle gelir.

Daha fazla okuma için açık kaynaklar