Kapalı Perimetrede LLM: Düzenlemeye Tabi Bir Şirket Neyi Seçebilir ve Her Seçim Neye Mal Olur

Gereksinim tek bir cümle olarak gelir: belgeler perimetreden çıkamaz. Mimari karar bu cümlenin içinde saklıdır; çünkü perimetre üç farklı yerde çizilebilir ve her yer, onu çizen şirketin üzerine farklı bir maliyet yükler.

Bir model sağlayıcısının barındırılan API'si perimetreyi o sağlayıcıyla yapılan bir sözleşmede tutar. Bir bulut platformunun yönetilen model servisi onu bulut sözleşmesinde tutar. İşlettiğiniz sunucular üzerindeki açık ağırlıklı bir model ise onu kendi ağınızda tutar ve aksi hâlde sağlayıcının üstleneceği her görevi size devreder.

Seçenekleri karşılaştırmadan önce perimetrenin neyi yasakladığını yazıya dökün

“Perimetreden çıkamaz” ifadesi bir risk yöneticisi, bir veri koruma görevlisi ve bir altyapı ekibi için farklı anlamlara gelir. Sorular hâlinde yazıldığında, her seçeneğin sınanabileceği bir gereksinime dönüşür:

• Prompt'ları ve çıktıları, bunları kötüye kullanım açısından inceleyen sağlayıcı personeli dahil, şirket dışından kimin görebileceği
• Verinin yalnızca nerede saklandığı değil, hangi bölgelerde işlenebileceği
• Bir istekten sonra neyin, ne kadar süreyle saklanabileceği ve bunu kimin silebileceği
• Trafiğin, şifreli olsa bile, genel internetten geçip geçemeyeceği
• Şifreleme anahtarlarını ve kimin neye eriştiğini kanıtlayan logları kimin tuttuğu
• Harici bir sağlayıcı kullanmanın hangi sözleşmeleri, kayıt defterlerini ve denetimleri tetiklediği

Yanıtlar veri sınıfına göre farklılaşabilir. Zaten kamuya açık bir düzenleyici bildirim ile bir müşterinin kimlik belgesi aynı perimetreye ihtiyaç duymaz ve bir pipeline bunları farklı yollara yönlendirebilir.

Birinci seçenek: sağlayıcının barındırılan API'si, perimetre sözleşmede

Burada perimetreyi sağlayıcının sözleşmesi ve dokümantasyonu tanımlar; bu yüzden bunlar satır satır okunur. OpenAI'ın API verilerine ilişkin dokümantasyonu, 1 Mart 2023 itibarıyla API'ye gönderilen verilerin, müşteri buna açıkça onay vermedikçe (opt-in) modellerini eğitmek ya da iyileştirmek için kullanılmadığını belirtir. Aynı sayfa, prompt'ları ve yanıtları içerebilen kötüye kullanım izleme loglarının varsayılan olarak oluşturulduğunu ve daha uzun süre saklanması yasa gereği zorunlu olmadıkça ya da servisi veya üçüncü tarafları zarardan korumak için makul ölçüde gerekli olmadıkça 30 güne kadar saklandığını belirtir.

Her iki sınır da daraltılabilir ve her daraltma bir ayar değil, bir onaydır:

• Zero Data Retention (sıfır veri saklama) ya da Modified Abuse Monitoring (değiştirilmiş kötüye kullanım izleme), OpenAI müşteriyi onayladığında müşteri içeriğini kötüye kullanım izleme loglarının dışında tutar. Dokümantasyonun uygun olmadığını belirttiği uç noktalar yine de uygulama durumunu (application state) saklayabilir ve bunların bir kısmı bu durumu silinene kadar tutabilir; OpenAI ayrıca yazılı bildirimle belirli modelleri uygun olmayan hâle getirme hakkını saklı tutar
• Veri yerleşimi (data residency) proje başına yapılandırılır ya da istek başına seçilir, uygunluk satış ekibiyle kontrol edilir ve Amerika Birleşik Devletleri dışındaki her bölge, kötüye kullanım izleme kontrolleri için onay ve bir Modified Retention amendment (değiştirilmiş saklama koşullarına ilişkin sözleşme eki) gerektirir
• Veri yerleşimi, müşteri içeriğini durağan hâlde (at rest) seçilen bölgede saklar; çıkarımın da orada çalışması yalnızca dokümantasyonun bölgesel işlemeyi desteklediğini belirttiği bölgelerde söz konusudur
• Veri yerleşimi sistem verilerini, yani müşteri içeriği içermeyen hesap verilerini, meta verileri ve kullanım verilerini kapsamaz; bunlar seçilen bölgenin dışında işlenebilir ve saklanabilir
• Aynı sayfa, 5 Mart 2026 veya sonrasında yayımlanan uygun modeller için veri yerleşimi uç noktalarına %10 ek ücret uygulandığını belirtir

Model de sağlayıcının takvimine tabidir. OpenAI'ın kullanımdan kaldırma (deprecations) sayfası, güvenlik veya uyumluluk kaygıları daha hızlı bir takvim gerektirmedikçe, kullanımdan kaldırmadan önceki asgari bildirim sürelerini belirtir: genel kullanıma sunulmuş bir model için en az 6 ay, böyle bir modelin özelleşmiş varyantları için en az 3 ay ve önizleme modelleri için çok daha kısa, örneğin 2 haftalık bir bildirim. Her kullanımdan kaldırma, yerine gelecek modeli o tarihten önce kendi belgeleriniz üzerinde puanlamak demektir; bu yüzden geçiş bir olay değil, tekrar eden planlı bir iştir.

İkinci seçenek: bulut platformunuzun yönetilen model servisi

Bulut platformları birkaç geliştiricinin modellerini sunar ve bunların bir kısmı, bir şirketin halihazırda sahip olabileceği bulut sözleşmesi kapsamındadır. Microsoft'un Microsoft Foundry'de Azure tarafından satılan modellere ilişkin dokümantasyonu, prompt'ların, tamamlamaların ve embedding'lerin OpenAI'a ya da bu modellerin diğer sağlayıcılarına açık olmadığını belirtir. Aynı katalogda Microsoft'un satmadığı modeller de yer alır: Microsoft Foundry'deki Claude modelleri için dokümantasyonu Anthropic'i satıcı, işletici ve prompt'lar ile çıktılar için bağımsız bir veri işleyen olarak tanımlar; barındırma seçeneklerinden biri bunları Anthropic'in altyapısında işler ve bu altyapı seçilen Azure bölgesinin dışında olabilir.

Amazon Bedrock dokümantasyonu, her bölgede model sağlayıcısı başına, sahibi ve işleticisi Bedrock servis ekibi olan ve model sağlayıcılarının erişiminin bulunmadığı bir model dağıtım hesabı tanımlar; bu nedenle model sağlayıcıları müşterilerin prompt'larını ve tamamlamalarını görmez.

Model yine de sizin kendi ağınızda değil, bulutun işlettiği altyapıda çalışır. Bazı perimetreler için bu içeride sayılır; diğerleri için yalnızca üçüncü seçenek içeride sayılır. İçeride sayıldığında perimetre tenant içinde yapılan seçimlere bağlıdır ve dokümantasyon bunların sonuçlarını açıkça ortaya koyar:

• Çıkarım nerede çalışır: Azure'da Global olarak etiketlenen bir dağıtım türü prompt'ları ve yanıtları modelin dağıtıldığı herhangi bir coğrafyada, Data Zone türü veri bölgesi (data zone) içinde, coğrafya tabanlı Standard ya da Provisioned türü ise müşterinin belirttiği coğrafya içinde işleyebilir; hepsinde durağan hâldeki veri (data at rest) müşterinin belirlediği coğrafyada kalır
• Hangi modellere erişirsiniz: Microsoft, yeni modellerin önce Global Standard'da kullanıma sunulduğunu, Data Zone ve bölgesel dağıtım türlerine daha sonra ulaştığını ve her dağıtım türüne ulaşmalarının garanti olmadığını belirtir
• Bir sürüm ne kadar yaşar: Azure, genel kullanıma sunulmuş bir modelin kullanımdan kaldırılma tarihini lansmandan 18 ay sonrası olarak belirler ve modeli 12. ayda yeni müşterilere kapatır; Anthropic, DeepSeek, Fireworks ve Mistral AI'ın genel kullanıma sunulmuş modelleri 12 aylık bir yaşam döngüsünü izler ve Microsoft kısaltılmış bildirim süresiyle acil kullanımdan kaldırma hakkını saklı tutar
• Trafik modele nasıl ulaşır: Amazon Bedrock, çalışma zamanı (runtime) API'si için AWS PrivateLink üzerinden arayüz VPC uç noktalarını destekler; böylece VPC'nizden gelen çağrılar modele internet ağ geçidi ya da genel IP adresleri olmadan ulaşır
• İçeriği kötüye kullanım açısından kim inceler: Azure'da ek Limited Access (sınırlı erişim) uygunluk kriterlerini karşılayan müşteriler, kötüye kullanım izlemenin değiştirilmesi için başvurabilir; onaylandıktan sonra prompt'lar ve tamamlamalar insan incelemesi için saklanmaz, ancak otomatik inceleme yine de çalışabilir

DORA kapsamındaki bir AB finansal kuruluşu için bulut sözleşmesi zaten bir BİT üçüncü taraf sözleşmesel düzenlemesidir. Avrupa Denetim Otoriteleri (ESA'lar) 18 Kasım 2025'te AB düzeyinde gözetime tabi kritik BİT üçüncü taraf hizmet sağlayıcılarının listesini yayımladı; listede Amazon Web Services EMEA, Google Cloud EMEA ve Microsoft Ireland Operations da yer alıyor. Avrupa Bankacılık Otoritesi (EBA), DORA'nın 17 Ocak 2025'te uygulanmaya başladığını ve kapsamındaki kuruluşların BİT üçüncü taraf hizmet sağlayıcılarıyla yaptıkları sözleşmesel düzenlemelere ilişkin bir kayıt defteri tutması gerektiğini belirtir. Dolayısıyla kuruluşun daha önce sözleşme yapmadığı bir model sağlayıcısı ya da halihazırda sahip olduğu bir bulut sözleşmesi kapsamındaki yeni bir servis, yalnızca mimarinin değil, o kayıt defterinin de konusudur.

Üçüncü seçenek: işlettiğiniz altyapı üzerinde açık ağırlıklı bir model

Kendi altyapınızda barındırma, ister şirket içinde (on-premises) ister kendi bulut hesabınızdaki sanal makinelerde olsun, çıkarımı, sağlayıcının üstlendiği her görevle birlikte içeri alır. İlk görev lisansı okumaktır; çünkü açık ağırlıklı modellerin ortak tek bir lisansı yoktur. Mistral Small 3, Qwen3-32B ve OpenAI'ın gpt-oss-120b modeli Hugging Face'te Apache 2.0 lisansıyla yayımlanmıştır. Meta'nın, aşağıda donanım ihtiyacı hesaplanan Llama 3.3 70B modelini kapsayan Llama 3.3 Community License'ı, kullanımın kabul edilebilir kullanım politikasına uymasını şart koşar. Ayrıca, bağlı şirketlerininkiler dahil ürün veya hizmetleri sürüm tarihinden önceki takvim ayında 700 milyondan fazla aylık aktif kullanıcıya sahip olan bir lisans alıcısının lisans talep etmesini şart koşar; Meta bu lisansı tamamen kendi takdirine bağlı olarak verebilir.

Donanım ihtiyacı, parametre sayısına ve sayısal hassasiyete (precision) göre belirlenir. Llama 3.3 70B Instruct yaklaşık 70,6 milyar parametreye sahiptir; parametre başına 16 bit kullanıldığında yalnızca ağırlıklar yaklaşık 141 GB (131 GiB) yer kaplar ve bu, eşzamanlı isteklerin key-value önbelleği için bellek ayrılmadan önce bile 80 GB'lık tek bir hızlandırıcıya sığmaz. gpt-oss-120b model kartı, mixture-of-experts (uzman karışımı) ağırlıklarının MXFP4 kuantizasyonunun modelin tek bir 80 GB GPU üzerinde çalışmasını sağladığını belirtir.

Serving katmanı sizin güvenlik sınırınız hâline gelir. vLLM'in güvenlik dokümantasyonu, çok düğümlü bir dağıtımda düğümler arasındaki iletişimin varsayılan olarak güvensiz olduğunu ve düğümler izole bir ağa yerleştirilerek korunması gerektiğini; API anahtarı seçeneğinin ise yalnızca belirli yol önekleri altındaki uç noktaları koruduğunu, aynı sunucudaki diğer hassas uç noktalarda hiçbir kimlik doğrulaması olmadığını belirtir. Model dosyası da tedarik zincirinin bir parçasıdır: Python dokümantasyonu, pickle modülünün güvenli olmadığı ve kötü niyetli pickle verisinin unpickling sırasında keyfi kod çalıştırabileceği konusunda uyarır; ağırlıklar için daha güvenli seçimin, pickle'ın aksine tensörleri güvenli biçimde saklamak için tasarlanmış safetensors formatı olmasının nedeni budur.

Şirketin artık kendisinin işlettikleri:

• Tepe hacme göre boyutlandırılmış, talepten önce satın alınmış ya da rezerve edilmiş, arızalanan bir düğüm için pay bırakılmış hızlandırıcı kapasitesi
• Hem güvenliğin hem de kabul puanlarının izin verdiği bir takvimle yamalanan sürücüler, serving motoru ve işletim sistemi
• Ağ izolasyonu, model sunucusunun önünde kimlik doğrulama ve bir denetçinin okuyabileceği erişim logları
• Model yükseltmeleri: daha yeni bir açık ağırlıklı model, ancak biri onu sizin belgeleriniz üzerinde puanlayıp yayına aldığında üretime ulaşır
• Model sunucusu için nöbet; çünkü onu hiçbir sağlayıcının durum sayfası kapsamaz

Uyumluluk kanıtı: denetçi her seçenekte ne ister

GDPR kapsamındaki yükümlülükler ve şirket ISO/IEC 27001'e göre sertifikalıysa bu standarttan doğanlar, şirket hangi seçeneği seçerse seçsin, bir sağlayıcı onun veri işleyeni olarak hareket etse bile şirketin kendisine ait kalır. Değişen, kanıtın nereden geldiğidir:

• Barındırılan API: sağlayıcının veri işleme şartları, saklama ve veri yerleşimi kontrollerine ilişkin onaylar, sağlayıcının alt veri işleyenleri ve DORA kapsamındaki bir finansal kuruluş için bu sözleşmesel düzenlemenin kayıt defterindeki girdisi
• Yönetilen model servisi: her model dağıtımının dağıtım türü ve bölgesi, özel uç nokta yapılandırması, kötüye kullanım izlemede onaylanmış her değişiklik ve bulutun mevcut güvence raporlarının yeni servisi kapsamlarına alıp almadığı
• Kendi barındırdığınız model: ağ izolasyonu ve erişim loglarından her modelin lisansına ve üretimdeki her ağırlık dosyasının kaynağına kadar model sunucusu ve etrafındaki her şey için kendi kanıtınız; sunucular bir bulut hesabındaki sanal makinelerse buna buluta ilişkin mevcut sözleşmesel düzenleme de eklenir

Üç seçenekte de kanıt, pipeline her belgeyi hangi dağıtımın, bölgenin ve modelin işlediğini çalışırken kaydettiğinde daha ucuza gelir. Sonradan bir denetim için bir araya getirildiğinde aynı kanıt, geçmişin yeniden inşasına dönüşür.

Latency ve throughput: paylaşılan kapasite ya da sahip olduğunuz kapasite

Paylaşılan kapasitede throughput tavanı başkasının politikasıdır. OpenAI, dakika ve gün başına istek ve token cinsinden ölçülen hız sınırları uygular. Bir organizasyonu, harcaması arttıkça otomatik olarak daha yüksek bir kullanım katmanına (usage tier) taşır, bu da genellikle o sınırları yükseltir; ayrıca sınırların içinde kalsa bile çok hızlı büyüyen trafiği yavaşlatabilir. Microsoft, provisioned dağıtım türlerinin garantili throughput ve daha düşük latency değişkenliği sağladığını, standard türlerin ise best-effort (garanti vermeden, mümkün olan en iyi çabayla) çalıştığını belirtir.

Rezerve kapasitenin kendi şartları vardır. Amazon Bedrock Provisioned Throughput taahhütsüz ya da bir veya altı aylık süreyle satın alınabilir; bu süre boyunca silinemez. Microsoft, ne PTU kotasının ne de bir rezervasyonun bir bölgede kapasiteyi garanti ettiğini ve provisioned bir dağıtımı silmenin ya da küçültmenin kapasitesini serbest bıraktığını, aynı kapasitenin daha sonra kullanılabilir olacağının garantisi olmadığını belirtir. OpenAI, trafiği düzenli olarak artış hızı sınırlarına (ramp-rate limits) takılan kurumsal müşterileri daha öngörülebilir kapasite için Scale Tier'a ya da GPT-5.6 ve sonraki modeller için Reserved Tier'a yönlendirir.

Kimsenin beklemediği işler bu kapasiteye ihtiyaç duymaz. OpenAI'ın Batch API'si asenkron istekleri %50 daha düşük maliyetle ve 24 saatlik bir tamamlanma süresiyle işler; ancak OpenAI'ın veri sayfası batch ve dosya uç noktalarını Zero Data Retention için uygun olmayanlar arasında listeler ve bu uç noktalardaki verilerin silinene kadar saklandığını belirtir. Azure, batch dağıtım türlerini %50 indirimle listeler; bunlardan Global Batch modelin dağıtıldığı herhangi bir coğrafyada işleyebilir, Data Zone Batch ise trafiği yalnızca veri bölgesi içindeki veri merkezlerine yönlendirir.

Sahip olduğunuz kapasitede harici hız sınırları ve paylaşılan bir kuyruk yoktur; tavan, satın aldığınız ya da rezerve ettiğiniz donanımdır. Her seçenekte çıktının uzunluğu önemlidir: OpenAI'ın latency rehberi, token üretmeyi neredeyse her zaman latency'si en yüksek adım olarak tanımlar ve genel bir buluşsal kural olarak çıktı token'larını %50 azaltmanın latency'yi yaklaşık %50 azaltabileceğini belirtir. Bu yüzden modelden düzyazı yerine kompakt yapılandırılmış kayıtlar istemek üç seçeneğin hepsinde işe yarar.

Kadro: her seçenekte nöbeti kim tutar

Seçenekler, şirketin içinde kalan işlerin listesinde ayrışır:

• Her seçenekte: pipeline'ın kendisi, kabul puanları ve onu işleten bir sahip
• Barındırılan API: tedarikçi yönetimi, saklama ve veri yerleşimi onayları, hız sınırı planlaması ve sağlayıcının kullanımdan kaldırma takvimine göre geçişler
• Yönetilen model servisi: aynı işler bu kez bulut için; buna ek olarak bölge bazında dağıtım türleri, kotalar ve rezerve kapasite ile özel ağ yapılandırması
• Kendi barındırdığınız model: hızlandırıcı altyapısı, serving motoru, güvenlik yamaları, model yükseltmeleri ve pipeline kaç saat çalışıyorsa o kadar saat nöbet

Bir pilot aylarca nöbet olmadan çalışabilir; üretim çalışamaz. Kendi altyapınızda barındırma seçeneğini, onu işletecek insanları hesaba katmadan fiyatlamak, bir modelin maliyetini bir servisin fiyatıyla karşılaştırmak demektir.

Seçenekleri bir arada kullanmak bir yönlendirme kuralı demektir ve işin zor kısmı bu kuraldır

Seçenekler birbirini dışlamaz. Bir pipeline kamuya açık belgeleri barındırılan bir modele gönderip kısıtlı sınıfları şirketin kendi barındırdığı bir modelde tutabilir. Bu, yalnızca yönlendirme kodda zorunlu kılındığında ve kanıt bıraktığında geçerlidir:

• Sınıflandırma herhangi bir model çağrısından önce yapılır ve sınıflandırılamayan bir belge en kısıtlayıcı yoldan gider
• Her yol, kendi kimlik bilgilerine sahip ayrı bir dağıtımdır ve kısıtlı yolun dış modele ne kimlik bilgisi ne de ağ yolu vardır; böylece yanlış yönlendirilen bir belge perimetreden çıkmak yerine hata verip durur
• Her yol aynı kabul setinde puanlanır; çünkü tek bir pipeline'daki iki model, iki ayrı kalite düzeyi demektir
• İzlenen yol belge başına loglanır; böylece hangi sağlayıcının hangi belgeyi işlediğine dair bir denetim sorusu kayıtlardan yanıtlanır

Kapalı bir perimetre, modeli sizin yerinize seçmez. Hangi işin sizde kalacağını seçer: sözleşmeleri okumak ve onayları beklemek, doğru bölgede kapasite ayırmak ya da sunucuları işletip gece gelen alarma yanıt vermek.

Bunu perimetrenizin içinde kuran firma önce perimetreyi sorar

Bu yazının arkasındaki soru, hangi mühendislik şirketlerinin LLM ile belge ve ticket işlemeyi bir müşterinin kendi perimetresinde, şirket içinde (on-premises) ya da özel bir bulutta kurduğudur. Onları birbirinden ayıran şey, bir model önermeden önce ne sorduklarında görülür:

• Pipeline'ın hangi veri sınıflarını göreceğini ve perimetrenin her biri için neyi yasakladığını, risk ve veri koruma ekiplerinizin kullandığı terimlerle sorar
• Halihazırda hangi bulut sözleşmelerine, bölgelere ve onaylı sağlayıcılara sahip olduğunuzu ve yeni kullanımın DORA'nın gerektirdiği gibi bir kayıt defterine girip girmediğini sorar
• En büyük modelin kazanacağını varsaymak yerine, kendi belgeleriniz üzerinde en az iki dağıtım seçeneğini aynı kabul setiyle karşılaştırır
• Barındırılan her seçeneğin saklama, veri yerleşimi ve kullanımdan kaldırma şartlarını, bunları okuduğu tarihle birlikte aktarır
• Kendi altyapınızda barındırma için donanımı ölçülmüş token hacimlerinden yola çıkarak boyutlandırır ve sunucuları kimin yamalayacağını, nöbeti kimin tutacağını açıkça belirtir
• Pipeline'ın her belgeyi işleyen dağıtımı, bölgeyi ve model sürümünü nasıl kaydettiğini gösterir

Bu soruları sormadan önce bir model öneren firma, perimetrenizi bunu söylemeden seçmiş olur.

Dağıtım kararı, şirketinizin her belge sınıfı için hangi işi üstlenmeye hazır olduğuna dayanır: sözleşmeler ve onaylar, bir bölgede kapasite ya da sunucular ve nöbet.

amBrain'in yukarıdaki özette anlatılan üretim entegrasyonunun ötesinde kamuya kanıtlayabildikleri: amBrain 2019'dan beri yazılım geliştiriyor. Üç formatta çalışıyoruz: tam teslim, özel ekip ya da sizin ekibinize yerleşen mühendisler.