AI Red Teaming Nedir? LLM Güvenlik Testi Rehberi

2025 yılının başında büyük bir Türk finans kurumu, müşteri danışmanlık yapay zekasını canlıya almadan bir hafta önce özel bir güvenlik ekibine verdi. Ekip üç saat içinde on bir farklı açık buldu. Bunların bir kısmı modeli ırkçı tavsiyeler vermeye zorlayan prompt dizileriydi. Bir kısmı gizli sistem talimatlarını sızdıran sorgulardı. Biri ise modeli rakip bankaların ürünlerini önermeye yönlendiren bir jailbreak zinciriydi. Hiçbiri önceki statik testlerde, kural tabanlı filtrelerde ya da birim testlerinde yakalanmamıştı.

Bu hikaye artık istisnai değil. Kurumsal AI dağıtımları hızlandıkça, sistem güvenliğini test etmenin yeni bir disipline dönüştüğü bir dönemden geçiyoruz. Bu disiplinin adı AI red teaming.

AI Red Teaming Nedir?

Red teaming, bir sistemi korumaya çalışan tarafın değil, ona saldırmaya çalışan tarafın bakış açısını benimseyerek yapılan güvenlik testidir. Askeri planlama geleneğinden siber güvenliğe, oradan da yapay zeka sistemlerine taşınan bu yaklaşım, testin değerini tam olarak bu perspektif kaymasından alır: kendi sistemini “düşman gibi” sorgulamak.

Geleneksel siber güvenlik red teaming’inden temel fark, saldırı yüzeyinin tanımsız olmasıdır. Bir web uygulamasını test ederken giriş noktaları bellidir; SQL injection, XSS, açık portlar gibi teknikler sistematik biçimde uygulanabilir. LLM testinde ise giriş alanı doğal dildir ve teorik olarak sonsuzdur. Modelin bir güvenlik açığı sergilemesi için gerekli prompt belirli bir kelimeden, belirli bir ton değişikliğinden ya da birden fazla konuşma turunda kurulan bağlamdan kaynaklanabilir.

AI red teaming’in özgün zorluğu da buradan geliyor. Model deterministik değildir; aynı prompt farklı çalıştırmalarda farklı yanıtlar üretebilir. Bu da testin kapsamlı olmasını güçleştiriyor.

Neden LLM’ler Özel Güvenlik Testi Gerektirir?

Klasik yazılım güvenlik araçları LLM’lere doğrudan uygulanamaz. Fuzzing araçları rastgele byte dizileri üretir; bir dil modelinin doğal dilde cevap veren davranış katmanına bu teknikler ulaşmaz. Statik kod analizi, model ağırlıklarını değil uygulama kodunu inceler; model seviyesindeki riskleri görmez.

LLM’lerin özel test gerektirdiği üç temel neden var:

Birincisi, giriş yüzeyi pratik olarak sınırsız. Kullanıcı, modele metin, kod, tablo, hatta bozuk karakter dizisi gönderebilir. “Beklenen girdi” kavramı burada anlamlı değil.

İkincisi, emergent behavior. Büyük modeller eğitim sırasında öğretilmemiş yetenekler sergiler. Bu yetenekler bilinmiyorsa güvenlik testi de onları kapsayamaz.

Üçüncüsü, bağlam birikmesi. Çok turlu konuşmalarda model önceki turları taşır. Saldırgan birinci turda zararsız görünen sorgularla bağlam kurar; beşinci turda bu bağlam bir güvenlik açığını tetikler.

Red Teaming Metodolojisi: Adım Adım

1. Kapsam Belirleme

Her kapsam belirsiz bir test, eksik bulgularla biter. Test öncesinde şu soruların yanıtı yazılı olarak netleştirilmelidir:

• Test edilecek model hangisi? Hangi sürümü, hangi deployment ortamı?
• Sistem promptu dahil mi, yoksa yalnızca kullanıcı girdisi mi test edilecek?
• Hangi tehdit aktörleri modele erişebilir? (dış kullanıcı, iç çalışan, üçüncü taraf entegrasyon?)
• Başarı nasıl tanımlanacak? Hangi bulgular “kritik”, hangisi “düşük risk”?

Bu soruların yanıtlanmadan başlanan test oturumları genellikle sonuçları değerlendirirken çatışmaya yol açar.

2. Tehdit Kategorileri

Red teaming oturumunda hedeflenen tehdit türleri önceden sınıflandırılmalıdır. En yaygın beş kategori şunlar:

Zararlı içerik üretimi: model nefret söylemi, tehlikeli kimyasal talimatlar veya terör propagandası üretmeye yönlendirilebilir mi? Politika ihlallerini kapsayan bu kategori genellikle ilk test alanı olur.

Bilgi sızıntısı: sistem promptu ele geçirilebilir mi? Model PII içeren verilere erişiyorsa bunları sızdırabilir mi?

Görev sapması: belirli bir amaç için kurulan model başka bir amaca çekilebilir mi? Finans asistanı tıbbi tavsiye verebilir mi, müşteri hizmetleri botu siyasi tartışmaya sürüklenebilir mi?

Jailbreak kalıpları: DAN (“Do Anything Now”) tarzı rol oyunları, çok adımlı bağlam manipülasyonu, farklı dil veya kodlamayla filtre atlatma.

Prompt injection: ajanlar ve RAG sistemlerinde özellikle dikkat isteyen bu alan, harici verilerden gelen talimatların modeli ele geçirip geçiremeyeceğini test eder. Web sayfasındaki gizli bir metin bile modelin davranışını değiştirebilir. Daha ayrıntılı bilgi için prompt injection nedir yazısına bakabilirsiniz.

3. Test Teknikleri

Manuel keşif. Deneyimli bir red teamer, modelle gerçek bir saldırgan gibi etkileşime girer. Bu yaklaşım, otomatik araçların göremediği nüanslı zafiyetleri ortaya çıkarır. Aynı zamanda en yüksek maliyetli tekniktir.

Otomatik fuzzing. Garak ve PyRIT gibi araçlar, önceden tanımlanmış saldırı kategorilerinde büyük ölçekte test çalıştırır. Binlerce prompt varyantı kısa sürede uygulanabilir; insan testerın gözden kaçıracağı istatistiksel örüntüler bu yolla yakálanır.

Çok turlu konuşma saldırıları. Saldırı tek bir promptta değil, birden fazla konuşma turunda kurulur. Model, güvenli görünen birkaç turdan sonra hassas içerik üretmeye yönlendirilebilir.

Çapraz dil testleri. Model Türkçe güvenlik politikaları için fine-tune edilmiş ama İngilizce ya da Arapça sorgulara karşı zayıf kalıyor olabilir. Dilsel eşdeğerlik açıkları, özellikle çok dilli deployment’larda sıkça karşılaşılan bir zafiyet türüdür.

4. Araçlar ve Çerçeveler

Microsoft PyRIT. Python tabanlı, açık kaynaklı red teaming çerçevesi. Saldırı senaryoları tanımlamak, büyük ölçekte otomatik testler çalıştırmak ve sonuçları raporlamak için modüler bir yapı sunar. Azure OpenAI ve diğer model sağlayıcılarıyla entegre çalışır.

Garak. NVIDIA destekli LLM zafiyet tarayıcısı. Hallüsinasyon, jailbreak, prompt injection ve veri sızıntısı gibi kategorilerde hazır “probe” setleri barındırır. Komut satırından çalıştırılabilir yapısı CI/CD pipeline entegrasyonunu kolaylaştırır.

Promptfoo. Hem prompt güvenlik testi hem de regresyon testi için kullanılabilir. Model çıktılarını önceden tanımlanmış beklentilerle karşılaştırır; farklı model sürümleri arasında güvenlik davranışı karşılaştırması yapılabilir.

NVIDIA NeMo Guardrails. Test aracının ötesinde hem guardrail tanımlama hem de test için kullanılır. Red teaming sırasında belirlenen açıkları hemen guardrail kuralına dönüştürme iş akışını destekler.

NIST AI Risk Management Framework ve Red Teaming

NIST AI RMF, 2023’ten itibaren kurumsal AI güvenlik standartlarının referans belgesi. Çerçevenin “Measure” işlevi altında red teaming açıkça bir değerlendirme yöntemi olarak tanımlanıyor.

AB Yapay Zeka Yasası’nın (AI Act) Madde 9’u yüksek riskli AI sistemleri için belgelenmeli risk yönetim süreci zorunlu kılıyor. Red teaming, bu risk değerlendirmesinin doğrulanabilir bir bileşeni olarak kullanılabiliyor.

MITRE ATLAS (Adversarial Threat Landscape for Artificial-Intelligence Systems), siber güvenlik alanındaki ATT&CK çerçevesinin AI karşılığı. AI saldırı taktikleri ve tekniklerini kategorize eden bu taksonomi, red teaming kapsamını planlarken başvurulabilecek sistematik bir kaynak.

Yapay zeka güvenliği yazısında bu çerçevelerin genel AI güvenlik yaklaşımlarıyla nasıl ilişkilendiğini daha geniş bir perspektiften bulabilirsiniz.

Kurumsal Red Teaming Programı Nasıl Kurulur?

Dahili ekip mi, dışarıdan hizmet mi?

Dahili bir red team’in avantajı, sistemi ve iş bağlamını derinlemesine bilmesidir. Dezavantajı, aynı zihin haritasını paylaşan bir ekibin “kör nokta” üretmesidir. Dışarıdan hizmet alan bir ekip taze bakış açısı getirir ama sistemi öğrenmesi zaman alır.

Pratikte çoğu kurum ikisini birleştirir. Dahili ekip rutin testleri yürütür; dışarıdan uzmanlar yılda bir ya da iki kez daha derin bir değerlendirme yapar. Bu kombinasyon hem kör nokta riskini hem de maliyeti dengeler.

Test sıklığı ve tetikleyiciler

Red teaming, tek seferlik bir etkinlik değil. Aşağıdaki durumlarda yeni bir test oturumu planlanmalıdır:

• Model yeni bir sürüme geçirildiğinde
• Sistem promptu ya da güvenlik politikası güncellendiğinde
• Yeni bir kullanım alanı veya kullanıcı kitlesi eklediğinde
• Kamuoyuna açık bir jailbreak tekniği modeli hedef aldığında

Bulguları önceliklendirme ve raporlama

Red teaming sonuçları ham haliyle eyleme dönüştürülemez. Her bulgu için şu bilgilerin raporlanması gerekiyor:

• Zafiyetin kategorisi ve spesifik tetikleyicisi
• Yeniden üretim adımları (reproducibility)
• Olası etkisi (kullanıcı zararı, marka riski, yasal risk)
• Önerilen düzeltme yaklaşımı (guardrail mı, fine-tuning mi, sistem prompt değişikliği mi?)

Red Teaming ve Guardrails: Birbirini Tamamlayan İki Katman

Red teaming açıkları bulur. LLM guardrails ise bu açıkları kapatır. İkisi birbirinin alternatifi değil; birbirini besleyen iki ayrı süreç.

Red teaming olmadan guardrail tasarımı, bilinmeyen tehditlere karşı kör savunma yapmak anlamına gelir. Guardrail olmadan red teaming, bulguların uygulamaya geçirilmediği akademik bir egzersiz kalır.

Olgun bir güvenlik programında bu döngü şöyle çalışır: red teaming yeni bir zafiyet kategorisi ortaya çıkarır → guardrail politikası güncellenir → sonraki red teaming oturumu yeni politikanın etkinliğini sınar → döngü devam eder.

Constitutional AI gibi eğitim zamanı hizalama yöntemleri bu denkleme üçüncü bir katman ekler: modeli zararlı davranışları reddetmeye eğitmek. Ama eğitim zamanı hizalama tek başına yeterli değildir; red teaming, hizalamanın gerçek dünya saldırılarına karşı ne ölçüde tutarlı kaldığını doğrular.

Gerçek Dünyadan Vakalar

OpenAI GPT-4 lansman öncesi red teaming. OpenAI, GPT-4’ü kamuoyuyla paylaşmadan önce birkaç ay boyunca harici red teamer gruplarıyla çalıştı. Bu süreçte biyolojik silah talimatları, kimlik taklidi ve hukuki süreçlerden kaçınmaya yönelik tavsiye gibi onlarca zafiyet kategorisi belirlendi, sistem çıkmadan önce güvenlik önlemleri güncellendi.

Meta LLaMA 3 açık kaynak red team süreci. Meta, LLaMA 3’ü kamuoyuyla paylaşmadan önce 350’yi aşkın bağımsız araştırmacıyla red team çalışması yaptı. Bulgular, farklı dillerdeki güvenlik davranışı tutarsızlıklarını ve spesifik “birden fazla tur” saldırı kalıplarını içeriyordu. Sonuçlar meta’nın güvenlik kartıyla birlikte yayımlandı.

Çok dilli deployment açıkları. Büyük bir Avrupa bankasının müşteri hizmetleri LLM’i, İngilizce sorgulara karşı sıkı güvenlik davranışı sergilerken aynı soruların Romence versiyonlarında bu filtreleri atladı. Sorun, güvenlik ince ayarlarının yalnızca İngilizce verilerle yapılmış olmasından kaynaklanıyordu.

Eylem Adımları

Kurumsal bir AI deployment’ı varsa ya da planlıyorsanız, red teaming programını kurmak için makul bir başlangıç noktası şu:

Önce tehdit modeli. Sistemi kim kullanıyor, hangi veriye erişiyor, hangi çıktılar karar süreçlerini etkiliyor? Bu soruların yanıtı olmadan test kapsamı net olamaz.

Sonra ilk manuel oturum. Dışarıdan deneyimli bir red teamer ile sınırlı kapsamlı bir test yapın. Neyi aradığınızı öğrenmek için bile bu oturum değerli.

Ardından otomasyona geçiş. Garak veya PyRIT ile tekrarlanabilir test süreçleri kurun. Her bulguyu kayıt altına alın; iki oturum arasında karşılaştırma yapabilmek için.

Son olarak, guardrail döngüsünü bağlayın. Red teaming bulguları doğrudan guardrail güncellemelerine dönüşecek bir iş akışı tanımlanmazsa, test raporları sonunda çekmecelerde kalır. Model veya politika her değiştiğinde yeni bir döngü tetiklensin.

Prompt engineering ile hem güçlü hem de güvenli sistem promptları nasıl yazılır konusunu da araştırıyorsanız, iyi bir sistem promptunun saldırı yüzeyini baştan nasıl daraltabileceğini görmek için o yazıya da göz atabilirsiniz.

AI red teaming, büyük bir bütçe gerektiren bir lüks değil. Kurumsal AI sistemlerinin üretim ortamına çıkmadan önce geçmesi gereken bir güvenlik olgunluk adımı. Sistemin ne kadar zeki olduğu değil, kötüye kullanıma karşı ne kadar dirençli olduğu, uzun vadeli güveni belirleyecek olan şey.