AI Tedarikçi Risk Değerlendirmesi (TPRM)
40 soruluk vendor güvenlik anketi ve doğrulama rehberi

AI Tedarikçi Risk Değerlendirmesi (TPRM) nedir?

AI tedarikçi risk değerlendirmesi (AI TPRM — Third-Party Risk Management), kuruma yapay zeka veya büyük dil modeli (LLM) yeteneği sağlayan bir üçüncü tarafın güvenlik, gizlilik ve uyum duruşunu; sözleşme imzalanmadan ve sistem üretime alınmadan önce yapılandırılmış biçimde ölçen süreçtir. Klasik tedarikçi denetiminden farkı, değerlendirmenin yalnızca kurumsal olgunluğu (ISO belgesi, veri merkezi, SLA) değil; modelin nereden geldiğini, hangi veriyle eğitildiğini, hangi saldırı sınıflarına karşı test edildiğini ve verinizin çıkarım (inference) sırasında nasıl işlendiğini de kapsamasıdır.

Kısaca: geleneksel TPRM "bu şirkete güvenebilir miyim?" sorusunu sorar; AI TPRM buna "bu modele ve onu çalıştıran boru hattına güvenebilir miyim?" sorusunu ekler. Bir LLM tedarikçisi olgun bir yazılım şirketi olabilir ama kullandığı temel model, ince ayar verisi veya guardrail katmanı sizin risk iştahınızın çok dışında olabilir. Bu iki katmanı ayrı ayrı sorgulamayan bir anket, tedarikçiyi değil yalnızca tedarikçinin pazarlama metnini değerlendirmiş olur.

Neden AI tedarikçileri ayrı bir risk sınıfı?

Standart bir SaaS tedarikçi anketi genellikle veri şifreleme, erişim kontrolü ve iş sürekliliği etrafında döner. Bu sorular gerekli ama bir AI tedarikçisi için yeterli değildir; çünkü modelin kendisi hem saldırı yüzeyi hem de kontrol edilmesi güç bir bileşendir. AI'a özgü risk sınıfları şu başlıklarda toplanır:

• Tedarik zinciri opaklığı: Tedarikçinizin kullandığı temel model, üçüncü bir sağlayıcıdan gelir; onun eğitim verisi ve zafiyetleri sizin görünürlüğünüzün tamamen dışındadır. OWASP'ın LLM tedarik zinciri riski (LLM03) tam olarak bu görünmezliği tarif eder.
• Prompt injection ve guardrail kaçışı: Modele giden metin bir kullanıcı girdisidir; kötü niyetli talimat, veri ile birlikte gelir. Tedarikçinin "güvenlik filtremiz var" beyanı, o filtrenin hangi dilde ve hangi saldırı kalıbında test edildiğini söylemiyorsa boştur.
• Veri kalıcılığı ve sınır ötesi akış: Girdileriniz eğitime karışıyor mu, ne kadar süre saklanıyor, hangi ülkede işleniyor? KVKK açısından bu bir aktarım sorusudur, teknik bir ayrıntı değil.
• Ajan yetkileri: Modele araç (tool) veya API erişimi verildiyse, tedarikçi bu yetkiyi en az ayrıcalık ilkesiyle mi sınırlandırıyor, yoksa geniş bir eylem alanı mı açıyor?

Bu risk sınıflarını ayrı sorgulamayan bir onay süreci, sorunu üretime taşındıktan sonra keşfetmeye mahkûmdur. Türkçe içerikte genel GRC şablonu bol olsa da AI'a özgü, madde madde sorulabilir bir tedarikçi anketi neredeyse hiç bulunmuyor; bu rehberin amacı o boşluğu doldurmak.

40 soruluk AI vendor güvenlik anketi

Aşağıdaki anket yedi kategoriye bölünmüştür. Her soruyu tedarikçiye gönderin ve yanıtı üç durumdan biriyle işaretleyin: Belgeli (kanıt ekli), Beyan (yazılı ama kanıtsız) veya Yok/Bilinmiyor. Yalnızca "Belgeli" yanıtları puanlamaya alın; ilerideki bölümde bu ayrımın neden hayati olduğunu göstereceğiz.

Bu 40 soruyu bir onay kapısı olarak kullanın: kritik kategorilerde (C, D, F) "Yok/Bilinmiyor" yanıtı, düzeltilene kadar üretim onayını bloklamalıdır.

Beyana güvenme, test et: bağımsız doğrulama protokolü

Anketin en zayıf noktası basittir: tedarikçi soruları yanıtlar, siz de kelimelere güvenirsiniz. Oysa güvenlik iddiaları en kolay abartılan iddialardır. Özellikle 13. soruyu (guardrail'ler Türkçe'de test edildi mi?) yazılı bir "evet" ile geçen tedarikçilerin çoğunda bu "evet" doğrulanabilir bir ölçüme dayanmaz.

Bunu neden bu kadar vurguluyoruz? AltaySec'in kendi guardrail-arena ölçümünde — iki eksenli, Türkçe ve İngilizce guardrail kıyaslama düzeneğimiz — vendor guardrail katmanlarının Türkçe saldırıların yaklaşık %83'ünü kaçırdığını, buna karşın meşru istekleri engelleme (aşırı-red) oranının %25 ile %70 arasında savrulduğunu gözlemledik. Bu rakamlar bizim iç ölçüm verimizdir, endüstri geneli bir gerçek değil; ancak açık bir örüntüye işaret ediyor: İngilizce'de makul görünen bir guardrail, Türkçe morfolojik varyasyon ve kültürel bağlam saldırılarında sessizce çöküyor ve bu boşluk tedarikçinin pazarlama metninde asla görünmüyor.

Sonuç net: güvenlik beyanı bir kabul kriteri değil, doğrulanacak bir hipotezdir. Uyguladığımız üç adımlı doğrulama protokolü şudur:

1. Beyanı somut teste indir: "Prompt injection'a karşı korumalıyız" ifadesini, tedarikçinin sisteminde sizin belirlediğiniz saldırı kalıplarıyla denenebilecek bir kabul testine çevirin. Türkçe kalıpları mutlaka dahil edin — çünkü kaçış çoğunlukla orada oluyor.
2. Kontrollü tarama yap: AltaySec Scanner (v2.6) gibi bir Türkçe LLM zafiyet tarayıcısıyla, tedarikçinin izin verdiği bir test ortamında sınırlı ama tekrarlanabilir bir tarama çalıştırın. Not: Scanner belirli payload kütüphanesiyle çalışan sınırlı kapsamlı bir araçtır; bir kırmızı takım değerlendirmesinin yerini tutmaz, ancak beyanla gerçek arasındaki ilk uçurumu görünür kılar.
3. Farkı belgele ve tekrarla: Testin engellediği ve kaçırdığı vakaları kanıtla kaydedin; bunu sözleşmeye "kabul kriteri" olarak gömün ve model sürümü değiştiğinde (5. soru) tekrarlayın.

Bu protokolün ürünleşmiş hali, çalışma zamanında girdi ve çıktıyı denetleyen bir LLM güvenlik duvarıdır; AltaySec tarafında bunu Guardian ile sağlıyoruz. Ama araç ikincildir; asıl disiplin, tedarikçiyi "belgeli" yanıt vermeye zorlamak ve her kritik beyanı bağımsız bir ölçümle karşılamaktır.

Anketi puanlama ve karar eşiği

40 soru ancak bir karar kuralına bağlanırsa değerlidir. Önerdiğimiz yalın puanlama modeli üç seviyelidir ve kanıt düzeyini ödüllendirir:

Toplam puanı yorumlamadan önce iki kural uygulayın:

• Kritik kapı soruları: C, D ve F kategorilerindeki soruların hiçbiri 0 olamaz. Buradaki tek bir "Yok" yanıtı, toplam puan yüksek olsa bile onayı bloklar — çünkü guardrail, veri gizliliği ve olay müdahalesi telafisi olmayan alanlardır.
• Doğrulama çarpanı: Bağımsız test (yukarıdaki protokol) yapılmadıysa, tüm "Belgeli" yanıtları geçici olarak "Beyan" seviyesine indirin. Puan yalnızca ölçümle sabitlenir.

Eşik örneği: 80 üzerinden 60'ın altı "onaylama"; 60-72 "koşullu onay + düzeltme planı"; 72 üstü ve tüm kritik kapılar geçilmişse "onay". Bu sayıları kurumunuzun risk iştahına göre kalibre edin; önemli olan eşiğin önceden ve yazılı olmasıdır, aksi halde değerlendirme tedarikçiyle pazarlığa döner.

Sözleşmeye gömme ve sürekli izleme

Tek seferlik bir anket, imza gününün fotoğrafıdır; model bir hafta sonra güncellenip güvenlik profilini değiştirebilir. AI TPRM'i canlı tutmak için anketin çıktılarını iki yere bağlayın:

• Sözleşme maddelerine: Kritik yanıtları (girdinin eğitime kullanılmaması, sürüm değişikliği bildirimi, olay bildirim SLA'sı, denetim hakkı, veri iadesi) taahhüt olarak sözleşmeye yazın. Beyan sözleşmede yoksa hukuken yoktur.
• Yönetişim döngüsüne: Tedarikçiyi yıllık değil, sürüm-tetikli yeniden değerlendirin. Bir AI yönetişim komitesi bu tekrarları sahiplenmeli; model imzalama ve menşe kontrolü için provenance disiplinini, dış model kaynaklı riskler için model hub tedarik zinciri incelemesini sürece bağlayın.

Özetle iyi bir AI tedarikçi değerlendirmesi üç şeyi bir arada yapar: doğru soruları sorar (40 madde), yanıtı kanıt düzeyine göre puanlar (kritik kapılar) ve her kritik beyanı bağımsız bir ölçümle test eder (beyana güvenme, test et). Bu üçlü olmadan anket, tedarikçinin kendini değerlendirdiği bir forma indirgenir. Kurumsal bir doğrulama turuna ihtiyaç duyarsanız bizimle iletişime geçebilirsiniz.

Kaynaklar

• OWASP Top 10 for LLM Applications — LLM03: Supply Chain
• NIST AI Risk Management Framework (AI RMF 1.0)
• NIST SP 800-161r1 — Cybersecurity Supply Chain Risk Management Practices
• MITRE ATLAS — Adversarial Threat Landscape for AI Systems (Matrices)
• AltaySec guardrail-arena — Türkçe/İngilizce guardrail kıyaslama veri seti (Hugging Face)

İlgili Yazılar

• Hugging Face Model Hub: Tedarik Zinciri Riskleri
• Model İmzalama ve Provenance
• AI Yönetişim Komitesi Kurulması
• Yapay Zeka & KVKK: Kurumsal Sorular