Private Cloud vs Public LLM: Stratejik Ayrım

Büyük dil modelleri (LLM) iş süreçlerine hızla girerken asıl soru modelin kendisinden çok nerede çalıştığıdır. Veri bir Public LLM (SaaS API) üzerinden mi işlenir, yoksa Private Cloud veya On-Premises ortamında kurum ağı içinde mi kalır?

Bu tercih güvenlik, veri egemenliği, yasal uyum, maliyet ve performansı doğrudan belirler. Aşağıda Public LLM ile Private Cloud / On-Premises yaklaşımlarını bu açılardan karşılaştırıyoruz.

Veri güvenliği ve sızıntı riskleri

Public API’ler veya kontrolsüz SaaS abonelikleriyle yürüyen yapay zeka süreçleri, veriyi kurum ağı dışına taşır. Prompt’lar, RAG girdileri ve model çıktıları kamusal internet üzerinden üçüncü taraf sunuculara gider. İzleme zayıfsa sızıntıyı yakalamak zorlaşır.

Shadow AI (yetkisiz yapay zeka araçlarının kullanımı), hangi ticari sırların veya kişisel verilerin dışarı çıktığını takip etmeyi zorlaştırır. Tüketici planlarında veya giriş seviyesindeki kurumsal aboneliklerde işlem üçüncü taraf altyapıda kaldığı için veri egemenliği zayıflar.

Risk yalnızca veri aktarımıyla sınırlı değildir. Prompt Injection ve Data Poisoning gibi uygulama katmanı saldırıları SaaS LLM kullanımında da geçerlidir. RAG mimarilerinde RBAC zayıfsa, düşük yetkili bir kullanıcı LLM üzerinden erişmemesi gereken belgelere ulaşabilir. Standart API sözleşmelerindeki 30 günlük abuse monitoring saklama süreleri de ihlal sonrası risk süresini uzatır.

Mimari ve veri akışı

Public LLM (SaaS) tarafında istek yerel ağdan çıkar, sağlayıcının çok kiracılı (multi-tenant) altyapısına gider. API ağ geçidinde işlenir, yetkilendirilir ve inference kümesine yönlendirilir. Verinin işlendiği konum, bellekte kalma süresi ve log’lara yazılıp yazılmaması büyük ölçüde sağlayıcı politikasına bağlıdır.

Private Cloud veya On-Premises tarafında veri belirlenen güvenlik sınırları içinde kalır. İstekler bir AI Gateway üzerinden kimlik doğrulama, maskeleme ve güvenlik politikası kontrollerinden geçer, ardından VPC veya veri merkezindeki GPU kümelerine iletilir. Inference, vLLM, SGLang veya TensorRT-LLM gibi sunucu motorlarında çalışır. İşlem bitince veri kalıcı depolamaya yazılmadan bellekten temizlenir. Yanıt yerel ağ üzerinden döner.

Mimari özellik	Public LLM (SaaS API)	Private Cloud (VPC / Single-Tenant)	On-Premises / Air-Gapped
Barındırma	Üçüncü taraf kamusal bulut	Kuruma özel izole bulut alanı	Veri merkezi / yerel sunucu
Veri sınırı	Şirket dışı (kamusal internet)	Şirket kontrolünde sanal ağ	Tamamen şirket içi (LAN)
Kurulum	Dakikalar / saatler	Günler / haftalar	Haftalar / aylar
CapEx	Yok (kullandıkça öde)	Düşük-orta (bulut kiralama)	Yüksek (GPU / sunucu)
Gecikme	İnternete bağlı / değişken	Düşük ve öngörülebilir	Çok düşük (LAN)
Model özelleştirme	Sınırlı (prompt / fine-tuning)	Yüksek (açık model ağırlıkları / LoRA)	Tam kontrol (full fine-tuning)
Veri egemenliği	Sözleşmeye bağlı risk	Yüksek (bölgesel depolama)	Mutlak
Ölçeklenebilirlik	Anlık ve esnek	Otomatik esnek ölçekleme	Donanım kapasitesiyle sınırlı

Performans tarafında donanım ve bellek bant genişliği belirleyicidir. NVIDIA H100 / H200 kümelerinde vLLM ile toplu (batch) iş yüklerinde yüksek token çıktısı alınabilir. Sonuç BF16 / FP8 / FP4 kuantizasyonu ve NVLink bağlantısına bağlıdır.

Yasal uyum: KVKK, GDPR ve EU AI Act

Kişisel verinin Public LLM API’lerine prompt veya belge olarak gitmesi, Türkiye’de KVKK kapsamında yurtdışına aktarım kurallarını tetikleyebilir. Taahhütname, standart sözleşme veya geçerli açık rıza yoksa bu kullanım hukuki risk doğurur. Tamamen otomatik kararlarda etkin insan denetimi (human-in-the-loop) ve gerektiğinde DPIA de gündeme gelir.

GDPR ve EU AI Act yapay zeka sistemlerini risk kategorilerine ayırır. İhlallerde cironun önemli bir oranına varan cezalar söz konusu olabilir. Burada Zero Data Retention (ZDR) kritik bir kontroldür: işlem geçici bellekte kalır, diske prompt / yanıt / metadata yazılmaz. Standart SaaS hesapları abuse monitoring için veriyi günlerce tutabilir. Kurumsal ZDR ise çoğu zaman özel sözleşme ister.

Bazı sağlayıcılar bölgesel veri sınırları (ör. Azure OpenAI EU Data Boundary) sunsa da yerel barındırma seçenekleri her yerde aynı değildir. Yüksek hassasiyetli veride Private Cloud / On-Premises, uyum açısından daha öngörülebilir bir seçenek sunar.

Maliyet ve TCO

Yalnızca API birim fiyatına bakmak yanıltıcıdır. Token maliyeti düştükçe kullanım hacmi artabilir (Jevons Paradoksu), toplam bütçe yine büyür. Public LLM’de maliyet iş yüküne göre değişir ve ani sorgu artışları beklenmedik fatura yükselişine yol açabilir. Private Cloud / On-Premises’te ise CapEx + OpEx dengesi vardır.

Basit bir TCO hesabı:

Yıllık TCO = (Donanım / Amortisman) + Enerji ve soğutma + Bakım ve lisans + Personel ve operasyon

GPU bedeli çoğu zaman toplamın küçük kısmıdır. Operasyon, izleme, entegrasyon ve mühendislik maliyeti yalnızca GPU maliyetinin birkaç katına çıkabilir.

Maliyet tarafında asıl kırılma noktası iş yükü profilidir. Düşük veya dalgalı trafikte Public LLM genelde daha esnek ve başlangıç maliyeti düşük kalır. Yüksek ve sürekli yükte Private Cloud / On-Premises, birim maliyeti düşürebilir. Kendi altyapınızda barındırmada kritik risk atıl kapasitedir: küme doluyken token maliyeti düşer, trafik seyrekse fiili maliyet hızla yükselir.

AI Gateway: güvenlik ve akıllı yönlendirme

Dağıtımı tek noktadan denetlemek için AI Gateway katmanı faydalıdır. Gateway, uygulamalar ile modeller arasında durumu tutmayan (stateless) bir ara katman gibi çalışır. İstekler doğrudan modele gitmez, önce bu katmanda işlenir.

Tipik akış:

1. Yerel NER ile PII tarama ve maskeleme
2. RBAC ile yetki kontrolü
3. Semantic caching ile tekrarlayan sorularda API / GPU tasarrufu
4. Smart routing: basit işler yerel SLM’lere, karmaşık muhakeme ZDR’li Public LLM’lere

RAG bağlamı yalnızca inference süresince bellekte tutulur. Yanıt gateway’de maskesi kaldırılarak kullanıcıya döner. Böylece güvenlik politikası ve maliyet kontrolü aynı noktadan uygulanır.

Sonuç: stratejik ayrım

Tek doğru model yok. Seçim veri hassasiyetine, iş yükü profiline ve yasal gereksinimlere bağlıdır.

• Hassas müşteri ve risk verisi (finans, bankacılık, sigorta): On-Premises veya izole Private Cloud öne çıkar.
• Sağlık ve biyoteknoloji: yerel SLM + izole RAG çoğu zaman zorunlu yaklaşım olur.
• Düşük hassasiyetli içerik ve hızlı deneme: Public LLM, AI Gateway ve ZDR ile birlikte kullanılabilir.

Pratikte en dengeli yol çoğu zaman hibrit ve risk bazlı yönlendirmeli mimaridir. Hassas ve sürekli işler Private Cloud / On-Premises’te kalır. Yüksek muhakeme gerektiren genel işler gateway kontrolünde Public LLM’e gider. Güvenlik, maliyet ve performans bu ayrım üzerinden dengelenir.