Veri Zehirleme Nedir? Data Poisoning ve Yapay Zekaya Sinsi Saldırı

Veri zehirleme nedir?

Veri zehirleme, bir yapay zeka sisteminin eğitim, ince ayar ya da bilgi tabanı verisine kasıtlı olarak bozuk, yanıltıcı veya gizli davranış taşıyan kayıtlar sokarak modelin davranışını saldırganın istediği yöne çekme saldırısıdır. Model kodu değişmez; bozulan şey modelin öğrendiği ya da başvurduğu bilgidir.

Basit bir benzetme yapalım. Bir aşçının tarif defterine gizlice yanlış ölçüler yazıldığını düşünün. Aşçı mutfakta dikkatle çalışsa da yemeğin tadı bozuk çıkar. Çünkü hata aşçıda değil, tarifin kaynağındadır.

Yapay zeka modelleri de aynı şekilde çalışır. Model, gördüğü veriden örüntü çıkarır. Veri kaynağına kötü niyetli bir kayıt girerse model bu kaydı da içine alır ve güvenle tekrarlar.

Bu yazıda veri zehirlemeyi tek bir terim olarak ele alıyoruz. Önce çalışma mantığına, sonra türlerine, ardından benzer terimlerle farkına ve savunma yollarına bakacağız. Sonunda işletmeniz için bir kontrol listesi bulacaksınız.

Yapay zeka için veri neden bir saldırı yüzeyi olur?

Klasik yazılımda davranışı kod belirler. Bu yüzden güvenlik ekipleri kodu, sunucuyu ve ağı korumaya yoğunlaşır. Makine öğrenmesinde ise davranışın büyük kısmı veriden doğar. Yani veriyi değiştiren biri, tek satır kod yazmadan sistemin davranışını etkileyebilir.

Bu durum yeni bir risk alanı açar. Modellere çoğu zaman geniş ve karışık kaynaklar veri sağlar: açık web sayfaları, halka açık veri setleri, kullanıcı yorumları, şirket içi belgeler. Bu kaynakların her biri, kontrolü sizde olmayan bir giriş kapısıdır.

Ayrıca veri hattı uzundur. Toplama, temizleme, etiketleme, eğitim ve yayın aşamalarının her birinde biri araya girebilir. Zincirin en zayıf halkası, saldırganın seçtiği halkadır.

Güvenlik standartları da bu nedenle konuya ayrı başlık açıyor. OWASP, büyük dil modeli uygulamaları için yayımladığı risk listesinde veri ve model zehirlemeyi ayrı bir risk olarak sayar. Aynı çerçevede amaç, yalnızca modeli bozmak değil, gizli davranış yerleştirmek de olabilir.

Veri zehirleme nasıl çalışır?

Çalışma mantığı kavramsal olarak üç adımdan oluşur. İlk adımda saldırgan, modelin ya da sistemin okuyacağı bir veri kaynağına erişir. Bu erişim bazen doğrudan olur, bazen de herkesin katkı verebildiği açık bir kaynak üzerinden dolaylı olarak gerçekleşir.

İkinci adımda bozuk kayıtlar veri hattına karışır. Kayıtlar çoğu zaman sıradan bir kayıt gibi durur. Bu yüzden basit bir göz taramasıyla fark edilmezler. Etkili zehirleme sessizdir; sistem çalışmaya devam eder.

Üçüncü adımda model bu kayıtlara bakarak ağırlıklarını ayarlar ya da sistem bu kayıtları cevabına katar. Böylece davranış değişir. Değişim bazen genel bir kalite düşüşü olarak karşınıza çıkar. Bazen de yalnızca belirli bir konuda ya da belirli bir koşulda ortaya çıkar.

1. Saldırgan, veri kaynağına katkı verme ya da kaynağı değiştirme imkânı bulur.
2. Bozuk kayıtlar, toplama ve temizleme aşamalarından fark edilmeden geçer.
3. Model eğitimde ya da cevap üretirken bu kayıtları esas alır.
4. Etkiyi ancak tuhaf cevaplar alan kullanıcılar ya da bir değerlendirme ortaya çıkarır.

Bu yazı bilerek saldırı tarifi vermez. Amacımız süreci anlamanız ve savunmanızı buna göre kurmanızdır. Ayrıca zehirlemenin her zaman büyük ölçek gerektirmediğini bilmek önemlidir; küçük ama hedefli bir müdahale, doğru yerde yapıldığında büyük etki yaratabilir. Bu yüzden risk değerlendirmesinde yalnızca veri miktarına değil, verinin modelin davranışı üzerindeki ağırlığına da bakarsınız.

Veri zehirlemenin türleri nelerdir?

Veri zehirlemeyi, hangi aşamanın hedeflendiğine göre üç ana gruba ayırabiliriz. Bu ayrım, savunmayı nerede kuracağınızı da belirler.

• Eğitim verisi zehirleme: Sıfırdan eğitim ya da ön eğitim verisine bozuk kayıt karışır.
• İnce ayar zehirleme: Hazır bir modeli kendi verinizle uyarlarken kullandığınız veri setine bozuk kayıt girer.
• Bilgi tabanı zehirleme: Modelin cevap verirken başvurduğu belge deposuna (RAG) yanıltıcı belge girer.

İlk iki tür modelin içine işler. Yani zehir, model ağırlıklarına yerleşir ve geri almak için yeniden eğitim gerekir. Üçüncü tür ise modele dokunmaz; yalnızca modelin okuduğu kaynağa zarar verir. Bu nedenle düzeltmesi daha kolaydır, ama tespit etmesi her zaman kolay değildir.

Ayrıca amaca göre de bir ayrım yapabilirsiniz. Bazı saldırılar genel doğruluğu düşürmeyi hedefler. Bazıları ise yalnızca belirli bir konuda yanlış cevap üretmeyi ya da gizli bir davranış eklemeyi amaçlar. ABD Ulusal Standartlar ve Teknoloji Enstitüsü (NIST), düşmanca makine öğrenmesi taksonomisinde zehirleme saldırılarını ayrı bir saldırı sınıfı olarak ele alır.

Arka kapı ve tetikleyici kavramı ne anlama gelir?

Arka kapı (backdoor), modelin normal koşullarda sorunsuz çalışıp yalnızca belirli bir işaret gördüğünde farklı davranmasıdır. Bu işarete tetikleyici denir. Tetikleyici bir kelime, bir desen ya da bir veri özelliği olabilir; kavramın özü, gizli bir kural gibi davranmasıdır.

Buradaki tehlike, modelin standart testlerde başarılı görünmesidir. Test verisinde tetikleyici yoksa model beklendiği gibi cevap verir. Dolayısıyla genel doğruluk puanına bakarak güvende olduğunuzu varsaymak yanıltıcı olur.

Bir benzetme işe yarar. Bir bina güvenlik denetiminden geçer; kapılar kilitli, kameralar çalışıyor. Ama yapım aşamasında biri gizli bir yan kapı bırakmıştır. Yalnızca o kapıyı bilen kişi içeri girer. Arka kapı da modelin içinde böyle bir gizli yoldur.

Güvenli tarafta kalmak için burada tetikleyicinin nasıl tasarlandığını anlatmıyoruz. Önemli olan, bu riskin var olduğunu bilmeniz ve model kaynağını sorgulamanızdır. Özellikle dışarıdan indirdiğiniz hazır modellerde bu soru geçerlidir.

RAG belge zehirleme nedir ve neden özellikle önemlidir?

RAG (retrieval augmented generation), modelin cevap vermeden önce bir belge deposunda arama yapıp bulduğu parçaları cevaba eklemesidir. Konuyu ayrıntılı olarak RAG nedir yazımızda anlattık. Burada yalnızca güvenlik tarafına bakıyoruz.

RAG belge zehirleme, bu depoya yanıltıcı ya da bozuk bir belge sokulmasıdır. Model, aramada bu belgeyi bulursa içeriğine güvenir ve cevabına katar. Model hiç değişmez; yalnızca okuduğu kaynak bozulmuştur.

Bu tür önemlidir, çünkü saldırı bariyeri düşüktür. Eğitim verisini bozmak büyük ölçek gerektirebilir. Oysa paylaşılan bir klasöre, herkesin yazabildiği bir wiki sayfasına ya da kullanıcı yüklemelerine tek bir belge eklemek çok daha kolaydır.

Üstelik bu belge bir de istem enjeksiyonu taşıyabilir. Yani belgenin içine, modele talimat gibi görünen metinler gizlenebilir. Bu ayrı bir risk olduğu için aşağıdaki tabloda ve istem enjeksiyonu yazımızda ele alıyoruz.

Belgelerin parçalanma biçimi ve aramanın nasıl çalıştığı da önemlidir. İlgili temel kavramlar için belge parçalama ve embedding yazılarına göz atabilirsiniz.

İnce ayar ve kullanıcı geri bildirimi zehirlenmesi nasıl ortaya çıkar?

İnce ayar, hazır bir modeli kendi verinizle belirli bir göreve uyarlamaktır. Konunun temelini fine tuning ve LoRA yazımızda bulabilirsiniz. Veri seti küçük olduğu için tek tek kayıtların etkisi büyüktür.

Risk, özellikle kullanıcı içeriğiyle ince ayar yapan sistemlerde artar. Örneğin kullanıcıların beğeni ya da düzeltme verdiği bir sohbet uygulamasını düşünün. Bu geri bildirimler toplanıp modeli iyileştirmek için kullanılıyorsa, birileri bu kanalı kasıtlı olarak yönlendirebilir.

Burada sorun, geri bildirimin güvenilir olduğunu varsaymaktır. Gerçek kullanıcılar ile kötü niyetli kullanıcıları ayıran bir süzgeç yoksa, her beğeni ve her düzeltme potansiyel bir veri kaynağı olur. Bu nedenle otomatik öğrenme döngülerinde insan onayı önemli bir güvencedir.

Bir başka kaynak, başka modellerin ürettiği verilerdir. Sentetik veri kullanıyorsanız kaynağın kalitesini ve güvenilirliğini ayrıca sorgulamalısınız. Bu konuyu sentetik veri yazımızda işledik.

Veri zehirleme nedir, prompt injection ve model çöküşünden farkı ne?

Bu üç terimi sık birbirine katarız, çünkü üçü de yapay zekayı bozan veri sorunlarıyla ilgilidir. Oysa zamanlama, amaç ve çözüm yolları birbirinden farklıdır. Aşağıdaki tablo farkı özetliyor.

Tablodan çıkan sonuç şudur: veri zehirleme "ne öğrendiği" sorunudur, prompt injection "şimdi neye uyduğu" sorunudur, model çöküşü ise "kendi kendini taklit etmesi" sorunudur. Model çöküşünü ayrı bir yazıda anlattık.

İki saldırı birbirini de besleyebilir. Örneğin zehirli bir belge, içinde gizli talimat taşıyorsa hem veri zehirleme hem istem enjeksiyonu etkisi yaratır. Bu yüzden savunmayı tek bir katmana bırakmayın.

Veri zehirleme kimler için risk oluşturur?

Her yapay zeka kullanıcısı aynı düzeyde risk taşımaz. Risk, verinin nereden geldiğine ve kimlerin ona dokunabildiğine bağlıdır. Aşağıdaki gruplar daha yakından izlenmelidir.

• Dış kaynaktan veri toplayanlar: Web taraması ya da halka açık veri setleriyle model eğiten ekipler, kaynağı denetleyemez.
• Kullanıcı içeriğiyle ince ayar yapanlar: Yorum, geri bildirim ya da sohbet kayıtlarını eğitime katan ürünler.
• Açık bilgi tabanı kullananlar: Herkesin yazabildiği wiki, forum ya da paylaşımlı belge depolarına bağlı RAG sistemleri.
• Hazır model indirenler: Kaynağını doğrulamadığı modelleri doğrudan üretime alan ekipler.

Buna karşılık yalnızca kendi kontrol ettiğiniz, sürüm numaralı ve onaylı belgelerle çalışan küçük bir sistemin riski daha düşüktür. Ancak risk sıfır değildir. İçeriden yapılan hatalar ve yanlış sürüm yüklemeleri de benzer bozulmalara yol açabilir.

Kısacası soru şudur: Verinizin kapısında kim duruyor, ve siz o kapıyı gerçekten denetliyor musunuz? Bu sorunun cevabı net değilse, aşağıdaki savunma bölümleri sizin için önceliklidir.

Bir işletmede veri zehirleme nasıl ortaya çıkar?

Aşağıdaki bir örnek senaryodur; gerçek bir müşteri ya da olay değildir. Bir mağazanın, iade koşullarını paylaşılan bir belge klasöründen okuyan bir müşteri destek asistanı olduğunu varsayalım.

Klasöre herkes belge yükleyebiliyor. Bir gün klasöre, iade koşullarını yanlış anlatan bir belge düşüyor. Asistan aramada bu belgeyi buluyor ve müşterilere yanlış iade süresi söylemeye başlıyor. Model sağlıklı çalışıyor, ama cevaplar yanlış.

Bu senaryoda saldırgan olmayabilir. Dikkatsiz bir çalışan da aynı sonucu doğurabilir. Fakat kötü niyetli biri aynı yolu bilinçli kullanırsa, etki daha hedefli olur ve gözden kaçması kolaylaşır.

Sonuç olarak işletme, müşteri güvenini ve belki de hukuki sorumluluğu riske atar. Bu yüzden kurumsal bilgi asistanı kuran ekiplerin içerik yönetişimini baştan planlaması gerekir. Böyle bir sistem için kurumsal bilgi asistanı çözümümüzü inceleyebilirsiniz.

Zehirlenmenin belirtileri nelerdir ve nelere bakmalısınız?

Zehirlenme çoğu zaman sessizdir, ama bazı işaretler şüphe uyandırmalıdır. Hiçbir belirti tek başına kanıt değildir; birkaçı bir arada görülünce araştırma başlatmak mantıklıdır.

• Model, belirli bir konuda ısrarla aynı yanlış cevabı veriyor.
• Cevap kalitesi, bir veri güncellemesinin hemen ardından belirgin biçimde değişiyor.
• Aynı soruya, ifade biçimine göre çok farklı bir kesinlikle cevap geliyor.
• Bilgi tabanında kaynağı belirsiz, yeni eklenmiş ve çok sık öne çıkan belgeler var.
• Kullanıcı şikâyetleri belirli bir konu ya da ürün etrafında toplanıyor.

Bu işaretleri yakalamak için izleme gerekir. Örneğin hangi belgenin kaç cevapta kullanıldığını kaydedebilirsiniz. Bir belge aniden öne çıkıyorsa, nedenini incelemek iyi bir başlangıçtır.

Ayrıca düzenli değerlendirme setleri çalıştırmak, veri değişikliklerinin etkisini ölçmenizi sağlar. Böylece bir güncellemenin öncesi ve sonrasını karşılaştırabilirsiniz. Değerlendirme yaklaşımı için LLM evals yazımıza bakın.

Veri kökeni takibi (data provenance) neden savunmanın temelidir?

Veri kökeni, bir kaydın nereden geldiğini, kim tarafından, ne zaman eklendiğini ve hangi dönüşümlerden geçtiğini gösteren izdir. Kaynağını bilmediğiniz veriye güvenemezsiniz. Bu basit ilke, savunmanın ilk katmanıdır.

OWASP da veri kökenini izlemeyi, güvenilir kaynak kullanmayı ve veri sürümlerini saklamayı temel önlemlere dahil ediyor. Bunun mantığı açıktır: Bir sorun çıktığında hangi kayıtların etkilendiğini bulabilmeniz gerekir.

1. Her veri kaynağı için sahibini ve güven düzeyini kaydedin.
2. Veri setlerini sürümleyin; her eğitimin hangi sürümle yapıldığını not edin.
3. Dışarıdan alınan veriyi, iç veriden ayrı bir alanda tutup doğrulayın.
4. Kayıtların özetini (hash) saklayın ki sonradan değişiklik olursa fark edin.

Bu kayıtlar sadece güvenlik için değil, hata ayıklama için de değerlidir. Model bir gün garip davranınca, geriye dönük izleme yapabilirsiniz. Böylece sorunlu sürümü hızla ayırır, öncekine dönersiniz.

Erişim kontrolü ve onay sürecini nasıl kurarsınız?

Zehirlemenin en ucuz engeli, veriye kimin yazabileceğini sınırlamaktır. En az yetki ilkesi burada da geçerlidir. Bilgi tabanına belge ekleyebilen kişi sayısı azaldıkça saldırı yüzeyi de daralıyor.

Pratikte iki katman işe yarar. Birincisi yazma yetkisinin rol bazlı verilmesidir. Yani herkes değil, yalnızca sorumlu kişiler ekleme yapabilir. İkincisi ise eklemelerin bir onay adımından geçmesidir.

• Bilgi tabanına yazma yetkisini küçük ve bilinen bir grupla sınırlayın.
• Yeni belgeleri, yayına girmeden önce ikinci bir kişinin onayına bağlayın.
• Kullanıcı yüklemelerini ayrı bir alanda tutun ve ana bilgi tabanına doğrudan almayın.
• Her değişikliği kimin yaptığıyla birlikte kaydedin.

Bu önlemler özellikle RAG sistemlerinde etkilidir. Çünkü orada zehir, modele değil belgeye girer ve belge tarafında klasik erişim kontrolü yöntemleri hemen uygulanabilir. Modelin çıktısını sınırlayan katmanlar için guardrails yazımıza göz atabilirsiniz.

Anomali tespiti, değerlendirme ve red teaming zehirlenmeye karşı nasıl yardım eder?

Önleme tam olmaz; bu yüzden tespit katmanı da gerekir. Anomali tespiti, veri setindeki alışılmadık kayıtları işaretlemeyi amaçlar. Örneğin diğerlerinden belirgin biçimde farklı, tekrar eden ya da kaynağı belirsiz kayıtları incelemeye alırsınız.

Değerlendirme tarafında ise iki fikir birleşir. Birincisi, her veri değişikliğinden sonra sabit bir test setini çalıştırmaktır. İkincisi, bu test setine yalnızca genel doğruluğu değil, hassas konulardaki davranışı da dahil etmektir.

Red teaming ise savunma amaçlı yetkili bir test yaklaşımıdır. Ekip, sistemi saldırgan gözüyle sınar ve zayıf noktaları sizden önce bulur. Bu konuyu AI red teaming yazımızda ayrıntılı anlattık.

Üç yöntem birbirini tamamlar. Anomali tespiti girişte, değerlendirme çıkışta, red teaming ise sistemin bütününde çalışır. Hiçbiri tek başına yeterli değildir; birlikte kullanıldığında ise açıkları belirgin biçimde azaltır.

Zehirlenme şüphesi doğarsa ne yaparsınız?

Şüphe doğduğunda panik yapmak yerine sıralı ilerlemek işi kolaylaştırır. Aşağıdaki adımlar genel bir olay müdahale akışıdır; kendi sisteminize göre uyarlayın.

1. Şüpheli veri kaynağını ve ilgili güncellemeyi belirleyin.
2. Gerekirse etkilenen bilgi tabanı bölümünü geçici olarak devre dışı bırakın.
3. Son bilinen sağlıklı veri sürümüne dönün.
4. Sorunlu kayıtları inceleyin ve kaynağını, yani nasıl girdiklerini bulun.
5. Erişim ve onay kurallarını, açığı kapatacak şekilde güncelleyin.
6. Modeli yeniden eğitmeniz gerekiyorsa, temiz veriyle baştan başlayın ve değerlendirme setiyle sınayın.

RAG sistemlerinde bu süreç daha hızlıdır, çünkü yalnızca belgeyi çıkarırsınız. Eğitim ya da ince ayar zehirlenmesinde ise model ağırlıkları bozulmuş olabilir ve yeniden eğitim şart olabilir.

Önemli bir not: Olayın etkisi kişisel veri ya da müşteri bilgisi içeriyorsa, hukuki yükümlülükleriniz doğabilir. Bu yazı hukuki danışmanlık değildir; böyle bir durumda uzman bir hukukçuya danışmalısınız.

Veri zehirleme nedir sorusunun sınırları ve sık yanlış anlamaları neler?

Konu hakkında birkaç yaygın yanlış anlama var. Bunları netleştirmek, gereksiz korkuyu ve gereksiz rehaveti birlikte azaltır.

• "Büyük şirketlerin modelleri zehirlenmez." Hiçbir model bağışık değildir; risk, veri kaynağının doğasına bağlıdır.
• "Yüksek doğruluk, güvenli demektir." Arka kapılı bir model, standart testlerde başarılı görünebilir.
• "Yalnızca eğitim verisi risklidir." Bilgi tabanı ve geri bildirim döngüleri de aynı derecede önemli yüzeylerdir.
• "Tek bir araç sorunu çözer." Savunma katmanlıdır; kök neden çoğunlukla süreçtedir.

NIST taksonomisi de mevcut savunmaların kesin güvence vermediğini ve açık araştırma sorularının sürdüğünü vurgular. Bu nedenle hedefiniz riski sıfırlamak değil, azaltmak ve fark edebilmektir.

Ayrıca bu alan hızlı gelişiyor. Yöntem ve araçların güncel durumunu, ilgili standart kuruluşlarının ve sağlayıcıların resmi belgelerinden kontrol etmenizi öneririz.

Zehirlenmiş veri neden bu kadar zor ayırt edilir?

Veri zehirleme nedir sorusunun en rahatsız edici yanı, saldırının çoğu zaman sıradan veriye benzemesidir. Bozuk bir kayıt, bir yazım hatası ya da eski bir bilgi gibi görünebilir. Dolayısıyla bir insan gözden geçirse bile ayırt etmek güçleşir.

İkinci zorluk ölçektir. Büyük bir veri setinde milyonlarca kayıt bulunabilir ve hepsini tek tek okumak mümkün değildir. Bu nedenle örnekleme ve otomatik kontroller devreye girer, ama kusursuz değildir.

Üçüncü zorluk, etkinin dağınık olmasıdır. Model genel olarak iyi çalışır, yalnızca dar bir konuda yanlış cevap verir. Test setiniz o konuyu kapsamıyorsa sorun görünmez kalır.

Son olarak, kötü veri her zaman saldırıdan gelmez. Eski belgeler, çelişen sürümler ve hatalı etiketler de benzer bozulmalara yol açar. Dolayısıyla iyi bir veri hijyeni, hem kasıtlı hem kazara oluşan sorunlara karşı aynı anda koruma sağlar.

Hazır model ve veri setleri tedarik zinciri riski taşır mı?

Evet, taşır. Yazılımda bir kütüphaneyi doğrulamadan projeye eklemek riskliyse, hazır bir model ya da veri setini doğrulamadan kullanmak da aynı riski doğurur. Bunu yapay zeka tedarik zinciri riski olarak adlandırıyoruz.

Model dosyalarını ve veri setlerini paylaşan platformlar çok değerlidir. Ancak herkesin katkı verebildiği bir ortamda, bir paketin gerçekten iddia ettiği içeriği taşıdığından emin olmak size düşer. Sağlayıcının resmi belgelerindeki doğrulama önerilerini okumak iyi bir alışkanlıktır.

• Modeli ve veri setini yalnızca bilinen, sorumluluğu belli kaynaklardan alın.
• İndirdiğiniz dosyanın özetini (hash) yayıncının verdiğiyle karşılaştırın.
• Yeni bir modeli doğrudan üretime almadan önce ayrı bir test alanında değerlendirin.
• Lisans ve kullanım koşullarını da kayıt altına alın.

Böylece hem güvenlik hem de uyumluluk tarafında sağlam bir kayıt oluşturursunuz. Güvenlik katmanlarını tek tek planlamak istiyorsanız yapay zeka entegrasyonu çözümlerimizde yapay zeka entegrasyonu sayfasına bakabilirsiniz.

Veri zehirleme nedir sorusunu sıradan kalite sorunlarından nasıl ayırırsınız?

Her kötü cevap bir saldırı değildir. Çoğu zaman sorun halüsinasyon, eksik veri ya da eski belgedir. Gereksiz alarmdan kaçınmak için önce basit açıklamaları eleyin.

1. Hatayı yeniden üretebiliyor musunuz? Tutarlı bir hata, rastgele bir halüsinasyondan ayrılır.
2. Hata belirli bir veri güncellemesinden sonra mı başladı?
3. Yanlış cevabın dayandığı belge ya da kayıt izlenebiliyor mu?
4. Belgeyi ekleyen kişi ve ekleme zamanı biliniyor mu?

Bu sorulara net cevap verebiliyorsanız, olayın kazara mı kasıtlı mı olduğunu da anlayabilirsiniz. Cevap veremiyorsanız, asıl eksik izleme düzenidir. Halüsinasyonun ayrı bir olgu olduğunu unutmayın; ayrıntıları için halüsinasyon yazımıza bakabilirsiniz.

Veri güvenliği için ekipte kim sorumlu olmalı?

Veri zehirleme nedir sorusuna teknik cevap yeterli değildir; sorumluluğun kimde olduğu da net olmalıdır. Pek çok kurumda veri hazırlayan ekip, modeli kuran ekip ve ürünü yöneten ekip ayrı kişilerden oluşur. Sorun çıkınca herkes bir başkasının sorumlu olduğunu düşünür.

Bu belirsizliği gidermek için üç rol tanımlamak işe yarar. Veri sahibi, her kaynağın içeriğinden ve güncelliğinden sorumludur. Model sahibi, hangi verinin eğitime ya da bilgi tabanına gireceğine onay verir. Güvenlik sorumlusu ise erişim kurallarını, izlemeyi ve olay müdahale akışını yönetir.

Küçük ekiplerde bu roller aynı kişide toplanabilir. Önemli olan, rollerin yazılı olması ve birbirinden bağımsız bir ikinci gözün onay vermesidir. Böylece tek bir hata ya da tek bir kötü niyetli kişi, veri hattını tek başına bozamaz.

Son olarak ekibinizi eğitmeyi ihmal etmeyin. Çalışanların hangi belgeyi nereye yükleyebileceğini bilmesi, zehirlemenin en yaygın kapısını kapatır. Kurumsal eğitim için kurumsal yapay zeka eğitimi sayfamızı inceleyebilirsiniz.

Veri zehirleme nedir diye soran bir işletme için pratik kontrol listesi nasıl olmalı?

Aşağıdaki liste, küçük ve orta ölçekli bir ekibin başlangıç noktası olabilir. Hepsini bir günde yapmanız gerekmez; önceliği kendi risk durumunuza göre belirleyin.

• Modelinizin ve bilgi tabanınızın hangi kaynaklardan beslendiğini yazılı olarak listeleyin.
• Kimlerin veriye yazabildiğini gözden geçirin ve gereksiz yetkileri kaldırın.
• Yeni belge ve veri eklemelerini onay sürecine bağlayın.
• Dışarıdan indirdiğiniz model ve veri setlerinin kaynağını doğrulayın.
• Her veri güncellemesinden sonra sabit bir değerlendirme seti çalıştırın.
• Hangi belgenin cevaplarda ne sıklıkta kullanıldığını izleyin.
• Önceki sağlıklı veri sürümüne dönebilecek bir yedekleme düzeni kurun.
• Yılda en az bir kez, yetkili bir red teaming çalışması planlayın.

Bu listede ilk üç madde en düşük maliyetli ve en yüksek etkili olanlardır. Çoğu ekip için işe oradan başlamak mantıklıdır.

Kurumunuzda yapay zeka kullanımını güvenli kurmak istiyorsanız, yapay zeka danışmanlığı sayfamızdan bize ulaşabilirsiniz. Genel hizmet çerçevemiz için yapay zeka ve otomasyon hizmetlerimize de bakabilirsiniz.

Veri zehirleme hakkında daha fazlasını nereden öğrenebilirsiniz?

Konuda en güvenilir başlangıç noktası, standart kuruluşlarının ve güvenlik topluluklarının resmi yayınlarıdır. Bu yazıdaki çerçeve de bunlara dayanıyor.

• OWASP Top 10 for LLM Applications: Büyük dil modeli uygulamaları için risk listesi; veri ve model zehirleme ayrı bir madde olarak yer alır.
• NIST düşmanca makine öğrenmesi taksonomisi: Zehirleme dahil saldırı türlerini ve terimleri sınıflandıran resmi yayın.

Bu kaynakları yazarları sürekli yeniliyor. Bu yüzden belirli bir sürüme ya da sayıya yaslanmak yerine, yayını açıp güncel halini okumanızı öneririz. Yazıdaki bilgiler genel eğitim amaçlıdır ve güvenlik ya da hukuki danışmanlık yerine geçmez.

Özetle veri zehirleme, yapay zekanın öğrendiği ya da okuduğu bilgiyi hedef alan sessiz bir saldırıdır. Savunmayı veri kökeni, erişim kontrolü, izleme ve düzenli sınamayla kurarsınız. Kaynağını bilmediğiniz veriye sistemin kapısını açmayın.