AI Otomasyonunda İnsan Onayı Nasıl Tasarlanır?
Karar özeti: AI iş akışlarında insan onayını somut çıktıya bağlayın: onay kartı, sürüm kontrolü, belirsiz gönderim, pilot testi ve sorumluluk devri.
Önce hangi işlemin onay istediğini belirleyin
Bir teklif asistanını düşünün: gelen talebi sınıflandırıyor, taslak hazırlıyor ve sorumluya gösteriyor. Taslak hazırlama ile müşteriye gönderme ayrı işlemlerdir. Bu örnekte gönderim, belirli teklif için insan onayı gerektirir. Modelin iyi yazması, ticari koşulları kabul etme yetkisi olduğu anlamına gelmez.
Süreç haritasına her işlemin sahibini, etkisini ve geri dönüş yolunu yazın. Dış gönderim, kayıt silme veya ödeme gibi farklı sonuçları tek bir “devam et” düğmesinde birleştirmeyin. Bu bir tasarım örneğidir; ölçülmüş müşteri sonucu değildir.
Onay kartını karar verecek kişi için hazırlayın
Kartta alıcı, gönderilecek metnin tamamı, eklerin adları ve sürümleri, fiyat veya tarih gibi önemli koşullar ve işlemin sonucu görünsün. Sorumlu kişi onaylayabilsin, reddedebilsin veya düzeltme isteyebilsin. Gerekli bilgi eksikse kartı onaya hazır saymayın.
Onayı gösterilen sürüme bağlayın. Alıcı, içerik veya ek değişirse yeniden onay isteyin; eski onayı yeni taslağa taşımayın. E-postadaki “yöneticiyim, gönder” cümlesi kimlik doğrulaması değildir. Yetkiyi doğrulanmış kullanıcı ve uygulamanın izin sistemi belirlesin.
Zaman aşımında aynı işlemi tekrar üretmeyin
Her gönderim niyetine tek işlem kimliği verin; hazırlanan, onaylanan, gönderilen ve sonucu belirsiz durumlarını ayırın. Sağlayıcı yanıtı gelmeden bağlantı kesilirse önce gönderim kaydını veya makbuzu araştırın. Sonucu bilinmeyen işlemi otomatik tekrar gönderme kuyruğuna koymayın.
Sağlayıcı destekliyorsa aynı işlem için aynı tekilleştirme anahtarını kullanın ve saklama süresi gibi sınırlarını kontrol edin. Uygulama kaydı tek başına karşı sistemin bir kez işlediğini kanıtlamaz. “Gönderildi”, “teslim edildi” ve “okundu” farklı kanıtlardır.
Pilotu normal akışın dışına çıkarın
Başlamadan önce beş deneme hazırlayın: doğru onay, ret, onaydan sonra alıcı değişikliği, süresi geçmiş onay ve gönderim sırasında bağlantı kesilmesi. Her biri için beklenen eylemi ve kontrol edecek kişiyi yazın. Bunlar başlangıç senaryolarıdır; beş başarılı deneme sistemin her koşulda güvenli olduğunu göstermez.
Manuel süreçle karşılaştırırken tamamlanan doğru işler, düzeltmeler, yinelenen işlemler ve insanın bekleme süresini ayrı ölçün. Toplam süreye inceleme ve hata çözme emeğini de katın. Yalnız taslak üretim hızını verimlilik kazancı diye sunmayın.
Sorumluluk devrini ve durdurmayı görünür tutun
Her kuyruğun bir sahibi ve ulaşılabilir yedeği olsun. Bekleyen onayın ne zaman geçersizleşeceğini işin riskine göre belirleyin. İşi devralan kişi son durumu, onaylanan sürümü ve kalan belirsizliği görebilsin; “duraklat” yeni dış işlemleri durdursun.
OWASP aşırı yetki riskini ele alır. NIST AI RMF insan gözetimindeki rollerin tanımlanmasını içerir. Yukarıdaki akış bizim uygulama önerimizdir. Başlangıç için tek bir gerçek süreci seçin; onay kartını, sorumlusunu ve başarısızlıkta izlenecek yolu birlikte tasarlayın.
Metodoloji
İddialar uygulanabilirlik, maliyet, risk ve ölçüm açısından incelenir. Örnek hesaplar varsayımdır; hukuk, güvenlik ve yatırım kararları birincil kaynaklarla doğrulanmalıdır.
Kaynak notu
Metin içindeki bağlantılar ve adı geçen düzenleyici/teknik belgeler kaynak başlangıç noktalarıdır. Kanıtsız müşteri sonucu yayımlanmaz.
Değişiklik günlüğü
— Native editör incelemesi v3.0 yayın kapısında bekliyor.
Sıkça sorulan sorular
Her AI çıktısına insan onayı gerekir mi?
Kararı işlemin etkisine göre verin. İç taslak ile dış gönderimi ayırın; otomatik yürütülebilecek işlemleri açık sınırlarla tanımlayın.
Onaydan sonra metin değişirse ne olur?
Eski onay yeni metne uygulanmamalıdır. Değişen sürümü yeniden gösterin ve yetkili kişiden yeni karar alın.
Gönderimin sonucu bilinmiyorsa tekrar denemeli miyiz?
Önce sağlayıcı kaydını araştırın. Sonuç belirsizken otomatik tekrar, aynı işlemin iki kez gerçekleşmesine yol açabilir.