Blog

Egemen yapay zeka, bir kurumun veya ülkenin veri, hesaplama gücü ve model ağırlıkları üzerinde dışa bağımlılık olmadan kontrol sahibi olması anlamına geliyor. 2026 yılına girerken bu kavram yalnızca kamu kurumlarının gündeminde değil; regülasyona tabi sektörlerde çalışan orta ölçekli şirketlerin, sağlık ve finans ekiplerinin, hatta ürünlerini yapay zeka ile zenginleştiren KOBİ’lerin de gündemine yerleşti. Egemen yapay zeka bir ürün değil, bir mimari tercihi: altyapıdan başlayıp veri katmanından geçen, model seçimiyle devam eden ve uygulama katmanında sonlanan bir yığın tasarımı. Bu yazıda söz konusu yığını katman katman ele alıyor, hangi noktalarda bağımlılık yarattığını ve kurumların gerçekçi bir yol haritasını nasıl kurabileceğini anlatıyoruz.

Egemen yapay zeka tam olarak neyi kapsıyor?

Terim sıkça “verilerin ülke sınırları içinde kalması” ile eşitleniyor; oysa kapsam bundan çok daha geniş. Egemen bir yapay zeka yığını dört ayrı katmanda kontrol gerektirir:

• Hesaplama katmanı: Eğitim ve çıkarım iş yüklerinin hangi fiziksel donanımda, hangi hukuki çerçevede çalıştığı.
• Veri katmanı: Ham verinin nerede saklandığı, kimin erişebildiği, yedeklerin ve logların hangi bölgede tutulduğu.
• Model katmanı: Modelin ağırlıklarına erişiminiz olup olmadığı, ince ayar yapıp yapamadığınız, sürüm değişikliklerini ne zaman ve nasıl alacağınız.
• Uygulama katmanı: Ajanların, entegrasyonların ve kullanıcı arayüzlerinin bu yığın üzerinde nasıl konumlandığı.

Bu dört katmandan herhangi biri tek bir dış sağlayıcıya bağlıysa, kâğıt üzerinde egemen görünen bir mimari pratikte kırılgan olur. Gerçek egemenlik, katmanlar arasında taşınabilirlik (portability) sağlandığında ortaya çıkar.

Altyapı: egemenliğin en somut katmanı

Hesaplama katmanı, egemenlik tartışmasının en görünür ve en pahalı parçası. Kurumlar burada üç temel model arasında seçim yapıyor: tamamen kendi veri merkezi, barındırılan özel donanım ve paylaşımlı bulut. Her birinin yönetişim, maliyet ve esneklik dengesi farklı.

Kendi donanımınızı işletmek en yüksek kontrolü verir; ancak GPU tedarik süreleri, soğutma, yedeklilik ve donanım yenileme döngüsü gibi operasyonel yükleri de beraberinde getirir. Bu nedenle birçok ekip, eğitim ve çıkarım iş yüklerini coğrafi olarak kendi belirlediği bölgelerde konumlandırılmış dedicated sunucu altyapısı üzerinde çalıştırıyor; böylece fiziksel izolasyonu korurken ölçeklendirme esnekliğini de kaybetmiyor.

Daha hafif iş yükleri için tercih edilen yaklaşım ise çıkarım (inference) katmanını ayrı tutmak. Küçük ve orta ölçekli modeller, sürekli eğitim gerektirmedikleri için VPS hosting hizmeti üzerinde izole biçimde barındırılabilir. Bu yaklaşımın avantajı, veri ikametgahı kurallarını uygularken modelin çalıştığı ortamı uygulama sunucusundan ayırarak saldırı yüzeyini daraltmaktır.

Enerji, gecikme ve gerçek maliyet

Egemenlik kararlarında sık gözden kaçan bir değişken enerji. Büyük modellerin eğitimi tek seferlik bir maliyet olsa da çıkarım sürekli bir gider kalemi. Aynı modelin farklı bölgelerde çalıştırılması, elektrik fiyatları ve soğutma koşulları nedeniyle toplam sahip olma maliyetini ciddi biçimde değiştirebiliyor. Karar verirken yalnızca GPU saat fiyatına değil, veri transferi, depolama katmanı ve yedekleme maliyetlerine birlikte bakmak gerekiyor.

Veri katmanı: uyumluluk ve ikametgah kuralları

Veri egemenliği, yapay zeka egemenliğinin önkoşulu. KVKK, GDPR ve sektörel düzenlemeler, kişisel verilerin işlendiği ortamın denetlenebilir olmasını şart koşuyor. Pratikte bu şu anlama geliyor: bir modelin yalnızca çıktısını değil, o çıktıyı üreten sürecin loglarını, erişim kayıtlarını ve silme prosedürlerini de belgeleyebilmelisiniz.

Uygulamada en sık yapılan hata, vektör veritabanı ve gömme (embedding) katmanını ayrı bir yönetişim alanı olarak görmemek. Oysa bu katman, ham veriden türetilmiş ve çoğu zaman ham veri kadar hassas bilgi içeriyor. Kendi barındırdığınız ortamlarda bu katmanı kurarken dikkat edilmesi gereken noktaları VPS’inizde Supabase barındırırken nelere dikkat edilmeli başlıklı rehberimizde ayrıntılı olarak ele almıştık.

• Ham veri, gömme vektörleri ve ince ayar veri setleri için ayrı saklama politikaları tanımlayın.
• Yedeklerin hangi bölgede tutulduğunu yazılı hale getirin; yedek, ana veriden farklı bir hukuki rejime tabi olabilir.
• Silme taleplerini model ağırlıklarına kadar izlenebilir kılın; eğitilmiş bir modelden veri “çıkarmak” hukuken ve teknik olarak tanımlı bir süreç olmalı.

Model katmanı: açık ağırlıklar mı, kapalı API’ler mi?

Model seçimi, egemenlik tartışmasının kalbinde yer alıyor. Kapalı bir API kullanmak hızlı başlangıç sağlar; ancak model sürümü değiştiğinde davranışın da değişmesi, fiyatlandırmanın tek taraflı güncellenmesi ve verinin sağlayıcı altyapısında işlenmesi gibi bağımlılıklar doğurur. Açık ağırlıklı modeller ise kendi donanımınızda çalıştırılabilir, ince ayara ve tam denetime izin verir; karşılığında mühendislik yatırımı ister.

2026 itibarıyla dengeli yaklaşım şu: yüksek hacimli, düşük riskli görevler için küçük ve kendi ortamınızda çalışan modeller; karmaşık akıl yürütme gerektiren istisnai görevler için ise sözleşmeyle güvence altına alınmış dış servisler. Bu hibrit model, hem maliyeti kontrol altında tutar hem de kritik veri akışlarını kendi sınırlarınız içinde bırakır.

İnce ayar ve model sürümleme disiplini

Kendi modelinizi çalıştırıyorsanız sürümleme, artık bir yazılım meselesi değil yönetişim meselesi haline gelir. Her ince ayar denemesinin hangi veri setiyle, hangi parametrelerle ve hangi değerlendirme ölçütleriyle yapıldığını kayıt altına alın. Aksi halde altı ay sonra “bu model neden böyle davranıyor” sorusunun yanıtı belgelenmemiş olur.

Uygulama katmanı: ajanlar ve otomasyon

Egemen bir yığının asıl değeri, üzerine kurulan ajanlarda ortaya çıkıyor. Görev yükünü yapay zeka ajanlarıyla yöneten KOBİ’ler için kritik soru, ajanın hangi veriye erişebildiği ve hangi eylemleri özerk olarak gerçekleştirebildiği. Bu nedenle KOBİ’ler görev yükünü AI ajanlarıyla nasıl yönetiyor sorusuna verilen yanıt, teknik olduğu kadar organizasyonel bir tasarım kararı.

Ajan mimarisinde üç kural işe yarıyor: en az yetki ilkesi, eylemlerin denetlenebilir loglanması ve insan onayı gerektiren kritik eşiklerin açıkça tanımlanması. Bu kurallar olmadan, egemen altyapı üzerinde çalışan bir ajan bile kurumsal risk üretebilir. Özellikle otonom saldırıların arttığı bir dönemde, ajanların dış sistemlere erişimini sıkı denetlemek gerekiyor; bu konuyu otonom yapay zeka saldırıları rehberimizde ayrıca ele aldık.

Egemen ve bağımlı mimarilerin karşılaştırması

Ölçüt	Kendi barındırdığınız egemen yığın	Dış API’ye dayalı yığın
Veri ikametgahı	Tam kontrol, bölgeyi siz belirlersiniz	Sağlayıcının bölge politikasına bağlı
Model özelleştirme	Ağırlıklara erişim, ince ayar mümkün	Genellikle sınırlı parametre ayarı
Başlangıç hızı	Haftalar ile ölçülür	Saatler ile ölçülür
Operasyonel yük	Yüksek: donanım, güncelleme, izleme	Düşük: sağlayıcı yönetir
Maliyet davranışı	Sabit ve öngörülebilir, ölçekte avantajlı	Değişken, kullanıma bağlı
Sürüm değişikliği riski	Sizin kontrolünüzde	Sağlayıcının takvimine bağlı
Uyumluluk denetimi	Doğrudan denetlenebilir	Sözleşme ve raporlarla sınırlı

Adım adım: egemen yapay zeka yol haritası

Aşağıdaki sıralama, sıfırdan başlayan bir ekip için gerçekçi bir çerçeve sunuyor. Amaç ilk günden tam egemenlik değil, katman katman bağımlılığı azaltmak.

1. Envanter çıkarın. Hangi iş yüklerinin hangi veriyle, hangi modelle ve hangi bölgede çalıştığını tek bir tabloda toplayın. Çoğu kurum bu adımda farkında olmadığı gölge yapay zeka kullanımlarını keşfediyor.
2. Risk sınıflandırması yapın. Her iş yükünü veri hassasiyeti ve hata maliyeti ekseninde etiketleyin. Bu etiketler, hangi iş yükünün kendi altyapınızda kalması gerektiğini belirleyecek.
3. Pilot için izole bir ortam kurun. Küçük bir modeli ve vektör veritabanını ayrı bir ortamda çalıştırın. Deneme ortamını üretimden ayırmak, ölçüm yapmadan karar vermeyi engeller. Bu tür pilotlar için sınırsız hosting paketleri hızlı bir başlangıç sağlayabilir.
4. Değerlendirme ölçütleri belirleyin. Doğruluk, gecikme, birim maliyet ve uyumluluk olmak üzere en az dört ölçüt tanımlayın. Ölçüt olmadan yapılan geçişler genellikle altı ay içinde geri alınıyor.
5. Taşınabilirlik katmanı ekleyin. Model çağrılarını tek bir arayüz arkasında soyutlayın; böylece sağlayıcı veya model değişimi uygulama kodunu etkilemez.
6. Üretime kademeli geçin. Önce iç araçlar, sonra müşteriye dokunmayan süreçler, en son kritik akışlar. Her aşamada geri dönüş planı hazır olsun.

Sık yapılan hatalar

• Egemenliği yalnızca sunucu konumu sanmak. Model ağırlıkları ve loglar başka bir bölgedeyse coğrafi kontrol kâğıt üzerinde kalır.
• Toplam maliyeti eksik hesaplamak. GPU maliyeti, depolama, çıkarım trafiği ve mühendislik saatleri birlikte değerlendirilmelidir.
• Değerlendirme setini atlamak. Kendi modelinize geçmeden önce mevcut çıktı kalitesini ölçmediyseniz, iyileşmeyi de kanıtlayamazsınız.
• Güvenliği sonraya bırakmak. Ajanlara verilen erişim yetkileri, mimarinin en kritik parçasıdır ve sonradan eklenmesi zordur.
• Tek sağlayıcıya bağlı kalmak. Egemenlik iddiası, çıkış stratejisi yoksa sürdürülebilir olmaz.

Sonuç: egemenlik bir hedef değil, süreklilik meselesi

Altyapıdan modellere uzanan egemen bir yapay zeka yığını, tek seferlik bir satın alma kararıyla kurulmuyor. Model sürümleri değişiyor, düzenlemeler güncelleniyor, donanım nesilleri yenileniyor. Bu nedenle egemenliği bir varış noktası değil, düzenli olarak gözden geçirilmesi gereken bir mimari disiplin olarak ele almak gerekiyor. Katmanlar arasında taşınabilirliği koruyan, veri akışlarını belgeleyen ve ölçüm yapmadan karar vermeyen ekipler, hem uyumluluk hem de maliyet tarafında avantaj elde ediyor.

Sık Sorulan Sorular

Egemen yapay zeka yalnızca kamu kurumları için mi geçerli?

Hayır. Kişisel veri işleyen, regülasyona tabi sektörlerde faaliyet gösteren veya ürününde yapay zeka kullanan her ölçekteki şirket için geçerli bir mimari tercih. KOBİ’ler için bu genellikle tam egemenlik değil, kritik veri akışlarını kendi ortamında tutmak şeklinde uygulanıyor.

Kendi modelimi çalıştırmak için mutlaka GPU donanımı mı gerekir?

Büyük modellerin eğitimi için evet. Ancak çıkarım tarafında, görev için yeterli küçük modeller CPU üzerinde de makul gecikmeyle çalışabiliyor. Doğru yaklaşım, görev karmaşıklığına göre model boyutunu seçmek.

Açık ağırlıklı modeller kapalı API’lerden her zaman daha mı iyi?

Her zaman değil. Kapalı servisler en son yeteneklere daha hızlı erişim sağlayabilir. Belirleyici olan, veri hassasiyeti ve sürüm kontrolü ihtiyacınızın hangi ağırlıkta olduğu.

Geçiş süreci ne kadar sürer?

Pilot aşaması genellikle birkaç hafta, üretime kademeli geçiş ise iş yükü sayısına bağlı olarak birkaç ay sürebilir. Envanter ve değerlendirme ölçütleri doğru kurulduysa süre kısalıyor.

Uyumluluk tarafında ilk hangi belgeyi hazırlamalıyım?

Veri akış haritası. Hangi verinin nereden alındığı, nerede işlendiği, nerede saklandığı ve kimin erişebildiğini gösteren tek sayfalık bir harita, sonraki tüm uyumluluk çalışmalarının temelini oluşturuyor.