On-premise yapay zeka nedir? Veri kurum dışına çıkmadan AI kullanımı

Son güncelleme: 17 Ağustos 2026

Yapay zeka projeleri çoğu zaman modelde tıkanmaz. Teknik ekip demoyu çalıştırır, sonuçlar tatmin edicidir, dosya ilerler ve hukuk biriminin masasında tek bir soruyla durur: bu veri nereye gidiyor? Sağlık, finans ve kamu tarafında bu sorunun cevabı yanlışsa bütçe onaylanmış olsa bile imza çıkmaz. İç denetim, savunamayacağı bir süreci onaylamaz. On-premise yapay zeka tam olarak bu tıkanmayı çözmek için vardır: modeli veriye götürürsünüz, veriyi modele değil.

Kısa özet

On-premise yapay zeka, yapay zeka modelinin kurumun kendi sunucusunda, kendi veri merkezinde ve kendi ağı içinde çalıştırılması, verinin işlenmek üzere hiçbir dış sağlayıcıya gönderilmemesidir. Bu yazıda cevaplanan sorular:

  • On-premise ile bulut arasındaki teknik ve yönetimsel fark nedir?
  • Veri kurum dışına çıktığında hukuk, operasyon ve denetim tarafında hangi risk doğar?
  • Konteyner tabanlı bir kurulum pratikte nasıl yapılır, air-gapped ağ ne demektir?
  • Lokal açık kaynak modeller hangi işleri karşılar, hangilerini karşılamaz?
  • Hibrit mimaride sınır nerede çizilir?
  • Donanım, kurulum ve bakım yükü kimin üzerindedir?

On-premise yapay zeka nedir, buluttan farkı nedir?

On-premise, sistemin kurumun kendi sunucusunda, kendi veri merkezinde ve kendi ağı içinde çalışması demektir. Türkçesi yerinde kurulumdur. Karşıtı bulut tabanlı kullanımdır: veriyi bir sağlayıcının sunucusuna gönderir, cevabı geri alırsınız.

Teknik fark şurada somutlaşır. Eğitilmiş bir yapay zeka modeli iki parçadan oluşur: modelin yapısını tanımlayan mimari ve eğitim sırasında öğrenilen sayısal parametreler. Bu parametrelere model ağırlıkları denir ve pratikte bir dosya olarak taşınırlar. Bulut kullanımında bu dosya sağlayıcıda durur, veriniz oraya gider. On-premise kurulumda dosya sizin sunucunuza iner; tıbbi görüntü, sözleşme metni, üretim hattı kaydı veya vatandaş verisi binadan hiç çıkmaz.

İkinci fark yönetimseldir. Bulut sağlayıcıları çoğunlukla sürüm sabitleme (version pinning) imkânı sunar, ancak bir sürümün ne zaman emekliye ayrılacağına ve yerine hangi sürümün geleceğine sağlayıcı karar verir. Emeklilik takvimi geldiğinde çalışan bir üretim akışını yeni bir model sürümüne taşımak zorunda kalırsınız. On-premise kurulumda model sürümü sizin kontrolünüzdedir; hangi sürümün hangi tarihte hangi kararı ürettiği kendi kayıtlarınızda durur.

On-premise, bulut ve hibrit karşılaştırması

Kriter On-premise Bulut / ticari API Hibrit
Veri nerede işlenir Kurumun kendi sunucusunda Sağlayıcının sunucusunda Veri sınıfına göre ayrılır
Model sürümü kimin kontrolünde Kurumda Sağlayıcıda Kritik iş yükü kurumda
Gecikme Ağ içi, milisaniye seviyesi İnternet gidiş-dönüş süresi eklenir İş yüküne göre değişir
Maliyet yapısı Önden donanım yatırımı Kullanım başına fatura Karma
İnternete kapalı çalışma Mümkün (air-gapped) Mümkün değil Kritik bileşen çalışmaya devam eder
Tipik kullanım alanı Sağlık, savunma, kamu, finans Hassas olmayan genel içerik Karma veri profiline sahip kurumlar

Veri kurum dışına çıktığında hangi risk doğar?

Kısa cevap: Risk tek yerde değil, üç ayrı masada birikir. Hukuk, operasyon ve denetim.

Hukuk tarafında 6698 sayılı Kişisel Verilerin Korunması Kanunu (KVKK) belirleyicidir. Kanunun 6. maddesi sağlık verisini özel nitelikli kişisel veri olarak tanımlar ve işlenmesini ayrı şartlara bağlar; 9. madde ise kişisel verilerin yurt dışına aktarımını kendi koşullarına bağlar. Bir hastane veya banka için sürece yeni bir "veri işleyen üçüncü taraf" eklemek, tek başına aylar sürebilen bir uyum ve sözleşme çalışması demektir.

Operasyon tarafında bağımlılık vardır. İnternet bağlantısı koptuğunda, sağlayıcı fiyatlandırmasını değiştirdiğinde veya kullandığınız model emekliye ayrıldığında süreciniz durur. Görüntü işleme gibi saniyede onlarca karenin işlenmesi gereken işlerde dış servise gidip gelme gecikmesi zaten kabul edilebilir değildir: 50 FPS hedefi kare başına 20 milisaniyelik, 150 FPS hedefi ise yaklaşık 6,7 milisaniyelik bir bütçe bırakır. İnternet üzerinden tek bir gidiş-dönüş bile bu bütçeyi tek başına tüketir.

Denetim tarafında ispat sorunu vardır. Yönetim kuruluna veya denetçiye "bu kararı neye dayanarak verdiniz" sorusunun cevabını vermeniz gerekir. Kararın hangi girdiyle, hangi model sürümüyle ve hangi tarihte üretildiğini gösteremiyorsanız sistem üretime giremez. Yapay zeka yönetim sistemi standardı olan ISO/IEC 42001 de bu izlenebilirliği talep eder; on-premise kurulum, kayıtların kurumun kendi sınırları içinde tutulmasını doğal olarak kolaylaştırır.

On-premise bir yapay zeka sistemi teknik olarak nasıl kurulur?

Kurulumun bugünkü standart yolu konteyner tabanlı dağıtımdır. Konteyner, bir uygulamanın çalışması için gereken kodu, kütüphaneleri, çalışma zamanını ve ayarları tek bir paket haline getiren yalıtılmış çalışma ortamıdır. Sanal makineden farkı, kendi işletim sistemini taşımaması, çekirdeği sunucuyla paylaşmasıdır; bu yüzden daha hafiftir ve daha hızlı başlar. En yaygın aracı Docker'dır.

Aynı paket test ortamında ve üretim sunucunuzda aynı davranışı gösterir. Tek koşul şudur: GPU sürücüsü ve CUDA gibi donanıma bağlı katmanlar konteynerin dışında, sunucu tarafında kalır; bu katmanların sürümlerinin de eşleşmesi gerekir. Kurulum planında bu satır atlanırsa "bende çalışıyordu" sorunu üretimde geri döner.

Kurulum sırasında baştan konuşulması gereken beş başlık

  1. Sunucu: Sistem hangi fiziksel veya sanal sunucuda çalışacak, bu sunucu hangi ağ segmentinde duracak?
  2. GPU ve bellek: Hangi GPU (grafik işlem birimi) gerekli ve ne kadar VRAM istiyor? Model boyutu, eşzamanlı kullanıcı sayısı ve gerçek zamanlılık hedefi bu kararı birlikte belirler.
  3. Ağ modeli: Sistem internete tamamen kapalı bir ağda mı, yoksa kontrollü bir bağlantıyla mı duracak? İnternete tamamen kapalı, fiziksel olarak dış ağlardan yalıtılmış kurulum için kullanılan terim air-gapped ağdır; savunma ve kamu tarafında sıkça istenir.
  4. Model sürüm yönetimi: Hangi model sürümünün ne zaman yürürlükte olduğu nasıl kayıt altına alınacak, geri dönüş (rollback) nasıl yapılacak?
  5. Güncelleme kanalı: Air-gapped kurulumda model ve imaj güncellemeleri hangi kontrollü yolla içeri alınacak?

Bizim çalışma biçimimiz de bu yöndedir. AI Yapay Zeka Mühendislik olarak dağıtımı Docker konteynerleri üzerinden yapıyoruz; kurulumlarımız ağırlıklı olarak on-premise, bulut ise opsiyonel. Model tarafında PyTorch, TensorFlow, OpenCV ve YOLO gibi araçların yanında projeye özel eğitilmiş modeller kullanıyoruz. Servis katmanını Python ve FastAPI ile yazıyoruz; mobil ve arayüz tarafında Dart/Flutter, ek servislerde Node.js kullanıyoruz. Kendi geliştirdiğimiz yapay zeka framework'ü bu katmanların üzerinde çalışır. Hizmetlerimizin tamamını inceleyebilirsiniz.

Lokal açık kaynak modeller işi gerçekten görür mü?

Kısa cevap: Kurum içi kullanım senaryolarının büyük bölümünde evet. Birkaç yıl önce tartışmalı olan bu soru, açık kaynak modellerin olgunlaşmasıyla büyük ölçüde kapandı.

Büyük dil modelleri (LLM, large language model: çok büyük metin verisiyle eğitilmiş, metni anlayıp üretebilen yapay zeka modelleri) tarafında açık kaynak seçenekler, kurum içi işlerin önemli bölümünü karşılayacak seviyeye geldi. Belge özetleme, kurum içi soru cevaplama, form doldurma, sınıflandırma ve raporlama gibi işlerde lokal model yeterlidir.

Görüntü işleme tarafında durum daha da nettir. Nesne tespiti, takip ve görüntü tabanlı karar destek modelleri zaten kurum içinde eğitilecek ve çalıştırılacak şekilde tasarlanır. Görüntü işleme projelerimizde %80 üzeri stabilite, sağlık alanındaki projelerimizde %85 üzeri doğruluk ile çalışıyoruz. İnsan performansıyla karşılaştırdığımız bir iş akışında %80 olan başarı oranı yapay zeka desteğiyle %90'a çıktı.

Savunma sanayii bağlantılı bir müşteri için geliştirdiğimiz sistemde, insansız hava aracı görüntüsünde sınıftan bağımsız uçan cisim tespiti ve takibi yapılıyor; gerçek zamanlı hedefimiz 50-150 FPS, yani saniyede işlenen kare sayısı. Bu tür bir işi dış servise göndererek yapmanın yolu yoktur; hesap yukarıdaki milisaniye bütçesinde zaten tutmaz.

Hibrit mimari ne zaman mantıklı, sınır nerede çizilir?

Kısa cevap: Her iş yüzde yüz lokal olmak zorunda değildir. Sınırı verinin niteliği çizer, maliyeti değil.

Biz lokal açık kaynak modelleri ticari API entegrasyonlarıyla birlikte kullanabilen hibrit bir mimariyle çalışıyoruz. API (application programming interface), iki yazılımın birbiriyle veri alışverişi yaptığı servis arayüzüdür; ticari bir API kullandığınızda isteğiniz o servisin sunucusuna gider.

Ayrım şöyle kurulur:

  • Lokal modelde kalması gerekenler: Kişisel veri, özel nitelikli sağlık verisi, ticari sır, görev kritik operasyon verisi, hukuki delil niteliği taşıyan kayıtlar.
  • Ticari API'ye çıkabilecekler: Kurum dışına çıkmasında sakınca olmayan genel içerikler, kamuya açık kaynaklardan üretilen metinler, anonim veya sentetik veriyle yapılan denemeler.

Önemli olan bu sınırın toplantıda sözle değil, mimaride ve dokümanda yazılı olmasıdır. Hangi veri tipinin hangi katmanda işlendiği baştan tanımlanmazsa, "veri dışarı çıkmıyor" cümlesi ilk teknik incelemede geri teper.

On-premise kurulumun donanım ve bakım yükü kimde?

Kısa cevap: Bu, ilk toplantıda sorulması gereken sorudur ve cevabı bir web sayfasında değil sözleşmede olmalıdır. Pratikte üç kalem vardır.

  • Donanım: Sunucu ve GPU yatırımı genellikle kuruma aittir. Buna karşılık kullanım başına ödenen dış servis faturası ortadan kalkar; hacim büyüdükçe lokal kurulumun toplam maliyeti daha öngörülebilir hale gelir.
  • Kurulum ve entegrasyon: Mevcut sistemlerle bağlantı kurma işi tedarikçidedir. Hastane bilgi yönetim sistemi, ERP, görüntü arşiv sistemi, kamera altyapısı veya kurum içi kimlik doğrulama gibi bileşenlerle entegrasyon kapsamı, kabul kriterleri ve test ortamı sözleşmede tek tek yazılmalıdır. Kapsamı yazılmayan entegrasyon, projenin en pahalı kalemi olur.
  • Bakım ve model yaşam döngüsü: Model güncellemesi, yeniden eğitim, sürüm geçişi ve izleme kimin sorumluluğunda? Bu kalem genellikle yıllık destek anlaşmasıyla tanımlanır. Air-gapped kurulumlarda güncellemenin hangi kontrollü kanalla içeri alınacağı da bu başlığa yazılır.

Üç kalemin de sorumlusu isim isim belliyse proje savunulabilir. Belli değilse, sistem üretime alındıktan altı ay sonra kimin bakacağı sorusu kurumun içinde kalır.

Sıkça sorulan sorular

On-premise yapay zeka nedir?

On-premise yapay zeka, yapay zeka modelinin kurumun kendi sunucusunda, kendi veri merkezinde ve kendi ağı içinde çalıştırılmasıdır. Veri işlenmek üzere hiçbir dış sağlayıcıya gönderilmez; model dosyası kuruma iner, veri kurumdan çıkmaz.

On-premise ile bulut tabanlı yapay zeka arasındaki fark nedir?

Bulut kullanımında veri sağlayıcının sunucusuna gider ve model sürümünü sağlayıcı yönetir. On-premise kurulumda veri kurumun ağı içinde kalır, model sürümü kurumun kontrolündedir ve hangi sürümün hangi tarihte çalıştığı kurumun kendi kayıtlarında durur. Gecikme tarafında da fark vardır: on-premise kurulumda internet gidiş-dönüş süresi devreye girmez.

KVKK yapay zeka projelerinde on-premise kurulumu zorunlu kılıyor mu?

KVKK doğrudan on-premise kurulum şartı getirmez. Ancak 6698 sayılı Kanun'un 6. maddesi sağlık verisini özel nitelikli kişisel veri sayarak işlenmesini ayrı şartlara bağlar, 9. maddesi ise kişisel verilerin yurt dışına aktarımını kendi koşullarına bağlar. Bu nedenle veriyi kurum içinde tutmak, uyum yükünü ve süreye yayılan sözleşme çalışmasını pratikte azaltan yoldur.

Lokal açık kaynak LLM modelleri kurumsal işleri karşılar mı?

Belge özetleme, kurum içi soru cevaplama, form doldurma, sınıflandırma ve raporlama gibi kurum içi senaryolarda lokal açık kaynak büyük dil modelleri yeterlidir. Görüntü işleme tarafında ise nesne tespiti, takip ve karar destek modelleri zaten kurum içinde eğitilip çalıştırılacak şekilde tasarlanır.

On-premise yapay zeka internete kapalı (air-gapped) bir ağda çalışır mı?

Evet. Air-gapped ağ, fiziksel olarak dış ağlardan yalıtılmış, internete hiç bağlanmayan ağ demektir. Konteyner tabanlı bir kurulum bu ortamda çalışabilir; koşul, model ve imaj güncellemelerinin hangi kontrollü kanalla içeri alınacağının baştan tanımlanmış olmasıdır. Savunma ve kamu projelerinde sıkça istenen bir yapılandırmadır.

On-premise yapay zeka için hangi donanım gerekir?

Temel gereksinim GPU'lu bir sunucudur. Kesin yapılandırma tek bir formülle verilemez; model boyutu, eşzamanlı kullanıcı sayısı ve gerçek zamanlılık hedefi birlikte belirler. Saniyede 50-150 kare işlenmesi gereken bir görüntü işleme sistemiyle, günde birkaç yüz belge özetleyen bir sistemin donanım ihtiyacı aynı değildir.

Hangi sektörler on-premise yapay zekaya ihtiyaç duyar?

Veri hassasiyeti yüksek ve denetime tabi sektörler: sağlık, finans ve bankacılık, kamu, savunma sanayii, üretim ve lojistik. Ortak nokta, verinin kurum dışına çıkmasının hukuki, operasyonel veya denetimsel olarak savunulamaz olmasıdır.

Kurumunuzda hangi katmanın lokal kalması gerektiğini konuşalım

On-premise mi, hibrit mi sorusunun cevabı kurumun veri profiline göre değişir. Mevcut sistemlerinizi, veri sınıflarınızı ve gerçek zamanlılık hedeflerinizi konuşarak hangi iş yükünün lokal kalması gerektiğini birlikte çıkarabiliriz.

AI Yapay Zeka Mühendislik A.Ş.
Telefon: 0540 509 19 05
E-posta: gokhan@aiyapayzeka.io
Adres: Şehit Muhtar Mah., Mis Sk. No:24, 34435 Beyoğlu/İstanbul
Çalışma saatleri: Her gün 09.00-19.00

Yazar hakkında

Bu yazı AI Yapay Zeka Mühendislik Anonim Şirketi tarafından hazırlanmıştır. Kurucu Dr. Gökhan Tahıl, bilgisayar mühendisliği kökenlidir ve doktorasını Fransa'da yapay zeka alanında yapmıştır. Şirketin ISO 42001 belgesi bulunmakta olup ISO 42001 danışmanlığı da vermektedir. Dr. Gökhan Tahıl, CNN Türk'ün Özel Sektör programına "Bugünün teknolojisiyle yarına yatırım" başlığıyla konuk olmuş; Galatasaray Üniversitesi'nde düzenlenen ilk Fransız-Türk yapay zeka günleri GSU AI Days 2026'da konuşmacı ve jüri üyesi olarak yer almıştır.

Ücretsiz danışmanlık için bize ulaşın

← Tüm yazılar