AI Safety ve AI Security Arasındaki Temel Farklar Nelerdir?

Büyük işletmelerin Operasyonel ve Üretken Yapay Zeka (GenAI) entegrasyonu hızlandıkça, yönetim kurullarında ve CISO toplantılarında iki terim sıklıkla masaya gelmektedir: AI Safety (Yapay Zeka Emniyeti) ve AI Security (Yapay Zeka Siber Güvenliği). Bu iki disiplin çoğu zaman eşanlamlı gibi kullanılsa da, güvenlik mühendisliği açısından tamamen farklı endişeleri hedef alırlar.

LLM'lerinizi ve otonom iş akışlarınızı devreye almadan önce, bu uçurumun farkında olmak veri mahremiyetini ve marka değerinizi kurtaracak tek önlemdir. Konuyu en basit tanımıyla özetlemek gerekirse: AI Safety, insanlığı yapay zekanın "hata ve zararlarından" korur; AI Security ise yapay zekayı kötü niyetli insanlardan (saldırganlardan) korur.

---

1. AI Safety (Yapay Zeka Emniyeti) Nedir ve Neye Odaklanır?

Yapay zeka emniyeti (AI Safety), bir modelin amaçlandığı gibi davranmasını, teknik öngörülebilirliği korumasını ve insan değerleriyle "uyumlu" (Alignment) kalmasını amaçlar. Emniyet çalışmaları sistemin kendiliğinden çığırından çıkarak kazara kullanıcılara veya kuruma zarar vermesini engellemeye odaklanır. Ortada aktif, kötü niyetli bir hacker yoktur; modelin bizzat kendi tasarımsal eksiklikleri vardır.

AI Safety uzmanlarının temel olarak ilgilendiği konular ve problemler şunlardır:

• Halüsinasyon (Hallucination): Modelin kurgusal ve tamamen yanlış bilgileri yüksek bir özgüven tonuyla, yalan makinesi gibi "doğruymuşçasına" raporlaması. Bu durum hukuki ve medikal danışmanlıklarda devasa bir emniyet krizidir.
• Toplumsal Önyargı (Bias) ve Adalet: Algoritmanın eğitim verisindeki azınlık veri kümelerinin eksikliği nedeniyle, kredi veya işe alım algoritmalarının ırk veya cinsiyete göre ayrımcı (bias) kararlar vermesi.
• Toksisite Kategorisi: AI motorunun kullanıcılara nefret söyleminde bulunması veya şiddet içeren eylemler (örneğin patlayıcı kimyasal şeması verme) için yardımcı olmasını engellemek üzere filtreler ("Guardrails") konulması.
• Varoluşsal Emniyet (AGI Alignment): Gelecekteki süper zeka (AGI) modellerinin insanlığı yok etmeden veya insanlık değerlerine paralel kararlar verecek şekilde kısıtlanması.

---

2. AI Security (Yapay Zeka Siber Güvenliği) Nedir?

AI Security ise denkleme kötü niyetli, proaktif bir siber saldırganı (Adversary) koyar. Bu disiplin, eğitim aşamasından başlayarak canlıya alınan makine öğrenimi modellerini hedeflenmiş dış ve iç siber saldırılara karşı savunma bilimidir.

AI Security kapsamında sistemlerin izole edilmesi, Pentest (Sızma Testi) uygulamaları ve açık zafiyet yönetimi devreye girer:

• Prompt Injection (İstem Enjeksiyonu): Hackerların, sistemin orijinal komutlarını ezen kurnaz prompt'lar tasarlayarak modeli manipüle etmesidir (Jailbreaking). Örneğin başarılı bir enjeksiyon, müşteri hizmetleri asistanını şirket veri tabanındaki tüm kullanıcı T.C. kimlik numaralarını dışarı çıkartması için ikna edebilir.
• Veri Zehirlenmesi (Data Poisoning): Kötü niyetli aktörlerin yapay zekayı eğittiğiniz ilk veri okyanusuna sızarak, modelin içine bilinçli olarak truva atları ve "Arka Kapılar" (Backdoors) yerleştirmesi olayıdır.
• Tersine Mühendislik (Model Extraction): Yüz binlerce dolar harcayarak ürettiğiniz algoritmaya, saldırganın API sınırlarını esneterek on milyonlarca sorgu yollaması ve sonucunda yapay zekanızın "tasarım ağırlıklarının" birebir bir kopyasını kendi bilgisayarlarına indirebilmesidir.
• Adversarial Noise (Saldırgan Gürültü): Otonom sensörlere, sadece matematiksel olarak farklılık gösteren pikselli objeler göstererek, çok sağlam bir güvenlik kamerasının içeriye elinde silahlı birini "Ziyaretçi Şemsiyesi" olarak etiketlemesini sağlayacak bypass yöntemleri.

---

3. Kurumsal Çarpışma: Neden Sadece "Emniyet" Yetersizdir?

Günümüzde dev teknoloji şirketleri piyasaya sürdükleri dil modellerini (Örn: ChatGPT veya Claude) ağırlıklı olarak AI Safety (Emniyet) standartlarında değerlendirmektedir. Modeli ahlaklı ve halüsinasyon görmez hale getirmek ticari bir gerekliliktir. Ancak şu altın kural unutulmamalıdır: Bir model son derece "Emniyetli" (Safe) olabilirken siber güvenliği sınıfta kalmış (Insecure) olabilir.

Trajikomik Senaryo: Bir fintek firması, mobil bankacılık uygulamasının içine müşteriler için harika bir "Yatırım Asistanı" kurmuştur. Geliştiriciler modele kesinlikle siyasi görüş paylaşmaması, argo kelime etmemesi için mükemmel sınırlar ("AI Safety") çizmiştir. Asistan çok temiz konuşmaktadır. Fakat yetenekli bir siber saldırgan bu asistanla konuşmaya başlar. SQL benzeri komutlar ve gelişmiş Prompt Injection teknikleri ile modele veritabanını dökmesini emreder. Model son derece kibar, ahlaklı ve kurumsal (Safe) bir dil kullanarak şirketteki 1 milyon müşterinin kredi ekstresini CSV formatında korsana uzatır!

Sonuç: Kapsamlı AI Savunma Stratejisi

Güvenli bir yapay zeka deneyimi inşa etmek istiyorsanız, bu iki disiplini birbirinden beslenerek büyüyen iki kardeş olarak ele almalısınız. AI geliştiricileriniz makine öğrenimi modellerinin etik sınırlarından ("Safety") taviz vermemeli; kurumsal Güvenlik Opearsyonları ve Sızma Testi Ekipleri (Red Team) ise acımasızca modele saldırarak "AI Security" bariyerlerinin yüksek basınca ("Stress-test") ne kadar dayanabileceğini ispatlamalıdır.

Saha Kontrol Notları

Bu başlık pratikte yalnızca teorik risk olarak ele alınmamalıdır. AI sistemlerinde zafiyetin etkisi, modelin bulunduğu ortam ve bağlı olduğu veri kaynaklarıyla birlikte değişir.

İnceleme sırasında şu kanıtlar toplanmalıdır:

• Model veya agent hangi ortamda çalışıyor?
• Hangi kullanıcı veya servis hesabı kullanılıyor?
• Hassas veri kaynakları ayrı etiketlenmiş mi?
• Model dosyası veya artefact kaynağı doğrulanmış mı?
• Yükleme anında kod çalıştırma riski var mı?
• Retrieval sonuçları kullanıcı yetkisine göre filtreleniyor mu?
• Tool çağrıları ayrı loglanıyor mu?
• Kritik aksiyonlarda onay mekanizması var mı?
• Test ortamı production verisinden ayrılmış mı?
• Olay halinde hangi loglardan geri dönüş yapılacak?

Uygulama Kontrol Listesi

• Güvenilmeyen model dosyaları izole ortamda açılmalı.
• Model registry erişimi minimum yetkiyle çalışmalı.
• Hash, imza veya provenance bilgisi tutulmalı.
• Agent tool izinleri görev bazlı ayrılmalı.
• Memory ve retrieval kaynakları ayrı güven sınırı olarak ele alınmalı.
• Prompt testleri runtime aksiyon testleriyle desteklenmeli.
• Her bulgu iş etkisiyle birlikte raporlanmalı.

Karar Noktası

Bu risk müşteri verisine, üretim API’sine, geliştirici ortamına veya model yükleme hattına dokunuyorsa bekletilmemelidir. Eresus Security bu tip incelemelerde dosya, runtime, tool ve veri sınırını birlikte test ederek gerçek saldırı yolunu kanıtlar.

Operasyonel İnceleme Checklisti

• Model veya agent kaynağı doğrulandı mı?
• Tool izinleri minimum yetkiyle mi tanımlandı?
• Retrieval sonucu kullanıcı yetkisine göre filtreleniyor mu?
• Memory kalıcı talimat riskine karşı incelendi mi?
• Model artefact hash veya imza ile takip ediliyor mu?
• Yükleme işlemi sandbox içinde test edildi mi?
• Prompt testi runtime aksiyon testiyle desteklendi mi?
• MCP veya plugin server listesi çıkarıldı mı?
• Agent production API çağırıyorsa onay var mı?
• Veri sızıntısı senaryosu kontrollü denendi mi?
• Kapsam net yazıldı mı?
• Etkilenen varlık sahibi belli mi?
• Test ortamı production etkisinden ayrıldı mı?
• Kullanıcı rolleri doğru temsil ediliyor mu?
• Hassas veri sınıfı tanımlandı mı?
• Yetki sınırı teknik olarak doğrulandı mı?
• Log kaynağı ve saklama süresi belli mi?
• Bulgu tekrar üretilebilir kanıtla destekleniyor mu?
• İş etkisi teknik etkiden ayrı açıklandı mı?
• Düzeltme sahibi belirlendi mi?
• Retest kriteri yazıldı mı?
• Benzer risklerin nerelerde tekrar edebileceği kontrol edildi mi?
• Monitoring veya alert tarafında görünürlük var mı?
• Olay müdahale adımı gerekiyorsa planlandı mı?
• Yönetim özeti teknik jargona boğulmadan hazırlanabilir mi?

Sonraki Teknik Adım

Bu checklist tamamlandıktan sonra bulgular önem sırasına göre backlog’a taşınmalı, kritik riskler için retest planı çıkarılmalı ve ilgili servis/hub sayfasına iç bağlantı verilmelidir. Eresus Security bu aşamada kapsam netleştirme, kanıt üretme ve remediation önceliklendirme konusunda teknik ekiplerle birlikte çalışır.

Ek Kontrol Soruları

• Bu risk hangi varlıkları etkiliyor?
• Hangi kullanıcı rolleri bu akışa erişebiliyor?
• Aynı sorun başka endpoint veya entegrasyonda tekrar ediyor mu?
• Bulgunun müşteri verisine etkisi var mı?
• Loglardan olayın izi sürülebiliyor mu?
• Düzeltme sonrası retest nasıl yapılacak?
• Geçici önlem ile kalıcı çözüm ayrıldı mı?
• İş etkisi teknik ekibin dışında da anlaşılır mı?
• Benzer hata için önleyici kontrol eklenebilir mi?
• Ekip bu kontrolü release sürecine bağlayabilir mi?
• Gerekirse bağımsız doğrulama için hangi kanıtlar hazırlanmalı?
• Sonraki sprintte hangi iç bağlantı ve servis sayfası desteklemeli?