On-Prem vs Bulut: Kurumsal AI Mimarileri Karşılaştırması (Hibrit Yaklaşım Dahil)

Kurumsal ölçekte yapay zeka teknolojileri devreye alırken en kritik kararların başında “nerede çalıştıracağız?” sorusu gelir: kurum içi veri merkezinde (on‑prem), genel bulutta, yoksa hibrit bir mimaride mi? Bu karar yalnızca maliyeti değil; veri yönetişimini, uyumluluk yaklaşımını, gecikmeyi (latency), ekibin operasyonel yükünü ve ürünün pazara çıkış hızını etkiler.

Bu yazı, on‑prem, bulut ve hibrit AI mimarilerini pratik bir çerçeveyle karşılaştırır; hangi senaryoda hangi yaklaşımın daha mantıklı olabileceğini, hangi soruları sormanız gerektiğini ve kararınızı nasıl doğrulayacağınızı adım adım açıklar. Ayrıca AI risklerini ele almak için NIST’in AI Risk Management Framework’ünü (AI RMF) mimari kararlarla ilişkilendirir.

Önce kavramları netleştirelim: On‑prem, bulut ve hibrit AI nedir?

On‑prem (kurum içi) AI

Model eğitimi, ince ayar (fine-tuning), çıkarım (inference) ve veri işleme iş yüklerinin kurumun kendi veri merkezinde veya kuruma ayrılmış ortamlarında çalıştırılmasıdır. Donanım (GPU/CPU), depolama, ağ ve güvenlik kontrolleri daha fazla kurumun sorumluluğundadır.

Bulut AI

AI/ML iş yüklerinin genel bulut sağlayıcılarının altyapısı ve yönetilen hizmetleri üzerinde çalıştırılmasıdır. Yönetilen ML platformları hızlı kurulum ve ölçekleme sunar. Örneğin AWS’nin SageMaker ekosistemi, kurulumdan model dağıtımına kadar yönetilen bileşenler sağlar (sağlayıcı dokümantasyonu). Kaynak: https://aws.amazon.com/documentation-overview/sagemaker/

Hibrit AI (ve “dağıtılmış bulut” yaklaşımları)

Veri ve iş yüklerinin bir kısmının kurum içinde, bir kısmının bulutta çalıştığı; arada güvenli veri akışının kurulduğu yaklaşımdır. Bazı senaryolarda bulut sağlayıcılarının “dağıtılmış bulut / on‑prem bulut” çözümleriyle (ör. belirli ürün aileleri) bulut işletim modelini kurum içine taşımak da bu kapsama girer. Google Distributed Cloud gibi yaklaşımlar, veri yerinde işleme, düşük gecikme ve air‑gapped (izole) senaryoları için ürün anlatımları sunar. Kaynak: https://cloud.google.com/distributed-cloud-hosted

Karşılaştırma özeti: Hangi mimari hangi gereksinime daha yakın?

Aşağıdaki tablo, en sık tartışılan boyutlarda hızlı bir kıyas sunar. “Daha iyi” olan seçenek, kurumunuzun risk iştahına, veri hassasiyetine, ekip yetkinliğine ve iş yükü desenine göre değişir.

Uyumluluk ve risk yönetimi: Mimari kararını NIST AI RMF ile bağlamak

Mimari seçimi yalnızca teknik bir konu değildir; risk yönetimi ve yönetişim konusudur. NIST’in Artificial Intelligence Risk Management Framework (AI RMF) dokümanı, AI yaşam döngüsü boyunca riskleri tanımlama, ölçme, yönetme ve belgeleme için bir çerçeve sunar. Bu çerçeve, ister bulutta ister on‑prem çalışın, “riskleri görünür kılma” ve “süreçle yönetme” açısından faydalı bir referans noktasıdır. Kaynak: https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf

Pratikte AI RMF’i şu şekilde mimari kararlara yansıtabilirsiniz:

• Varlık envanteri: Hangi veri setleri, modeller, üçüncü taraf bileşenler ve uç noktalar nerede çalışacak?
• Risk kayıtları ve kanıt: Veri akış diyagramları, erişim kontrolleri, loglama, model sürümleri ve değerlendirme sonuçları için kanıt üretimi.
• Yaşam döngüsü yönetimi: Eğitimden dağıtıma, izleme ve geri alma (rollback) planına kadar süreç sahipliği.

Not: Bu yazı hukuki uyumluluk danışmanlığı değildir. Sektör ve eyalet bazında gereksinimler değişebileceğinden kurum içi hukuk/uyumluluk ekipleriyle doğrulama yapılmalıdır.

Gecikme (latency) ve veri yerinde işleme: Ne zaman on‑prem/yerel daha anlamlı olabilir?

Gecikme hedefleri, özellikle gerçek zamanlı çıkarım gerektiren kullanım durumlarında (ör. üretim hattı kalite kontrolü, çağrı merkezi anlık asist, finansal işlemlerde dolandırıcılık sinyalleri gibi) mimariyi belirler. Bu noktada, “veriyi modele taşıma” ile “modeli veriye yakınlaştırma” arasında bir denge kurulur.

Google Distributed Cloud gibi dağıtılmış yaklaşımlar, belirli senaryolarda veri yerinde işleme ve düşük gecikme ihtiyaçlarına vurgu yapar (sağlayıcı ürün/dokümantasyon anlatımı). Kaynak: https://cloud.google.com/distributed-cloud-hosted

On‑prem veya yerel dağıtımların daha sık tercih edildiği durumlara örnekler:

• Ağ bağımlılığı azaltma: İnternet bağlantısı kısıtlı/kararsız lokasyonlar.
• Çok sıkı gecikme hedefleri: Milisaniye seviyesinde tepkilerin kritik olduğu süreçler.
• Veri yerelliği ve izolasyon: Bazı kurumlarda verinin belirli sınırlar içinde kalması için tasarım tercihleri.

Operasyonel gerçekler: “Kim yönetecek?” sorusu çoğu kararı belirler

AI platformu seçerken yalnızca model doğruluğu değil, platformun işletimi de belirleyici olur:

• Altyapı işletimi: GPU sürücüleri, kernel/OS güncellemeleri, güvenlik yamaları, kapasite planlama.
• MLOps: Model sürümleme, CI/CD, feature store yaklaşımı, izleme ve geri alma.
• Güvenlik operasyonları: Erişim yönetimi, anahtar yönetimi, olay müdahalesi, log saklama.

Bulut tarafında yönetilen ML platformları bu yükün bir kısmını azaltmayı hedefler. Örneğin SageMaker dokümantasyonu, eğitim/dağıtım ve entegre bileşenler üzerinden operasyonel kolaylıklar sunar (sağlayıcı dokümantasyonu). Kaynak: https://aws.amazon.com/documentation-overview/sagemaker/

Hibrit yaklaşımda ise iki dünyanın süreçlerini entegre etmeniz gerekir: kimlik ve erişim, ağ topolojisi, gözlemlenebilirlik (observability) ve dağıtım otomasyonu gibi konular proje başarısını doğrudan etkiler. Microsoft’un hibrit platform anlatımı, hibrit yaklaşımın kurumsal kullanım senaryolarını ve “yerinde” dağıtım modellerini ele alır (sağlayıcı dokümanı). Kaynak: https://download.microsoft.com/download/2/8/1/281F9BFF-2722-4D44-8B8D-DB6C3469F3B6/Microsoft_Azure_The_Complete_Hybrid_Platform.pdf

TCO (toplam sahip olma maliyeti): Neyi ölçmezseniz yanlış sonuç çıkar?

TCO karşılaştırması, “sunucu fiyatı” hesabından çok daha geniştir. Araştırma paketindeki bulguya paralel şekilde, bağımsız ve doğrudan karşılaştırmalı TCO/benchmark çalışmalarının her senaryo için genellenebilir olması zordur; maliyetler kurumun iş yükü desenine göre değişir. Bu nedenle aşağıdaki kalemleri birlikte ölçmeden karar vermemek gerekir:

• Sermaye ve amortisman: On‑prem donanım alımı, yenileme döngüsü, kapasite fazlası.
• Operasyonel işçilik: Platform ekibi, güvenlik, ağ, DevOps/MLOps eforu.
• Enerji ve veri merkezi maliyetleri: Güç/soğutma, yer, bakım.
• Kullanım bazlı maliyetler: Bulutta hesaplama, depolama, veri çıkışı/transferi, yönetilen servis ücretleri.
• Verimlilik maliyeti: Projeyi başlatma süresi, deneme-yanılma hızının iş değerine etkisi.

Pratik öneri: TCO’yu tek bir toplam rakam yerine, 3 senaryo üzerinden modelleyin: (1) pilot/öğrenme, (2) sınırlı üretim, (3) ölçekli üretim. Her senaryoda günlük/aylık çıkarım hacmi, model güncelleme sıklığı ve veri büyümesi varsayımlarını yazılı hale getirin.

Kurumsal karar çerçevesi: 10 soruluk hızlı kontrol listesi

Aşağıdaki sorulara net cevap vermek, doğru mimariyi seçmeyi kolaylaştırır:

1. Veri sınıflandırmanız nedir? (hassas veri, ticari sır, kişisel veri vb.)
2. Gecikme hedefiniz nedir? (ör. p95/p99 hedefleri) ve bunu nasıl ölçeceksiniz?
3. Çıkarım hacmi ve zirve deseniniz nedir? (öngörülebilir mi, dalgalı mı?)
4. Model yaşam döngüsü: Modeli ne sıklıkla güncelleyeceksiniz? Geri alma planınız var mı?
5. Gözlemlenebilirlik: Loglar, metrikler, izler (traces) nerede toplanacak ve ne kadar saklanacak?
6. Erişim ve kimlik: Kim hangi veriye ve modele erişecek? Ayrıcalıklar nasıl yönetilecek?
7. Ağ ve bağlantı: Buluta bağlantı kapasitesi, kesinti toleransı, yedeklilik yaklaşımı?
8. Güvenlik kontrolleri: Anahtar yönetimi, şifreleme, güvenlik yamaları ve zafiyet yönetimi kimde?
9. Ekip yetkinliği: Donanım/cluster işletimi mi daha güçlü, yoksa bulut/MLOps otomasyonu mu?
10. Risk yönetimi kanıtı: NIST AI RMF gibi bir çerçeveyle riskleri nasıl belgeleyeceksiniz?

Örnek mimari desenler (kurumların sık kullandığı pratik yaklaşımlar)

1) Bulutta hızlı başlangıç + üretimde seçici optimizasyon

Pilot aşamada bulutun yönetilen hizmetleriyle hızlı prototipleme; üretimde maliyet ve gecikmeye göre bazı bileşenleri optimize etme yaklaşımıdır. Özellikle ürün/iş birimi doğrulaması (MVP) hedefleniyorsa sık görülür. Yönetilen ML platformları bu hızlı başlangıca yardımcı olabilir (örn. AWS SageMaker dokümantasyon yaklaşımı). Kaynak: https://aws.amazon.com/documentation-overview/sagemaker/

2) Hassas veri yerelde + model geliştirme/orkestrasyon bulutta (hibrit)

Hassas veri, kurum içi kontrol altında kalır. Model geliştirme süreçleri için bulut kaynakları kullanılır; yalnızca gerekli öznitelikler taşınır veya uygun tekniklerle veri minimizasyonu yapılır. Bu desen, veri yerelliği beklentileri ile bulutun esnekliğini dengelemek isteyen kurumlarda yaygındır (hibrit platform anlatımları). Kaynak: https://download.microsoft.com/download/2/8/1/281F9BFF-2722-4D44-8B8D-DB6C3469F3B6/Microsoft_Azure_The_Complete_Hybrid_Platform.pdf

3) Uç/şube lokasyonlarında yerel çıkarım + merkezi izleme

Perakende mağazaları, fabrikalar veya kampüsler gibi dağıtık ortamlarda çıkarım yerelde yapılırken; izleme, model sürümü ve politika yönetimi merkezden yürütülür. Dağıtılmış bulut yaklaşımlarının, veri yerinde işleme ve air‑gapped senaryolarına dair anlatımları bu desene işaret eder. Kaynak: https://cloud.google.com/distributed-cloud-hosted

Sağlayıcı dokümantasyonlarını doğru okumak: Nasıl doğrulama yapmalı?

AWS, Google ve Microsoft gibi sağlayıcıların dokümanları değerli birincil teknik referanslardır; ancak performans, maliyet veya operasyonel kolaylık anlatımları çoğu zaman ürün perspektifinden sunulur. Bu nedenle şu doğrulama adımlarını önerin:

• İş yükünüzü tanımlayın: Model tipi, parametre boyutu, batch/online çıkarım, eşzamanlılık, veri boyutu.
• Pilot benchmark planı yazın: Aynı metriklerle (latency, throughput, hata oranı, maliyet) ölçün.
• Gözlemlenebilirlik zorunluluğu koyun: Pilot, üretim benzeri log/metric ile koşmalı.
• Çıkış kriteri belirleyin: “Bulut mu on‑prem mi?” kararı için minimum kabul kriterleri.

Bu yaklaşım, kararınızı tek bir dokümantasyon cümlesine değil, sizin koşullarınızda üretilen ölçümlere dayandırmanıza yardımcı olur.

Adım adım uygulama planı: 30-60-90 gün yaklaşımı

İlk 30 gün: Gereksinim ve risk haritalama

• Kullanım senaryosunu ve başarı metriklerini yazılı hale getirin.
• Veri akış diyagramı çıkarın (nerede oluşuyor, nerede işleniyor, kim erişiyor).
• NIST AI RMF’ten yararlanarak riskleri ve kontrol ihtiyaçlarını kayıt altına alın. Kaynak: https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf

60 gün: Pilot ve ölçüm

• Aynı modeli/iş akışını bulut ve on‑prem/yerel seçeneklerden en az ikisinde çalıştırın (mümkünse).
• Latency, throughput, hata oranı, operasyonel efor ve maliyeti ölçün.
• Güvenlik ve erişim kontrollerini “pilot olsa bile” üretime yakınlaştırın.

90 gün: Üretime geçiş tasarımı

• Seçilen mimariye göre MLOps süreçlerini standartlaştırın (sürümleme, onay akışı, geri alma).
• İzleme ve olay müdahalesi prosedürlerini yazın.
• TCO modelini ölçümlere göre güncelleyin ve yönetime karar paketi sunun.

Sonuç: Tek doğru yok, ama doğru karar süreci var

On‑prem, bulut ve hibrit AI mimarileri arasında seçim yaparken tek bir “en iyi” yoktur. Bulut genellikle hız ve esneklik sağlar; on‑prem yaklaşımı veri yerinde işleme ve gecikme hassasiyeti olan senaryolarda öne çıkabilir; hibrit ise birçok kurum için pratik bir denge noktasıdır. En güvenilir yaklaşım, gereksinimleri netleştirip (özellikle uyumluluk ve latency), NIST AI RMF gibi bir risk yönetimi çerçevesiyle kontrolleri belgelemek ve kendi iş yükünüzle ölçüm yapmaktır.

Bu şekilde, mimari kararınız hem teknik hem yönetişim açısından savunulabilir hale gelir; yapay zeka teknolojileri yatırımlarınızın sürdürülebilirliği artar.