KVKK'ya uygun yapay zekâ mümkün mü? On-premise mimarilerin mantığı

Düzenlemeye tabi kurumlarda yapay zekâ konuşmaları çoğunlukla aynı yerde tıkanır: iş tarafı AI istiyor, hukuk ve güvenlik onay vermiyor. İki taraf da haklı — çünkü soru yanlış kurulmuş durumda. Doğru soru "AI kullanalım mı?" değil, "AI trafiği nerede aksın?" sorusudur.

Tıkanmanın dört tanıdık belirtisi

• Hassas veri nedeniyle bulut AI hizmetleri kullanılamıyor.
• Çalışanlar kurumsal veriyi halka açık araçlara yapıştırıyor — yasak var, denetim yok.
• Regülasyon (bankacılık, sağlık, kamu) veri lokasyonu şartı koyuyor.
• AI pilotları hukuk incelemesinde aylardır bekliyor.

İkinci madde en tehlikelisi: resmi bir AI kanalı olmayan kurumda gölge kullanım başlar ve veri, en kontrolsüz yoldan dışarı çıkar. Yasak, bu trafiği ortadan kaldırmaz — yalnızca ölçülemez hâle getirir. Kurumsal bir kanal açmak, çoğu zaman riski artıran değil azaltan hamledir.

On-premise mimarinin mantığı

On-premise (kurum içi) AI kurulumunun ilkesi tek cümledir: açık kaynak modeller kurumun kendi donanımında veya kontrolündeki özel bulutta servis edilir; hiçbir istek kurumsal sınırın dışına çıkmaz.

Bunun üzerine üç katman eklenir:

1. Ağ izolasyonu ve erişim kontrolü — gerekiyorsa tamamen kapalı ağ dağıtımı; kim neye erişebilir, sorgu katmanında uygulanır.
2. Veri sınıflandırma ve maskeleme hattı — kişisel veri, modele ancak maskelenmiş/anonimleştirilmiş biçimde gider. KVKK uyumu sonradan eklenen filtre değil, hattın parçasıdır.
3. Denetim izi — AI trafiğinin tamamının kurum sınırında kaldığı iddia değil, denetlenebilir kayıttır.

Dört dağıtım seçeneği

"On-premise mi, bulut mu?" ikili sorusu pratikte dörde ayrılır ve aradaki seçenekler çoğu kurum için doğru cevabı barındırır.

Sahada en sık kurduğumuz yapı hibrittir ve nedeni pragmatiktir: bir kurumun bütün senaryoları aynı hassasiyette değildir. Pazarlama metni yazan kullanıcı ile özlük dosyası inceleyen kullanıcının aynı modele gitmesi için bir neden yoktur. Yönlendirme kararının nasıl kurulduğunu LLM API'leri ve yurt dışına veri aktarımı yazımızda ayrıntılandırdık.

Maskeleme hattı nasıl kurulur?

Maskeleme, "kişisel veriyi sil" kadar basit bir işlem değildir; işi bozmadan kimliği kaldırmak gerekir. Beş adımda kurulur:

1. Veri sınıflandırma. Hangi alanlar kişisel veri, hangileri özel nitelikli? Bu, teknik değil kurumsal bir envanter çalışmasıdır ve VERBİS kaydınızla tutarlı olmalıdır.
2. Tespit. Yapılandırılmış alanlarda kural, serbest metinde varlık tanıma ile kişisel veri bulunur. Serbest metin daha zordur ve kaçak oranı burada ölçülmelidir.
3. Dönüştürme. Alan, işin gereğine göre farklı işlenir: tamamen kaldırma, yer tutucuyla değiştirme, genelleştirme (doğum tarihi → yaş aralığı) ya da tutarlı takma ad.
4. Geri yazma. Cevap kullanıcıya dönerken yer tutucular gerçek değerlerle değiştirilir. Eşleştirme tablosu kurum sınırında kalır.
5. Ölçüm. Maskeleme hattının kaçak oranı düzenli olarak test edilir. Test edilmeyen bir maskeleme hattı, güvence değil varsayımdır.

Üçüncü adımda kritik bir ayrım vardır: takma adlaştırma anonimleştirme değildir. Eşleştirme anahtarı sizde durduğu sürece veri hâlâ kişisel veridir. Veri minimizasyonu ilkesi burada devreye girer — en güvenli alan, hiç gönderilmeyen alandır.

Erişim kontrolü neden sorgu katmanında olmalı?

Kurum içi kurulumlarda en sık yapılan mimari hata, yetki kontrolünü arayüzde bırakmaktır: model tüm belgeleri görür, cevap sonradan filtrelenir.

Bu yaklaşım sızıntıyı engellemez. Model, görmemesi gereken belgeden edindiği bilgiyi yeniden ifade ederek aktarabilir; metin filtresi kelimeyi yakalar, bilgiyi yakalayamaz.

Doğru mimaride yetki aramaya iner:

• Her belge parçası erişim üst verisiyle etiketlenir.
• Arama, sorguyu yapan kullanıcının yetkili olduğu parçalar üzerinde çalışır.
• Yetkisiz içerik modele hiç gitmez.
• Rol değişimi ve ayrılma anında etkili olur.

İstisnai erişim ihtiyacı olan durumlar için — acil müdahale, denetim — break-glass erişim tanımlanır: geçici, gerekçeli ve mutlaka kayıt altında.

Denetim izinde ne tutulur?

"Veri kurum dışına çıkmadı" ifadesi, gösterilemiyorsa bir iddiadır. Denetim izinde en az şunlar bulunmalıdır:

Buna bir de durdurma yeteneği eklenir: bir yeteneğin beklenmedik davrandığı fark edildiğinde onu anında devre dışı bırakan kill switch, üretime alma ön koşuludur.

"Kapalı modeller zayıf değil mi?"

En sık gelen itiraz bu. İki gözlemimiz var: aradaki fark hızla kapanıyor ve birçok kurumsal senaryoda kapalı modeller yeterli ölçülüyor. Buradaki anahtar kelime "ölçülüyor" — karar, genel kanıyla değil, sizin senaryonuzda yapılan karşılaştırmalı ölçümle verilir.

Ölçümün nasıl yapıldığı önemlidir: kurumun gerçek sorularından bir değerlendirme seti hazırlanır, aynı sorular hem bulut hem kurum içi modelle çalıştırılır ve sonuçlar kabul kriterine göre karşılaştırılır. Bu çalışma tipik olarak fizibilite fazına sığar ve tartışmayı kanaat düzeyinden çıkarır.

Yaygın bir bulgu şudur: dar tanımlı kurumsal görevlerde — sınıflandırma, özet, belgeye dayalı soru cevaplama — aradaki fark, senaryoyu değiştirmeyecek kadar küçük olabilir. Fark, açık uçlu yaratıcı görevlerde ve uzun akıl yürütme zincirlerinde büyür.

Donanım: ne kadar gerekir?

İkinci itiraz donanım maliyetidir: her iş için dev GPU kümesi gerekmez. İlkemiz **"en büyük model" değil "işi gören en verimli model"**dir; donanım ihtiyacı senaryo bazlı boyutlandırılır ve fizibilite fazında işletme maliyetiyle birlikte şeffaf hesaplanır.

Boyutlandırmayı belirleyen dört değişken:

1. Eşzamanlı kullanıcı sayısı — donanımı en çok bu belirler, toplam kullanıcı sayısı değil.
2. Model boyutu — göreve göre seçilir; ince ayarlanmış küçük bir model çoğu dar görevde büyük modelin yerini tutar.
3. Bağlam uzunluğu — uzun belge parçaları bellek ihtiyacını doğrudan artırır.
4. Gecikme beklentisi — "anında" ile "birkaç saniye" arasındaki fark, donanım bütçesinde ciddi fark üretir.

Maliyet kalemlerinin tamamını yapay zekâ projesi maliyeti yazımızda ele aldık.

Kurulum nasıl ilerliyor?

Sürecin başarı ölçütleri de baştan yazılıdır: AI trafiğinin tamamının kurumsal sınır içinde kalması, hukuk/güvenlik onayının alınmış olması ve hedef senaryonun kapalı altyapıda tanımlı performansla çalışması.

On-premise ne zaman yanlış karardır?

Dürüst bir rehber, aracın sınırını da söyler. Kurum içi kurulum şu üç durumda yanlış karardır:

1. Kullanım hacmi düşükse. Başlangıç yatırımının amorti olması hacme bağlıdır; günde birkaç yüz istek için kurulan bir küme, kullanılmayan bir yatırımdır.
2. Senaryo kişisel veri içermiyorsa. Hukuki zorunluluk yokken katlanılan işletme yükü, karşılığı olmayan bir maliyettir.
3. İşletme kapasitesi yoksa. Model güncellemesi, izleme, yedeklilik ve olay müdahalesi süreklilik ister. Sahibi olmayan altyapı, altı ayda bakımsız kalır.

Bu üç durumda doğru cevap genellikle yönetilen özel bulut ya da hibrit yönlendirmedir.

Toparlarken

KVKK'ya uygun yapay zekâ mümkün — ama bir ürün özelliği olarak değil, mimari karar olarak. Verinin nerede işlendiğini, kime maskelendiğini ve nasıl denetlendiğini tasarlayan kurum, "AI mı, gizlilik mi" ikilemini sorudan çıkarmış olur.

Kararın otomatikleşmemesi gereken noktalardaki tasarım ilkesini insan onaylı yapay zekâ yazımızda, kurum bilgisiyle çalışan asistan mimarisini ise RAG yazımızda ele aldık.

On-premise AI hizmetimizi inceleyin