Etkin sorgulama, varsayımları sınayan ve kararı değiştirebilecek kanıt arayan bir incelemedir. Geliştirme ekibinden farklı bir görüş üretmek tek başına bağımsızlık kanıtı değildir.
tanım: soru sormak değil, sonuç değiştirebilmek
"Effective challenge" terimi SR 11-7'den gelir ve üç bileşenle tanımlanır: challenge'ı yapanın yetkinliği (konuyu geliştirici kadar anlaması), bağımsızlığı (teşviklerinin geliştirmeden ayrışması) ve etkisi/yaptırımı (itirazının sonuca yansıyabilmesi — kelimenin tam anlamıyla "stature": kurumsal ağırlık). Üçünden biri eksikse challenge, ne kadar zeki sorular içerirse içersin, etkin değildir.
Bu tanımın kritik sonucu: challenge bir aktivite değil, bir güç ilişkisidir. Yüz soru sorup hepsinin geçiştirilmesine izin veren fonksiyon challenge yapmamıştır; üç soru sorup birinde sistemin lansmanını durduran fonksiyon yapmıştır. AI bağlamında bu daha da önemli çünkü asimetri büyümüştür: geliştirici tarafında vendor'ın pazarlama gücü, "AI dönüşümü" baskısı ve teknik jargon duvarı; ilgili tarafında ise "içine bakamadığın" bir sistem. Dengeleyici güç, sorunun kalitesi + kanıt standardı (Modül 11) + yaptırım mekanizmasıdır (onay koşulları, Modül 10'un issues log'u).
Challenge'ın hedefi geliştiriciyi "yakalamak" değil — sistemin gerçek sınırlarını birlikte ama bağımsız pozisyonlardan haritalamaktır. En iyi challenge oturumları gerginlikle değil, geliştiricinin "bunu düşünmemiştik, test edelim" cümlesiyle biter. Düşmanlaştıran challenge, bilgi akışını keser ve bir sonraki dosyada savunmacı, eksik evidence üretir. Sertlik kanıt standardında; üslupta değil.
challenge theater vs gerçek challenge
Denetçilerin ve regülatörlerin iyi bildiği bir hastalık: challenge theater — challenge'ın biçimsel olarak var, işlevsel olarak yok olması. Karşılaştır:
Theater — biçim var, işlev yok
Sorular şablondan kopyalanır; her sisteme aynı 40 soru gider, cevaplar okunmadan dosyalanır.
"Challenge edildi" kanıtı bir toplantı tutanağıdır: kim ne sordu, ne cevaplandı, ne değişti — belirsiz.
Geliştiricinin her cevabı kabul edilir; hiçbir cevap ek test, revizyon veya kısıt üretmez.
Zamanlama: lansmandan üç gün önce, "onay için son bir formalite" olarak.
Sonuç dağılımı: son 20 dosyada 20 koşulsuz onay. İstatistiksel olarak imkânsız bir mükemmellik.
Gerçek — sonuca dokunur
Sorular risk register'dan türetilir (Modül 05); use-case'in en riskli üç noktasına yığılır.
Yetersiz cevap bulguya dönüşür; bulgu kapanmadan onay koşullu kalır. Cevabın "yeterliliği" kriterlidir.
Zamanlama: tasarım aşamasında beklenti bildirimi + yürütmede resmî oturumlar. Son gün sürprizi yok.
Sonuç dağılımı: koşulsuz onay, koşullu onay, kapsam daraltma, ret — hepsi zaman içinde görülür.
Kendi fonksiyonun için turnusol testi: son 12 ayda challenge'ın değiştirdiği şeylerin listesi. Ertelenen lansman, daraltılan kapsam, eklenen kontrol, değişen model, reddedilen dosya... Liste boşsa iki ihtimal var: ya kurumun tüm sistemleri kusursuz (değil) ya da challenge theater'dasın. Bu liste aynı zamanda komiteye ve denetçiye fonksiyonun değerini anlatan en güçlü sayfadır.
soru bankası: beş katman, yirmi beş soru
Aşağıdaki banka, Modül 03'ün dört katmanına beşinciyi (governance) ekler ve AI'a özgü sorularla genişletir. Her soruda "neden sorulur" notu var — soruyu ezberlemek değil, arkasındaki şüpheyi anlamak önemli. Katmana göre filtrele:
challenge soru bankası
cevap değerlendirme: bu cevap yeterli mi?
Challenge'ın zor kısmı soruyu sormak değil, cevabı değerlendirmektir. Geliştirici cevapları nadiren "bilmiyoruz" der; genellikle ikna edici görünen ama soruyu cevaplamayan formlarda gelir. Dört gerçekçi cevabı değerlendir:
Belgelenmemiş challenge, yapılmamış challenge'dır — denetçi gözünde ve hukuken. Ama belgelemenin amacı savunma değil yalnızca; kurumsal hafızadır: bir sonraki validasyon, önceki challenge'ın nerede takıldığını bilerek başlar. Minimum yapı:
challenge log kaydı — örnek
ID / Tarih
CH-24-117 · 12 Mayıs, challenge oturumu #2
Soru
Test seti üretim trafiğini nasıl temsil ediyor? (Değerlendirme katmanı, risk register R-3'e bağlı)
Cevap özeti
Test seti ürün ekibince yazılmış 200 soru; üretim logları henüz kullanılmamış. Ekip, pilot loglarından örneklem eklemeyi kabul etti.
Değerlendirme
Yetersiz — mevcut haliyle temsiliyet iddiası kanıtsız.
Aksiyon
Bulgu V24-036 açıldı: pilot loglarından ≥300 örnek + dağılım karşılaştırması. Termin: 30 gün. Kapanışa kadar eval sonuçları "ön sonuç" statüsünde.
Sonuç etkisi
Onay önerisi bu bulgunun kapanışına koşullandı.
Formatın kritik alanı sonuncusudur: sonuç etkisi. Her challenge kaydı, sonucu nasıl etkilediğini söylemeli — "etkilemedi (cevap yeterliydi)" de meşru bir kayıttır. Bu alan doluysa theater otomatik olarak imkânsızlaşır: her kayıt ya bir değişiklik ya bir gerekçeli kabul üretir. Boşsa, log bir soru arşividir.
Bağımsız sorgulama
Etkin sorgulama, varsayımları sınayan ve kararı değiştirebilecek kanıt arayan bir incelemedir. Geliştirme ekibinden farklı bir görüş üretmek tek başına bağımsızlık kanıtı değildir.
İtirazın hangi riskten doğduğu, hangi testle ele alındığı ve hangi gerekçeyle kapandığı kaydedilir. Uzmanlık, bilgiye erişim ve karar süreçlerindeki konum birlikte önem taşır.
anahtar çıkarımlar
challenge bir güç ilişkisidir, aktivite değil
Yetkinlik + bağımsızlık + yaptırım. Üçünden biri eksikse, soruların zekâsı önemsizdir. Turnusol: son 12 ayda challenge'ın değiştirdiği şeylerin listesi.
sorular risk register'dan türer, şablondan değil
Her sisteme aynı 40 soru theater'dır. Sorular use-case'in en riskli üç noktasına yığılır; her sorunun arkasında adlandırılabilir bir şüphe vardır.
cevabın yeterliliği kriterlidir
İkna edici görünen cevapların çoğu soruyu cevaplamaz: yeniden ifade, otoriteye havale, gelecek vaadi, ilgisiz kanıt. Yetersiz cevap bulguya dönüşür — dönüşmüyorsa challenge dişsizdir.
"sonuç etkisi" alanı theater'ı imkânsızlaştırır
Her challenge kaydı sonucu nasıl etkilediğini söyler: değişiklik, koşul veya gerekçeli kabul. Bu alan dolu olduğu sürece challenge biçimsellikten çıkar; log da kurumsal hafızaya dönüşür.
Uygulama örneği · kurgusal vaka
karar masası: Lansman baskısıyla bulgu düşürme
Senaryo: Model sahibi injection bulgusunun teorik olduğunu söyleyip High’dan Medium’a indirilmesini istiyor; lansman tarihi gerekçe. Test yeniden üretilebilir ve tool etkisi maddi.
Örnek değerlendirmeyi aç
DeğerlendirmeSeverity’yi takvimle değiştirme. Yeni teknik kanıt varsa değerlendir; yoksa bulgu ve kapanış kriterini koru, anlaşmazlığı yetkili hatta eskale et.
Gerekli kanıtSaldırı izi; tool/veri etkisi; olasılık/şiddet; telafi kontrolü; yazılı karşı kanıt; severity metodolojisi; emsal bulgular.
Karar kaydıChallenge log + eskalasyon: anlaşmazlık, kanıtlar, bağımsız değerlendirme, geçici kontrol, karar sahibi ve risk kabul yetkisi.