Makine Öğrenimi Modellerinde Veri Güvenliği ve Yerellik

Bir makine öğrenmesi projesinde en değerli varlık çoğu zaman model değil, modeli mümkün kılan veridir. On yıllık yazılım, veri altyapısı ve güvenli sistem tasarımı deneyimimde gördüğüm en yaygın hata, güvenliği yalnızca eğitim veri setini şifrelemek olarak düşünmektir. Oysa feature store, embedding, model checkpoint, log, inference girdisi, yedek ve hatta model ağırlıkları aynı güvenlik zincirinin parçalarıdır. Makine Öğrenimi Modellerinde Veri Güvenliği ve Yerellik konusu bu nedenle yalnızca sunucunun hangi ülkede bulunduğuyla açıklanamaz. Bu rehberde makine öğrenmesi modellerinde veri güvenliği nasıl sağlanır, yapay zeka ve makine öğrenmesinde veri yerelliği nedir, KVKK açısından veri akışı nasıl düşünülmelidir ve on-premise, bulut, edge ile hibrit mimariler nasıl değerlendirilmelidir sorularını uygulamaya dönük bir bakışla ele alacağız.

Özellikle kurumsal projelerde verinin nerede saklandığını bilmek başlangıçtır, son nokta değildir. Verinin hangi ülkede işlendiği, hangi alt hizmet sağlayıcılardan geçtiği, şifreleme anahtarını kimin yönettiği ve operasyon ekibinin veriye erişip erişemediği ayrıca sorulmalıdır. Makine öğrenmesi sistemlerinde KVKK uyumlu veri saklama ve işleme yöntemleri tasarlanırken storage, training, inference, logging, backup ve support süreçlerinin tamamı tek veri akışı üzerinde görülmelidir. On-premise ve bulut makine öğrenmesi modellerinde veri güvenliği karşılaştırması da yalnızca “kurum içi daha güvenlidir” veya “bulut daha güvenlidir” gibi kısa hükümlerle yapılamaz. Doğru mimari veri sınıfı, hukuki gereksinim, saldırı modeli, kurumun operasyon kapasitesi, maliyet ve performans beklentisinin birlikte değerlendirilmesiyle ortaya çıkar.

Makine Öğreniminde Veri Güvenliği ve Yerellik Nedir?

Makine öğreniminde veri güvenliği, verinin yaşam döngüsü boyunca yetkisiz erişime, değişikliğe, kayba ve gereksiz kullanıma karşı korunmasını kapsar. Veri yerelliği ise verinin ve kimi durumlarda veri işlemenin belirli bir coğrafi veya operasyonel sınır içinde tutulmasıyla ilgilidir. Bu iki kavram birbirini destekleyebilir, fakat birbirinin yerine kullanılamaz. Aynı ülkede bulunan kötü yapılandırılmış bir storage hizmeti güvenli olmayabileceği gibi başka bir bölgede çalışan güçlü güvenlik kontrollerine sahip bir sistem de hukuki aktarım gereksinimleri doğurabilir. Sağlıklı başlangıç, verinin fiziksel konumu ile erişim, işleme, anahtar kontrolü ve tabi olunan hukuk gibi katmanları ayrı ayrı haritalamaktır.

ML Sistemlerinde Veri Güvenliği Neden Kritik?

Makine öğrenmesi sistemleri klasik uygulamalardan farklı olarak aynı veriyi eğitim, değerlendirme, feature üretimi ve inference gibi birçok aşamada tekrar kullanabilir. Tek bir kişisel kayıt training pipeline'a girdiğinde geçici dosyalarda, cache alanlarında, checkpoint'lerde ve loglarda kopyaları oluşabilir. Bir veri ihlali yalnızca veritabanını değil modelin kendisini de etkileyebilir, çünkü belirli modeller eğitim örneklerini kısmen ezberleyebilir. Veri bütünlüğü bozulduğunda ise saldırgan modeli yanlış davranacak biçimde yönlendirebilir veya belirli örneklere arka kapı yerleştirebilir. Bu nedenle ML güvenliği confidentiality kadar integrity, model provenance, supply chain, erişilebilirlik ve güvenli silme süreçlerini de kapsamalıdır.

Veri Yerelliği Nedir?

Veri yerelliği, verinin belirlenen lokasyon veya altyapı sınırı içinde tutulması ve çoğu projede işleme akışının da bu sınırlarla uyumlu tasarlanması yaklaşımıdır. Örneğin şirket, müşteri verisinin yalnızca Türkiye'deki veri merkezlerinde saklanmasını bir iç politika olarak belirleyebilir. Fakat storage Türkiye'de olsa bile embedding API başka ülkede çalışıyorsa veri işlem sırasında dışarı çıkabilir. Aynı durum merkezi loglama, yedekleme veya uzaktan teknik destek süreçlerinde de yaşanabilir. Bu nedenle gerçek yerellik kontrolü yalnızca database lokasyonunu değil uçtan uca data flow haritasını incelemeyi gerektirir.

Data Residency Nedir?

Data residency, verinin hangi coğrafi bölgede veya ülkede saklandığını ifade etmek için kullanılan bir kavramdır. Bir cloud servisi “Türkiye region” veya belirli Avrupa bölgelerinde storage sunuyorsa residency tercihi bu lokasyonu işaret edebilir. Ancak aynı sağlayıcının backup, telemetry veya support sistemleri farklı coğrafyalarda bulunabilir. Residency taahhüdünün hangi veri kategorilerini kapsadığı sözleşme ve teknik dokümanlardan doğrulanmalıdır. ML projelerinde training dataset, checkpoint, feature store, embeddings, logs ve backups için ayrı residency soruları sormak bu nedenle önemlidir.

Data Localization Nedir?

Data localization belirli veri kategorilerinin belirli ülke veya bölge sınırları içinde tutulmasını ya da işlenmesini gerektiren politika veya hukuki zorunlulukları ifade edebilir. Bu kavram data residency'den daha kural odaklı kullanılabilir. Bir kurum gönüllü olarak residency seçerken localization bazı durumlarda düzenleyici gereksinimden kaynaklanabilir. Makine öğrenmesi mimarisinde localization şartı varsa yalnızca storage değil dış API, support ve disaster recovery bağlantıları da gözden geçirilmelidir. Böyle bir projede architecture kararı model kalitesinden önce veri akışının izin verilen sınırlar içinde kalıp kalmadığıyla başlamalıdır.

Data Sovereignty Nedir?

Data sovereignty, verinin yalnızca bulunduğu fiziksel lokasyonu değil, hangi hukuki ve operasyonel kontrol alanına tabi olduğunu da kapsar. Bir veri merkezi Türkiye'de olsa bile hizmeti yöneten kuruluşun hukuki yapısı, yönetici erişimi veya anahtar kontrolü egemenlik değerlendirmesinde önemli olabilir. Veri egemenliği ayrıca kurumun hizmet sağlayıcıdan bağımsız olarak verisine erişebilmesini, silebilmesini ve başka platforma taşıyabilmesini de içerir. Bu nedenle teknik egemenlik, hukuki egemenlik ve operasyonel egemenlik birlikte düşünülmelidir. Makine öğrenmesi projelerinde model artifact'larının, veri setlerinin ve encryption key'lerin kontrolü bu tartışmanın doğrudan parçasıdır.

Bu Kavramlar Arasındaki Temel Farklar

Data residency daha çok verinin fiziksel veya mantıksal olarak nerede tutulduğunu anlatırken data localization bu konuma ilişkin zorunlulukları ifade edebilir. Data sovereignty ise verinin hangi hukuk, kurum ve yönetim kontrolü altında olduğunu daha geniş biçimde ele alır. Aynı proje üç kavramın tamamıyla ilgili gereksinim taşıyabilir. Örneğin veri Türkiye'de saklanabilir, Türkiye dışına çıkarılmaması politikası uygulanabilir ve encryption key yalnızca kurum tarafından yönetilebilir. Mimari tasarımda bu kavramları tek “veri Türkiye'de” kutucuğuna indirgemek yerine her biri için ayrı teknik ve hukuki doğrulama yapmak gerekir.

Verinin nerede saklandığı

İlk soru training dataset, feature store ve üretim verisinin fiziksel veya mantıksal olarak hangi bölgede saklandığıdır. Cloud region seçimi bu konuda başlangıç bilgisi verir. Ancak snapshot, archive ve yedeklerin farklı bölgelerde tutulup tutulmadığı da kontrol edilmelidir. Object storage ile database'in aynı residency politikasına tabi olduğu varsayılmamalıdır. Veri haritasında her storage bileşeni için ana lokasyon, replica lokasyonu ve disaster recovery lokasyonu ayrı kaydedilmelidir.

Verinin nerede işlendiği

Storage lokasyonu ile processing lokasyonu aynı olmayabilir. Bir dosya Türkiye'de saklanırken embedding üretimi başka ülkedeki API üzerinde gerçekleştirilebilir. Inference isteği global load balancer üzerinden farklı GPU region'a yönlendirilebilir. Data preprocessing veya support amaçlı batch işlemler de başka bölgelerde çalışabilir. Bu nedenle makine öğrenmesi veri yerelliği denetiminde CPU, GPU, serverless job ve dış API yürütme lokasyonları ayrıca doğrulanmalıdır.

Veriye kimin erişebildiği

Fiziksel lokasyon güvenliğin sadece bir parçasıdır. Platform administrator, support çalışanı, data engineer ve üçüncü taraf işlemcilerin erişim yetkileri incelenmelidir. En az yetki, MFA, JIT privileged access ve ayrılmış görevler bu noktada önem kazanır. Support erişiminin varsayılan olarak açık olması yerine olay bazlı ve süreli olması daha güvenli bir modeldir. Audit log, veriye kim tarafından hangi tarihte erişildiğinin geriye dönük doğrulanmasını sağlamalıdır.

Verinin hangi hukuka tabi olduğu

Veri fiziksel olarak bir ülkede bulunurken sağlayıcının hukuki merkezi başka ülkede olabilir. Bu durum tek başına otomatik bir ihlal anlamına gelmez, ancak hukuki yetki ve veri erişimi risk analizinde değerlendirilmelidir. Çok uluslu hizmetlerde alt veri işleyenlerin bulunduğu ülkeler de dikkate alınmalıdır. Sözleşmeler, veri işleme ekleri ve yurt dışı aktarım mekanizmaları teknik mimariyle birlikte incelenmelidir. Hukuki yorum gereken projelerde kurumun hukuk ve kişisel veri uzmanları teknik ekiple birlikte çalışmalıdır.

Şifreleme anahtarını kimin kontrol ettiği

Verinin şifreli olması önemli bir kontroldür, fakat anahtarın kimde olduğu en az şifreleme kadar önemlidir. Provider-managed key modelinde sağlayıcı anahtar yaşam döngüsünün önemli bölümünü yönetir. Customer-managed, BYOK veya daha sıkı modeller kuruma daha fazla kontrol sağlayabilir. Anahtar iptal edildiğinde sağlayıcının veriye erişiminin gerçekten kesilip kesilmediği architecture seviyesinde değerlendirilmelidir. Veri egemenliği gereksinimi yüksek projelerde key ownership çoğu zaman temel karar kriterlerinden biridir.

Makine Öğrenimi Sistemlerinde Hangi Veriler Korunmalıdır?

Makine öğrenmesi güvenliğinde sadece ham veri setini korumak yeterli değildir. Eğitim sırasında üretilen feature'lar, embedding'ler, model checkpoint'leri ve gradient'ler hassas bilgi taşıyabilir. Inference sırasında gelen kullanıcı girdileri ile üretilen sonuçlar da kişisel veya ticari veri içerebilir. Log, telemetry ve backup sistemleri asıl production database'den daha uzun süre veri sakladığı için ayrıca risk oluşturabilir. Bu yüzden koruma kapsamı “dataset” yerine veri yaşam döngüsünde oluşan bütün artifact'ları içermelidir.

Ham Training Data

Ham training data çoğu zaman en hassas veri katmanıdır, çünkü henüz minimizasyon veya anonimleştirme işleminden geçmemiş olabilir. Kişisel bilgiler, müşteri kayıtları, finansal veriler veya ticari sır niteliğindeki içerikler burada bulunabilir. Dataset erişimi sadece gerçekten ihtiyacı olan data engineering ve ML rollerine verilmelidir. Kopyaların notebook cihazlarına veya kişisel depolara dağılması engellenmelidir. Training tamamlandıktan sonra ham verinin ne kadar süre saklanacağı veri sınıfına ve işleme amacına göre açık policy ile belirlenmelidir.

Validation ve Test Data

Validation ve test setlerinin production verisi kadar korunması gerektiği sık unutulur. Bu setler de ham kaynaktan türetildiği için kişisel veya ticari bilgi taşıyabilir. Test verisinin geliştirici bilgisayarlarına geniş biçimde dağıtılması veri sızıntısı riskini artırır. Mümkün olduğunda sentetik veya minimize edilmiş test veri setleri tercih edilmelidir. Model performansı için gerçek veriye ihtiyaç varsa aynı erişim, şifreleme ve retention kontrolleri bu setlere de uygulanmalıdır.

Feature Store

Feature store model için hazırlanmış özellikleri merkezi biçimde tutabilir ve bu özellikler doğrudan kişisel veriden türetilebilir. Yaş, davranış puanı, lokasyon alışkanlığı veya risk skoru gibi alanlar ham değerden daha hassas hâle gelebilir. Online feature store inference sırasında düşük gecikmeyle erişildiği için geniş network erişimine sahip olmamalıdır. Offline ve online store arasındaki senkronizasyon da veri egress açısından kontrol edilmelidir. Feature lineage sayesinde hangi özelliğin hangi kaynaktan üretildiği ve hangi modelde kullanıldığı izlenebilmelidir.

Embeddings

Embedding'ler okunabilir düz metin değildir, ancak otomatik olarak anonim veya risksiz kabul edilmemelidir. Belirli saldırılar veya benzerlik sorguları embedding üzerinden orijinal veri hakkında çıkarım sağlayabilir. Kişisel veya gizli dokümandan üretilen embedding bu nedenle aynı erişim alanında korunmalıdır. Embedding üretimi harici API üzerinden yapılıyorsa kaynak metnin hangi bölgeye gönderildiği ayrıca kontrol edilmelidir. RAG mimarilerinde document store, embedding pipeline ve vector database aynı veri güvenliği planının parçaları olmalıdır.

Vector Database

Vector database embedding'leri, metadata'yı ve bazı mimarilerde ham chunk içeriğini tutabilir. Bu nedenle sadece performans bileşeni olarak değil veri deposu olarak ele alınmalıdır. Collection veya tenant seviyesinde erişim kontrolü uygulanmalıdır. Backup ve replica lokasyonları data residency politikasına uymalıdır. RAG güvenliği hakkında daha ayrıntılı teknik mimari için https://www.diyarbakiryazilim.com.tr/posts/yapay-zeka-projelerinde-rag-retrieval-augmented-generation-mimarisi adresindeki rehber de tamamlayıcı bir kaynak olarak kullanılabilir.

Model Weights

Model ağırlıkları şirketin fikri mülkiyeti olabileceği gibi eğitim verisi hakkında dolaylı bilgi de taşıyabilir. Özellikle hassas veri üzerinde fine-tune edilen modelin public artifact store'a yüklenmesi ciddi risk oluşturabilir. Model registry erişimi role-based olmalı ve artifact download işlemleri audit edilmelidir. Weight dosyaları imzalanarak hangi build sürecinden geldikleri doğrulanabilir. Modelin dışarı sızması yalnızca IP kaybına değil extraction ve membership inference gibi saldırı yüzeylerinin büyümesine de yol açabilir.

Model Checkpoints

Checkpoint'ler eğitim sırasında model durumunu belirli aralıklarla kaydeder. Production model kadar güvenli tutulmaları gerekir, çünkü benzer veri izleri ve fikri mülkiyet içerirler. Geçici checkpoint'lerin yıllarca object storage içinde unutulması gereksiz risk yaratır. Retention süresi training tamamlandıktan sonra otomatik temizlenecek şekilde tanımlanabilir. Disaster recovery için gereken az sayıdaki checkpoint şifreli, erişimi sınırlı ve doğrulanabilir biçimde saklanmalıdır.

Gradients ve Model Updates

Gradient ve federated model update'leri ham verinin kendisi değildir, fakat hassas örnekler hakkında bilgi sızdırabilir. Gradient inversion ve reconstruction saldırıları bunun neden güvenlik kapsamına alınması gerektiğini gösterir. Merkezi federated server'ın tekil update'leri görmesi mümkünse risk büyür. Secure aggregation ve differential privacy gibi teknikler bu tehdidi azaltmak için birlikte kullanılabilir. Debug amacıyla gradient dump alınması gerekiyorsa production data üzerinde gereksiz kalıcı log oluşturulmamalıdır.

Inference Input

Inference input gerçek kullanıcı tarafından sağlandığı için production sisteminin en hassas veri akışlarından biridir. Kullanıcı bir tahmin API'sine kişisel, finansal veya şirket içi bilgi gönderebilir. Input'un model provider, feature service ve logging altyapısı boyunca nasıl hareket ettiği açıkça bilinmelidir. Gerekli olmayan alanlar model çağrısından önce çıkarılmalıdır. API gateway, PII redaction ve schema validation gibi kontroller inference verisinin gereksiz yere çoğalmasını önleyebilir.

Model Output

Model output da korunması gereken veri olabilir. Sağlık tahmini, kredi riski veya kullanıcı profili gibi sonuçlar kişinin kendisi hakkında hassas çıkarım oluşturabilir. Output loglanıyor veya analitik platformuna gönderiliyorsa yeni bir veri işleme faaliyeti doğabilir. Yetkisiz kullanıcıların başkasına ait tahmin sonucunu görmesi engellenmelidir. Automated decision süreçlerinde output'un nasıl kullanıldığı, insan kontrolü bulunup bulunmadığı ve sonuç saklama süresi açık biçimde yönetilmelidir.

Log ve Telemetry Verileri

Loglar çoğu projede fark edilmeden ikinci bir veri deposuna dönüşür. Request body, kullanıcı ID, feature değeri veya exception dump içinde kişisel veri bulunabilir. Debug log seviyesini production'da sürekli açık tutmak gereksiz veri kopyaları oluşturur. Log toplama platformunun region ve retention politikası asıl ML servisinden ayrı kontrol edilmelidir. Mümkün olduğunda identifier'lar pseudonymize edilmeli ve hassas field'lar loglama öncesinde maskelenmelidir.

Backup ve Disaster Recovery Kopyaları

Backup verileri production sistemden daha uzun süre saklanabildiği için veri yerelliği açısından özel önem taşır. Ana database Türkiye'de olsa bile snapshot başka region'a kopyalanıyorsa gerçek data flow bundan etkilenir. Backup encryption key lokasyonu ve erişim yetkileri ayrıca değerlendirilmelidir. Silme talebi geldiğinde immutable backup içindeki veri için uygulanacak yaşam döngüsü politikası önceden belirlenmelidir. Disaster recovery testi de yalnızca sistemin geri gelmesini değil doğru region ve erişim politikalarının restore edilmesini doğrulamalıdır.

ML Veri Güvenliğinde CIA Üçlüsü

CIA modeli confidentiality, integrity ve availability kavramlarını birlikte ele alır ve ML güvenliği için güçlü bir başlangıç çerçevesi sunar. Confidentiality yetkisiz kişinin veriyi görmesini engellerken integrity veri, model ve pipeline'ın izinsiz değişmemesini hedefler. Availability ise servis ve kritik verilerin ihtiyaç duyulduğunda erişilebilir olmasını sağlar. ML projelerinde üç alan birbirine sıkıca bağlıdır, çünkü veri poisoning integrity problemini model davranışına taşıyabilir veya ransomware availability kaybıyla birlikte training artifact'larını etkileyebilir. Bu nedenle güvenlik planı sadece şifrelemeye değil tüm CIA hedeflerine göre hazırlanmalıdır.

Confidentiality

Confidentiality, training verisi ve model artifact'larının yalnızca yetkili taraflarca görülebilmesini sağlar. Encryption, RBAC, private networking ve secret management temel kontroller arasındadır. ML projelerinde embedding, checkpoint ve log gibi ikincil artifact'ların da confidential kabul edilmesi gerekir. Cloud support veya administrator erişimi için JIT yetkilendirme kullanılabilir. Confidentiality kontrolünün başarısı yalnızca erişim listesiyle değil gerçek audit log ve yetkisiz erişim testleriyle doğrulanmalıdır.

Integrity

Integrity, verinin ve model artifact'larının beklenmedik biçimde değiştirilmediğinden emin olmayı hedefler. Dataset poisoning, dependency manipülasyonu veya model registry'ye zararlı artifact yüklenmesi bu alanın tehditleridir. Dataset hash, artifact signing ve immutable lineage kayıtları değişiklikleri izlemeye yardımcı olur. CI/CD pipeline production modeli yalnızca doğrulanmış build'den dağıtmalıdır. Training verisindeki küçük fakat hedefli değişikliklerin bile model kararlarını bozabileceği unutulmamalıdır.

Availability

Availability, model servisinin ve supporting infrastructure'ın ihtiyaç anında kullanılabilir olmasını sağlar. GPU kapasitesi, feature store, model registry ve network bağlantısı aynı hizmet zincirinin parçalarıdır. DDoS, cloud region kesintisi veya disk kaybı inference hizmetini durdurabilir. Yedek, replica ve disaster recovery planı iş SLA'ına göre belirlenmelidir. Çok yüksek availability hedefi maliyeti artırdığı için kritik model servisleri ile deneysel sistemlerin hedefleri birbirinden ayrılmalıdır.

ML Sistemlerinde CIA Modelinin Özel Riskleri

ML sistemlerinde confidentiality kaybı yalnızca dosya sızıntısıyla değil model sorguları üzerinden de yaşanabilir. Integrity problemi training data poisoning sayesinde modelin yalnızca belirli girdilerde yanlış davranmasına neden olabilir. Availability ise yüksek GPU maliyeti nedeniyle basit resource exhaustion saldırılarından bile etkilenebilir. Bu sebeple klasik CIA kontrollerine model extraction, membership inference, adversarial abuse ve supply chain testleri eklenmelidir. Threat model normal web uygulaması güvenliği ile ML'e özgü saldırı senaryolarını aynı değerlendirme içinde birleştirmelidir.

Makine Öğrenimi Veri Yaşam Döngüsünde Güvenlik

Veri güvenliği yalnızca production deployment sırasında başlayan bir süreç değildir. Veri ilk toplandığı andan silindiği veya anonimleştirildiği ana kadar farklı riskler taşır. Her aşamanın ayrı owner, erişim politikası, retention süresi ve lineage kaydı bulunmalıdır. Training pipeline geliştirme ortamında başlayıp production'a geçtiğinde güvenlik politikasının zayıflamaması gerekir. Yaşam döngüsü yaklaşımı özellikle makine öğrenmesi sistemlerinde KVKK uyumlu veri saklama ve işleme yöntemleri tasarlamak için pratik bir temel sağlar.

Veri Toplama

Veri toplama aşamasında ilk soru gerçekten hangi alanlara ihtiyaç olduğudur. İleride lazım olabilir düşüncesiyle gereksiz kişisel veri toplamak hem riski hem operasyon yükünü artırır. Kaynağın hukuki dayanağı ve izin verilen kullanım amacı kayıt altına alınmalıdır. Dataset provenance bilgisi daha sonra model lineage ile ilişkilendirilmelidir. Veri kalitesi kontrolü yapılırken hassas alanların debug ortamlarına kopyalanmaması gerekir.

Veri Transferi

Veri sistemler arasında aktarılırken TLS veya private networking kullanılmalıdır. Dosyayı manuel e-posta veya kişisel dosya paylaşımıyla taşıma gibi yöntemlerden kaçınılmalıdır. Transfer endpoint'i hangi region'a ve hangi işleyene veri gönderdiği açısından kontrol edilmelidir. Büyük batch transferlerde checksum bütünlüğü doğrulamak için kullanılabilir. Egress monitoring, beklenmedik dış hedeflere yapılan veri hareketini tespit etmeye yardımcı olur.

Veri Depolama

Storage katmanında encryption at rest, access control ve region policy temel kontrollerdir. Bucket veya database'in public erişime yanlışlıkla açılması ciddi risk yaratır. Object storage policy sadece belirli workload identity'lerine izin vermelidir. Retention ve lifecycle kuralları eski dataset kopyalarını otomatik temizleyebilir. Backup lokasyonu ana storage politikasıyla birlikte değerlendirilmelidir.

Veri Temizleme ve Etiketleme

Data labeling süreci verinin üçüncü taraf çalışanlar tarafından görülmesine neden olabilir. Hassas veri mümkün olduğunda maskelenmeli veya görev için gereksiz alanlar çıkarılmalıdır. Labeling platformunun veri lokasyonu ve alt işleyenleri incelenmelidir. Annotator kullanıcıları sadece atandıkları veri parçasına erişmelidir. Export edilen etiket dosyaları da asıl dataset ile aynı güvenlik sınıfında tutulmalıdır.

Feature Engineering

Feature engineering ham veriyi yeni özniteliklere dönüştürür ve bazen hassasiyet seviyesini artırabilir. Bir kişinin davranışlarından üretilen risk skoru doğrudan hassas profile dönüşebilir. Feature pipeline version control altında tutulmalı ve hangi kaynaktan hangi feature'ın üretildiği lineage içinde gösterilmelidir. Geçici notebook output'ları production veri kopyası hâline gelmemelidir. Feature store erişimi model servisleri ile data engineering rolleri arasında açıkça sınırlandırılmalıdır.

Model Training

Training sırasında GPU worker'ların veriye hangi kimlikle eriştiği kontrol edilmelidir. Dataset'in local scratch disk'e kopyalanıp işlem sonunda temizlenmediği mimariye göre doğrulanmalıdır. Distributed training yapılıyorsa node'lar arası trafik şifrelenebilir. Training job yalnızca ihtiyaç duyduğu bucket ve model registry alanına erişmelidir. Experiment çıktıları ve checkpoint'ler otomatik olarak doğru güvenlik sınıfındaki storage'a yazılmalıdır.

Fine-Tuning

Fine-tuning çoğu zaman şirketin en değerli iç verisini genel amaçlı modele yaklaştırdığı aşamadır. Bu nedenle base model provenance ile fine-tuning dataset güvenliği birlikte değerlendirilmelidir. Harici API üzerinden fine-tuning yapılıyorsa provider'ın veriyi nerede işlediği ve ne kadar süre tuttuğu kontrol edilmelidir. Fine-tuned weight dosyasının sızıntı testleri yapılabilir. Fine-tuning tamamlandıktan sonra geçici upload kopyalarının sağlayıcı tarafında silinme süreci doğrulanmalıdır.

Evaluation

Evaluation dataset'i çoğu ekipte production kadar iyi korunmaz, ancak kişisel veri içerebilir. Benchmark için gerçek müşteri örnekleri kullanılacaksa minimizasyon yapılmalıdır. Model çıktıları insan değerlendiriciye gönderiliyorsa bu yeni erişim noktasıdır. Evaluation platformu ve export edilen sonuçlar için retention belirlenmelidir. Regression dataset mümkünse anonim veya sentetik örneklerle zenginleştirilerek gerçek veriye bağımlılık azaltılmalıdır.

Deployment

Model deployment sırasında artifact'ın doğru ve onaylı sürüm olduğu doğrulanmalıdır. Model hash veya dijital imza supply chain bütünlüğü sağlayabilir. Production runtime yalnızca model registry'den imzalı artifact çekebilir. Deployment identity'sinin training data'ya erişmesi çoğu zaman gerekli değildir. Network policy inference servisinin sadece ihtiyaç duyduğu feature ve logging sistemlerine bağlanmasına izin vermelidir.

Inference

Inference production kullanıcı verisinin gerçek zamanlı işlendiği aşamadır. Input validation, authentication ve authorization klasik API güvenliği kadar önemlidir. Model provider'a gönderilen payload yalnızca gerekli feature'ları içermelidir. Logging katmanı ham input'u default olarak saklamamalıdır. Inference execution lokasyonu data residency politikasının gerçekten uygulanıp uygulanmadığını belirleyen kritik kontroldür.

Monitoring

Monitoring için veri toplamak güvenliğin parçasıdır, fakat gereğinden fazla telemetry yeni risk yaratır. Model drift için gerekli metrikler mümkün olduğunda kişisel identifier olmadan hesaplanmalıdır. Ham prompt veya prediction değerlerinin sürekli loglanması yerine aggregate metric kullanılabilir. Monitoring platformu farklı region'daysa veri aktarım haritasına dahil edilmelidir. Security ve privacy alarmı sadece infrastructure hatalarını değil beklenmeyen egress ve access olaylarını da izlemelidir.

Veri ve Model Silme

Veri silme işlemi database satırını kaldırmaktan daha kapsamlı olabilir. Aynı kayıt backup, feature store, vector database, cache ve training dataset içinde bulunabilir. Veri model eğitiminde kullanıldıysa machine unlearning veya retraining gereksinimi ayrıca değerlendirilmelidir. Silme talebinin hangi sistemlere yayıldığını gösteren orchestration süreci oluşturulabilir. Model ve veri artifact'larının lifecycle policy'si hem hukuki gereksinime hem iş amacına göre belirlenmelidir.

Veriyi Sınıflandırmadan Güvenlik Mimarisi Kurulabilir mi?

Veri sınıflandırması olmadan güvenlik mimarisi genellikle ya gereğinden pahalı ya da gereğinden zayıf olur. Her veriye en yüksek güvenlik seviyesini uygulamak operasyonu zorlaştırırken bütün veriyi aynı düşük seviyede değerlendirmek kritik risk yaratır. Public, internal, confidential, kişisel ve özel nitelikli kişisel veri gibi sınıflar teknik policy ile ilişkilendirilebilir. Her sınıf için izin verilen storage region, model provider, retention ve erişim rolleri tanımlanmalıdır. Böylece güvenlik kararları proje ekiplerinin kişisel yorumuna bırakılmadan otomatik policy hâline getirilebilir.

Public Data

Public data kamuya açık ve paylaşımı kurum açısından kısıtlı olmayan içeriktir. Buna rağmen kaynağın lisans ve kullanım koşulları gözden geçirilmelidir. Public dataset supply chain saldırısı veya poisoning açısından yine doğrulanmalıdır. Model training için kullanılan public verinin provenance kaydı tutulmalıdır. Public olması integrity ve kalite kontrollerinin gereksiz olduğu anlamına gelmez.

Internal Data

Internal data kurum dışına açıklanması amaçlanmayan fakat en yüksek gizlilik seviyesinde olmayan veridir. İç süreç dokümanları veya genel operasyon metrikleri bu sınıfa girebilir. External model API kullanımına kurum politikası izin vermeyebilir. Access çalışan rolüyle sınırlandırılmalıdır. Dataset dışarı export edildiğinde otomatik data loss prevention kontrolü uygulanabilir.

Confidential Data

Confidential data ticari veya operasyonel açıdan önemli ve sınırlı erişim gerektiren bilgidir. Müşteri segmentleri, fiyatlandırma stratejileri veya henüz açıklanmamış ürün planları buna örnek olabilir. Bu veri üzerinde çalışan ML job'ları private network ve güçlü encryption kullanmalıdır. Harici API kullanımı açık güvenlik onayına bağlanabilir. Model çıktılarının confidential bilgiyi dolaylı biçimde ifşa edip etmediği red team testleriyle kontrol edilmelidir.

Kişisel Veri

Kişisel veri belirli veya belirlenebilir gerçek kişiyle ilişkili bilgi olarak değerlendirilir. ML sistemleri doğrudan isim taşımayan davranış verilerini de kişiyle ilişkilendirilebilir hâle getirebilir. Bu nedenle pseudonymized identifier otomatik olarak kişisel veri kapsamı dışına çıkmış sayılmamalıdır. İşleme amacı, hukuki dayanak, minimizasyon ve saklama süresi belirlenmelidir. Model lineage kaydı hangi kişisel veri setinin hangi model sürümünde kullanıldığını gösterebilmelidir.

Özel Nitelikli Kişisel Veri

Özel nitelikli kişisel veri çok daha sıkı koruma gerektiren veri kategorilerini içerir. Sağlık verisi gibi içerikler ML projelerinde özellikle dikkat gerektirir. Access, audit ve encryption kontrolleri normal kişisel veriden daha güçlü olabilir. External provider kullanımında hukuki ve teknik değerlendirme birlikte yapılmalıdır. Eğitim verisini anonimleştirme veya federated learning gibi teknikler risk azaltabilir, fakat tek başına hukuki uyum garantisi sağlamaz.

Ticari Sır ve Fikri Mülkiyet

Training dataset, model mimarisi ve fine-tuned weight kurumun fikri mülkiyetinin önemli parçaları olabilir. Veri kişisel olmasa bile sızıntısı ciddi ticari zarar yaratabilir. Model registry ve source repository ayrı access policy ile korunmalıdır. Open-source dependency ve pre-trained model lisansları fikri mülkiyet riskine dahil edilmelidir. Vendor exit planı model ve dataset'in başka altyapıya taşınabilmesini güvence altına almalıdır.

Sektörel Olarak Düzenlenen Veriler

Finans, sağlık, telekom ve kamu gibi sektörlerde genel kişisel veri kurallarına ek yükümlülükler bulunabilir. Sektörel düzenleme hangi verinin nerede tutulacağı veya hangi kontrolün uygulanacağı konusunda özel şartlar getirebilir. Makine öğrenmesi projesi başlamadan önce ilgili regülasyon envanteri çıkarılmalıdır. Teknik mimari sadece KVKK üzerinden tasarlanıp sektör düzenlemeleri sonradan eklenmemelidir. Kritik projelerde hukuk, bilgi güvenliği ve ML ekipleri aynı design review sürecine katılmalıdır.

Veri Sınıfına Göre ML Güvenlik Politikası

Veri sınıfı doğrudan deployment ve provider seçimine bağlanabilir. Public data public cloud üzerinde geniş seçeneklerle işlenirken özel nitelikli veriler için on-premise veya daha sıkı sovereign altyapı politikası belirlenebilir. Confidential sınıf external API'ye gönderilemez şeklinde otomatik egress policy uygulanabilir. Encryption key kontrolü de sınıfa göre değiştirilebilir. Böylece güvenlik ilkeleri dokümanda kalmak yerine platform tarafından uygulanabilir kurallara dönüşür.

Merkezi Makine Öğrenimi Mimarilerinin Veri Güvenliği Riskleri

Merkezi ML mimarisi bütün veriyi tek training veya analytics ortamında topladığı için yönetimi kolaylaştırabilir. Ancak aynı merkez saldırgan açısından yüksek değerli hedef hâline gelir. Erişim hatası, insider risk veya cloud configuration problemi çok büyük veri hacmini etkileyebilir. Cross-region replication ve üçüncü taraf hizmetleri merkezi havuzun sanıldığından daha fazla lokasyona yayılmasına neden olabilir. Bu nedenle merkezi mimaride segmentation, least privilege, data minimization ve güçlü audit özel önem taşır.

Büyük Merkezi Veri Havuzları

Merkezi lake veya warehouse bütün kurum verisini tek yerde topladığında analitik ve ML ekipleri için kolaylık sağlar. Ancak yanlış role tanımı binlerce tabloya aynı anda erişim verebilir. Dataset bazlı fine-grained access ve sensitive column masking uygulanmalıdır. Training job yalnızca kullandığı partition veya view'a erişmelidir. Merkezi havuzun büyüklüğü nedeniyle data discovery ve classification otomatik araçlarla desteklenmelidir.

Tek Noktadan Veri İhlali Riski

Tek bir yüksek yetkili credential'ın ele geçirilmesi merkezi sistemde geniş etki yaratabilir. Admin hesabı sürekli aktif tutulmamalı ve JIT erişim tercih edilmelidir. Storage, catalog ve key management ayrı trust boundary olarak tasarlanabilir. Immutable audit log olay sonrası hangi verilere erişildiğini gösterebilir. Kritik dataset'ler farklı encryption key veya project boundary ile ayrılarak ihlal etkisi sınırlandırılabilir.

Yetkisiz İç Kullanıcı Erişimi

Insider risk sadece kötü niyetli çalışan anlamına gelmez. Yanlışlıkla fazla yetki verilen veri bilimci de gereksiz kişisel veriye erişebilir. Separation of duties ve role review bu riski azaltır. Notebook environment içinde data export ve clipboard davranışı bile yüksek güvenlik sınıfında kontrol konusu olabilir. Production dataset'e erişim ihtiyacı süreli ve gerekçeli onayla verilebilir.

Cloud Provider Riskleri

Cloud provider fiziksel altyapı ve yönetim düzleminde belirli kontrol yetkilerine sahiptir. Güvenlik sorumluluğu paylaşıldığı için müşteri tarafındaki IAM ve configuration hataları hâlâ kurum sorumluluğundadır. Provider support erişimi, encryption key modeli ve subprocessor listesi incelenmelidir. Confidential computing belirli data-in-use risklerini azaltabilir. Cloud kullanımı otomatik olarak güvenli veya güvensiz değildir, asıl konu seçilen kontrollerin threat model ile uyumudur.

Cross-Region Replication

High availability için veri farklı region'lara otomatik kopyalanabilir. Bu özellik data residency gereksinimini fark edilmeden ihlal edebilir. Database ve object storage replication policy açıkça belirlenmelidir. Failover region da izin verilen coğrafi sınırlar içinde seçilmelidir. Backup sistemlerinin ayrı replication davranışı ayrıca kontrol edilmelidir.

Third-Party Processor Riskleri

ML platformu tek sağlayıcı gibi görünse de arka planda telemetry, support veya model API hizmetleri için başka işleyenler kullanabilir. Alt veri işleyenlerin kim olduğu ve hangi veri kategorisine eriştiği incelenmelidir. Yeni subprocessor eklendiğinde kurumun nasıl bilgilendirileceği sözleşmede bulunmalıdır. Data flow diagram bu tarafları görünür hâle getirir. External processor kullanımı minimum gerekli veriyle sınırlandırılmalıdır.

Veri Taşıma ve Egress Riskleri

Veri egress yalnızca bilinçli export işlemiyle oluşmaz. Model API çağrısı, debug telemetry veya package download sırasında bile dış bağlantılar kullanılabilir. Egress firewall ve domain allowlist beklenmeyen hedefleri engelleyebilir. DNS ve proxy logları veri hareketinin izlenmesine yardımcı olur. Hassas workload için default deny egress yaklaşımı güçlü bir kontroldür.

ML Sistemlerinde Şifreleme Nasıl Uygulanır?

Şifreleme, verinin rest, transit ve use durumlarının her birinde farklı tekniklerle korunmasını amaçlar. Disk veya object storage encryption yalnızca depolanmış veriyi korurken TLS ağ trafiğini korur. Data in use tarafı daha zordur, çünkü klasik işlem sırasında veri CPU veya GPU belleğinde açık hâle gelir. Confidential computing, trusted execution environment ve homomorphic encryption bu alanı güçlendiren tekniklerdir. İyi mimari sadece algoritma seçmekle kalmaz, anahtar yönetimi, rotation, access ve revocation süreçlerini de tasarlar.

Data at Rest

Data at rest disk, database veya object storage üzerinde kalıcı biçimde bulunan veriyi ifade eder. Storage encryption cihaz veya disk çalınması gibi fiziksel risklere karşı koruma sağlar. Database seviyesinde encryption hassas tablo veya kolonlar için ek kontrol sunabilir. Object storage server-side encryption yaygın kullanılır, fakat key ownership ayrıca değerlendirilmelidir. Backup ve snapshot'ların da aynı veya daha güçlü şifreleme politikasıyla korunması gerekir.

Disk encryption

Disk encryption sunucu veya storage volume üzerindeki veriyi blok seviyesinde şifreler. Fiziksel disk ele geçirilse bile anahtar olmadan içerik okunamaz. Ancak sistem çalışırken yetkili işletim sistemi kullanıcıları dosyalara erişebilir. Bu nedenle disk encryption IAM ve application access control'ün yerine geçmez. On-premise GPU sunucularında boot key ve recovery key yönetimi operasyon planına dahil edilmelidir.

Database encryption

Database encryption transparent encryption veya kolon bazlı encryption gibi yöntemlerle uygulanabilir. Çok hassas alanlarda uygulama seviyesinde şifreleme sağlayıcı operatöründen dahi veriyi gizleyebilir. Bunun karşılığında sorgulama ve index kullanımı zorlaşabilir. Encryption key database ile aynı credential alanında tutulmamalıdır. Key rotation sırasında eski verinin nasıl yeniden şifreleneceği test edilmelidir.

Object storage encryption

Dataset, checkpoint ve model artifact'ları çoğu zaman object storage içinde tutulur. Bucket seviyesinde server-side encryption zorunlu policy hâline getirilebilir. Customer-managed key ile belirli veri sınıfları ayrı anahtarlarla korunabilir. Public ACL veya yanlış signed URL ayarı şifrelemeyi anlamsız hâle getirebilir. Bu nedenle storage encryption, private access policy ve audit logging birlikte uygulanmalıdır.

Data in Transit

Data in transit servisler arasında ağ üzerinden hareket eden veridir. TLS istemci ile API, training worker ile storage veya servisler arası iletişimde kullanılabilir. Private network kullanmak trafik exposure'ını azaltır, fakat şifrelemenin yerini her zaman tutmaz. VPN uzak yönetim veya site-to-site bağlantılar için güvenli tünel sağlayabilir. Certificate management ve mutual TLS yüksek güvenlik gerektiren service-to-service iletişimde ayrıca değerlendirilebilir.

TLS

TLS ağ üzerinden gönderilen veriyi dinlemeye ve değiştirmeye karşı korur. Sertifika doğrulamasının kapatılması test ortamında bile kötü alışkanlık oluşturur. Internal API'ler de hassas veri taşıyorsa TLS kullanmalıdır. Certificate rotation otomatikleştirilmelidir. Eski protokol ve zayıf cipher kullanımı security baseline üzerinden engellenmelidir.

Private network

Private network servislerin genel internet yerine kurumun kontrol ettiği adres alanında iletişim kurmasını sağlar. Storage ve model endpoint'leri private endpoint üzerinden erişilebilir hâle getirilebilir. Public route kapatıldığında yanlış credential sızıntısının etkisi azalır. Network segmentation farklı veri sınıflarını birbirinden ayırabilir. Private network yine de güçlü identity ve TLS kontrolleriyle birlikte kullanılmalıdır.

VPN

VPN uzak kullanıcı veya veri merkezini güvenli network alanına bağlayabilir. ML administrator erişimi doğrudan public SSH yerine VPN üzerinden sağlanabilir. MFA ve cihaz güvenliği VPN kimlik doğrulamasını güçlendirir. Split tunneling politikası hassas veri akışında dikkatle değerlendirilmelidir. VPN logları privileged access audit kayıtlarıyla ilişkilendirilebilir.

Data in Use

Data in use CPU veya GPU tarafından aktif olarak işlenen açık veridir. Klasik encryption at rest bu aşamada koruma sağlamaz. Trusted execution environment memory bölgesini diğer yazılım katmanlarından izole etmeye çalışır. Confidential computing bu hardware destekli izolasyonu cloud veya server altyapısında kullanılabilir hâle getirir. Homomorphic encryption ise bazı hesapların veri hiç çözülmeden yapılmasını sağlar, fakat performans maliyeti daha yüksektir.

Trusted execution environment

TEE işlem sırasında veriyi izole hardware korumalı alanda tutmayı amaçlar. Host işletim sistemi veya hypervisor'ın erişimi belirli threat model içinde kısıtlanabilir. Remote attestation ile workload'un beklenen güvenilir code üzerinde çalıştığı doğrulanabilir. TEE bütün application açığını çözmez ve yanlış kod yine veriyi sızdırabilir. Bu nedenle trusted computing base mümkün olduğunca küçük tutulmalıdır.

Confidential computing

Confidential computing data-in-use korumasını hardware destekli trusted execution ortamlarıyla sağlamayı hedefler. Özellikle cloud operatöründen veya privileged infrastructure katmanından kaynaklanan riskleri azaltmak için değerlidir. Secret'lar yalnızca attestation başarılı olduğunda workload'a verilebilir. GPU destekli confidential seçenekler AI inference ve training senaryolarında giderek önem kazanmıştır. Yine de network, application güvenliği ve model saldırıları ayrıca yönetilmelidir.

Homomorphic encryption

Homomorphic encryption şifreli veri üzerinde belirli matematiksel işlemleri veriyi çözmeden gerçekleştirebilir. Bu özellik çok hassas inference senaryolarında güçlü gizlilik sağlar. Ancak klasik plaintext hesaplamaya göre ciddi performans ve mühendislik maliyeti oluşturabilir. Model mimarisinin desteklenen operasyonlara uyarlanması gerekebilir. Bu nedenle FHE bugün her ML workload için varsayılan seçenek değil, belirli threat model ve yüksek gizlilik ihtiyacında değerlendirilen özel bir tekniktir.

Şifreleme Anahtarlarını Kim Kontrol Etmeli?

Encryption key yönetimi veri egemenliği tartışmasının merkezindedir. Aynı storage hizmeti provider-managed key ile kullanıldığında sağlayıcı anahtar lifecycle'ının büyük bölümünü yönetebilir. Customer-managed modelde kurum key policy, rotation ve revocation üzerinde daha fazla kontrol elde eder. BYOK ve HYOK yaklaşımları kontrol seviyesini daha ileri taşıyabilir. Seçim yapılırken sadece teknik destek değil acil iptal, audit, recovery ve vendor exit süreçleri de değerlendirilmelidir.

Provider-Managed Keys

Provider-managed keys kullanımı kolay ve operasyon maliyeti düşük bir modeldir. Anahtar oluşturma, saklama ve rotation büyük ölçüde hizmet sağlayıcı tarafından yönetilir. Küçük veya düşük hassasiyetli workload için yeterli olabilir. Ancak kurum anahtar üzerinde sınırlı kontrol ve görünürlük elde eder. Yüksek egemenlik gereksiniminde customer-managed veya daha ileri key ownership modelleri değerlendirilmelidir.

Customer-Managed Keys

Customer-managed key modelinde anahtar cloud key management hizmetinde müşteri kontrolündeki policy ile yönetilir. Hangi workload'un anahtarı kullanabileceği IAM ile belirlenebilir. Key disable veya revoke işlemi veri erişimini hızlı şekilde kesebilir. Audit log her anahtar kullanımını gösterebilir. Anahtar kaybının geri dönüşsüz veri kaybına yol açabileceği için backup ve recovery süreci de ciddi biçimde tasarlanmalıdır.

BYOK Nedir?

Bring Your Own Key yaklaşımında kurum kendi ürettiği anahtarı hizmet sağlayıcının key management sistemine getirir. Bu yöntem key generation üzerinde müşteriye daha fazla kontrol sağlar. Ancak anahtar provider altyapısına import edildiği için gerçek ownership ve kullanım modeli dikkatle incelenmelidir. Rotation sürecinde yeni anahtar import ve re-encryption davranışı test edilmelidir. BYOK, key control'ü artırır fakat sağlayıcıdan tamamen bağımsız bir anahtar modeli anlamına gelmez.

HYOK Nedir?

Hold Your Own Key yaklaşımı anahtarın sağlayıcı altyapısından daha bağımsız biçimde kurum kontrolünde tutulmasını hedefler. Bu model veri egemenliği gereksinimi yüksek ortamlarda değerlendirilebilir. Ancak performans, availability ve entegrasyon karmaşası daha yüksektir. Key service ulaşılamazsa workload veriye erişemeyebilir. Bu nedenle HYOK seçimi sadece güvenlik değil operasyonel dayanıklılık ve disaster recovery açısından da test edilmelidir.

Key Rotation

Key rotation eski anahtarın belirlenen sürede yenisiyle değiştirilmesini sağlar. Rotation otomatik veya olay bazlı yapılabilir. Anahtar değişikliğinin mevcut checkpoint, backup ve database üzerindeki etkisi test edilmelidir. Eski key'in ne kadar süre tutulacağı recovery gereksinimine göre belirlenir. Rotation audit logları güvenlik denetiminin parçası olmalıdır.

Key Revocation

Key revocation compromise veya vendor exit durumunda veri erişimini hızla kesmek için güçlü kontroldür. Ancak yanlış key disable production sistemini tamamen kullanılmaz hâle getirebilir. Bu nedenle privileged key işlemleri separation of duties ve MFA ile korunmalıdır. Emergency revocation runbook önceden hazırlanmalıdır. Revocation sonrası hangi replica ve backup'ın erişilebilir kalacağı ayrıca doğrulanmalıdır.

Anahtar Kontrolü Veri Egemenliği İçin Neden Önemlidir?

Veri aynı ülkede saklansa bile provider anahtarı tam kontrol ediyorsa kurumun teknik egemenliği sınırlı olabilir. Key ownership, veriyi kimlerin gerçekten çözebildiği üzerinde doğrudan etkilidir. Customer-managed veya kurum dışı key modeli sağlayıcı operator riskini azaltabilir. Aynı zamanda vendor exit sırasında verinin kullanımını sonlandırma gücü sağlar. Bu nedenle data sovereignty assessment içinde storage region kadar encryption key custody de mutlaka sorulmalıdır.

Confidential Computing Nedir?

Confidential computing, veriyi işlem sırasında korumaya odaklanan hardware destekli güvenlik yaklaşımıdır. Klasik şifreleme disk ve network üzerindeki veriyi korurken uygulama çalışırken veri memory içinde çözülebilir hâle gelir. Confidential workload bu memory alanını host işletim sistemi, hypervisor veya belirli privileged operator katmanlarından izole etmeyi amaçlar. Remote attestation sayesinde secret yalnızca beklenen güvenilir workload'a verilebilir. ML inference ve training için özellikle cloud operator riskinin azaltılması gereken senaryolarda önemli bir araçtır.

Trusted Execution Environment (TEE)

TEE, kod ve verinin izole execution alanında çalışmasını sağlayan hardware destekli mekanizmadır. Normal operating system aynı makinede çalışsa bile protected memory'ye erişim sınırlandırılabilir. Güven sınırı kullanılan CPU ve platform teknolojisine göre değişir. TEE'ye alınan uygulamanın kendi açıkları hâlâ risk oluşturabilir. Bu nedenle küçük trusted computing base ve signed workload kullanmak iyi pratiktir.

Confidential VM

Confidential VM tüm sanal makinenin memory'sini hardware seviyesinde korumayı hedefler. Mevcut ML uygulamalarını container'a özel yeniden yazmadan confidential altyapıya taşımayı kolaylaştırabilir. Cloud operator veya host administrator tehdidini azaltabilir. GPU passthrough ve accelerator desteği sağlayıcıya göre değişebilir. Performance ve attestation davranışı gerçek workload üzerinde test edilmelidir.

Confidential Container

Confidential container yaklaşımı container workload'unu daha güçlü hardware izolasyonu içinde çalıştırır. Kubernetes gibi platformlarla integration mümkün olabilir. Container image signing ve remote attestation birlikte kullanıldığında deployment supply chain güçlenir. Secret manager yalnızca doğrulanmış container ölçümü için credential yayınlayabilir. Runtime güvenliği yine network ve application security kontrolleriyle tamamlanmalıdır.

Confidential GPU

ML workload'larının büyük kısmı GPU üzerinde çalıştığı için yalnızca CPU memory koruması yeterli olmayabilir. Confidential GPU teknolojileri host ile accelerator arasındaki veri hareketini ve GPU memory'sini korumayı hedefler. Desteklenen model, driver ve cloud seçenekleri hızla geliştiği için güncel vendor dokümantasyonu kontrol edilmelidir. Training ve inference performans overhead'i ölçülmelidir. Özellikle hassas model weight ve inference input'un cloud GPU üzerinde işlenmesi gereken senaryolarda değerlidir.

Data-in-Use Protection

Data-in-use protection ML input'unun aktif işlem sırasında privileged infrastructure katmanından gizlenmesini hedefler. TEE memory encryption bunun temel araçlarından biridir. Secret, model weight ve inference input aynı protected execution ortamında tutulabilir. Attestation başarısız olduğunda key veya credential verilmemesi güvenlik zincirini tamamlar. Bu kontrol application içindeki yetkili kodun veriyi yanlış kullanmasını tek başına engellemez.

Cloud Operatöründen Koruma

Confidential computing özellikle cloud provider altyapısındaki privileged operator tehdidini azaltmak için anlamlıdır. Hypervisor veya host administrator'ın guest memory'yi okuması hardware politikasıyla sınırlandırılır. Bu, kurumun “operatör veriyi görebilir mi?” sorusuna teknik bir cevap sağlar. Ancak provider control plane ve network metadata riskleri devam edebilir. Threat model hangi operator yetkilerinin gerçekten kapsam dışında kaldığını net biçimde açıklamalıdır.

Remote Attestation

Remote attestation uzaktaki workload'un beklenen hardware ve software ölçümüyle çalıştığını doğrular. Veriyi veya secret'ı göndermeden önce execution ortamının güvenilirliği kontrol edilebilir. Attestation token imzalı platform kanıtı taşır. Policy engine kabul edilen image hash veya security version değerlerini doğrulayabilir. Bu mekanizma confidential ML servisinde key release işlemini otomatik güvenlik kapısına dönüştürebilir.

Hardware measurement

Hardware measurement boot veya workload durumunun kriptografik özetini oluşturur. Ölçüm trusted firmware, kernel veya container image bileşenlerini içerebilir. Beklenen değer baseline olarak policy içinde tutulur. Değişiklik olduğunda attestation başarısız olabilir. Ölçüm kapsamı kullanılan confidential computing teknolojisine göre doğrulanmalıdır.

Attestation token

Attestation token platformun güvenilir execution ortamı hakkında imzalı kanıt sağlar. Token içindeki measurement, security version ve nonce değerleri doğrulanabilir. Replay saldırısını önlemek için freshness kontrolü önemlidir. Token sadece trusted attestation authority üzerinden kabul edilmelidir. Application policy bu kanıta göre bağlantı veya secret erişimi verebilir.

Secret release gate

Secret release gate, model API key veya decryption key'in yalnızca doğrulanmış workload'a verilmesini sağlar. Attestation başarılı değilse secret manager credential yayınlamaz. Böylece saldırgan aynı image'ı güvenilmeyen host üzerinde çalıştırsa bile veriye ulaşamayabilir. Policy update kontrollü change management ile yapılmalıdır. Emergency recovery için güvenli ama erişilebilir alternatif süreç de tasarlanmalıdır.

Confidential Computing'in Sınırları

Confidential computing bütün ML güvenlik sorunlarını çözmez. Uygulama içindeki SQL injection, insecure API veya yanlış authorization açığı TEE içinde de varlığını sürdürür. Side-channel riskleri kullanılan hardware ve threat model'e göre değerlendirilebilir. Model extraction veya poisoning gibi ML'e özgü saldırılar ayrıca yönetilmelidir. Bu teknoloji güçlü bir data-in-use katmanıdır, fakat defense-in-depth yaklaşımının yalnızca bir bileşenidir.

Federated Learning Nedir?

Federated learning, training verisini merkezi sunucuya taşımadan farklı cihaz veya kurumlarda lokal model eğitimi yapılmasını sağlar. Merkezi server global modeli dağıtır ve client'lar kendi verileri üzerinde update üretir. Bu update'ler aggregate edilerek global model yenilenir. Ham verinin yerinde kalması veri yerelliğine önemli katkı sağlar. Ancak gradient veya model update'lerinin bilgi sızdırabileceği için federated learning tek başına gizlilik garantisi değildir.

Merkezi ML ile Federated Learning Farkı

Merkezi ML yaklaşımında training verisi çoğunlukla ortak data lake veya training cluster'a taşınır. Federated learning ise compute'u verinin bulunduğu yere götürür. Bu sayede kurum veya cihaz ham veriyi dışarı göndermeden ortak modele katkı sağlayabilir. Buna karşılık network koordinasyonu ve heterojen client yönetimi zorlaşır. Güvenlik modeli de merkezi dataset korumasından gradient, client identity ve aggregation güvenliğine doğru genişler.

Federated Learning Nasıl Çalışır?

Federated learning genel olarak global modelin client'lara gönderilmesiyle başlar. Client kendi local verisi üzerinde belirli epoch kadar training yapar. Oluşan model update merkezi aggregation servisine gönderilir. Server update'leri birleştirerek yeni global model oluşturur. Bu döngü hedef performansa veya belirlenen round sayısına ulaşana kadar devam eder.

Global model

Global model federated round'un ortak başlangıç ve sonuç modelidir. Server bu modeli seçilen client grubuna dağıtır. Global weight'lerin integrity'si imza veya hash ile doğrulanabilir. Client kötü niyetli model alırsa local data üzerinde beklenmedik davranış oluşabilir. Model provenance federated sistemlerde bu nedenle önemlidir.

Local training

Local training verinin cihaz veya kurum sınırı içinde kaldığı aşamadır. Training process sadece izinli local dataset'e erişmelidir. Device güvenli değilse attacker local veri veya gradient'e erişebilir. Secure enclave veya device-level encryption ek koruma sağlayabilir. Training sonucu ham veri yerine update olarak dışarı gönderilir.

Model update

Model update local training sonucunda oluşan gradient veya weight farkıdır. Ham data içermese bile reconstruction saldırısına karşı hassas olabilir. Secure aggregation tekil update'in server tarafından görülmesini engellemeyi hedefler. Differential privacy update'e kontrollü noise ekleyebilir. Update channel TLS ile korunmalıdır.

Aggregation

Aggregation birçok client update'ini birleştirerek global modeli yeniler. Basit ortalama yerine client veri büyüklüğü veya robustness dikkate alınabilir. Malicious client poisoning saldırısı aggregation sonucunu bozabilir. Robust aggregation ve anomaly detection kullanılabilir. Secure aggregation privacy sağlarken poisoning tespitinin tasarımını daha zor hâle getirebilir.

Cross-Device Federated Learning

Cross-device federated learning çok sayıda mobil veya edge cihazın training'e katıldığı senaryodur. Client'lar sık sık offline olabilir ve donanım kapasiteleri farklıdır. Server her round için uygun cihaz alt kümesi seçer. Update boyutu network ve batarya maliyetini etkiler. Secure aggregation ve device authentication bu yapıda temel güvenlik gereksinimleridir.

Cross-Silo Federated Learning

Cross-silo federated learning daha az sayıda fakat güvenilirlik ve veri hacmi yüksek kurumlar arasında uygulanır. Hastaneler veya finans kurumları ham veriyi paylaşmadan ortak model geliştirebilir. Participant identity genellikle güçlü PKI ile doğrulanabilir. Network daha stabil olsa da hukuki veri paylaşımı ve model ownership konuları daha belirgindir. MPC ve secure aggregation kurumların birbirine duyduğu güven ihtiyacını azaltabilir.

Federated Learning'in Veri Yerelliğine Katkısı

Federated learning ham verinin merkezileştirilmesini azaltarak residency gereksinimine yardımcı olur. Hastane verisi hastane içinde, mobil veri cihaz üzerinde kalabilir. Ancak model update'in yurt dışındaki server'a gönderilmesi hâlâ veri aktarımı değerlendirmesi gerektirebilir. Merkezi orchestrator logları veya telemetry de kişisel bilgi taşıyabilir. Bu nedenle federated architecture veri yerelliğini güçlendirir, fakat bütün veri akışının hukuki ve teknik analizini ortadan kaldırmaz.

Federated Learning Veriyi Tamamen Güvenli Hale Getirir mi?

Federated learning ham training data'yı merkezileştirmediği için önemli risk azaltımı sağlar, fakat tam gizlilik sağlamaz. Gradient ve model update'leri belirli örneklerin yeniden oluşturulmasına veya üyelik bilgisinin tahmin edilmesine yol açabilir. Kötü niyetli client modeli zehirleyebilir veya backdoor yerleştirmeye çalışabilir. Server da tekil update'leri görüyorsa privacy tehdidi oluşturabilir. Bu nedenle production federated learning tasarımında secure aggregation, differential privacy, authentication, anomaly detection ve model validation birlikte düşünülmelidir.

Gradient Leakage

Gradient leakage, training sırasında paylaşılan gradient'in local veri hakkında bilgi açığa çıkarmasıdır. Özellikle küçük batch veya belirli network yapılarında risk daha yüksek olabilir. Server veya network attacker gradient'i analiz ederek örnek özelliklerini tahmin etmeye çalışabilir. Secure aggregation tekil gradient görünürlüğünü azaltır. Differential privacy de update'e noise ekleyerek bireysel örneğin etkisini sınırlar.

Model Inversion

Model inversion saldırısı model output veya update üzerinden training örneklerinin temsilî özelliklerini geri çıkarmayı amaçlar. Federated yapı bu riski tamamen ortadan kaldırmaz. Özellikle hassas sınıflar için model response granularity ve confidence output sınırlandırılabilir. Privacy evaluation gerçek threat model üzerinden yapılmalıdır. Model inversion testleri red team sürecine eklenebilir.

Training Data Reconstruction

Training data reconstruction saldırısı gradient veya model davranışından orijinal örneğe yakın veri üretmeyi hedefler. Görsel ve metin gibi yüksek boyutlu verilerde farklı teknikler kullanılabilir. Local batch büyüklüğü ve update clipping riski etkileyebilir. Secure aggregation saldırganın tek client update'ini görmesini engelleyebilir. Hassas projelerde reconstruction başarısı ölçülerek privacy riskine somut skor verilebilir.

Membership Inference

Membership inference belirli kaydın model training setinde bulunup bulunmadığını tahmin etmeye çalışır. Bir kişinin belirli sağlık veri setinde yer aldığının bilinmesi bile hassas bilgi olabilir. Overfitting bu saldırının başarısını artırabilir. Differential privacy membership leakage riskini azaltmak için güçlü tekniktir. Production öncesi hem global hem federated model üzerinde membership inference testi yapılabilir.

Malicious Client

Federated network'e katılan client kötü niyetli veya ele geçirilmiş olabilir. Yanlış gradient göndererek global modeli bozmaya çalışabilir. Client identity, certificate ve device attestation katılım kontrolünü güçlendirir. Anomaly detection aşırı veya olağandışı update'leri işaretleyebilir. Tek client'ın global modele etkisi clipping veya robust aggregation ile sınırlandırılabilir.

Poisoning Attack

Poisoning attack training update'i manipüle ederek model performansını veya belirli sınıf davranışını bozar. Saldırgan local veriyi değiştirerek kötü update üretebilir. Secure aggregation privacy sağladığı için server tek update'i inceleyemediğinde poisoning detection daha zor olabilir. Robust aggregation teknikleri bu dengeyi yönetmeye yardımcı olur. Federated security tasarımı privacy ile integrity hedeflerini birlikte ele almalıdır.

Backdoor Attack

Backdoor saldırısı modelin normal veride düzgün çalışıp belirli trigger olduğunda yanlış davranmasını hedefler. Malicious client lokal dataset'e trigger örnekleri ekleyebilir. Global accuracy testi bu saldırıyı fark etmeyebilir. Backdoor-specific validation seti ve model behavior analysis gerekir. Kritik federated projelerde suspicious update quarantine mekanizması kullanılabilir.

Federated Learning Neden Ek Güvenlik Katmanları Gerektirir?

Federated architecture saldırı yüzeyini merkezden çok sayıda client'a genişletir. Ham veri merkezde bulunmaz, fakat update'ler privacy riski taşır. Client poisoning integrity riskini artırırken server compromise model ve coordination katmanını etkiler. Secure aggregation, differential privacy ve güçlü client authentication farklı riskleri hedefler. Hiçbiri tek başına yeterli olmadığı için defense-in-depth federated learning için temel tasarım ilkesidir.

Secure Aggregation Nedir?

Secure aggregation federated learning server'ının tek tek client update'lerini görmeden toplu sonucu hesaplamasını sağlar. Böylece server sadece yeterli sayıda client'ın aggregate model update'ine erişir. Teknik olarak secret sharing, masking veya kriptografik protokoller kullanılabilir. Client dropout gerçek dünyada yaygın olduğu için protokolün belirli katılımcılar bağlantıyı kesse bile tamamlanabilmesi önemlidir. Secure aggregation gradient privacy riskini azaltır, fakat poisoning ve global model leakage sorunlarını tek başına çözmez.

Model Update'lerinin Gizlenmesi

Client model update'ini server'a plaintext göndermek yerine cryptographic mask uygular. Mask'ler aggregate edildiğinde birbirini iptal edecek biçimde tasarlanabilir. Server tek update'in gerçek değerini göremez. Yeterli sayıda client sonucu bir araya geldiğinde global toplam elde edilir. Protocol correctness ve key exchange aşaması dikkatle uygulanmalıdır.

Server'ın Tekil Gradient'leri Görmemesi

Secure aggregation'ın temel privacy amacı merkezi server'ın bireysel client update'ini inceleyememesidir. Bu, honest-but-curious server threat modelinde güçlü koruma sağlar. Ancak server collusion veya protocol implementation hataları ayrıca değerlendirilebilir. Minimum participant threshold belirlenmelidir. Çok az client ile aggregate sonuç bile bireysel bilgiye yakın olabilir.

Secret Sharing

Secret sharing update veya mask bilgisini birden fazla parçaya ayırabilir. Tek taraf tüm secret'a erişemez. Belirli threshold sayıda parça birleştiğinde gerekli değer yeniden oluşturulabilir. Bu yöntem MPC ve secure aggregation protokollerinde sık kullanılır. Key ve share lifecycle yönetimi protocol security'nin önemli parçasıdır.

Dropout-Resilient Aggregation

Mobil cihazların training round sırasında bağlantıyı kesmesi federated learning'de normaldir. Secure aggregation protocol sadece tüm client'lar online kaldığında çalışıyorsa pratik değildir. Dropout-resilient tasarım eksik client mask'lerini güvenli biçimde çözerek aggregate'i tamamlamayı sağlar. Threshold çok düşük tutulursa privacy zayıflayabilir. Availability ile confidentiality dengesi gerçek client davranışına göre test edilmelidir.

Federated Learning + Secure Aggregation

Federated learning ham veriyi yerinde tutarken secure aggregation model update'lerinin merkezi server tarafından okunmasını zorlaştırır. Birlikte kullanıldığında privacy seviyesi önemli ölçüde artar. Ancak global model membership inference'a açık olabilir. Differential privacy bu üçüncü katmanı tamamlayabilir. Production tasarımında iletişim overhead'i ve failure recovery de performans testine dahil edilmelidir.

Differential Privacy Nedir?

Differential privacy, bir bireyin verisinin dataset'e eklenmesi veya çıkarılmasının gözlemlenen sonuç üzerindeki etkisini matematiksel olarak sınırlandırmayı hedefler. ML training sırasında gradient clipping ve noise addition ile uygulanabilir. Privacy budget sistemin ne kadar gizlilik harcadığını sayısal olarak takip etmeye yardımcı olur. Daha güçlü privacy genellikle model accuracy üzerinde belirli maliyet oluşturabilir. Bu nedenle epsilon ve delta değerleri sadece teknik ekip tarafından rastgele seçilmemeli, risk ve utility hedefleri birlikte değerlendirilmelidir.

Bireysel Verinin Model Üzerindeki Etkisini Sınırlamak

Differential privacy'nin ana fikri modelin tek bir training kaydına aşırı bağımlı olmasını önlemektir. Bir kayıt değiştiğinde model davranışının dramatik biçimde değişmemesi hedeflenir. Bu özellik membership inference ve memorization riskini azaltabilir. Gradient clipping her örneğin update üzerindeki maksimum etkisini sınırlar. Noise ise tek bireyin katkısının ayırt edilmesini daha zor hâle getirir.

Privacy Budget Nedir?

Privacy budget bir sistemin differential privacy kapsamında ne kadar bilgi açığa çıkarabileceğini temsil eder. Aynı veri üzerinde tekrar tekrar sorgu veya training yapıldıkça bütçe tüketilebilir. Privacy accountant toplam kaybı takip eder. Düşük epsilon genel olarak daha güçlü privacy anlamına gelir, fakat utility maliyeti artabilir. Budget değerleri model ve iş riskiyle ilişkilendirilmelidir.

Epsilon

Epsilon differential privacy garantisinin ana parametrelerinden biridir. Değer küçüldükçe iki komşu dataset'in output dağılımlarını ayırt etmek daha zorlaşır. Çok küçük epsilon model accuracy'yi ciddi etkileyebilir. Çok büyük epsilon ise pratik privacy faydasını azaltabilir. Uygun değer literatür, sektör riski ve deneysel performans birlikte değerlendirilerek seçilmelidir.

Delta

Delta saf differential privacy'den küçük bir ihlal olasılığına izin veren parametredir. Genellikle dataset boyutuna göre çok küçük değer seçilir. Epsilon ile birlikte privacy guarantee'nin tamamını ifade eder. Delta'nın ne anlama geldiği teknik olmayan karar vericilere açık biçimde anlatılmalıdır. Compliance için yalnızca “DP kullanıyoruz” demek yerine gerçek epsilon ve delta kayıtları saklanmalıdır.

DP-SGD Nasıl Çalışır?

Differentially Private SGD klasik stochastic gradient descent eğitimine privacy kontrolleri ekler. Önce örnek bazlı gradient normları belirli limite clip edilir. Daha sonra aggregate gradient'e kontrollü random noise eklenir. Privacy accountant eğitim round'ları boyunca toplam epsilon değerini hesaplar. Model performansı ile privacy budget farklı clipping ve noise parametrelerinde benchmark edilmelidir.

Gradient clipping

Gradient clipping tek training örneğinin model update üzerindeki maksimum etkisini sınırlar. Her örnek gradient normu belirlenen threshold'u aşarsa küçültülür. Threshold çok düşükse öğrenme kapasitesi zarar görebilir. Çok yüksekse privacy için gereken noise daha fazla olabilir. Clipping değeri gerçek gradient dağılımı analiz edilerek seçilmelidir.

Noise addition

Noise addition aggregate gradient'e rastgele gürültü ekler. Amaç tek bir bireyin katkısının output üzerinden ayırt edilmesini zorlaştırmaktır. Noise seviyesi privacy budget ve clipping norm ile ilişkilidir. Fazla noise accuracy kaybı yaratabilir. Eğitim deneyleri privacy ile utility arasında kabul edilebilir dengeyi bulmalıdır.

Privacy accounting

Privacy accounting training boyunca biriken privacy loss değerini hesaplar. Her epoch veya sampling işlemi toplam budget'ı etkiler. Accountant olmadan yalnızca noise eklemek formal DP garantisi vermeyebilir. Model artifact yanında privacy report saklamak governance açısından faydalıdır. Yeni retraining başladığında budget'ın dataset ve kullanıcı bazında nasıl ele alınacağı belirlenmelidir.

Local Differential Privacy

Local differential privacy noise'u verinin merkezi sisteme ulaşmasından önce kullanıcı veya cihaz üzerinde ekler. Server hiçbir zaman ham değeri görmez. Bu model merkezi kuruma daha az güven gerektirir. Ancak aynı utility için central DP'ye göre daha fazla noise gerekebilir. Telemetry ve kullanıcı davranışı toplama gibi senaryolarda değerlendirilebilir.

Central Differential Privacy

Central differential privacy güvenilir veri yöneticisinin ham veriye eriştiği ve yalnızca aggregate sonuç veya model üzerinde privacy mekanizması uyguladığı yaklaşımdır. Daha iyi accuracy sağlamak mümkün olabilir. Buna karşılık merkezi dataset'in güçlü biçimde korunması gerekir. Access control ve secure environment burada hâlâ kritik önemdedir. DP breach riskini azaltır, fakat database sızıntısına karşı encryption'ın yerine geçmez.

Differential Privacy ve Model Accuracy Dengesi

Privacy arttıkça modele eklenen noise veya clipping etkisi büyüyebilir. Bu durum özellikle küçük dataset ve az temsil edilen sınıflarda accuracy düşüşüne yol açabilir. Sadece overall accuracy değil subgroup performance da ölçülmelidir. Privacy parameter seçimi security, data science ve ürün ekiplerinin ortak kararı olmalıdır. Deney sonuçları privacy budget ile birlikte kaydedilirse sonraki modeller için karşılaştırılabilir governance oluşur.

Homomorphic Encryption ile Makine Öğrenimi

Homomorphic encryption, şifreli veri üzerinde veriyi çözmeden hesap yapabilme imkânı sağlar. Bu yaklaşım inference provider'ın kullanıcı input'unu plaintext görmemesini sağlayabilir. Klasik neural network operasyonlarının tamamını verimli biçimde desteklemek zor olduğu için model uyarlaması gerekebilir. Fully homomorphic yöntemler güçlü gizlilik sunarken yüksek computational overhead yaratabilir. Bu nedenle bugün özellikle hassas ve sınırlı inference fonksiyonlarında değerlendirilen bir privacy-preserving tekniktir.

Homomorphic Encryption Nedir?

Homomorphic encryption ciphertext üzerinde yapılan işlemlerin plaintext üzerindeki karşılığına dönüşebilmesini sağlayan kriptografik yöntemdir. Server kullanıcı verisini decrypt etmeden hesaplama yapabilir. Sonuç yine şifreli olarak kullanıcıya döner. Decryption key sadece veri sahibinde kalabilir. Böylece compute provider'a duyulan veri gizliliği güveni önemli ölçüde azaltılır.

Partial Homomorphic Encryption

Partial homomorphic encryption yalnızca belirli işlem türlerini destekler. Örneğin toplama veya çarpma operasyonlarından biri sınırsız uygulanabilir. Daha basit olduğu için FHE'ye göre daha iyi performans sağlayabilir. Belirli lineer istatistik ve aggregation görevleri için yeterli olabilir. Model workload'u desteklenen matematiksel işlemlerle uyumluysa pratik seçenek hâline gelir.

Fully Homomorphic Encryption

Fully homomorphic encryption hem toplama hem çarpma kombinasyonlarını destekleyerek genel hesaplamaya yaklaşır. Teoride karmaşık ML inference işlemleri şifreli veri üzerinde gerçekleştirilebilir. Pratikte ciphertext büyüklüğü ve computational overhead önemlidir. Model activation fonksiyonları polynomial approximation gerektirebilir. Bu nedenle deployment kararı latency ve maliyet benchmark'ına dayanmalıdır.

Şifreli Veri Üzerinde Inference

Kullanıcı input'u kendi tarafında encrypt eder ve ciphertext inference servisine gönderir. Server şifreli ağırlık veya plaintext model ile desteklenen hesaplamayı yapabilir. Sonuç ciphertext olarak geri döner ve yalnızca key sahibi tarafından çözülür. Provider input'un gerçek değerini görmez. Bu model finansal veya sağlık gibi çok hassas prediction senaryolarında değerlendirilebilir.

FHE'nin Avantajları

FHE compute provider'a plaintext veri göstermeden işlem yapılmasını sağlar. Data-in-use confidentiality açısından güçlü bir özellik sunar. Provider compromise olduğunda bile attacker kullanıcı input'unu doğrudan okuyamayabilir. Encryption key kurum veya kullanıcı tarafında kalabilir. Multi-tenant cloud üzerinde hassas inference için güçlü privacy sınırı oluşturabilir.

FHE'nin Performans ve Maliyet Sorunları

FHE klasik inference'a göre çok daha yüksek CPU ve memory maliyeti oluşturabilir. Ciphertext boyutu network trafiğini artırır. Model mimarisi ve precision seviyesi yeniden tasarım gerektirebilir. GPU acceleration seçenekleri gelişse de her workload için ekonomik değildir. Bu nedenle proof of concept aşamasında gerçek latency, throughput ve maliyet ölçülmeden production kararı verilmemelidir.

Secure Multi-Party Computation (MPC)

MPC birden fazla tarafın kendi gizli verisini birbirine açıklamadan ortak hesaplama yapmasını sağlayan kriptografik protokol ailesidir. Kurumlar verilerini secret share'lere bölerek ortak training veya inference yapabilir. Hiçbir taraf tek başına diğer kurumun plaintext verisini görmeyebilir. Privacy faydası güçlüdür, fakat network communication ve computation maliyeti artar. Cross-silo federated learning ve secure aggregation senaryolarında MPC önemli tamamlayıcı tekniktir.

MPC Nedir?

Secure multi-party computation bir fonksiyonun girdileri gizli kalacak şekilde taraflarca birlikte hesaplanmasını sağlar. Her kurum kendi verisini doğrudan paylaşmaz. Cryptographic share'ler veya garbled circuit gibi teknikler kullanılabilir. Threat model honest-but-curious veya malicious participant olarak farklılaşabilir. Kullanılan protocol güvenlik seviyesine göre performans açısından farklı maliyetler taşır.

Birden Fazla Kurumun Verisini Paylaşmadan Hesaplama

İki banka fraud istatistiği üretmek isteyebilir, ancak müşteri datasını birbirine vermek istemeyebilir. MPC ile ortak fonksiyon sonuçlandırılırken ham kayıtlar tarafların kontrolünde kalabilir. Bu yöntem yasal veri paylaşım risklerini azaltabilir. Yine de output'un kişisel bilgi açığa çıkarıp çıkarmadığı ayrıca değerlendirilmelidir. Ortak protocol governance ve participant authentication süreci kurulmalıdır.

Secret Sharing

Secret sharing bir değeri birden fazla anlamsız parçaya böler. Tek share orijinal veriyi açıklamaz. Belirli sayıda share bir araya geldiğinde hesaplama veya reconstruction yapılabilir. MPC protocol'leri aritmetik işlemleri share'ler üzerinde uygulayabilir. Share storage ve transport güvenliği de normal credential kadar korunmalıdır.

Private Model Training

MPC farklı kurumların ortak model eğitimi sırasında data'yı birbirine göstermemesini sağlayabilir. Training operation ciphertext veya secret share üzerinde gerçekleştirilir. Bu yöntem federated learning'e göre daha sıkı privacy sunabilir. Bunun karşılığında training süresi ve network maliyeti yüksektir. Küçük modeller veya yüksek hassasiyetli sektörler için daha uygulanabilir olabilir.

Private Inference

Private inference model sahibinin modeli, kullanıcının da input'unu karşı tarafa açıklamak istemediği senaryoya odaklanabilir. MPC ile iki taraf birlikte prediction hesaplayabilir. Kullanıcı model weight'lerini görmezken provider da input'u görmeyebilir. Bu çift taraflı gizlilik ticari model IP'si için de değerlidir. Latency gereksinimi protocol seçiminde ana kriterdir.

MPC ve Federated Learning Birlikte Nasıl Kullanılır?

Federated learning veriyi local tutarken MPC aggregation aşamasını gizleyebilir. Client update'leri secret sharing ile server taraflarına dağıtılabilir. Tek server hiçbir update'i plaintext göremez. Bu yapı secure aggregation'ın daha geniş bir uygulamasına dönüşebilir. Malicious client ve poisoning riskleri yine robust training teknikleriyle ayrı yönetilmelidir.

Privacy-Preserving Machine Learning Teknikleri Nasıl Karşılaştırılır?

Privacy-preserving ML teknikleri aynı sorunu çözmez ve bu nedenle “en güvenli yöntem hangisi?” sorusunun tek cevabı yoktur. Federated learning veri merkezileştirmeyi azaltırken differential privacy bireysel kaydın model üzerindeki etkisini sınırlar. Secure aggregation update gizliliğini, MPC kurumlar arası ortak hesabı, FHE encrypted computation'ı ve confidential computing privileged infrastructure riskini hedefler. Aynı projede birden fazla teknik birlikte kullanılabilir. Doğru seçim threat model, latency, model accuracy, operasyon kapasitesi ve hukuki gereksinim üzerinden yapılmalıdır.

Federated Learning

Federated learning ham veriyi merkezi training ortamına taşımama ihtiyacı için güçlü çözümdür. Edge ve kurumlar arası veri yerelliğini destekler. Communication overhead ve client heterogeneity operasyon maliyeti oluşturur. Update leakage riskini tek başına çözmez. Secure aggregation ve differential privacy ile birlikte kullanıldığında privacy seviyesi yükselir.

Differential Privacy

Differential privacy bireysel verinin model veya istatistik üzerindeki etkisine matematiksel sınır getirir. Membership inference ve memorization riskini azaltır. Central veya local uygulanabilir. Accuracy üzerinde maliyet oluşturabilir. Formal privacy budget yönetimi gerektirdiği için governance açısından güçlü ve ölçülebilir araçtır.

Secure Aggregation

Secure aggregation federated server'ın tek client update'ini görmemesini sağlar. Ham veri zaten local kalırken gradient privacy'sini güçlendirir. Communication ve cryptographic coordination gerektirir. Client dropout için özel protocol tasarımı gerekir. Poisoning gibi integrity saldırılarını kendi başına çözmez.

MPC

MPC birden fazla tarafın ortak hesaplama yaparken girdilerini gizli tutmasını sağlar. Kurumlar arası düşük güven ortamında güçlü seçenektir. Training ve inference için kullanılabilir. Computational ve network overhead yüksektir. Küçük sayıda yüksek değerli katılımcının bulunduğu cross-silo senaryolarda özellikle anlamlıdır.

Homomorphic Encryption

Homomorphic encryption compute provider'a plaintext veriyi göstermeden hesap yapılmasını sağlar. FHE güçlü data-in-use privacy sunar. Buna karşılık model operasyonlarının desteklenmesi ve performans önemli sınırlardır. Low-latency genel amaçlı inference için henüz her durumda ideal değildir. Yüksek hassasiyetli ve daha dar model görevlerinde güçlü aday olabilir.

Confidential Computing

Confidential computing workload memory'sini privileged infrastructure katmanından korur. Cloud üzerinde yüksek performanslı native ML framework'lerinin daha az değişiklikle kullanılmasını sağlayabilir. FHE kadar provider bağımsız cryptographic privacy sağlamaz. Hardware ve attestation trust modeline dayanır. GPU training ve inference için performans açısından daha pratik privacy katmanı olabilir.

Hangi Teknik Hangi Risk İçin Kullanılmalı?

Teknik seçimi önce risk tanımlanarak yapılmalıdır. Veriyi merkezileştiremiyorsanız federated learning, memorization endişesi varsa differential privacy ve gradient exposure varsa secure aggregation öne çıkar. Cloud operator threat modelinde confidential computing, karşılıklı güvenmeyen kurumlarda MPC ve provider'a plaintext vermeme ihtiyacında FHE değerlendirilebilir. Aynı problem birden fazla risk taşıyabilir. Bu nedenle privacy-preserving mimari tek ürün seçimi değil katmanlı kontrol tasarımıdır.

Veriyi merkezileştirememe

Regülasyon veya kurum politikası nedeniyle ham veri lokasyonundan çıkamıyorsa federated learning güçlü başlangıçtır. Compute local dataset'e gider. Merkezi server yalnızca model update alır. Update'in kendisi hassas olabileceği için secure aggregation eklenebilir. Kurumlar arası hukuki değerlendirme yine devam eder.

Model memorization

Modelin training örneklerini ezberlemesi membership inference ve extraction riskini artırır. Differential privacy bireysel örneğin etkisini sınırlandırabilir. Regularization ve deduplication ek yardımcı kontrollerdir. Red team extraction testi privacy seviyesini ölçebilir. Çok hassas veri varsa modelin hiç train edilmemesi veya RAG gibi alternatif yaklaşım da değerlendirilebilir.

Gradient leakage

Gradient leakage federated veya distributed training'de update üzerinden veri çıkarılmasını ifade eder. Secure aggregation tekil gradient'i server'dan gizler. Differential privacy update'e noise ekleyebilir. Batch ve clipping parametreleri risk üzerinde etkilidir. Gradient debug kayıtları production ortamında tutulmamalıdır.

Cloud operatörü riski

Cloud operator veya privileged host administrator'ın memory erişimi threat model içindeyse confidential computing değerlidir. Attestation ile yalnızca doğrulanmış workload'a key verilebilir. Customer-managed key at-rest riskini tamamlar. Private networking transit exposure'ı azaltır. Uygulama içi yetkilendirme yine ayrıca uygulanmalıdır.

Kurumlar arası güven problemi

Kurumlar verilerini birbirine açıklamadan ortak model geliştirmek istiyorsa federated learning veya MPC kullanılabilir. MPC karşılıklı gizlilik konusunda daha güçlü kriptografik garanti sağlayabilir. Federated learning performans ve mevcut ML framework desteği açısından daha kolay olabilir. Secure aggregation iki yaklaşım arasında güçlü köprü oluşturur. Governance modeli hangi tarafın neyi görebileceğini sözleşme ve teknik kontrollerle açıkça belirtmelidir.

Privacy–Utility Trade-Off Nedir?

Privacy arttıkça veri üzerinde yapılabilecek işlemler ve modelin erişebildiği sinyal sınırlanabilir. Differential privacy noise ekler, encryption compute maliyeti getirir ve federated learning iletişim gecikmesi oluşturur. Bununla birlikte güvenliğin her zaman performansı dramatik biçimde düşüreceği varsayımı doğru değildir. Doğru workload ve modern hardware ile bazı kontrollerin maliyeti düşük olabilir. Kurumun hedefi maksimum privacy veya maksimum accuracy yerine kabul edilebilir güvenlik, maliyet ve iş başarısı dengesini sayısal metriklerle bulmak olmalıdır.

Gizlilik Arttıkça Model Performansı Düşer mi?

Bazı privacy teknikleri model performansını etkileyebilir, ancak etki dataset ve algoritmaya göre değişir. Differential privacy küçük dataset'te daha belirgin accuracy kaybı oluşturabilir. Federated learning non-IID client dağılımı nedeniyle convergence sorunları yaşayabilir. Confidential computing çoğu durumda model accuracy'yi değiştirmez, fakat runtime overhead ekleyebilir. Bu nedenle her kontrol gerçek workload üzerinde benchmark edilmelidir.

Differential Privacy ve Accuracy

Düşük epsilon daha güçlü privacy sağlarken daha yüksek noise gerektirebilir. Bu durum rare class accuracy'sini özellikle etkileyebilir. Aggregate accuracy kabul edilebilir görünse bile subgroup sonuçları incelenmelidir. Model size ve training süresi farklı privacy budget'larda optimize edilebilir. Privacy report ile performance report aynı release artifact'ının parçası olmalıdır.

Encryption ve Latency

TLS ve at-rest encryption modern altyapıda çoğu workload için sınırlı overhead oluşturur. FHE ise çok daha yüksek latency getirebilir. MPC network round sayısı nedeniyle coğrafi olarak uzak kurumlarda yavaşlayabilir. Encryption seçimi “şifreleme pahalıdır” gibi genel hüküm yerine algoritma ve workload ölçümüyle yapılmalıdır. Kullanıcı deneyimi için P95 ve throughput birlikte değerlendirilmelidir.

Confidential Computing ve Performans

Confidential VM veya container memory encryption belirli overhead oluşturabilir. CPU ve GPU teknolojisine göre fark önemli ölçüde değişir. Memory-intensive training workload üzerinde gerçek benchmark yapılmalıdır. Attestation çoğu zaman session başlangıcında ek gecikme getirir. Security faydası ile performans maliyeti production SLO üzerinden karşılaştırılmalıdır.

Federated Learning ve Communication Overhead

Federated learning model update'lerini tekrar tekrar network üzerinden taşır. Büyük model weight'leri mobil cihazlarda bandwidth maliyeti oluşturabilir. Compression ve update sparsification teknikleri bu yükü azaltabilir. Client selection network kalitesi ve enerji durumunu dikkate alabilir. Cross-silo sistemlerde dedicated private connectivity daha yüksek throughput sağlayabilir.

Güvenlik–Maliyet–Performans Dengesi

Her güvenlik kontrolünün farklı maliyeti vardır. On-premise GPU yüksek sermaye gideri yaratırken sovereign cloud premium fiyatlandırma sunabilir. FHE latency, federated learning communication ve DP accuracy maliyeti oluşturabilir. Buna karşılık veri ihlali ve uyumsuzluk riski de gerçek business maliyetidir. Architecture decision record bu dört boyutu birlikte karşılaştırarak kararın nedenini açıkça kaydetmelidir.

On-Premise Makine Öğrenimi Nedir?

On-premise ML, training ve inference altyapısının kurumun kendi veri merkezi veya doğrudan kontrol ettiği fiziksel ortamda çalıştırılmasıdır. Verinin kurum dışına çıkmasını azaltabilir ve network ile key management üzerinde yüksek kontrol sağlar. Buna karşılık GPU lifecycle, patching, capacity planning ve fiziksel güvenlik sorumluluğu tamamen kuruma geçer. Kurumun bu operasyon yetkinliği yoksa on-premise sistem kötü yapılandırılmış cloud ortamından daha riskli bile olabilir. Bu yüzden on-premise seçimi veri hassasiyeti ile gerçek işletim kapasitesinin birlikte değerlendirilmesini gerektirir.

Verinin Kurum İçinde Tutulması

On-premise mimaride storage, training ve inference aynı kurum network'ünde kalabilir. External model API kullanılmadığında veri egress önemli ölçüde azalır. Backup ve remote support süreçleri yine dış aktarım yaratabilir. GPU driver veya model package güncellemeleri için internet erişimi gerekiyorsa kontrollü egress tasarlanmalıdır. Air-gap gereksiniminde offline supply chain oluşturulabilir.

On-Prem ML'nin Avantajları

On-premise sistem yüksek data locality ve network control sağlar. Encryption key kurum HSM'i içinde tutulabilir. Internal data source'lara düşük latency ile erişim mümkündür. Vendor bağımlılığı belirli ölçüde azaltılabilir. Özellikle sürekli yüksek GPU kullanımında uzun vadeli maliyet cloud'a göre avantajlı olabilir.

Dezavantajları

On-premise ML donanım yatırımını ve platform işletimini kurumun sorumluluğuna bırakır. GPU availability, driver compatibility ve hardware failure ekip tarafından yönetilir. Capacity talebi hızla büyüdüğünde yeni donanım almak zaman alabilir. Security patch ve monitoring için güçlü platform ekibi gerekir. Bu yükler hesaplanmadan yalnızca veri yerelliği gerekçesiyle on-premise kararı verilmemelidir.

GPU maliyeti

Modern training GPU'ları yüksek başlangıç maliyeti oluşturabilir. Donanım kullanımı düşük kaldığında yatırım verimsiz olur. Elektrik, soğutma ve yedek parça toplam maliyete eklenir. Birkaç büyük training job için cloud kiralama daha ekonomik olabilir. Sürekli inference ve yüksek utilization varsa on-premise TCO avantajı ortaya çıkabilir.

Operasyon yükü

GPU server, storage, network ve cluster platformu sürekli bakım gerektirir. Driver update ML framework uyumluluğunu etkileyebilir. Monitoring ve incident response ekip kapasitesi ister. Yedek hardware bulunmadığında tek arıza uzun downtime oluşturabilir. Bu nedenle on-premise maliyet hesabına personel zamanı mutlaka eklenmelidir.

Ölçeklenebilirlik

Cloud'da kısa sürede yeni GPU instance açılabilirken on-premise fiziksel kapasiteyle sınırlıdır. Peak training workload kapasiteyi aşabilir. Queue ve scheduling ile kullanım optimize edilebilir. Hybrid cloud burst modeli geçici kapasite ihtiyacını karşılayabilir. Ancak hassas dataset'in cloud'a taşınabilme durumu policy ile belirlenmelidir.

Güncelleme ve bakım

Firmware, BIOS, driver ve ML framework güncellemeleri planlı maintenance gerektirir. Her update production modeli etkileyebileceği için staging GPU ortamında test edilmelidir. Security patch geciktirilmemelidir. Offline ortamda paketlerin integrity'si imza ve hash ile doğrulanmalıdır. Update runbook supply chain güvenliğinin parçasıdır.

Hangi Veriler İçin On-Prem Mantıklıdır?

Çok hassas kişisel veri, ticari sır veya sektör politikası dış cloud kullanımını kısıtlıyorsa on-premise mantıklı olabilir. Büyük hacimli veriyi sürekli cloud'a taşımak network maliyeti oluşturuyorsa da avantaj sağlar. Düşük latency gerektiren factory veya internal inference senaryolarında uygundur. Bununla birlikte veri public veya düşük hassasiyetli ise cloud esnekliği daha fazla değer sağlayabilir. Seçim veri sınıfına ve workload özelliğine göre yapılmalıdır.

Edge Machine Learning ile Veri Yerelliği

Edge ML model inference veya training işlemini verinin üretildiği cihaz veya lokasyona yaklaştırır. Kamera görüntüsü, sensör verisi veya mobil kullanım bilgisi merkezi cloud'a gönderilmeden işlenebilir. Bu yaklaşım network latency ve data egress'i azaltır. Ancak edge cihazlar fiziksel olarak ele geçirilebilir veya patch yönetimi zor olabilir. Veri yerelliği kazanımı device security, secure boot ve model update güvenliğiyle birlikte değerlendirilmelidir.

Edge ML Nedir?

Edge ML modelin merkezi cloud yerine gateway, telefon, kamera veya endüstriyel cihaz üzerinde çalışmasıdır. Ham veri cihazdan çıkmadan feature veya prediction üretilebilir. Network bağlantısı olmadığında bile hizmet devam edebilir. Model boyutu ve compute kapasitesi cihazla sınırlıdır. Quantization ve pruning edge deployment için sık kullanılan optimizasyonlardır.

On-Device Inference

On-device inference kullanıcı verisini local olarak işler. Ses veya görüntü gibi hassas içerik cloud'a gönderilmeyebilir. Yalnızca anonim aggregate telemetry merkeze iletilebilir. Model artifact cihaz üzerinde extraction saldırısına karşı korunmalıdır. Secure enclave ve code signing mobil cihazlarda ek güvenlik sağlayabilir.

On-Device Training

On-device training kullanıcı verisinden cihaz üzerinde model update üretir. Federated learning bu update'leri merkezi model için kullanabilir. Ham data cihazda kalır. Battery ve compute kullanımı kullanıcı deneyimini etkileyebilir. Malicious cihaz update poisoning riski nedeniyle client attestation ve robust aggregation önemlidir.

IoT ve Sensör Verileri

Endüstriyel IoT cihazları sürekli büyük miktarda sensör verisi üretir. Edge model anomalileri local olarak tespit edip sadece alarmı merkeze gönderebilir. Bu yaklaşım bandwidth ve veri merkezi depolama ihtiyacını azaltır. Cihaz firmware güvenliği kritik hâle gelir. Fiziksel saldırganın debug port üzerinden model veya data çıkarması engellenmelidir.

Mobil Cihazlarda ML

Mobil cihaz güçlü modern accelerator'lar sayesinde birçok modeli local çalıştırabilir. Klavye önerisi veya kişiselleştirme gibi görevlerde privacy faydası sağlar. App sandbox kullanıcı verisini diğer uygulamalardan ayırır. Model update imzalı application release veya güvenli remote update üzerinden yapılmalıdır. Device telemetry kullanıcı izni ve minimizasyon ilkelerine göre tasarlanmalıdır.

Edge AI'ın Gizlilik Avantajları

Ham input'un cloud'a hiç gönderilmemesi privacy riskini önemli ölçüde azaltır. Merkezi data breach durumunda daha az kullanıcı verisi etkilenir. Network egress ve cross-border transfer azalabilir. Local inference düşük latency de sağlar. Buna karşılık cihaz kaybı veya malware local veriye erişebileceği için endpoint security güçlendirilmelidir.

Edge Cihaz Güvenliği

Secure boot sadece imzalı firmware'in çalışmasını sağlar. Device key hardware-backed storage içinde tutulabilir. Model artifact encryption extraction riskini azaltabilir. Remote attestation merkezi platformun cihaz bütünlüğünü doğrulamasına yardımcı olur. Patch alamayan eski cihazlar production ML ağından çıkarılmalıdır.

Air-Gapped Makine Öğrenimi

Air-gapped ML sistemi internet veya genel kurumsal ağdan fiziksel ya da güçlü mantıksal izolasyonla ayrılır. Savunma, kritik altyapı veya çok yüksek gizlilik gerektiren veriler için kullanılabilir. Veri egress ciddi biçimde azalır, ancak model ve software güncellemesi zorlaşır. Offline supply chain içeri alınan her package ve model artifact için doğrulama gerektirir. Air-gap güvenliğin tek başına garantisi değildir, çünkü insider ve removable media riskleri devam eder.

Air Gap Nedir?

Air gap sistem ile dış network arasında doğrudan bağlantı olmamasıdır. Güncellemeler kontrollü fiziksel medya veya ayrı transfer gateway üzerinden alınabilir. Network attack surface önemli ölçüde azalır. Bunun karşılığında telemetry ve remote support zorlaşır. Fiziksel erişim politikası ve removable media kontrolü kritik hâle gelir.

İnternete Kapalı ML Sistemleri

Model registry, package repository ve dataset tamamen internal altyapıda tutulabilir. External API model kullanılamaz. Open-weight modeller offline inference için avantaj sağlar. Security update paketleri ayrı doğrulama sürecinden geçerek içeri alınmalıdır. Monitoring verisi internal SIEM üzerinde kalmalıdır.

Savunma ve Kritik Altyapı Senaryoları

Çok hassas operasyon verisi internet bağlantısının kabul edilemez olduğu ortamlarda işlenebilir. Model inference local accelerator üzerinde çalışır. Training dataset restricted network'te kalır. Model update ancak güvenilir artifact verification sonrasında yapılır. Bu sistemlerde availability ve physical security confidentiality kadar önemlidir.

Model Güncelleme Problemi

Air-gap ortam dış registry'den otomatik model çekemez. Yeni model önce staging veya transfer zone içinde doğrulanmalıdır. Artifact hash, signature ve dependency manifest kontrol edilir. Ardından onaylı removable media veya data diode yaklaşımıyla içeri taşınabilir. Rollback için önceki model version saklanmalıdır.

Offline Model Supply Chain

Offline supply chain model, package ve container image'ın trusted source'tan geldiğini doğrulamalıdır. SBOM ve artifact signature kullanılabilir. Malware scanning internet bağlantısından ayrı ortamda yapılabilir. Dependency tree önceden freeze edilmelidir. İç repository production sisteminin tek izinli software kaynağı hâline getirilebilir.

Cloud, Sovereign Cloud, On-Prem ve Edge Nasıl Karşılaştırılır?

Deployment modelleri security, locality, maliyet ve operasyon açısından farklı avantajlar taşır. Public cloud yüksek esneklik sunarken on-premise fiziksel kontrolü artırır. Sovereign cloud belirli hukuki ve operasyonel egemenlik gereksinimlerine yanıt vermeyi hedefler. Edge veriyi kaynağa yakın işler, air-gap ise network exposure'ını minimuma indirir. En iyi architecture çoğu kurumda tek seçenek yerine veri sınıfına göre farklı workload'ların birlikte kullanıldığı hybrid model olabilir.

Public Cloud

Public cloud hızlı provisioning ve geniş GPU seçeneği sağlar. Managed ML, database ve security servisleri operasyon yükünü azaltabilir. Region ve subprocessor politikaları veri yerelliği açısından incelenmelidir. Customer-managed key ve private endpoint kullanılabilir. Güvenlik shared responsibility modeli nedeniyle müşteri configuration sorumluluğunu ortadan kaldırmaz.

Private Cloud

Private cloud kurum veya sınırlı tenant grubu için ayrılmış cloud benzeri altyapıdır. Self-service ve orchestration avantajlarını kurum kontrolüyle birleştirebilir. Donanım ve platform operasyonu yine kurum veya seçilen iş ortağında kalır. GPU utilization iyi planlanmalıdır. Network ve identity merkezi kurum politikasıyla yönetilebilir.

Sovereign Cloud

Sovereign cloud belirli ülke veya hukuk alanında data, operasyon ve control plane egemenliği sağlamaya odaklanabilir. Sadece region lokasyonu değil support personeli ve key ownership gibi kontroller de önemlidir. “Sovereign” etiketi her sağlayıcıda aynı teknik garanti anlamına gelmez. Sözleşme ve architecture detayları tek tek doğrulanmalıdır. Yüksek compliance gereksinimi için ek maliyet kabul edilebilir olabilir.

On-Premise

On-premise deployment fiziksel server ve network üzerinde doğrudan kurum kontrolü sağlar. Veri egress güçlü biçimde sınırlandırılabilir. GPU ve storage kapasitesi kurum tarafından sağlanır. Patching ve security monitoring sorumluluğu da tamamen kuruma geçer. Yüksek hassasiyetli ve stabil workload için anlamlı olabilir.

Edge

Edge veri üretim noktasında inference veya training yapar. Merkezi transfer ihtiyacını azaltır. Latency düşer ve offline kullanım mümkün olur. Cihazların fiziksel güvenliği ve update mekanizması risk oluşturur. Büyük model çalıştırma kapasitesi sınırlı olabilir.

Air-Gapped

Air-gapped sistem dış network bağlantısını kaldırarak data egress riskini minimuma indirir. Çok yüksek gizlilikli workload için kullanılabilir. Model update ve package management daha zahmetlidir. Remote monitoring sınırlıdır. İç tehdit ve fiziksel erişim hâlâ yönetilmelidir.

Hybrid Architecture

Hybrid architecture farklı veri sınıflarını uygun deployment modeliyle eşleştirir. Hassas training on-premise yapılırken public data training cloud üzerinde çalışabilir. Edge cihaz local inference üretip yalnızca aggregate telemetry gönderilebilir. Cloud daha büyük model için fallback olabilir. Routing policy veri sınıfını ve kullanıcı yetkisini dikkate almalıdır.

Veri Hassasiyetine Göre Deployment Seçimi

Public veya düşük hassasiyetli veri public cloud'da kolayca işlenebilir. Confidential data private cloud veya sıkı cloud policy gerektirebilir. Özel nitelikli veya kritik sektör verisi için on-premise, sovereign veya federated seçenekleri değerlendirilebilir. Çok yüksek gizlilik air-gap gerektirebilir. Bu karar matrix şeklinde security architecture dokümanına eklenmelidir.

Veri Yerelliği ile Veri Egemenliği Neden Aynı Şey Değildir?

Verinin Türkiye'deki bir veri merkezinde bulunması önemli bir residency bilgisidir, fakat egemenlik için tek başına yeterli değildir. Sağlayıcı merkez ülkesi, remote administrator erişimi, encryption key ownership ve control plane lokasyonu farklı olabilir. Veri egemenliği ayrıca kurumun sistemi sağlayıcıdan bağımsız işletme veya başka platforma taşıma kapasitesini içerir. Technical ve operational sovereignty bu nedenle fiziksel lokasyondan daha geniş kavramlardır. ML projelerinde model weight, feature store ve GPU execution lokasyonu birlikte değerlendirilmelidir.

Fiziksel Lokasyon

Physical location verinin hangi data center veya ülkede saklandığını gösterir. Residency kontrolü için temel bilgidir. Fakat cloud disk Türkiye'de olsa bile management API başka region'da çalışabilir. Backup kopyası farklı ülkeye gidebilir. Bu nedenle location inventory bütün storage ve replica bileşenlerini kapsamalıdır.

Hukuki Yetki Alanı

Hangi ülke hukukunun sağlayıcı ve veri üzerinde yetki sahibi olabileceği sovereignty değerlendirmesinde önemlidir. Çok uluslu provider birden fazla hukuki rejime tabi olabilir. Contract tek başına bütün government access riskini ortadan kaldırmayabilir. Encryption key ownership teknik azaltım sağlayabilir. Hukuk ekibi bu analizi infrastructure design ile birlikte yürütmelidir.

Cloud Provider'ın Merkez Ülkesi

Provider'ın şirket merkezi data center lokasyonundan farklı olabilir. Bu durum remote operation ve hukuki yetki açısından analiz edilmelidir. Local subsidiary bulunması tek başına tam egemenlik garantisi değildir. Support ve control plane ekiplerinin nerede bulunduğu sorulmalıdır. Provider due diligence teknik ve sözleşmesel belgelerle yapılmalıdır.

Yönetici Erişimi

Cloud veya on-premise fark etmeksizin privileged administrator erişimi önemli risktir. Local data center içindeki veriye yabancı support ekibi uzaktan erişebiliyorsa fiziksel yerellik tek başına yeterli olmaz. JIT, session recording ve dual approval kullanılabilir. Confidential computing operator riskini teknik olarak azaltabilir. Privileged access log'ları düzenli review edilmelidir.

Encryption Key Ownership

Key ownership sağlayıcıdan veri çözme yetkisini ne kadar ayırabildiğinizi belirler. Provider-managed key kolaydır ama egemenlik seviyesi daha düşüktür. Customer-managed veya external key daha fazla kontrol sağlar. Key revoke vendor exit senaryosunda güçlü mekanizmadır. Key backup'ın da aynı sovereignty politikasına uyması gerekir.

Technical Sovereignty

Technical sovereignty sistemin source, model, configuration ve data artifact'larını bağımsız biçimde yönetebilme kapasitesidir. Açık standart ve export formatları vendor lock-in'i azaltır. Self-hosted inference teknik kontrolü artırabilir. Ancak bağımlılık ve driver ekosistemi hâlâ dış tedarikçilere bağlı olabilir. Architecture bu bağımlılıkları açık inventory olarak tutmalıdır.

Operational Sovereignty

Operational sovereignty kritik sistemi günlük olarak kimin yönetebildiğini ifade eder. Kurum kendi personeliyle incident response ve recovery yapabiliyor mu sorusu önemlidir. Provider support olmadan sistemi restore edememek operasyon bağımlılığı yaratır. Runbook, local expertise ve backup erişimi bu egemenliği artırır. Eğitim ve dokümantasyon teknik ürün kadar önemlidir.

Türkiye'de Makine Öğrenimi ve KVKK

Türkiye'de kişisel veri içeren ML projeleri 6698 sayılı Kişisel Verilerin Korunması Kanunu çerçevesinde değerlendirilmelidir. ML training data kişisel veri içeriyorsa işleme amacı, hukuki şart, minimizasyon ve saklama süresi gibi konular model geliştirme sürecine doğrudan girer. Kişisel verilerin yurt dışına aktarımına ilişkin kurallar 2024 yılında önemli biçimde değişmiş ve standart sözleşmeler ile bağlayıcı şirket kuralları uygun güvence yöntemleri arasında düzenlenmiştir. Güncel Kurum kaynakları, standart sözleşmelerin kullanılabildiğini ve imzadan sonra belirli bildirim yükümlülüklerinin bulunduğunu gösterir. :contentReference[oaicite:1]{index=1}

ML Training Data Kişisel Veri İçerebilir mi?

Evet, training dataset doğrudan veya dolaylı olarak gerçek kişiyi belirleyebilen bilgiler içerebilir. İsim kaldırılmış olsa bile müşteri ID, lokasyon geçmişi veya davranış örüntüsü kişiyle yeniden ilişkilendirilebilir. Pseudonymization riski azaltır, fakat veriyi otomatik olarak anonim hâle getirmez. Training öncesi data discovery ve classification yapılmalıdır. Hukuki dayanak ve işleme amacı dataset lineage kaydında gösterilebilir.

Kişisel Verilerin İşlenmesinde Temel İlkeler

KVKK kapsamında kişisel veri işleme belirli temel ilkelere göre yürütülmelidir. ML projesinde bu ilkeler dataset toplama, feature engineering, training ve monitoring aşamalarına uygulanmalıdır. Verinin gereğinden uzun tutulmaması ve amaçla bağlantılı kullanılması mimariyi doğrudan etkiler. Modelin gelecekte başka amaçla kullanılacak olması önceki veri işleme amacını otomatik olarak genişletmez. Teknik ekiplerin bu ilkeleri project requirement olarak görmesi compliance sürecini sonradan yapılan belge çalışması olmaktan çıkarır.

Veri Minimizasyonu

Model için gerekli olmayan field'lar training dataset'e alınmamalıdır. Feature importance analizi hangi verinin gerçekten katkı sağladığını gösterebilir. Hassas feature düşük performans faydası sağlıyorsa kaldırılması riski ciddi ölçüde azaltabilir. Inference sırasında da tüm müşteri profili yerine modelin kullandığı alanlar gönderilmelidir. Minimizasyon privacy ile birlikte storage ve token maliyetini de düşürür.

Amaçla Sınırlılık

Veri belirlenen meşru ve açık amaç doğrultusunda kullanılmalıdır. Müşteri destek verisini toplamak daha sonra sınırsız model training hakkı anlamına gelmeyebilir. Yeni ML kullanım amacı privacy ve hukuk review gerektirebilir. Dataset catalog üzerinde izin verilen kullanım amacı metadata olarak tutulabilir. Pipeline, amacıyla uyumsuz data source'u otomatik olarak engelleyecek policy ile güçlendirilebilir.

Saklama Süresi

Training dataset süresiz saklanmamalıdır. Retention iş amacı ve hukuki gereksinime göre belirlenir. Checkpoint, log ve backup için de ayrı süre tanımlanmalıdır. Süre dolduğunda otomatik lifecycle policy veriyi silebilir. Model üzerinde verinin etkisi devam ediyorsa machine unlearning veya retraining konusu ayrıca değerlendirilmelidir.

Teknik ve İdari Tedbirler

Encryption, access control, network segmentation ve audit logging teknik tedbir örnekleridir. Role approval, veri sınıflandırma ve çalışan eğitimi idari tedbirlerle birlikte yürütülmelidir. ML-specific riskler için model leakage ve poisoning testleri de eklenebilir. Access review belirli periyotlarda tekrarlanmalıdır. Compliance yalnızca policy dokümanıyla değil çalışan teknik kontroller ve audit kanıtıyla desteklenmelidir.

KVKK Açısından ML Verisinin Yurt Dışına Aktarılması

ML verisi cloud storage, model API, yabancı GPU sağlayıcısı, SaaS platform veya remote support üzerinden yurt dışına aktarılabilir. 6698 sayılı Kanunun 9 uncu maddesinde 2024 yılında yapılan değişiklik sonrasında yeterlilik kararı, uygun güvenceler ve belirli şartlarda istisnai aktarım çerçevesi uygulanmaktadır. Standart sözleşmeler ve bağlayıcı şirket kuralları uygun güvence yöntemleri arasında yer alır; taahhütname ve Kurul izni de ilgili düzenlemede bulunan yöntemlerdendir. Kurum ayrıca standart sözleşme metinlerini yayımlamış ve 2026 yılında bunların uygulanmasında dikkat edilecek hususlar hakkında güncel duyuru paylaşmıştır. :contentReference[oaicite:2]{index=2}

Yurt Dışına Veri Aktarımı Ne Zaman Gerçekleşir?

Aktarım yalnızca dosyayı manuel olarak yabancı sunucuya yüklemek değildir. Cloud storage replikasyonu, model API isteği, telemetry ve remote support erişimi de veri akışı oluşturabilir. ML architecture bu hareketleri otomatik olarak yaptığı için ekiplerin fark etmeden aktarım yapması mümkündür. Data flow mapping bu nedenle hukuki analizin teknik girdisidir. Her endpoint için gönderilen veri kategorisi, alıcı, region ve amaç kaydedilmelidir.

Cloud storage

Object storage veya database yabancı region'da bulunuyorsa kişisel veri yurt dışındaki altyapıya taşınabilir. Backup replication ayrıca değerlendirilmelidir. Provider region pinning sunuyorsa configuration audit edilmelidir. Global metadata servislerinin kapsamı sözleşmeden doğrulanmalıdır. Storage seçimi hukuki aktarım mekanizmasıyla birlikte yapılmalıdır.

Model training API

Harici training API'ye dataset veya fine-tuning dosyası yüklemek doğrudan veri aktarımı oluşturabilir. Provider dosyayı hangi region'da işliyor sorulmalıdır. Training tamamlandıktan sonra upload dosyasının retention süresi kontrol edilmelidir. Dataset minimization uygulanmalıdır. Mümkünse hassas identifier training öncesi çıkarılmalıdır.

Foreign GPU provider

GPU instance yabancı data center'da çalışıyorsa training veya inference input'u fiziksel olarak bu bölgede işlenebilir. Storage Türkiye'de olsa bile processing transfer yaratabilir. GPU memory ve local scratch disk retention davranışı incelenmelidir. Snapshot farklı region'a kopyalanmamalıdır. Compute scheduler region enforcement policy ile sınırlandırılabilir.

SaaS ML platform

SaaS platform experiment tracking, model registry veya annotation hizmeti sunabilir. Kullanıcı sadece metric gönderdiğini düşünürken sample data veya prompt logları da aktarılabilir. Data processing agreement veri kategorilerini açıkça belirtmelidir. Alt işleyenler incelenmelidir. SaaS integration'a gönderilen payload teknik testle doğrulanmalıdır.

Remote support

Yurt dışındaki support ekibinin production verisine uzaktan erişebilmesi de değerlendirme konusu olabilir. Support hesabı sürekli açık tutulmamalıdır. JIT ve customer approval kullanılabilir. Ekran paylaşımı ve diagnostic log içinde kişisel veri bulunabileceği unutulmamalıdır. Support runbook veri minimization ve masking adımlarını içermelidir.

Yeterlilik Kararı

Kanunun güncel yurt dışına aktarım sistemi yeterlilik kararı mekanizmasını öngörmektedir. Yeterlilik değerlendirmesi ülke, sektör veya uluslararası kuruluş düzeyinde ele alınabilir. Güncel kararların ve kapsamın Kurum tarafından yayımlanan kaynaklardan doğrulanması gerekir. ML ekibinin varsayıma dayanarak ülkeyi “güvenli” kabul etmesi doğru değildir. Hukuk ve privacy ekibi deployment region listesini düzenli olarak güncellemelidir. :contentReference[oaicite:3]{index=3}

Uygun Güvenceler

Yeterlilik kararı bulunmayan durumlarda Kanunda öngörülen şartlarla uygun güvenceler üzerinden aktarım yapılabilmektedir. Standart sözleşmeler ve bağlayıcı şirket kuralları bu mekanizmalar arasında yer alır. Belirli durumlarda taahhütname ve Kurul izni de kullanılabilir. Teknik mimari sözleşmede yazan veri kategorileri ve güvenlik tedbirleriyle uyumlu olmalıdır. ML pipeline değiştiğinde aktarım kapsamının da değişip değişmediği kontrol edilmelidir. :contentReference[oaicite:4]{index=4}

Standart sözleşmeler

Kurum farklı aktarım ilişkileri için standart sözleşme metinleri yayımlamıştır. Veri sorumlusu ve veri işleyen tarafların rolüne göre doğru metin seçilmelidir. Standart sözleşme imzalandıktan sonra Kanunda öngörülen bildirim yükümlülüğü uygulanır. Kurumun güncel bilgilendirmesine göre bildirim için çevrim içi modül de kullanılabilmektedir. Teknik ekip sözleşmede belirtilen veri kategorileri ile gerçek API payload'ının eşleşmesini sağlamalıdır. :contentReference[oaicite:5]{index=5}

Bağlayıcı şirket kuralları

Bağlayıcı şirket kuralları özellikle çok uluslu şirket grupları içindeki aktarımlar için uygun güvence mekanizması olarak kullanılabilir. Kurum bu konuda başvuru formları ve yardımcı dokümanlar yayımlamıştır. 2026 yılında da bir BŞK başvurusunun Kurul tarafından onaylandığına ilişkin güncel duyuru bulunmaktadır. Grup içi ML platformu farklı ülkelerde çalışıyorsa BŞK teknik data flow ile uyumlu olmalıdır. Yeni region veya iştirak eklendiğinde kapsam yeniden değerlendirilmelidir. :contentReference[oaicite:6]{index=6}

Taahhütname

Yurt dışına aktarım düzenlemesinde belirli şartlarla yeterli korumayı sağlayacak hükümler içeren taahhütname ve Kurul izni de uygun güvence yöntemi olarak yer alır. Özellikle standart sözleşmenin kullanımının uygun olmadığı özel yapıların hukuki değerlendirmesinde gündeme gelebilir. Taahhütname teknik ve idari tedbirleri gerçek sistem davranışıyla uyumlu tanımlamalıdır. Cloud architecture değişikliği hukuki belgeyi de etkileyebilir. Uygulama öncesinde kurumun güncel resmi dokümanları ve hukuk görüşü esas alınmalıdır. :contentReference[oaicite:7]{index=7}

İstisnai Aktarım Hâlleri

Kanunda belirlenen bazı istisnai aktarım durumları da bulunmaktadır. Bu mekanizmalar düzenli ve sürekli cloud operasyonunun varsayılan çözümü olarak görülmemelidir. ML workload sürekli olarak yurt dışındaki API'yi çağırıyorsa kalıcı ve uygun aktarım mekanizması değerlendirilmelidir. İstisnai hâlin şartlarının gerçekten oluşup oluşmadığı hukuk ekibi tarafından analiz edilmelidir. Teknik ekip fallback veya emergency transfer senaryosunu ayrıca data flow içinde belgelemelidir.

ML Pipeline Tasarlanırken Yurt Dışı Aktarım Haritası Oluşturma

Data flow diagram üzerinde dataset kaynağı, storage, training, feature service, model API, logging ve backup bileşenleri gösterilmelidir. Her ok için veri kategorisi, region, alıcı ve hukuki transfer mekanizması kaydedilebilir. Yeni SaaS veya external model provider eklenmesi architecture review'u tetiklemelidir. Network egress logları belgeyle gerçek davranışın uyuşup uyuşmadığını doğrulayabilir. Bu yöntem compliance ekibi ile ML engineering arasında ortak bir teknik dil oluşturur.

GDPR ile KVKK Arasındaki ML Veri Güvenliği Bağlantısı

GDPR ve KVKK farklı hukuki düzenlemeler olsa da ML güvenlik mimarisinde veri minimizasyonu, amaçla sınırlılık ve güvenli işleme gibi ortak tasarım etkileri görülür. GDPR Article 5 kişisel verilerin belirli, açık ve meşru amaçlarla işlenmesini ve gerekli olanla sınırlı tutulmasını düzenler. Article 17 silme hakkı, Article 22 belirli otomatik karar süreçleri ve Chapter V uluslararası veri transferleri açısından ML projelerini etkileyebilir. Avrupa kullanıcılarını veya kuruluşlarını kapsayan projelerde iki düzenleme ayrı ayrı değerlendirilmelidir. Teknik olarak privacy by design yaklaşımı her iki rejimde de daha yönetilebilir compliance architecture oluşturur. :contentReference[oaicite:8]{index=8}

Privacy by Design

Privacy by design gizlilik kontrolünü deployment sonunda eklemek yerine ürün mimarisinin başlangıcına yerleştirir. Dataset minimization requirement ilk sprint'te belirlenebilir. External model provider seçimi privacy assessment'ten geçebilir. Log schema hassas field içermeyecek biçimde tasarlanabilir. Böylece compliance düzeltmesi production sonrasında maliyetli yeniden yapılandırmaya dönüşmez.

Data Minimization

GDPR Article 5 kapsamında veri minimizasyonu işleme amacı için yeterli, ilgili ve gerekli olan veriyle sınırlılığı ifade eder. ML projelerinde daha fazla feature her zaman daha iyi model anlamına gelmez. Gereksiz alanlar training öncesi kaldırılabilir. Privacy riskinin yanı sıra storage ve compute maliyeti de azalır. Feature selection ile privacy engineering birlikte yürütülebilir. :contentReference[oaicite:9]{index=9}

Purpose Limitation

Purpose limitation kişisel verinin belirlenen amaçla uyumlu kullanılmasını gerektirir. Kullanıcı destek kaydı başka bir AI modeline otomatik training verisi yapılmadan önce amaç uyumluluğu değerlendirilmelidir. Dataset catalog işleme amacını metadata olarak taşıyabilir. Pipeline policy izin verilmeyen kullanımda job'ı durdurabilir. Bu yaklaşım hukuki ilkeleri teknik kontrol hâline dönüştürür. :contentReference[oaicite:10]{index=10}

International Data Transfers

GDPR kapsamında uluslararası transferler ayrı kurallara tabidir. ML architecture global cloud ve model API kullandığında veri birden fazla jurisdiction'dan geçebilir. European data için uygun transfer mekanizması değerlendirilmelidir. KVKK kapsamında yürütülen transfer analizi GDPR için otomatik olarak yeterli sayılmaz. Her veri sahibi grubu için uygulanabilir hukuki rejim ayrı belirlenmelidir.

Automated Decision Making

ML modelinin kişi üzerinde önemli etki yaratan otomatik karar süreçlerinde kullanılması ek hukuki ve governance gereksinimleri doğurabilir. Decision pipeline hangi model output'unun nihai karara dönüştüğünü açıkça göstermelidir. Human review gerçek ve anlamlı olmalıdır. Model explanation veya appeal süreci sektör gereksinimine göre tasarlanabilir. Automated decision risk assessment sadece model accuracy değil fairness ve privacy boyutlarını da kapsamalıdır.

Right to Erasure

Silme talebi klasik database satırının kaldırılmasının ötesine geçebilir. Dataset, feature store, backup ve model training etkisi birlikte değerlendirilmelidir. Machine unlearning bazı senaryolarda teknik araç sağlayabilir. Her model için hangi dataset version ile eğitildiği bilinmiyorsa silme etkisini analiz etmek zorlaşır. Bu nedenle lineage, privacy operasyonunun temel altyapısıdır.

ML Sistemlerinde Compliance by Design

Compliance by design hukuki ve güvenlik kurallarını pipeline içinde otomatik uygulamayı hedefler. Region policy yanlış bölgede training job başlatılmasını engelleyebilir. Data classification hassas dataset'in external model API'ye gönderilmesini bloklayabilir. Retention policy eski artifact'ları otomatik temizleyebilir. Audit log bu kontrollerin gerçekten çalıştığını denetim sırasında gösterebilir.

Machine Unlearning Nedir?

Machine unlearning, belirli training verisinin model üzerindeki etkisini modelin tamamını her zaman sıfırdan eğitmeden azaltmayı veya kaldırmayı amaçlayan yöntemlerdir. Kullanıcı verisi database'den silinse bile model weight'leri önceki training örneğinden etkilenmiş olabilir. Tam retraining en güvenilir yöntemlerden biridir, fakat büyük modellerde pahalıdır. Approximate unlearning daha hızlı olabilir, ancak etkinliğinin doğrulanması gerekir. Silme taleplerinin ML pipeline'a bağlanması için güçlü dataset ve model lineage şarttır.

Veriyi Veri Tabanından Silmek Neden Yeterli Olmayabilir?

Training verisi model optimizasyonu sırasında ağırlıkları değiştirmiştir. Kaydı sonradan dataset'ten silmek mevcut model weight'lerini otomatik değiştirmez. Checkpoint ve backup kopyaları da veriyi içerebilir. Model memorization varsa belirli bilgi inference sırasında geri çıkabilir. Silme süreci bu nedenle model impact assessment içermelidir.

Training Data'nın Model Üzerindeki Etkisi

Her training örneğinin model üzerindeki etkisi aynı değildir. Duplicate veya rare örnek model tarafından daha fazla ezberlenebilir. Influence function ve privacy testleri belirli verinin etkisini tahmin etmeye çalışabilir. Differential privacy bu etkinin baştan sınırlanmasına yardımcı olur. Unlearning ihtiyacı model ve data type'a göre farklılaşır.

Retraining

Retraining ilgili veri çıkarıldıktan sonra modeli yeniden eğiterek en doğrudan yaklaşımı sağlar. Büyük dataset ve modelde ciddi GPU maliyeti oluşturabilir. Reproducible training pipeline süreci hızlandırır. Eski model artifact production'dan kaldırılmalıdır. Retraining sonrası aynı evaluation ve leakage testleri tekrar çalıştırılmalıdır.

Approximate Unlearning

Approximate unlearning belirli verinin etkisini daha düşük maliyetle azaltmaya çalışır. Model update, shard retraining veya influence-based yöntemler kullanılabilir. “Yaklaşık” olması nedeniyle residual influence ölçülmelidir. Kritik kişisel veri senaryosunda yeterlilik hukuk ve risk ekipleriyle değerlendirilmelidir. Unlearning sonucu audit kayıtlarına eklenmelidir.

Kullanıcı Silme Taleplerinin ML Pipeline'a Entegrasyonu

Silme talebi identity service üzerinden data catalog'a iletilebilir. Lineage hangi dataset ve model sürümünün etkilendiğini bulur. Dataset kopyaları silinir ve gerekiyorsa model retraining queue'ya alınır. Backup lifecycle ayrıca yönetilir. Talebin tamamlandığına dair evidence otomatik compliance report içine eklenebilir.

Modelin Kendisi Kişisel veya Hassas Veri Sızdırabilir mi?

Evet, model weight'leri doğrudan okunabilir kişisel kayıt taşımıyor olsa bile training verisi hakkında bilgi sızdırabilir. Memorization özellikle fazla tekrar eden veya unique örneklerde risk oluşturur. Membership inference bir örneğin training setinde olup olmadığını tahmin etmeye çalışırken model inversion ve extraction daha ayrıntılı veri çıkarmayı hedefleyebilir. Model artifact bu nedenle hassas güvenlik varlığı olarak korunmalıdır. Privacy red teaming model release sürecinin parçası olmalıdır.

Memorization

Model bazı training örneklerini genellemek yerine ezberleyebilir. Büyük ve yüksek kapasiteli modeller rare text veya identifier değerlerini hatırlayabilir. Deduplication ve regularization riski azaltabilir. Differential privacy daha formal koruma sağlar. Release öncesi canary data ile memorization testi yapılabilir.

Training Data Extraction

Training data extraction saldırganın model sorguları üzerinden eğitim örneklerini geri üretmeye çalışmasıdır. Query rate limit saldırı maliyetini artırabilir. Output confidence ve sampling davranışı risk üzerinde etkili olabilir. Hassas veride extraction red team senaryoları çalıştırılmalıdır. Başarılı extraction görülürse training pipeline ve model access policy gözden geçirilmelidir.

Membership Inference

Membership inference belirli kaydın eğitimde bulunup bulunmadığını tahmin eder. Training ve test loss farkının yüksek olması riski artırabilir. Model response'u gereğinden fazla confidence bilgisi taşımamalıdır. Differential privacy güçlü mitigation'dır. Model API rate limiting ve attack monitoring ek savunma sağlar.

Attribute Inference

Attribute inference bilinen bazı özelliklerden gizli bir özelliği tahmin etmeye çalışır. Model output ve public bilgi birlikte kullanılabilir. Kişisel profil çıkarımı açısından önemli privacy riskidir. Feature selection hassas attribute bağımlılığını azaltabilir. Risk assessment model kullanım bağlamını ve attacker knowledge seviyesini dikkate almalıdır.

Model Inversion

Model inversion output'lardan training sınıfının temsilî özelliklerini geri oluşturmayı hedefleyebilir. Yüz veya sağlık verisi gibi senaryolarda hassas sonuçlar doğurabilir. API erişimi ve confidence output sınırlandırılabilir. Privacy-preserving training kullanılabilir. Red team testi gerçek attack tool'larıyla yapılmalıdır.

Model Weight'lerinin Hassas Varlık Olarak Korunması

Model weight sadece IP değil potansiyel privacy surface'tir. Public bucket'ta tutulmamalıdır. Registry access least privilege ile sınırlandırılmalıdır. Artifact download loglanmalıdır. Signed model release supply chain integrity sağlar.

ML Model Supply Chain Güvenliği

Makine öğrenmesi modelleri çoğu zaman sıfırdan geliştirilmez. Pre-trained weight, Python package, container image ve dataset farklı kaynaklardan gelir. Zararlı model dosyası veya dependency production ortamında code execution riski yaratabilir. Model provenance, hash, signing ve güvenli registry bu zinciri güçlendirir. Supply chain güvenliği veri yerelliği kadar önemli çünkü güvenilmeyen artifact local sistemin içinde çalıştırıldığında dış saldırı yüzeyi yeniden oluşabilir.

Pre-Trained Model Kaynağı

Model yalnızca güvenilir repository veya doğrulanmış publisher'dan alınmalıdır. Rastgele file-sharing adresleri kullanılmamalıdır. Model card ve license incelenmelidir. Publisher identity doğrulanabiliyorsa kayıt altına alınmalıdır. Artifact internal registry'ye alınmadan önce security scan uygulanmalıdır.

Model Provenance

Model provenance artifact'ın nereden geldiğini ve hangi işlemlerden geçtiğini gösterir. Base model, fine-tuning dataset ve training code version ilişkilendirilebilir. Production modeli incident sırasında bu zincire kadar takip edilebilir. Provenance kaydı immutable metadata olarak tutulabilir. Bu bilgi vendor exit ve audit süreçlerinde de değerlidir.

Model Hash

Cryptographic hash model dosyasının integrity fingerprint'idir. Download sonrası beklenen hash ile karşılaştırılabilir. Artifact değiştirilirse hash farklı olur. Hash tek başına kaynağın güvenilirliğini kanıtlamaz. Publisher signature veya internal signing ile birlikte kullanıldığında daha güçlü kontrol sağlar.

Artifact Signing

Artifact signing modeli güvenilir build pipeline ile ilişkilendirir. Deployment sadece izinli signing key tarafından imzalanmış artifact kabul edebilir. Signing key güçlü HSM veya key management içinde tutulmalıdır. Compromise durumunda revocation ve re-signing planı gerekir. Signature verification CI/CD gate olarak otomatikleştirilebilir.

Zararlı Model Dosyaları

Bazı model serialization formatları load sırasında code execution riski taşıyabilir. Safe serialization formatları mümkün olduğunda tercih edilmelidir. Model dosyası güvenilmeyen ortamda doğrudan açılmamalıdır. Sandbox scanning ve static inspection uygulanabilir. Production service internetten runtime model indirmemelidir.

Dependency Security

ML framework ve yardımcı package'lar geniş dependency tree oluşturur. Known vulnerability scanning CI pipeline'a eklenmelidir. Version pinning reproducibility sağlar. Dependency update staging'de model regression ve security testinden geçmelidir. Kullanılmayan library'ler image'dan kaldırılmalıdır.

Python Package Supply Chain

Python ekosisteminde typo-squatting ve compromised package riskleri bulunabilir. Internal package mirror izinli dependency listesini kontrol edebilir. Hash pinning package integrity sağlar. Developer notebook'un production network'e sınırsız package install etmesi engellenebilir. Requirements veya lock file version control altında tutulmalıdır.

Model Registry Güvenliği

Model registry production artifact'larının merkezi kaynağıdır. Write erişimi yalnızca CI/CD veya onaylı ML release rolüne verilmelidir. Developer herkes production modelini overwrite edememelidir. Immutable version ve signing kullanılmalıdır. Registry audit logları security monitoring sistemine gönderilebilir.

Dataset Provenance ve Data Lineage

Dataset provenance verinin kaynağını, data lineage ise sistem içinde hangi dönüşümlerden geçtiğini gösterir. ML governance için bu bilgiler model performans logundan daha değerlidir. Belirli kullanıcı silme talebi geldiğinde hangi modelin etkilendiği ancak lineage ile bulunabilir. Aynı şekilde poisoning olayı olduğunda compromised data source hangi model release'lerini etkilediği izlenebilir. Hukuki dayanak, veri owner ve retention metadata'sı dataset catalog'a eklenebilir.

Veri Nereden Geldi?

Her dataset için source system ve collection tarihi bilinmelidir. Public dataset bile güvenilir kaynaktan mı geldiği açısından doğrulanmalıdır. Third-party data license ve kullanım amacı kayıt altına alınmalıdır. Data source değişirse model behavior değişebilir. Provenance bilgisi training artifact ile birlikte saklanmalıdır.

Kim Tarafından Değiştirildi?

Dataset transformation job veya kullanıcı değişiklikleri audit edilmelidir. Manuel CSV edit production dataset'te yapılmamalıdır. Data pipeline code review ve version control altında tutulmalıdır. Output hash değişikliği detect edilebilir. Change record ilgili training run ile ilişkilendirilmelidir.

Hangi Model Versiyonunda Kullanıldı?

Her training run dataset version ID kaydetmelidir. Model registry metadata'sında source dataset bulunmalıdır. Böylece dataset hatası keşfedildiğinde etkilenen modeller hızla bulunur. Silme ve retraining kararları kolaylaşır. Reproducibility de ciddi biçimde gelişir.

Hangi Hukuki Dayanakla İşlendi?

Kişisel veri içeren dataset için işleme dayanağı ve amacı data governance kaydında bulunabilir. ML engineer hukuk yorumlamak zorunda değildir, fakat approved usage metadata'sını görebilmelidir. Pipeline izin verilmeyen amaçta dataset kullanımını engelleyebilir. Yeni model amacı değişirse privacy review tetiklenir. Bu yaklaşım compliance ile engineering arasındaki iletişimi güçlendirir.

Data Lineage Kaydı

Lineage kaynak tablo, transformation, feature store ve model arasındaki bağlantıyı gösterir. Otomatik data catalog araçları bu ilişkiyi çıkarabilir. Kritik pipeline için manuel business metadata eklenebilir. Lineage grafiği data residency noktalarını da gösterebilir. Böylece hangi transformation'ın hangi region'da çalıştığı görülebilir.

Audit Trail

Audit trail kullanıcı ve sistem işlemlerini zaman sırasıyla kaydeder. Dataset erişimi, model publish ve key kullanımı önemli event'lerdir. Logların sonradan değiştirilmesi engellenmelidir. Immutable veya write-once storage değerlendirilebilir. Audit erişimi de privacy nedeniyle sınırlı olmalıdır.

Embedding ve Vector Database Verileri Güvenli midir?

Embedding ve vector database verilerini anonim kabul etmek riskli bir yaklaşımdır. Embedding kaynak metin hakkında semantic bilgi taşır ve metadata doğrudan identifier içerebilir. Vector database'in dışarı açılması RAG knowledge base sızıntısına yol açabilir. Region, encryption ve access control normal database kadar ciddi uygulanmalıdır. Self-hosted RAG düşünülürken embedding üretim servisi de aynı data residency analizine dahil edilmelidir.

Embedding'ler Hassas Bilgi Taşıyabilir mi?

Evet, embedding'ler orijinal verinin semantic temsilidir. Doğrudan okunabilir metin olmasa da similarity ve inversion teknikleri bilgi çıkarabilir. Hassas document embedding'leri confidential data gibi korunmalıdır. Public paylaşım yapılmamalıdır. Dataset silme talebinde ilgili embedding kayıtları da kaldırılmalıdır.

Vector Database Access Control

Vector DB collection bazlı access control desteklemelidir. Multi-tenant sistemde kullanıcı başka tenant collection'ını sorgulayamamalıdır. Application identity minimum read/write scope almalıdır. Admin erişimi JIT olabilir. Query ve export event'leri audit edilmelidir.

Region Pinning

Managed vector database seçerken data region sabitlenebilmelidir. Replica ve backup'ın başka region'a gitmediği doğrulanmalıdır. Control plane metadata kapsamı ayrıca incelenmelidir. Region policy change privileged işlem olmalıdır. Audit log yanlış relocation girişimini göstermelidir.

Encryption

Vector data at rest ve transit şifrelenmelidir. Customer-managed key support yüksek hassasiyetli projelerde değerlendirilebilir. Application tarafında field-level encryption arama kabiliyetini etkileyebilir. Backup encryption ayrı kontrol edilmelidir. Key rotation vector index erişimini kesintiye uğratmadan test edilmelidir.

RAG Sistemlerinde Veri Yerelliği

RAG sisteminde document store, embedding API, vector DB ve LLM inference endpoint ayrı bileşenlerdir. Bunlardan biri yabancı region kullanıyorsa data flow sınır dışına çıkabilir. Kullanıcı sadece document storage lokasyonuna bakarak yerellik sonucuna varmamalıdır. Her bileşenin region ve subprocessor bilgisi architecture inventory'de bulunmalıdır. RAG güvenlik incelemesi için https://www.diyarbakiryazilim.com.tr/posts/yapay-zeka-projelerinde-rag-retrieval-augmented-generation-mimarisi adresindeki teknik yaklaşım da yararlı bir devam okumasıdır.

Document store

Kaynak PDF, Word veya web içeriği document store'da bulunur. Bu katman çoğu zaman en hassas plaintext veriyi taşır. Access role ve retention açık olmalıdır. Source silindiğinde downstream chunk'lar da temizlenmelidir. Backup lokasyonu kontrol edilmelidir.

Embedding API

Embedding API chunk metnini uzak modele gönderebilir. Bu adım fark edilmeden yurt dışı transfer oluşturabilir. Local embedding modeli veri egress'i azaltabilir. Provider retention ve training policy kontrol edilmelidir. API payload loglanmamalıdır.

Vector DB

Vector DB embedding, metadata ve chunk text tutabilir. Region pinning ve tenant isolation uygulanmalıdır. Public endpoint kapatılabilir. Backup residency kontrol edilir. Query logging içinde hassas kullanıcı sorusu bulunmaması sağlanmalıdır.

LLM inference endpoint

Retrieval sonucu LLM inference endpoint'e context olarak gönderilir. Böylece şirket içi doküman parçası external provider'a çıkabilir. Local model veya sovereign endpoint gerekli olabilir. Prompt minimization uygulanmalıdır. Provider zero retention seçenekleri sözleşme ve teknik configuration ile doğrulanmalıdır.

ML API Kullanımında Veri Yerelliği

Bir ML API'ye istek gönderdiğinizde yalnızca endpoint URL'sine bakmak yeterli değildir. Payload'ın hangi region'da işlendiği, logların ne kadar tutulduğu ve alt işleyenlerin kim olduğu anlaşılmalıdır. Bazı sağlayıcılar veri training için kullanılmama veya zero retention seçenekleri sunabilir, fakat şartlar plan ve hizmet türüne göre değişebilir. Teknik ekip bu bilgiyi güncel sözleşme ve resmi dokümandan doğrulamalıdır. API gateway üzerinden gerçek gönderilen field'ları ölçmek data minimization için güçlü pratiktir.

API'ye Hangi Veriler Gönderiliyor?

Request body schema açıkça belgelenmelidir. Modelin kullanmadığı identifier ve metadata gönderilmemelidir. Debug header içinde hassas bilgi bulunmamalıdır. Proxy ile sample payload incelemesi yapılabilir. Schema change privacy review tetikleyebilir.

Provider Veriyi Saklıyor mu?

Provider request ve response'u abuse monitoring veya service operation amacıyla belirli süre saklayabilir. Retention süresi plan ve sözleşmeye göre farklı olabilir. “Model eğitimi için kullanmıyor” ifadesi “hiç saklamıyor” anlamına gelmez. Zero retention seçeneği varsa kapsamı doğrulanmalıdır. Log storage region da ayrıca sorulmalıdır.

Provider Veriyi Model Eğitimi İçin Kullanıyor mu?

Provider'ın customer data'yı kendi model training sürecinde kullanıp kullanmadığı contract içinde açık olmalıdır. Consumer hizmet ile enterprise API policy farklı olabilir. Opt-out mekanizması varsa default davranış kontrol edilmelidir. Hassas veri için sözleşmesel garanti tercih edilmelidir. Policy değişiklikleri vendor monitoring sürecine dahil edilmelidir.

Inference Hangi Bölgede Çalışıyor?

API endpoint global olabilir ve request farklı region'a yönlenebilir. Provider region-specific inference seçeneği sunuyorsa kullanılmalıdır. GPU execution location teknik olarak doğrulanabilmelidir. Failover sırasında başka region'a geçiş olup olmadığı sorulmalıdır. Residency requirement varsa global routing kapatılmalıdır.

Alt Veri İşleyenler Kim?

Provider infrastructure, support veya analytics için başka şirketlerden hizmet alabilir. Subprocessor listesi düzenli takip edilmelidir. Yeni taraf eklendiğinde notification mekanizması bulunmalıdır. Hangi subprocessor'ın customer content'e erişebildiği ayrıştırılmalıdır. Data transfer map bu bilgileri içermelidir.

Log Retention Süresi Nedir?

Request log retention privacy riskini doğrudan etkiler. Short retention ve redaction tercih edilir. Production debug amacıyla süresiz ham prompt saklanmamalıdır. Provider ve kurum tarafındaki retention farklı olabilir. Silme API'si varsa otomatik lifecycle sürecine bağlanabilir.

Zero Data Retention Nedir?

Zero data retention hizmetin kullanıcı content'ini kalıcı log veya training amacıyla saklamamasını hedefleyen özelliktir. Ancak operational metadata'nın kapsamı ayrıca incelenmelidir. Her endpoint veya özellik ZDR kapsamında olmayabilir. Provider'ın resmi teknik ve sözleşmesel açıklaması doğrulanmalıdır. ZDR güçlü kontrol olsa da data transfer ve processing location sorularını ortadan kaldırmaz.

Inference Residency Nedir?

Inference residency model prediction işleminin hangi coğrafi bölgede gerçekleştirildiğine odaklanır. Storage Türkiye'de olabilir, fakat request başka ülkedeki GPU cluster'da işlenebilir. Bu nedenle storage residency ile inference residency ayrı teknik gereksinimlerdir. Global API routing, tool çağrıları ve content moderation servisleri ek egress noktaları oluşturabilir. Uçtan uca yerellik ancak request'in bütün işlem zincirinde takip edilmesiyle doğrulanabilir.

Storage Residency ile Farkı

Storage residency verinin kalıcı olarak nerede tutulduğunu anlatır. Inference residency ise geçici processing lokasyonudur. Aynı servis iki konuda farklı garanti verebilir. Backup storage üçüncü ayrı lokasyon olabilir. Contract ve architecture dokümanları her alanı ayrı belirtmelidir.

GPU Execution Lokasyonu

Model inference çoğu zaman GPU worker üzerinde gerçekleşir. Scheduler request'i farklı availability zone veya region'a yönlendirebilir. Residency policy GPU node pool'u izinli bölgeyle sınırlandırmalıdır. Confidential GPU ek data-in-use security sağlayabilir. Execution logs region bilgisini audit için kaydedebilir.

CPU Processing ve Routing

GPU öncesi tokenization veya preprocessing CPU servisinde yapılabilir. Global load balancer request'i başka country edge noktasından geçirebilir. Bu metadata veya content transfer anlamına gelebilir. Routing architecture detaylı incelenmelidir. Private regional endpoint daha güçlü locality sağlayabilir.

External Tool Kullanımında Veri Egress

Model local çalışsa bile external tool çağrısı kullanıcı context'ini dışarı gönderebilir. Agent web search, CRM veya translation API kullanabilir. Tool description hangi field'ların gönderildiğini açıkça tanımlamalıdır. Data classification tool permission ile eşleştirilebilir. Hassas workflow için external tool default olarak kapalı tutulabilir.

Gerçek Uçtan Uca Yerellik Nasıl Doğrulanır?

Data flow diagram başlangıç dokümanıdır. Network egress logları gerçek endpoint'leri gösterir. Storage ve compute resource region tag'leri policy engine ile doğrulanabilir. Provider audit report ve contract ek kanıt sağlar. Periodic penetration ve residency testleri documentation drift'i yakalayabilir.

MLOps Sistemlerinde Veri Güvenliği

MLOps pipeline model geliştirme sürecini otomatikleştirirken geniş bir yetki alanına sahip olabilir. CI runner dataset okuyabilir, model registry'ye yazabilir ve production deployment yapabilir. Bu nedenle pipeline credential'ları en hassas secret'lar arasındadır. Feature store, experiment tracking, registry ve monitoring aynı security architecture içinde değerlendirilmelidir. MLOps güvenliği hem software supply chain hem data governance kontrolü olarak ele alınmalıdır.

Secure Data Pipeline

Data pipeline source'tan training ortamına kadar şifreli ve kimlik doğrulanmış bağlantı kullanmalıdır. Job identity sadece ihtiyaç duyduğu dataset'e erişmelidir. Temporary storage otomatik temizlenmelidir. Schema ve data quality değişiklikleri validation gate'ten geçmelidir. Lineage her dönüşümü kaydetmelidir.

Secret Management

Database password veya API key notebook içinde tutulmamalıdır. Central secret manager kullanılmalıdır. Workload identity mümkün olduğunda uzun süreli static credential'ın yerini almalıdır. Secret rotation otomatikleştirilebilir. Access audit edilmeli ve unused secret silinmelidir.

Model Registry

Registry model lifecycle'ın güvenilir kaynağıdır. Development model doğrudan production label alamamalıdır. Approval workflow kullanılabilir. Artifact signing ve immutable version desteklenmelidir. Download ve promotion event'leri audit log'a yazılmalıdır.

Feature Store

Feature store hem training hem inference tarafından kullanıldığı için yüksek değerli veri katmanıdır. Offline ve online access ayrı yetkilerle yönetilebilir. Sensitive feature masking uygulanabilir. Region ve backup policy data classification ile eşleşmelidir. Feature deletion kullanıcı silme talebine bağlanabilir.

CI/CD

CI/CD runner production environment'a sınırlı süreli credential almalıdır. Pull request code review olmadan model pipeline değişmemelidir. Dependency scan ve artifact signing build aşamasına eklenir. Deployment policy sadece onaylı registry artifact kabul eder. Pipeline loglarında secret masking yapılmalıdır.

Experiment Tracking

Experiment platformu metric ile birlikte sample input veya prompt saklayabilir. Bu nedenle düşük riskli telemetry olduğu varsayılmamalıdır. Logging schema önceden tanımlanmalıdır. Production data sample upload kapatılabilir. Retention ve region policy uygulanmalıdır.

Monitoring

Infrastructure ve model behavior birlikte izlenmelidir. Security monitoring anomalous access ve network egress event'lerini toplar. Model monitoring drift ve unusual prediction pattern'i ölçer. Privacy monitoring query abuse veya extraction davranışını işaretleyebilir. Alarm action runbook ile ilişkilendirilmelidir.

Audit Logging

Kim hangi dataset'i okudu, hangi modeli publish etti ve hangi key'i kullandı soruları audit log ile cevaplanmalıdır. Loglar append-only veya immutable storage'a gönderilebilir. Administrator kendi log kaydını silememelidir. Time synchronization incident timeline için önemlidir. Retention hukuki ve security ihtiyaçlarına göre belirlenmelidir.

Backup

MLOps metadata, registry ve feature store backup planına dahil edilmelidir. Sadece database restore model artifact olmadan işe yaramayabilir. Backup encryption ve residency kontrol edilir. Restore test staging environment'ta yapılır. Dependency ve model registry recovery sırası runbook içinde bulunmalıdır.

ML Logları Gizli Veri Sızdırabilir mi?

Evet, ML logları gizli veri sızıntısının en sık gözden kaçan kaynaklarından biridir. Training exception bir satır sample data'yı yazdırabilir veya inference log tam request body'yi saklayabilir. Prompt ve response logging kullanıcıların bilinçsizce gönderdiği hassas metni kalıcı hâle getirebilir. PII redaction ve structured logging bu riski azaltır. Log storage region, retention ve access policy production database kadar ciddi yönetilmelidir.

Training Logs

Training code debug amacıyla batch sample yazdırmamalıdır. Dataset path ve identifier bile hassas metadata olabilir. Loss ve aggregate metric çoğu monitoring ihtiyacı için yeterlidir. Error stack trace veri içerebilir. Log review testleri privacy pipeline'ın parçası olabilir.

Inference Logs

Inference access log input veya output'u default olarak kaydetmemelidir. Request ID troubleshooting için çoğu durumda yeterlidir. Gerekirse sample logging düşük oran ve masking ile yapılabilir. User identifier pseudonymous tutulabilir. Production incident dışında full payload logging süreli ve onaylı olmalıdır.

Debug Logs

Debug level en fazla veri sızdıran log seviyesidir. Production'da sürekli açık kalmamalıdır. Geçici aktivasyon otomatik expiry ile yapılabilir. Hassas field redaction library genel logging katmanında uygulanmalıdır. Incident bitince debug log retention kısaltılmalıdır.

Prompt ve Response Logging

Generative ML sistemlerinde prompt kullanıcı sırları veya kişisel veri içerebilir. Response da kaynak dokümandan hassas bilgi üretebilir. Quality evaluation için tüm konuşmaları saklamak yerine kullanıcı izinli sample veya synthetic dataset kullanılabilir. Prompt hash belirli analitik ihtiyaçlarda içeriği saklamadan ölçüm sağlayabilir. Log erişimi support personeline otomatik verilmemelidir.

PII Redaction

PII redaction log yazılmadan önce e-posta, telefon veya identifier gibi alanları maskeler. Rule-based ve ML tabanlı yöntemler birlikte kullanılabilir. False negative riski bulunduğu için hassas field'ları schema seviyesinde hiç loglamamak daha güçlüdür. Redaction pipeline kendisi de test edilmelidir. Maskelenmiş değer gerektiğinde correlation için tokenized biçimde tutulabilir.

Log Retention

Log retention operational ihtiyaçtan uzun olmamalıdır. Security log ve application debug log farklı süreye sahip olabilir. Automatic lifecycle deletion kullanılmalıdır. Backup içinde eski log bulunuyorsa ayrıca policy gerekir. Retention değişikliği security ve privacy ekiplerince review edilmelidir.

Log Storage Residency

Central log platformu farklı cloud region'da bulunabilir. Bu durumda production data local olsa bile loglar yurt dışına çıkabilir. SIEM vendor data processing terms kontrol edilmelidir. Regional collector kullanılabilir. Hassas logları local tutup sadece alert metadata göndermek alternatif architecture olabilir.

Kimlik ve Erişim Yönetimi

ML güvenliğinde güçlü identity yönetimi network firewall kadar önemlidir. Data engineer, ML engineer, security engineer ve platform administrator aynı yetkilere sahip olmamalıdır. Least privilege ve separation of duties özellikle production model registry ve encryption key üzerinde kritik koruma sağlar. Managed identity static credential kullanımını azaltabilir. JIT privileged access yüksek yetkinin yalnızca ihtiyaç anında kısa süreli verilmesini sağlar.

Least Privilege

Kullanıcı ve workload yalnızca görev için gerekli yetkiyi almalıdır. Training job production customer table'ın tamamına erişmek zorunda olmayabilir. Read ve write permission ayrı tutulur. Temporary access otomatik sona erebilir. Permission usage audit edilerek kullanılmayan haklar kaldırılır.

Role-Based Access Control

RBAC yetkileri kullanıcı yerine role bağlar. Data scientist, model deployer ve auditor ayrı role sahip olabilir. Role inheritance gereksiz geniş yetki yaratmamalıdır. Production write role az sayıda kullanıcıya verilir. Düzenli access certification uygulanır.

Attribute-Based Access Control

ABAC karar verirken kullanıcı, veri ve ortam attribute'larını birlikte kullanır. Department, data classification ve region policy aynı erişim kuralında değerlendirilebilir. Örneğin confidential dataset yalnızca Türkiye'deki managed device üzerinden erişilebilir olabilir. Policy engine merkezi governance sağlar. Attribute kaynaklarının güvenilir olması gerekir.

Managed Identity

Managed identity workload'un static API key olmadan hizmetlere erişmesini sağlar. Credential rotation platform tarafından yönetilebilir. Training job farklı storage ve registry için ayrı identity kullanabilir. Identity theft etkisi kısa ömürlü token ile azaltılır. Cloud ve Kubernetes ortamlarında workload identity tercih edilmelidir.

Just-in-Time Privileged Access

JIT yüksek yetkinin sürekli açık tutulmasını önler. Administrator belirli süre ve gerekçeyle role activation yapar. MFA ve manager approval eklenebilir. Session loglanabilir. Süre sonunda permission otomatik kaldırılır.

Separation of Duties

Separation of duties tek kişinin dataset, training ve production deployment üzerinde sınırsız kontrol sahibi olmasını önler. Model developer kendi build'ini tek başına production'a alamayabilir. Security engineer key policy yönetirken data engineer data pipeline yönetir. Bu yaklaşım insider ve yanlışlık riskini azaltır. Küçük ekiplerde de kritik adımlar için iki kişi onayı uygulanabilir.

Data engineer

Data engineer source ve transformation pipeline'ını yönetebilir. Production model deployment yetkisine ihtiyacı olmayabilir. Sensitive raw dataset access rol bazlı verilir. Schema ve quality değişiklikleri audit edilir. Data export sınırlandırılabilir.

ML engineer

ML engineer approved dataset view'ları üzerinden model geliştirir. Raw kişisel veri erişimi her zaman gerekli değildir. Registry development namespace'e yazabilir. Production promotion için ayrı approval gerekir. Experiment logları privacy policy'ye uymalıdır.

Security engineer

Security engineer policy, threat model ve incident response süreçlerini yönetir. Dataset business content'ine sürekli erişmesi gerekmez. Key policy ve network rule review yapabilir. Audit log üzerinde read-only erişim yeterli olabilir. Production model weight değişikliği yapmamalıdır.

Platform administrator

Platform administrator cluster ve runtime yönetir. Application verisine mümkün olduğunca erişmemelidir. Confidential computing privileged operator riskini azaltabilir. Admin session JIT ve recorded olabilir. Root credential shared account olarak kullanılmamalıdır.

Zero Trust Yaklaşımı ML Sistemlerine Nasıl Uygulanır?

Zero Trust yaklaşımı network içinde bulunmayı otomatik güven kanıtı saymaz. Her kullanıcı, workload ve connection identity üzerinden doğrulanır. ML cluster internal network'te olsa bile model registry ve feature store erişimi ayrı kontrol edilir. Private endpoint ve egress restriction attack surface'i azaltır. Continuous verification device, session ve workload durumundaki değişiklikleri erişim kararına yansıtır.

Never Trust, Always Verify

Her access request kimlik ve policy doğrulamasından geçer. Internal IP tek başına yetki vermez. Training job signed workload identity ile authentication yapar. Device posture privileged kullanıcı erişiminde değerlendirilebilir. Session boyunca risk yeniden kontrol edilir.

Identity-Based Access

Network location yerine kullanıcı ve workload identity ana karar girdisidir. Certificate veya short-lived token kullanılır. Service account paylaşımı önlenir. Identity'nin hangi dataset ve model artifact'a erişebildiği policy ile belirlenir. Audit log insan ve machine identity'yi ayrı gösterir.

Network Segmentation

Training, inference, management ve data storage ayrı network segmentlerinde tutulabilir. Lateral movement sınırlandırılır. GPU worker'ın admin network'e erişmesine gerek yoktur. Firewall rule default deny yaklaşımı kullanabilir. Segmentler arası trafik loglanır.

Private Endpoints

Storage, registry ve model API için public internet endpoint'i kapatılabilir. Workload private IP üzerinden erişir. DNS private zone üzerinden çözülür. Data egress riski azalır. Authentication yine zorunlu tutulur.

Egress Control

Egress control workload'un hangi dış hedeflere bağlanabileceğini sınırlar. Training notebook her internet sitesine erişmek zorunda değildir. Package repository allowlist oluşturulabilir. Sensitive model API sadece approved domain'e erişir. Beklenmeyen outbound trafik security alarmı üretir.

Continuous Verification

Kullanıcı login olduktan sonra sonsuza kadar güvenilir sayılmaz. Device compromise veya role change erişimi etkileyebilir. Short-lived token tekrar authorization sağlar. High-risk işlem tekrar MFA isteyebilir. ML platform audit ve identity signal'larını sürekli değerlendirebilir.

ML Veri Güvenliği İçin Threat Modeling

Threat modeling korunan varlıkları, saldırganları ve trust boundary'leri sistem geliştirilmeden önce görünür hâle getirir. ML projelerinde dataset, model weight, gradient ve inference input ayrı asset olarak listelenmelidir. Classic STRIDE yaklaşımı API ve infrastructure tehditlerini incelerken ML-specific senaryolar poisoning, model extraction ve membership inference gibi ek riskler getirir. Data flow diagram threat model için en güçlü başlangıç belgesidir. Her threat için preventive, detective ve recovery kontrolleri belirlenmelidir.

Korunan Varlıkları Belirleme

İlk adım neyi koruduğunuzu bilmektir. Dataset, model, source code, key, feature store ve user prediction farklı değer taşır. Her asset confidentiality, integrity ve availability açısından skorlanabilir. Owner belirtilmelidir. Korunacak asset bilinmeden güvenlik kontrolü seçmek etkisiz olur.

Trust Boundary

Trust boundary farklı güven seviyelerindeki sistemlerin buluştuğu noktadır. User API ile inference service, cloud ile on-prem veya client ile federated server boundary oluşturabilir. Boundary üzerinden geçen veri sınıfı kaydedilir. Authentication ve encryption bu noktalarda güçlendirilir. External provider ayrı trust zone olarak ele alınmalıdır.

Threat Actor'ları Belirleme

External attacker, malicious insider, compromised client ve curious provider farklı threat actor'lardır. Her biri farklı erişim seviyesine sahiptir. Federated client poisoning yapabilirken cloud operator memory access tehdidi oluşturabilir. Model API kullanıcısı extraction deneyebilir. Threat model bütün actor'ları aynı kategoriye koymamalıdır.

Attack Surface

API endpoint, notebook, model registry, package manager ve object storage attack surface'in parçalarıdır. Public endpoint sayısı azaltılmalıdır. Unused service kapatılmalıdır. Model file upload ayrıca malware surface yaratabilir. Attack surface inventory sürekli güncellenmelidir.

STRIDE Yaklaşımı

STRIDE spoofing, tampering, repudiation, information disclosure, denial of service ve elevation of privilege kategorilerini kullanır. ML API üzerinde spoofed user, dataset tampering ve model DoS senaryoları bu çerçevede analiz edilebilir. ML-specific threat'ler ayrıca eklenir. Her data flow edge STRIDE ile gözden geçirilebilir. Sonuç risk register'a aktarılır.

ML'e Özgü Saldırı Senaryoları

ML sistemleri klasik application risklerine ek olarak training ve model davranışını hedefleyen saldırılara sahiptir. Data poisoning model integrity'yi bozar. Membership inference privacy'yi, model extraction fikri mülkiyeti etkiler. Gradient leakage federated learning için özel risktir. Supply-chain attack pre-trained artifact üzerinden production runtime'ı tehlikeye atabilir.

Data poisoning

Saldırgan training verisine kötü örnek ekler. Amaç genel accuracy'yi düşürmek veya belirli trigger davranışı oluşturmaktır. Dataset provenance ve anomaly detection kullanılabilir. High-risk data source quarantine edilebilir. Retraining sonrası validation sadece aggregate metric'e bakmamalıdır.

Membership inference

Saldırgan modelin belirli kaydı eğitimde görüp görmediğini tahmin eder. Overfitting riski artırabilir. Differential privacy mitigation sağlar. API rate limit saldırı ölçeğini azaltır. Release öncesi attack simulation yapılabilir.

Model extraction

Model extraction çok sayıda sorguyla model davranışını kopyalamaya çalışır. Rate limit ve anomaly detection uygulanabilir. High-value API output precision sınırlandırılabilir. Watermark veya fingerprinting yardımcı olabilir. Extraction monitoring user ve IP pattern'lerini analiz eder.

Gradient leakage

Federated update training verisi hakkında bilgi sızdırabilir. Secure aggregation tekil update visibility'sini azaltır. Differential privacy əlavə koruma sağlar. Batch size ve clipping parametreleri optimize edilir. Gradient logları tutulmamalıdır.

Supply-chain attack

Malicious model veya dependency trusted pipeline içine sızabilir. Artifact signing ve SBOM kullanılabilir. Internal registry sadece verified package kabul eder. Build runner internetten rastgele dependency çekmemelidir. Runtime image immutable olmalıdır.

ML Güvenliğinde Red Teaming

Red teaming güvenlik kontrollerinin gerçek saldırı senaryoları altında nasıl davrandığını ölçer. ML projesinde sadece web penetration testi yapmak model privacy riskini yeterince test etmez. Membership inference, training extraction, inversion, poisoning ve data egress denemeleri eklenmelidir. Sonuçlar severity ve reproducibility ile kayıt altına alınmalıdır. Model veya pipeline güncellendiğinde yüksek riskli testler regression suite olarak tekrar çalıştırılabilir.

Privacy Attack Simulation

Privacy attack simulation saldırganın sahip olabileceği API ve auxiliary data seviyesini taklit eder. Black-box ve white-box senaryolar ayrı çalıştırılabilir. Başarı oranı baseline modelle karşılaştırılır. Attack sonucu sadece “başarılı/başarısız” yerine risk metriği üretmelidir. Mitigation sonrası aynı test tekrar edilmelidir.

Membership Inference Testi

Train ve holdout örnekler üzerinden attacker model geliştirilir. Hedef model output davranışı karşılaştırılır. Attack advantage yüksekse overfitting ve privacy parametreleri incelenir. DP training değerlendirilebilir. API response granularity azaltılabilir.

Training Data Extraction Testi

Model kontrollü canary örneklerle eğitilebilir. Red team bu canary içeriğini sorgu yoluyla geri çıkarmaya çalışır. Başarı memorization riskini gösterir. Data deduplication ve privacy training sonrası test tekrarlanır. Production gerçek kişisel veri kullanılmadan güvenli lab kurulabilir.

Model Inversion Testi

Model output üzerinden representative input oluşturma saldırısı denenir. White-box erişim varsa risk seviyesi ayrı ölçülür. Hassas sınıfların reconstruction kalitesi incelenir. Output confidence azaltma ve DP gibi kontroller karşılaştırılır. Sonuç privacy risk register'a eklenir.

Poisoning Testi

Training dataset'in küçük kısmına kontrollü malicious sample eklenir. Modelin genel ve trigger-specific performansı ölçülür. Data quality guardrail'lerinin saldırıyı yakalayıp yakalamadığı kontrol edilir. Federated senaryoda malicious client simulation yapılabilir. Robust aggregation sonrası sonuç karşılaştırılır.

Data Egress Testi

Workload'un izin verilmeyen external endpoint'e veri göndermeye çalışması test edilir. Egress firewall'ın çağrıyı bloklaması beklenir. DNS tunneling ve metadata endpoint erişimi değerlendirilebilir. Log alarmının oluştuğu doğrulanır. Bu test data residency policy'nin teknik olarak enforce edildiğini gösterir.

Veri Yerelliği Nasıl Denetlenir?

Veri yerelliği yalnızca provider'ın satış dokümanındaki region ifadesine güvenilerek denetlenemez. Data flow mapping, configuration policy, network telemetry ve provider audit bilgileri birlikte kullanılmalıdır. Storage ve processing location ayrı kontrol edilmelidir. Egress monitoring beklenmeyen API ve support bağlantılarını gösterebilir. Immutable audit log, region veya key policy değişikliklerini denetim sırasında kanıtlamaya yardımcı olur.

Data Flow Mapping

Her veri kaynağı ve hedefi diagram üzerinde gösterilir. Storage, training, inference, log ve backup node'ları dahil edilir. Her edge veri kategorisi ve region bilgisi taşır. Third-party processor ayrıca işaretlenir. Diagram application release ile birlikte güncellenmelidir.

Region Policy

Infrastructure-as-code policy sadece izinli region'da resource oluşturulmasına izin verebilir. Deployment yanlış location seçtiğinde CI fail olur. Administrator exception prosedürü tanımlanabilir. Region tag zorunlu kılınabilir. Policy drift otomatik scanning ile tespit edilir.

Storage Location Verification

Database ve bucket resource metadata'sı programatik olarak kontrol edilebilir. Replica ve backup ayrıca listelenmelidir. Scheduled compliance job region değerini doğrulayabilir. Değişiklik alarm üretir. Provider portal ekran görüntüsü yerine API tabanlı evidence daha güvenilirdir.

Processing Location Verification

Compute node, GPU pool ve serverless job region bilgisi izlenmelidir. Global endpoint'in gerçek execution location bilgisini provider sunabiliyor mu kontrol edilir. Job scheduler policy sadece izinli pool seçer. Fallback region devre dışı bırakılabilir. Audit log execution region'i kaydedebilir.

Network Egress Monitoring

Firewall ve proxy outbound destination'ları kaydeder. Yeni external domain görülürse alarm oluşturulabilir. DNS query logları da yardımcı sinyal sağlar. Hassas workload default deny kullanabilir. Approved endpoint listesi change management ile güncellenir.

Provider Audit

Provider security sertifikası tek başına residency kanıtı değildir. Audit scope, region ve subprocessor bilgisi incelenmelidir. Data processing agreement ile teknik dokümantasyon karşılaştırılır. Müşteri audit hakkı yüksek riskli sözleşmede değerlendirilebilir. Sağlayıcı değişiklikleri yıllık değil sürekli vendor management sürecinde takip edilmelidir.

Attestation

Confidential computing attestation workload'un beklenen hardware ve code üzerinde çalıştığını doğrular. Region bilgisinin attestation claim içinde bulunup bulunmadığı teknolojiye göre değişir. Secret release policy ek location signal kullanabilir. Attestation loglanmalıdır. Hardware security version minimum baseline olarak belirlenebilir.

Immutable Audit Logs

Compliance kanıtı sonradan değiştirilebilir normal application loguna bırakılmamalıdır. Immutable storage veya append-only log kullanılabilir. Region change, key usage ve privileged access event'leri kaydedilir. Retention denetim ihtiyacına göre belirlenir. Log encryption ve access policy uygulanır.

Backup ve Disaster Recovery Veri Yerelliğini Bozabilir mi?

Evet, backup ve disaster recovery en sık unutulan data residency noktalarıdır. Production database doğru ülkede çalışırken otomatik snapshot farklı region'a kopyalanabilir. Cross-region failover bir kesinti sırasında veriyi izin verilmeyen lokasyonda işleyebilir. Encryption key replica başka jurisdiction'da tutulabilir. DR tasarımı availability hedefi kadar residency ve sovereignty hedefini de korumalıdır.

Cross-Region Replication

Cross-region replication yüksek availability sağlar. Ancak her target region privacy policy'ye uygun olmalıdır. Hassas dataset için sadece aynı ülke içi zone replication tercih edilebilir. Provider default replication davranışı kontrol edilmelidir. IaC policy unauthorized replication'ı engelleyebilir.

Snapshot Lokasyonu

Snapshot hangi region'da saklandığı production diskten bağımsız ayardır. Automated backup service default global storage kullanabilir. Snapshot tag data classification içermelidir. Copy permission sınırlandırılmalıdır. Restore test yalnızca izinli region'da yapılmalıdır.

Disaster Recovery Region

DR region failover anında gerçek production region olur. Bu nedenle normal zamanda kullanılmaması residency gereksinimini ortadan kaldırmaz. Hukuki ve teknik onay önceden alınmalıdır. DNS failover sadece approved region'a yönelmelidir. Annual DR test veri lokasyonunu doğrulamalıdır.

Encryption Key Replication

Cross-region encrypted backup için key replication gerekebilir. External key modelinde region key availability planlanmalıdır. Aynı key'i bütün ülkelerde kullanmak sovereignty hedefini zayıflatabilir. Region-specific key policy oluşturulabilir. Disaster recovery sırasında key access test edilmelidir.

Backup Retention

Backup retention production data'dan daha uzun olursa silinmiş kayıtlar backup içinde kalabilir. Hukuki ve business retention birlikte belirlenmelidir. Immutable backup ransomware koruması sağlar, fakat silme süreçlerini zorlaştırır. Expiry policy otomatik uygulanmalıdır. Backup catalog hangi dataset'in hangi tarihe kadar tutulduğunu göstermelidir.

Secure Deletion

Cloud object deletion altta fiziksel medyanın hemen sıfırlanması anlamına gelmeyebilir. Provider secure deletion policy incelenmelidir. Encryption key destruction crypto-shredding yaklaşımı sağlayabilir. On-premise disk decommission sırasında secure erase veya physical destruction uygulanabilir. Silme evidence'ı audit kaydında tutulmalıdır.

Veri Güvenliğinde Model Performansı ve Maliyet

Güvenlik architecture seçimi toplam ML maliyetini doğrudan etkiler. On-premise GPU yatırımı yüksek olabilirken cloud egress ve sovereign hizmet premium ücret oluşturabilir. Encryption ve privacy teknikleri compute overhead yaratabilir. Bunun karşılığında veri ihlali, regülasyon sorunu ve vendor lock-in de uzun vadeli maliyettir. TCO modeli yalnızca GPU saatini değil security operation, audit, backup ve insan kaynağını da içermelidir.

On-Prem GPU Maliyeti

GPU satın alma maliyetine elektrik, soğutma ve bakım eklenir. Donanım birkaç yıl içinde model gereksinimlerinin gerisinde kalabilir. Yüksek utilization varsa birim inference maliyeti düşebilir. Düşük kullanım cloud daha ekonomik olabilir. Capacity planning gerçek workload ölçümüne dayanmalıdır.

Sovereign Cloud Premium

Sovereign hizmet ek lokasyon ve operasyon kontrolleri nedeniyle daha yüksek fiyatlı olabilir. Bu premium compliance riskini azaltıyorsa kabul edilebilir. Hangi sovereignty özelliğinin fiyatı artırdığı anlaşılmalıdır. Sadece pazarlama etiketi için ödeme yapılmamalıdır. Contract ve technical control mapping ile değer ölçülmelidir.

Network Egress Maliyeti

Cloud'dan büyük dataset çıkarmak egress ücreti yaratabilir. Hybrid training sürekli data transfer ediyorsa maliyet büyür. Data locality performansla birlikte maliyeti de iyileştirebilir. Cache ve feature preprocessing transferi azaltabilir. Vendor exit planında büyük model ve dataset export maliyeti önceden hesaplanmalıdır.

Encryption Overhead

TLS ve disk encryption overhead'i modern hardware üzerinde genellikle düşüktür. FHE ve MPC çok daha yüksek compute maliyeti oluşturabilir. Confidential computing belirli workload'da orta düzey overhead yaratabilir. Benchmark olmadan varsayım yapılmamalıdır. Security requirement ile latency SLO aynı testte ölçülmelidir.

Federated Learning Communication Cost

Federated round model update'lerini birçok client arasında taşır. Büyük weight dosyası network maliyeti oluşturur. Compression communication maliyetini azaltabilir. Client selection bağlantı kalitesine göre yapılabilir. Cross-silo private link sabit ama öngörülebilir maliyet sunabilir.

Privacy–Accuracy Trade-Off

DP noise model accuracy'sini etkileyebilir. Daha fazla data bu etkiyi azaltmaya yardımcı olabilir. Rare class performansı özellikle izlenmelidir. Privacy parameter business risk seviyesine göre belirlenmelidir. Model release report privacy ve accuracy metriklerini birlikte göstermelidir.

Güvenlik Seviyesine Göre Toplam Sahip Olma Maliyeti

TCO infrastructure, software license, platform personeli, security operation ve compliance maliyetini içerir. High-assurance system daha pahalı olabilir. Risk reduction değeri de hesaplanmalıdır. On-premise ve cloud karşılaştırması sadece aylık GPU ücretine indirgenmemelidir. Üç yıllık scenario model daha gerçekçi karar sağlar.

Açık Kaynak Modeller Veri Yerelliğini Nasıl Etkiler?

Open-weight modeller kurumun inference'ı kendi altyapısında çalıştırmasına olanak sağlayarak data locality açısından önemli avantaj sunabilir. Prompt ve input harici API'ye gönderilmez. Model version ve serving configuration üzerinde daha fazla kontrol elde edilir. Ancak model artifact'ın kaynağı, lisansı ve supply chain güvenliği ayrıca doğrulanmalıdır. Açık model kullanmak otomatik olarak güvenli sistem anlamına gelmez, fakat veri akışı üzerinde daha fazla teknik kontrol sağlayabilir.

Open-Weight Model Nedir?

Open-weight model eğitim sonunda elde edilen weight dosyalarının erişilebilir olduğu modeldir. Kaynak kod veya training dataset'in tamamen açık olması zorunlu değildir. Lisans şartları kullanım alanını etkileyebilir. Weight internal registry'ye alınabilir. Production öncesi security ve quality validation yapılmalıdır.

Self-Hosted Inference

Model kurum GPU'sunda veya kontrol edilen cloud instance üzerinde çalıştırılabilir. Input third-party model API'ye gönderilmez. Network egress daha güçlü sınırlandırılabilir. Model serving stack patch ve scaling kurum sorumluluğundadır. High utilization'da maliyet avantajı oluşabilir.

Veriyi Harici API'ye Göndermeme

Local inference hassas prompt ve feature'ın dış provider'a çıkmasını engelleyebilir. Embedding veya telemetry hâlâ dış servis kullanıyorsa tam yerellik sağlanmaz. Egress policy bütün pipeline'ı kapsamalıdır. Model update download sırasında sadece artifact alınır, kullanıcı data'sı gönderilmez. Network monitoring bu davranışı doğrulayabilir.

Model Kontrolü

Kurum model version'ını istediği süre boyunca sabitleyebilir. Provider tarafındaki beklenmeyen model değişikliği riski azalır. Safety ve patch update kurum tarafından planlanır. Fine-tuned weight internal kalır. Model rollback daha kontrollü yapılabilir.

Vendor Lock-In'in Azaltılması

Açık model standard serving API üzerinden farklı hardware üzerinde çalıştırılabilir. Dataset ve model artifact kurum kontrolünde tutulur. Cloud provider değişikliği daha kolay olabilir. Ancak accelerator ve optimization stack yeni bağımlılıklar yaratabilir. Exit test belirli aralıklarla başka environment'ta çalıştırılabilir.

Açık Model Kullanmanın Güvenlik Riskleri

Model dosyası zararlı serialization içerebilir. Kaynağı bilinmeyen weight kullanılmamalıdır. Modelin training data provenance'i belirsiz olabilir. Prompt safety ve output güvenliği kurum tarafından yönetilir. Security patch provider-managed API'ye göre daha fazla operasyon gerektirir.

Open Source ve İşbirliği ile Privacy-Preserving ML

Privacy-preserving ML alanında açık kaynak ekosistem öğrenme ve prototip geliştirmeyi hızlandırır. Federated learning, differential privacy, MPC ve homomorphic encryption için farklı projeler bulunmaktadır. Bu araçları doğrudan production'a almak yerine threat model ve maintenance durumuna göre değerlendirmek gerekir. Açık kaynak olması güvenlik açığı olmadığı anlamına gelmez. Topluluk benchmark'ları ve code review ise tekniklerin gerçek performans ve privacy özelliklerini anlamayı kolaylaştırır.

Açık Kaynak PPML Ekosistemi

PPML ekosistemi federated learning'den cryptographic computation'a kadar geniştir. Framework seçimi kullanım senaryosuna göre yapılmalıdır. Project activity ve security disclosure süreci incelenmelidir. Library version pinning uygulanmalıdır. Küçük proof of concept sonuçları karşılaştırılabilir.

Flower

Flower federated learning uygulamaları geliştirmek için kullanılan açık kaynaklı framework'lerden biridir. Farklı ML framework'leriyle client ve server architecture kurulabilir. Cross-device ve cross-silo prototipleri için değerlendirilebilir. Secure aggregation gibi özelliklerin kullanılan sürümde nasıl desteklendiği dokümantasyondan doğrulanmalıdır. Production security için framework dışındaki identity ve network kontrolleri ayrıca gerekir.

TensorFlow Federated

TensorFlow Federated federated computation ve learning araştırmaları için araçlar sunar. TensorFlow ekosistemiyle çalışan ekipler için doğal seçenek olabilir. Simulation ortamı algoritma geliştirmeyi kolaylaştırır. Real production orchestration için ek altyapı gerekebilir. Privacy guarantee kullanılan algorithm ve configuration'a bağlıdır.

PySyft

PySyft privacy-preserving data science ve remote computation fikirleri etrafında geliştirilen açık kaynaklı projelerden biridir. MPC ve privacy odaklı veri erişim modelleriyle deney yapmayı kolaylaştırabilir. Kullanılan feature set sürümlere göre değişebilir. Production tasarımında performance ve security review yapılmalıdır. Framework seçimi community activity ile birlikte değerlendirilmelidir.

Opacus

Opacus PyTorch modellerine differential privacy training özellikleri eklemeyi kolaylaştırır. DP-SGD ve privacy accounting uygulamalarında kullanılabilir. Model mimarisinin desteklenen operasyonlarla uyumlu olması gerekir. Privacy budget gerçek dataset üzerinde izlenmelidir. Kütüphane kullanmak doğru epsilon seçimini otomatik olarak çözmez.

NVIDIA FLARE

NVIDIA FLARE federated learning ve distributed collaboration senaryoları için araçlar sunar. Özellikle cross-silo ve GPU odaklı kullanımda değerlendirilebilir. Participant identity ve secure deployment özellikleri sürüme göre incelenmelidir. Framework yine network ve data governance politikasının yerine geçmez. Pilot çalışma gerçek communication ve GPU maliyetini ölçmelidir.

Microsoft SEAL

Microsoft SEAL homomorphic encryption algoritmaları geliştirmek için kullanılan açık kaynaklı cryptography library'lerinden biridir. Encrypted computation prototipleri oluşturulabilir. FHE kavramlarını pratikte öğrenmek için değerlidir. Parameter seçimi hem security hem performance üzerinde kritiktir. Cryptography production kullanımında alan uzmanı review'u önemlidir.

OpenMined Ekosistemi

OpenMined privacy-preserving computation ve data governance alanında açık kaynak projeler geliştiren bir topluluk ekosistemidir. Eğitim materyalleri PPML kavramlarını öğrenmeyi kolaylaştırabilir. Framework'lerin production readiness seviyesi ayrı değerlendirilmelidir. Community örnekleri küçük lab ortamında yeniden uygulanabilir. Security-critical kullanımda bağımsız review yapılmalıdır.

Ortak Güvenlik Testleri ve Benchmark'lar

Açık source işbirliği privacy tekniklerinin ortak test edilmesini sağlar. Aynı dataset üzerinde accuracy, epsilon, latency ve communication ölçülebilir. Attack benchmark membership inference ve reconstruction başarısını karşılaştırabilir. Sonuçların tekrar üretilebilir olması önemlidir. Topluluk projeleri için https://www.diyarbakiryazilim.com.tr/projects adresindeki çalışma yaklaşımı yeni ortak PPML projeleri için fikir sağlayabilir.

Makine Öğrenimi ve Veri Güvenliği İçin En İyi Programlama Dili Hangisidir?

Bu alanda tek doğru programlama dili yoktur, fakat Python makine öğrenmesi ve privacy framework ekosistemi nedeniyle ilk sırada değerlendirilir. PyTorch, TensorFlow, Opacus, Flower ve PySyft gibi araçlar Python ile güçlü entegrasyon sunar. Rust memory safety gereken düşük seviye güvenlik bileşenlerinde, Go ise platform ve network servislerinde değerlidir. SQL veri erişimi ve minimizasyon için temel beceridir. Ben yeni başlayan bir geliştiriciye önce Python, SQL, Linux ve network güvenliği temellerini birlikte öğrenmesini öneriyorum.

Python Neden Öne Çıkıyor?

Python ML research ve production prototyping için geniş library ekosistemine sahiptir. Data processing, model training ve API geliştirme aynı dil içinde yapılabilir. PPML library'lerinin önemli bölümü Python binding sunar. Bununla birlikte package supply chain güvenliğine dikkat edilmelidir. Virtual environment ve lock file kullanılmalıdır.

PyTorch

PyTorch model training ve araştırma için yaygın framework'tür. Custom training loop differential privacy ve federated learning deneylerini kolaylaştırır. GPU acceleration destekler. Model serialization güvenliği dikkate alınmalıdır. Production artifact güvenilir format ve registry üzerinden dağıtılmalıdır.

TensorFlow

TensorFlow training ve serving için geniş araç setine sahiptir. Federated learning çalışmaları için TensorFlow Federated ekosistemi kullanılabilir. Deployment edge ve server ortamında yapılabilir. Saved model artifact supply chain'e dahil edilmelidir. Dependency version sabitlenmelidir.

Opacus

Opacus differential privacy training'i PyTorch workflow'una entegre eder. Gradient clipping ve noise addition süreçlerini kolaylaştırır. Privacy accountant epsilon takibi sağlar. Uygun parameter seçimi yine data scientist sorumluluğundadır. Performance benchmark yapılmalıdır.

Flower

Flower Python tabanlı federated learning prototiplerini hızlı kurmayı sağlar. Client ve server logic farklı framework'lerle entegre olabilir. Network ve authentication production deployment'ta ayrıca güvenceye alınmalıdır. Secure aggregation desteği kullanılan version üzerinden doğrulanmalıdır. Cross-silo pilotları için kullanışlıdır.

PySyft

PySyft private data science ve remote computation deneyleri için Python geliştiricilerine araç sunar. Privacy-preserving architecture kavramlarını uygulamalı öğrenmeyi kolaylaştırır. Framework API'leri sürüm değişikliklerinden etkilenebilir. Production readiness proje ihtiyacına göre değerlendirilmelidir. Security guarantee kullanılan protocol'e bağlıdır.

Rust'ın Güvenlik Odaklı Sistemlerde Rolü

Rust memory safety ile low-level service geliştirmede güçlüdür. Cryptographic component ve high-performance inference gateway için kullanılabilir. Python native extension güvenli şekilde hızlandırılabilir. Öğrenme eğrisi Python'a göre daha yüksektir. Kritik network ve parser bileşenlerinde değer sağlar.

Go ile ML Platform Servisleri

Go concurrency ve sade deployment özellikleriyle MLOps servislerinde yaygın kullanılabilir. API gateway, scheduler veya policy service geliştirilebilir. Tek binary operasyonu kolaylaştırır. ML model training ekosistemi Python kadar geniş değildir. Platform katmanı ile data science katmanı farklı diller kullanabilir.

SQL ve Veri Erişim Güvenliği

SQL veri minimizasyonu ve least privilege için temel beceridir. Model sadece gereken kolonları view üzerinden alabilir. Row-level security tenant isolation sağlayabilir. Dynamic query parameterize edilmelidir. Data engineer'ın secure SQL bilgisi privacy architecture'ı doğrudan etkiler.

Programlama Dilinden Daha Önemli Olan Güvenlik Mimarisi

Güvenli olmayan architecture en güvenli dil ile yazıldığında bile risk taşır. Identity, key management, network, data classification ve threat modeling temel konulardır. Python kodu private network ve least privilege olmadan hassas veri sızdırabilir. Rust uygulaması yanlış authorization ile aynı sonucu doğurabilir. Bu nedenle dil becerisi security architecture bilgisiyle birlikte geliştirilmelidir.

Veri Güvenliği ve Privacy-Preserving ML Alanında Yazılımcı Olmak İçin Ne Yapmalı?

Bu alana girmek isteyen geliştirici hem ML hem security kavramlarını birlikte öğrenmelidir. Sadece neural network eğitmek yeterli değildir, çünkü gerçek projeler IAM, network, encryption, data governance ve compliance içerir. Python ve temel machine learning iyi başlangıçtır. Ardından network security, cryptography, federated learning, differential privacy ve MLOps eklenebilir. Küçük ama çalışan security project'leri portföyde teorik sertifikadan daha fazla değer gösterebilir.

Python Öğrenmek

Python syntax ve data structure temelleri öğrenilmelidir. NumPy ve pandas ile veri işleme yapılabilir. API ve file handling pratiği önemlidir. Virtual environment ve dependency management güvenli development alışkanlığı kazandırır. Daha sonra PyTorch ile model geliştirmeye geçilebilir.

Machine Learning Temelleri

Train, validation ve test ayrımı anlaşılmalıdır. Overfitting privacy riskini de etkileyebilir. Classification metric ve calibration öğrenilmelidir. Gradient descent mantığı federated ve DP training'i anlamayı kolaylaştırır. Küçük dataset üzerinde model training projesi yapılmalıdır.

Network ve Cloud Security

TLS, VPN, private network ve firewall kavramları öğrenilmelidir. IAM ve service identity cloud ML için kritiktir. Storage public exposure riski uygulamalı lab'da test edilebilir. Network egress kontrolü öğrenilmelidir. Cloud shared responsibility modeli anlaşılmalıdır.

Cryptography Temelleri

Symmetric ve asymmetric encryption farkı bilinmelidir. Hash, digital signature ve key exchange kavramları supply chain güvenliği için gereklidir. HSM ve key management sistemi öğrenilmelidir. Cryptographic primitive'leri sıfırdan yazmamak gerektiği anlaşılmalıdır. Daha sonra MPC ve FHE kavramlarına geçilebilir.

Federated Learning

Önce küçük iki veya üç client simulation kurulabilir. Local training ve aggregation gözlemlenir. Ardından secure aggregation eklenebilir. Non-IID data etkisi test edilir. Communication maliyeti ölçülür.

Differential Privacy

Epsilon ve delta kavramları öğrenilmelidir. DP-SGD küçük classifier üzerinde uygulanabilir. Farklı privacy budget'larda accuracy karşılaştırılır. Membership inference testi yapılabilir. Privacy accountant çıktısı raporlanmalıdır.

MLOps

Model registry ve experiment tracking öğrenilmelidir. CI/CD ile signed artifact deployment kurulabilir. Dataset lineage eklenebilir. Monitoring ve drift ölçülür. Secret ve IAM policy pipeline içinde uygulanır.

KVKK ve GDPR Temelleri

Geliştirici hukukçu olmak zorunda değildir, ancak kişisel veri ve veri aktarımı kavramlarını anlamalıdır. Data minimization teknik requirement'a dönüşebilir. Privacy by design uygulamaya alınabilir. Güncel düzenlemeler resmi kaynaklardan takip edilmelidir. Hukuki karar gereken noktada uzman görüşü alınmalıdır.

Threat Modeling

Basit ML architecture çizilerek asset ve trust boundary belirlenebilir. STRIDE uygulanabilir. Membership inference ve poisoning senaryoları eklenebilir. Risk için mitigation seçilir. Design review yazılı threat model üzerinden yapılır.

Secure Software Development

Code review ve dependency scanning alışkanlığı kazanılmalıdır. Secret code repository'ye yazılmamalıdır. Input validation uygulanmalıdır. Signed build pipeline kullanılabilir. Security test release sürecinin parçası olmalıdır.

Portföy İçin Veri Güvenliği ve Yerellik Projeleri

Portföy projesi sadece model accuracy'sini göstermemeli, veri güvenliği kararlarını da görünür kılmalıdır. Bir local-first ML uygulaması network egress olmadan çalıştırılabilir. Federated demo secure aggregation ile zenginleştirilebilir. Differential privacy classifier privacy budget raporu üretebilir. Proje README'sinde threat model, data flow ve güvenlik kontrolleri açıklanırsa gerçek production düşüncesi gösterilmiş olur.

Local-First ML Uygulaması

Kullanıcı verisi cihazdan çıkmadan çalışan küçük classifier geliştirilebilir. Model offline inference yapabilir. Telemetry yalnızca aggregate metric gönderir. Network egress testle doğrulanır. Threat model cihaz kaybını içerir.

Federated Learning Demo

Üç farklı simulated kurum local dataset üzerinde training yapabilir. Server sadece model update alır. Secure aggregation eklenebilir. Malicious client poisoning testi yapılabilir. Sonuç merkezi training ile karşılaştırılabilir.

Differentially Private Classifier

Basit tabular classifier DP-SGD ile eğitilebilir. Farklı epsilon değerlerinde accuracy ölçülür. Membership inference attack sonucu raporlanır. Privacy accountant output README'ye eklenir. Normal classifier ile karşılaştırma yapılır.

Self-Hosted RAG Sistemi

Local embedding ve local LLM kullanarak dış API gerektirmeyen RAG sistemi kurulabilir. Document store ve vector DB private network'te çalışır. Egress firewall dış bağlantıyı engeller. User access tenant bazında sınırlandırılır. İlgili mimari fikirleri https://www.diyarbakiryazilim.com.tr/posts/yapay-zeka-projelerinde-rag-retrieval-augmented-generation-mimarisi üzerinden genişletebilirsiniz.

Secure ML API

Model API OAuth veya token authentication ile korunabilir. Request schema validation uygulanır. PII loglanmaz. Rate limit extraction saldırısını sınırlar. Private model registry'den signed artifact yüklenir.

Data Residency Policy Engine

Infrastructure deployment sadece approved region'a izin veren policy geliştirilebilir. Wrong region resource creation fail olur. Dataset classification policy input olarak kullanılabilir. Exception process loglanır. Compliance report otomatik oluşturulur.

Confidential Inference Prototipi

TEE destekli VM üzerinde inference servisi çalıştırılabilir. Remote attestation sonucu alınır. Secret yalnızca valid measurement olduğunda verilir. Normal VM ile performance karşılaştırılır. Threat model cloud operator riskini açıkça tanımlar.

Diyarbakır Yazılım Topluluğu İçin Güvenli ML Proje Fikirleri

Güvenli ML konuları küçük ekiplerle uygulamalı öğrenildiğinde çok daha kalıcı hâle gelir. Diyarbakır Yazılım Topluluğu içinde local-first model, federated learning ve KVKK farkındalığı içeren örnek projeler geliştirilebilir. Gerçek kişisel veri yerine sentetik veya açık dataset kullanmak öğrenme sürecini güvenli tutar. Projeler Git üzerinden açık issue ve review süreçleriyle yürütülebilir. Topluluk hakkında ayrıntılı bilgi için https://www.diyarbakiryazilim.com.tr/about adresini inceleyebilirsiniz.

Local-First Türkçe Yapay Zekâ Uygulamaları

Türkçe text classifier veya local assistant tamamen cihaz ya da yerel sunucuda çalıştırılabilir. Harici API kullanılmaz. Network egress monitor edilir. Model boyutu ve latency optimize edilir. Proje data residency kavramını somut biçimde öğretir.

KOBİ'ler İçin Kurum İçi ML Prototipleri

KOBİ'nin gerçek müşteri verisi yerine sentetik dataset kullanılarak demo hazırlanabilir. On-premise inference ve local database birlikte çalışır. Role-based access eklenir. Backup ve restore test edilir. Böylece küçük işletmeler için production yaklaşımının temel parçaları gösterilebilir.

Açık Kaynak Federated Learning Atölyesi

Katılımcılar farklı laptop'larda local client çalıştırabilir. Ortak global model training yapılır. Raw dataset client'tan çıkmaz. Secure aggregation kavramı uygulamalı anlatılır. Communication overhead ölçülür.

KVKK Uyumlu ML Hackathon'u

Takımlara sentetik kişisel veri içeren business case verilebilir. Her takım model kadar data flow ve retention planı tasarlar. External API kullanıyorsa transfer haritası hazırlamak zorunda olur. Security review sonuç puanına dahil edilir. Böylece compliance teorik ek bölüm yerine architecture kararına dönüşür.

Privacy-Preserving ML Çalışma Grubu

Federated learning, DP ve confidential computing için aylık çalışma planı oluşturulabilir. Her toplantıda küçük paper veya open-source demo incelenir. Attack simulation yapılır. Sonuçlar Türkçe teknik not olarak paylaşılır. Bu içerikler yeni geliştiricilerin alana girişini kolaylaştırır.

Türkçe Veri Güvenliği Benchmark Projesi

Türkçe text model üzerinde memorization ve privacy attack benchmark hazırlanabilir. Public veya sentetik dataset kullanılabilir. Farklı DP parametreleri karşılaştırılır. Sonuçlar açık CSV ve notebook olarak yayımlanır. Aynı benchmark yeni modellerde tekrar çalıştırılabilir.

Open Source Güvenli Yapay Zekâ Katkı Günleri

Topluluk üyeleri PPML projelerinin issue listelerini inceleyebilir. Dokümantasyon, test veya küçük bug fix katkısı yapılabilir. Contribution guide takip edilir. Gerçek secret veya müşteri data kullanılmaz. Topluluk projeleri ve işbirliği alanları için https://www.diyarbakiryazilim.com.tr/projects adresi takip edilebilir.

Sektörlere Göre Veri Yerelliği ve ML Güvenliği

ML güvenlik ihtiyacı sektörün veri türüne ve iş etkisine göre değişir. Sağlıkta hasta verisi, finansta işlem bilgileri ve kamuda vatandaş kayıtları çok daha sıkı kontrol gerektirebilir. Savunmada air-gap tercih edilirken perakendede edge personalization daha uygun olabilir. Telekom altyapısında federated analytics merkezi data transferini azaltabilir. Architecture kararları sektör düzenlemeleri ve threat model birlikte değerlendirilerek verilmelidir.

Sağlık

Sağlık ML sistemleri yüksek hassasiyetli kişisel veri işler. Training dataset erişimi çok sınırlı olmalıdır. Federated learning hastaneler arası ortak model için değerlendirilebilir. On-premise inference patient data egress'ini azaltabilir. Model output da hassas sağlık verisi olarak korunmalıdır.

Hasta verileri

Hasta kayıtları güçlü encryption ve access control gerektirir. Identifier mümkün olduğunda pseudonymize edilir. Dataset minimization uygulanır. Training lineage tutulur. Silme ve retention süreçleri sağlık mevzuatıyla birlikte değerlendirilir.

Federated learning

Hastaneler raw data paylaşmadan local training yapabilir. Secure aggregation update privacy'sini güçlendirir. DP membership inference riskini azaltabilir. Participant authentication kritik önemdedir. Model validation her kurum populasyonu için yapılmalıdır.

On-prem inference

Model hastane network'ünde local çalıştırılabilir. Patient input dış provider'a gönderilmez. GPU ve patch operasyonu hastanenin sorumluluğundadır. Audit her prediction erişimini kaydedebilir. High availability klinik kullanımda kritik olabilir.

Finans

Finansal ML transaction ve risk verisi işler. Fraud detection düşük latency gerektirir. Strong IAM ve audit zorunlu tasarım bileşenleridir. Kurumlar ortak fraud signal için privacy-preserving learning kullanabilir. Model output kredi veya risk kararında kullanılıyorsa governance güçlendirilmelidir.

İşlem verileri

Transaction data doğrudan müşteri davranışını gösterir. Feature store çok hassas hâle gelebilir. Tokenization kullanılabilir. Data egress sıkı kontrol edilmelidir. Real-time stream encryption uygulanmalıdır.

Fraud detection

Fraud model düşük latency ve yüksek availability ister. Feature access minimum tutulmalıdır. Adversarial attacker modeli probe etmeye çalışabilir. Rate limiting ve anomaly monitoring gerekir. Drift monitoring yeni saldırı pattern'lerini yakalayabilir.

Kurumlar arası güvenli öğrenme

Birden fazla kurum ortak fraud model geliştirmek isteyebilir. Ham müşteri data paylaşımı risklidir. Federated learning veya MPC değerlendirilebilir. Secure aggregation client update'lerini gizler. Governance model ownership ve update policy'yi tanımlar.

Kamu

Kamu sistemleri geniş kapsamlı vatandaş verisi işleyebilir. Data sovereignty ve operational control özel önem taşır. On-premise veya sovereign architecture değerlendirilebilir. Administrator ve vendor support erişimi sınırlandırılmalıdır. Audit log uzun süreli ve güvenilir tutulabilir.

Hassas vatandaş verileri

Citizen data farklı kamu sistemlerinde birleştiğinde risk büyür. Data minimization ve purpose limitation uygulanmalıdır. Cross-agency sharing açık governance gerektirir. ML dataset provenance kayıt altına alınmalıdır. Model output yetkisiz profil oluşturmak için kullanılmamalıdır.

Sovereign AI

Sovereign AI data, model ve infrastructure üzerinde yerel kontrol hedefleyebilir. Open-weight model self-hosted inference ile kullanılabilir. Key ownership kurumda tutulabilir. Operator access yerel policy'ye bağlı olur. Vendor exit ve local expertise bu yaklaşımın ayrılmaz parçasıdır.

Savunma

Savunma workload'ları çok yüksek gizlilik gerektirebilir. Air-gap ve offline model serving kullanılabilir. Model artifact supply chain sıkı doğrulanmalıdır. Removable media kontrolü kritik hâle gelir. Hardware ve physical security ML platform güvenliğinin parçasıdır.

Air-gapped ML

Training ve inference dış network'ten izole edilir. Dataset kurum sınırında kalır. Update controlled transfer gateway üzerinden alınır. Package signature doğrulanır. İç tehdit monitoring devam eder.

Offline model serving

Model tamamen local server üzerinde hizmet verir. External API bağımlılığı bulunmaz. Registry internal ortamda tutulur. Model update manuel release sürecinden geçer. Rollback image hazır tutulur.

Perakende

Perakende müşteri davranışı ve satın alma geçmişi üzerinden model geliştirir. Pseudonymization ve consent management önemli olabilir. Edge personalization müşteri verisini cihazda tutabilir. Campaign model external provider kullanıyorsa egress kontrol edilmelidir. Model output customer profiling olarak ayrıca değerlendirilmelidir.

Müşteri davranışları

Clickstream ve loyalty data kişisel profil oluşturabilir. Retention sınırlı olmalıdır. Identifier tokenization kullanılabilir. Feature minimization yapılmalıdır. Analytics log region policy'ye uymalıdır.

Edge personalization

Recommendation model cihaz üzerinde çalışabilir. Raw browsing history cloud'a gönderilmez. Model küçük ve optimize olmalıdır. Federated update merkezi modele katkı sağlayabilir. User opt-out cihaz seviyesinde uygulanabilir.

Telekom

Telekom yüksek hacimli network ve subscriber data işler. Edge computing doğal altyapı avantajı sunar. Federated analytics bölgesel data'yı merkezileştirmeden trend çıkarabilir. Network telemetry minimization önemlidir. Model ve infrastructure availability servis kalitesi için kritiktir.

Federated analytics

Bölgesel node'lar local aggregate hesaplayabilir. Merkezi sistem ham user event almaz. Secure aggregation aggregate privacy'sini artırabilir. Differential privacy output'a noise ekleyebilir. Network overhead klasik raw data transferinden daha düşük olabilir.

Edge learning

Base station veya edge node local model update üretebilir. Low latency network optimization sağlanabilir. Data region içinde kalır. Node compromise riski vardır. Secure boot ve attestation kullanılabilir.

ML Platformu Seçerken Veri Yerelliği Kontrol Listesi

Platform seçiminde model accuracy veya GPU fiyatından önce veri akışına ilişkin net sorular sormak gerekir. Storage, training, inference, backup, embeddings, logs ve checkpoint'ler farklı region politikalarına sahip olabilir. Encryption key ownership ve alt veri işleyen listesi sovereignty açısından önemlidir. Provider'ın customer data'yı training için kullanıp kullanmadığı açık olmalıdır. Vendor exit planı veri ve model artifact'larının başka altyapıya taşınabilmesini sağlamalıdır.

Veri Nerede Saklanıyor?

Ana storage region sözleşmede açıkça belirtilmelidir. Replica lokasyonu sorulmalıdır. Metadata servislerinin kapsamı incelenmelidir. Region change yetkisi sınırlandırılmalıdır. API üzerinden location evidence alınabilmelidir.

Training Nerede Yapılıyor?

GPU training cluster region'i bilinmelidir. Global scheduler kullanılıyorsa locality guarantee doğrulanmalıdır. Scratch disk data retention sorulmalıdır. Distributed node'lar aynı izinli region'da olmalıdır. External fine-tuning API ayrı transfer noktası olarak değerlendirilmelidir.

Inference Nerede Çalışıyor?

Model API regional endpoint sunuyor mu kontrol edilmelidir. Failover başka ülkeye geçiyor mu sorulmalıdır. CPU preprocessing ve moderation servisleri de kapsama alınmalıdır. Execution region loglanabilmelidir. Locality contract ile teknik behavior eşleşmelidir.

Backup Nerede?

Backup region ana storage'dan farklı olabilir. Snapshot replication policy incelenmelidir. DR region izinli olmalıdır. Backup encryption key location kontrol edilmelidir. Retention ve secure deletion belgelenmelidir.

Embedding Nerede Oluşturuluyor?

RAG sistemi external embedding API kullanıyor olabilir. Source chunk provider'a gönderilir. Embedding endpoint region-specific olmalıdır. Local model alternatif olabilir. Provider retention ve training policy kontrol edilir.

Loglar Nerede Saklanıyor?

Central telemetry çoğu zaman global SaaS platforma gider. Ham prompt veya prediction loglanıyor mu sorulmalıdır. Log region ve retention bilinmelidir. PII redaction uygulanmalıdır. Support export süreçleri kontrol edilmelidir.

Model Checkpoint'leri Nerede?

Checkpoint object storage ayrı bucket'ta bulunabilir. Region ve backup policy kontrol edilir. Old checkpoint retention sınırlandırılır. Registry ile training storage access ayrılır. Encryption key model weight hassasiyetine uygun olmalıdır.

Encryption Key Kimin Kontrolünde?

Provider-managed ve customer-managed seçenekleri karşılaştırılır. BYOK veya external key desteği sorulur. Key revocation yetkisi müşteride olmalıdır. Audit log key usage göstermelidir. Key recovery sovereignty policy'ye uymalıdır.

Alt Veri İşleyenler Kim?

Provider subprocessor listesi güncel olmalıdır. Her tarafın hangi data kategorisine eriştiği bilinmelidir. Değişiklik notification süreci bulunmalıdır. Support ve telemetry provider'ları da kapsama girer. Vendor review periyodik tekrarlanmalıdır.

Veriler Model Eğitimi İçin Kullanılıyor mu?

Customer data'nın provider training için kullanımı açıkça belirtilmelidir. Opt-out default mu kontrol edilir. Enterprise API ile consumer product koşulları karıştırılmamalıdır. ZDR seçeneği varsa kapsam doğrulanmalıdır. Contract change monitoring yapılmalıdır.

Silme Süreci Nasıl İşliyor?

User veya tenant data silindiğinde storage, log ve backup etkilenmelidir. Provider deletion SLA sunabilir. Immutable backup için expiry yaklaşımı açıklanmalıdır. Model training'e giren veri için unlearning policy sorulmalıdır. Silme event'i audit edilmelidir.

Vendor Exit Plan Var mı?

Dataset ve model export formatı açık olmalıdır. Egress maliyeti hesaplanmalıdır. Encryption key revocation planlanmalıdır. Provider-specific feature bağımlılığı inventory hâline getirilmelidir. Yılda bir küçük exit rehearsal vendor lock-in riskini ölçebilir.

Uçtan Uca Güvenli ve Yerel ML Mimarisi Nasıl Kurulur?

Uçtan uca güvenli ML architecture tek ürün satın alarak kurulmaz. İş problemi, veri sınıfı, hukuki gereksinim ve threat model sırasıyla tanımlanmalıdır. Sonra deployment, encryption, identity, privacy-preserving teknikler ve monitoring seçilir. Model supply chain ve backup da aynı güvenlik kapsamına alınır. Aşağıdaki yirmi adım production öncesi architecture workshop için doğrudan kontrol listesi olarak kullanılabilir.

1. İş Problemini Tanımlayın

Modelin hangi business kararını destekleyeceğini netleştirin. Gerekli input ve output'u belirleyin. Model gerçekten gerekli mi sorusunu sorun. Basit rule sistemi yeterliyse hassas veriyi ML pipeline'a sokmayın. Başarı ve risk metriğini birlikte tanımlayın.

2. Veri Envanteri Çıkarın

Bütün data source'ları listeleyin. Training, feature, log ve backup dahil olsun. Data owner belirtin. Kişisel ve confidential alanları işaretleyin. Unknown data source production'a alınmasın.

3. Verileri Sınıflandırın

Public, internal, confidential ve kişisel veri sınıfları belirleyin. Her sınıf için security policy tanımlayın. Special category data ayrı işaretlenir. Classification otomatik discovery ile desteklenebilir. Dataset catalog tek kaynak olur.

4. Hukuki ve Sektörel Gereksinimleri Belirleyin

KVKK ve ilgili sektör kuralları listelenir. Yurt dışı aktarım ihtiyacı belirlenir. Data retention hukuki gereksinimle eşleştirilir. Hukuk ekibi teknik diagram üzerinden review yapar. Gereksinim release criteria'ya dönüşür.

5. Data Flow Diagram Oluşturun

Kaynak, storage, compute ve output node'larını çizin. Her bağlantının taşıdığı veri kategorisini yazın. Region ve provider bilgisi ekleyin. Log ve backup akışını unutmayın. Diagram değişiklikle birlikte güncellensin.

6. Trust Boundary'leri Belirleyin

Cloud, on-prem, user ve third-party sınırlarını işaretleyin. Her boundary authentication gerektirsin. Encryption in transit uygulanır. Untrusted input validation yapılır. Data crossing event audit edilir.

7. Deployment Modelini Seçin

Public cloud, sovereign, on-prem veya edge seçeneklerini karşılaştırın. Data sensitivity temel kriter olsun. Performance ve cost birlikte ölçülsün. Hybrid model gerekebilir. Karar architecture record olarak saklansın.

8. Veri Yerelliği Politikasını Belirleyin

İzin verilen storage ve processing region'larını tanımlayın. Backup region'i ekleyin. External API kullanımı belirtilsin. Policy IaC seviyesinde enforce edilsin. Drift monitoring kurulsun.

9. Encryption ve Key Management Kurun

At rest ve transit encryption zorunlu olsun. Data-in-use riskine göre confidential computing değerlendirin. Key ownership belirleyin. Rotation ve revocation runbook hazırlayın. Key audit loglarını saklayın.

10. Identity ve Access Policy Oluşturun

Human ve workload identity ayrı olsun. Least privilege kullanın. MFA ve JIT privileged access uygulayın. Shared account kaldırın. Access review düzenli çalışsın.

11. Privacy-Preserving Teknikleri Seçin

Threat model hangi PPML tekniğine ihtiyaç olduğunu gösterir. Federated learning data locality için seçilebilir. DP memorization riskini azaltır. Secure aggregation gradient privacy sağlar. FHE veya confidential computing data-in-use ihtiyacına göre değerlendirilir.

12. Model Supply Chain'i Güvenceye Alın

Pre-trained model kaynağını doğrulayın. Artifact hash ve signature kullanın. Internal registry oluşturun. Dependency scanning yapın. Unknown serialization formatını sandbox dışında açmayın.

13. Training Pipeline'ı Güvenli Hale Getirin

Job identity sadece gerekli dataset'e erişsin. Scratch disk otomatik temizlensin. Network egress sınırlandırılsın. Checkpoint güvenli storage'a yazılsın. Training loglarında sample data bulunmasın.

14. Inference Pipeline'ını Güvenli Hale Getirin

API authentication zorunlu olsun. Input schema doğrulansın. Rate limiting extraction riskini azaltsın. Sensitive input loglanmasın. External tool veya provider çağrısı data policy'den geçsin.

15. Logging ve Monitoring'i Minimize Edin

Sadece operasyon için gerekli telemetry toplayın. PII redaction uygulayın. Prompt loglamayı default kapatın. Security ve model metric'lerini aggregate tutun. Retention otomatik uygulanmalıdır.

16. Privacy Attack Testleri Yapın

Membership inference test edilir. Training extraction ve inversion senaryosu çalıştırılır. Federated gradient leakage test edilir. Attack metric release threshold ile karşılaştırılır. Mitigation sonrası yeniden test yapılır.

17. Yerellik ve Egress Kontrollerini Test Edin

Wrong region deployment denenir. Policy'nin engellediği doğrulanır. External domain egress testi yapılır. Backup ve DR region kontrol edilir. Network log gerçek data flow ile eşleştirilir.

18. Audit Trail Oluşturun

Dataset access ve model publish loglanır. Key usage kaydı tutulur. Privileged session izlenir. Loglar immutable storage'a yazılabilir. Correlation ID incident analysis'i kolaylaştırır.

19. Backup ve Recovery'yi Test Edin

Database ve model registry yedeklenir. Restore test environment'ta çalıştırılır. Region compliance doğrulanır. Key recovery test edilir. RTO ve RPO ölçülür.

20. Sürekli İzleme ve Güncelleme Yapın

Security architecture bir kez hazırlanıp bırakılmamalıdır. Provider ve subprocessor değişiklikleri takip edilir. Yeni model attack yöntemleri değerlendirilir. Access ve region policy düzenli audit edilir. Incident ve test sonuçları architecture'ı günceller.

Makine Öğrenimi Veri Güvenliğinde En Sık Yapılan Hatalar

ML güvenlik hatalarının çoğu tek bir teknoloji eksikliğinden değil yanlış varsayımdan kaynaklanır. Bulutu otomatik güvensiz, on-premise sistemi otomatik güvenli görmek bunların başında gelir. Veri residency ile sovereignty kavramını karıştırmak da yanlış architecture kararlarına yol açar. Embedding, log ve backup gibi ikincil veri kopyaları sık unutulur. Güvenli yaklaşım varsayımlar yerine ölçüm, audit ve açık threat model kullanır.

Verinin Bulutta Olmasını Otomatik Olarak Güvensiz Saymak

Cloud güçlü security ve managed encryption servisleri sunabilir. Risk yanlış configuration veya uygun olmayan data flow'dan kaynaklanabilir. On-premise sistem de patch edilmezse daha riskli olabilir. Threat model karşılaştırması yapılmalıdır. Deployment etiketi tek başına security score değildir.

Verinin Türkiye'de Olmasını Otomatik Olarak Güvenli Saymak

Physical location confidentiality garantisi değildir. Public bucket Türkiye'de olsa da herkes erişebilir. Remote admin başka ülkeden bağlanabilir. Encryption key provider controlünde olabilir. Yerellik ile security ayrı doğrulanmalıdır.

Data Residency ile Sovereignty'yi Karıştırmak

Residency fiziksel lokasyona odaklanır. Sovereignty hukuk, control ve operation boyutunu ekler. Aynı data center iki hedefi farklı düzeyde karşılayabilir. Key ownership ve support access incelenmelidir. Architecture decision iki kavramı ayrı kriter olarak tutmalıdır.

Sadece Training Dataset'i Korumak

Feature store ve test dataset aynı hassasiyeti taşıyabilir. Checkpoint ve gradient data leakage yaratabilir. Inference input production kişisel veri içerebilir. Log ve backup ayrıca korunmalıdır. Asset inventory tüm yaşam döngüsünü kapsamalıdır.

Model Weight'lerini Hassas Veri Olarak Görmemek

Weight fikri mülkiyet içerir. Training data memorization riski bulunabilir. Public paylaşım leakage attack surface'i büyütür. Registry access kontrol edilmelidir. Signed artifact kullanılmalıdır.

Embedding ve Vector DB'yi Unutmak

Embedding semantic bilgi taşır. Vector metadata doğrudan identifier içerebilir. Managed vector DB başka region'da olabilir. RAG context external LLM'e aktarılabilir. Data flow bütün RAG bileşenlerini göstermelidir.

Loglarda PII Saklamak

Debug kolaylığı için ham request loglamak gereksiz risk yaratır. PII redaction uygulanmalıdır. Log retention kısa tutulabilir. Access role sınırlandırılır. Production prompt loglama opt-in veya sample olabilir.

Backup Lokasyonunu Kontrol Etmemek

Backup farklı region'a otomatik gidebilir. DR failover residency'yi bozabilir. Snapshot encryption key ayrı lokasyonda olabilir. Backup policy architecture review'a dahil edilmelidir. Restore test location kontrolü yapmalıdır.

Provider-Managed Key'e Körü Körüne Güvenmek

Provider-managed key çoğu workload için yeterli olabilir. Ancak high-sovereignty requirement'ta daha fazla kontrol gerekebilir. Customer-managed ve BYOK seçenekleri karşılaştırılmalıdır. Key revocation yetkisi önemlidir. Seçim risk seviyesine göre yapılmalıdır.

Federated Learning'i Tek Başına Gizlilik Garantisi Sanmak

Gradient data leakage oluşturabilir. Malicious client poisoning yapabilir. Global model membership inference'a açık olabilir. Secure aggregation ve DP eklenebilir. Client authentication ayrıca gerekir.

Model Extraction ve Membership Inference Testi Yapmamak

Model API attack surface olarak değerlendirilmelidir. Rate limit tek başına privacy guarantee değildir. Red team attack success ölçebilir. DP ve output restriction etkisi karşılaştırılır. Test regression pipeline'a eklenir.

Vendor Lock-In Riskini Görmezden Gelmek

Provider-specific model formatı migration'ı zorlaştırabilir. Dataset export pahalı olabilir. Encryption key dışarı taşınamayabilir. Open standard ve internal registry bağımlılığı azaltır. Exit rehearsal planlanmalıdır.

Veri Silme Sürecini Modele Yansıtmamak

Database record silinince model etkisi devam edebilir. Dataset version ve model lineage bilinmelidir. Retraining veya unlearning ihtiyacı değerlendirilir. Checkpoint ve backup lifecycle güncellenir. User deletion workflow ML platformuna entegre edilmelidir.

Production ML Veri Güvenliği Checklist

Production release öncesi data, encryption, access, model, infrastructure ve monitoring birlikte kontrol edilmelidir. Checklist sadece “aktif” veya “pasif” kutusundan oluşmamalı, her madde için kanıt bulunmalıdır. Region bilgisi API çıktısı, key policy ve test sonucu gibi evidence saklanabilir. Model leakage testi normal security scan kadar release kriteri hâline getirilebilir. Aşağıdaki yapı hem yeni proje hem yıllık security review için kullanılabilir.

Data

Dataset source ve owner belli olmalıdır. Kişisel ve confidential alanlar classification altında bulunmalıdır. Data minimization uygulanmalıdır. Lokasyon storage ve processing için doğrulanmalıdır. Retention ve deletion policy otomatikleştirilmelidir.

Sınıflandırıldı mı?

Her dataset security class taşımalıdır. Unknown class production'da kullanılamamalıdır. Classification data catalog'a yazılmalıdır. Sensitive data discovery otomatik olabilir. Owner sınıfı düzenli review etmelidir.

Minimize edildi mi?

Modelin kullanmadığı kolonlar kaldırılmalıdır. Log payload minimum tutulmalıdır. Feature importance yardımcı ölçüm sunar. External API sadece gerekli field'ı almalıdır. Redundant dataset copy temizlenmelidir.

Lokasyon doğrulandı mı?

Storage region API ile kontrol edilmelidir. Compute region ayrıca doğrulanır. Backup lokasyonu listelenir. Egress logları incelenir. DR region policy ile eşleşir.

Encryption

At-rest encryption storage seviyesinde zorunlu olmalıdır. Transit connection TLS kullanmalıdır. Data-in-use threat modeli varsa TEE veya daha ileri teknikler değerlendirilir. Key ownership açıklanır. Rotation ve recovery test edilir.

At rest

Disk ve object storage encryption aktiftir. Database gerekirse column-level koruma kullanır. Backup aynı security seviyesindedir. Customer-managed key ihtiyacı değerlendirilir. Public access kapalıdır.

In transit

API TLS kullanır. Internal service connection da şifrelenir. Certificate validation kapatılamaz. Mutual TLS yüksek güvenlik alanlarında uygulanabilir. Private network ek exposure azaltımı sağlar.

In use

Confidential computing ihtiyacı threat model'den gelir. TEE attestation kullanılabilir. FHE özel inference için değerlendirilebilir. Key yalnızca trusted workload'a verilebilir. Performance etkisi ölçülür.

Access

Human ve workload access ayrı yönetilmelidir. Shared account kullanılmamalıdır. Production privilege süreli olmalıdır. MFA zorunlu tutulur. Role review düzenli yapılır.

Least privilege

Her role minimum yetki alır. Training job sadece dataset read yetkisine sahip olabilir. Registry write CI role'üne verilir. Unused permission kaldırılır. Access test otomatikleştirilebilir.

MFA

Administrator erişiminde MFA zorunlu olmalıdır. Phishing-resistant yöntemler mümkünse tercih edilir. Shared MFA token kullanılmaz. Recovery kodları güvenli saklanır. MFA bypass event alarm üretir.

JIT access

Privileged role sürekli aktif kalmaz. User gerekçe ile süreli aktivasyon yapar. Approval gerekiyorsa ikinci kişi onaylar. Session loglanır. Süre sonunda permission otomatik kaldırılır.

Model

Production model trusted source'tan gelmelidir. Provenance ve hash kayıtlıdır. Artifact signature doğrulanır. Leakage ve extraction testleri çalıştırılır. Model version rollback için saklanır.

Provenance

Base model source bellidir. Dataset version kaydedilir. Training code commit ID bulunur. Dependency manifest saklanır. Release owner belirtilir.

Signed artifact

Model internal signing key ile imzalanır. Deployment signature doğrular. Untrusted artifact reddedilir. Key revocation planı vardır. Signature event audit edilir.

Leakage testing

Membership inference çalıştırılır. Memorization canary testi yapılır. Extraction denemesi rate limit altında ölçülür. Sonuç threshold ile karşılaştırılır. Failure release'i durdurabilir.

Infrastructure

Network private ve segmented olmalıdır. Public endpoint sadece gerekli servislerde açılır. Egress control hassas workload'u sınırlar. Region policy infrastructure-as-code seviyesinde uygulanır. Container ve host patch durumu izlenir.

Private networking

Storage public internetten erişilemez. Model registry private endpoint kullanır. Admin VPN üzerinden bağlanır. Internal TLS devam eder. Network route audit edilir.

Egress control

Default deny high-risk workload için uygulanabilir. Approved model provider allowlist'e eklenir. Package repository kontrollüdür. DNS log izlenir. Unexpected destination alarm üretir.

Region enforcement

IaC policy wrong region deployment'ı engeller. Resource relocation privileged işlemdir. Backup region ayrıca kontrol edilir. Compute scheduler approved pool kullanır. Drift scan düzenli çalışır.

Monitoring

Monitoring security ve model behavior'ı birlikte kapsar. Audit log immutable olabilir. Privacy attack indicator izlenir. Model drift kalite riskini gösterir. Security alert incident response runbook'a bağlanır.

Audit logs

Dataset access loglanır. Model promotion event kaydedilir. Key usage izlenir. Privileged session saklanır. Loglar değiştirilemez storage'a gönderilir.

Privacy monitoring

Excessive query extraction sinyali olabilir. Sensitive output pattern detection uygulanabilir. Unexpected data egress alarm üretir. Privacy budget trend izlenir. Incident privacy owner'a yönlendirilir.

Drift

Input distribution değişimi izlenir. Model performance düşüşü alert üretir. Drift yeni data source riskini gösterebilir. Retraining approval gerektirir. Yeni dataset privacy review'dan geçer.

Security alerts

Unauthorized access anında bildirilir. Public bucket detection kritik alarmdır. Key disable event izlenir. Unexpected region resource oluşturulması engellenir. Incident timeline audit log ile oluşturulur.

Sık Sorulan Sorular

Makine Öğrenimi Modellerinde Veri Güvenliği ve Yerellik konusunda en sık sorulan sorular storage lokasyonundan federated learning ve KVKK'ya kadar uzanıyor. Bu soruların ortak noktası tek bir teknolojinin bütün riskleri çözeceği beklentisidir. Gerçekte secure ML katmanlı architecture gerektirir. Hukuki gereksinimler de teknik controls ile birlikte tasarlanmalıdır. Aşağıdaki yanıtlar hızlı karar desteği sağlar, ancak somut hukuki değerlendirmelerde kurumun hukuk ve kişisel veri uzmanlarının görüşü ayrıca alınmalıdır.

Makine öğreniminde veri güvenliği nedir?

ML veri güvenliği dataset, model ve supporting infrastructure'ın confidentiality, integrity ve availability açısından korunmasıdır. Training, inference ve monitoring aşamalarını kapsar. Encryption, IAM, network security ve audit temel kontrollerdir. ML-specific olarak poisoning, model extraction ve membership inference da değerlendirilir. Güvenlik veri yaşam döngüsünün tamamına uygulanmalıdır.

Veri yerelliği nedir?

Veri yerelliği verinin ve gerektiğinde processing'in belirli coğrafi veya operasyonel sınır içinde kalmasını ifade eder. Storage location tek başına yeterli değildir. Training, inference, log ve backup region'ları da kontrol edilir. External API data egress yaratabilir. Gerçek locality data flow ve network evidence ile doğrulanmalıdır.

Data residency ile data sovereignty arasındaki fark nedir?

Data residency verinin nerede bulunduğunu anlatır. Data sovereignty hukuki yetki, operator access ve key ownership gibi daha geniş kontrol alanını kapsar. Türkiye'de storage kullanmak residency sağlayabilir. Ancak remote support ve provider-managed key sovereignty değerlendirmesini etkiler. İki kavram architecture checklist'te ayrı tutulmalıdır.

Makine öğrenimi verilerinin Türkiye'de tutulması zorunlu mudur?

Bütün ML verileri için genel ve tek cümlelik “mutlaka Türkiye'de tutulmalıdır” sonucu doğru değildir. Veri kategorisi, işleme amacı, sektör düzenlemeleri ve yurt dışı aktarım şartları ayrı değerlendirilmelidir. Kişisel verilerin yurt dışına aktarımı KVKK'nın güncel 9 uncu maddesi ve ilgili düzenlemeler çerçevesinde ele alınır. Sektörel mevzuat daha özel yükümlülükler getirebilir. Somut proje hukuk ve veri koruma uzmanıyla değerlendirilmelidir. :contentReference[oaicite:11]{index=11}

ML verileri yurt dışındaki cloud servislerine gönderilebilir mi?

Kişisel veri içeren ML verisinin yurt dışına aktarımı güncel KVKK aktarım mekanizmalarına uygun olmalıdır. Yeterlilik kararı, uygun güvenceler ve şartları oluştuğunda istisnai hâller değerlendirilir. Standart sözleşme ve bağlayıcı şirket kuralları uygun güvence yöntemleri arasındadır. Teknik olarak API, storage ve remote support akışlarının tamamı haritalanmalıdır. Somut aktarım için güncel Kurum kaynakları ve hukuk görüşü esas alınmalıdır. :contentReference[oaicite:12]{index=12}

Federated learning verileri tamamen güvenli hale getirir mi?

Hayır, federated learning ham datayı local tutar fakat update privacy riskini ortadan kaldırmaz. Gradient leakage ve reconstruction saldırıları mümkündür. Malicious client poisoning yapabilir. Secure aggregation ve differential privacy eklenebilir. Client authentication ve model validation ayrıca gerekir.

Differential privacy nedir?

Differential privacy tek bireyin verisinin model veya istatistik üzerindeki etkisini sınırlandıran matematiksel yaklaşımdır. Epsilon ve delta privacy budget'ı tanımlar. DP-SGD gradient clipping ve noise kullanır. Daha güçlü privacy accuracy maliyeti oluşturabilir. Privacy accounting production governance için önemlidir.

Homomorphic encryption makine öğreniminde nasıl kullanılır?

Homomorphic encryption şifreli veri üzerinde belirli hesapları plaintext'i açmadan yapmayı sağlar. Inference provider kullanıcının gerçek input'unu görmeyebilir. Sonuç şifreli olarak geri döner. FHE yüksek compute ve latency maliyeti oluşturabilir. Çok hassas ve daha sınırlı model görevlerinde değerlendirilebilir.

Confidential computing nedir?

Confidential computing veriyi işlem sırasında trusted hardware ortamında korumayı hedefler. Memory encryption privileged host erişimini sınırlandırabilir. Remote attestation workload'un güvenilirliğini doğrular. Secret yalnızca valid environment'a verilebilir. Application açığı ve model saldırıları ayrıca yönetilmelidir.

On-prem ML buluttan daha güvenli midir?

Otomatik olarak daha güvenli değildir. On-premise yüksek fiziksel ve network kontrolü sağlar, fakat patching ve operation tamamen kurumun sorumluluğudur. İyi yönetilen cloud sistemi kötü yönetilen on-premise sistemden daha güvenli olabilir. Data sensitivity ve ekip kapasitesi birlikte değerlendirilmelidir. Risk-based comparison yapılmalıdır.

Open-source model kullanmak veri gizliliğini artırır mı?

Open-weight model self-hosted inference sayesinde veriyi external API'ye göndermeme avantajı sağlar. Bu privacy riskini önemli ölçüde azaltabilir. Ancak model supply chain ve serving security kurumun sorumluluğuna geçer. Embedding veya logging hâlâ dış provider kullanıyorsa tam locality oluşmaz. Bütün pipeline değerlendirilmelidir.

Model weights kişisel veri sızdırabilir mi?

Model training örneklerini belirli ölçüde ezberleyebilir. Membership inference veya extraction saldırıları training data hakkında bilgi çıkarabilir. Bu nedenle weight hassas artifact olarak korunmalıdır. Differential privacy risk azaltabilir. Release öncesi leakage testing yapılabilir.

Embedding'ler hassas veri sayılabilir mi?

Embedding kaynak veri hakkında semantic bilgi taşır. Doğrudan okunabilir metin olmaması güvenli olduğu anlamına gelmez. Kişisel veya confidential dokümandan üretildiyse güçlü access control uygulanmalıdır. Vector database region ve backup policy kontrol edilmelidir. Silme talebi embedding kaydını da kapsamalıdır.

Machine unlearning nedir?

Machine unlearning belirli training verisinin model üzerindeki etkisini kaldırmayı veya azaltmayı amaçlar. Database satırını silmek model weight'ini otomatik değiştirmez. Retraining en açık yöntemdir. Approximate unlearning daha düşük maliyetli olabilir. Güçlü lineage hangi modelin etkilenmiş olduğunu bulmak için gereklidir.

KVKK uyumlu makine öğrenimi sistemi nasıl tasarlanır?

Önce veri envanteri ve sınıflandırması yapılır. İşleme amacı, minimizasyon, retention ve yurt dışı transfer akışları belirlenir. Encryption, IAM, network, logging ve deletion teknik kontrollerle uygulanır. ML-specific leakage ve poisoning riskleri test edilir. Hukuki değerlendirme güncel KVKK düzenlemeleri ve somut iş modeline göre uzmanlarla birlikte yürütülmelidir.

Veri güvenliği için hangi programlama dili tercih edilmelidir?

Python ML ekosistemi nedeniyle en pratik başlangıçtır. Rust güvenlik odaklı system component, Go platform service ve SQL güvenli data access için değerlidir. Dil security architecture'ın yerine geçmez. IAM, encryption ve threat modeling bilgisi daha kritik olabilir. İyi ekip farklı katmanlarda farklı dilleri birlikte kullanabilir.

Makine Öğrenimi Veri Güvenliği ve Yerelliği Hakkında Sık Sorulan Sorular

Makine Öğrenimi Modellerinde Veri Güvenliği ve Yerellik konusunda kurumların en çok ihtiyaç duyduğu şey, teknik güvenlik ile hukuki veri akışını aynı tabloda görebilmektir. Kurumsal makine öğrenmesi veri güvenliği ve yerel AI altyapısı hizmeti planlayan ekipler için storage region, model provider, key ownership ve backup lokasyonu birlikte değerlendirilmelidir. Yapay zeka veri güvenliği ve makine öğrenmesi danışmanlığı yakınımda şeklinde destek ararken yalnızca model geliştirme değil Linux, cloud, privacy, MLOps ve KVKK farkındalığını birlikte ele alan yaklaşım tercih edilmelidir. Aşağıdaki beş soru bu kararların kısa özetini verir. Her production projesinde sonuçlar gerçek veri sınıfı ve kurum risk iştahına göre ayrıca uyarlanmalıdır.

Makine öğrenimi modellerinde veri güvenliği nasıl sağlanır?

Makine öğrenmesi modellerinde veri güvenliği nasıl sağlanır sorusunun cevabı encryption ile başlamalı, fakat orada bitmemelidir. Dataset sınıflandırılır, access least privilege ile sınırlandırılır, network private hâle getirilir ve model artifact'ları signed registry içinde tutulur. Training, inference, log ve backup için ayrı retention ve region policy uygulanır. Membership inference, model extraction ve poisoning saldırıları release öncesi test edilir. Security monitoring, key rotation ve restore testi production yaşam döngüsünün sürekli parçaları hâline getirilir.

Makine öğrenimi süreçlerinde veri yerelliği (Data Residency) neden önemlidir?

Data residency verinin hangi ülkede veya region'da saklandığını ve kurumun locality gereksiniminin karşılanıp karşılanmadığını anlamaya yardımcı olur. Özellikle kişisel, sektörel veya ticari hassas veride yanlış region kullanımı hukuki ve operasyonel risk oluşturabilir. Ancak residency storage ile sınırlı düşünülmemelidir. Training GPU, inference endpoint, embedding API, log ve backup da aynı haritada incelenmelidir. Network egress monitoring ile dokümante edilen locality'nin gerçekte uygulanıp uygulanmadığı doğrulanmalıdır.

On-premise, bulut ve hibrit mimariler arasında veri güvenliği açısından hangi yaklaşım tercih edilmelidir?

On-premise ve bulut makine öğrenmesi modellerinde veri güvenliği karşılaştırması tek kazanan çıkaracak biçimde yapılmamalıdır. On-premise daha fazla fiziksel ve network kontrolü sağlar, fakat operasyon yükünü kuruma taşır. Cloud güçlü managed security ve esneklik sunar, fakat provider, region ve subprocessor risklerini değerlendirmeyi gerektirir. Hybrid mimari hassas workload'u local tutup düşük hassasiyetli workload'u cloud'a taşıyarak dengeli çözüm oluşturabilir. Karar veri sınıfı, compliance, GPU ihtiyacı, latency ve ekip yetkinliğinin birlikte değerlendirilmesiyle verilmelidir.

Makine öğrenimi modellerinde KVKK, veri egemenliği, şifreleme ve erişim kontrolü nasıl yönetilmelidir?

Önce KVKK kapsamındaki kişisel veri akışı data flow diagram üzerinde açıkça çıkarılmalıdır. Yurt dışı aktarım ihtiyacı varsa güncel Kanun ve Kurum düzenlemelerine göre uygun mekanizma değerlendirilmelidir; 2024 sonrası sistemde standart sözleşmeler ve bağlayıcı şirket kuralları uygun güvence yöntemleri arasında yer almaktadır. Encryption key ownership sovereignty hedefiyle ilişkilendirilmelidir. Access RBAC, MFA, JIT ve separation of duties ile sınırlandırılmalıdır. Hukuki hükümler ile gerçek cloud ve ML configuration'ın birbiriyle uyumlu olduğunun düzenli audit ile doğrulanması gerekir. :contentReference[oaicite:13]{index=13}

Makine öğrenimi veri güvenliği ve veri yerelliği konusunda yakınımda danışmanlık veya eğitim nerede bulabilirim?

Yapay zeka veri güvenliği ve makine öğrenmesi danışmanlığı yakınımda şeklinde araştırma yaparken yalnızca model accuracy'sine odaklanan bir eğitim yerine veri güvenliği, privacy, cloud, on-premise ve MLOps konularını birlikte ele alan çalışma ortamı aramak faydalıdır. Diyarbakır'da açık kaynak, yazılım ve yapay zeka alanlarında birlikte üretmek isteyenler Diyarbakır Yazılım Topluluğu hakkında https://www.diyarbakiryazilim.com.tr/about adresinden bilgi alabilir. Topluluk proje çalışmalarını https://www.diyarbakiryazilim.com.tr/projects adresinden inceleyebilirsiniz. Güvenli ML öğrenirken local-first inference, federated learning, differential privacy ve self-hosted RAG gibi küçük uygulamalı projeler güçlü başlangıç sağlar. Özellikle kendi data flow diagram'ınızı çizmek ve egress testini gerçekten yapmak teorik güvenlik bilgisini production düşüncesine dönüştürür.

Sonuç: Güvenli ve Yerel Makine Öğrenimi Mimarisi Nasıl Düşünülmeli?

Makine Öğrenimi Modellerinde Veri Güvenliği ve Yerellik konusu bir cloud region seçeneğini işaretlemekten çok daha geniştir. Verinin nerede saklandığı, hangi GPU üzerinde işlendiği, hangi loglara kopyalandığı, hangi encryption key ile korunduğu ve hangi kullanıcıların erişebildiği birlikte değerlendirilmelidir. Federated learning, differential privacy, secure aggregation, MPC, homomorphic encryption ve confidential computing farklı riskleri hedefleyen tamamlayıcı araçlardır. KVKK tarafında da teknik mimari gerçek yurt dışı aktarım akışıyla uyumlu olmalı ve güncel resmi düzenlemeler takip edilmelidir. Güvenli production sistemi model, veri, infrastructure, privacy ve operasyon ekiplerinin aynı architecture üzerinde birlikte çalışmasıyla kurulur.

Ben yeni bir kurumsal ML projesinde önce “hangi modeli kullanalım?” sorusuyla değil “hangi veri nereden geliyor, nerede işleniyor, kim erişiyor ve hangi noktada dışarı çıkıyor?” sorularıyla başlamayı tercih ediyorum. Bu dört soru cevaplandığında on-premise, cloud, federated veya confidential architecture seçimi çok daha kolay hâle gelir. Ardından model supply chain, privacy attack testleri, backup, unlearning ve vendor exit gibi uzun vadeli işletim başlıkları eklenebilir. Diyarbakır'da güvenli yapay zeka, yerel AI altyapısı, açık kaynak ve makine öğrenmesi projeleri üzerinde birlikte üretmek isterseniz https://www.diyarbakiryazilim.com.tr adresinden Diyarbakır Yazılım Topluluğu'na ulaşabilirsiniz. Küçük bir local-first proje kurup data flow, threat model ve privacy testlerini gerçek olarak uygulamak, güvenli ML mimarisini öğrenmenin en etkili yollarından biridir.