Yapay Zeka Tedarikçi Riskleri Nasıl Değerlendirilir?

Yapay zeka tedarikçi riskleri; veri gizliliği, model güvenliği, entegrasyon ve ISO 27001 ile GDPR uyumluluğu kriterleri üzerinden sistematik olarak analiz edilir. Kurumsal operasyonlara harici yapay zeka çözümlerini dahil etmek, geleneksel yazılım tedarik süreçlerinden köklü biçimde ayrışan teknik ve hukuki risk profillerini beraberinde getirir. Karar vericilerin yalnızca algoritmik performansa değil; veri egemenliği, telif hakları, modelin öngörülemez davranışları ve regülasyon uyumuna odaklanan çok katmanlı bir denetim mekanizması kurması zorunludur. Bu rehberde, "Yapay Zeka Tedarikçi Riskleri Nasıl Değerlendirilir?" sorusunun yanıtı, teknik mimariden sözleşme müzakerelerine kadar uzanan operasyonel kontrol adımlarıyla ele alınmaktadır.

1. Yapay Zeka Satın Alması Neden Geleneksel SaaS Tedarikinden Farklıdır?

Geleneksel bulut tabanlı yazılım (SaaS) tedarikinde risk değerlendirmesi, büyük oranda deterministik sistemlerin incelenmesine dayanır. Bir kurumsal kaynak planlama (ERP) veya müşteri ilişkileri yönetimi (CRM) yazılımı satın alındığında, sistemin girdi ve çıktı ilişkisi belirli kod blokları, iş mantığı kuralları ve veritabanı şemaları üzerinden mutlak bir kesinlikle tanımlanır. Yazılımın güvenlik açıkları genellikle statik kod analizi, sızma testleri, rol tabanlı erişim kontrolü (RBAC) ve veri merkezinin ISO/IEC 27001 veya SOC 2 Tip II sertifikaları üzerinden ölçümlenir. Ancak yapay zeka, özellikle de büyük dil modelleri (LLM) ve üretken yapay zeka sistemleri söz konusu olduğunda, bu klasik denetim mimarisi yetersiz kalmaktadır.

Yapay zeka sistemleri olasılıksal (probabilistik) bir doğaya sahiptir. Aynı girdiye karşılık her zaman aynı çıktıyı garanti etmeyen bu modeller, statik kurallarla değil, parametre ağırlıkları ve istatistiksel dağılımlarla çalışır. Bu temel çalışma prensibi, tedarikçi değerlendirmesinde "yazılımın doğrulanması" kavramını kökten değiştirir. Bir makine öğrenmesi modelinin güvenliği ve performansı, yalnızca yazılımı barındıran sunucunun güvenliğine değil; modelin hangi verilerle eğitildiğine, çıkarım (inference) aşamasında kurumsal verileri nasıl işlediğine ve harici girdilere karşı sergilediği tutarlılığa doğrudan bağımlıdır.

Tedarik zinciri perspektifinden bakıldığında, harici bir yapay zeka platformunu şirketin kritik süreçlerine bağlamak, statik bir araç entegre etmekten ziyade üçüncü taraf bir bilişsel iş gücünü operasyona dahil etmeye benzer. Bu durum, veri sızıntısından telif hakkı ihlallerine, regülasyon cezalarından marka itibar kaybına kadar genişleyen yeni bir risk spektrumu doğurur. Kurumların, geleneksel BT satın alma süreçlerini aşarak yapay zekaya özgü Yapay Zeka Risk Yönetimi (AI Risk Management) çerçevelerini devreye alması bu sebeple zorunlu hale gelmiştir.

Geleneksel Yazılım vs. Dinamik Yapay Zeka Sistemleri

Geleneksel yazılımlarda bir hata (bug), sistem kodundaki mantıksal bir kural ihlalinden kaynaklanır ve tespit edildiğinde bir yama (patch) ile kalıcı olarak giderilebilir. Yapay zeka sistemlerinde ise çıktının bozulması, her zaman kod tabanlı bir hataya işaret etmez. Modelin eğitim verisindeki örtük yanlılıklar (bias), bağlam penceresi (context window) sınırları veya modelin dili anlama biçimindeki olasılıksal sapmalar, öngörülemez sonuçlar doğurabilir.

Geleneksel sistemlerde veriler ilişkisel veri tabanlarında (PostgreSQL, Oracle, SQL Server vb.) saklanırken, yapay zeka sistemlerinde yüksek boyutlu vektör uzaylarında (vektör veritabanları) temsil edilir. Verinin depolanma ve işlenme biçimindeki bu yapısal fark, güvenlik denetimlerinin odağını da değiştirir. Klasik SaaS tedariğinde verinin durağan halde (data-at-rest) ve aktarım halinde (data-in-transit) AES-256 ve TLS 1.3 protokolleriyle şifrelenmesi yeterli bir güvenlik kriteri kabul edilirken; yapay zekada verinin kullanım anında (data-in-use), yani model çıkarımı sırasında bellekte ve bağlamda nasıl izole edildiği birincil denetim konusu haline gelir.

Kara Kutu (Black Box) Problemi ve Açıklanabilirlik Sınırları

Derin öğrenme mimarileri ve yüz milyarlarca parametreye sahip temel modeller (foundation models), doğaları gereği "kara kutu" olarak nitelendirilir. Modelin belirli bir girdiye neden belirli bir çıktıyı ürettiğini nöron ve ağırlık seviyesinde tam olarak izah etmek, mevcut matematiksel yöntemlerle dahi sınırlıdır. Bir finansal skorlama, sigorta poliçesi fiyatlandırması veya işe alım sürecinde kullanılan üçüncü taraf bir yapay zeka aracı karar ürettiğinde, bu kararın yasal mercilere veya denetçilere gerekçelendirilmesi (explainability) kurumun sorumluluğundadır.

Tedarikçinin açıklanabilirlik (XAI - Explainable AI) araçları sunup sunmadığı kritik bir eşiktir. SHAP (SHapley Additive exPlanations) veya LIME (Local Interpretable Model-agnostic Explanations) gibi analitik yöntemlerin tedarikçi platformuna entegre olup olmadığı sorgulanmalıdır. Karar vericiler, tedarikçinin "Algoritmamız tescillidir, detaylarını paylaşamayız" savunmasını doğrudan bir operasyonel risk olarak kaydetmelidir; zira açıklanamayan bir model çıktısı, regüle edilen sektörlerde doğrudan mevzuat ihlali anlamına gelir.

Sürekli Değişen Dinamik Risk Profili ve Veri Bağımlılığı

Geleneksel yazılımlar sürümler (v1.0, v2.0) üzerinden güncellenir ve her güncelleme sürüm notları ile kontrollü test ortamlarında incelenebilir. Yapay zeka servis sağlayıcıları ise arka plandaki modelleri sürekli olarak güncellemekte, optimize etmekte veya parametre ağırlıklarını değiştirmektedir. API üzerinden tüketilen bir model, dün verdiği doğru bir yanıtı bugün model üzerinde yapılan bir optimizasyon (örneğin kuantizasyon - quantization) neticesinde eksik veya hatalı üretebilir.

Bunun yanı sıra sistemlerin veri bağımlılığı, tedarikçi güvenilirliğinin sürdürülebilirliğini dinamik kılar. Tedarikçi, modelin performansını artırmak amacıyla sistem mimarisini RAG (Retrieval-Augmented Generation) altyapısına geçirdiğinde, harici veri kaynaklarına yapılan erişimler yeni sızıntı vektörleri oluşturur. Bu nedenle yapay zeka satın alması bir defalık bir BT denetimi değil, sözleşmesel olarak bağlanan sürekli bir risk izleme süreci gerektirir.

2. Kritik Risk Alanları: AI Entegrasyonunda Hangi Açıklara Odaklanılmalı?

Kurumsal sistemlere entegre edilen yapay zeka teknolojileri, siber güvenlik yüzeyini önemli ölçüde genişletir. Geleneksel sistemlerdeki SQL Injection veya Cross-Site Scripting (XSS) gibi standart zafiyetlerin yerini, yapay zekaya özgü yeni nesil açıklar almıştır. OWASP (Open Web Application Security Project) tarafından yayınlanan "Top 10 for LLM Applications" listesi, bu tehditlerin teknik çerçevesini somutlaştırmaktadır. Tedarikçi değerlendirmesinde incelenmesi gereken üç ana risk vektörü bulunmaktadır.

Veri Gizliliği, KVKK ve GDPR Kapsamında Model Eğitimi Riskleri

Tedarikçiye sağlanan girdilerin (prompt, doküman, müşteri verisi), tedarikçinin genel modellerini eğitmek (fine-tuning veya pre-training) amacıyla kullanılması kurumsal veri gizliliğinin önündeki en büyük tehdittir. Birçok tüketici odaklı veya giriş seviyesi kurumsal yapay zeka aracı, kullanıcı sözleşmelerinde (Terms of Service) varsayılan olarak kullanıcı verilerini "hizmeti iyileştirmek" amacıyla işleme hakkını saklı tutar.

Şirket içi hassas bilgilerin, finansal tabloların veya müşteri kimlik verilerinin tedarikçinin temel modeline beslenmesi, bu bilgilerin modelin parametre ağırlıklarına kazınmasına yol açabilir. Parametrik hafızaya giren bu veriler, üçüncü bir kullanıcının ustaca kurgulanmış bir prompt ile sorgulama yapması durumunda istem dışı olarak dışarı sızdırılabilir (Training Data Extraction Attack). GDPR'ın 17. Maddesi uyarınca "Unutulma Hakkı" (Right to be Forgotten) kapsamında bir müşterinin verilerinin silinmesi talep edildiğinde, eğitilmiş bir derin öğrenme modelinden o veriyi çıkarmak (Machine Unlearning) teknik olarak son derece karmaşık ve maliyetlidir; çoğu zaman imkansızdır. Dolayısıyla tedarikçinin "Sıfır Veri Saklama" (Zero Data Retention - ZDR) politikası sunup sunmadığı ve kurumsal verileri model eğitim havuzundan kesin bir dille izole edip etmediği kontrol edilmelidir.

Model Güvenliği: Prompt Injection, Veri Zehirleme ve Çıkarım Saldırıları

Yapay zeka modelleri harici girdilerle yönlendirilir. Tedarikçinin sistem mimarisinde yeterli filtreleme ve sterilizasyon katmanları bulunmuyorsa, sistem kötü niyetli manipülasyonlara açık hale gelir. Bu durumun başında "Prompt Injection" (Komut Enjeksiyonu) saldırıları gelir. Doğrudan veya dolaylı (indirect) yollarla yapılan bu saldırılarda, saldırgan modelin sistem talimatlarını (system prompt) geçersiz kılarak tedarikçi üzerinden kurumun iç sistemlerine yetkisiz sorgular gönderebilir veya verileri ifşa edebilir.

İkinci büyük tehdit "Veri Zehirleme" (Data Poisoning) riskidir. Tedarikçi, modelini veya RAG mimarisinde kullandığı bilgi tabanını harici kaynaklardan besliyorsa, manipüle edilmiş veri setleri modelin mantık dizilimini bozabilir. Üçüncü risk ise "Model Tersine Mühendisliği ve Çıkarım Saldırılarıdır" (Inversion & Inference Attacks). Saldırganlar, tedarikçinin API'sine binlerce özel kurgulanmış sorgu göndererek modelin arkasındaki tescilli veri tabanını veya modelin kendisini yeniden oluşturabilir. Tedarikçinin bu saldırı tiplerine karşı hız sınırlandırması (rate limiting), semantik girdi filtreleme ve anomali tespiti gibi güvenlik duvarları (AI Firewall) kullanıp kullanmadığı teknik olarak belgelenmelidir.

Çıktı Güvenilirliği: Halüsinasyon (Hallucination) ve Model Sapması (Model Drift)

Büyük dil modelleri, mantıksal gerçeklik doğrulaması yapan mekanizmalar değil, bir önceki kelimeden sonra gelmesi en muhtemel kelimeyi tahmin eden istatistiksel hesaplayıcılardır. Bu durum, modelin teknik veya hukuki olarak tamamen uydurma olan bilgileri son derece ikna edici bir dille sunmasıyla sonuçlanan Halüsinasyon (Hallucination) olgusunu ortaya çıkarır. Karar destek süreçlerinde kullanılan bir yapay zekanın yanlış çıktı üretmesi; hatalı tedarik siparişlerine, yanlış yasal beyanlara veya kusurlu ürün tasarımlarına neden olabilir.

+-----------------------------------------------------------------------------+
|              YAPAY ZEKA ENTEGRASYONUNDA KRİTİK RİSK HARİTASI               |
+-----------------------------------------------------------------------------+
|                                                                             |
|   1. VERİ GİZLİLİĞİ VE REGÜLASYON                                           |
|      ├── Model Eğitimi İhlali (Kurumsal girdilerin genel modele karışması)  |
|      ├── GDPR/KVKK Uyumsuzluğu (Eğitilmiş modelden verinin silinememesi)   |
|      └── Sınıraşan Veri Transferi (Sunucuların bilinmeyen yargı bölgelerinde)|
|                                                                             |
|   2. MODEL MANİPÜLASYONU VE SİBER GÜVENLİK                                 |
|      ├── Indirect Prompt Injection (Harici verilerle talimat geçersiz kılma)|
|      ├── Data Poisoning (RAG veya eğitim havuzunun manipüle edilmesi)       |
|      └── Model Inversion (API üzerinden eğitim verisinin çekilmesi)        |
|                                                                             |
|   3. OPERASYONEL PERFORMANS VE TUTARLILIK                                   |
|      ├── Halüsinasyon Riski (Olasılıksal uydurma veri üretimi)              |
|      ├── Model Sapması / Drift (Zamanla çıktı kalitesinin düşmesi)          |
|      └── Gizli Kuantizasyon (Tedarikçinin maliyet kısmak için modeli kısması)|
|                                                                             |
+-----------------------------------------------------------------------------+

Model Sapması (Model Drift), zaman içerisinde girdi verilerinin dağılımının değişmesi veya tedarikçinin model parametrelerinde sessizce yaptığı değişiklikler neticesinde modelin performansının düşmesidir. Örneğin, bir müşteri şikayeti sınıflandırma modeli ilk devreye alındığında %94 doğrulukla çalışırken, altı ay sonra tüketici terminolojisindeki değişimler veya arka plan güncellemeleri nedeniyle %70 doğruluğa gerileyebilir. Tedarikçinin sürekli performans izleme metrikleri (F1-score, perplexity, latency) ve otomatik doğruluk testleri sunup sunmadığı operasyonel sürdürülebilirlik açısından hayati önem taşır.

3. Yapay Zeka Tedarikçisi Seçiminde Masaya Getirilmesi Gereken 5 Temel Soru

Tedarikçi görüşmelerinde satış ve pazarlama ekiplerinin sunduğu genel geçer güvenceler teknik ve yasal denetim için yetersizdir. Karar vericilerin, sistemin derinliklerine inen, sözleşmeye bağlanabilir ve teknik ekiplerce doğrulanabilir somut sorular yöneltmesi gerekir.

Soru 1: Model Eğitiminde Kullanılan Verilerin Fikri Mülkiyet (IP) ve Telif Durumu Nedir?

Yapay zeka modelleri, internet üzerindeki milyarlarca metin, kod ve görsel üzerinden beslenir. Bu verilerin telif haklarına tabi olup olmadığı, dünya genelinde telif davalarının odak noktasıdır. Tedarikçinin temel modelinin (foundation model) telifli materyallerle eğitilmiş olması, bu modelin ürettiği çıktıları ticari süreçlerinde kullanan son kullanıcı kurumları da yasal risk altına sokabilir.

Tedarikçiye eğitim veri setlerinin kaynağı, kamuya açık lisanslara (Creative Commons, MIT vb.) uygunluğu ve eğitim sürecinde lisanssız veri kullanıldığı iddiasıyla açılabilecek davalara karşı müşteriyi koruyan bir "Tazminat Maddesi" (IP Indemnification Clause) sunup sunmadığı sorulmalıdır. Microsoft, Google ve AWS gibi büyük altyapı sağlayıcıları belirli kurumsal paketlerinde telif hakkı tazminat garantisi sunmaktadır. Girişim seviyesindeki tedarikçilerin ise bu riski nasıl sigortalattığı mutlaka denetlenmelidir.

Soru 2: Kurumsal Veriler Modelin Yeniden Eğitiminde (Fine-Tuning) Kullanılıyor mu?

Tedarikçiye sağlanan girdilerin ve elde edilen çıktıların, tedarikçinin genel model havuzuna dönüp dönmediği en kritik veri güvenliği sorusudur. Çoğu SaaS sağlayıcısı API katmanında veriyi eğitmediğini iddia etse de, web arayüzleri (UI) veya ara yazılımlar üzerinden gönderilen veriler farklı kullanıcı sözleşmelerine tabi olabilir.

• API Sözleşmesi: "Girdiler ve çıktılar, tedarikçinin temel veya türetilmiş modellerini geliştirmek, eğitmek veya iyileştirmek için hiçbir koşulda kullanılmayacaktır" maddesi aranmalıdır.

• İnce Ayar (Fine-Tuning) İzolasyonu: Eğer kuruma özel bir ince ayar (Fine-Tuning) yapılıyorsa, oluşturulan model ağırlıklarının (weights) ve adaptörlerin (LoRA) kuruma özel şifrelenmiş bir depolama alanında tutulup tutulmadığı ve diğer müşterilerin erişimine kapatıldığı doğrulanmalıdır.

• Çalışan Erişimi: Tedarikçi personelinin müşteri prompt'larını ve sistem yanıtlarını "manuel etiketleme" veya "hata ayıklama" amacıyla inceleme (human review) yetkisinin bulunup bulunmadığı netleştirilmelidir. Kurumsal sistemlerde bu yetki tamamen devre dışı bırakılmalıdır (Opt-out).

Soru 3: API Katmanında ve Veri Aktarımında Sıfır Saklama (Zero Data Retention) Garantisi Var mı?

Pek çok yapay zeka sağlayıcısı, sistemin kötüye kullanımını (abuse monitoring) tespit etmek amacıyla API üzerinden gelen istekleri ve üretilen yanıtları 30 güne kadar kendi sunucularında saklamaktadır. Finans, sağlık veya savunma gibi yüksek regülasyona tabi sektörlerde, üçüncü taraf bir sunucuda 30 gün boyunca loglanan veri doğrudan bir regülasyon ihlali teşkil eder.

Tedarikçinin "Zero Data Retention" (ZDR) seçeneğini etkinleştirip etkinleştirmediği sorulmalıdır. ZDR etkinleştirildiğinde, model çıkarımı tamamlandığı anda istemcinin verisi geçici RAM bellekten silinir ve diske hiçbir şekilde kalıcı log kaydı yazılmaz. Tedarikçinin bu süreci bağımsız denetim raporlarıyla (SOC 2 Tip II) belgeleyebilmesi beklenir.

Soru 4: ISO/IEC 42001, ISO 27001 ve SOC 2 Tip II Denetim Raporları Mevcut mu?

Geleneksel ISO/IEC 27001 standardı bilgi güvenliği yönetim sistemlerini tanımlarken, yapay zekaya özgü riskleri denetlemek üzere 2023 sonunda yayınlanan ISO/IEC 42001 (Yapay Zeka Yönetim Sistemi) standardı kurumsal AI olgunluğunun küresel referansıdır.

                                ISO/IEC STANDARTLARI VE KAPSAMI
┌─────────────────────────────────────────────────────────────────────────────────────────────┐
│                                                                                             │
│   ISO/IEC 27001: Bilgi Güvenliği Yönetim Sistemi                                           │
│   ├── Ağ ve Sunucu Güvenliği                                                                │
│   ├── Fiziksel Güvenlik ve Şifreleme                                                        │
│   └── Veri Erişim Politikaları (Kimlik Doğrulama)                                           │
│                                                                                             │
│   ISO/IEC 42001: Yapay Zeka Yönetim Sistemi (AI Özel Standardı)                             │
│   ├── Algoritmik Şeffaflık ve Açıklanabilirlik Standartları                                 │
│   ├── Eğitim Verisi Kalitesi, Önyargı ve Sapma Kontrolleri                                   │
│   ├── Olasılıksal Risk Değerlendirmesi ve Halüsinasyon Yönetimi                             │
│   └── Yaşam Döngüsü Boyunca İnsan Denetimi (Human-in-the-Loop) Tasarımı                    │
│                                                                                             │
└─────────────────────────────────────────────────────────────────────────────────────────────┘

Tedarikçiden ISO/IEC 42001 belgesine sahip olup olmadığı veya bu standardın Ek-A kontrollerine (Annex A Controls) uyum sağlayıp sağlamadığı sorulmalıdır. Eğer tedarikçi bu sertifikaya henüz sahip değilse, SOC 2 Tip II Güvenilirlik İlkeleri kapsamında yer alan "Gizlilik" (Confidentiality) ve "İşlem Bütünlüğü" (Processing Integrity) raporlarının en güncel kopyaları talep edilmelidir.

Soru 5: İnsan Denetimi (Human-in-the-Loop) ve Hata Düzeltme Protokolleri Nasıl Tasarlandı?

Yapay zeka sistemleri tamamen otonom çalıştığında operasyonel risk katsayısı katlanarak artar. Tedarikçinin çözüm mimarisinde kritik kararların bir insan onayından geçmesini sağlayan İnsan Denetimi (Human-in-the-Loop - HITL) arayüzlerinin veya geri bildirim döngülerinin (RLHF - Reinforcement Learning from Human Feedback) bulunup bulunmadığı sorgulanmalıdır.

Hatalı bir çıktı üretildiğinde veya sistem güvenlik duvarını aşan bir yanıt verdiğinde, kurum içi ekiplerin bu durumu anında işaretleyebileceği (flagging), sistemin bu çıktıyı derhal karantinaya alabileceği ve tedarikçiye hata bildirimi yapıldığında düzeltme sürecinin nasıl işleyeceği (SLA süreleri) yazılı olarak netleştirilmelidir.

4. Adım Adım Yapay Zeka Tedarikçi Risk Değerlendirme Metodolojisi

Yapay zeka tedarikçilerini değerlendirmek tek seferlik bir toplantı veya teknik özellik tablosu karşılaştırmasıyla tamamlanamaz. Yapılandırılmış, tekrarlanabilir ve kurumun kurumsal risk iştahıyla uyumlu üç aşamalı bir metodoloji uygulanmalıdır.

Aşama 1: Kullanım Senaryosu Sınıflandırması ve Kritiklik Tespiti (Triage)

Tedarikçi incelemesine başlamadan önce, satın alınacak yapay zeka aracının kurum içerisinde hangi görevde kullanılacağı tanımlanmalıdır. Her kullanım senaryosu aynı risk derecesine sahip değildir:

1. Düşük Riskli Senaryolar: Pazarlama metni taslakları hazırlama, kamuya açık verilerin özetlenmesi, dahili dokümantasyon için kod tamamlama. Bu senaryolarda kişisel veri veya fikri mülkiyet aktarımı asgari düzeydedir.

2. Orta Riskli Senaryolar: Müşteri hizmetleri botları, dahili bilgi tabanı aramaları (dahili dokümanlar üzerinden çalışan kurumsal RAG sistemleri), operasyonel raporlama asistanları. Bu aşamada veri sızıntısı ve halüsinasyon riskleri kurumu doğrudan etkileyebilir.

3. Yüksek Riskli Senaryolar: Kredi tahsis algoritmaları, İK işe alım ve performans değerlendirmeleri, tıbbi teşhis destek sistemleri, tedarik zinciri kritik karar otomasyonları, hukuki sözleşme analizi. Bu senaryolar, hatalı çıktılar durumunda doğrudan yasal ceza, finansal yıkım veya insan hakları ihlali riski taşır.

Kullanım senaryosu "Yüksek Risk" kategorisine giriyorsa, tedarikçi değerlendirmesi sadece Bilgi Teknolojileri departmanı tarafından değil; Hukuk Müşavirliği, Risk Yönetimi, Uyum (Compliance) ve Veri Koruma Görevlisi (DPO) ekiplerinin yer aldığı ortak bir komisyon tarafından yürütülmelidir.

Aşama 2: Teknik Mimari, Veri Akışı ve Güvenlik Denetimi

Kritiklik düzeyi belirlendikten sonra tedarikçinin sunduğu teknik mimarinin derinlemesine incelenmesi gerekir. Bu aşamada bir Veri Akış Şeması (Data Flow Diagram - DFD) talep edilmelidir. Şema üzerinde şu parametreler doğrulanmalıdır:

• Veri Depolama Konumu (Data Residency): Verilerin hangi ülkede, hangi bulut sağlayıcısında (AWS, GCP, Azure vb.) ve hangi veri merkezinde işlendiği doğrulanmalıdır. Avrupa Birliği Genel Veri Koruma Tüzüğü (GDPR) ve Türk Kişisel Verilerin Korunması Kanunu (KVKK) uyarınca, açık rıza veya yeterlilik kararı olmaksızın verilerin yurt dışına aktarılması hukuki yaptırım doğurur.

• Mimari Tercihi (RAG vs. Fine-Tuning): Tedarikçinin verileri nasıl bağlamsallaştırdığı incelenmelidir. Bilgiye dayalı doğruluk gerektiren işlerde RAG (Retrieval-Augmented Generation) mimarisi tercih edilmelidir; zira RAG sistemlerinde kurumsal veriler modelin parametrelerine gömülmez, harici bir vektör veritabanında saklanır ve sorgu anında bağlam olarak modele aktarılır. Bu, modelin halüsinasyon oranını düşürür ve veri yönetimini kurumun kontrolünde tutar.

• Şifreleme Standartları: Veri aktarımında TLS 1.3 zorunluluğu, dinlenme halindeki verilerde en az AES-256 şifreleme ve kurumun kendi anahtarlarını yönetebilmesine (BYOK - Bring Your Own Key) imkan tanıyan şifreleme katmanları aranmalıdır.

                    ÜÇ ADIMLI TEDARİKÇİ DENETİM VE GEÇİŞ PROTOKOLÜ
┌─────────────────────────────────────────────────────────────────────────────────────────────┐
│                                                                                             │
│  [AŞAMA 1: TRİAGE & SINIFLANDIRMA]                                                          │
│  │                                                                                          │
│  ├── Kullanım Senaryosu Risk Skoru (Düşük / Orta / Yüksek)                                  │
│  ├── İşlenecek Verinin Niteliği (Açık Veri / PII / Ticari Sır)                              │
│  └── Hukuk ve Uyum Komisyonunun Onay Eşiği                                                  │
│                                                                                             │
│  [AŞAMA 2: TEKNİK VE MİMARİ DOĞRULAMA]                                                      │
│  │                                                                                          │
│  ├── Veri Akış Şeması (Data Flow Diagram) ve Veri Lokasyonu (Data Residency)                │
│  ├── RAG vs. Fine-Tuning Ayrımı ve Vektör Veritabanı İzolasyonu                             │
│  └── Sıfır Veri Saklama (ZDR) ve API Güvenlik Testleri                                      │
│                                                                                             │
│  [AŞAMA 3: HUKUKİ PROTOKOL VE SÜREKLİ İZLEME]                                               │
│  │                                                                                          │
│  ├── IP Tazminat Garantisi ve Veri İşleyen (Processor) Sözleşmesi                          │
│  ├── SLA Çıktı Performansı, Doğruluk Sapması Takibi ve Hata Bildirimi                      │
│  └── Veri İade/İmha Garantili Çıkış Stratejisi (Exit Strategy)                             │
│                                                                                             │
└─────────────────────────────────────────────────────────────────────────────────────────────┘

Aşama 3: Yasal Sözleşmeler, Hizmet Seviyesi Taahhütleri (SLA) ve Çıkış Stratejisi

Teknik doğrulaması tamamlanan tedarikçiyle yürütülecek sözleşme müzakerelerinde geleneksel SLA parametreleri (örneğin %99.9 sunucu çalışma süresi) yeterli değildir. Yapay zekaya özgü SLA metrikleri devreye sokulmalıdır:

• Gecikme Süresi (Latency) ve Çıkarım Hızı: Modelin belirli bir token uzunluğundaki girdiye kaç milisaniyede yanıt üreteceği belirlenmelidir.

• Doğruluk ve Sapma Bildirimi: Tedarikçinin arka planda model güncellemesi yapmadan en az 30 gün önce müşteriyi bilgilendirme zorunluluğu olmalıdır.

• Çıkış Stratejisi (Exit Strategy) ve Veri Taşınabilirliği: Tedarikçiyle çalışmanın sonlandırılması durumunda, sisteme yüklenen tüm dokümanların, oluşturulan vektör indekslerinin ve ince ayar yapılmışsa ilgili adaptör ağırlıklarının eksiksiz, okunabilir bir formatta iade edileceği ve tedarikçi sunucularından kriptografik olarak silineceği sözleşmeye eklenmelidir.

5. Regülasyon Uyumu: EU AI Act, Standartlar ve Yasal Sorumluluklar

Yapay zeka teknolojilerinin kurumsal kullanımı, küresel ölçekte katı regülasyon kurallarına bağlanmaktadır. Bir organizasyonun üçüncü taraf bir yapay zeka aracını bünyesine katması, onu bu düzenlemelerin getirdiği yasal sorumluluklardan muaf kılmaz. Aksine, regülasyonlar genellikle "sağlayıcı" (provider) ile "uygulayıcı" (deployer) arasında paylaşımlı bir sorumluluk modeli kurar.

Avrupa Birliği Yapay Zeka Yasası (EU AI Act) Risk Sınıflandırması

Avrupa Birliği sınırları içinde faaliyet gösteren veya AB vatandaşlarının verilerini işleyen şirketleri doğrudan bağlayan Avrupa Birliği Yapay Zeka Yasası (EU AI Act), sistemleri dört risk kategorisine ayırmaktadır:

1. Kabul Edilemez Risk (Unacceptable Risk): Sosyal puanlama sistemleri, bilişsel davranış manipülasyonu yapan sistemler ve kamuya açık alanlarda gerçek zamanlı biyometrik kimlik tespiti gibi uygulamalar tamamen yasaklanmıştır.

2. Yüksek Risk (High-Risk): Kritik altyapı yönetimi, eğitim ve mesleki eğitimde erişim kararları, istihdam ve çalışan yönetimi araçları, temel kamu hizmetlerine erişim ve kredi skorlama sistemleri bu gruptadır. Bir tedarikçiden bu alanlarda yapay zeka yazılımı satın alınıyorsa; sistemin risk yönetim sistemine sahip olması, yüksek kaliteli eğitim verisi kullanması, detaylı teknik dokümantasyon sunması, insan denetimine izin vermesi ve yüksek düzeyde siber güvenlik dayanıklılığı taşıması zorunludur.

3. Sınırlı Risk (Limited Risk): Doğrudan insanlarla etkileşime giren sohbet robotları (chatbots) ve duygu tanıma sistemleri. Bu sistemlerde temel şart şeffaflıktır (transparency); kullanıcının bir yapay zekayla muhatap olduğunu açıkça bilmesi gerekir.

4. Minimal / Düşük Risk: Spam filtreleri, yapay zeka destekli video oyunları. Bu sistemler ek yasal yükümlülük olmaksızın serbestçe kullanılabilir.

Uygulayıcı kurum, yüksek riskli bir alanda üçüncü taraf bir araç kullanıyorsa ve bu araç EU AI Act gerekliliklerini karşılamıyorsa, küresel cirosunun %7'sine veya 35 milyon Euro'ya (hangisi yüksekse) varan ağır idari para cezalarıyla karşı karşıya kalabilir.

ISO/IEC 42001 ve NIST AI Risk Yönetimi Çerçevesi (AI RMF)

Yasal mevzuatların yanı sıra, teknik denetimlerde kullanılan iki temel çerçeve öne çıkmaktadır:

• NIST AI RMF 1.0 (National Institute of Standards and Technology - AI Risk Management Framework): Amerikan Ticaret Bakanlığı'na bağlı NIST tarafından geliştirilen bu çerçeve; Yönetişim (Govern), Haritalama (Map), Ölçümleme (Measure) ve Yönetme (Manage) olmak üzere dört temel fonksiyondan oluşur. Tedarikçinin yapay zeka risklerini ölçümlemek için NIST AI RMF göstergelerini kullanıp kullanmadığı kontrol edilmelidir.

• ISO/IEC 42001 Standardı: Dünyanın ilk akredite edilebilir Yapay Zeka Yönetim Sistemi standardıdır. Bir tedarikçinin bu sertifikaya sahip olması; model yaşam döngüsü yönetimi, risk analizi, veri kalitesi yönetimi ve etik ilkeler konusunda bağımsız denetimlerden başarıyla geçtiğini belgeler.

Tedarikçi Zincirinde Sorumluluk Paylaşımı ve Sözleşmesel Güvenceler

Bulut bilişimdeki "Paylaşımlı Sorumluluk Modeli" (Shared Responsibility Model), yapay zekada daha karmaşık bir yapıya bürünür:

+-----------------------------------------------------------------------------+
|               YAPAY ZEKA PAYLAŞIMLI SORUMLULUK MODELİ                       |
+-----------------------------------------------------------------------------+
|                                                                             |
|   KATMAN                 SAĞLAYICI (VENDOR)      UYGULAYICI (MÜŞTERİ)       |
|   ───────────────────────────────────────────────────────────────────────   |
|   Temel Model (Weights)  [  TAM SORUMLU  ]       [    SORUMSUZ   ]         |
|   Eğitim Verisi Telifi   [  TAM SORUMLU  ]       [    SORUMSUZ   ]         |
|   Altyapı Güvenliği      [  TAM SORUMLU  ]       [    SORUMSUZ   ]         |
|   İnce Ayar (Fine-Tune)  [ PAYLAŞILAN RİSK ]     [ PAYLAŞILAN RİSK ]         |
|   Prompt / Girdi Verisi  [    SORUMSUZ   ]       [  TAM SORUMLU  ]         |
|   Çıktının Doğrulanması  [    SORUMSUZ   ]       [  TAM SORUMLU  ]         |
|   Nihai İşlem Kararı     [    SORUMSUZ   ]       [  TAM SORUMLU  ]         |
|                                                                             |
+-----------------------------------------------------------------------------+

Tedarikçinin sorumluluğu modelin inşası, altyapısı ve temel ağırlıklarıyla sınırlıyken; modele beslenen kurumsal verilerin meşruiyeti, sistemin kullanım amacı ve modelin ürettiği çıktıların doğrulanması tamamen uygulayıcı kurumun sorumluluğundadır. Bu nedenle sözleşmelerde "Kullanıcı, model çıktılarının doğruluğunu kendi imkanlarıyla teyit etmekle yükümlüdür" benzeri tedarikçi lehine olan maddeler dikkatle incelenmeli, operasyonel süreçlerde kritik iş akışları doğrudan model çıktısına bağlanmamalıdır.

6. Karar Alıcılar İçin Kurumsal AI Risk Yönetimi Stratejisi

Yapay zeka sistemlerinin sunduğu üretkenlik potansiyelinden yararlanırken kurumsal varlıkları korumak, temkinli ve gerçekçi bir yönetişim anlayışını gerektirir. Teknolojiyi tamamen reddetmek rekabet dezavantajı yaratırken, kontrolsüz bir şekilde operasyonlara entegre etmek felaketle sonuçlanabilir.

Gerçekçi Beklentiler: Tam Otomasyon Yanılgısı ve Risk Toleransı

Yapay zekanın her iş sürecini kusursuzca ve otonom biçimde devralacağı beklentisi tehlikeli bir yanılgıdır. Karar vericilerin benimsemesi gereken ana ilke: "Yapay zeka bir karar alıcı değil, karar destek asistanıdır."

Risk toleransı düşük olan muhasebe, bordrolama, yasal sözleşme hazırlama, tıbbi tanı ve siber güvenlik olay müdahalesi gibi alanlarda sistemler hiçbir zaman tam otomasyona bırakılmamalıdır. Sistem her zaman insan gözetimini zorunlu kılan mekanizmalarla çevrelenmelidir. Bir yapay zeka ajanının (AI Agent) kendi başına e-posta göndermesi, satın alma yapması veya kod tabanına doğrudan commit atması gibi uç senaryolar, yalnızca belirli finansal ve operasyonel eşiklerin altındaki düşük riskli görevler için tanımlanmalıdır.

Model Bağımlılığını (Vendor Lock-in) Önleme ve RAG Mimarisi Alternatifleri

Tek bir yapay zeka modeline veya tedarikçisine derinlemesine bağımlı hale gelmek, kurumu ciddi fiyat artışlarına, servis kesintilerine veya tedarikçinin hizmet politikasını değiştirmesine karşı savunmasız bırakır. Karar vericiler mimariyi tasarlarken şu stratejileri uygulamalıdır:

• Model Bağımsızlığı (Model-Agnostic Architecture): Uygulama katmanı ile yapay zeka modelleri arasına bir soyutlama katmanı (LiteLLM, LangChain, LlamaIndex gibi entegrasyon arayüzleri veya API Gateway'ler) yerleştirilmelidir. Böylece tek bir satır kod değiştirmeden OpenAI, Anthropic, Google veya açık kaynaklı bir modele geçiş yapılabilir.

• Fine-Tuning Yerine RAG Önceliği: Kurumsal verileri doğrudan modelin içine ince ayar (Fine-Tuning) ile gömmek yerine, verileri kendi denetiminizdeki bir vektör veritabanında tutarak RAG (Retrieval-Augmented Generation) mimarisini tercih edin. RAG mimarisi hem verinin silinmesini ve güncellenmesini kolaylaştırır hem de yarın daha yetenekli ve ucuz bir temel model çıktığında veritabanınızı o modele kolayca bağlamanızı sağlar.

+-----------------------------------------------------------------------------+
|                 MODEL-AGNOSTIC VE RAG MERKEZLİ MİMARİ                       |
+-----------------------------------------------------------------------------+
|                                                                             |
|   KURUMSAL UYGULAMA KATMANI (ERP / CRM / Dahili Portallar)                  |
|          │                                                                  |
|          ▼                                                                  |
|   ┌─────────────────────────────────────────────────────────────┐           |
|   │ AI GATEWAY / SOYUTLAMA KATMANI (API & Rate Limit Yönetimi)  │           |
|   └──────────────────────────────┬──────────────────────────────┘           |
|                                  │                                          |
|         ┌────────────────────────┴────────────────────────┐                 |
|         ▼                                                 ▼                 |
|   [KURUMSAL RAG KATMANI]                       [MODEL SEÇİM HAVUZU]         |
|   - Güvenli Vektör Veritabanı                  - Model A (Tescilli API)     |
|   - Yerel Erişim İzinleri (RBAC)               - Model B (Açık Kaynak/Local)|
|   - Veri Maskeleme & Filtreleme                - Model C (Özel Altyapı)     |
|                                                                             |
+-----------------------------------------------------------------------------+

Tedarikçi Yaşam Döngüsü: Sürekli Denetim ve Performans Takibi

Tedarikçi seçim süreci sözleşmenin imzalanmasıyla sona ermez; aksine yeni bir izleme döngüsü başlar. Karar alıcılar, tedarikçiyle olan iş birliğini üçer veya altışar aylık periyotlarla teknik denetimlere tabi tutmalıdır:

• Prompt ve Güvenlik Testleri (Red Teaming): Tedarikçinin API'si dönemsel olarak sızma ve prompt manipülasyon testlerine tabi tutulmalı, güvenlik duvarlarının etkinliği ölçülmelidir.

• Gizli Kuantizasyon Denetimi: Tedarikçilerin sunucu maliyetlerini kısmak amacıyla modelleri arka planda daha düşük hassasiyetli (FP16'dan INT4'e) sürümlerle değiştirip değiştirmediği, belirlenen test sorguları üzerinden yanıt kalitesi ve F1 skoru takibi yapılarak izlenmelidir.

• Sözleşme ve Sertifika Yenilemeleri: SOC 2 Tip II ve ISO sertifikalarının geçerlilik tarihleri yıllık bazda takip edilmeli, süresi dolan sertifikaların yeni raporları talep edilmelidir.