Sovereign Cloud ve Veri Egemenliği: Regüle Sektörler İçin AI Mimarisi

Sovereign cloud nedir? Sovereign cloud (egemen bulut), verinin ve iş yüklerinin belirli bir ülkenin hukukuna ve yargı yetkisine tabi kalacak şekilde, o ülke sınırları içinde ve yabancı erişimden yalıtılmış biçimde barındırıldığı bir bulut modelidir. Amacı, bulutun esneklik ve ölçek avantajını korurken veri egemenliği (data sovereignty) ile veri ikametgahını (data residency) güvence altına almak ve böylece regüle sektörlerin — bankacılık, sağlık, kamu — yapay zeka mimarilerini uyum içinde kurmalarını sağlamaktır.

Üretken yapay zeka, kurumların en hassas verilerini modellere taşımayı gerektirdikçe, "bu veri hangi ülkenin sınırında, kimin kontrolünde ve hangi hukuka tabi işleniyor?" sorusu stratejik gündemin en üstüne çıktı. Bu rehber, sovereign cloud ve veri egemenliği konusunu bir danışman titizliğiyle ele alıyor: sovereign cloud nedir; veri egemenliği ile veri ikametgahı nasıl ayrışır; neden regüle sektörler için kritiktir; sovereign cloud ile public cloud ve on-premises arasındaki fark; KVKK ve yurt dışına veri aktarımı; hibrit mimariler; LLM için sovereign yaklaşımlar; maliyet ve pratik zorluklar; bir karar çerçevesi; Türkiye'deki seçenekler ve yaygın hatalar. Not: Bu içerik bilgilendirme amaçlıdır ve hukuki tavsiye değildir.

Tanım

Sovereign Cloud (Egemen Bulut)

Verinin ve iş yüklerinin belirli bir ülkenin hukukuna ve yargı yetkisine tabi kalacak şekilde, o ülke sınırları içinde ve yabancı erişimden yalıtılmış biçimde barındırıldığı bulut modeli. Sovereign cloud; veri egemenliği, veri ikametgahı ve operasyonel/teknik egemenliği bir arada güvence altına alarak regüle sektörlerin (bankacılık/BDDK, sağlık, kamu) KVKK ve yurt dışına veri aktarımı yükümlülüklerini karşılamasına imkân tanır. On-premises'in kontrolü ile public cloud'un esnekliği arasında düzenlemeye duyarlı bir denge sunar; yapay zeka ve LLM iş yüklerinde prompt'ların ve kurumsal verinin ülke sınırları içinde kalmasını mümkün kılar.

Ayrıca: egemen bulut, sovereign cloud, ulusal bulut, veri egemenliği bulutu, egemenlik odaklı bulut

Sovereign cloud nedir sorusunun en kısa cevabı şudur: verinizi ve yapay zeka iş yüklerinizi, bir ülkenin sınırları içinde, yabancı yargıdan yalıtılmış ve denetlenebilir biçimde tutan bulut modeli. "Sovereign" (egemen) kelimesi burada anahtardır; sıradan bir buluttan farkı, yalnızca verinin nerede durduğunu değil, kimin erişebileceğini, hangi hukuka tabi olduğunu ve operasyonun kimin tarafından yürütüldüğünü de kontrol altına almasıdır.

Bir benzetme yardımcı olur. Sıradan bir public cloud, bavulunuzu güvenilir ama uluslararası bir kargo şirketine teslim etmeye benzer: paket hızlı ve verimli taşınır, ama hangi ülkeden geçtiğini, kimin elinden geçtiğini ve hangi ülkenin gümrük kurallarına tabi olduğunu tam olarak kontrol edemezsiniz. Sovereign cloud ise paketi ülke sınırları içinde, yalnızca yerel ve yetkili ellerden geçen, her adımı kayıt altına alınan bir taşımaya benzer. Taşıma kalitesi benzer olabilir; değişen, üzerindeki egemenlik ve denetimdir.

Bu ayrım kritik bir sonuç doğurur: sovereign cloud, bir "teknoloji ürünü" değil, bir "güvenceler bütünü"dür. Bir sağlayıcının hizmetine "egemen" etiketi yapıştırması onu gerçekten egemen yapmaz; egemenlik, verinin fiziksel konumundan şifreleme anahtarlarının kimde olduğuna, destek personelinin nerede bulunduğundan işletmecinin hangi ülke hukukuna tabi olduğuna kadar bir dizi somut güvencenin toplamıdır. Bu yüzden sovereign cloud'u anlamak için önce onun kalbindeki iki kavramı — veri egemenliği ve veri ikametgahı — ayırmak gerekir. Bulutun genel mantığını yapay zeka nedir ve dil modellerinin temelini LLM nedir rehberlerinde ele alıyoruz; bu yazı ise bu modellerin nerede ve hangi egemenlik altında çalıştığına odaklanır.

Sovereign cloud tartışmasının kalbinde iki kavram vardır ve bunlar sık sık karıştırılır: veri egemenliği ve veri ikametgahı. Aralarındaki farkı anlamadan verilen hiçbir sovereign cloud kararı sağlam değildir; çünkü çoğu hata, tam olarak bu iki kavramı birbirine karıştırmaktan doğar.

Veri İkametgahı (Data Residency)

Veri ikametgahı, verinin fiziksel olarak hangi coğrafyada tutulduğu ve işlendiğidir. Dar ve teknik bir kavramdır: "verim hangi veri merkezinde, hangi ülkede duruyor?" sorusuna cevap verir. Bir kurum, verisinin Türkiye'deki bir veri merkezinde tutulmasını istediğinde bir veri ikametgahı gereksinimi tanımlamış olur. Bu, birçok senaryoda önemli bir ilk adımdır; ama tek başına yeterli değildir, çünkü verinin nerede durduğu, kimin ona erişebileceği ve hangi hukuka tabi olduğu sorusunu tam olarak yanıtlamaz.

Veri Egemenliği (Data Sovereignty)

Veri egemenliği, verinin hangi ülkenin hukukuna ve yargı yetkisine tabi olduğu ilkesidir. Daha geniş, hukuki ve stratejik bir kavramdır. Bir veri fiziksel olarak nerede tutuluyorsa çoğu zaman o ülkenin hukukuna tabi olur; ama işi karmaşıklaştıran şudur: veriyi işleyen şirketin tabi olduğu yasalar da devreye girebilir. Örneğin bir veri Türkiye'deki bir veri merkezinde dursa bile, o veri merkezini işleten şirket yabancı bir ülkenin hukukuna tabiyse, o ülkenin yasaları — örneğin sınır ötesi devlet erişim talepleri — teorik olarak veri üzerinde söz sahibi olabilir. İşte bu yüzden veri ikametgahı (fiziksel konum) tek başına veri egemenliğini (hukuki kontrol) garanti etmez.

Üçüncü Katman: Operasyonel ve Teknik Egemenlik

Olgun bir sovereign cloud tanımı üç katman içerir. Birincisi veri egemenliği: verinin hangi hukuka tabi olduğu. İkincisi operasyonel egemenlik: sistemi kimin işlettiği, bakım ve desteğin kimin elinden geçtiği, personelin nerede bulunduğu. Üçüncüsü teknik egemenlik: şifreleme anahtarlarının kimde olduğu, verinin sağlayıcı tarafından bile okunamayacak biçimde korunup korunmadığı. Bu üç katman birlikte sağlandığında gerçek egemenlikten söz edilebilir; yalnızca biri (örneğin sadece veri ikametgahı) sağlandığında ise egemenlik kısmi kalır. Bu katmanları ayırmak, ilerideki karar çerçevesinin de temelini oluşturur.

Veri ikametgahı ile veri egemenliği arasındaki fark

Boyut	Veri ikametgahı (residency)	Veri egemenliği (sovereignty)
Temel soru	Veri nerede duruyor?	Veri hangi hukuka tabi?
Kapsam	Dar, teknik/coğrafi	Geniş, hukuki/stratejik
Yabancı erişim riski	Tek başına çözmez	Yalıtımı hedefler
Anahtar/operasyon	Kapsam dışı	Kapsam içinde
Sovereign cloud'daki rolü	Gerekli ama yetersiz	Asıl hedef

Sovereign cloud kavramı herkes için aynı ağırlığı taşımaz; asıl kritik olduğu yer regüle sektörlerdir. Regüle sektörler — bankacılık, sağlık, kamu, sigortacılık, telekom — hem en hassas verileri işler hem de en sıkı düzenlemelere tabidir. Bu iki koşul bir araya geldiğinde, verinin nerede ve hangi egemenlik altında işlendiği artık bir tercih değil, bir yükümlülük haline gelir.

Düzenleyici Yük ve Veri Hassasiyetinin Kesişimi

Bir kurumun sovereign cloud'a ne kadar ihtiyaç duyduğu, iki eksenin kesişiminde belirlenir: verinin hassasiyeti ve sektörün düzenleyici yükü. Genel, kamuya açık veri işleyen düşük düzenlemeli bir kurum için public cloud çoğu zaman yeterlidir. Ama kişisel, finansal veya sağlık verisi işleyen yüksek düzenlemeli bir kurum için, verinin sınır dışına çıkması hem hukuki hem itibari bir risktir. İşte regüle sektörler bu ikinci kategoridedir; bu yüzden sovereign cloud onlar için bir "iyi olur" değil, çoğu zaman bir "olmazsa olmaz"dır.

Neden Sadece Uyum Değil, Güven

Regüle sektörlerde sovereign cloud'un değeri yalnızca yasal uyumla sınırlı değildir; müşteri ve vatandaş güvenini de kapsar. Bir bankanın müşteri finansal verisinin, bir hastanenin hasta kayıtlarının veya bir kamu kurumunun vatandaş verisinin yabancı bir sağlayıcının küresel altyapısında işlenmesi, bir veri sızıntısı yaşanmasa bile bir güven sorunu yaratır. Sovereign cloud, "verinizi ülke sınırları içinde ve kontrolde tutuyoruz" diyebilmeyi sağlayarak bu güveni korur. Bu, özellikle düzenleyici denetimlerin ve kamuoyu duyarlılığının yüksek olduğu sektörlerde stratejik bir varlıktır.

Regüle sektörlerin her birinin kendine özgü çerçevesi vardır; bankacılıkta BDDK, sağlıkta özel nitelikli veri kuralları, kamuda ulusal güvenlik gereksinimleri. Bu sektörel derinleşmeyi ilerideki bölümde ayrıntılı ele alacağız; ama önce sovereign cloud'un diğer iki dağıtım modelinden — public cloud ve on-premises — nasıl ayrıştığını netleştirmek gerekir. KVKK'nın genel çerçevesini KVKK nedir ve kişisel verinin tanımını kişisel veri nedir rehberlerinde bulabilirsiniz.

Sovereign cloud'u doğru konumlandırmak için onu diğer iki modelin yanına koymak gerekir: public cloud ve on-premises. Bu üçü, bir kontrol-esneklik yelpazesinin farklı noktalarında durur ve her biri farklı bir egemenlik-maliyet dengesi sunar.

Public Cloud: Maksimum Esneklik, Sözleşmeye Bağlı Egemenlik

Public cloud, veriyi ve iş yüklerini bir sağlayıcının küresel ve paylaşımlı altyapısında çalıştırır. En büyük avantajı hız, ölçek ve düşük giriş maliyetidir: dakikalar içinde en güçlü modellere erişir, kullandıkça ödersiniz. Ancak veri egemenliği ve yurt dışına veri aktarımı büyük ölçüde sağlayıcının veri merkezi konumuna ve sözleşmeye bağlıdır. Public cloud, hassas olmayan iş yükleri ve dalgalı talep için mükemmeldir; ama yüksek hassasiyetli, düzenlemeye tabi veri için egemenlik boşluğu bırakabilir.

On-Premises: Maksimum Kontrol, Maksimum Yük

On-premises (yerinde), veriyi ve modelleri kurumun kendi kontrolündeki altyapıda çalıştırır. Egemenlik en yüksek seviyededir çünkü veri kurumun fiziksel ve mantıksal sınırlarından hiç çıkmaz; ama maliyet, uzmanlık ve operasyon yükü de tümüyle kurumundur. On-premises ile sovereign cloud arasındaki ayrım incedir: on-premises kurumun kendi altyapısıyken, sovereign cloud çoğu zaman bir üçüncü tarafın yurt içi ve yalıtılmış altyapısını kullanır. On-premises yapay zeka ile bulut arasındaki kararı derinlemesine on-premises yapay zeka vs bulut KVKK rehberimizde ele alıyoruz.

Sovereign Cloud: Düzenlemeye Duyarlı Denge

Sovereign cloud, bu ikisinin arasında konumlanır. On-premises'in egemenlik ve kontrol avantajına yaklaşırken, bulutun operasyonel kolaylığının bir kısmını korur: kurum kendi veri merkezini kurmak zorunda kalmadan, veriyi ülke sınırları içinde ve yabancı erişimden yalıtılmış tutabilir. Bu, özellikle on-premises kurmaya kaynağı veya uzmanlığı yetmeyen ama public cloud'un egemenlik boşluğunu da kabul edemeyen regüle kurumlar için bir orta yol sunar. Sovereign cloud'un cazibesi tam da buradadır: egemenlik ile esneklik arasında, düzenlemeye duyarlı bir denge.

Sovereign cloud, public cloud ve on-premises karşılaştırması

Boyut	Public cloud	Sovereign cloud	On-premises
Veri egemenliği	Sözleşmeye bağlı, düşük	Yüksek, tasarım gereği	En yüksek
Veri ikametgahı	Çoğu zaman yurt dışı	Yurt içi taahhüt	Kurum içi
Esneklik / ölçek	En yüksek	Orta-yüksek	Sabit kapasite
Maliyet modeli	OPEX, en düşük birim	OPEX, orta-yüksek	CAPEX ağırlıklı
Operasyon yükü	Sağlayıcıda	Büyük ölçüde sağlayıcıda	Tümüyle kurumda
En uygun	Hassas olmayan, dalgalı	Regüle, yurt içi zorunlu	En kritik, tam kontrol

Bu tablo, kararın "hangisi en iyi?" değil, "hangi veri hangi modele uygun?" sorusu olduğunu gösterir. Çoğu kurum tek bir modele değil, verisini hassasiyetine göre bu üç modele dağıtan bir mimariye ulaşır; bunu hibrit mimariler bölümünde ele alacağız.

Sovereign cloud kararının en somut hukuki gerekçesi, KVKK ve yurt dışına veri aktarımı çerçevesinde ortaya çıkar. Türkiye'de faaliyet gösteren bir kurum için bu, sovereign cloud'u soyut bir "iyi fikir" olmaktan çıkarıp somut bir uyum aracına dönüştürür.

Yurt Dışına Veri Aktarımının Doğurduğu Yük

KVKK, kişisel verinin yurt dışına aktarılmasını serbest bırakmaz; belirli güvencelere ve koşullara bağlar. Bir public cloud yapay zeka servisi veriyi yurt dışındaki veri merkezlerinde işliyorsa, bu bir yurt dışına veri aktarımıdır ve uyum yükümlülüğü doğurur: uygun bir aktarım mekanizması, açık rıza veya taahhüt temelleri gerekir. Bu yükümlülükleri karşılamak hem hukuki hem idari bir çaba gerektirir; ve bu çaba, her yeni sağlayıcı, her yeni alt işleyen ve her yeni veri kategorisiyle katlanır.

Sovereign cloud, bu yükü büyük ölçüde ortadan kaldırır. Veri ülke sınırları içinde kaldığı için bir yurt dışına veri aktarımı gerçekleşmez; dolayısıyla aktarıma özgü hukuki mekanizmaları kurma ve sürdürme yükü doğmaz. Yüksek hacimde ve sürekli kişisel veri işleyen kurumlar için bu, önemli bir sadeleşme ve risk azaltımıdır. Kişisel veriyi anonimleştirerek riski azaltma yöntemini veri anonimleştirme nedir rehberinde ele alıyoruz; ancak üretken yapay zeka senaryolarında anonimleştirme her zaman mümkün olmadığından, sovereign cloud çoğu zaman daha güvenilir bir yoldur.

Sorumluluğun Devredilemezliği

Kritik bir ilke: veri sorumlusu kurumdur ve öyle kalır. Veri bir sovereign cloud sağlayıcısına gitse bile, KVKK karşısında sorumluluk kurumun üzerindedir; sağlayıcı yalnızca bir veri işleyendir. Bu yüzden sovereign cloud seçmek, sorumluluğu devretmek değil, sorumluluğu daha yönetilebilir bir çerçevede tutmaktır. Sağlayıcıyla yapılan sözleşme, güvenlik tedbirlerini, denetim haklarını ve verinin işlenme sınırlarını net biçimde tanımlamalıdır.

GDPR ve Sınır Ötesi Bağlam

Avrupa'ya ürün veya hizmet sunan Türk kurumları için tablo GDPR ile katmanlanır. GDPR de sınır ötesi veri aktarımını sıkı koşullara bağlar ve ihlallerde ağır yaptırımlar öngörür; ayrıca "veri egemenliği" kavramı Avrupa'da düzenleyici ve stratejik bir öncelik haline gelmiştir. GDPR'ın çerçevesini GDPR nedir ve Avrupa yapay zeka düzenlemesini EU AI Act nedir rehberlerinde ele alıyoruz. Hem KVKK hem GDPR kapsamındaki bir kurum için, veriyi kaynağına yakın ve egemen kontrol altında tutmak — yani sovereign cloud veya on-premises — çoğu zaman en düşük uyum riskini sunar. EU AI Act'in Türk şirketlerine etkisini EU AI Act Türkiye şirketleri etkisi yazısında, Türkiye'nin gelişen düzenleyici çerçevesini ise Türkiye yapay zeka regülasyonu yazısında bulabilirsiniz.

Gerçek dünyada çoğu kurum için doğru cevap, saf sovereign cloud, saf public cloud ya da saf on-premises değil; bunları birleştiren hibrit bir mimaridir. Hibrit yaklaşım, iş yüklerini veri hassasiyetine göre bölerek her veriyi hak ettiği egemenlik seviyesine yönlendirir.

Hibrit Mimarinin Mantığı

Hibrit yaklaşımın temel fikri basittir: en hassas ve düzenlemeye tabi veriyi sovereign cloud ya da on-premises tut, hassas olmayan veya genel iş yüklerini public cloud'a bırak. Örneğin bir bankada, müşteri finansal kayıtlarını içeren yapay zeka iş yükleri yurt içi bir sovereign cloud'da çalışırken; genel pazarlama metni üretimi, kamuya açık bilgiyle çalışan chatbot veya kod yardımı public cloud modeliyle karşılanabilir. Böylece kurum, sovereign cloud'un egemenlik güvencesi ile public cloud'un hız ve maliyet avantajını aynı anda kullanır.

Katmanlı Bir Egemenlik Modeli

Olgun bir hibrit mimari, veriyi tek bir "hassas/hassas değil" ikilisine değil, birkaç katmana ayırır. En üstte kritik/özel nitelikli veri (sağlık, biyometrik, finansal detay) sovereign cloud veya on-premises'te; ortada hassas ama yönetilebilir veri uygun güvencelerle sovereign cloud'da veya anonimleştirilerek public cloud'da; en altta genel/hassas olmayan veri (kamuya açık bilgi, hassas olmayan dokümantasyon) rahatça public cloud'da işlenir. Bu katmanlı model, her veri için "ne kadar egemenlik gerekiyor?" sorusunu somutlaştırır ve maliyeti gereksiz yere şişirmeden riski yönetir.

Hibrit mimaride veri katmanları ve önerilen konum

Veri katmanı	Örnek	Önerilen konum
Kritik / özel nitelikli	Sağlık, biyometrik, finansal detay	Sovereign cloud / on-premises
Hassas ama yönetilebilir	Kişisel ama özel nitelikli olmayan	Sovereign cloud veya anonimleştirme
Genel / hassas olmayan	Kamuya açık bilgi, kod parçaları	Public cloud

Hibridin Ön Koşulu: Veri Sınıflandırması ve Yönlendirme

Hibrit yaklaşım güçlüdür ama tek bir ön koşulu vardır: net bir veri sınıflandırma ve yönlendirme politikası. Hangi verinin hassas sayıldığı, hangi verinin public cloud'a gidebileceği ve bu kararın nasıl uygulanacağı yazılı ve mümkünse otomatikleştirilmiş olmalıdır. Bu politika olmadan hibrit mimari, "bazen hassas veri yanlışlıkla public cloud'a gider" riskini taşır ki bu, saf public cloud'dan bile daha tehlikeli olabilir çünkü yanlış bir güven duygusu yaratır. Bu yüzden hibrit yaklaşımın kalbi teknoloji değil, veri yönetişimidir. Bu yönetişim disiplinini AI governance nedir ve sorumlu yapay zeka nedir yazılarında ele alıyoruz.

Sovereign cloud tartışması, yapay zeka ve özellikle büyük dil modelleri (LLM) söz konusu olduğunda yeni bir aciliyet kazanır. Çünkü bir LLM iş yükü, tanımı gereği veriyi modele taşır: bir soruyu yanıtlamak için hassas belgeleri, kişisel kayıtları veya kurumsal bilgiyi modele bağlam olarak verirsiniz. Bu veri hareketinin nereye gittiği, sovereign cloud'un yapay zeka bağlamındaki asıl meselesidir.

Prompt'lar Nereye Gidiyor?

Bir public cloud LLM'ine prompt gönderdiğinizde, o prompt — içindeki tüm hassas veriyle — kurum dışına ve çoğu zaman yurt dışına çıkar. Bir hasta raporunu özetlemek, bir sözleşmeyi analiz etmek veya bir müşteri kaydıyla soru yanıtlamak istediğinizde, o veri modelin çalıştığı sunucuya gider. Eğer bu sunucu yurt dışındaysa, bu bir yurt dışına veri aktarımıdır ve veri egemenliği açısından bir boşluk doğurur. Yapay zeka için sovereign yaklaşım, tam olarak bu akışı ülke sınırları ve kurum kontrolü içinde tutmayı hedefler.

Sovereign LLM İçin Üç Ana Yol

Yapay zeka iş yüklerinde egemenliği sağlamanın üç ana yolu vardır. Birincisi self-hosted LLM: açık ağırlıklı bir modeli kurumun kendi yurt içi altyapısında çalıştırmak; prompt'lar hiç dışarı çıkmaz. Açık modellerin bu stratejik değerini açık kaynak LLM nedir yazısında ele alıyoruz. İkincisi yurt içi sovereign cloud üzerinde barındırılan model: kurum kendi altyapısını kurmadan, yurt içi ve yalıtılmış bir bulutta modeli çalıştırır. Üçüncüsü küresel sağlayıcının egemen bölgesi: bazı sağlayıcılar, verinin belirli bir ülkede kalacağını taahhüt eden yalıtılmış bölgeler sunar — bu, veri ikametgahını sağlar ama operasyonel egemenlik derinliği değişkendir.

RAG ve Sovereign Yaklaşım

Kurumsal yapay zekanın en yaygın deseni olan RAG (bilgi getirimiyle üretim), sovereign yaklaşımı özellikle kritik kılar. RAG'de hassas kurumsal belgeler bir vektör veritabanında tutulur ve modele bağlam olarak verilir; bu belgelerin ve prompt'ların sınır dışına çıkmaması gerekir. RAG'in nasıl çalıştığını RAG nedir yazısında ele alıyoruz. Sovereign bir RAG mimarisinde hem model hem vektör veritabanı hem de bilgi tabanı ülke sınırları içinde kalır; böylece kurumsal bilgi erişimi, veri egemenliğinden ödün vermeden sağlanır. Bu modelleri yurt içinde çalıştırmanın operasyonel yükünü (LLMOps) LLMOps nedir yazısında bulabilirsiniz.

Sovereign cloud cazip bir vaat sunar; ama bu vaadin bir bedeli ve bir dizi pratik zorluğu vardır. Dürüst bir değerlendirme, bu zorlukları gizlemez, çünkü onları görmezden gelen kurumlar hayal kırıklığına uğrar.

Maliyet: Ölçek Ekonomisinin Kaybı

Sovereign cloud çoğu zaman public cloud'dan pahalıdır. Bunun temel nedeni ölçek ekonomisidir: küresel public cloud sağlayıcıları, devasa ölçekleri sayesinde birim maliyeti çok düşürebilir. Sovereign cloud ise daha küçük, özel olarak yalıtılmış ve yurt içine sınırlı bir altyapı kullandığı için aynı ölçek avantajına sahip değildir. Sonuç, genellikle daha yüksek bir birim maliyettir. Bu ek maliyet, düzenlemeye tabi veri için çoğu zaman bir "uyum sigortası" olarak değerlendirilir; ama hassas olmayan iş yüklerini de sovereign cloud'a taşımak, gereksiz bir maliyet israfıdır. Maliyet mantığını yapay zeka projelerinde nasıl kuracağınızı toplam sahip olma maliyeti çerçevesiyle değerlendirmeniz gerekir.

En Yeni Modellere Erişim Gecikmesi

Public cloud, en yeni ve en güçlü yapay zeka modellerine çoğu zaman ilk erişimi sunar; bir model yayımlandığında saatler içinde kullanılabilir hale gelir. Sovereign cloud ve self-hosted ortamlarda ise en yeni modele geçiş, indirme, test, dağıtım ve bazen donanım yükseltmesi gerektirir. Bu, hızlı yenilik gerektiren senaryolarda bir dezavantajdır. Ancak çoğu kurumsal görev için "en yeni model" şart değildir; birkaç sürüm önceki bir açık model, birçok görevi fazlasıyla iyi yapar. Yani bu gecikme, kullanım senaryosuna göre önemli veya önemsiz olabilir.

Gerçek Egemenlik Ayrıntıda Saklı

En sinsi zorluk, "egemen" etiketinin gerçekten neyi kapsadığıdır. Bir bulutun sovereign olarak pazarlanması, verinin gerçekten yabancı yargıdan yalıtıldığı anlamına gelmez. Belirleyici sorular şunlardır: şifreleme anahtarlarını kim yönetiyor? Sağlayıcının destek personeli veriye erişebiliyor mu ve nerede bulunuyor? İşletmeci hangi ülkenin hukukuna tabi? Yedekleme ve destek süreçleri yurt içinde mi? Bu soruların yanıtı zayıfsa, coğrafi olarak yurt içinde duran veri bile hukuken tam egemen olmayabilir.

Sovereign cloud'un başlıca pratik zorlukları

Zorluk	Neden ortaya çıkar	Nasıl yönetilir
Yüksek maliyet	Ölçek ekonomisi kaybı	Sadece hassas veriyi taşı, hibrit kur
Model gecikmesi	En yeniye geç erişim	Kritik görevde sabit modelle çalış
Egemenlik derinliği	Etiket ≠ garanti	Anahtar/operasyon/hukuku doğrula
Operasyon uzmanlığı	Yerinde yönetim gerekebilir	LLMOps ve güvenlik ekibi kur
Ölçek esnekliği	Public cloud kadar elastik değil	Kapasiteyi öngörülü planla

Tüm bu boyutları tek bir karar çerçevesinde toplayalım. Sovereign cloud, public cloud mı yoksa on-premises mi sorusunun cevabı, birkaç anahtar soruya verdiğiniz yanıtların bileşiminden çıkar. Kritik olan, kararı sezgiyle değil, sistematik bir çerçeveyle vermektir.

Karar Matrisi

Aşağıdaki matris, kararı belirleyen ana kriterleri ve her birinin hangi modele işaret ettiğini özetler. Çoğunluk bir yöne ağıyorsa karar nettir; kriterler bölünüyorsa — ki en yaygın durum budur — cevap hibrit bir mimaridir.

Sovereign cloud vs public cloud vs on-premises karar matrisi

Karar kriteri	Public cloud lehine	Sovereign cloud lehine	On-premises lehine
Veri hassasiyeti	Genel / düşük	Kişisel / düzenlemeli	En kritik / özel nitelikli
Düzenleyici yük	Düşük	Yüksek (KVKK, BDDK)	En yüksek + tam kontrol şart
Yurt içi zorunluluk	Yok	Var, ama bulut kabul	Var + kurum kontrolü şart
İç uzmanlık	Sınırlı	Orta	Güçlü MLOps/güvenlik ekibi
Ölçek / esneklik ihtiyacı	Yüksek, dalgalı	Orta	Öngörülebilir, sabit
Bütçe	En düşük	Orta-yüksek	Yüksek CAPEX

Karar Veriden Başlar, Teknolojiden Değil

Bu çerçevenin en önemli mesajı şudur: doğru karar teknolojiyle değil, veri sınıflandırmasıyla başlar. "Sovereign cloud mı public cloud mı?" sorusuna doğrudan cevap aramak yanlış başlangıçtır. Doğru başlangıç, "hangi verimiz var ve her biri ne kadar hassas, hangi düzenlemeye tabi?" sorusudur. Veri sınıflandırması netleştiğinde, mimari karar çoğu zaman kendiliğinden ortaya çıkar: kritik veri sovereign cloud veya on-premises'te kalır, genel veri public cloud'a gider, arada kalanlar için hibrit ve anonimleştirme devreye girer.

Türkiye bağlamında sovereign cloud, hem yüksek yapay zeka benimsemesi hem de gelişen bir düzenleyici çerçeve nedeniyle özellikle stratejik bir konudur. Türkiye'de veri egemenliğini destekleyen birkaç yol vardır ve her biri farklı bir egemenlik derinliği sunar.

Yurt İçi Yerli İşletmeci

En yüksek egemenlik derinliğini, yurt içinde konumlanmış ve yerli bir işletmeci tarafından yönetilen veri merkezleri ve bulut hizmetleri sunar. Bu modelde hem veri ikametgahı (fiziksel konum) hem de operasyonel ve hukuki egemenlik yurt içindedir; işletmeci Türk hukukuna tabi olduğu için yabancı yargı erişimi riski en aza iner. Regüle sektörler ve kamu için bu, çoğu zaman en güvenli seçenektir. Türkiye'nin gelişen yerli bulut ve veri merkezi ekosistemi, bu seçeneği giderek daha erişilebilir kılmaktadır.

Küresel Sağlayıcının Yurt İçi Bölgesi

İkinci yol, küresel bulut sağlayıcılarının Türkiye'de veri ikametgahı taahhüdü veren bölgesel seçenekleridir. Bu modelde veri fiziksel olarak yurt içinde kalır — yani veri ikametgahı sağlanır — ama işletmeci yabancı bir şirket olduğu için operasyonel ve hukuki egemenlik tam olmayabilir. Bu seçenek, public cloud'un zengin hizmet setine erişim sunarken veri ikametgahını da sağlar; ancak gerçek egemenlik için anahtar yönetimi ve operasyonel erişim gibi ayrıntıların dikkatle doğrulanması gerekir.

On-Premises ve Özel Bulut

Üçüncü yol, kurumun kendi altyapısında kurduğu on-premises veya özel bulut çözümleridir. Bu, en yüksek kontrolü sunar ama en yüksek maliyet ve operasyon yükünü de getirir. On-premises ile sovereign cloud arasındaki seçim, kurumun kaynağına, uzmanlığına ve düzenleyici beklentisine göre yapılır; bu karşılaştırmayı on-premises yapay zeka vs bulut KVKK rehberimizde ayrıntılı ele alıyoruz.

Türkiye'nin bu yüksek benimsemesi, kurumlar için hem fırsat hem sorumluluktur: yapay zeka hızla yaygınlaşırken, hassas veriyi doğru egemenlik seviyesinde tutan kurumlar hem uyum riskini yönetir hem de müşteri ve vatandaş güvenini korur. Uluslararası yönetişim referansları (ISO/IEC 42001 yapay zeka yönetim sistemi standardı, NIST AI RMF risk çerçevesi), bu egemenliği kanıtlanabilir bir yönetişime dönüştürmede yol gösterir. Bu içerik belirli bir sağlayıcı önermez; seçim, kurumun kendi veri işleme envanteri ve uyum değerlendirmesine bağlıdır.

Sovereign cloud kararı sektöre göre kökten değişir; çünkü her regüle sektörün düzenleyici yükü ve veri hassasiyeti farklıdır. Bu bölümde üç ana regüle sektörü — bankacılık, sağlık, kamu — ve birkaç ek alanı ele alıyoruz.

Bankacılık ve BDDK

Bankacılık, veri hassasiyeti ve düzenleyici yükün en yüksek olduğu alanlardan biridir. BDDK'nın bilgi sistemleri yönetimi ve dış hizmet alımına ilişkin çerçeveleri, kritik verinin korunması, yerleşimi ve denetlenebilirliği konusunda yüksek beklentiler doğurur. Bu beklentiler, uygulamada birçok banka ve finans kurumunu sovereign cloud ya da sıkı denetlenen yurt içi altyapılara yöneltir. Amaç yalnızca uyum değil, aynı zamanda güvendir: müşteri finansal verisinin kurum kontrolünde ve yurt içinde kalması, hem düzenleyici hem itibari bir gerekliliktir. Burada "belirli teknoloji zorunlu" demek yerine "yükümlülükleri karşılayabilen mimari gerekli" demek doğrudur.

Sağlık

Sağlık verisi, KVKK'da özel nitelikli kişisel veri kategorisindedir ve en yüksek koruma seviyesini gerektirir. Hasta kayıtları, görüntüleme verileri ve tanı bilgileri işleyen bir yapay zeka sistemi, veri egemenliği ve yurt dışına veri aktarımı açısından en katı çerçeveye tabidir. Bu, sağlık kurumlarını sıklıkla sovereign cloud veya yurt içi izole altyapı çözümlerine yöneltir. Görüntü analizinde performans için public cloud'un cazibesi büyük olsa da, verinin hassasiyeti çoğu zaman egemenliği öne çıkarır; bu senaryolarda anonimleştirme veya yurt içi işleme kritik hale gelir.

Kamu

Kamu kurumları için veri egemenliği çoğu zaman bir ulusal güvenlik ve egemenlik meselesidir. Vatandaş verisinin yabancı bir sağlayıcının küresel altyapısında işlenmesi, hem hukuki hem stratejik açıdan hassastır. Bu yüzden kamuda sovereign cloud ve yurt içi bulut çözümleri, çoğu zaman varsayılan tercihtir. Kamu, sovereign cloud'un en doğal ve en güçlü kullanım alanlarından biridir; çünkü burada egemenlik yalnızca bir uyum konusu değil, doğrudan bir devlet önceliğidir.

Diğer Regüle Alanlar: Sigorta, Telekom, Hukuk

Regüle sektörler bankacılık, sağlık ve kamuyla sınırlı değildir. Sigortacılık hem finansal hem sağlık verisini bir arada işlediği için yüksek hassasiyet taşır ve tipik bir sovereign/hibrit adayıdır. Telekom operatörleri çok büyük hacimde abone ve iletişim üstverisi işler; bu hacim ve hassasiyet, hem maliyet hem egemenlik açısından sovereign yaklaşımı cazip kılar. Hukuk büroları ve danışmanlık firmaları ise müvekkil gizliliği nedeniyle en yüksek veri hassasiyetine sahiptir; bir dava dosyasının yurt dışı bir servise gitmesi hem KVKK hem meslek sırrı açısından kabul edilemez olabilir.

Sektörel eğilim: sovereign cloud, on-premises ve hibrit

Sektör	Baskın eğilim	Ana sürücü
Bankacılık	Sovereign cloud / on-premises	BDDK, kritik finansal veri
Sağlık	Sovereign / yurt içi izole	Özel nitelikli veri
Kamu	Sovereign / yurt içi bulut	Ulusal veri egemenliği
Sigorta	Sovereign / hibrit	Karışık hassasiyet
Telekom	Hibrit	Hacim + dalgalı yük
Hukuk	Sovereign / on-premises	Müvekkil gizliliği

Aşağıdaki adım adım kontrol listesi, bir kurumu sovereign cloud ya da hibrit bir egemenlik mimarisine sağlıklı biçimde taşımak için pratik bir rehberdir. Her adımı tamamlayabiliyorsanız, kararınız savunulabilir demektir.

Nasıl Yapılır

Sovereign cloud geçiş kontrol listesi

Veri envanterinden egemenlik doğrulamasına kadar sovereign cloud / hibrit geçişin adımları.

1. 1

   Veri işleme envanteri çıkar

   Hangi verinin işlendiğini, hassasiyetini ve KVKK kategorisini (özel nitelikli mi?) belgele; kişisel veri akışlarını haritala.

2. 2

   Veriyi hassasiyete göre sınıflandır

   Her veri kümesi için gereken egemenlik seviyesini belirle: sovereign cloud mu, on-premises mi, public cloud mu, anonimleştirme mi?

3. 3

   Aktarım ve egemenlik riskini değerlendir

   Public cloud kullanılacaksa yurt dışına veri aktarımı olup olmadığını ve güvence mekanizmasını netleştir; veri ikametgahı ile egemenliği ayır.

4. 4

   Egemenlik derinliğini doğrula

   Sovereign cloud adayında anahtar yönetimini, operasyonel erişimi ve işletmecinin tabi olduğu hukuku sözleşme ve mimariyle doğrula.

5. 5

   Dar bir pilotla başla

   En hassas tek bir yapay zeka akışını yurt içi bir sovereign ortamda pilotla; büyük yatırıma girmeden doğrula.

6. 6

   Yönetişim ve ölçüm kur

   Veri sınıflandırma, erişim, log, denetim ve KPI çerçevesini tanımla; uyum ve maliyeti düzenli izle.

Bu kontrol listesinin ilk adımının — veri işleme envanteri — atlanması, sovereign cloud kararında yapılan en yaygın ve en pahalı hatadır. Envanter olmadan verilen her karar, tahmine dayanır. İkinci en önemli adım ise egemenlik derinliğinin doğrulanmasıdır; çünkü "egemen" etiketine körü körüne güvenmek, coğrafi olarak yurt içinde ama hukuken egemen olmayan bir kuruluma yol açabilir.

Bir sovereign cloud ya da hibrit egemenlik mimarisi kararı, teknik bir kurulumla bitmez; onu ayakta tutan bir yönetişim yapısı gerektirir. Yönetişim olmadan, en iyi mimari bile zamanla aşınır: veri sınıflandırması güncelliğini yitirir, erişim hakları birikir ve egemenlik avantajı sessizce kaybolur.

Roller ve Sorumluluk

Sağlam bir yönetişim, kararı ve sürekliliği birkaç role dağıtır. Veri sorumlusu ve hukuk/uyum, KVKK ve düzenleyici yükümlülüklerin karşılandığını güvence altına alır. BT ve güvenlik, altyapının, erişim kontrolünün ve egemenlik güvencelerinin doğru işlediğini sağlar. İş birimi, hangi verinin gerçekten hassas olduğunu ve iş değerini bilir. Model operasyonu (LLMOps), modelin performansını ve güvenliğini sürdürür. Bu roller bir araya gelmeden verilen kararlar tek boyutlu kalır. Bu rolleri buluşturan disiplin ve doğru danışmanlık, kararın kalitesini belirler; kurumunuza özel bir çerçeve için yapay zeka danışmanlığı ile başlayabilirsiniz.

Denetlenebilirlik: Egemenliğin Kanıtı

Sovereign cloud'un en değerli çıktılarından biri denetlenebilirliktir. Bir denetçi "bu veriye kim, ne zaman, hangi ülkeden erişti?" diye sorduğunda, sovereign bir mimaride cevap doğrudan elinizdedir. Bu, yalnızca bir uyum gerekliliği değil, egemenliğin somut kanıtıdır: veri gerçekten yurt içinde ve kontrolde kaldıysa, bunu gösteren loglar ve kayıtlar da yurt içinde ve erişilebilir olmalıdır. Denetlenebilirliği en baştan tasarlamak — her erişimin loglanması, her aktarımın kaydedilmesi — sovereign cloud'un vaadini kanıtlanabilir kılar. KVKK uyumlu bir yapay zeka mimarisinin denetim ve kontrol katmanını KVKK uyumlu yapay zeka kontrol listesi rehberinde ele alıyoruz.

Düzenli Gözden Geçirme

Yönetişimin son parçası, kararın periyodik gözden geçirilmesidir. Kullanım hacmi, veri hassasiyeti ve düzenleyici çerçeve zamanla değişir; bugün doğru olan mimari, iki yıl sonra yanlış olabilir. Örneğin public cloud'da başlayan bir iş yükü, hacmi ve hassasiyeti arttıkça sovereign cloud'a taşınmayı gerektirebilir; ya da yeni bir düzenleme, mevcut bir kurulumu yetersiz kılabilir. Bu yüzden sovereign cloud kararı bir kerelik bir seçim değil, düzenli gözden geçirilen yaşayan bir mimari politikasıdır. En iyi kurumlar, bu kararı yılda en az bir kez güncel veri, maliyet ve düzenlemeyle yeniden değerlendirir.

Tüm bu tartışmanın altında yatan tek gerçek şudur: doğru sovereign cloud kararı, doğru veri sınıflandırmasından çıkar. Sovereign cloud, public cloud ve on-premises arasında bilinçli seçim yapmak isteyen her kurum, önce verisini hassasiyetine göre katmanlara ayırmalıdır. Bu sınıflandırma yapılmadan verilen her karar, ya aşırı korumacı (her şeyi pahalıya egemen tutmak) ya da aşırı riskli (hassas veriyi kontrolsüz public cloud'a göndermek) olur.

Neden Sınıflandırma Önce Gelir?

Sovereign cloud maliyetli ve operasyonel olarak yüklüdür; bu yüzden her veriyi ona taşımak hem gereksiz hem israftır. Ama hassas veriyi public cloud'da bırakmak da bir uyum riskidir. İkisi arasındaki doğru dengeyi kurmanın tek yolu, hangi verinin gerçekten egemenlik gerektirdiğini bilmektir. Veri sınıflandırması, bu bilgiyi üretir: her veri kümesinin hassasiyetini, KVKK kategorisini (özel nitelikli mi?), düzenleyici bağlamını ve iş değerini belgeler. Bu envanter olmadan verilen sovereign cloud kararı, tahmine dayanır; envanterle birlikte verilen karar ise kanıta dayanır.

Sınıflandırmayı Politikaya Dönüştürmek

Sınıflandırma bir kez yapılıp rafa kaldırılan bir belge olmamalıdır; canlı bir yönlendirme politikasına dönüşmelidir. Yani sistem, hangi verinin nereye gideceğine — sovereign cloud, on-premises, public cloud veya anonimleştirme — otomatik ve tutarlı karar verebilmelidir. Örneğin bir belge kritik olarak etiketlendiğinde, onun yalnızca yurt içi bir egemen ortamda işlenmesi teknik olarak zorlanmalı; genel bir soru geldiğinde ise public cloud modeline yönlendirilebilmelidir. Bu politika, hibrit mimarinin de kalbidir: hibrit ancak net bir sınıflandırma ve yönlendirmeyle güvenli olur. Bu yönetişim disiplinini AI governance nedir yazısında ele alıyoruz.

Sınıflandırma ve Yapay Zeka Akışları

Yapay zeka bağlamında sınıflandırmanın özel bir boyutu vardır: yalnızca depolanan veri değil, modele gönderilen prompt'lar da sınıflandırmaya tabidir. Bir kullanıcı hassas bir belgeyi bir modele bağlam olarak verdiğinde, o akışın hangi ortama gideceği sınıflandırma politikasıyla belirlenmelidir. Bu yüzden sovereign cloud için veri sınıflandırması, statik bir veri envanterinden fazlasıdır; canlı yapay zeka akışlarını da kapsayan dinamik bir yönlendirme katmanıdır. Sınıflandırmayı doğru kuran kurum, sovereign cloud'un maliyetini yalnızca gereken yerde öder ve egemenliği tam olarak ihtiyaç duyulan veride sağlar.

Sovereign cloud'un "egemenlik" vaadi, pazarlama diline değil, somut teknik katmanlara dayanır. Bir bulutun gerçekten egemen olup olmadığını anlamak için, verinin nasıl şifrelendiğine, anahtarların kimde durduğuna ve iş yüklerinin nasıl yalıtıldığına bakmak gerekir. Bu teknik ayrıntılar, "egemen" etiketi ile gerçek egemenlik arasındaki farkın tam olarak yaşandığı yerdir.

Şifreleme ve Anahtar Egemenliği

Verinin durağan halde (depolamada) ve aktarım halinde (ağ üzerinde) şifrelenmesi, sovereign cloud'un temelidir; ama asıl kritik soru şifrelemenin kendisi değil, şifreleme anahtarlarının kimde olduğudur. Eğer anahtarları sağlayıcı yönetiyorsa, sağlayıcı teorik olarak veriyi çözebilir; bu da egemenlik vaadini zayıflatır. Gerçek anahtar egemenliği için kurum, kendi anahtarlarını kendi kontrolünde (müşteri tarafından yönetilen anahtarlar, hatta kurumun kendi donanım güvenlik modülünde) tutmalıdır. Böylece veri sağlayıcının altyapısında dursa bile, sağlayıcı onu okuyamaz. Anahtar egemenliği, sovereign cloud'un en güçlü ama en çok atlanan güvencesidir; çünkü "veri yurt içinde" demek, "veriyi yalnızca kurum çözebilir" demekle aynı şey değildir.

Yalıtım ve Ağ Mimarisi

İkinci teknik katman yalıtımdır. Sovereign cloud, verinin ve iş yüklerinin diğer müşterilerden ve dış ağlardan yalıtılmasını gerektirir. Bu, mantıksal yalıtım (sanal ağlar, özel bulut segmentleri) veya fiziksel yalıtım (yalnızca bir kuruma tahsis edilmiş donanım) biçiminde olabilir. Regüle sektörlerde, özellikle bankacılık ve kamuda, fiziksel yalıtım veya en azından sıkı mantıksal yalıtım çoğu zaman beklenir. Ağ mimarisi de egemenlik açısından kritiktir: verinin dışarıya açılan bir bağlantı noktası varsa, o nokta bir sızıntı riskidir. Sovereign bir mimaride veri akışları en aza indirilir, izlenir ve loglanır; verinin nereye gittiği her an bilinir.

Kimlik ve Erişim Yönetimi

Üçüncü katman, kimin veriye erişebildiğidir. Sovereign cloud'da erişim, en az yetki ilkesine göre tasarlanır: her kullanıcı ve her sistem yalnızca ihtiyaç duyduğu veriye erişir. Kritik nüans, sağlayıcının kendi personelinin erişimidir; bakım ve destek personeli veriye erişebiliyorsa ve bu personel yurt dışındaysa, egemenlik boşluğu doğar. Bu yüzden olgun sovereign cloud kurulumları, sağlayıcı personelinin veriye erişimini teknik olarak imkânsız kılar veya en azından kurumun onayına ve denetimine bağlar. Bu üç teknik katman — anahtar egemenliği, yalıtım ve erişim yönetimi — birlikte sağlandığında, "egemen" etiketi gerçek bir güvenceye dönüşür.

Sovereign cloud kararının sık atlanan bir boyutu iş sürekliliğidir. Bir yapay zeka sistemi iş süreçlerine gömüldükçe, onun kesintisiz çalışması bir "güzel özellik" olmaktan çıkıp bir zorunluluğa dönüşür. Ama egemenlik ile süreklilik arasında bir gerilim vardır: veriyi tek bir ülkede tutmak, coğrafi yedekliliği zorlaştırabilir.

Egemenlik ile Yedekliliğin Gerilimi

Küresel public cloud, coğrafi olarak dağıtılmış veri merkezleri sayesinde yüksek yedeklilik sunar: bir bölge çökse bile hizmet başka bir bölgeden sürebilir. Ama bu bölgeler çoğu zaman farklı ülkelerdedir; ve sovereign cloud, veriyi ülke sınırları içinde tutmayı gerektirdiği için bu sınır ötesi yedeklilikten yararlanamaz. Sonuç, egemenlik ile süreklilik arasında bir denge kurma ihtiyacıdır. Çözüm, yedekliliği ülke içinde kurmaktır: aynı ülkede birden fazla veri merkezi veya erişilebilirlik bölgesi kullanmak. Bu, sınır ötesi yedeklilik kadar geniş olmasa da, çoğu senaryo için yeterli bir süreklilik sağlar.

Yurt İçi Felaket Kurtarma

Sovereign bir mimaride felaket kurtarma, verinin ülke sınırları içinde kaldığı ikinci bir yerde yedeklenmesiyle sağlanır. Yedekleme, arşivleme ve kurtarma süreçlerinin de egemenlik kapsamında olması kritiktir; çünkü verinin kendisi yurt içinde dursa bile, yedekleri yurt dışındaysa egemenlik boşluğu devam eder. Bu yüzden sovereign cloud değerlendirmesinde "yedekler nerede tutuluyor?" sorusu, "ana veri nerede?" sorusu kadar önemlidir. Olgun bir kurulum, tüm veri yaşam döngüsünü — üretim, yedek, arşiv, silme — egemenlik çerçevesinde tutar.

Bağımlılık ve Kesinti Senaryoları

Kritik bir düşünce deneyi şudur: sovereign cloud sağlayıcınız bir gün hizmet veremezse ne olur? Bu risk, veriyi tek bir sağlayıcıya veya tek bir ülke altyapısına bağlamanın bedelidir. Bu yüzden süreklilik planlaması, yalnızca teknik yedekliliği değil, sağlayıcı bağımlılığını da hesaba katmalıdır. İş açısından kritik bir süreç yapay zekaya bağlıysa, bir yedek plan (insan devralması, alternatif yurt içi sağlayıcı) gerekir. Süreklilik planlaması, sovereign cloud kararının ayrılmaz bir parçasıdır; egemenlik ve dayanıklılık birlikte tasarlanmalıdır.

Sovereign cloud kararı statik değildir; koşullar değiştikçe kurumlar bir sağlayıcıdan diğerine veya bir modelden diğerine geçmek isteyebilir. Bu geçişi mümkün kılan (veya engelleyen) faktör taşınabilirliktir. Bugün verilen mimari karar, yarın yön değiştirme özgürlüğünüzü belirler.

Tedarikçi Kilitlenmesi Riski

En sinsi risk, tedarikçi kilitlenmesidir (vendor lock-in): bir sağlayıcının özel arayüzlerine, veri formatlarına ve araçlarına o kadar bağımlı hale gelirsiniz ki, ayrılmak neredeyse imkânsız veya çok pahalı olur. Bu bağımlılık, sağlayıcı fiyat artırdığında, koşulları değiştirdiğinde veya egemenlik güvencelerini zayıflattığında kurumu savunmasız bırakır. Sovereign cloud bağlamında bu risk özellikle önemlidir; çünkü yerel bir sağlayıcıya bağımlılık, o sağlayıcının kaderine bağımlılık demektir. Açık standartlar ve açık ağırlıklı modeller kullanmak — yani başka bir egemen ortama geçişi mümkün kılan bir mimari — bu kilitlenmeyi azaltır. Açık modellerin bu stratejik değerini açık kaynak LLM nedir yazısında ele alıyoruz.

Taşınabilir Mimari Nasıl Kurulur?

Taşınabilirliğin anahtarı, uygulamayı belirli bir sağlayıcıdan veya modelden soyutlamaktır. Model erişimini standart bir arayüzün arkasına koyduğunuzda, altta çalışan modeli — bir sovereign cloud'dan diğerine veya on-premises'e — görece kolay değiştirebilirsiniz. Aynı şekilde, veriyi ve bilgi tabanını (örneğin bir RAG mimarisindeki vektör veritabanını) sağlayıcıdan bağımsız, taşınabilir formatlarda tutmak, geçişi kolaylaştırır. Böyle tasarlanmış bir sistem, "bir egemen sağlayıcıda başla, gerekirse başka bir egemen ortama taşı" stratejisini gerçekten uygulanabilir kılar. Taşınabilirlik, egemenliğin uzun vadeli sigortasıdır: bugün egemen olan bir kurulum, taşınabilir değilse, yarın bir bağımlılık tuzağına dönüşebilir.

Sovereign cloud'un maliyet boyutunu somutlaştırmak için, açıkça varsayımsal ve illüstratif bir çerçeve düşünelim. Aşağıdaki mantık gerçek bir ölçüm değil, yalnızca değerlendirme yöntemini göstermek içindir; kendi kararınızda bunları kendi ölçülmüş verinizle değiştirmelisiniz.

Maliyet Tarafı: Görünür ve Görünmez Kalemler

Sovereign cloud'un maliyeti yalnızca aylık faturadan ibaret değildir. Görünür kalemler arasında hizmet ücreti, depolama ve işlem maliyeti bulunur; bunlar genellikle public cloud'dan yüksektir. Ama asıl belirleyici olan görünmez kalemlerdir: egemenlik doğrulaması için gereken hukuki ve teknik inceleme, olası yerinde operasyon veya self-hosted LLM için gereken uzmanlık, ve en yeni modele erişim gecikmesinin dolaylı maliyeti. Varsayımsal bir senaryoda, bir kurum sovereign cloud'a geçtiğinde birim işlem maliyetinin public cloud'a göre belirgin biçimde arttığını görebilir; ama bu artış, işlenen verinin yalnızca hassas kısmıyla sınırlı tutulursa yönetilebilir kalır.

Değer Tarafı: Uyumsuzluğun Maliyeti

Maliyet karşılaştırmasının en çok atlanan tarafı, uyumsuzluğun maliyetidir. Public cloud ucuz görünebilir; ama hassas kişisel veri yanlış yerde işlenirse, doğabilecek idari para cezası, itibar kaybı ve düzeltme maliyeti, sovereign cloud'un tüm ek maliyetini kat kat aşabilir. Bu yüzden değerlendirme yalnızca "hangisi ucuz?" değil, "uyumsuzluk riskini de hesaba katınca hangisi daha düşük toplam maliyetli?" sorusuyla yapılmalıdır. İllüstratif bu çerçevenin dersi rakamlar değil, kalıptır: hassas ve düzenlemeye tabi veri için sovereign cloud'un ek maliyeti bir sigorta primi gibi değerlendirilir; hassas olmayan veri için ise bu prim gereksizdir ve public cloud daha mantıklıdır. Bu ayrımı doğru yapan kurum, ne aşırı öder ne de aşırı risk alır.

Bir sovereign cloud ya da hibrit egemenlik mimarisi kararı verildikten sonra iş bitmez; kararın doğru olup olmadığını sürekli ölçmek gerekir. Sağlam bir ölçüm çerçevesi dört boyutu izler ve her boyutu somut bir metriğe bağlar.

Birincisi egemenlik: hassas veri işleyen akışların yüzde kaçı gerçekten yurt içinde ve doğrulanmış egemenlik altında çalışıyor? Hedef yüzde yüzdür ve bu, düzenli denetimle kanıtlanmalıdır. İkincisi uyum: veri işleme envanteri güncel mi, yurt dışına veri aktarımı güvenceleri yerinde mi, denetim kayıtları eksiksiz mi? Üçüncüsü maliyet: sovereign cloud'un ek maliyeti tahminle uyumlu mu, hassas olmayan iş yükleri yanlışlıkla pahalı ortama mı taşınmış? Dördüncüsü performans ve operasyon: gecikme ve kullanılabilirlik hedefte mi, egemenlik güvenceleri periyodik doğrulanıyor mu, ekip yükü sürdürülebilir mi?

Bu dört boyutu düzenli izleyen bir gösterge tablosu, sovereign cloud kararını statik bir seçimden yönetilen bir sürece dönüştürür. Örneğin egemenlik metriği yüzde yüz ama maliyet tahmini aşılıyorsa, hassas olmayan iş yüklerinin public cloud'a taşınıp taşınamayacağı tartışılır; ya da maliyet tutuyor ama denetim kayıtları eksikse, egemenlik iddiası kanıtlanamaz hale gelir. Ölçüm olmadan bu tartışmalar sezgiyle yapılır; ölçümle birlikte veriyle yapılır — ve bu fark, sovereign cloud yatırımını uzun vadede yönetilebilir kılan şeydir. En dürüst metrik ise egemenlik doğrulamasının tazeliğidir: anahtar yönetimi, operasyonel erişim ve işletmeci hukuku en son ne zaman doğrulandı? Bu doğrulama eskiyse, "egemen" etiketi gerçekliğini yitirmeye başlamış olabilir.

Deneyimli bir gözle bakıldığında, sovereign cloud kararı benzer hatalarla bozulur. Bu hataların ortak özelliği, sovereign cloud'u teknik bir etiket sanıp onu bir yönetişim ve veri sınıflandırma disiplini olarak görmemektir.

• Veri ikametgahını veri egemenliğiyle karıştırmak: "Veri Türkiye'de duruyor" deyip egemenliğin sağlandığını sanmak, en yaygın hatadır. İşletmecinin tabi olduğu hukuk ve operasyonel erişim doğrulanmadan ikametgah tek başına egemenlik vermez.
• Karar öncesi veri envanteri çıkarmamak: Hangi verinin ne kadar hassas ve hangi düzenlemeye tabi olduğunu bilmeden verilen her sovereign cloud kararı temelsizdir.
• Anahtar yönetimi ve operasyonel erişimi görmezden gelmek: Şifreleme anahtarları sağlayıcıdaysa ve destek personeli veriye erişebiliyorsa, "egemen" etiketi büyük ölçüde semboliktir.
• "Egemen" etiketine doğrulamasız güvenmek: Sözleşme, teknik mimari ve operasyon incelenmeden bir sovereign cloud iddiasına güvenmek, yanlış bir güven duygusu yaratır.
• Maliyeti yalnızca faturayla kıyaslamak: Sovereign cloud'un ek maliyetini görüp "pahalı" demek, uyumsuzluğun maliyetini (idari ceza, itibar kaybı, aktarım karmaşıklığı) hesaba katmaz.
• Her veriyi aynı kefeye koymak: Hassas olmayan iş yüklerini de pahalı sovereign cloud'a taşımak, gereksiz maliyet israfıdır; doğru cevap hibrittir.
• Yapay zeka prompt'larını unutmak: Bir sistem sovereign kurulsa bile, hassas veri bir public cloud LLM'ine prompt olarak gönderiliyorsa egemenlik boşluğu devam eder. Prompt akışı da egemenlik kapsamında olmalıdır.

Sovereign cloud (egemen bulut) nedir?

Sovereign cloud, verinin ve iş yüklerinin belirli bir ülkenin hukukuna ve yargı yetkisine tabi kalacak şekilde, o ülke sınırları içinde ve yabancı erişimden yalıtılmış biçimde barındırıldığı bir bulut modelidir. Amacı, bulutun esneklik ve ölçek avantajını korurken veri egemenliği ile veri ikametgahını güvence altına almaktır. Sıradan bir bulut hizmetinden farkı, yalnızca verinin nerede durduğunu değil; kimin erişebileceğini, hangi hukuka tabi olduğunu ve operasyonun kimin tarafından yürütüldüğünü de kontrol altına almasıdır. Bu yüzden sovereign cloud, özellikle regüle sektörler için bir uyum ve güven aracı olarak öne çıkar.

Veri egemenliği ile veri ikametgahı arasındaki fark nedir?

Veri ikametgahı (data residency), verinin fiziksel olarak hangi coğrafyada tutulduğu ve işlendiğidir; dar ve teknik bir kavramdır. Veri egemenliği (data sovereignty) ise verinin hangi ülkenin hukukuna ve yargı yetkisine tabi olduğudur; daha geniş, hukuki ve stratejik bir kavramdır. Bir veri Türkiye'de bir veri merkezinde durabilir (ikametgah yurt içi) ama işletmecisi yabancı bir şirketse, o şirketin tabi olduğu yabancı yasalar teorik olarak veriye erişim talebi doğurabilir (egemenlik tam değil). Sovereign cloud'un asıl vaadi, veri ikametgahının ötesine geçip gerçek veri egemenliğini — yani yabancı yargıdan yalıtımı — sağlamaktır.

Sovereign cloud neden regüle sektörler için kritiktir?

Regüle sektörler (bankacılık/BDDK, sağlık, kamu) için veri, hem yüksek hassasiyette hem de sıkı düzenlemeye tabidir. KVKK kişisel verinin korunmasını ve belirli koşullarda yurt içinde tutulmasını isterken, bankacılıkta BDDK kritik verinin yerleşimi ve denetlenebilirliği konusunda yüksek beklentiler doğurur; sağlıkta özel nitelikli veri en yüksek korumayı gerektirir; kamuda ise veri egemenliği bir ulusal güvenlik meselesidir. Sovereign cloud, bu yükümlülükleri karşılayacak biçimde veriyi yurt içinde, denetlenebilir ve yabancı erişimden yalıtılmış tutarak regüle sektörlerin hem uyumu hem de itibari güveni korumasını sağlar. Bu bir hukuki tavsiye değildir; her sektör kendi yükümlülüğünü hukuk ve uyum birimiyle netleştirmelidir.

Sovereign cloud ile public cloud ve on-premises arasındaki fark nedir?

Public cloud, veriyi bir sağlayıcının küresel ve paylaşımlı altyapısında çalıştırır; hız ve ölçek yüksektir ama veri egemenliği ve yurt dışına veri aktarımı sözleşmeye bağlıdır. On-premises, veriyi kurumun kendi altyapısında tutar; kontrol en yüksektir ama maliyet ve operasyon yükü de kurumundur. Sovereign cloud bu ikisinin arasındadır: verinin bir ülkenin sınırları içinde ve yabancı erişimden yalıtılmış kalmasını sağlayan, ama bulutun operasyonel kolaylığının bir kısmını koruyan bir modeldir. Kısaca on-premises maksimum kontrol, public cloud maksimum esneklik, sovereign cloud ise kontrol ile esneklik arasında düzenlemeye duyarlı bir dengedir.

KVKK ve yurt dışına veri aktarımı sovereign cloud kararını nasıl etkiler?

KVKK, kişisel verinin yurt dışına aktarılmasını belirli güvencelere ve koşullara bağlar. Public cloud hizmetleri veriyi çoğu zaman yurt dışındaki veri merkezlerinde işleyebildiği için bu bir yurt dışına veri aktarımı doğurur ve uyum yükü getirir: uygun aktarım mekanizması, açık rıza veya taahhüt temelleri gerekir. Sovereign cloud, veriyi ülke sınırları içinde tutarak bu aktarımı büyük ölçüde ortadan kaldırır; böylece kurum, aktarım yükümlülüğünün karmaşıklığından kurtulur. Yüksek hassasiyetli kişisel veri işleyen kurumlar için yurt dışına veri aktarımı kısıtları, çoğu zaman sovereign cloud ya da on-premises lehine belirleyici bir gerekçedir.

Yapay zeka ve LLM iş yükleri için sovereign yaklaşım ne demektir?

Bir bulut LLM'ine prompt gönderdiğinizde, o prompt içindeki tüm hassas veriyle birlikte kurum dışına ve çoğu zaman yurt dışına çıkar. Yapay zeka için sovereign yaklaşım, bu akışı ülke sınırları ve kurum kontrolü içinde tutmaktır: modeli yurt içinde barındırmak, açık ağırlıklı bir modeli self-hosted LLM olarak çalıştırmak veya sağlayıcının yurt içi ve yalıtılmış bir bölgesini kullanmak. Böylece prompt'lar, kurumsal belgeler ve model yanıtları veri egemenliği çerçevesinde kalır. Bu yaklaşım, RAG gibi kurumsal bilgi erişimi mimarilerinde özellikle önemlidir; çünkü hassas belgeler modele bağlam olarak verilir ve bu bağlamın sınır dışına çıkmaması gerekir.

Sovereign cloud public cloud'dan daha mı pahalıdır?

Çoğu zaman evet, ama tek kaleme değil toplam değere bakmak gerekir. Sovereign cloud, daha küçük ölçekli ve özel olarak yalıtılmış altyapı kullandığı için birim maliyeti genellikle küresel public cloud'un ölçek ekonomisinin altında kalır; ayrıca en yeni modellere ve hizmetlere erişim gecikebilir. Buna karşılık sovereign cloud, uyum riskini, olası idari para cezalarını, itibari kaybı ve yurt dışına veri aktarımının hukuki karmaşıklığını azaltır. Yani karşılaştırma yalnızca fatura değil, "uyumsuzluğun maliyeti" de dahil edilerek yapılmalıdır. Yüksek düzenlemeli veri için sovereign cloud'un ek maliyeti, çoğu zaman bir sigorta primi gibi değerlendirilir.

Türkiye'de sovereign cloud seçenekleri nelerdir?

Türkiye'de veri egemenliğini destekleyen birkaç yol vardır: yurt içinde konumlanmış ve yerli işletmeci tarafından yönetilen veri merkezleri ve bulut hizmetleri; küresel sağlayıcıların Türkiye'de veri ikametgahı taahhüdü veren bölgesel seçenekleri; ve kurumun kendi altyapısında kurduğu on-premises veya özel bulut çözümleri. Her seçenek farklı bir egemenlik derinliği sunar: yerli işletmeci en yüksek egemenlik, yabancı sağlayıcının yurt içi bölgesi ise veri ikametgahı sağlar ama operasyonel egemenlik yabancı işletmecide kalabilir. Doğru seçim, verinin hassasiyetine ve sektörün düzenleyici beklentisine göre yapılır. Bu içerik belirli bir sağlayıcı önermez; seçim kurumun kendi değerlendirmesine bağlıdır.

Sovereign cloud gerçekten yüzde yüz egemenlik sağlar mı?

Otomatik olarak değil; gerçek egemenlik ayrıntıda saklıdır. Bir bulutun "egemen" etiketi taşıması, verinin gerçekten yabancı yargıdan yalıtıldığı anlamına gelmez. Belirleyici sorular şunlardır: şifreleme anahtarlarını kim yönetiyor (kurum mu, sağlayıcı mı)? Sağlayıcının bakım/destek personeli veriye erişebiliyor mu ve nerede bulunuyor? İşletmeci hangi ülkenin hukukuna tabi? Yedekleme ve destek süreçleri de yurt içinde mi? Bu soruların yanıtı zayıfsa, coğrafi olarak yurt içinde duran veri bile hukuken tam egemen olmayabilir. Bu yüzden sovereign cloud, bir etiket değil, doğrulanması gereken bir güvenceler bütünüdür; sözleşme, teknik mimari ve operasyon birlikte incelenmelidir.

Sovereign cloud kararında en sık yapılan hatalar nelerdir?

En sık hatalar şunlardır: veri ikametgahını veri egemenliğiyle karıştırmak ve "veri Türkiye'de duruyor" deyip egemenliğin sağlandığını sanmak; kararı veri işleme envanteri çıkarmadan vermek; anahtar yönetimi ve operasyonel erişim gibi teknik ayrıntıları görmezden gelmek; "egemen" etiketine sözleşme ve mimari doğrulaması yapmadan güvenmek; maliyeti yalnızca faturayla kıyaslayıp uyumsuzluğun maliyetini hesaba katmamak; her veriyi aynı kefeye koyup hassas olmayan iş yüklerini de pahalı sovereign cloud'a taşımak; ve yapay zeka iş yüklerinde prompt'ların sınır dışına çıktığını fark etmemek. Bu hataların ortak kökü, sovereign cloud'u teknik bir etiket sanıp onu bir yönetişim ve veri sınıflandırma disiplini olarak görmemektir.

Özetle sovereign cloud, verinin ve yapay zeka iş yüklerinin bir ülkenin sınırları içinde, yabancı erişimden yalıtılmış ve denetlenebilir biçimde tutulduğu, veri egemenliğini güvence altına alan bir bulut modelidir. Kararın kalbinde veri egemenliği ile veri ikametgahı ayrımı vardır: veri ikametgahı verinin nerede durduğunu, veri egemenliği ise hangi hukuka tabi olduğunu sorar — ve gerçek egemenlik, ikametgahın ötesinde anahtar yönetimi, operasyonel erişim ve hukuki yalıtım gibi ayrıntılarda saklıdır. Regüle sektörler (bankacılık/BDDK, sağlık, kamu) için sovereign cloud kritiktir; çünkü KVKK ve yurt dışına veri aktarımı yükümlülükleri veriyi yurt içinde ve denetlenebilir tutmayı gerektirir.

En önemli mesaj şudur: sovereign cloud bir teknoloji tercihi değil, bir veri yönetişimi kararıdır. Önce veriyi tanıyın, hassasiyetine göre sınıflandırın, sonra her veriyi hak ettiği egemenlik seviyesine yönlendirin. Doğru cevap çoğu kurum için tek bir kutuya sığmaz: en hassas veri sovereign cloud ya da on-premises ile yurt içinde işlenirken, genel iş yükleri public cloud'un hız ve ölçeğinden yararlanabilir — yani cevap çoğu zaman hibrittir. Yapay zeka iş yüklerinde ise prompt'ların da egemenlik kapsamında olması gerektiğini unutmayın; self-hosted LLM ve yurt içi barındırma bunun ana araçlarıdır. Bu dengeyi kuran, egemenliği doğrulayan, düzenli gözden geçiren ve ölçen kurumlar hem uyum riskini yönetir hem de yapay zekadan en yüksek değeri güvenle çıkarır. Temel kavramlar için KVKK nedir ve EU AI Act nedir rehberlerine göz atabilir; on-premises ile bulut kararını on-premises yapay zeka vs bulut KVKK yazısında derinleştirebilir; kurumunuza özel bir sovereign cloud ve KVKK-uyumlu yapay zeka mimarisi için yapay zeka danışmanlığı ile başlayabilir, ekiplerinizin bu mimariyi yönetecek yetkinliği için kurumsal eğitim seçeneklerini inceleyebilir ve tüm kavramları öğrenme merkezinde derinleştirebilirsiniz. Not: Bu içerik bilgilendirme amaçlıdır ve hukuki tavsiye değildir.