Yapay zeka red teaming: planlama, yürütme ve düzeltme döngüsü

Red teaming nedir ve neden gerekir?

Geleneksel yazılım testleri, beklenen girdilere beklenen çıktıların verildiğini doğrular. Üretken yapay zeka uygulamalarında girdi doğal dildir ve olasılıkların sınırı yoktur; bir kullanıcının ya da kötü niyetli birinin ne yazacağı önceden tam olarak bilinemez. Red teaming bu boşluğu doldurur: uygulamayı kasıtlı olarak zorlayıp istenmeyen davranışı yayından önce görünür kılar.

İstenmeyen davranış geniş bir alandır. Uygulamanın zararlı içerik üretmesi, hassas bilgiyi ifşa etmesi, talimatını yok sayması, bağlı olduğu araçlarla yetkisiz işlem yapması, taraflı ya da yanıltıcı yanıt vermesi ya da kurumu itibar açısından zor durumda bırakması bunlardan bazılarıdır. Hangisinin önemli olduğu uygulamanın ne yaptığına bağlıdır.

Konu burada bilinçli olarak yöntem ve yönetişim açısından ele alınır: belirli saldırı tekniklerinin ayrıntısı değil, testin nasıl planlanıp yönetildiği önemlidir. Çünkü kurumsal değer, tek tek hileleri bilmekten çok, testi düzenli, yetkili ve izlenebilir bir süreç haline getirmekten gelir.

Kapsam, yetki ve kurallar

Red teaming, açık yetkiyle yapılır. Kapsam ve kural belgesi şunları içermelidir: test edilecek uygulama ve ortam, test edilmeyecek sistemler, izin verilen yöntemlerin sınırı, test sırasında canlı veriye ve gerçek kullanıcılara erişim kuralı, bulguların kime ve nasıl bildirileceği ve test verilerinin saklanma biçimi.

Test mümkünse canlı sistemden ayrı bir ortamda yapılır. Canlı ortamda yapılacaksa gerçek kullanıcıların etkilenmemesi için ek önlem gerekir. Üçüncü taraf bir modeli ya da hizmeti test ediyorsanız sağlayıcının kullanım koşullarını ve test izinlerini kontrol edin; bazı hizmetler kendi sistemlerine yönelik test için ayrı onay ister.

Test ekibinin çıktıyla karşılaşacağı içerik de düşünülmelidir. Zararlı içerik üreten bir sistemi sınayan kişi bu içeriği görmek zorundadır; ekibin psikolojik ve hukuki korunması, içeriğin güvenli saklanması ve gerekirse paylaşım sınırı belirlenmelidir.

Önce zarar haritası, sonra senaryo

Senaryolar rastgele denemelerden değil, uygulamanın amacından ve paydaşlarından türetilir. İlk adım, uygulamanın kullanım amacını, kullanıcılarını, eriştiği veri ve araçları, ve hata yaptığında kimlerin nasıl etkileneceğini yazmaktır. Bu bilgiyle bir zarar taksonomisi kurulur.

Taksonomi, kategori bazlıdır: içerik güvenliği, gizlilik ve veri ifşası, yetki ve araç kötüye kullanımı, yanıltıcı bilgi, taraflılık ve ayrımcılık, uygulamanın talimatına uymaması gibi. Her kategori için uygulamanın hangi davranışının kabul edilemez olduğu yazılır. Bu eşikler olmadan "bulgu" ile "beklenen sınırlama" ayrılamaz.

Senaryo yazarken kullanıcı tiplerini çeşitlendirin: iyi niyetli ama dikkatsiz kullanıcı, meraklı kullanıcı ve kasıtlı kötüye kullanan kişi. Çoğu gerçek zarar, kötü niyetten değil, uygulamanın öngörülmeyen durumlarda yanlış davranmasından çıkar. Alan uzmanları, yani hukuk, sağlık, finans ya da insan kaynakları gibi alanlardan kişiler, genel güvenlik ekiplerinin göremeyeceği riskleri bulur.

Ekip ve yürütme düzeni

İyi bir red team tek bir uzmandan değil, farklı bakışlardan oluşur. Güvenlik uzmanları teknik zayıflıkları ve kötüye kullanım yollarını bilir. Ürün ve uygulama sahipleri sistemin gerçek kullanım bağlamını bilir. Alan uzmanları sektöre özgü zararları görür. Hukuk ve uyum ekipleri yükümlülükleri ve itibar etkisini değerlendirir. Uygulamayı geliştiren ekip testin içinde değil, bulguyu alan taraftır; böylece test bağımsız kalır.

Yürütme sırasında her deneme kaydedilir: ne denendi, uygulama ne yaptı, sonuç ne. Kayıt, yeniden üretilebilirlik için gereklidir. Deneme yöntemi iki biçimde ilerler: insanlar yaratıcı ve beklenmedik yaklaşımlar dener, otomatik araçlar ise hazır senaryoları büyük hacimde çalıştırır. İkisi birbirini tamamlar; otomasyon kapsamı, insan ise hayal gücünü sağlar.

Bulgu çıktıkça hemen paylaşılır; ciddi bir bulgu için testin bitmesi beklenmez. Bulgular güvenli bir kanalda ve yalnız ilgili kişilerle paylaşılır, çünkü bulgu kaydı kendi başına hassas bilgi olabilir.

Bulguları sınıflandırmak ve düzeltmek

Her bulgu için etkisi, tekrarlanabilirliği ve kötüye kullanım kolaylığı değerlendirilir. Etki, zararın kime ve ne büyüklükte dokunduğunu gösterir. Tekrarlanabilirlik, bulgunun her seferinde mi yoksa nadiren mi ortaya çıktığıdır. Kötüye kullanım kolaylığı, sıradan bir kullanıcının bunu yapıp yapamayacağıdır. Bu üç boyut bulguya öncelik verir.

Düzeltme seçenekleri çok yönlüdür. Uygulamanın talimatı değiştirilebilir, girdi ve çıktı filtreleri eklenebilir, araç yetkileri daraltılabilir, hassas bilgiye erişim kısıtlanabilir, insan onayı eklenebilir ya da kullanım kapsamı daraltılabilir. Bazı bulgular için düzeltme mümkün olmaz; bu durumda kalan risk bilinçli biçimde kabul edilir ve sahibi tarafından yazılı onaylanır.

Her düzeltme yeniden test edilir. Bir bulgunun kapandığı, onu ortaya çıkaran senaryonun artık sorunsuz geçtiğiyle kanıtlanır. Senaryolar bir test kümesine eklenerek sonraki sürümlerde otomatik çalıştırılır.

Red teaming'i yönetişime bağlamak

Test, tek başına bir etkinlik değil, yayın kararının bir girdisidir. Kurumun yapay zeka politikası, hangi riskte hangi testin zorunlu olduğunu söylemelidir: düşük riskli bir iç özetleme aracı için hafif bir değerlendirme, müşteriyle konuşan ya da araçlarla işlem yapan bir uygulama için kapsamlı bir red team gibi. Yayına çıkış onayı, kapanmamış kritik bulgu olmamasına bağlanır.

Bulgular risk kayıt defterine işlenir, sahibi ve kapanış tarihi izlenir. Önemli bulgular yönetişim komitesine raporlanır. Tedarikçi modelleri için sağlayıcıdan test ve güvenlik belgeleri istenir; ama sağlayıcının testi, kurumun kendi kullanım bağlamındaki testin yerini tutmaz.

Değişiklik tetikleyicileri tanımlanır: model sürümü, sistem talimatı, bağlı araçlar veya veri kaynağı değiştiğinde ilgili senaryolar yeniden çalıştırılır. Kullanımda gelen şikayetler ve olaylar da yeni senaryo kaynağıdır.

Sık hatalar

İlk hata, red teaming'i yalnızca bir kez, yayından hemen önce yapmaktır. Bulunan sorunlar düzeltilecek zaman bırakmaz ve test, değişikliklerle eskir. İkinci hata, ekibi tek bir bakışla, örneğin yalnız teknik güvenlik uzmanlarıyla sınırlı tutmaktır.

Üçüncü hata, zarar eşiğini tanımlamadan test yapmaktır; sonuçta her bulgu tartışmalı olur. Dördüncü hata bulguyu düzeltmeden raporlayıp kapatmak, yeniden test etmemektir. Beşinci hata, tedarikçinin güvenlik beyanını kurumun kendi testinin yerine koymaktır.

Son olarak kapsam ve yetki belgesiz test, hem hukuki hem de operasyonel risk yaratır. Yetkisiz ya da kuralsız deneme, bulgu kadar sorun üretebilir.

Bu beceriyi Mindset programlarında nerede çalışırsınız

Yapay Zeka Risk Yönetimi ve Yönetişim kursunun Üretken Yapay Zeka Spesifik Risk Yönetimi ve Operasyonel Yapay Zeka Riski Kontrolleri modülleri bu konunun risk ve kontrol tarafını çalıştırır. Risk, güvenlik ve ürün sahibi ekipler için uygundur.

Yapay Zeka Uyum ve Etik Uzmanlığı programındaki Yapay Zeka Güvenliği ve Üçüncü Taraf Riskleri modülü ise testi yönetişim ve tedarikçi bağlamına yerleştirmek isteyen uyum ekiplerine yöneliktir.