Dışarıdan alınan model veya hizmette bilgiye erişim sınırlı olabilir. Kullanım kapsamı, yerel testler, sözleşmedeki değişiklik bildirimleri ve çıkış seçenekleri bu belirsizlikle birlikte değerlendirilir.
limited-access: içini göremediğin sistemi validate etmek
Üçüncü taraf AI bileşenlerinde ağırlıklara, eğitim verisine veya bazı konfigürasyonlara erişim sınırlı olabilir. Hizmet; dış model, satın alınmış tahmin bileşeni veya bir yazılıma gömülü asistan şeklinde sunulabilir. Değerlendirme, bilgi erişimi sınırlarını açıkça kaydederek sağlayıcı kanıtı ile yerel davranış testlerini birleştirir.
İlk refleks yanlıştır: "içini göremiyorsam validate edemem." Doğrusu: validasyon yalnızca modelin içine bakmak değildir. Kavramsal sağlamlık, mimari ve veri dokümantasyonu hâlâ önemlidir; fakat fitness for purpose görüşünün merkezi, sistemin kendi kullanım bağlamındaki davranışı ve kontrolleridir. Limited-access bazı kanıt türlerini erişilemez kılar ve kalan kanıtların ağırlığını artırır. Soru "nasıl içini görürüm?" kadar, "göremediğim kısmın belirsizliğini hangi bağımsız test, kontrol ve sözleşmeyle yönetirim?" sorusudur.
Bu problem yeni değil — klasik dünyada da vendor skorkartları, satın alınmış rating modelleri, dış veri sağlayıcıları vardı ve model risk bunları "third-party model" olarak validate ederdi. SR 11-7 geleneği bunu açıkça kapsar: dışarıdan alınan model, kurumun kendi geliştirdiği kadar validasyona tabidir; "vendor'a güvendik" bir savunma değildir. AI'da tek fark, opaklığın derecesi ve vendor'ın gücünün artması. Zihinsel çerçeve tanıdık; ölçek yeni.
erişim spektrumu: ne kadar görebiliyorsun?
"Vendor AI" tek bir şey değil; erişim düzeyine göre bir spektrumdur ve validasyon stratejin buna göre değişir. Soldan sağa opaklık artar. Her düzeye tıkla:
Açık ağırlık
Llama, Mistral — kendi barındırdığın
→
API erişimi
GPT, Claude API — kara kutu ama kontrol sende
→
Gömülü SaaS
CRM churn, chatbot platformu
→
Kapalı ürün
Copilot, Enterprise GPT
Kritik gözlem: opaklık arttıkça doğrudan test edebildiğin yüzey daralır ama güvence ihtiyacın azalmaz. Bu boşluğu üç şey doldurur: vendor kanıtı, ilgili kara kutu davranış testin ve sözleşmesel güvenceler. Spektrumun sağına gittikçe ağırlık davranış testinden sözleşmeye ve vendor sertifikasyonuna kayar — çünkü test yüzeyin küçülür. Strateji sabit değil, erişim düzeyine göre ayarlanır; bunu scoping kararında (Modül 10) açıkça yaz.
dört ayaklı kanıt modeli
Modül 04'te tanıttığımız çerçeveyi şimdi tam açıyoruz. İçini göremediğin bir sistemin güvencesi tek kaynaktan gelemez — dört ayak üzerinde durur ve hiçbiri tek başına yeterli değildir:
Ayak 1
Vendor kanıtı
Model/sistem kartı, bağımsız denetim raporları (SOC 2, ISO 42001), eval sonuçları, güvenlik sertifikasyonları, kırmızı takım özetleri. Değerli ama çıkar çatışmalı: vendor kendi ürününü satıyor. Kanıt olarak ağırlığı, bağımsızlık ve doğrulanabilirlikle orantılı (Modül 11'in merdiveni).
Kara kutu davranış testi
Ayak 2
Bağımsız test kanıtı: kendi golden setinle, kendi use-case'inde, kendi kabul kriterlerinle sistemi dışarıdan test etmek (Modül 14). İçini görmesen de davranışını ölçebilirsin. Bu ayak, vendor kanıtının "bizim bağlamımızda da geçerli mi?" sorusunu cevaplar ve yerel kullanım kanıtını güçlendirir.
Ayak 3
Sistem katmanı kontrolleri
Vendor modelini değiştiremezsin ama etrafını kuşatabilirsin: girdi/çıktı guardrail'leri (Modül 16), en az ayrıcalık (Modül 08), insan onay katmanı (Modül 17), izleme (Modül 18). Modelin içine güvenemediğin ölçüde, dışına kontrol koyarsın. Bu ayak tamamen ilgili elinde.
Sözleşmesel güvenceler
Ayak 4
Teknik olarak zorlayamadığını hukuken zorla: model değişikliği bildirimi, sürüm sabitleme hakkı, veri işleme/eğitim şartları, denetim hakkı, SLA, sorumluluk. Sözleşme, teknik kontrolün ulaşamadığı yeri kapatır — özellikle "sessiz güncelleme" riskini (Modül 02).
Validasyon lensi: Dört ayağın dengesi erişim düzeyine göre kayar (yukarıdaki spektrum). Açık ağırlıkta 2. ve 3. ayak güçlü; kapalı üründe 1. ve 4. ayak öne çıkar. Ama hiçbir erişim düzeyinde tek ayağa inilmez — özellikle "vendor kanıtı yeterli" tuzağına düşme: SOC 2 raporu güvenlik süreçlerini denetler, ilgili kredi use-case'inde halüsinasyon oranını söylemez. Her onay dosyasında dört ayağın da hangi kanıtla doldurulduğu görünmeli; boş bırakılan ayak, gerekçesiyle yazılmalı.
vendor evidence: bu kanıt işe yarar mı?
Vendor'lar bol miktarda "kanıt" sunar — ama hepsi ilgili sorunu cevaplamaz. Modül 11'in yeterlilik testini (ilgili mi, güncel mi, bağımsız mı, ilgili bağlamında mı?) vendor kanıtına uygula. Beş gerçekçi vendor iddiasını değerlendir:
vendor kanıtı — güvence sağlıyor mu?
Bağlam: bir kredi tahsis chatbot'u için SaaS sağlayıcının onay dosyasına koyduğu kanıtlar. Soru: her biri, ilgili use-case'in için yeterli güvence sağlıyor mu?
sözleşme kontrol listesi: 4. ayağı kur
Sözleşme, AI risk yöneticisinin en güçlü ama en çok atlanan araçlarından biridir — çünkü satın alma anında imzalanır ve model risk masaya geç oturur. Aşağıdaki maddeleri işaretle; bir vendor sözleşmesinin AI risk açısından kapsama görünümünü gör:
Sözleşme kapsama skoru
0 / 8 · kritik 0 / 4
Bu gösterge bir hukuk görüşü veya "sözleşme yeterlidir" kararı değildir. Kritik dört kapıdan biri eksikse toplam skor yüksek görünse bile yeşil olamaz; maddenin kapsamı, uygulanabilirliği ve hizmetin kritiklik düzeyi hukuk, satın alma, bilgi güvenliği ve iş sürekliliğiyle birlikte değerlendirilir.
En kritik maddelerden biri genellikle en çok direnç görenidir: model değişikliği bildirimi + orantılı sürüm/geri dönüş/geçiş hakkı. Her SaaS hizmetinde sürüm sabitleme teknik olarak mümkün olmayabilir; fakat bildirimsiz maddi değişiklik, sistem davranışının ilgili kontrolün dışında değişmesi demektir (Modül 02). Bu yüzden en azından ön bildirim, değişiklik sınıflandırması, regresyon testi için süre ve risk gerçekleşirse geri dönüş veya geçiş mekanizması aranır.
copilot / enterprise gpt: kapalı ürün vakası
Kurumsal copilot'lar (Microsoft 365 Copilot, ChatGPT Enterprise, Claude Enterprise) özel bir zorluk sınıfıdır: yaygın, güçlü, kapalı ve envanterin dışında büyümeye meyilli. Çalışanlar kullanır, verimlilik artar, kimse "bu bir AI sistemi, validate edilmeli mi?" diye sormaz. Bir onay değerlendirmesinin sorması gerekenler:
kapalı copilot — onay soru seti
Veri sınırı
Copilot hangi kurumsal veriye erişiyor? Erişim, kullanıcının kendi yetkisiyle sınırlı mı, yoksa aşırı geniş indeksleme mi var? (Bir çalışanın görmemesi gereken dosyayı Copilot ona özetleyebilir mi?)
Veri sızıntısı
Girdiler ve kurumsal veri vendor'ın modelini eğitmek için kullanılıyor mu? Enterprise sözleşmesi bunu dışlıyor mu? Veri nerede işleniyor (residency)?
Kapsam kullanımı
Çalışanlar Copilot'u onaylanmamış kritik işlerde (kredi kararı gerekçesi, müşteri iletişimi, mevzuat yorumu) kullanıyor mu? Kullanım politikası ve sınırı var mı?
Bu Copilot envantere kayıtlı mı, tier'ı ne? "Verimlilik aracı" diye envanter dışında mı? (Modül 09'un envanter savaşı — en sık kaçan sistem sınıfı budur.)
Kapalı ürünün paradoksu: doğrudan test yüzeyi en dar (dört ayaktan 2. en zayıf), ama yaygınlığı en yüksek. Strateji bu yüzden 3. ve 4. ayağa kayar: sistem katmanı kontrolleri (veri erişim sınırları, DLP, kullanım politikası, çıktı doğrulama kültürü) ve sözleşmesel güvenceler (Enterprise seviyesi veri korumaları). Copilot'u "validate edilemez, çok kapalı" diye geçmek değil; validate edilebilir kısmına (erişim, kullanım, kontroller) odaklanıp kalanı için vendor kanıtı ve sözleşmeye yaslanmak — ve bu dengeyi onay dosyasında açıkça belgelemek.
Pratik hareket: kurumsal copilot'lar için sistem bazlı validasyon yerine bir çerçeve onayı + kullanım governance modeli daha gerçekçidir. Ürünü bir kez (erişim modeli, sözleşme, temel kontroller) değerlendirir, sonra riski kullanım politikası, eğitim ve izlemeyle (kapsam dışı kullanım oranı — Modül 18) yönetirsin. Her çalışanın her sorgusunu validate edemezsin; kullanımın çerçevesini validate edersin.
Tedarikçi bağımlılığı
Dışarıdan alınan model veya hizmette bilgiye erişim sınırlı olabilir. Kullanım kapsamı, yerel testler, sözleşmedeki değişiklik bildirimleri ve çıkış seçenekleri bu belirsizlikle birlikte değerlendirilir.
Sertifika veya sağlayıcı test raporu, yerel kullanımın tüm risklerini kapatmaz. Kanıtın sürümü ve kapsamı ile hizmetin gerçek konfigürasyonu karşılaştırılır.
anahtar çıkarımlar
limited-access, validasyonu imkânsız değil kanıt-ağırlıklı yapar
Mimari ve dokümantasyon önemini korur; erişilemeyen bölümün belirsizliği bağımsız davranış testi, sistem kontrolleri ve sözleşmeyle yönetilir. Görüş, hangi ayağın ne kadar güçlü olduğunu açıkça söyler.
dört ayak: vendor kanıtı, kara kutu test, sistem kontrolleri, sözleşme
Hiçbiri tek başına yeterli değil. Erişim düştükçe ağırlık davranış testinden sözleşme ve kontrollere kayar — ama hiçbir düzeyde tek ayağa inilmez. Boş ayak gerekçesiyle yazılır.
sözleşme, teknik olarak zorlayamadığını hukuken zorlar
Model değişikliği bildirimi + sürüm sabitleme en kritik ve en dirençli madde. Bu yüzden model risk satın almanın başında masada olmalı — imza sonrası değil.
copilot'lar: en dar test yüzeyi, en yüksek yaygınlık
Strateji sistem kontrolleri + sözleşmeye kayar; çerçeve onayı + kullanım governance daha gerçekçi. "Verimlilik aracı" diye envanter dışında bırakmak, denetimin en sık bulduğu açıktır.
Uygulama örneği · kurgusal vaka
karar masası: Sözleşme yenileme masasında karar
Senaryo: Kritik kredi asistanının vendor’ı model kartı ve ayrıntılı eval sonuçlarını paylaşmıyor; SOC 2 sunuyor. Sözleşmede bildirimsiz model güncellemesi ve zayıf çıkış desteği var. Yenileme için üç gün kalmış, alternatif sağlayıcı hazır değil.
Örnek değerlendirmeyi aç
DeğerlendirmeSOC 2’yi ürün davranışı kanıtı sayma. Yenilemeyi otomatik tam onaya bağlama; iş sürekliliği için süreli/geçici uzatma gerekiyorsa kapsam daraltma, yoğun izleme ve kritik sözleşme maddelerinin yeniden görüşülmesini risk kabul merciine taşı.
Gerekli kanıtDört ayak kanıt haritası; kurum golden-set testi; SOC 2 kapsam/istisna; alt yükleniciler ve yoğunlaşma; değişiklik bildirimi; veri kullanım şartı; olay bildirimi; exit/geçiş planı; ikame süresi ve artık risk.
Karar kaydıVendor karar notu: yenileme önerisi ve süresi, kritik açıklar, pazarlıkta vazgeçilmez maddeler, geçici kontroller, risk kabul sahibi, exit kilometre taşları ve yeniden ihale tetikleyicisi.