Bir AI akışına her adımda onay eklemek işi yavaşlatabilir; hiç onay koymamak da belirsiz çıktıları doğrudan eyleme dönüştürebilir. Tasarım sorusu, insanın sistemde bulunup bulunmaması değil, hangi kararın kim tarafından ve hangi bilgiyle verilmesidir. İnceleme noktalarını iş etkisi ve geri alınabilirlik üzerinden seçmek daha anlaşılır bir model oluşturur.
Öneri hazırlamakla işlem yapmak arasına sınır koyun
Talebi özetlemek, CRM alanını değiştirmek ve müşteriye mesaj göndermek aynı etkiye sahip değildir. Önce akıştaki çıktıların hangilerinin bilgi, hangilerinin dış dünyada işlem olduğunu listeleyin. Yetki sınırlarını yalnızca genel bir metin talimatına bırakmayın; akışın izin verdiği eylemleri de sınırlayın.
n8n’in resmî dokümanı, belirli AI araç çağrıları için insan onayı istenebildiğini ve ret halinde işlemin çalışmadığını açıklar. Bu bir uygulama seçeneğidir; işletmenizin hangi işlemi onaylaması gerektiğini kendiliğinden belirlemez. O karar süreç sahibiyle verilmelidir.
Onay ihtiyacını işin etkisine göre değerlendirin
Aşağıdaki yaklaşım karar toplantısında kullanılabilecek bir başlangıçtır. Sektör, veri ve sözleşme koşulları ayrı gereksinimler doğurabilir; bunlar proje kapsamına göre değerlendirilmelidir.
| İşlem | İlk tasarım yaklaşımı | İnceleyene gösterilecek bilgi |
|---|---|---|
| İç kullanım için özet | Örnekleme ve kalite kontrolü | Kaynak ve eksik bağlam |
| Müşteri kaydını güncelleme | Alan bazlı doğrulama | Eski değer ve yeni öneri |
| Teklif veya mesaj gönderme | Gönderim öncesi yetkili inceleme | Alıcı, kapsam ve tam metin |
| Belirsiz talebi yönlendirme | İstisna kuyruğu | Kategori seçenekleri ve kaynak |
Onayı tek düğmeden fazlası haline getirin
Kontrol eden kişi neyi onayladığını görebilmelidir. Hedef kayıt, mevcut değer, önerilen değişiklik ve gerekçe aynı yerde sunulursa inceleme anlamlı olur. Uzun bir konuşmanın sonunda yalnızca “devam et” düğmesi göstermek, kararın kapsamını belirsiz bırakabilir.
Onaydan sonra içerik değişirse eski onayın yeni içeriğe uygulanmaması gerekir. Varsayımsal bir teklif akışında müşteri adı veya fiyat güncellenirse son hali yeniden incelenmelidir. İnceleme kaydının hangi sürüme ait olduğunu tutmak, sonraki sorulara cevap vermeyi kolaylaştırır.
Ret, gecikme ve sorumlu yokluğu için yol belirleyin
Onay bekleyen işlem sonsuza kadar görünmez bir kuyrukta kalmamalıdır. Süre dolduğunda hatırlatma, alternatif sorumlu veya güvenli iptal seçenekleri işin niteliğine göre planlanabilir. Sessizlik onay olarak yorumlanmamalıdır. Ret sebebi sonraki taslağı geliştirecek kadar açık tutulmalıdır.
Pilot sırasında sadece doğru onayları değil yanlışlıkla verilen onayları, terk edilen kayıtları ve kontrol yükünü de inceleyin. Onay katmanı hatayı azaltmıyorsa daha fazla düğme eklemek yerine sunulan bağlamı ve yetki sınırını düzeltin. İnsan kontrolünün değeri, kararın gerçekten değerlendirilebilmesidir.
Kontrol eden kişinin iş yükünü de planlayın. Çok sayıda benzer istek geldiğinde toplu görünüm yararlı olabilir, ancak farklı alıcı veya kapsam taşıyan işlemler birbirinin onayını paylaşmamalıdır. İnceleme kolaylığı karar sınırını silmemelidir.