AI ajan guardrails: yapay zekânın yapamayacaklarını tanımlamak

Cuma günü 16:40. Bir B2B yazılım şirketinin destek sorumlusu, üç haftadır sorunsuz çalıştığını düşündüğü ajanın konuşma dökümünü açıyor. Temsili bir tablo: fiyat sorusu gelen dokuz konuşmanın altısında ajan, "size özel bir indirim tanımlayabiliriz" cümlesini kurmuş. Ajana kimse indirim yetkisi vermedi. Ama kimse ona indirim yetkisi olmadığını da söylemedi. İstemde yalnızca "yardımcı ol, müşteriyi kaybetme" yazıyordu ve ajan bunu tam olarak uyguladı.

Bu yazı o cümlenin nasıl baştan imkansız hale getirildiğini anlatıyor. Önce bir ajana yapamayacaklarını istem içinde söylemenin neden yetmediğini, sonra guardrail'in kuraldan ve iş akışından hangi noktada ayrıldığını ele alıyoruz. Ardından yasak listesinin hangi kaynaklardan çıkarıldığına, hangi aksiyonun sert yasağa hangisinin onay kapısına girdiğine, ajanın okuyabildiği bilginin neden sınırın yarısı olduğuna bakıyoruz. Son bölümlerde ihlal anında ne olması gerektiğini, sınırın gerçekten tuttuğunu nasıl test edeceğinizi, hangi kayıtlardan doğrulayacağınızı ve bu listenin zamanla kim tarafından güncelleneceğini konuşuyoruz.

Ajanın yapamayacaklarını isteme yazmak neden yetmez?

İstem bir niyet beyanıdır, bir mekanizma değil. Modele "asla fiyat taahhüdü verme" yazdığınızda, bu cümle diğer yüzlerce talimatla aynı havuzda yarışır. Konuşma uzadıkça, müşteri ısrar ettikçe, bağlam penceresi doldukça o cümlenin ağırlığı düşer. Modelin gördüğü şey bir yasak değil, bir tercihtir; ve tercihler çatıştığında kazanan genellikle en son ve en yüksek sesle söylenen olur. Müşteri "bu fiyata alamam" dediğinde ajanın önündeki en yardımsever çıkış, tam da yasakladığınız çıkıştır.

İkinci sorun ölçek. Bir ajan tek bir metin üretmiyor; kayıt oluşturuyor, alan güncelliyor, mesaj gönderiyor, bütçe değiştiriyor. yazılımın karar verip harekete geçtiği bu yeni çalışma biçiminde hatanın maliyeti artık yanlış bir cümle değil, geri alınamayan bir işlemdir. Metin hatasını düzeltirsiniz; gönderilmiş teklifi düzeltemezsiniz.

Guardrail bu yüzden istemden ayrı bir katmanda durur. Ajan Rocketly'de Guardrails — Güvenlik Sınırları ekranında yapmaması gerekenleri deklaratif olarak tanımlar ve bu sınırlar modelin ikna edilebileceği bir yerde değil, çalışma anında zorunlu tutulan bir yerde yaşar. Fark şudur: istemdeki yasak ajanın istememesini sağlamaya çalışır, guardrail ajanın yapamamasını sağlar.

Guardrail'i kuraldan ve iş akışından ayıran nedir?

Üç kavram sık karıştırılır. İş akışı, "şu olursa şunu yap" der: sıralı, koşullu, öngörülebilir. Kural motoru bir alanın değerine bakıp bir sonucu tetikler. Guardrail ise hiçbir şeyi tetiklemez; sadece bir kapıyı kapatır. İş akışı yolu tarif eder, guardrail uçurumun kenarına korkuluk koyar. Bir ajanın nasıl davranacağını bilmediğiniz durumlarda korkuluk çalışır — zaten değerli olmasının nedeni de budur.

Pratik ayrım şu soruyla yapılır: bu ifade bir yol mu tarif ediyor, bir sınır mı? "Yeni lead gelince araştır, özetle, karta not düş" bir yoldur; Adım Adım Playbook ile aksiyon sırasını modele bırakmadan tanımlarsınız. "Müşteriye asla tarih taahhüdü verme" bir sınırdır; hangi yoldan gidilirse gidilsin geçerlidir. İkisini aynı yere yazmak, ikisini de zayıflatır.

Bu ayrımı netleştirmek, ajanı bir ekibin yanında çalışan yardımcı pilot olarak konumlandırmanın da ön koşuludur. Yardımcı pilotun ne yapabileceği kadar, kokpitte hangi düğmelere elini süremeyeceği de tanımlıdır.

Yasak listesini hangi kaynaklardan çıkarırsınız?

Boş bir sayfaya oturup "ajan neler yapmamalı" diye düşünmek en verimsiz yöntemdir; akla hep aynı üç beş şey gelir. Liste dört somut kaynaktan üretilir.

• Yetki matrisi. İnsan ekipte kim neyi onaysız yapamıyorsa, ajan da yapamamalıdır. Satış temsilcisi tek başına iskonto veremiyorsa, bu satırı olduğu gibi kopyalarsınız.
• Geçmiş olaylar. Son altı ayda müşteriye giden yanlış bilgilerin listesi, en dürüst yasak kaynağıdır. Her biri bir guardrail satırına çevrilir.
• Sözleşme metinleri. Taahhüt ettiğiniz yanıt süreleri, kapsam dışı bıraktığınız işler, gizlilik hükümleri. Bunlar ajanın ağzından çıktığında bağlayıcı hale gelir.
• Mevzuat ve veri sınırları. Kişisel veri işlenmesine, pazarlama iznine ve saklama süresine dair kısıtlar.

Bu dört kaynak tarandığında ortaya genellikle otuz kırk satır çıkar ve bunların büyük kısmı birbirinin tekrarıdır. Tekrarları birleştirip kategori başlıklarına indirdiğinizde elinizde on beş satırlık, okunabilir bir metin kalır. Uzun liste güvenlik hissi verir ama kimse okumaz; kısa ve kategorik liste ise ekipteki herkesin ezberleyebileceği bir çerçeve kurar.

Listeyi çıkarırken en sık yapılan hata, yasakları soyut yazmaktır. "Yanıltıcı bilgi verme" ölçülemez. "Yayınlanmış fiyat listesinde olmayan bir rakamı yazma" ölçülebilir. Aynı disiplin CRM içindeki akıllı özelliklerin nasıl kurulduğunu anlatan yaklaşımla aynıdır: model ne kadar iyi olursa olsun, sınır ne kadar somutsa o kadar işe yarar.

Hangi aksiyon sert yasağa, hangisi onay kapısına girer?

Her sınır aynı sertlikte olmak zorunda değil. İki eksen yeter: işlem geri alınabilir mi, ve müşteri bunu görüyor mu? Geri alınabilir ve içeride kalan işlemler otomatik çalışabilir. Geri alınamayan ve dışarı çıkan işlemler ya onay bekler ya da hiç yapılmaz. Rocketly'de Onay Kontrolü Sizde ile her aksiyon türü için otomatik mi çalışsın yoksa sizin onayınızı mı beklesin ayrı ayrı seçersiniz; guardrail ise onay kapısının bile açılmaması gereken satırları tutar.

Aksiyon	Geri alınabilir mi?	Müşteri görür mü?	Önerilen sınır
Karta not ve özet düşme	Evet	Hayır	Otomatik
Lead puanı ve etiket güncelleme	Evet	Hayır	Otomatik
Reklam bütçesini artırma	Kısmen	Hayır	Manuel onay
Müşteriye teklif gönderme	Hayır	Evet	Manuel onay
İndirim veya tarih taahhüdü	Hayır	Evet	Sert yasak
Kayıt veya konuşma silme	Hayır	Hayır	Sert yasak

Tablodaki son sütun bir kere doldurulup unutulmaz. Özellikle "manuel onay" satırları zamanla iki yöne kayar: güven arttıkça otomatiğe, bir olay yaşandıkça yasağa. Yanıt süresi taahhüdü verilen işlerde ise sınırı belirleyen şey ajanın yeteneği değil, sözleşmede tanımladığınız hizmet seviyesidir; ajan o eşiği aşan bir söz veremez.

Ajanın okuyabildiği bilgi neden sınırın yarısıdır?

Yasak listesi çoğunlukla aksiyonlar üzerine kurulur, ama bir ajanın söyleyebilecekleri okuyabildikleriyle sınırlıdır. Fiyat listesine erişimi olmayan bir ajan yanlış fiyat veremez. İç maliyet tablosuna erişimi olan bir ajan, hiçbir yasak yazmasanız bile er ya da geç oradan bir sayı sızdırır. Bu yüzden erişim sınırı, davranış sınırından önce gelir.

Rocketly'de Ajan Bilgi Yönlendirme ile her ajan için hangi bilgi kaynaklarına erişebileceğini tek tek seçersiniz; bilgi tabanı aramasını tümüyle kapatmak da mümkündür. Aynı kurumda satış ajanı fiyat listesini okur, destek ajanı yalnızca dokümantasyonu görür. Bu, şirket bilgisini yapay zekaya bağlarken kurulan ilişkinin tersten okunuşudur: neyi bağladığınız kadar neyi bağlamadığınız da bir tasarım kararıdır.

Kişisel veri tarafında sınır daha da nettir. Ajanın bir kaydı okuyabilmesi, o kaydı üçüncü bir tarafa özetleyebileceği anlamına gelmez. Müşteri verisini yapay zeka ile işlerken hangi alanların ajana hiç gösterilmediğini baştan yazmak, sonradan bir ihlali soruşturmaktan çok daha ucuzdur.

Sınır ihlali anında ajan durmalı mı, devretmeli mi?

Guardrail'in tetiklendiği an, kullanıcı için bir çıkmaz olmamalıdır. Kötü tasarlanmış bir sınır "bu konuda yardımcı olamam" diyip konuşmayı bitirir; müşteri aynı soruyu üçüncü kez sorar ve gider. İyi tasarlanmış bir sınırın üç çıkışı vardır: ajan yapamayacağını söyler, yapabileceği en yakın şeyi önerir ve gerekiyorsa konuşmayı insana verir.

Akıllı İnsan Devri tam olarak bu noktada devreye girer: karmaşık ya da hassas durumlarda konuşma tüm bağlamıyla doğru temsilciye aktarılır. Devir bir başarısızlık değil, sınırın çalıştığının kanıtıdır. Ölçmeniz gereken şey devir oranının sıfır olması değil, devirlerin doğru sebeple gerçekleşmesidir.

Bir ihlalin en tehlikeli biçimi, ajanın yasağı çiğnemesi değil, bilmediği bir şeyi biliyormuş gibi anlatmasıdır. Modelin ne zaman yanıldığını tanımak guardrail tasarımının parçasıdır: kaynak gösteremediği bir iddiayı ajanın hiç kurmaması, kurup sonra düzeltmesinden iyidir. Aynı mantık kanaldan bağımsız geçerlidir; telefonda konuşan bir ajanda ise geri alma imkanı hiç olmadığı için sınırlar yazılı kanallara göre daha dar tutulur.

Yazdığınız sınırın gerçekten tuttuğunu nasıl test edersiniz?

Guardrail yazmak kolay, tuttuğunu göstermek zordur. Testin birinci kuralı: sınırı, onu aşmaya çalışan cümlelerle deneyin. Nazik sorularla test etmek hiçbir şey kanıtlamaz. "Fiyatta bir esneklik var mı, yöneticinize sorabilir misiniz, rakip şu rakamı verdi" gibi baskı cümleleri, gerçek konuşmalarda karşınıza çıkacak cümlelerdir.

Test ve Önizleme paneli ajanı yayına almadan önce gerçek senaryolarla denemenizi sağlar; burada yalnızca yanıtları değil, ajanın hangi aksiyonu çağırdığını da görürsünüz. Bir sınırın tuttuğunu anlamanın yolu, ajanın kibar bir cümle kurmasına bakmak değil, yasaklı aksiyonun hiç çağrılmamış olmasına bakmaktır. Playbook tarafındaki yan etkisiz prova modu aynı işi akış düzeyinde yapar: adımlar çalışır, sonuçlar görünür, hiçbir kayıt değişmez.

Yönlendirme eşiğini değiştirirken de aynı disiplin geçerlidir; Çoklu Ajan Yönlendirme yeni bir kuralı önce gölge modda ölçmenize izin verir, kararın neden o ajana çıktığını açıklama panelinde görürsünüz. Test senaryolarını yazarken istemi net kurmanın pratiğinden yararlanın: belirsiz bir test cümlesi, belirsiz bir sonuç verir.

Sınırların işlediğini hangi kayıtlardan okursunuz?

Bir guardrail'in değeri, ihlal olmadığı sürece görünmez. Bu yüzden ölçüm dolaylıdır: ajanın ne yaptığına değil, ne yapmayı denediğine bakarsınız. Çalışma İzi tüm ajanların çalıştırmalarını tek akışta toplar; her aksiyonun parametresi, sonucu, süresi ve onaylayanı kayıt altındadır. Bir müşteri "bana şu söylendi" dediğinde tartışma değil, kayıt vardır.

Ajan İçgörüleri ise aynı loglardan toplu resmi çıkarır: hangi aksiyon ne sıklıkla çalışıyor, nerede takılıyor, ne kadar kredi yakıyor. Bir aksiyonun onay kuyruğunda sürekli birikmesi genellikle sınırın yanlış yere konduğunu gösterir — ya çok geniş yasaklamışsınızdır ya da o işi hiç ajana vermemeniz gerekir. AI Analitiği tarafında insana devir kırılımı ve ajan karşılaştırması, hangi senaryoyu düzelteceğinizi tahminle değil veriyle seçmenizi sağlar.

Maliyet de bir sınır türüdür. Ajan Başına Kredi Tavanı ile her ajana aylık tavan koyarsınız; tavanı aşacak bir çalıştırma daha başlamadan durdurulur. Sonsuz döngüye giren bir ajanın faturayı şişirmesi, yanlış bir cümle kurmasından daha sessiz ama daha pahalı bir arızadır.

Bu üç ekranı birlikte okumanın pratik bir yolu var: ayda bir kez, engellenen ya da onay bekleyen aksiyonların listesini alıp her satır için "bu doğru karar mıydı" sorusunu sormak. Cevabın "hayır, aslında yapabilirdi" olduğu satırlar sınırın gereğinden geniş çizildiğini; "iyi ki yapamadı" olduğu satırlar ise sınırın tam yerinde durduğunu gösterir. Bu okuma yarım saat sürer ve ajanın yetkisini genişletme kararlarının tamamını besler.

Bu listeyi kim sahiplenir ve ne sıklıkla güncellenir?

Guardrail listesi sahipsiz kaldığında iki yönde bozulur: ya kimse dokunmadığı için ajan giderek işe yaramaz hale gelir, ya da herkes eklediği için içinden çıkılmaz bir metne dönüşür. Sağlıklı kurulumda listenin tek bir sahibi olur — genellikle ajanın çalıştığı sürecin sorumlusu — ve değişiklikler onun onayından geçer.

Gözden geçirme takvimi basit tutulabilir: her ay devir kayıtlarına ve onay kuyruğuna bakılır, çeyrekte bir de tüm liste satır satır okunur. Her satır için tek soru sorulur: bu sınır son üç ayda bir kez bile tetiklendi mi? Hiç tetiklenmeyen sınır ya gereksizdir ya da yanlış yazılmıştır. Sık tetiklenen sınır ise genellikle bir eğitim ihtiyacına işaret eder; müşteriye giden mesajların nasıl kurulduğunu yeniden düşünmenin zamanı gelmiş demektir.

Bir ajanı sınırlarıyla birlikte kurmak, onu sonradan frenlemeye çalışmaktan çok daha kolaydır; kendi yasak listenizi çıkarıp deneyerek görmek isterseniz Rocketly hesabınızı ücretsiz açıp bir ajanı test panelinde deneyebilirsiniz.

Sıkça sorulan sorular

Guardrail koymak ajanı işe yaramaz hale getirir mi?

Aksine, dar ve net sınırlı bir ajana daha çok iş devredilir. Sınırsız bir ajanı kimse gerçek müşteri konuşmalarına açmaz; sınırları yazılı olan ajan ise izlenebildiği için yetkisi genişletilebilir.

Sınırları istemde yazmakla ayrı bir ekranda tanımlamak arasındaki fark nedir?

İstemdeki cümle modelin yorumuna açıktır ve konuşma uzadıkça etkisi zayıflar. Deklaratif tanımlanan sınır ise çalışma anında zorunlu tutulur; ajan o aksiyonu çağırmayı denese bile işlem gerçekleşmez.

Her yasak için ayrı bir satır mı yazmak gerekir?

Hayır. Önce kategori bazında yazın: taahhüt, kişisel veri, geri alınamaz işlem, kapsam dışı konu. Ayrıntılı satırları ancak gerçek bir olay yaşandığında ekleyin; olaydan doğmayan yasaklar genellikle hiç tetiklenmez.

Ajan bir sınırı aşmaya çalıştığında bunu nasıl fark ederim?

Çalışma izinde her aksiyonun parametresi, sonucu ve onaylayanı görünür; engellenen denemeler de bu akışta kalır. Ajan içgörüleri aynı kayıtları toplulaştırarak hangi sınırın ne sıklıkla devreye girdiğini gösterir.