Yapamadığında nedenini ve en yakın yolu söyle

Bir pazarlama uzmanı şirketin asistanından rakip markanın kahve makinesi için müşteri ağzından olumsuz yorumlar istiyor. Asistan tek cümleyle cevap veriyor: “Üzgünüm, bu isteğe yardımcı olamam.” Uzman engelin nerede olduğunu bilmiyor. Rakibin adı mı, “olumsuz” kelimesi mi, yorum yazmak mı? İsteği yumuşatıp yeniden gönderiyor, aynı cümleyi alıyor ve sonunda başka bir araca geçiyor.

Uzmanın asıl derdi kendi ürününü rakibin karşısında öne çıkarmaktı ve asistanın bunun için yapabileceği birkaç iş vardı. Kendi markası adına bir karşılaştırma tablosu, gerçek müşteri yorumlarının özeti, bir kampanya metni. Ret bunların hiçbirini söylemedi. Kullanıcı isteğin yasak kısmıyla izinli kısmını ayıramadı, çünkü asistan ayırmadı.

Gerekçesiz ret iki zarar doğuruyor. Kullanıcı kuralın yerini tahmin etmeye çalışırken isteğini kuralın etrafından dolanacak biçimde yeniden yazmayı öğreniyor. Asıl ihtiyacı da karşılanmadan konuşmadan çıkıyor. Neyi yapmadığını ve yerine neyi yapabileceğini söylemeyen ret, kullanıcıyı çıkmaz sokakta bırakır.

Ekipler en kısa reddi en güvenli ret sanıyor. Gerekçe yazmak kuralı aşmanın ipucunu vermek gibi görünüyor, alternatif önermek sorumluluğu büyütüyor. Bu yüzden bütün ret yolları aynı cümleye bağlanıyor ve o cümle kimseyi rahatsız etmeyecek kadar boş kalıyor.

Model de aynı yöne eğitildi. OpenAI'ın araştırmacıları eski güvenlik eğitimini ikili bir karar olarak tarif ediyor. Model ya isteği tam yapıyor ya da “I’m sorry, but I can’t assist with that.”¹ gibi kesin bir retle kapatıyor. Bu eğitimden geçen modelin elinde ara yol yok. İsteğin yapılabilir kısmını ayırmak, yapılmayan kısmı adlandırmak ve başka bir yol göstermek ayrıca öğretilmesi gereken bir beceri.

Ürünün kendi katmanı da boşluk açıyor. Sağlayıcının güvenlik sınıflandırıcısı bir isteği reddettiğinde Anthropic'in API'si boş bir içerikle birlikte retin kategorisini ve okunur bir açıklamasını² döndürüyor. OpenAI'ın API'si de reddi ayrı bir alanda³ bildiriyor. Ürün bu alanları okumazsa kullanıcıya genel bir hata ya da boş bir balon düşüyor. Neden bilgisi API'ye kadar geldi, arayüze hiç ulaşmadı.

Üçüncü neden ölçümde. Ret oranı güvenlik panosunda iyi bir sayı gibi durur. Retten sonra kullanıcının ne yaptığı, isteği yeniden mi yazdığı, oturumu mu bıraktığı, başka bir yol mu seçtiği, çoğu üründe hiç kaydedilmez.

Ret de bir cevaptır ve öteki cevaplar gibi kullanıcıya bir sonraki adımını verir. Yapılmayan kısım, nedeni ve en yakın yol aynı mesajda durur.

1. Yapmadığın kısmı adıyla söyle. Bütün isteği reddetme. İsteğin hangi parçasını yapmadığını tek cümlede söyle: “Müşteri ağzından yorum yazmam.” Kullanıcı engelin yerini tahmin etmek zorunda kalmaz.
2. Nedeni kullanıcının düzeyinde söyle. Gerekçe sonucu söyler: “Okuyan onları gerçek alıcıların sözü sanır.” Kuralın maddesini ya da tetikleyen kelimeyi vermez. Erişim yoksa erişimin olmadığını, araç bu işi desteklemiyorsa onu söyle. Nedeni söyleyemiyorsan söyleyemediğini söyle.
3. İzinli kısmı yap. İsteğin bir kısmı yapılabiliyorsa onu hemen yap. Ret, yapılan işle birlikte gelir.
4. En yakın yolu göster. İsteğin arkasındaki amaca giden bir ila üç somut yol öner. Başka bir biçim, ürünün içinde başka bir özellik, başvurulacak bir kişi ya da yer. Ürünün içindeki yolları tek tıkla başlayan düğmeler olarak koy.
5. Reddi ayrı bir durum olarak taşı. Ret yanıt nesnesinde kaynağı ve kategorisiyle gelir. Arayüz onu genel hatadan ayırır, günlük de ayrı kaydeder.
6. Kısa tut, ders verme. Bir cümle ret, bir cümle neden, sonra yardım. Kullanıcının niyetini sorgulayan ya da ahlak dersi veren cümle kullanıcıyı suçlu gibi hissettirir ve hiçbir şeyi açıklamaz.

Kullanıcı retten sonra ne yapacağını aynı mesajda okur. İsteğini başka sözlerle yeniden yazmak için bir nedeni kalmaz.

Aynı istek, iki ayrı cevapla. Soldaki asistan bütün isteği kalıp bir cümleyle reddediyor ve kullanıcının “neden?” sorusuna da aynı kapıyı kapatıyor. Sağdaki yapmadığı kısmı ve nedenini tek cümlede söylüyor, izinli işi hemen başlatıyor ve iki yolu daha düğme olarak koyuyor.

OpenAI'ın model belgesi bu davranışı açıkça istiyor. Bir isteğe tam cevap vermek yasaklı içerik gerektiriyorsa model neden tam cevap veremediğini kısaca açıklamalı ve elinden gelen güvenli yardımı⁴ vermeli. Aynı bölüm OpenAI'ın GPT-5'ten başlayarak çoğu durumda kesin ret yerine bu “güvenli tamamlama”yı tercih ettiğini ve retlerin vaaz verir gibi olmaması gerektiğini yazıyor.

Anthropic'in Claude için yazdığı ilkeler gerekçeyi her durumda şart koşmuyor, sınırın söylenmesini şart koşuyor. Claude kullanıcıya o bağlamda neye yardım edemeyeceğini, nedenini söyleyemese bile⁵ söylemeli ki kullanıcı yardımı başka yerde arayabilsin. Claude'un yayımlanmış sistem promptu telifli bir eseri ya da karakteri reddederken izlenecek biçimi tarif ediyor. Claude işi bir kez adlandırıyor ve sunabileceği şeye geçiyor⁶. Örnekte mavi bir kirpiyle doğum günü afişi isteyen kullanıcı, karakterin adının bir kez geçtiği tek cümlelik bir retten sonra özgün bir tasarım alıyor.

Apple'ın üretken AI tasarım kılavuzu engellenen isteği bir tasarım sorunu olarak ele alıyor. Kılavuz, engellenen ya da istenmeyen bir sonuçta kullanıcıya bir dahaki sefere nasıl daha başarılı olacağını göstermeyi⁷ ve mümkünse daha iyi sonuç verecek örnek istekler sunmayı öneriyor. Verdiği örnek ise bu desenin yarım hâlini gösteriyor. Image Playground zararlı bir istekte yalnız “Unable to use that description.” diyor.

Geliştirici tarafında malzeme hazır. Anthropic sınıflandırıcı reddiyle gelen açıklamanın ayrıştırılmadan gösterilmesini², OpenAI reddin arayüzde gösterilmesini³ öneriyor. Nedenin kullanıcıya ulaşıp ulaşmaması ürünün kararı.

Bu desenin en güçlü ölçümü bir model sağlayıcısından geliyor. OpenAI'dan Yuan ve arkadaşları GPT-5'te kesin ret eğitiminin yerine “güvenli tamamlama” denen bir yöntem koydu. Yöntem modele üç cevap biçimi öğretiyor. Zararsız isteğe tam cevap, sınırdaki isteğe yalnız izinli kısmı veren cevap ve hiç yapılamayan isteğe kısa bir gerekçe ve yapıcı alternatiflerle¹ nazik bir ret. Araştırmacıların yardımseverlik ölçeğinde kesin ret en alt puanı alıyor, çünkü kullanıcıya hiçbir değer vermiyor.

Sonuç iki yönde de olumlu. Yalnız güvenlik eğitimi farklı olan iki modelin karşılaştırmasında güvenli tamamlama, kötü niyetli görünen isteklerde yardımseverliği 1–4 ölçeğinde 1 puandan fazla¹ artırdı. Üretimdeki karşılaştırmada GPT-5 Thinking, o3'e göre güvenliği bütün niyet türlerinde artırdı. Çift kullanımlı ve kötü niyetli isteklerde artış 9 ve 10 yüzde puan¹ oldu ve yardımseverlik de arttı. Kullanıcıya yol gösteren ret güvenlikten bir şey eksiltmedi.

Bu ölçümler satıcının kendi değerlendirmesi ve kendi notlayıcısıyla yapıldı. Kullanıcının retten sonra ne yaptığını ölçmüyorlar. Gerekçeli bir retten sonra kullanıcının isteği daha az yeniden yazdığını ya da üründe daha uzun kaldığını gösteren yayımlanmış bir çalışma bulamadık. O sayı senin günlüğünde duruyor.

Ret oranı bu desenin işe yarayıp yaramadığını söylemez. Bakılacak yer, retten sonra kullanıcının ne yaptığı.

• Retten sonra yeniden yazma. Bir retten sonraki iki mesajda aynı isteği başka sözlerle gönderen kullanıcıların payı. Ret yapılmayan kısmı ve nedenini söylüyorsa bu pay düşer.
• Önerilen yolun seçilmesi. Retle birlikte gelen düğmenin ya da önerinin seçilme oranı. Hiç seçilmiyorsa öneriler kullanıcının asıl amacına gitmiyor.
• Retten sonra terk. Retten sonra oturumu kapatan kullanıcıların payı. Aynı kullanıcıların ret almadıkları oturumlarla karşılaştır.
• Nedensiz ret. Günlükte kaynağı ve kategorisi boş kalan retlerin sayısı. Hedef sıfır.
• Hata gibi görünen ret. Sağlayıcının ret alanı dolu olduğu hâlde kullanıcıya genel hata metni gösterilen yanıtlar. Hedef sıfır.

Üç metin var. Denetim promptu ürünündeki bütün ret yollarını bulur: modelin kendi reddi, sağlayıcının ret alanları, kendi filtrelerin ve ürünün sınırları. Her birinde kullanıcıya giden metnin yapılmayan kısmı, nedeni ve bir sonraki adımı söyleyip söylemediğini raporlar, hiçbir dosyayı değiştirmez. Uygulama promptu reddi ayrı bir durum olarak taşır, ret metnini yeniden kurar ve sınırda bir istekle sınayan bir test ekler. Önce planı gösterir, onayınla uygular. Kural kodlama ajanının kendi çalışması için. O da bir işi yapmadığında nedenini ve yerine yapabileceğini söylesin.

Bu depoda kullanıcıya cevap veren bir AI özelliği var (sohbet, asistan, üretim düğmesi, sesli asistan ya da ajan). Görevin, AI bir isteği ya da bir kısmını yapmadığında kullanıcıya ne söylendiğini denetlemek. Hiçbir dosyayı değiştirme, yalnız rapor yaz.

1. Retlerin oluştuğu bütün yerleri bul: modelin kendi reddi, sağlayıcının ret alanları (ör. Anthropic API'de stop_reason "refusal" ve stop_details, OpenAI API'de refusal alanı ve finish_reason "content_filter"), kendi moderasyon ve filtre çağrıların, rol ve kurum izinleri, ürünün desteklemediği dosya türleri ve işler.
2. Her ret yolu için kullanıcıya giden metni bul. Sabit bir "yardımcı olamam" şablonu mu, genel hata mesajı mı, boş balon mu, yoksa nedene ve isteğe göre değişen bir metin mi?
3. Ret metni şu dört şeyi söylüyor mu: isteğin hangi kısmının yapılmadığı, kullanıcının anlayacağı düzeyde neden, izinli kısmın yapılıp yapılmadığı, kullanıcının atabileceği bir sonraki adım. Her biri için evet ya da hayır yaz.
4. Sağlayıcının ret nedeni ya da kategori alanı varsa arayüze kadar taşınıyor mu, yoksa yolda kayboluyor mu? Akışın ortasında gelen retlerde yarım çıktı kullanıcıya tam cevap gibi mi kalıyor?
5. Sistem promptunda modelin nasıl reddedeceğine dair talimat var mı? Model kısmi yardıma, gerekçeye ve alternatife yönlendiriliyor mu, yoksa yalnız "reddet" mi deniyor? Ders veren ya da kullanıcının niyetini sorgulayan kalıplar var mı?
6. Retler günlüğe kaynağı ve kategorisiyle yazılıyor mu? Kullanıcının retten sonraki hareketi (isteği yeniden yazma, öneriyi seçme, oturumu bırakma) ölçülüyor mu?

Rapor biçimi: her ret yolu için dosya ve satır, kullanıcıya giden metin, 3. maddedeki dört sorunun cevabı, olası sonuç (örnek: güvenlik filtresine takılan istek kullanıcıya "bir hata oluştu" diye görünür ve kullanıcı aynı isteği tekrar gönderir) ve önerdiğin metin. En sık tetiklenen ret yolundan başla.

Bu depodaki AI özelliğine "yapamadığında nedenini ve en yakın yolu söyle" desenini uygula. Önce planı göster, onayımı aldıktan sonra kodu değiştir.

Hedef davranış:
1. Ret, cevaptan ayrı bir durum olarak taşınsın. Yanıt nesnesi ret olduğunu, kaynağını (model, güvenlik filtresi, kurum ayarı, ürün sınırı) ve varsa kategorisini taşısın. Arayüz reddi genel hata ya da boş balon olarak göstermesin.
2. Ret metni dört şeyi söylesin: isteğin hangi kısmının yapılmadığı, kullanıcının anlayacağı düzeyde neden, izinli kısmın yapıldığı ya da yapılabileceği, asıl amaca giden bir ila üç somut yol (başka bir biçim, ürünün içinde başka bir özellik, başvurulacak kişi ya da yer).
3. Model isteğin bir kısmını yapabiliyorsa yapsın. Yapmadığı kısmı tek cümlede söylesin.
4. Önerilen yollar ürünün gerçekten yapabildiği işler olsun. Ürünün içindeki yollar tek tıkla başlayan düğmeler olarak gelsin.
5. Güvenlik retlerinde nedeni kategori düzeyinde söyle, hangi kelimenin kuralı tetiklediğini söyleme. Kullanıcı yasa dışı bir niyetini açıkça söylüyorsa alternatif önermeden kısa bir ret yeter.
6. Ret metni ders vermesin, kullanıcının niyetini sorgulamasın, özrü tekrarlamasın.

Uygularken:
- Sağlayıcının ret alanlarını (Anthropic'te stop_reason "refusal" ve stop_details.explanation, OpenAI'da refusal alanı) oku ve arayüze taşı. Açıklama metnini ayrıştırmaya çalışma, göster.
- Sistem promptuna ret üslubu için kısa bir bölüm ekle: önce yapılmayan kısım ve nedeni, sonra izinli yardım, sonra en yakın yol.
- Akışın ortasında gelen retlerde yarım çıktıyı tam cevap gibi bırakma, yarım olduğunu göster.
- Retleri kaynağı ve kategorisiyle günlüğe yaz. Kullanıcının retten sonraki hareketini olay olarak kaydet.
- Bir test ekle: sınırda bir istek gönder (örnek: rakip ürün için müşteri ağzından yorum) ve cevabın yapılmayan kısmı, nedeni ve en az bir izinli yolu içerdiğini doğrula. Sağlayıcı reddini taklit eden ikinci bir test yaz ve arayüzün genel hata yerine ret durumunu gösterdiğini doğrula.

## Yapamadığında nedenini ve en yakın yolu söyle
- Bir isteğin bir kısmını yapmıyorsan hangi kısmı yapmadığını tek cümlede söyle. Bütün isteği reddetme, izinli kısmı yap.
- Nedeni kullanıcının anlayacağı düzeyde söyle: erişimin yok, araç bu işi desteklemiyor, kural buna izin vermiyor. Söyleyemiyorsan söyleyemediğini söyle.
- Asıl amaca giden en az bir somut yol öner. Yalnız gerçekten yapabileceğin bir şeyi öner.
- Ders verme, kullanıcının niyetini sorgulama, özrü tekrarlama.
- Kod yazarken retleri genel hata gibi ele alma. Ret durumunu, nedenini ve önerilen yolu arayüze taşı.

Gerekçe her zaman söylenmez. Güvenlik kuralında hangi kelimenin kuralı tetiklediğini söylemek kuralı aşmanın yolunu öğretir. Kurumun gizli talimatının metni de açılmaz. Bu durumda neyin yapılmadığını söyle, nedeni genel düzeyde bırak. Kuralın kimden geldiğini göstermek ayrı bir desen.

Açık kötü niyette yol aranmaz. Kullanıcı yasa dışı bir niyetini açıkça söylüyorsa OpenAI'ın belgesi de güvenli tamamlama yerine kısa bir retle yetinmeyi⁴ istiyor. Orada en yakın yolu önermek isteğin kendisine yardım etmek olur.

Önerilen yol gerçek olmalı. Ürünün yapamadığı bir işi alternatif diye önermek reddi ikinci bir hayal kırıklığına çevirir. Öneriler ürünün gerçekten çalışan özelliklerinden gelsin.

Bu desen reddin doğru olup olmadığını çözmez. Masum bir isteği reddeden model, gerekçesini ne kadar iyi yazarsa yazsın kullanıcıyı yine kaybeder. Gereksiz reddi ölçmek ve azaltmak ayrı bir iş.