Bulut mu Lokal Yapay Zekâ mı? Şirketler İçin Rehber

Bulut ve Lokal Yapay Zekâ Ne Anlama Gelir?

Şirketlerin yapay zekâ projelerinde karşılaştığı temel mimari kararlardan biri, modellerin ve bunları destekleyen altyapının nerede çalıştırılacağıdır. Bir tarafta OpenAI API, Microsoft Azure, Amazon Web Services veya Google Cloud gibi sağlayıcıların sunduğu yönetilen hizmetler bulunurken diğer tarafta şirketin kendi veri merkezinde veya kontrol ettiği özel altyapıda çalışan modeller vardır.

Bu ayrım yalnızca “sunucunun nerede olduğu” sorusundan ibaret değildir. Seçilen mimari; verinin hangi sistemlerden geçtiğini, altyapının kim tarafından yönetildiğini, modellerin ne kadar hızlı ölçeklenebildiğini, hangi modellerin kullanılabileceğini ve şirketin hangi operasyonel sorumlulukları üstleneceğini doğrudan etkiler.

NIST, bulut bilişimi talep üzerine erişilebilen ve hızlı biçimde tahsis edilip serbest bırakılabilen paylaşımlı bilişim kaynakları modeli olarak tanımlar. Bulutun temel özellikleri arasında talep üzerine self servis, geniş ağ erişimi, kaynak havuzlama, hızlı esneklik ve ölçümlenebilir hizmet bulunur [1].

Yapay zekâ açısından üç temel yaklaşım vardır:

Bulut yapay zekâ: Model veya yapay zekâ altyapısı üçüncü taraf bir bulut sağlayıcısının ortamında çalışır. Şirket modele genellikle API veya yönetilen platform üzerinden erişir.

Lokal / on-premise yapay zekâ: Model ve inference altyapısı şirketin kontrol ettiği sunucularda çalışır. Model ağırlıkları, GPU'lar, çalışma ortamı ve çoğu durumda veriler kurumun altyapısında bulunur.

Hibrit yapay zekâ: Bazı modeller veya iş yükleri lokal çalışırken diğerleri buluta yönlendirilir. Hassas veriler şirket içinde tutulurken genel amaçlı veya yüksek hesaplama gerektiren görevler buluttaki modellere gönderilebilir.

Bu nedenle gerçek karar çoğu zaman “bulut mu lokal mi?” yerine hangi iş yükünün nerede çalışması gerektiği sorusudur.

Bulut Yapay Zekâ Nasıl Çalışır?

Bulut yaklaşımında şirket genellikle kendi GPU altyapısını kurmak yerine bir servis sağlayıcının model veya hesaplama altyapısını kullanır.

Basitleştirilmiş bir üretken yapay zekâ uygulaması şu akışa sahip olabilir:

Model şirketin sunucusunda bulunmaz. Uygulama gerekli girdileri sağlayıcıya gönderir ve oluşturulan sonuç geri alınır.

Bulut kullanımının önemli avantajlarından biri altyapının talebe göre genişletilebilmesidir. NIST'in bulut tanımındaki “rapid elasticity” özelliği, kaynakların ihtiyaca göre hızlı biçimde artırılıp azaltılabilmesini ifade eder [1].

Kuruluş böylece ilk günden büyük bir GPU yatırımı yapmak yerine kullandığı kaynak veya hizmet miktarı üzerinden maliyet oluşturabilir.

Ancak “veri buluta gidiyor” ifadesi tek başına güvenlik değerlendirmesi yapmak için yeterli değildir. Sağlayıcının sözleşmesi, kullanılan ürün, veri saklama politikası, seçilen bölge, loglama mekanizmaları ve yapılandırılan güvenlik kontrolleri ayrıca incelenmelidir.

Örneğin OpenAI, API platformuna gönderilen verilerin kullanıcı açıkça paylaşmayı seçmediği sürece modelleri eğitmek veya geliştirmek için kullanılmadığını belirtmektedir. Bununla birlikte API özelliklerine göre farklı veri saklama davranışları bulunmaktadır; varsayılan kötüye kullanım izleme logları belirli durumlarda 30 güne kadar tutulabilir ve uygun müşteriler için ek veri saklama kontrolleri mevcuttur [2].

Benzer şekilde Microsoft, Azure üzerinden sunduğu modellerde müşteri promptlarının ve çıktıların diğer müşterilerle veya model sağlayıcılarıyla paylaşılmadığını ve müşterinin izni olmadan temel üretken yapay zekâ modellerinin eğitiminde kullanılmadığını belirtmektedir [3].

Amazon Bedrock da müşteri girdilerinin ve model çıktılarının üçüncü taraf model sağlayıcılarıyla paylaşılmadığını veya temel modellerin geliştirilmesinde kullanılmadığını belirtmektedir [4]. Google Cloud ise Vertex AI üzerindeki yönetilen modeller için müşterinin önceden izni veya talimatı olmadan verilerin model eğitimi veya fine-tuning amacıyla kullanılmayacağını belirtmektedir [5].

Dolayısıyla sağlayıcı değerlendirmesi “bulut güvenli mi?” gibi genel bir soruyla değil, kullandığımız ürün hangi veriyi hangi koşullarda işliyor ve saklıyor? sorusuyla yapılmalıdır.

Lokal Yapay Zekâ Nasıl Çalışır?

Lokal yapay zekâ mimarisinde şirket modeli kendi kontrolündeki altyapıda çalıştırır.

Örneğin:

Kullanıcı → Kurumsal uygulama → Şirket ağı → Lokal inference sunucusu → Model → Yanıt

Bu yapıda model inference işlemi için verinin harici bir model API'sine gönderilmesi zorunlu değildir.

Lokal kurulumlarda açık ağırlıklı modeller veya kurumun kullanım hakkına sahip olduğu modeller GPU sunucularında çalıştırılabilir. NVIDIA gibi altyapı sağlayıcıları da kurumsal inference platformlarını on-premise dağıtım senaryoları için sunmaktadır [6].

Ancak “lokal = tamamen özel” sonucu otomatik olarak çıkarılmamalıdır. Bir sistem şirket içinde çalışsa bile telemetri servisleri, model indirme mekanizmaları, güncelleme sunucuları, üçüncü taraf kütüphaneleri veya dış API entegrasyonları internet üzerinden iletişim kurabilir.

Bu nedenle gerçek veri akışının mimari seviyede doğrulanması gerekir.

Ayrıca lokal yapay zekâ, altyapı sorumluluğunu sağlayıcıdan şirkete taşır. GPU yönetimi, sürücüler, inference sunucuları, model güncellemeleri, erişim kontrolü, izleme, yedekleme, yüksek erişilebilirlik ve güvenlik yamaları kurumun sorumluluğuna girebilir.

Bulut ve Lokal Yapay Zekâ Karşılaştırması

Bu tablo tek başına seçim yapmak için kullanılmamalıdır. Özellikle maliyet ve güvenlik, kullanım biçimine göre önemli ölçüde değişebilir.

Veri Güvenliği Açısından Hangisi Daha Güvenli?

“Lokal yapay zekâ her zaman buluttan güvenlidir” veya “büyük bulut sağlayıcıları her zaman şirket içi sistemlerden güvenlidir” şeklindeki iki yaklaşım da aşırı genellemedir.

Güvenlik kullanılan mimariye ve kontrollerin kalitesine bağlıdır.

Kötü yapılandırılmış bir lokal sunucu; güncellenmeyen işletim sistemi, zayıf erişim kontrolleri ve yetersiz ağ segmentasyonu nedeniyle ciddi risk oluşturabilir.

Benzer şekilde yanlış yapılandırılmış bir bulut sistemi de gereksiz veri paylaşımı, fazla yetkilendirilmiş hesaplar veya hatalı loglama politikaları nedeniyle risk yaratabilir.

NIST'in üretken yapay zekâ risk yönetimi profili de kuruluşların üretken AI sistemlerini yalnızca model performansı açısından değil, yaşam döngüsü boyunca risk yönetimi perspektifiyle ele almasını öneren bir çerçeve sunmaktadır [7].

Bu nedenle güvenlik değerlendirmesinde en az şu sorular cevaplanmalıdır:

• Modele hangi veriler gönderiliyor?
• Kişisel veri bulunuyor mu?
• Ticari sır veya fikrî mülkiyet içeriyor mu?
• Veriler hangi ülkede veya bölgede işleniyor?
• Prompt ve çıktılar saklanıyor mu?
• Saklanıyorsa ne kadar süre tutuluyor?
• Kimler bu verilere erişebiliyor?
• Veriler model eğitimi amacıyla kullanılabiliyor mu?
• Veriler aktarım sırasında ve depolamada şifreleniyor mu?
• Erişim ve işlem kayıtları denetlenebiliyor mu?
• Verilerin silinmesi mümkün mü?

Bu sorular cevaplanmadan yalnızca “bulut” veya “lokal” etiketine bakarak güvenlik kararı vermek doğru değildir.

KVKK Açısından Bulut ve Lokal Yapay Zekâ

Türkiye'de kişisel veri içeren yapay zekâ uygulamalarında 6698 sayılı Kişisel Verilerin Korunması Kanunu kapsamındaki yükümlülüklerin ayrıca değerlendirilmesi gerekir.

Kişisel Verileri Koruma Kurumu, üretken yapay zekâ sistemlerinin kişisel veri işleme faaliyetleri açısından değerlendirilmesine yönelik rehber yayımlamıştır. Kurum; üretken yapay zekânın geliştirilmesi ve kullanılması sırasında kişisel verilerin korunmasını yaşam döngüsü boyunca ele almaktadır [8].

Buradaki kritik nokta, sistemin bulutta veya lokal çalışmasının tek başına KVKK uyumluluğu sağlamamasıdır.

Lokal sistemde de hukuka aykırı veri işlenebilir. Bulut sisteminde de gerekli hukuki, teknik ve organizasyonel tedbirlerle kontrollü veri işleme gerçekleştirilebilir.

Şirketin gerçek veri akışını çıkarması gerekir:

Veri kaynağı → Uygulama → Ara katman → AI modeli → Log sistemleri → Veri tabanı → Çıktı

Her aşamada hangi kişisel verinin hangi amaçla işlendiği belirlenmelidir.

Özellikle üçüncü taraf AI hizmetleri kullanıldığında veri aktarımı ve sağlayıcının rolü ayrıca değerlendirilmelidir.

Avrupa Birliği AI Act Açısından Altyapı Seçimi

Avrupa Birliği Yapay Zekâ Tüzüğü — Regulation (EU) 2024/1689 — risk temelli bir düzenleyici çerçeve getirmektedir. Düzenlemenin önemli bölümü 2 Ağustos 2026 itibarıyla uygulanmaya başlamış; bazı hükümler daha önce, bazı hükümler ise farklı tarihlerde uygulanacak şekilde kademelendirilmiştir [9].

AI Act açısından yalnızca modelin nerede barındırıldığına bakmak yeterli değildir. Kuruluşun AI sistemindeki rolü, sistemin kullanım amacı ve risk sınıflandırması gibi faktörler önemlidir.

Dolayısıyla “lokal model kullanırsak düzenlemelerden etkilenmeyiz” varsayımı doğru bir karar yaklaşımı değildir.

Şirketler altyapı kararını hukuk, güvenlik ve AI yönetişimi süreçlerinden bağımsız ele almamalıdır.

Maliyet: Bulut mu Daha Ucuz, Lokal mi?

Bu sorunun sabit bir cevabı yoktur.

Bulut sistemlerinde maliyet çoğunlukla kullanım miktarıyla ilişkilidir. API tabanlı modellerde token, istek veya özellik kullanımı; GPU altyapısında ise kullanılan hesaplama kaynağı ve çalışma süresi gibi unsurlar maliyeti belirleyebilir.

Lokal altyapıda ise maliyet yapısı farklıdır.

Başlangıçta şu kalemler oluşabilir:

• GPU veya hızlandırıcı donanımı
• Sunucu
• RAM ve depolama
• Ağ altyapısı
• Güç ve soğutma
• Yedekleme
• Sistem yönetimi
• MLOps / LLMOps
• Güvenlik
• Donanım yenileme

Bu nedenle yalnızca API faturası ile GPU satın alma fiyatını karşılaştırmak yanıltıcıdır.

Toplam sahip olma maliyeti hesaplanmalı

Daha sağlıklı karşılaştırma için Total Cost of Ownership (TCO) yaklaşımı kullanılabilir.

Basitleştirilmiş biçimde:

Lokal TCO = donanım + altyapı + enerji + operasyon + bakım + insan kaynağı + yenileme maliyeti

Bulut tarafında ise:

Bulut TCO = model/API kullanımı + hesaplama + depolama + ağ + gözlemleme + destek + entegrasyon maliyetleri

İş yükü düzensizse bulutun talebe göre ölçeklenebilmesi avantaj sağlayabilir.

Buna karşılık sürekli, yüksek hacimli ve öngörülebilir bir inference yükünde lokal altyapının ekonomik olup olmadığı ayrıca modellenebilir.

Karar gerçek kullanım ölçümleri üzerinden verilmelidir.

Performans ve Gecikme

Lokal yapay zekânın önemli avantajlarından biri ağ gecikmesini azaltabilmesidir.

Örneğin bir üretim hattındaki görüntü işleme sistemi milisaniyeler seviyesinde karar vermek zorundaysa görüntünün internet üzerinden uzak bir veri merkezine gönderilmesi uygun olmayabilir.

Edge veya lokal inference bu tür senaryolarda anlamlıdır.

Ancak büyük bir dil modeli kullanılıyorsa farklı bir durum ortaya çıkar. Şirketin lokal GPU altyapısı yeterli değilse daha küçük veya daha yoğun sıkıştırılmış bir model kullanılması gerekebilir. Bulutta ise daha güçlü modeller veya daha büyük hesaplama kapasitesi erişilebilir olabilir.

Dolayısıyla:

Lokal olmak otomatik olarak daha hızlı model anlamına gelmez.

Gerçek gecikme şu bileşenlerden oluşabilir:

Toplam gecikme = ağ + kuyruk + inference + veri erişimi + uygulama işleme süresi

Karar benchmark ile verilmelidir.

Model Kalitesi ve Model Seçimi

Bulut kullanımının önemli avantajlarından biri gelişmiş kapalı modellerin API üzerinden erişilebilir olmasıdır.

Lokal sistemlerde ise modelin çalıştırılabileceği donanım kapasitesi kritik hale gelir.

Model büyüdükçe GPU belleği ihtiyacı, hesaplama ihtiyacı, enerji tüketimi ve inference süresi gibi faktörler değişir.

Quantization gibi tekniklerle donanım ihtiyacı azaltılabilir; ancak yapılan optimizasyonun kalite ve performans üzerindeki etkisi gerçek görev setiyle test edilmelidir.

Bu nedenle yalnızca benchmark skorlarına bakarak model seçmek yerine şirket kendi değerlendirme veri setini oluşturmalıdır.

Örneğin müşteri destek sistemi kuruluyorsa test seti gerçek kullanım biçimini temsil eden sorulardan oluşmalıdır.

Ölçülebilecek kriterler:

• doğruluk,
• kaynaklara bağlılık,
• halüsinasyon oranı,
• yanıt süresi,
• görev tamamlama oranı,
• güvenlik ihlalleri,
• işlem başına maliyet.

Hibrit Yapay Zekâ Neden Önemli?

Birçok şirket için en mantıklı mimari tamamen bulut veya tamamen lokal olmak zorunda değildir.

Örneğin:

Hassas veri → Lokal model

Genel içerik üretimi → Bulut modeli

Kurumsal doküman araması → Lokal veya özel veri katmanı

Karmaşık muhakeme → Bulut modeli

şeklinde görev bazlı bir mimari kurulabilir.

Bu yaklaşımda bir AI gateway veya orkestrasyon katmanı gelen isteğin hangi modele yönlendirileceğine karar verebilir.

Örneğin sistem önce girdide hassas veri olup olmadığını kontrol eder. Hassas içerik varsa lokal modele yönlendirir; aksi durumda daha güçlü bir bulut modelini kullanabilir.

Ancak hibrit sistemler de ücretsiz bir avantaj sağlamaz. Birden fazla model, sağlayıcı ve altyapının yönetilmesi gözlemlenebilirlik ve operasyon karmaşıklığını artırabilir.

Temsili Kurumsal Senaryo

Aşağıdaki örnek tamamen temsili bir senaryodur; gerçek bir şirket veya proje değildir.

Bir üretim şirketinin üç AI ihtiyacı olduğunu varsayalım:

1. Çalışanların teknik dokümanlarda arama yapması
2. Pazarlama ekibinin içerik üretmesi
3. Üretim hattındaki kamera görüntülerinin analiz edilmesi

Tek bir altyapı seçmek yerine iş yükleri ayrı değerlendirilebilir.

Teknik doküman asistanı

Dokümanlar ticari açıdan hassas bilgiler içeriyorsa kurum, doküman veri tabanını kendi altyapısında tutmayı ve erişim kontrollerini kurum içinde yönetmeyi tercih edebilir.

Modelin lokal veya bulutta çalışması ise ayrı bir karar olabilir.

Pazarlama içerikleri

Hassas şirket verisi içermeyen genel içerik üretimi için yönetilen bulut modelleri kullanılabilir. Böylece GPU altyapısı kurmadan farklı modeller denenebilir.

Üretim hattı görüntü analizi

Sürekli görüntü aktarımının ağ maliyeti veya gecikme oluşturduğu durumda inference üretim tesisindeki edge sunucuda çalıştırılabilir.

Sonuçta aynı şirket üç farklı iş yükü için üç farklı mimari tercih edebilir.

Bu örnek, altyapı kararının şirket seviyesinde değil iş yükü seviyesinde verilmesinin neden önemli olduğunu gösterir.

Bulut Yapay Zekâ Hangi Durumlarda Daha Mantıklı?

Bulut yaklaşımı özellikle şu koşullarda değerlendirilebilir:

• AI projesi henüz pilot aşamasındaysa,
• kullanım miktarı belirsizse,
• hızlı prototipleme gerekiyorsa,
• şirketin GPU altyapısı bulunmuyorsa,
• güçlü modellere hızlı erişim gerekiyorsa,
• iş yükü dönemsel olarak ciddi değişiyorsa,
• altyapı yönetimi için yeterli ekip bulunmuyorsa.

Bulut özellikle bir fikrin teknik ve ticari olarak doğrulanması sırasında yüksek başlangıç yatırımı yapılmasını önleyebilir.

Ancak hassas veriler kullanılıyorsa sağlayıcının veri işleme koşulları mutlaka incelenmelidir.

Lokal Yapay Zekâ Hangi Durumlarda Daha Mantıklı?

Lokal altyapı şu durumlarda güçlü bir aday olabilir:

• Verilerin kurum dışına çıkmaması gerekiyorsa,
• internet bağlantısından bağımsız çalışma gerekiyorsa,
• çok düşük gecikme kritikse,
• mevcut güçlü GPU altyapısı varsa,
• iş yükü sürekli ve öngörülebilir düzeydeyse,
• kullanılan model lokal çalıştırılabiliyorsa,
• şirketin altyapıyı yönetecek teknik kapasitesi varsa.

Buna karşılık yalnızca “veriler bizde kalsın” düşüncesiyle lokal altyapıya geçmek yeterli değildir.

Şirketin güvenlik, MLOps, izleme ve operasyon kapasitesi yoksa sistem sürdürülebilir olmayabilir.

Lokal Yapay Zekânın Görünmeyen Operasyon Yükü

Bir API kullanırken model sağlayıcısı birçok altyapı görevini üstlenir.

Lokal modele geçildiğinde bu görevlerden bazıları şirketin sorumluluğuna dönüşebilir:

• inference servislerinin kurulması,
• GPU sürücülerinin yönetimi,
• model versiyonlama,
• container altyapısı,
• güvenlik yamaları,
• monitoring,
• loglama,
• kapasite planlama,
• yüksek erişilebilirlik,
• model değerlendirme,
• yedekleme ve felaket kurtarma.

Bu nedenle lokal AI projesi yalnızca “modeli indirip GPU'da çalıştırmak” olarak görülmemelidir.

Kurumsal ölçekte amaç çalışan bir demo değil, sürdürülebilir bir üretim sistemi kurmaktır.

Bulut Yapay Zekânın Temel Riskleri

Bulut kullanımında özellikle şu riskler değerlendirilmelidir:

Sağlayıcı bağımlılığı: Uygulama belirli bir modelin API'sine fazla bağımlı hale gelebilir.

Maliyet belirsizliği: Kullanım beklenenden hızlı büyürse tüketim tabanlı maliyetler de artabilir.

Veri yönetişimi: Prompt, çıktı ve logların nerede ve ne kadar süre tutulduğu bilinmelidir.

Servis bağımlılığı: Sağlayıcıdaki kesintiler uygulamayı etkileyebilir.

Model değişiklikleri: Yönetilen modellerin sürümleri veya davranışları zaman içinde değişebilir.

Bu riskler nedeniyle model erişim katmanının uygulamanın geri kalanından ayrılması, gerektiğinde sağlayıcı değişimini kolaylaştırabilir.

Lokal Yapay Zekânın Temel Riskleri

Lokal mimaride ise risk profili farklıdır:

Yüksek başlangıç yatırımı: Kapasite tahmini yanlış yapılırsa donanım atıl kalabilir.

Teknik borç: Model ve inference altyapısının güncellenmesi gerekir.

Kapasite sınırı: Talep ani biçimde arttığında fiziksel donanım sınırına ulaşılabilir.

Uzmanlık ihtiyacı: GPU altyapısı ve model servislerinin işletilmesi standart web uygulaması yönetiminden farklı yetkinlikler gerektirebilir.

Güvenlik sorumluluğu: Sağlayıcının üstlendiği birçok güvenlik operasyonu şirketin sorumluluğuna geçer.

Karar Vermeden Önce Pilot Nasıl Yapılmalı?

Doğrudan geniş ölçekli lokal GPU yatırımı yapmak veya tüm uygulamaları tek bir bulut sağlayıcısına taşımak yerine sınırlı bir pilot daha sağlıklı sonuç verir.

Pilot için önce tek bir iş süreci seçilmelidir.

Ardından aynı görev mümkünse farklı altyapılarda test edilmelidir.

Örneğin:

Bulut Model A

Bulut Model B

Lokal Model C

Aynı değerlendirme veri seti üç modele gönderilebilir.

Sonuçlar şu metriklerle karşılaştırılabilir:

• çıktı kalitesi,
• doğruluk,
• gecikme,
• throughput,
• hata oranı,
• güvenlik gereksinimleri,
• operasyon yükü,
• işlem başına maliyet.

Bu yöntem teorik karşılaştırma yerine gerçek şirket verisine dayalı karar alınmasını sağlar.

Bulut veya Lokal AI Karar Kontrol Listesi

Karar vermeden önce aşağıdaki sorular cevaplanmalıdır:

• İşlenecek veri sınıflandırıldı mı?
• Kişisel veri bulunuyor mu?
• Ticari sır veya fikrî mülkiyet bulunuyor mu?
• Verinin kurum dışına aktarılmasına ilişkin gereksinimler değerlendirildi mi?
• Gerekli model kapasitesi ölçüldü mü?
• Kabul edilebilir maksimum gecikme tanımlandı mı?
• Günlük ve aylık istek hacmi ölçüldü mü?
• Pik kullanım kapasitesi hesaplandı mı?
• Bulut kullanım maliyeti gerçek trafikle test edildi mi?
• Lokal altyapının üç veya daha fazla yıllık TCO'su modellendi mi?
• GPU kullanım oranı tahmin edildi mi?
• Lokal sistemi yönetecek ekip mevcut mu?
• Model güncelleme süreci tanımlandı mı?
• Loglama ve erişim politikaları oluşturuldu mu?
• Sağlayıcının veri saklama politikası incelendi mi?
• Felaket kurtarma senaryosu hazırlandı mı?
• Alternatif sağlayıcı veya model stratejisi var mı?
• Pilot için ölçülebilir başarı kriterleri belirlendi mi?
• Hukuk ve bilgi güvenliği ekipleri mimariyi değerlendirdi mi?

Bu soruların önemli bölümü cevaplanamıyorsa altyapı satın alma kararından önce keşif ve pilot aşamasının tamamlanması daha sağlıklı olacaktır.

Hangi Durumlarda Lokal AI Kurulmamalı?

Lokal altyapı teknik olarak mümkün olsa bile her durumda mantıklı değildir.

Özellikle şirketin gerçek kullanım hacmi bilinmiyorsa büyük GPU yatırımı erken olabilir.

Aynı şekilde:

• proje henüz PoC aşamasındaysa,
• iş değeri doğrulanmamışsa,
• modeli yönetecek ekip yoksa,
• kullanım çok düşükse,
• ihtiyaç duyulan model lokal çalıştırılamıyorsa,
• donanımın büyük bölümü atıl kalacaksa

lokal altyapının gerekçesi yeniden değerlendirilmelidir.

Önce problemi ve kullanım hacmini doğrulamak, ardından altyapıyı optimize etmek genellikle daha ölçülebilir bir yaklaşım sağlar.

Hangi Durumlarda Bulut AI Kullanılmamalı?

Bulut da varsayılan çözüm değildir.

Örneğin dış bağlantının bulunmadığı bir üretim ortamında veya verinin belirli bir sistem sınırının dışına çıkmasının kabul edilemediği bir uygulamada standart bulut API mimarisi uygun olmayabilir.

Benzer şekilde çok yüksek ve sürekli inference hacmi varsa uzun vadeli bulut maliyetinin alternatif altyapılarla karşılaştırılması gerekir.

Bulut kullanımına ilişkin veri işleme koşulları kurumun hukuki veya güvenlik gereksinimlerini karşılamıyorsa farklı bir sağlayıcı, özel bulut, lokal veya hibrit mimari değerlendirilmelidir.

Sonuç

Bulut ve lokal yapay zekâ arasında mutlak bir kazanan yoktur.

Bulut; hızlı başlangıç, ölçeklenebilirlik, yönetilen altyapı ve gelişmiş modellere erişim açısından güçlüdür. Lokal yapay zekâ ise altyapı ve veri akışı üzerinde daha fazla kontrol, çevrimdışı çalışma ve belirli iş yüklerinde düşük gecikme gibi avantajlar sağlayabilir.

Bunun karşılığında lokal mimari daha fazla altyapı ve operasyon sorumluluğu getirirken bulut mimarisi sağlayıcı bağımlılığı, veri yönetişimi ve değişken kullanım maliyetlerinin yönetilmesini gerektirir.

Bu nedenle şirketler kararı teknoloji tercihi olarak değil; veri sınıflandırması, iş yükü, güvenlik, mevzuat, performans ve toplam sahip olma maliyetinin birlikte değerlendirildiği bir mimari kararı olarak ele almalıdır.

Birçok kurumsal senaryoda sonuç tamamen bulut veya tamamen lokal bir altyapı yerine, farklı iş yüklerini uygun ortamlara dağıtan hibrit bir yapı da olabilir.

Sık Sorulan Sorular

Lokal yapay zekâ nedir?

Lokal yapay zekâ, AI modelinin şirketin kontrol ettiği sunucu, veri merkezi veya edge cihaz üzerinde çalıştırılmasıdır. Inference işlemi için verinin üçüncü taraf bir model API'sine gönderilmesi zorunlu değildir.

Bulut yapay zekâ mı daha güvenli, lokal yapay zekâ mı?

Tek başına dağıtım modeli güvenliği belirlemez. Güvenlik; erişim kontrolleri, şifreleme, ağ mimarisi, veri saklama politikaları, güncelleme süreçleri ve operasyon kalitesine bağlıdır.

Lokal LLM çalıştırmak için GPU gerekli mi?

Her model için zorunlu değildir; ancak modern büyük dil modellerinde kullanılabilir performans elde etmek için GPU veya benzeri hızlandırıcılar çoğu kurumsal inference senaryosunda önemlidir. Gereken donanım model büyüklüğüne, quantization seviyesine ve beklenen trafik miktarına bağlıdır.

Şirket verileri ChatGPT veya diğer AI API'lerine gönderilebilir mi?

Bu karar kullanılan ürünün veri işleme koşulları ve şirketin veri sınıflandırmasına göre verilmelidir. Tüketici ürünleri ile kurumsal/API ürünlerinin veri politikaları aynı kabul edilmemelidir. Kişisel veya hassas veri söz konusuysa KVKK ve ilgili diğer yükümlülükler ayrıca değerlendirilmelidir.

Bulut AI mı daha ucuz, lokal AI mı?

Kullanım biçimine bağlıdır. Düşük veya değişken trafikte bulut başlangıç maliyetini azaltabilir. Sürekli ve yüksek hacimli iş yüklerinde lokal altyapının TCO'su ayrıca karşılaştırılmalıdır. Yalnızca GPU fiyatı ile API faturası karşılaştırılmamalıdır.

Hibrit yapay zekâ nedir?

Hibrit AI, farklı iş yüklerinin farklı altyapılarda çalıştırılmasıdır. Örneğin hassas veriler lokal modelde işlenirken genel amaçlı görevler buluttaki bir modele yönlendirilebilir.

Şirket içinde ChatGPT benzeri bir sistem kurulabilir mi?

Evet. Uygun bir dil modeli, inference sunucusu, kullanıcı arayüzü, kimlik doğrulama, veri erişim katmanı ve gerektiğinde RAG altyapısıyla şirket içi bir asistan kurulabilir. Ancak modelin kurulması sistemin yalnızca bir parçasıdır; güvenlik, izleme, değerlendirme ve operasyon süreçleri de gerekir.

Lokal AI kullanmak KVKK sorununu tamamen çözer mi?

Hayır. Lokal çalışma verinin üçüncü taraf modele gönderilmesini önleyebilir ancak kişisel verilerin kurum içinde işlenmesi de KVKK kapsamındaki yükümlülüklere tabi olabilir. Veri işleme amacı, hukuki dayanak ve teknik-organizasyonel tedbirler ayrıca değerlendirilmelidir.

Kaynaklar

[1] National Institute of Standards and Technology (NIST) — The NIST Definition of Cloud Computing, SP 800-145. Eylül 2011; NIST sayfası 7 Mayıs 2026'da güncellenmiştir. Erişim tarihi: 28 Eylül 2026. Bulut bilişimin tanımı, talep üzerine kaynak sağlama ve hızlı ölçeklenebilirlik özellikleri için kullanılmıştır.
https://doi.org/10.6028/NIST.SP.800-145

[2] OpenAI — Data controls in the OpenAI platform. Erişim tarihi: 28 Eylül 2026. OpenAI API verilerinin model eğitiminde kullanımı, varsayılan kötüye kullanım izleme saklama süresi ve Zero Data Retention kontrolleri için kullanılmıştır.
https://developers.openai.com/api/docs/guides/your-data

[3] Microsoft — Data, privacy, and security for Foundry Models sold by Azure in Microsoft Foundry. Erişim tarihi: 28 Eylül 2026. Azure üzerinde işlenen prompt, çıktı ve müşteri verilerinin kullanımı ve veri işleme özellikleri için kullanılmıştır.
https://learn.microsoft.com/en-us/azure/foundry/responsible-ai/openai/data-privacy

[4] Amazon Web Services (AWS) — Amazon Bedrock — Privacy and Security. Erişim tarihi: 28 Eylül 2026. Amazon Bedrock müşteri girdileri ve çıktılarının model sağlayıcılarıyla paylaşılmaması, temel modellerin eğitiminde kullanılmaması ve güvenlik kontrolleri için kullanılmıştır.
https://aws.amazon.com/documentation-overview/bedrock/

[5] Google Cloud — Vertex AI and zero data retention. Erişim tarihi: 28 Eylül 2026. Vertex AI üzerinde müşteri verilerinin izin veya talimat olmadan AI/ML modellerinin eğitiminde veya fine-tuning işleminde kullanılmamasına ilişkin bilgi için kullanılmıştır.
https://docs.cloud.google.com/vertex-ai/generative-ai/docs/vertex-ai-zero-data-retention

[6] NVIDIA — Enterprise AI Infrastructure. Erişim tarihi: 28 Eylül 2026. On-premise kurumsal AI altyapısı ve yüksek performanslı inference sistemlerinin lokal olarak dağıtılabilmesine ilişkin teknik bağlam için kullanılmıştır.
https://www.nvidia.com/en-us/ai/

[7] National Institute of Standards and Technology (NIST) — Autio, C. ve diğerleri, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, NIST AI 600-1. 26 Temmuz 2024; güncelleme 8 Nisan 2026. Erişim tarihi: 28 Eylül 2026. Üretken yapay zekâ sistemlerinin yaşam döngüsü boyunca risk yönetimi yaklaşımı için kullanılmıştır.
https://doi.org/10.6028/NIST.AI.600-1

[8] Kişisel Verileri Koruma Kurumu (KVKK) — Üretken Yapay Zekâ ve Kişisel Verilerin Korunması Rehberi (15 Soruda). Erişim tarihi: 28 Eylül 2026. Üretken yapay zekâ sistemlerinde kişisel veri işleme faaliyetlerinin 6698 sayılı Kanun çerçevesinde değerlendirilmesine ilişkin bölüm için kullanılmıştır.
https://www.kvkk.gov.tr/Icerik/8547/uretken-yapay-zeka-ve-kisisel-verilerin-korunmasi-rehberi-15-soruda

[9] Avrupa Parlamentosu ve Avrupa Birliği Konseyi — Regulation (EU) 2024/1689 — Artificial Intelligence Act. 13 Haziran 2024; yürürlükteki konsolide sürüm 27 Temmuz 2026. Erişim tarihi: 28 Eylül 2026. AI Act'in yürürlük ve kademeli uygulama tarihleri ile düzenleyici çerçeveye ilişkin bilgiler için kullanılmıştır.
https://eur-lex.europa.eu/legal-content/EN/ALL/?uri=OJ:L_202401689