Yerel, bulut veya hibrit?

“Hangi yapay zekâyı kullanmalıyız?” sorusu teknikmiş gibi görünür. Oysa projelerde bu soru her şeyden önce bir mimari sorusudur.

Çünkü bir model hiçbir zaman sadece model değildir. Yerel, bulut veya ikisinin birleşimi lehine verilen her karar aynı zamanda veri yollarını, bağımlılıkları, maliyetleri, gecikmeyi, kullanılabilirliği, kontrol seviyesini, güncelleme risklerini ve ileride sağlayıcı ya da model değiştirmenin ne kadar kolay olacağını belirler.

Yerel bir model hassas verileri kurumun kendi sistemlerinde tutabilir ve yine de kötü güvenlik tasarımına sahip olabilir. Bir bulut modeli verileri haricî altyapıda işleyebilir, fakat kurumsal sözleşmeler, şifreleme, saklama politikaları ve veri yerleşimi seçenekleri sunabilir. Hibrit bir yapı iki dünyanın güçlü yanlarını bir araya getirebilir; ya da iki dünyanın karmaşıklığını aynı anda devralabilir.

Bu nedenle profesyonel soru şu değildir:

Yerel mi, bulut mu?

Asıl soru şudur:

Projemizin hangi bölümleri doğrudan kontrolümüz altında kalmalı, hangi bölümler haricî hesaplama kapasitesinden yararlanabilir ve bu geçişleri kaliteyi, egemenliği ve hareket kabiliyetini koruyacak şekilde nasıl inşa ederiz?

Egemenlik yalnızca modelin bulunduğu yer değildir

Yapay zekâ egemenliği tartışmalarında ilk konu genellikle sunucunun nerede bulunduğudur. Bu anlaşılabilir bir yaklaşımdır, fakat eksiktir.

Bir proje bütün verilerini kendi veri merkezinde tutabilir ve yine de özel bir model formatına, tek bir donanım yığınına veya haricî bir lisans sunucusuna bağımlı olabilir. Tersine, bir bulut servisi proje açısından kritik ham verileri hiç almadan kullanılabilir ve gerektiğinde ikinci bir sağlayıcı devreye girebilir.

Bu nedenle egemenlik en iyi şekilde değişen koşullar altında karar verebilme ve bu kararları uygulayabilme kapasitesi olarak düşünülmelidir.

Egemen bir proje şu sorulara cevap verebilir: Hangi veri nerede bulunuyor? Kim okuyabiliyor? Hangi model örneği veriyi işliyor? Hangi haricî servisler işletim açısından vazgeçilmez? Bir sağlayıcı devre dışı kaldığında bütün proje duruyor mu? Model değiştirildiğinde süreç mantığını baştan kurmak gerekiyor mu? Buluttan yerele veya sağlayıcı A’dan B’ye geçildiğinde kararlar yine izlenebilir ve yeniden değerlendirilebilir mi?

Inference’ın fiziksel konumu önemlidir. Fakat bu daha büyük bir kontrol modelinin yalnızca bir parçasıdır.

Yapay zekâ egemenliğinin üç katmanı

Pratik projelerde üçlü bir ayrım faydalıdır.

Bu katmanlar aynı şey değildir.

Tamamen yerel bir kurulum yüksek veri ve hesaplama egemenliği sağlayabilir, ancak uygulama taşınabilir olmayan tek bir stack’e sıkı biçimde bağlıysa model egemenliği düşük olabilir. Multi-cloud bir sistem sağlayıcı yedekliliğine sahip olabilir, fakat hassas bilgi birden fazla haricî servisten kontrolsüz geçiyorsa veri egemenliği zayıf kalabilir.

Bu nedenle egemenlik “on premise” veya “EU cloud” gibi etiketlerden değil, bağımlılıkların mimarisinden doğar.

Yerel, bulut ve hibrit kalite sınıfları değil, işletim modelleridir

“Yerel”, modelin ve ilgili işlemenin kurumun sahip olduğu veya doğrudan kontrol ettiği altyapıda çalışmasıdır.

“Bulut”, hesaplama kapasitesinin veya yapay zekâ servisinin haricî altyapıdan sağlanmasıdır.

“Hibrit” ise bu bağlamda, bir projenin yapay zekâ işleme yükünü bilinçli olarak farklı kontrol alanlarına dağıtmasıdır. Örneğin gizli işlemler için yerel modeller, çok zor ancak hassas olmayan görevler için bulut modelleri kullanılabilir.

Bu tanım NIST’in klasik “hybrid cloud” tanımından daha geniştir.^[4] Hibrit yapay zekâ mimarisi, bütün bileşenler klasik bulut altyapısı olmasa bile yerel workstation’ları, özel sunucuları, public API’leri ve birden çok model sağlayıcısını birleştirebilir.

Bu seçeneklerin hiçbiri baştan üstün değildir.

Doğru seçim workload’a bağlıdır.

Yerel yapay zekâ gerçekte neyi değiştirir?

Yerel inference’ın temel avantajı veri yolunun önemli ölçüde kısalabilmesidir.

Girdi, retrieval, model ve çıktı tamamen kontrollü ortamda kalıyorsa ham içerik haricî bir yapay zekâ sağlayıcısına gönderilmek zorunda değildir. Ticari sırlar, yayımlanmamış araştırma, şirket içi sözleşmeler, hassas kişisel veriler veya proprietary code için bu belirleyici bir mimari avantaj olabilir.

Yerel çalışmanın başka özellikleri de vardır: internet olmadan da çalışabilme, değişken API maliyetleri yerine donanım, elektrik, işletim ve bakım maliyetleri, model sürümlerini sabitleme ve kontrollü güncelleme, telemetriyi kendiniz tasarlama, dar görev alanları için uzmanlaşmış modeller ve bulut kesintilerinde yerel fallback.

Fakat bunların hiçbiri ücretsiz değildir.

Yerel olmak otomatik olarak güvenli veya compliant olmak değildir

Yaygın hata şudur: “Veri bilgisayarda kalıyor, o hâlde güvenli.”

Bu doğru değildir.

Yerel sistem eski model ağırlıkları, güvensiz Python paketleri, açık portlar, kötü korunan API anahtarları, şifrelenmemiş loglar veya compromise edilmiş extension’lar içerebilir. Laptop çalınabilir. Local vector store gereğinden fazla kullanıcıya açık olabilir. Agent dosya silebilir veya hassas içeriği debug loguna yazabilir.

Kişisel veri işlendiği anda amaçla sınırlılık, veri minimizasyonu, saklama süresinin sınırlandırılması, bütünlük, gizlilik ve hesap verebilirlik gibi ilkeler yerel sistemlerde de geçerlidir.

Doğru cümle şudur:

Yerel işleme dışarı veri aktarımını azaltabilir ve teknik kontrolü artırabilir. Ancak güvenlik mimarisinin veya veri koruma yönetişiminin yerini tutmaz.

Detaylı compliance mantığı bir sonraki makalenin konusu olacaktır. Buradaki mimari sonuç basittir: Yerel, bir kontrol aracıdır; compliance sertifikası değildir.

Bulut yapay zekâ gerçekte ne sağlar?

Bulut yapay zekâ yalnızca büyük modeller nedeniyle cazip değildir.

En önemli özelliği elasticity’dir: Yerel GPU filosu satın almak gerekmez, kapasite hızlı büyütülebilir, frontier modeller ve multimodal API’ler hızlı biçimde erişilebilir olur ve model hosting işletim yükü sağlayıcıya aktarılır.

Projelerde bu şu avantajları yaratabilir: donanım satın almadan peak load karşılamak, prototipe çok hızlı ulaşmak, uzmanlaşmış modellere erişmek, daha az yerel altyapı yönetimi, geniş coğrafi erişim ve çok sayıda kullanıcıya daha kolay ölçeklenmek.

Bulut özellikle capability ve time-to-value, maksimum yerel kontrolden daha önemli olduğunda güçlüdür.

Ancak kurum sadece hesaplama satın almaz. Sağlayıcının işletim bağımlılıklarının bir bölümünü de devralır.

Bulut otomatik olarak „verimizle model eğitiliyor“ anlamına gelmez

Yerel sistemleri abartmak kadar problemli olan başka bir genelleme de her bulut yapay zekâ servisinin şirket verilerini otomatik biçimde eğitimde kullandığını varsaymaktır.

Profesyonel ürünlerin şartları farklı olabilir. OpenAI örneğin Business, Enterprise ve API verilerinin varsayılan olarak model eğitiminde kullanılmadığını; uygun ürünlerde ve konfigürasyonlarda saklama ve veri yerleşimi seçeneklerinin mevcut olduğunu belirtir.^[5]

Bu, bulutun her veri türü için uygun olduğu anlamına gelmez. Fakat mimari kararların sadece “cloud” kelimesini değil, sözleşmesel ve teknik ürün özelliklerini değerlendirmesi gerektiğini gösterir.

Sorulması gerekenler: Müşteri verisi model eğitiminde kullanılıyor mu? Girdiler ve çıktılar ne kadar süre saklanıyor? İşleme ve depolama hangi bölgede gerçekleşiyor? Hangi subprocessor’lar var? Hangi admin ve audit kontrolleri sunuluyor? Retention ve logging azaltılabiliyor mu? Hangi sözleşme ve transfer mekanizmaları geçerli?

Bir sağlayıcının adı tek başına bu soruların hiçbirine cevap değildir.

Hibrit yaklaşım 50/50 uzlaşma değildir

Hibrit, görevlerin yarısının yerelde diğer yarısının bulutta çalışması demek değildir.

İyi bir hibrit mimari işi iş adımının özelliklerine göre route eder.

Örnek:

1. Sözleşmeler yerel ortamda alınır ve sınıflandırılır.

2. İsimler, iç tanımlar ve gizli ekler yerel veri alanında kalır.

3. Yerel model soyutlanmış bir problem temsili oluşturur.

4. Yalnızca bu onaylı soyutlama zor reasoning için bulut modeline gönderilir.

5. Sonuç tekrar yerel alana döner.

6. Nihai birleştirme, karar ve kayıt yerelde yapılır.

Burada bir kez “yerel mi bulut mu” kararı verilmez. Her sınır geçişi ayrı bir karardır.

Hibrit mimarinin gücü tam olarak budur.

Model Routing’den önce Data Routing gelir

Birçok ekip önce model router kurar: kolay görevler model A’ya, zor görevler model B’ye gider.

Egemen projelerde bu geç bir adımdır.

Önce hangi bilginin hangi execution zone’dan çıkabileceği belirlenmelidir.

Basit bir veri sınıflaması bile mimariyi değiştirebilir:

Somut sınıflar kuruma göre uyarlanmalıdır. Önemli olan prensiptir: Router sadece model kalitesini değil, veri serbest bırakma kararını da yönetir.

Egemen yapay zekâ mimarisinin beş plane’i

Yerel-bulut kararı, proje “modelle chat” olarak değil katmanlı sistem olarak düşünüldüğünde daha sağlam olur.

1. Data Plane

Dosyalar, veri tabanları, retrieval index’leri, secrets ve kanonik proje durumu burada bulunur.

Data Plane hangi verinin mevcut olduğunu ve hangi zone sınırlarının geçerli olduğunu belirler.

2. Inference Plane

Yerel ve haricî modeller burada çalışır.

Her model otomatik olarak aynı context’e sahip değildir.

3. Orchestration Plane

Hangi görevin hangi modele gideceğine, hangi fallback’in izinli olduğuna ve ne zaman insan gate’i gerektiğine karar verir.

4. Action Plane

Tool’lar, API’ler, dosya sistemi erişimi, veri tabanı yazma yetkileri ve gerçek yan etkiler burada bulunur.

Bulut modeli reasoning yapabilir fakat iç sistemlere doğrudan yazma yetkisi almak zorunda değildir.

5. Evidence Plane

Run’lar, model kimliği, routing kararı, artefact’lar ve onaylar burada kayıt altına alınır.

Böylece hangi bölümün yerel, hangi bölümün haricî işlendiği görülebilir.

Bu plane’ler teknik olarak aynı uygulamada olabilir. Mimari olarak yine de ayrılmaları gerekir.

Model Router bir Policy Engine’dir

İyi router sadece “hangi model daha ucuz?” diye sormaz.

Aynı anda şu boyutları değerlendirir:

Sensitivity — Task hangi veri sınıfını işler?

Capability — Hangi minimum kalite gerekir?

Latency — Sonuç ne kadar hızlı olmalı?

Cost — Hangi bütçe kabul edilebilir?

Availability — Hangi sağlayıcılar şu anda erişilebilir?

Context — Ne kadar context gerekir?

Tooling — Hangi araç veya modaliteler gerekir?

Action Risk — Model sadece okuyacak mı, öneri mi verecek, yoksa işlem mi yapacak?

Routing kararı örneğin şöyle olabilir:

D2 + read-only + standart analiz → yerel model.

D0 + yüksek reasoning gereksinimi → frontier bulut modeli.

D3 + yüksek reasoning gereksinimi → önce yerel redüksiyon/soyutlama; bulut ancak açık onayla.

Böylece routing görünmez maliyet optimizasyonu olmaktan çıkar ve yönetilebilir mimari karara dönüşür.

Capability Escalation ile Local-first

Sağlam modellerden biri local-first yaklaşımıdır.

Task yerelde başlar. Sistem önce kontrollü zone içinde çözmeye çalışır. Belirlenmiş kalite veya capability eşiği karşılanmazsa escalation gündeme gelir.

Bunun açık bir capability gate’i olmalıdır: local output eval’i geçerse iş yerelde tamamlanır; geçmezse veri serbest bırakma politikası kontrol edilir; veri çıkabiliyorsa cloud escalation yapılır; çıkamıyorsa yerel uzman route, insan review veya stop kalır.

Bu yaklaşım bulut kullanımının sadece rahat olduğu için default olmasını engeller.

Aynı zamanda yerel dogmatizmi de engeller: Yerel model işi güvenilir yapamıyorsa kalite açığı görünür hâle gelir.

Kontrollü geri çekilme ile Cloud-first

Tersi model de mantıklı olabilir.

Public veya düşük hassasiyetli veride proje cloud-first çalışabilir ve yerel sistemi fallback ve exit route olarak tutabilir.

Bu yüksek başlangıç hızı ve güçlü capability sağlar. Ancak temel proje objeleri sağlayıcının dışında tutulmalıdır: kendi kanonik state’iniz, kendi prompt ve policy versiyonlarınız, portable tool schema’ları, kendi artefact’larınız, kendi evaluation set’leriniz ve kendi routing mantığınız.

Bu durumda bulut değiştirilebilir execution ortamıdır; projenin hafızası değildir.

Split Processing: Hassas olan yerelde, soyutlama dışarıda

Tamamen yerel ile tamamen bulut arasında güçlü bir model vardır: Split Processing.

Task parçalara ayrılır.

Yerel sistem örneğin kişisel tanımlayıcıları kaldırabilir, belgeleri sınıflandırabilir, iç ID’leri pseudonymize edebilir, ilgisiz ekleri çıkarabilir, code fragment’larını minimize edebilir veya yapılandırılmış bir özet üretebilir.

Haricî model yalnızca onaylanan alt kümeyi görür.

Ancak bunu kusursuz anonymization ile karıştırmamak gerekir. Özet hâlâ hassas bilgi taşıyabilir; pseudonymization anonymization değildir. Mimari exposure’ı azaltır, otomatik compliance garantisi vermez.

Provider volatility bir proje riskidir

Yapay zekâ projesi metodolojik olarak iyi olabilir ve yine de sağlayıcı yüzünden durabilir.

Nedenler: API outage, rate limit, bölgesel kesinti, model retirement, fiyat değişimi, değişen limitler, farklı güvenlik politikaları, tool capability değişimleri veya yeni model versiyonunun farklı davranması.

Bu nedenle provider volatility sadece risk listesinde değil, mimaride ele alınmalıdır.

Soru “sağlayıcı çöker mi?” değildir.

Asıl soru:

Sağlayıcı çöktükten sonraki ilk dakikada sistemimiz ne yapar?

İkinci API key bir fallback stratejisi değildir

Gerçek fallback yalnızca alternatif endpoint gerektirmez.

En azından şunlar gerekir:

1. Trigger — Ne zaman geçiş yapılacak?

2. Compatibility Contract — Replacement model aynı input ve tool interface’lerini işleyebilir mi?