Kurumsal AI Güvenliği

AI Red Team Raporu Nasıl Okunur? Yönetici Rehberi

AI red team raporu nasıl okunur? Kapsam, şiddet ve olasılık ayrımı, kanıt kalitesi, düzeltme önceliği ve kalan risk kaydı için yönetici kontrol listesi.

Fevzi Ege YurtsevenlerYapay Zekâ Güvenliği Araştırmacısı · AltaySec Kurucusu

13 Ekim 2026 · altaysec.com.tr

AI red team raporu nasıl okunur sorusunun kısa cevabı şudur: önce kapsamı ve test edilen sürümü doğrulayın, sonra şiddet ile olasılığı ayrı değerlendirin, her bulgunun kanıtını ve tekrar edilebilirliğini kontrol edin, düzeltmeleri sahibine ve tarihine bağlayın, kalan riski açıkça kayda geçirin. Rapor bir karne değil, karar girdisidir. Değeri, yönetimin ondan sonra aldığı kararlarla ölçülür.

AI red team raporu okumaya nereden başlanır?

Okumaya bulgulardan değil kapsamdan başlayın. Hangi uygulama, hangi model sürümü, hangi sistem istemi, hangi araçlar ve hangi kullanıcı rolleri test edildi? Kapsam dışı bırakılan bileşenler, raporun söylemediği şeyleri belirler. "Kritik bulgu yok" cümlesi ancak bu sınırlar içinde anlam taşır.

Kapsam belgesinde şu sorulara cevap arayın:

Test, üretimle aynı yapılandırmada mı yapıldı?
Retrieval kaynakları, bağlı araçlar ve ajan yetkileri kapsama dahil miydi?
Dolaylı girdiler test edildi mi: belgeler, e-postalar, web sayfaları?
Türkçe saldırılar denendi mi, yoksa yalnızca İngilizce şablonlar mı kullanıldı?
Test hangi tarihte, hangi model ve istem sürümüne karşı yapıldı?

Son soru önemlidir. Yapay zekâ sistemleri sık değişir. Model sağlayıcısı sürüm günceller, ekip sistem istemini düzenler, yeni bir araç bağlanır. Tarihli ve sürümlü olmayan bir rapor, ne zamana kadar geçerli olduğunu söyleyemez.

Müşteriye açık bir sohbet asistanı test edildiyse, kapsamın tipik saldırı yüzeylerini içerip içermediğini kurumsal chatbot güvenlik testi rehberindeki adımlarla karşılaştırabilirsiniz. Eksik görünen alanlar, bir sonraki testin kapsam maddesi olur.

Yönetici özeti hangi dört soruyu cevaplamalı?

İyi bir yönetici özeti teknik ayrıntıya girmeden dört soruyu cevaplar: ne test edildi, ne bulundu, en büyük risk nedir ve ne yapılmalı. Özet bulguları saymak yerine iş etkisini anlatmalıdır. "Sistem istemi sızdırılabiliyor" teknik bir cümledir. "Saldırgan, asistan üzerinden başka bir müşterinin sipariş bilgisini görebiliyor" ise karar verdiren bir cümledir.

Özette denge arayın. Her bulguyu kritik diye işaretleyen rapor önceliği anlamsızlaştırır. Hiçbir şeyi net söylemeyen rapor ise karar vermeyi zorlaştırır. NIST'in üretken yapay zekâ profili (NIST AI 600-1) de red team sonuçlarının kurumsal karar ve politika süreçlerine alınmadan önce ek analizden geçirilmesini önerir. Özet bu analizin başlangıç noktasıdır, sonu değildir.

Özetin ilk sayfasında şunları arayın: kapsam ve sınırlamalar, iş etkisiyle anlatılmış ilk üç bulgu, sorumlu rolüyle önerilen eylemler ve karar gerektiren konular.

Şiddet ve olasılık neden ayrı okunmalı?

Şiddet, bulgu sömürülürse oluşacak etkinin büyüklüğüdür. Olasılık, sömürülme ihtimalidir. İkisi tek bir "kritik" etiketinde birleştirildiğinde hangisinin belirleyici olduğu kaybolur. Yüksek şiddetli ama zor sömürülen bir bulgu ile kolay sömürülen orta şiddetli bir bulgu farklı aciliyet taşır.

Rapor CVSS kullanıyorsa ölçeği doğrulayın. FIRST'ün CVSS v4.0 belirtimindeki nitel ölçek şöyledir: 0.1-3.9 düşük, 4.0-6.9 orta, 7.0-8.9 yüksek, 9.0-10.0 kritik. Yapay zekâya özgü bulgularda CVSS her zaman iyi oturmaz. Rapor kendi ölçeğini kullanıyorsa ölçütlerini açıklamalıdır.

Olasılığı okurken yapay zekânın olasılıksal doğasını unutmayın. Bir saldırının on denemede iki kez çalışması "nadiren çalışıyor" anlamına gelmez. Saldırgan denemeyi tekrarlar. Bu yüzden her bulguda deneme sayısı ve başarı sayısı yazmalıdır. Oranın nasıl ölçüleceği ve güven aralığının nasıl verileceği saldırı başarı oranı (ASR) ölçümü yazısında anlatılır.

Durum	Şiddet	Olasılık	Önerilen ele alış
Kimlik doğrulaması gerekmeden müşteri verisi sızıntısı	Yüksek	Yüksek	Hemen, gerekirse özelliği kapatarak
Müşteri verisi sızıntısı, nadir ve karmaşık koşulda	Yüksek	Düşük	Planlı ama öncelikli
Sistem isteminin kısmi ifşası, kolay tekrar	Düşük ya da orta	Yüksek	Toplu düzeltme ve izleme
Küçük etki, zor koşul	Düşük	Düşük	Kabul ya da izleme

Bir bulgunun kanıtı yeterli mi, nasıl anlaşılır?

İyi bir bulgu, başka birinin aynı koşulda tekrar edebileceği kadar ayrıntılıdır. Kanıt; istem ve yanıt kaydı, araç çağrısı günlüğü ya da ekran kaydı olabilir. Sonucun gözlemlenmiş mi yoksa varsayılmış mı olduğu açıkça yazılmalıdır.

Her bulgu için şu kontrolü yapın:

Benzersiz bir kimliği ve açık bir başlığı var mı?
Etkilenen bileşen, kullanıcı rolü, model sürümü ve istem sürümü yazılmış mı?
Yeniden üretim adımları başka biri tarafından izlenebilir mi?
Deneme sayısı ve başarılı deneme sayısı verilmiş mi?
Kanıt, iddia edilen etkiyi gerçekten gösteriyor mu?
Bulgu, iş etkisiyle ve mümkünse OWASP ya da MITRE ATLAS kategorisiyle eşlenmiş mi?

Eksik görünen noktalar için raporu yazan ekipten açıklama isteyin. Bu, iyi bir raporlama sürecinin olağan parçasıdır. Raporun kendisinin hassas bir belge olduğunu da unutmayın. Yeniden üretim adımları saldırı tarifi içerir. Yönetici sürümünü teknik ekten ayırın ve teknik eki sınırlı bir grupla paylaşın.

Otomatik tarama çıktısı ile red team bulgusu nasıl ayırt edilir?

Otomatik tarama bilinen kalıpları geniş ölçekte dener. Red team çalışması ise sisteminizin işleyişini anlayıp saldırı zinciri kurar. İkisi de değerlidir, ama aynı şey değildir. Microsoft'un yüz üretken yapay zekâ ürününü test eden ekibinin yayımladığı derslerde de otomasyonun kapsamı genişlettiği, insan yargısının ise vazgeçilmez olduğu vurgulanır.

Raporda ham araç çıktısı yorumsuz aktarılmışsa bu bir uyarı işaretidir. Ham liste, yanlış pozitifleri ayıklamaz ve bulguyu iş akışınıza bağlamaz. İyi bir rapor otomatik bulguları ayrı bir bölümde toplar, elle doğrulananları işaretler ve zincir halindeki saldırıları ayrıca anlatır. Örneğin "bir belgede gizli talimat, asistanın e-posta aracını çağırması ve verinin dışarı gönderilmesi" tek bir zincir bulgusudur. Üç ayrı düşük bulgu olarak listelenmemelidir.

Hizmet sağlayıcıdan bu ayrımı baştan istemek gerekir. Teklif aşamasında sorulacak sorular için AI red team hizmeti nasıl seçilir yazısına, şartnameye yazılacak raporlama maddeleri için AI pentest RFP şablonu yazısına bakabilirsiniz.

Düzeltmeler nasıl önceliklendirilir ve kim karar verir?

Önceliklendirme şiddet, olasılık, düzeltme maliyeti ve bağımlılıkların birlikte değerlendirilmesidir. En yüksek riskli bulgular listenin başında kalır. Her düzeltme için bir sahip, bir hedef tarih ve bir doğrulama yöntemi belirlenir.

Öneriler eyleme dönüşebilir olmalıdır. "Girdi doğrulamasını iyileştirin" belirsizdir. "Araç çağrısı parametrelerini sunucu tarafında şemaya göre doğrulayın, şemaya uymayan çağrıyı reddedin ve günlüğe yazın" ise uygulanabilir.

Bağımlılıklara bakın. Bir yetki sorunu giderilmeden diğer bulgular tam kapanmayabilir. Bazen tek bir mimari değişiklik, örneğin ajanın araç yetkisini daraltmak, birden fazla bulguyu birlikte kapatır. Bu fırsatları ayrı bir satırda gösterin.

Yeniden test planını sözleşmeye baştan yazın. Kritik ve yüksek bulgularda bağımsız doğrulama, diğerlerinde ekibin kanıt kaydı uygundur. Bulgu kapanışı, yeniden testin olumlu sonucuyla olur.

Kalan risk nasıl kaydedilir ve toplantı nasıl kapanır?

Kalan risk, düzeltmeler uygulandıktan sonra geride kalan risktir. Bir kısmı bilinçli kabul edilir, bir kısmı kapsam dışı kalmıştır, bir kısmı ise tamamen giderilemez. Her biri adıyla, gerekçesiyle, geçici önlemiyle, kabul eden kişiyle ve gözden geçirme tarihiyle kaydedilir.

Rapor sonrası toplantı tartışma için değil karar için yapılır. Masada teknik ekip, ürün sahibi, risk sahibi ve raporu yazan ekipten bir temsilci bulunur. Toplantı şu kayıtla kapanır:

Bulgu	Karar	Sorumlu	Hedef tarih	Doğrulama
Kimlik ve kısa tanım	Düzelt, kabul et ya da ertele	Rol ve kişi	Planlanan tarih	Yeniden test ya da kanıt

Bulgular bir kişinin başarısızlığı değil, sistemin o anki durumudur. Suçlayıcı bir dil kullanılırsa sonraki testlerde bulgular gizlenmeye başlar. Kararları risk kaydına ve kurul raporuna aktarın. Böylece süreç kurumsal belleğe dönüşür.

Raporda hangi kırmızı bayraklar dikkat çeker?

Dikkat edilecek işaretler şunlardır:

Kapsamı ve sürümü belirtmeyen genel iddialar.
Kanıtı ve deneme sayısı olmayan kritik bulgular.
Her bulguyu aynı şiddetle işaretleyen listeler.
Yorumsuz aktarılmış otomatik araç çıktısı.
"Güvenliği artırın" gibi eyleme dönüşmeyen öneriler.
Kalan riskin ve kapsam dışı alanların hiç anılmaması.

Bu işaretlerden biri varsa açıklama isteyin. Rapor tek başına kalıcı güvence değildir. Microsoft ekibinin derslerinden biri de yapay zekâ sistemlerini güvenli hale getirmenin bitmeyen bir iş olduğudur. Raporu bir andaki fotoğraf olarak okuyun ve düzenli yenilenen bir test programının parçası yapın. Kapsamlı bir test planlıyorsanız LLM pentest sayfasında kapsam seçeneklerini inceleyebilirsiniz.

Sık Sorulan Sorular

Rapordaki bulgu sayısı güvenlik düzeyini gösterir mi?

Göstermez. Az bulgu dar kapsamdan, kısa süreden ya da yalnızca otomatik taramadan kaynaklanabilir. Çok bulgu ise derin bir testin işareti olabilir. Sayı yerine kapsamın sisteminizi ne kadar kapsadığına, en yüksek şiddetli bulgunun iş etkisine ve kanıt kalitesine bakın. Kapsam dışı bırakılan bileşenlerin listesi, bulgu sayısından daha çok şey anlatır.

Yapay zekâ bulgularında neden deneme sayısı yazılmalı?

Dil modelleri aynı girdiye her seferinde aynı yanıtı vermez. Bir saldırı on denemede iki kez çalışıyorsa bu, saldırganın birkaç denemede başarıya ulaşabileceği anlamına gelir. Rapor yalnızca çalıştı ya da çalışmadı diyorsa tekrar edilebilirlik bilinemez. Her bulguda deneme sayısını, başarılı deneme sayısını ve kullanılan model ile istem sürümünü isteyin.

Otomatik tarama raporu ile red team raporu arasındaki fark nedir?

Otomatik tarama, bilinen saldırı kalıplarını geniş ölçekte dener ve kapsamı artırır. Red team çalışması ise sisteminizin iş akışını, araçlarını ve yetkilerini anlayarak saldırı zinciri kurar. Microsoft'un yüz üretken yapay zekâ ürünü üzerindeki deneyimi de otomasyonun kapsamı genişlettiğini, insan yargısının ise vazgeçilmez kaldığını vurgular. İyi rapor ikisini ayırarak sunar.

Kalan risk kararını kim vermelidir?

Kalan riski teknik ekip değil, riskin sahibi olan iş birimi ya da yönetim kabul eder. Teknik ekip bulgunun etkisini, düzeltme maliyetini ve geçici önlemleri açıklar. Karar yazılı olur, gerekçe ve gözden geçirme tarihi içerir. Süresiz kabul edilen risk zamanla unutulur. Bir sonraki testte aynı bulgu çıktığında bu kayıt, kararın bilinçli verildiğini gösterir.

Düzeltme sonrası yeniden test her bulgu için gerekli mi?

Kritik ve yüksek şiddetli bulgularda gereklidir ve mümkünse raporu yazan ekip ya da bağımsız biri tarafından yapılmalıdır. Orta ve düşük bulgularda ekibin kendi doğrulaması ve kanıt kaydı yeterli olabilir. Yeniden testin kapsamı, süresi ve ücreti sözleşmeye baştan yazılmalıdır. Aksi halde bulgular kâğıt üzerinde kapanır ama gerçekte açık kalabilir.

Kaynaklar

İlgili Yazılar

Bu yazı, Türkiye odaklı Yapay Zekâ Güvenliği Rehberi'nin destek makalelerinden biridir.