Human-in-the-Loop Onay Akışı: Kim, Neyi, Ne Zaman Onaylar

Öne çıkanlar

İşlemleri risk düzeyine göre sınıflandırıp her sınıf için onaylayan rolü belirleyin.
İyi bir onay isteği; ne, neden, etki, geri alma ve kanıt içerir.
Zaman aşımında varsayılan davranış "uygulama" değil "bekle ve yükselt" olmalıdır.
Onay yorgunluğu, insan onayını anlamsızlaştıran en büyük risktir.

Confidenya'nın yaklaşımında temel ilke açıktır: hiçbir değişiklik insan onayı olmadan canlıya alınmaz. Ancak bu ilkeyi uygulamak, her işlem için bir onay butonu eklemekten fazlasını gerektirir. Kötü tasarlanmış bir onay akışı ya ajanı işe yaramaz hale getirecek kadar yavaştır ya da onaylayanların okumadan onay verdiği bir formaliteye dönüşür. Bu rehber, dengeli bir human-in-the-loop (HITL) akışının nasıl tasarlanacağını anlatır.

Adım 1: İşlemleri sınıflandırın

Ajanın yapabileceği tüm işlemleri listeleyin ve risk düzeyine göre gruplayın. Örnek bir sınıflandırma:

Sınıf 0, bilgi: okuma, analiz, rapor üretme. Onay gerekmez, kayıt tutulur.
Sınıf 1, düşük etkili yazma: vaka notu ekleme, ticket güncelleme, etiketleme. Onay gerekmeyebilir; örneklem denetimi yapılır.
Sınıf 2, geri alınabilir operasyonel değişiklik: tek bir alarmın kapatılması, tek bir e-postanın karantinası, geçici bir IP engeli. Tek kişilik onay.
Sınıf 3, üretim konfigürasyonu: firewall kuralı, SIEM korelasyon kuralı, EDR politikası veya istisnası. Ürün sahibi onayı ve değişiklik kaydı.
Sınıf 4, yüksek etkili veya geniş kapsamlı: çok sayıda cihazın izolasyonu, toplu hesap kilitleme, yetki değişiklikleri. İki kişilik onay (dört göz) ve gerekirse yönetim bilgilendirmesi.

Sınıflandırma ürüne değil etkiye göre yapılmalıdır: aynı üründe tek bir IP'yi engellemek ile bir ağ bloğunu engellemek farklı sınıflarda olabilir.

Adım 2: Onay matrisini yazın

Her sınıf için şu sorulara yanıt verin: Kim onaylar (rol, kişi değil)? Kim onaylayamaz (örneğin talep sahibi kendi talebini onaylayamaz)? Hangi kanaldan (ITSM, sohbet aracı, ürün konsolu)? Ne kadar süre içinde? Süre dolarsa ne olur? Mesai dışında kim onaylar?

Adım 3: İyi bir onay isteği

Onaylayanın karar verebilmesi için gereken bilgi, isteğin içinde olmalıdır. Onaylayanı ham loglara yönlendiren bir istek, ya geç onaylanır ya da okunmadan onaylanır. İyi bir onay isteğinin bölümleri:

Ne: yapılacak değişikliğin tam ve teknik tanımı (örneğin kural ID'si, eklenecek obje, etkilenecek cihaz grubu).
Neden: tetikleyen talep veya alarm ve ajanın gerekçesi.
Kanıt: gerekçeyi destekleyen log, sorgu veya analiz çıktısına bağlantılar.
Etki: değişikliğin etkileyeceği sistemler, kullanıcılar ve olası yan etkiler.
Alternatifler: ajanın değerlendirip seçmediği daha dar veya daha geniş seçenekler.
Geri alma: değişikliğin nasıl geri alınacağı ve bunun ne kadar sürdüğü.
Belirsizlik: ajanın emin olmadığı noktalar.

Adım 4: Zaman aşımı ve acil durum

Onay gelmediğinde varsayılan davranış "işlemi uygula" olmamalıdır. Bunun yerine istek bir üst role yükseltilir ve ajan, mümkünse daha düşük riskli bir ara önlem önerir (örneğin cihazı izole etmek yerine şüpheli süreci izlemeye almak). Acil durumlar için önceden tanımlanmış, dar kapsamlı ve sonradan gözden geçirilen hızlı onay yolları tasarlanabilir; ama bu yolların kullanımı her seferinde raporlanmalıdır.

Adım 5: Onay yorgunluğunu önleyin

Çok sayıda düşük değerli onay isteği, onaylayanları okumadan onay vermeye iter. Bu durum, insan onayının sağladığı güvenceyi ortadan kaldırır. Önleme yöntemleri:

Benzer istekleri gruplayın: tek tek on ayrı IP engeli yerine, gerekçesiyle birlikte tek bir toplu istek.
Düşük riskli işlemleri onay yerine örneklem denetimine taşıyın, ancak bunu kanıta dayalı ve yazılı bir kararla yapın.
Onay yükünü dağıtın ve bireysel onay hacmini izleyin.
Çok hızlı verilen onayları (örneğin isteğin açılmasından birkaç saniye sonra) inceleme konusu yapın.
Ajanın reddedilen önerilerini analiz edip öneri kalitesini artırın; kalitesiz öneri, yorgunluğun ana kaynağıdır.

Adım 6: Uygulamayı onaya bağlayın

Onay ile uygulama arasındaki bağ teknik olarak sağlanmalıdır. Ajan, onay kaydının kimliği olmadan sınıf 2 ve üzeri bir işlemi uygulayamamalı; uygulanan değişiklik onaylanan değişiklikle birebir aynı olmalıdır. Onaydan sonra değişikliğin içeriği değiştiyse yeni bir onay gerekir. Bu bağ, denetim izinin de temelidir.

Sık sorulan sorular

Her işlem için insan onayı ajanı yavaşlatmaz mı?

Risk tabanlı sınıflandırma ile okuma ve düşük etkili işlemler onaysız ilerler; onay yalnızca üretimi değiştiren işlemlerde istenir. Ajanın hazırlık işini üstlenmesi, onay süresini de kısaltabilir.

Dört göz ilkesi ne zaman gerekli?

Geniş kapsamlı veya geri alınması zor işlemlerde önerilir. Hangi işlemlerin bu sınıfa girdiği kurumun risk değerlendirmesiyle belirlenmelidir.

Onay sohbet aracından verilebilir mi?

Verilebilir, ancak onayın kimin tarafından verildiği güvenilir şekilde doğrulanmalı ve onay kaydı değişiklik yönetimi sistemine bağlanmalıdır.

İlgili çözümler

İlgili rehberler

confidenya

Bu adımları kendi ortamınızda planlayalım

Hiçbir değişiklik insan onayı olmadan canlıya alınmaz. Güvenlik ürünlerinizin yönetimini AI ajanlarına kademeli ve denetlenebilir şekilde devretmek için ekibimizle görüşün.

Ekibimizle görüşün

Bu içerik genel bilgilendirme amaçlıdır. Kurumunuza özel kararlar için uzman değerlendirmesi önerilir.

Human-in-the-loop onay akışı tasarımı: kim, neyi, ne zaman onaylar