Garfield
YZF Admin
Ajan iş akışında insan onayı, ajanın geri döndürülemez, dış dünyayı etkileyen, hassas veriye dayanan veya belirsiz sonucu olan bir eylemi gerçekleştirmesinden hemen önce konur. En güvenli tasarım; düşük riskli adımları otomatik bırakmak, risk yükseldiğinde akışı durdurup insana özet, kanıt ve önerilen eylemi göstermek, onaydan sonra yalnız onaylanan işlemi yürütmektir. Böylece insan her adımı elle yapmak zorunda kalmaz; ancak para, yetki, veri paylaşımı ve iletişim gibi kritik kararların son kontrolü insanda kalır.
Onay kutusunu her adıma koymak otomasyonu yavaşlatır; hiçbir yere koymamak ise ajanın hatasını doğrudan sonuca dönüştürebilir. Karar verirken şu soruyu sorun: Bu adım yanlış yapılırsa zarar geri alınabilir mi, dışarıdan fark edilir mi ve etkisi ne kadar geniş olur?
Yanlış işlem kolayca geri alınabiliyorsa ve yalnızca taslak oluşturuyorsa otomatik çalışabilir. Para transferi, kayıt silme, üretim ortamında değişiklik yapma, müşteriye mesaj gönderme, kişisel veri aktarma veya yeni bir yetki kullanma gibi eylemler ise genellikle insan onayı gerektirir.
Ajan bir e-posta gönderecek, destek kaydını kapatacak, sipariş oluşturacak, takvim daveti yollayacak ya da başka bir serviste kayıt değiştirecekse onay, taslak hazırlandıktan sonra fakat gönderim veya değişiklik yapılmadan önce konur. İnsan; alıcıyı, içeriği, ekleri ve hedef sistemi birlikte görmelidir.
Onay ekranında yalnızca “Onayla” düğmesi bulunmamalıdır. Ajanın hangi girdilere dayanarak bu sonucu hazırladığı, hangi alanları değiştireceği ve işlemin geri alınıp alınamayacağı da gösterilmelidir.
Kayıt silme, toplu güncelleme, para hareketi, abonelik başlatma, üretim ortamına dağıtım ve yüksek maliyetli API çağrıları için onay, işlemin kapsamı kesinleştikten sonra verilir. Ajan önce etkilenecek kayıt sayısını, tahmini maliyeti ve değişecek alanları çıkarabilir; insan bu özeti incelemeden yürütme adımına geçilmez.
Taslak oluşturmak ile işlemi gerçekleştirmek aynı güvenlik seviyesinde değildir. Ajanın silinecek kayıtları listelemesi otomatik olabilir; silme komutunu çalıştırması ayrıca onay gerektirebilir.
Ajan kişisel veri, finansal bilgi, şirket içi belge, erişim anahtarı veya müşteri görüşmesi içeren bir kaynağı kullanacaksa iki ayrı kontrol düşünülmelidir: veriyi okumaya yetki ve veriyi başka bir sisteme aktarma yetkisi. İç kaynaktan bilgi almak her zaman bu bilgiyi dış bir modele, uygulamaya veya kullanıcıya göndermeye izin vermez.
Bu noktadaki onayda verinin tamamı yerine mümkünse maskeleştirilmiş bir önizleme gösterilir. Hangi alanların paylaşılacağı, alıcının kim olduğu ve verinin hangi amaçla kullanılacağı açıkça yazılmalıdır.
Ajan gerekli bilgiyi bulamıyorsa, kaynaklar birbiriyle çelişiyorsa, güven puanı belirlenen eşik altındaysa veya talep tanımlı iş kuralına uymuyorsa akış otomatik devam etmemelidir. Bu durumda onay, normal işlemin önüne değil, istisna çözümleme noktasına konur.
Örneğin müşteri iade talep ediyor ancak sipariş tarihi, ürün durumu ve ödeme kaydı birbiriyle uyuşmuyorsa ajan doğrudan iade başlatmak yerine çelişen bilgileri ve önerdiği seçenekleri insana sunmalıdır. İnsan onayı burada yalnızca “devam et” anlamına gelmez; veriyi düzeltme, ek bilgi isteme veya işlemi reddetme kararı da olabilir.
Ajan mevcut yetkileriyle yapamadığı bir iş için yönetici rolü, yeni bir erişim anahtarı veya daha geniş dosya kapsamı istiyorsa onay gerekir. Yetki, yalnızca tek bir görev ve mümkün olan en kısa süre için verilmelidir. Onay kaydında kimin, hangi gerekçeyle, hangi kapsamı ve ne kadar süreyle verdiği tutulmalıdır.
Her iş akışında aynı onay noktalarını kullanmak yerine adımın etkisini değerlendirin. Aşağıdaki ayrım, onay gerekip gerekmediğini ve onayın ne zaman konacağını hızlıca belirlemeye yardımcı olur.
Tabloyu kullanırken yalnız işlemin adına bakmayın. Aynı işlem, kapsam büyüdükçe veya farklı bir veri kümesine uygulandıkça daha yüksek riskli hale gelebilir. Tek bir kaydı düzeltmek ile binlerce kaydı topluca değiştirmek aynı onay politikasına tabi tutulmamalıdır.
İnsan, ajanın bütün çalışma geçmişini okumadan karar verebilmelidir. Onay isteği en az şu bilgileri içermelidir: yapılacak eylem, eylemin nedeni, kullanılan temel girdiler, beklenen sonuç, etkilenecek kayıt veya kişi sayısı, risk ve geri alma yöntemi. Ajan bir seçenek öneriyorsa alternatifleri ve neden önerilen seçeneği seçtiğini de göstermelidir.
Örneğin varsayımsal bir fatura akışında ajan; gelen faturayı okur, tedarikçiyi sipariş kaydıyla eşleştirir ve ödeme taslağı hazırlar. Tutar, tedarikçi ve sipariş numarası eşleşiyorsa ödeme taslağı otomatik oluşturulabilir. Ancak ödeme emrini göndermeden önce onay ekranında “Tedarikçi: Örnek Ltd., tutar: 48.500 TL, sipariş: 2026-184, eşleşme: tam, ödeme tarihi: 12 Kasım 2026” gibi bir özet gösterilir. İnsan onay verirse yalnız bu tutar ve bu sipariş için ödeme gönderilir; bilgiler değişirse eski onay geçerli sayılmaz.
Onay kaydını işlem kimliğine, sürüme veya veri özetine bağlayın. Yürütme katmanı, yan etkiden hemen önce gerçek işlem girdilerinin onaylanan kapsamla eşleştiğini ve onayın hâlâ geçerli olduğunu denetlemelidir. Yalnızca kayıt tutmak bu korumayı sağlamaz; uyuşmazlık varsa işlem durmalı ve yeni kapsam için onay alınmalıdır.
Onay verildi sonucu yalnızca gösterilen kapsamın yürütülmesine izin verir. Ajanın aynı onayı kullanarak başka kayıtları, başka alıcıları veya değişmiş bir tutarı işlemesine izin vermez.
Reddedildi sonucu akışın başarısız olduğu anlamına gelmez. İşlem durur; neden reddedildiği kaydedilir ve gerekiyorsa taslak düzeltilerek yeni bir onay istenir. Reddetme gerekçesi yoksa ajan aynı hatalı öneriyi tekrar tekrar sunabilir.
Süre doldu veya yanıt gelmedi durumu varsayılan olarak ret gibi ele alınmalıdır. Özellikle para, yetki, veri paylaşımı ve dış iletişim içeren akışlarda sessizce devam etmek güvenli bir varsayım değildir.
Onaydan sonra girdi değişti durumunda yeni onay gerekir. Örneğin müşteri adresi, ödeme tutarı veya gönderilecek dosya değiştiyse önceki karar yeni eylemi kapsamaz.
Bu düzenin amacı insanı her adımın önüne koymak değil, doğru eşiklerde karar verici yapmaktır: ajan hazırlar ve kanıtlar; insan yüksek etkili eylemi yetkilendirir; sistem de yalnız yetkilendirilen kapsamı yürütür.
Onay noktası seçerken temel kural
Onay kutusunu her adıma koymak otomasyonu yavaşlatır; hiçbir yere koymamak ise ajanın hatasını doğrudan sonuca dönüştürebilir. Karar verirken şu soruyu sorun: Bu adım yanlış yapılırsa zarar geri alınabilir mi, dışarıdan fark edilir mi ve etkisi ne kadar geniş olur?
Yanlış işlem kolayca geri alınabiliyorsa ve yalnızca taslak oluşturuyorsa otomatik çalışabilir. Para transferi, kayıt silme, üretim ortamında değişiklik yapma, müşteriye mesaj gönderme, kişisel veri aktarma veya yeni bir yetki kullanma gibi eylemler ise genellikle insan onayı gerektirir.
İnsan onayı konulacak başlıca noktalar
1. Dış sisteme veya kişiye etki etmeden önce
Ajan bir e-posta gönderecek, destek kaydını kapatacak, sipariş oluşturacak, takvim daveti yollayacak ya da başka bir serviste kayıt değiştirecekse onay, taslak hazırlandıktan sonra fakat gönderim veya değişiklik yapılmadan önce konur. İnsan; alıcıyı, içeriği, ekleri ve hedef sistemi birlikte görmelidir.
Onay ekranında yalnızca “Onayla” düğmesi bulunmamalıdır. Ajanın hangi girdilere dayanarak bu sonucu hazırladığı, hangi alanları değiştireceği ve işlemin geri alınıp alınamayacağı da gösterilmelidir.
2. Geri döndürülemez veya pahalı işlemlerden önce
Kayıt silme, toplu güncelleme, para hareketi, abonelik başlatma, üretim ortamına dağıtım ve yüksek maliyetli API çağrıları için onay, işlemin kapsamı kesinleştikten sonra verilir. Ajan önce etkilenecek kayıt sayısını, tahmini maliyeti ve değişecek alanları çıkarabilir; insan bu özeti incelemeden yürütme adımına geçilmez.
Taslak oluşturmak ile işlemi gerçekleştirmek aynı güvenlik seviyesinde değildir. Ajanın silinecek kayıtları listelemesi otomatik olabilir; silme komutunu çalıştırması ayrıca onay gerektirebilir.
3. Hassas veriye erişmeden veya veri paylaşmadan önce
Ajan kişisel veri, finansal bilgi, şirket içi belge, erişim anahtarı veya müşteri görüşmesi içeren bir kaynağı kullanacaksa iki ayrı kontrol düşünülmelidir: veriyi okumaya yetki ve veriyi başka bir sisteme aktarma yetkisi. İç kaynaktan bilgi almak her zaman bu bilgiyi dış bir modele, uygulamaya veya kullanıcıya göndermeye izin vermez.
Bu noktadaki onayda verinin tamamı yerine mümkünse maskeleştirilmiş bir önizleme gösterilir. Hangi alanların paylaşılacağı, alıcının kim olduğu ve verinin hangi amaçla kullanılacağı açıkça yazılmalıdır.
4. Belirsizlik veya kural dışı durum oluştuğunda
Ajan gerekli bilgiyi bulamıyorsa, kaynaklar birbiriyle çelişiyorsa, güven puanı belirlenen eşik altındaysa veya talep tanımlı iş kuralına uymuyorsa akış otomatik devam etmemelidir. Bu durumda onay, normal işlemin önüne değil, istisna çözümleme noktasına konur.
Örneğin müşteri iade talep ediyor ancak sipariş tarihi, ürün durumu ve ödeme kaydı birbiriyle uyuşmuyorsa ajan doğrudan iade başlatmak yerine çelişen bilgileri ve önerdiği seçenekleri insana sunmalıdır. İnsan onayı burada yalnızca “devam et” anlamına gelmez; veriyi düzeltme, ek bilgi isteme veya işlemi reddetme kararı da olabilir.
5. Yetki yükseltmeden önce
Ajan mevcut yetkileriyle yapamadığı bir iş için yönetici rolü, yeni bir erişim anahtarı veya daha geniş dosya kapsamı istiyorsa onay gerekir. Yetki, yalnızca tek bir görev ve mümkün olan en kısa süre için verilmelidir. Onay kaydında kimin, hangi gerekçeyle, hangi kapsamı ve ne kadar süreyle verdiği tutulmalıdır.
Risk düzeyine göre pratik yerleşim
Her iş akışında aynı onay noktalarını kullanmak yerine adımın etkisini değerlendirin. Aşağıdaki ayrım, onay gerekip gerekmediğini ve onayın ne zaman konacağını hızlıca belirlemeye yardımcı olur.
| İşlem türü | Örnek | Onay yaklaşımı |
|---|---|---|
| Düşük riskli ve geri alınabilir | Taslak oluşturma, bilgi sınıflandırma, iç özet hazırlama | Genellikle otomatik; sonuç sonradan denetlenir |
| Dış iletişim | E-posta, müşteri yanıtı, takvim daveti | Gönderimden hemen önce içerik ve alıcı onayı |
| Hassas veri işlemi | Kişisel veya şirket içi veriyi başka servise aktarma | Veri kapsamı ve alıcı gösterilip doğrulandıktan sonra, aktarımdan önce onay |
| Yüksek etkili işlem | Silme, ödeme, üretim değişikliği, toplu güncelleme | Kapsam, maliyet ve geri alma planı görüldükten sonra zorunlu onay |
| Kural dışı veya belirsiz durum | Çelişkili kayıt, eksik bilgi, düşük güven | Otomatik yürütme durur; insan çözüm seçer veya ek bilgi ister |
Onay isteği nasıl hazırlanır?
İnsan, ajanın bütün çalışma geçmişini okumadan karar verebilmelidir. Onay isteği en az şu bilgileri içermelidir: yapılacak eylem, eylemin nedeni, kullanılan temel girdiler, beklenen sonuç, etkilenecek kayıt veya kişi sayısı, risk ve geri alma yöntemi. Ajan bir seçenek öneriyorsa alternatifleri ve neden önerilen seçeneği seçtiğini de göstermelidir.
Örneğin varsayımsal bir fatura akışında ajan; gelen faturayı okur, tedarikçiyi sipariş kaydıyla eşleştirir ve ödeme taslağı hazırlar. Tutar, tedarikçi ve sipariş numarası eşleşiyorsa ödeme taslağı otomatik oluşturulabilir. Ancak ödeme emrini göndermeden önce onay ekranında “Tedarikçi: Örnek Ltd., tutar: 48.500 TL, sipariş: 2026-184, eşleşme: tam, ödeme tarihi: 12 Kasım 2026” gibi bir özet gösterilir. İnsan onay verirse yalnız bu tutar ve bu sipariş için ödeme gönderilir; bilgiler değişirse eski onay geçerli sayılmaz.
Onay kaydını işlem kimliğine, sürüme veya veri özetine bağlayın. Yürütme katmanı, yan etkiden hemen önce gerçek işlem girdilerinin onaylanan kapsamla eşleştiğini ve onayın hâlâ geçerli olduğunu denetlemelidir. Yalnızca kayıt tutmak bu korumayı sağlamaz; uyuşmazlık varsa işlem durmalı ve yeni kapsam için onay alınmalıdır.
Onay sonucu nasıl yorumlanır?
Onay verildi sonucu yalnızca gösterilen kapsamın yürütülmesine izin verir. Ajanın aynı onayı kullanarak başka kayıtları, başka alıcıları veya değişmiş bir tutarı işlemesine izin vermez.
Reddedildi sonucu akışın başarısız olduğu anlamına gelmez. İşlem durur; neden reddedildiği kaydedilir ve gerekiyorsa taslak düzeltilerek yeni bir onay istenir. Reddetme gerekçesi yoksa ajan aynı hatalı öneriyi tekrar tekrar sunabilir.
Süre doldu veya yanıt gelmedi durumu varsayılan olarak ret gibi ele alınmalıdır. Özellikle para, yetki, veri paylaşımı ve dış iletişim içeren akışlarda sessizce devam etmek güvenli bir varsayım değildir.
Onaydan sonra girdi değişti durumunda yeni onay gerekir. Örneğin müşteri adresi, ödeme tutarı veya gönderilecek dosya değiştiyse önceki karar yeni eylemi kapsamaz.
Bu düzenin amacı insanı her adımın önüne koymak değil, doğru eşiklerde karar verici yapmaktır: ajan hazırlar ve kanıtlar; insan yüksek etkili eylemi yetkilendirir; sistem de yalnız yetkilendirilen kapsamı yürütür.
Son düzenleme:
