AI Red Teaming Nedir? Yapay Zekayı Saldırgan Gözüyle Test Etmek

AI red teaming nedir?

AI red teaming, bir yapay zeka sistemini yayından önce ve sonra kasıtlı olarak zorlayıp zararlı, yanlış ya da güvensiz davranışları bulma sürecidir. Test ekibi, kötü niyetli bir kullanıcı gibi düşünür. Amaç suçlu aramak değildir. Amaç, açığı gerçek kullanıcılar bulmadan önce sizin bulmanızdır.

Kısacası, sistemi bozmaya çalışan "iyi niyetli saldırgan" rolünü bir ekip üstlenir. Bu ekip sohbet botunu, yapay zeka ajanını ya da yapay zeka destekli arama kutusunu zorlar. Örneğin gizli bilgiyi sızdıran, kurallara aykırı yanıt veren ya da yetkisiz işlem yapan durumları arar.

Ardından her bulguyu kayıt altına alır ve geliştiricilere iletir. Geliştiriciler düzeltmeyi yapar, ekip aynı senaryoyu yeniden dener. Bu döngü, güvenlik açığı bulmanın yanında güvenilirliği de ölçülebilir hale getirir. Dolayısıyla AI red teaming nedir sorusunun özü, bilinmeyen riski bilinen ve yönetilebilir hale getirmektir.

Bu yazı yalnızca bu terimi işler. Komşu kavramlar için ayrı yazılarımız var, burada onlara kısaca değinip bağlantı veriyoruz. Konu güvenlik olduğu için saldırı tarifi ya da zararlı istem örneği vermiyoruz. Odağımız savunma ve süreçtir.

AI red teaming nedir, basit bir benzetmeyle nasıl anlatılır?

Yeni bir köprüyü düşünün. Trafiğe açılmadan önce mühendisler köprüyü ağır kamyonlarla, sert rüzgarla ve beklenmedik yüklerle sınar. Köprünün çökmesini beklemezler. Ancak çökebileceği noktaları önceden bilmek isterler. Çünkü gerçek hayatta köprü çöktüğünde geri dönüş yoktur.

AI red teaming de aynı işi yapay zeka için yapar. Köprü yerine model, sohbet botu ya da ajan vardır. Yük testi yerine tuhaf, kışkırtıcı ve sınır zorlayan kullanım senaryoları vardır.

Ancak önemli bir fark var. Köprü her seferinde aynı tepkiyi verir. Yapay zeka modeli ise aynı soruya, sözcükler biraz değişince farklı yanıt verebilir. Bu yüzden tek bir test yetmez. Çünkü tek bir başarılı deneme, gerçek kullanımdaki çeşitliliği temsil etmez. Aynı senaryoyu farklı biçimlerde ve birden çok kez denemeniz gerekir.

Terimdeki "red" kelimesi karşı takımı anlatır. Savunmayı kuran ekibe ise "blue team" denir. Pratikte iki ekip aynı kişilerden bile oluşabilir. Önemli olan, bir kişinin bir süreliğine saldırgan şapkasını takabilmesidir.

AI red teaming nedir ve klasik siber güvenlik red team'den farkı nedir?

Klasik red team, genellikle ağları, sunucuları, çalışanları ve bazen fiziksel erişimi hedef alır. Hedef çoğunlukla net bir erişim elde etmektir. Başarı da bellidir: içeri girdiniz ya da giremediniz.

AI red teaming ise sistemin davranışını test eder. Burada başarı daha bulanıktır. Model hiçbir yere sızılmadan da zararlı içerik üretebilir, önyargılı davranabilir ya da gizli bilgiyi sohbet içinde söyleyebilir. Google, yapay zeka red team ekibinin klasik red team ile yakından hizalı olduğunu ancak yapay zekaya özgü uzmanlık gerektirdiğini belirtir.

Farkları şöyle özetleyebiliriz:

• Hedef: Klasik ekip altyapıyı, AI ekibi hem altyapıyı hem modelin davranışını sınar.
• Sonuç: Klasik testte çıktı genelde tekrarlanabilir. AI testinde aynı girdi farklı çıktı verebilir.
• Zarar türü: Klasik testte veri ihlali öne çıkar. AI testinde zararlı içerik, yanlış bilgi ve önyargı da eklenir.
• Ekip yapısı: AI testinde güvenlik uzmanının yanında alan uzmanı ve ürün sahibi de gerekir.

Öte yandan ortak noktalar da çoktur. Örneğin ikisi de önce kapsam çizer, sonra bulguları sahiplerine atar. İki yaklaşım da tehdit modeli kurar, saldırgan davranışı simüle eder ve bulguları raporlar.

AI red teaming nedir, işletmeler için neden önemlidir?

Yapay zeka sistemleri geleneksel yazılım gibi öngörülebilir değildir. Geliştirme sırasında yaptığınız testler, gerçek kullanıcıların yaratıcılığını kapsamaz. Kullanıcılar beklemediğiniz sorular sorar, sistemi sınar ve bazen kasıtlı olarak kötüye kullanır.

Üstelik sistemler büyüdükçe risk de büyür. Bir sohbet botu yalnızca metin yazıyorsa hata sınırlıdır. Aynı bot müşteri verisine erişiyor, e-posta gönderiyor ya da sipariş değiştiriyorsa hata gerçek zarara dönüşebilir.

NIST, yapay zeka risk yönetimi için bir çerçeve yayımlar. Üretken yapay zeka profili ise bu çerçeveyi üretken sistemlere uyarlar ve bu sistemlerin kendine özgü risklerini tanımlar. Bu belgelerde test, değerlendirme ve düşmanca sınama yaklaşımları risk yönetiminin parçası olarak yer alır.

Dolayısıyla red teaming bir lüks değildir. Müşteriye açılan her yapay zeka özelliği için makul bir ön koşuldur. Ayrıca sorunu siz bulursanız, itibar ve hukuki sonuçlarını da siz yönetirsiniz. Bu bir hukuki danışmanlık değildir; veri koruma yükümlülükleriniz için uzmanınıza danışın.

AI red teaming hangi riskleri test eder?

Her proje farklıdır, ancak ekipler genellikle birkaç ana risk ailesine bakar. Aşağıdaki liste, bir işletme chatbotu için sık görülen başlıkları özetler.

• Zararlı içerik: Model, politikanıza aykırı, saldırgan ya da tehlikeli içerik üretiyor mu.
• Veri sızıntısı: Sistem, sistem talimatını, başka kullanıcının bilgisini ya da dahili belgeyi açığa çıkarıyor mu.
• İstem enjeksiyonu: Kullanıcı ya da dış içerik, modelin talimatlarını geçersiz kılabiliyor mu. Ayrıntısı için prompt injection yazımıza bakın.
• Önyargı: Yanıtlar belirli gruplara karşı adaletsiz davranıyor mu. Konuya yapay zeka önyargısı rehberimizden devam edebilirsiniz.
• Ajan yetki aşımı: Ajan, tanımlı yetkisinin dışında bir araç ya da işlem kullanabiliyor mu.

Bunlara ek olarak ekipler uydurma bilgi riskini de ölçer. Bu konu ayrı bir terimdir ve halüsinasyon yazımızda anlatılır. Veri tarafında eğitim verisinin bozulması ise veri zehirleme yazımızın konusudur.

Hangi riskin öncelikli olduğunu ürününüz belirler. Dolayısıyla başka bir şirketin listesini olduğu gibi kopyalamayın. Kişisel veri işleyen bir mağaza botu için gizlilik ve yetki sınırı, çoğu zaman en kritik başlıktır.

AI red teaming'i kimler yapar?

Üç ana yaklaşım vardır ve çoğu olgun program bunları birlikte kullanır.

• İç ekip: Ürünü en iyi tanıyan kişilerdir. Hızlı ve ucuzdurlar. Ancak sistemi kendi yaptıkları için kör noktaları olabilir.
• Dış uzman: Farklı bir bakış açısı ve saldırı deneyimi getirir. Bağımsız olması bulguların güvenilirliğini artırır.
• Otomatik araç: Çok sayıda senaryoyu hızlıca dener ve yeni sürümlerde tekrar çalıştırılabilir. Fakat yaratıcı, bağlama özgü açıkları tek başına bulamaz.

Microsoft gibi sağlayıcılar, üretken yapay zeka sistemlerini sınamak için otomasyon çerçeveleri ve rehberler yayımlar. Bu tür araçlar kavram olarak işe yarar. Yine de insan muhakemesinin yerini almaz. Çünkü hangi bulgunun gerçekten önemli olduğuna ancak bağlamı bilen biri karar verir.

Ekip kurarken tek bir uzmanlığa güvenmeyin. İdeal karışım şöyledir: bir güvenlik uzmanı, ürünü bilen biri ve alan bilgisi olan bir temsilci. Örneğin müşteri hizmetleri botunu test ederken, gerçek müşteri sorularını bilen bir destek çalışanı çok değerli olur.

Otomatik testler ile insan testi nasıl dengelenir?

Otomatik testler hız ve tekrar sağlar. Yüzlerce senaryoyu birkaç dakikada çalıştırır, her yeni sürümde aynı seti yeniden denersiniz. Bu sayede gerilemeleri erken yakalarsınız.

Ancak otomasyon yalnızca sizin tanımladığınız senaryoları ve değerlendirme ölçütlerini bilir. Yaratıcı bir kullanıcının aklına gelecek beklenmedik yolları keşfetmesi zordur. İnsan testçi ise bağlamı okur, sezgisini kullanır ve "bu cevap teknik olarak doğru ama yanıltıcı" diyebilir.

Bu nedenle dengeyi iki katmanla kurmanızı öneririz. İlk katmanda insanlar yeni riskleri keşfeder ve senaryo üretir. İkinci katmanda otomasyon, bulunan senaryoları sürekli koşturur.

Özetle keşif insana, tekrar makineye aittir. Otomatik değerlendirmede bir başka modeli yargıç olarak kullanmak mümkündür, ancak bu yaklaşımın kendi sınırları vardır. Ayrıntıyı evals yazımızda bulabilirsiniz.

AI red teaming ekibinde hangi beceriler gerekir?

Güçlü bir ekip tek bir alandan gelmez. Aşağıdaki beceriler bir arada olduğunda sonuç daha sağlam olur.

• Güvenlik düşüncesi: Bir sistemi saldırgan gözüyle okuyabilmek.
• Alan bilgisi: İşin gerçekte nasıl yürüdüğünü ve hangi hatanın pahalı olduğunu bilmek.
• Yapay zeka okuryazarlığı: Modelin neden tutarsız davranabildiğini anlamak.
• Yazarlık becerisi: Bulguları net, kısa ve eyleme dönük anlatabilmek.
• Etik duyarlılık: Zarar potansiyeli olan içerikle sorumlu biçimde çalışmak.

Ayrıca merak, bu işin en önemli yumuşak becerisidir. İyi bir testçi "Bu sistem şunu yaparsa ne olur?" sorusunu sürekli sorar.

Ekibinizde bu becerilerin hepsi yoksa dış destek almak mantıklıdır. Yine de ürünü iyi bilen iç ekibin sürece katılması şarttır, çünkü dış uzman iş bağlamını sizin kadar bilemez.

AI red teaming süreci hangi adımlardan oluşur?

Süreci beş adımlık bir döngü olarak düşünebilirsiniz. Her adımın çıktısı bir sonrakine girdi olur.

1. Kapsam: Neyi, hangi ortamda ve hangi kurallarla test edeceğinizi yazın.
2. Senaryo: Hangi kötüye kullanım ya da hata durumlarını deneyeceğinizi belirleyin.
3. Kayıt: Her denemeyi, gözleminizi ve etkisini düzenli biçimde not edin.
4. Düzeltme: Bulguları önem sırasına göre sahiplerine atayın ve çözümü uygulayın.
5. Tekrar test: Aynı senaryoyu ve yakın varyasyonlarını yeniden deneyin.

Döngü bir kez bitip kalmaz. Model sürümü, sistem talimatı, bağlı araçlar ya da bilgi kaynağı değiştiğinde davranış da değişebilir. Bu nedenle red teaming, tek seferlik bir denetim yerine düzenli bir alışkanlık olmalıdır.

Aşağıdaki bölümlerde, özellikle kapsam, kayıt ve düzeltme adımlarını ayrıntılandırıyoruz. Ayrıca bu adımların hangi sırayla ve hangi kişilerle yürütüleceğini de göreceksiniz.

Kapsamı ve senaryoları nasıl belirlersiniz?

İlk olarak sisteminizi bir haritaya dökün. Kullanıcılar kim, sistem hangi verilere erişiyor, hangi araçları çağırıyor ve hangi çıktılar zarar verebilir? Bu sorular, hangi riske öncelik vereceğinizi gösterir.

Ardından "kabul edilemez sonuçlar" listesi çıkarın. Bu liste, testin başarı ölçütü olur. Örneğin başka bir müşterinin bilgisinin görünmesi, onaysız para iadesi ya da markanıza uymayan bir yanıt bu listede yer alabilir.

Bir senaryo üç parçadan oluşur: amaç, bağlam ve beklenen güvenli davranış. Burada saldırıyı değil, hedefi tanımlarsınız. Örneğin "bot, kimliği doğrulanmamış kullanıcıya sipariş bilgisi vermemeli" cümlesi bir senaryo başlığıdır.

Kuralları da baştan yazın. Testi yalnızca yetkili olduğunuz sistemde ve mümkünse ayrı bir test ortamında yapın. Gerçek müşteri verisini kullanmayın. Ayrıca testi kimin onayladığını ve nelerin sınır dışı olduğunu belgeleyin.

Başkasına ait bir sistemi izinsiz sınamak, iyi niyetle bile olsa sorun yaratır. Yetkiniz yoksa yapmayın.

Bulguları nasıl kaydeder ve önceliklendirirsiniz?

İyi bir kayıt, bulguyu başka biri okuyup yeniden üretebilsin diye tutulur. Her bulgu için aşağıdaki alanları doldurmanızı öneririz.

• Senaryo adı ve hedefi.
• Sistem sürümü, talimat sürümü ve test tarihi.
• Gözlenen davranış ile beklenen davranışın kısa özeti.
• Bulgunun kaç denemede kaç kez tekrarlandığı.
• Olası etki: veri, para, itibar ya da güvenlik.
• Önem derecesi ve sorumlu kişi.

Model çıktıları değiştiği için tek bir başarılı deneme yeterli kanıt sayılmaz. Aynı senaryoyu birkaç kez çalıştırın ve görülme sıklığını yazın. Bu sayede "bazen oluyor" belirsizliği, ölçülebilir bir bilgiye dönüşür. Böylece ekip, gerçekten kritik olanı ayırt eder.

Önceliği etki ile olasılığın çarpımı gibi düşünün. Sık görülen ve gizli veri ifşa eden bir bulgu önce gelir. Nadir görülen ve düşük etkili bir bulgu bekleyebilir.

Zararlı çıktıların ham metnini geniş bir kitleyle paylaşmayın. Raporu yalnızca gerekli kişilerin erişebildiği bir yerde tutun.

Düzeltme ve tekrar test nasıl işler?

Düzeltme tek bir yöntemle sınırlı değildir. Soruna göre farklı katmanlara müdahale edersiniz.

• Sistem talimatını ve görev sınırlarını netleştirmek.
• Girdi ve çıktıya guardrails eklemek.
• Araçların yetkisini en dar düzeye çekmek ve riskli işlemlere insan onayı koymak.
• Bilgi kaynağındaki hatalı ya da riskli belgeleri temizlemek.
• Gerekirse modeli ya da sağlayıcıyı değiştirmek.

Düzeltmeden sonra aynı senaryoyu mutlaka yeniden deneyin. Üstelik yakın varyasyonlarını da deneyin, çünkü yalnızca tek bir ifadeyi engellemek gerçek çözüm değildir.

Her düzeltme yeni bir sorun da yaratabilir. Örneğin fazla katı bir kural, botun meşru soruları reddetmesine yol açabilir. Bu yüzden eski senaryoları bir regresyon setinde toplayın ve her değişiklikte çalıştırın. Bu setin nasıl ölçüleceği LLM evals yazımızın konusudur.

AI red teaming ne zaman yapılmalı, yayından önce mi sonra mı?

Cevap, her ikisi de. Yayından önce yapılan test, açık sorunları canlıya çıkmadan yakalar. Yayından sonra yapılan test ise gerçek kullanımın ortaya çıkardığı yeni davranışları yakalar.

Üç tetikleyici bir red teaming turunu başlatmalıdır:

• Yeni bir yapay zeka özelliğini müşterilere açmadan hemen önce.
• Model, sistem talimatı, bilgi kaynağı ya da bağlı araçlarda önemli bir değişiklik olduğunda.
• Canlı kullanımda beklenmedik bir şikayet ya da olay görüldüğünde.

Ayrıca düzenli aralıklarla küçük turlar planlayın. Çünkü kullanıcılar zamanla yeni yollar keşfeder. Böylece her turda sıfırdan başlamak yerine elinizdeki senaryo setini genişletirsiniz.

Yani red teaming bir proje değil, ürünün yaşam döngüsüne yayılmış bir alışkanlıktır. Yayın sonrası izleme ile birleştiğinde en iyi sonucu verir.

Red teaming raporu yönetime nasıl sunulur?

Yönetim, teknik ayrıntıdan çok karar ister. Raporu bu yüzden üç soruya göre kurun: ne bulduk, ne kadar önemli ve ne yapıyoruz?

Raporun başına kısa bir özet koyun. Kapsamı, test edilen sürümü ve en kritik üç bulguyu iki-üç cümleyle yazın. Ardından önem sırasına göre bulgu tablosunu ekleyin.

Her bulgu için sorumlu kişiyi ve hedef tarihi belirtin. Aksi halde rapor okunur, ama işlem yapılmaz. Örneğin "kimlik doğrulama kontrolü arka uca taşınacak" cümlesi, bir sahibi olduğunda gerçek bir görev olur.

Dürüst olun. Test edilmeyen alanları da açıkça yazın, çünkü yönetim bu boşlukları bilmek ister. Kalan riskleri kabul edip etmeyeceğine karar vermek yönetimin işidir; sizin işiniz bu kararı bilgiyle desteklemektir.

AI red teaming yaparken hangi etik ve hukuki sınırlara uymalısınız?

Red teaming, izinli bir faaliyettir. Test ettiğiniz sistemin sahibi sizseniz ya da yazılı yetki aldıysanız sorun yoktur. Başkasının sistemini izinsiz sınamak ise iyi niyetli olsanız bile ciddi sonuçlar doğurabilir.

Üçüncü taraf bir model sağlayıcısını kullanıyorsanız onun kullanım koşullarını da okuyun. Sağlayıcılar, test faaliyetleri için kendi kurallarını ve bildirim kanallarını tanımlayabilir. Bu kurallar değişebileceği için güncel metni her zaman resmi sayfadan kontrol edin.

Veri tarafında da dikkatli olun. Gerçek müşteri kişisel verisini test girdisi olarak kullanmayın. Test çıktılarında kişisel veri çıkarsa raporda maskeleyin ve erişimi sınırlayın. Bu durumda veri koruma yükümlülükleriniz devreye girebilir.

Son olarak, bu yazı hukuki danışmanlık değildir. KVKK ve benzeri düzenlemeler kapsamındaki sorumluluklarınız için uzman bir hukukçuya başvurun.

Ayrıca bir kural daha ekleyelim: bulduğunuz bir açığı kötüye kullanmak, savunmanın değil saldırının tarafına geçmek demektir. Red teaming yalnızca iyileştirme amacıyla yapılır.

AI red teaming, sızma testi, evals ve guardrails arasındaki fark nedir?

Bu dört kavram sıkça karıştırılır, oysa her biri farklı bir soruya cevap verir. Aşağıdaki tablo farkları özetler.

Kısacası red teaming açık arar, evals kaliteyi ölçer, guardrails çalışma anında korur. Sızma testi ise klasik altyapıyı kapsar.

Dolayısıyla biri diğerinin yerine geçmez. Red teaming bulduğu açıklar için yeni guardrails fikri verir. Evals ise düzeltmenin işe yaradığını sürekli kanıtlar. Bu zincir kurulduğunda güvenlik tek seferlik bir çaba olmaktan çıkar.

Gerçek bir işletme senaryosunda AI red teaming nasıl görünür?

Aşağıdaki durum bir örnek senaryodur, gerçek bir müşteri değildir. Bir e-ticaret firmasının sipariş ve iade sorularını yanıtlayan bir chatbotu olduğunu varsayalım.

Ekip önce kapsamı çizer: iade politikası, sipariş durumu sorgusu ve ürün bilgisi. Ardından kabul edilemez sonuçları yazar. Başka müşterinin siparişini göstermek, politika dışı indirim vaat etmek ve marka dışı bir dille konuşmak bu listededir.

Test sırasında ekip birkaç zayıf nokta bulur. Bot, sipariş sorgusunda yeterince kimlik doğrulaması istemiyor. Ayrıca indirim konusunda ısrar edildiğinde, bazen yetkisi olmayan bir söz veriyor.

Düzeltme ise katmanlıdır. Doğrulama kontrolü botun metin kararına bırakılmaz, arka uçta zorunlu hale getirilir. İndirim ve iade gibi kararlar için bot yalnızca öneri sunar, onayı bir çalışan verir. Ekip sonra aynı senaryoları yeniden dener.

Sonuç olarak risk sıfırlanmaz, ancak ölçülebilir biçimde azalır. Ayrıca ekip, bir sonraki sürümde çalıştıracağı hazır bir senaryo setine sahip olur. Üstelik bu set, yeni çalışanlar için de iyi bir eğitim materyalidir.

Ajan sistemlerinde AI red teaming nasıl değişir?

Ajanlar yalnızca yanıt vermez, araç da kullanır. E-posta gönderir, veritabanı sorgular, dosya açar ya da dış servise bağlanır. Bu nedenle test, "model ne söyledi" sorusundan "model ne yaptı" sorusuna kayar.

Burada en önemli başlıklardan biri yetki aşımıdır. OWASP, büyük dil modeli uygulamaları için hazırladığı risk listesinde bu durumu "aşırı yetki" (excessive agency) başlığı altında ele alır. Yani sisteme gereğinden fazla işlev, izin ya da özerklik verilmesi başlı başına bir risktir. Bu nedenle ajan testinde önce izinleri, sonra davranışı inceleyin.

Ajan testinde şu soruları sorarsınız:

• Ajan hangi araçlara erişebiliyor ve bu erişim gerçekten gerekli mi.
• Geri alınamayan işlemlerde insan onayı var mı.
• Ajan, okuduğu bir belgedeki talimatı kendi görevi sanabiliyor mu.
• Her araç çağrısı kayıt altına alınıyor mu.

Araç çağırma mantığını function calling yazımızda, ajanlara bağlantı protokolünü ise MCP yazımızda anlattık. Burada yalnızca şunu ekleyelim: yetkiyi en dar tutmak, en ucuz ve en etkili savunmadır.

AI red teaming'in sınırları ve riskleri nelerdir?

Her güvenlik yöntemi gibi red teaming de mutlak güvence vermez. Bir testin açık bulamaması, açığın olmadığını kanıtlamaz. Yalnızca denediğiniz senaryolarda sorun görmediğinizi gösterir.

Sonuçların ömrü de kısadır. Model, talimat ya da bağlı araç değişince bulgular geçersizleşebilir. Bu yüzden raporun tarihini ve sürümünü mutlaka not edin.

Anthropic, farklı red teaming yöntemlerinin kendine özgü avantaj ve dezavantajları olduğunu, standart uygulamaların eksikliğinin sistemleri karşılaştırmayı zorlaştırdığını anlatır. Yani iki firmanın "red team yaptık" demesi aynı kaliteyi göstermez. Bu nedenle bir tedarikçiden hizmet alırken kapsamı ve yöntemi mutlaka sorun.

Ayrıca insan testçilerin de bir yükü vardır. Rahatsız edici içerikle uzun süre çalışmak yorucu olabilir. Bu nedenle görev dağılımına ve testçi iyiliğine dikkat edin.

Son olarak yanlış bir güven duygusu yaratma riski var. "Test ettik, güvenli" cümlesi yerine "şu kapsamda, şu sürümde, şu bulguları gördük" demek çok daha dürüsttür.

Küçük bir işletme chatbotu için red teaming kontrol listesi nasıl olur?

Büyük bir ekibiniz olmasa da küçük ölçekte başlayabilirsiniz. Aşağıdaki liste, sade bir ilk tur için yeterlidir.

• Botun görevini ve görev dışı konularını tek paragrafta yazın.
• Botun eriştiği tüm veri ve araçları listeleyin.
• Kabul edilemez sonuçları beş ila on madde olarak belirleyin.
• Her madde için bir test senaryosu hazırlayın.
• Testleri gerçek müşteri verisi olmayan bir ortamda yapın.
• Her senaryoyu birkaç farklı ifadeyle ve birkaç kez deneyin.
• Sonuçları tarih ve sürümle birlikte bir tabloya kaydedin.
• Bulguları önem sırasına koyup sahiplerine atayın.
• Düzeltmeden sonra aynı senaryoları yeniden çalıştırın.
• Sistem değiştikçe listeyi tekrar çalıştıracak bir takvim koyun.
• Çalışanların onaysız araç kullanımını da gözden geçirin, bunun için shadow AI yazımıza bakın.

Bu liste bir başlangıçtır. Örneğin ilk turda yalnızca üç maddeyle başlayıp sonra genişletebilirsiniz. Daha kritik sistemlerde bağımsız bir uzmandan destek almanız gerekir.

AI red teaming sürecinde sık yapılan hatalar nelerdir?

Sahada en sık gördüğümüz hatalar şunlardır:

• Testi yalnızca yayından önce bir kez yapıp bırakmak.
• Yalnızca geliştiricilerin test etmesi ve alan uzmanını dışarıda bırakmak.
• Kapsamı yazmadan "ne bulursak bulalım" diye başlamak.
• Bulguları önem derecesi olmadan düz bir liste olarak tutmak.
• Düzeltme yaptıktan sonra eski senaryoları yeniden çalıştırmamak.
• Araç yetkilerini hiç sorgulamadan yalnızca metin çıktısına odaklanmak.
• Ham zararlı çıktıları herkesin görebildiği bir kanalda paylaşmak.

Bu hataların çoğu, süreci bir kontrol kutusu gibi görmekten doğar. Yani sorun teknikten çok, yaklaşımdadır. Oysa red teaming, sistemin nasıl davrandığını öğrenme çabasıdır. Öğrenme ise tekrarla gelişir. Kısacası sabır ve disiplin, burada zekadan daha değerlidir.

Ayrıca bulguları suçlama aracı yapmayın. Ekip, açık bulduğu için cezalandırılırsa bir sonraki sefer daha az açık bulur.

AI red teaming için hangi resmi kaynaklara bakmalısınız?

Terimi derinleştirmek isterseniz birincil kaynaklar aşağıdadır. Hepsi sağlayıcıların ya da kurumların kendi sayfalarıdır, güncel içeriği oradan kontrol edin.

• NIST Yapay Zeka Risk Yönetimi Çerçevesi: risk yönetimi için genel çerçeve.
• NIST AI 600-1 Üretken Yapay Zeka Profili: üretken sistemlere özgü riskler ve önerilen eylemler.
• OWASP LLM ve GenAI Top 10: büyük dil modeli uygulamalarının yaygın risk başlıkları.
• Microsoft AI Red Team belgeleri: ekip kurma ve otomasyon rehberleri.
• Google AI Red Team açıklaması: saldırı türleri ve çıkarılan dersler.
• Anthropic red teaming yazısı: farklı yöntemlerin artıları ve eksileri.

Bu kaynaklar sağlayıcıya özgü ayrıntılar içerir. Bu yüzden kendi ürününüze uyarlarken sade tutun ve kavramlara odaklanın. Model adı, sürüm ya da sınır değerleri için her zaman sağlayıcının güncel belgesine bakın.

AI red teaming'e nereden başlamalısınız?

AI red teaming nedir sorusunun pratik cevabı şudur: sisteminizi kullanıcılarınızdan önce, kontrollü biçimde zorlamak. Küçük başlayın. Bir chatbot, beş kabul edilemez sonuç ve her biri için bir senaryo yeterli bir ilk turdur.

Ardından bulguları kaydedin, düzeltin ve yeniden deneyin. Süreç oturduktan sonra evals ile sürekli ölçüm, guardrails ile çalışma anı koruması ekleyin. Ayrıca ajan kullanıyorsanız yetkileri baştan daraltın.

Talha Aslan ve ekibi olarak yapay zeka projelerinde kapsam belirleme ve risk değerlendirmesi konusunda destek veriyoruz. İsterseniz yapay zeka danışmanlığı sayfamızdan ya da chatbot geliştirme çözümümüzden bize ulaşabilirsiniz.

Bu yazı genel bilgi içindir; güvenlik, veri koruma ve hukuki konularda uzmanınıza danışın. Hiçbir test yöntemi tam güvenlik garantisi vermez.