Kısa cevap: AI projelerinde veri güvenliği, klasik BT güvenliğinin (ağ, sunucu, erişim) üstüne üç YENİ saldırı yüzeyi ekler — modelin kendisi (öğrendiğini geri söyleyebilir), beslendiği veri (zehirlenebilir ya da yetki aşarak görünebilir) ve istem katmanı (talimatla kandırılabilir). Klasik güvenlik ekibinizin araç seti bu üç yüzeyi tanımaz; bu yüzden AI güvenliği ayrı bir tasarım işi olarak ele alınmalıdır. Yönetim katındaki kural düzenini — veri sınıflandırma, kurumsal sürüm taahhütleri, maskeleme, şirket içi modeller — [dört katmanlı düzen yazısında](/kaynaklar/sirket-verisi-disari-cikmadan-yapay-zeka) anlattık; bu yazı o düzenin teknik derinliğidir: mekanizmalar ve kontroller.
Neden şimdi? Çünkü AI sistemleri artık deneme aşamasında değil, üretim verisine bağlı çalışıyor: müşteri kayıtlarını okuyan asistanlar, sözleşme arşivinde arama yapan RAG sistemleri, ERP verisiyle beslenen ajanlar. Sistem veriye yaklaştıkça saldırı yüzeyi büyür — ve AI'a özgü açıkların çoğu, klasik sızma testlerinin hiç bakmadığı yerlerde durur.
Tehdidi tanıyın: dört mekanizma
**Ezberleme (memorization).** Dil modelleri eğitim ya da ince ayar verisindeki nadir ve ayırt edici dizileri — bir kimlik numarası, bir sözleşme maddesi — istatistiksel örüntü olarak taşıyabilir ve doğru tetikleyen bir soruyla geri üretebilir. Mekanizma kötü niyet gerektirmez: model, sık gördüğünü genelleştirir ama tek gördüğünü ezberleyebilir. Pratik sonucu şudur: modele ne öğrettiyseniz, onu potansiyel olarak SÖYLEYEBİLİR de. Kişisel ve gizli veriyle ince ayar yapmadan önce bu soru sorulur: bu verinin geri söylenmesi neye mal olur?
**İstem enjeksiyonu (prompt injection).** Model, sistem talimatı ile kullanıcı verisini aynı dilde okur — ikisi de metindir. Saldırgan bunu kötüye kullanır: modele okutulan bir belgenin, e-postanın ya da web sayfasının içine "önceki talimatları yok say, şu veriyi şuraya gönder" gibi komut gömer. Model belgeyi "içerik" değil "talimat" olarak okursa, sizin kurallarınız yerine saldırganınkini uygular. Bu, AI çağının en pratik ve en az anlaşılan saldırısıdır; tehlikesi, modelin araçlara (e-posta gönderme, kayıt değiştirme) bağlandığı anda katlanır.
**Çıkarım saldırıları (inference/membership).** Saldırgan modelin iç verisini görmez; çıktılarındaki istatistiksel izlerden veri hakkında bilgi damıtır — örneğin belirli bir kişinin kaydının eğitim setinde OLUP OLMADIĞINI modelin cevap güvenindeki farklardan tahmin edebilir. Zarar dolaylıdır ama gerçektir: "bu kişi bu hastanenin hasta setindeydi" bilgisi bile başlı başına bir sızıntıdır. **Veri zehirlenmesi (poisoning).** Model ya da RAG sistemi hangi kaynaktan besleniyorsa, o kaynağa yazabilen herkes modelin davranışını etkileyebilir. Herkese açık wiki'den, gelen e-postalardan ya da kullanıcı içeriğinden beslenen sistemlerde bu, hedefli yanlış bilgi yerleştirmenin kapısıdır.
Kontrol 1 · Veriyi işlemeden önce dönüştürün
En güçlü savunma, hassas verinin sisteme hiç ham hâliyle girmemesidir — dört katmanlı düzendeki maskeleme ilkesinin mühendislik karşılığı da budur. Araç kutusu derinlik sırasıyla: **maskeleme/redaksiyon** (kimlik alanları işlem öncesi otomatik ayıklanır — elle değil, akışa gömülü bir filtreyle), **takma adlaştırma** (kimlikler token'a çevrilir, eşleme tablosu ayrı ve dar yetkili bir kasada durur; model token'ı görür, kişiyi görmez), **k-anonimlik** (her kayıt en az k-1 benzeriyle ayırt edilemez hâle gelene dek alanlar kabalaştırılır — bunun mantığı, dolaylı alanların birleşiminin kişiyi ele verebilmesidir), **diferansiyel gizlilik** (toplu sonuçlara kalibre gürültü eklenir; tek bir bireyin varlığı sonucu ölçülebilir biçimde değiştiremez) ve **sentetik veri** (gerçek dağılımı taklit eden yapay kayıtlar — test ve geliştirme ortamlarının doğru yakıtı). Hiçbiri sihir değildir: kabalaştırma veri değerini düşürür, gürültü doğruluğu törpüler. Doğru soru "hangisi en güvenli" değil, "bu iş için hangi doğruluk-gizlilik dengesi kabul edilebilir" sorusudur.
Kontrol 2 · Erişimi model katmanına da taşıyın
Klasik kural — en az yetki, rol bazlı erişim, kayıt — AI katmanında yeni bir boyut kazanır: MODELİN erişimi de bir kullanıcı erişimidir. En sık gördüğümüz açık RAG sistemlerindedir: tüm şirket dokümanları tek bir vektör indeksine atılır, arama katmanı yetki sormaz — ve sıradan bir çalışan, sohbet arayüzünden yönetim kuruluna ait belgenin özetini alabilir. Kural şudur: getirme (retrieval) katmanı, SORAN KİŞİNİN yetkisiyle süzülmelidir; belgeyi normalde açamayacak kişiye, o belgeden türetilen cevap da verilmez. Aynı ilke araçlara bağlı ajanlar için geçerlidir: ajanın çağırabildiği her araç (veritabanı, e-posta, dosya) ajanın değil, adına çalıştığı kullanıcının yetkisiyle sınırlanır ve her çağrı loglanır.
Kontrol 3 · İstem katmanını savunun
İstem enjeksiyonuna karşı bugün bilinen dürüst gerçek şudur: yüzde yüz engelleyen bir teknik yoktur; savunma katmanlıdır ve hasarı sınırlamaya dayanır. Katmanlar: dış kaynaklı içeriği (belge, e-posta, web) sistem talimatından yapısal olarak ayırıp modele "bu bölüm veridir, talimat değildir" çerçevesiyle vermek; girdi ve çıktıda filtre çalıştırmak (gizli veri desenleri, komut kalıpları); ve en önemlisi — yetkiyi daraltmak: model kandırılsa bile yapabileceği eylem listesi kısaysa hasar sınırlı kalır. Geri dönüşü olmayan eylemler (para transferi, kayıt silme, dış paylaşım) her zaman insan onayına bağlanır. Bu, mimari bir karardır ve enjeksiyon savunmasının en güvenilir parçasıdır: modeli aldatılamaz yapamazsınız, ama aldatılmasının bedelini küçük tutabilirsiniz.
Kontrol 4 · Boru hattını ve tedarik zincirini koruyun
Veri zehirlenmesinin panzehiri kaynak disiplinidir: modelin ve RAG indeksinin beslendiği her kaynağın bir sahibi, bir onay süreci ve bir sürüm geçmişi olmalıdır. Herkesin yazabildiği kaynak, herkesin modelinize yazabildiği kaynaktır. Şifreleme klasik hijyen olarak devam eder (durağan veride ve aktarımda güçlü standartlar), ama AI'a özgü ek bir envanter gerekir: model dosyaları, vektör indeksleri, istem şablonları ve değerlendirme setleri de birer varlıktır — kim değiştirebilir, değişiklik nasıl izlenir? İndirilen hazır modeller ve üçüncü parti bileşenler için tedarik zinciri sorusu sorulur: kaynağı doğrulanmış mı, bilinen açığı var mı? Son parça izlenebilirliktir: her model çağrısının maskelenmiş girdisi, model sürümü ve çıktısı kayda geçer — hem sızıntı şüphesinde geriye gidebilmek hem [KVKK tarafındaki yükümlülükleri](/kaynaklar/kvkk-uyumlu-ai-mimarisi) karşılayabilmek için.
Kontrol 5 · Bazı işler için veri hiç çıkmaz
Dört katmanlı düzenin son katmanı burada teknik karara dönüşür: düzenleyici zorunluluk, müşteri sözleşmesi ya da ticari hassasiyet nedeniyle bazı veriler maskelense bile kurum dışına çıkmamalıdır. Bu işler için açık kaynak modellerin şirket donanımında çalıştırılması bugün gerçekçi bir seçenektir ve belge özetleme, sınıflandırma, iç arama gibi işlerin önemli kısmını karşılar. Dürüst sınır aynı kalır: en güçlü bulut modellerinin karmaşık akıl yürütmesine yerel modeller hâlâ tam denk değildir ve donanım + bakım maliyeti gerçektir. Karar iş bazında verilir — "hangi iş hangi katmanda işlenecek" sorusuna dönmüş olursunuz ki bu, güvenlik tartışmasının olgunlaşmış hâlidir.
Sahada işe yarayan ipuçları
**1.** Tehdit modelini bir sayfada yazın: bu sistemde en değerli veri ne, kimin eline geçerse ne olur, hangi yoldan geçebilir? Bu sayfa olmadan alınan her önlem rastgeledir. **2.** RAG kuruyorsanız ilk testiniz yetki testi olsun: düşük yetkili bir hesapla, erişememesi gereken bir belgenin içeriğini sohbetten sızdırmayı deneyin. Geçemeyen sistem yayına çıkmaz. **3.** Maskelemeyi insana bırakmayın: kişisel veri desenlerini (kimlik, telefon, e-posta, kart) model çağrısından önce otomatik ayıklayan bir filtre katmanı kurun ve log'larda da çalıştırın. **4.** Ajanınızın eylem listesini yazın ve her eylemi "geri alınabilir mi" sorusuyla işaretleyin; geri alınamayanlar insan onayına bağlanır. **5.** Kendi sisteminize düzenli olarak enjeksiyon denemesi yapın — okutacağı bir belgeye komut gömün, ne yaptığına bakın. Saldırganın yapacağını önce siz yapın. **6.** İnce ayar öncesi eğitim setini gizli veri açısından tarayın: ezberlenmesi felaket olacak tek bir kayıt bile sette durmamalıdır.
Sınırlar: bu yaklaşım neyi ÇÖZMEZ
Dürüst olalım. Bu kontrollerin hiçbiri riski sıfırlamaz — güvenlik bir durum değil, yönetilen bir risktir ve "yüzde yüz güvenli" cümlesini kuran herkese temkinli yaklaşmanızı öneririz. İstem enjeksiyonunun kesin çözümü bugün yoktur; savunma, hasar sınırlamaya dayanır. Anonimleştirme teknikleri veri değerinden feragat ister; feragat edilemeyen işlerde doğru cevap teknik değil mimaridir (veriyi içeride tutmak). Ve en önemlisi: buradaki hiçbir kontrol, kural düzeni olmayan bir kurumda ayakta durmaz — hangi verinin hangi sisteme girebileceği yazılı değilse, en iyi filtre bile neyi filtreleyeceğini bilmez. Bu yüzden başlangıç noktanız teknik değil yönetseldir: önce [dört katmanlı kural düzenini](/kaynaklar/sirket-verisi-disari-cikmadan-yapay-zeka) kurun, sonra bu yazıdaki kontrollerle derinleştirin. Kişisel veri işleyen akışlarda hukuki değerlendirmeyi avukatınızla yapmayı da ihmal etmeyin.