OWASP GenAI Security Project, üretken yapay zekâ (GenAI) sistemlerinde verinin nasıl korunacağını anlatan yeni bir rehber serisi başlattı. “GenAI Data Security Best Practices” adlı rehberin 2.0 sürümünün ilk parçası Ekim 2026 tarihini taşıyor ve “Foundation, Scope & AI-DSPM” alt başlığıyla yayımlandı. Rehberin tamamı 400 sayfayı aştığı için 12 parça hâlinde yayımlanacak. Elimizdeki ilk parça 45 sayfa ve serinin geri kalanının dayanacağı temeli kuruyor.
Rehber, OWASP’ın “GenAI Data Security Risks and Mitigations 2026” adlı risk dokümanıyla birlikte okunmak üzere yazılmış. Risk dokümanı yapay zekâ sistemlerine özgü 21 veri güvenliği riskini DSGAI01’den DSGAI21’e kadar kodlarla tanımlıyor ve “ne ters gidebilir” sorusuna cevap veriyor. Yeni rehber ise “buna karşı ne yapmalıyız” sorusunu cevaplıyor. Şubat 2025’te yayımlanan ilk sürüm artık geçmişe dönük bir kaynak olarak duruyor. Rehber, onun güncel referans olarak kullanılmaması gerektiğini açıkça yazıyor.
Yazıda geçen birkaç kavram
Rehber, okurun yapay zekâ sistemlerinin nasıl çalıştığını bildiğini varsayıyor. Yazının geri kalanını takip etmeyi kolaylaştırmak için sık geçen terimleri kısaca açıklıyorum:
| Terim | Kısaca |
|---|---|
| Bağlam penceresi | Modelin bir soruya cevap verirken aynı anda gördüğü metnin tamamı: sistem talimatları, kullanıcının mesajı, çekilen belgeler ve önceki konuşma. |
| RAG | Modelin cevap vermeden önce kurumun kendi belgelerinden ilgili parçaları bulup bağlama eklemesi. Şirket içi yapay zekâ asistanlarının çoğu bu yöntemle çalışır. |
| Embedding ve vektör veritabanı | Embedding, bir metnin anlamını temsil eden sayı dizisi. RAG sistemleri belgeleri bu biçime çevirip vektör veritabanlarında saklar ve aranan konuya en yakın parçaları buradan bulur. |
| Ajan (agent) | Yalnızca metin üretmekle kalmayıp araç kullanarak iş yapan yapay zekâ sistemi. E-posta gönderebilir, veritabanı sorgulayabilir, başka ajanlara görev verebilir. |
| MCP | Model Context Protocol. Yapay zekâ sistemlerinin dış araçlara ve veri kaynaklarına bağlanmak için kullandığı protokol. |
| NHI | Non-Human Identity, yani insan olmayan kimlik. Ajanların, araçların ve servislerin sistemlere bağlanırken kullandığı hesaplar, anahtarlar ve token’lar. |
| Prompt injection | Modele verilen içeriğin arasına gizli talimat yerleştirerek modelin davranışını değiştirme saldırısı. Talimat bir e-posta ya da web sayfası gibi dış bir kaynaktan geliyorsa dolaylı (indirect) prompt injection denir. |
| Shadow AI | Kurumun haberi ya da onayı olmadan kullanılan yapay zekâ araçları. |
| DLP | Data Loss Prevention. Hassas verinin dışarı çıkmasını tespit edip engelleyen kontroller. |
Neden ayrı bir rehbere ihtiyaç duyuldu
Rehber, ilk sürümden bu yana geçen 16 ayda tehdit ortamının hızla değiştiğini söylüyor ve bu değişimi birkaç başlıkta topluyor. Ajan tabanlı sistemler yaygınlaştı ve beraberinde çok sayıda insan olmayan kimlik getirdi. RAG, üretimdeki baskın mimari hâline geldi ve vektör veritabanlarını ilk sıradaki güvenlik konularından biri yaptı. MCP ve araç entegrasyonları veri sınırını üçüncü taraf eklentilere, dış API’lere ve tarayıcı asistanlarına kadar genişletti. Görsel, ses ve video gibi girdiler de sızıntı yüzeyini metin filtrelerinin göremediği alanlara taşıdı.
Rehber bu risklerin artık teorik olmadığını gerçek olaylarla gösteriyor. 2025’te yaşanan ve dipnotlarda kaynaklarıyla verilen olaylar şunlar: Microsoft 365 Copilot’taki EchoLeak (CVE-2025-32711), Aim Security’nin Haziran 2025’te bildirdiği ve rehberin üretimdeki bir LLM sisteminde görülen ilk “sıfır tıklamalı” dolaylı prompt injection ile veri sızdırma olarak tanımladığı açık. Tenable Research’ün Eylül 2025’te bildirdiği ve Google Gemini’nin üç farklı bileşenindeki dolaylı prompt injection sorunlarını kapsayan “Gemini Trifecta”. Sourcegraph Amp ve Cline VS Code asistanında görülen, görünmez talimatlar ve markdown görselleri üzerinden veri sızdırma yöntemleri. Rehber ayrıca xAI’nin Grok modelinde güvenilirliği düşük kaynakların öne çıkarılması ve sistem talimatlarının kurcalanması olaylarını anıyor. Daha geniş örnekler olarak internete açık kalan bir DeepSeek veritabanı, Microsoft’un yapay zekâ ekibine ait 38 TB verinin açığa çıkması ve Samsung’un ChatGPT kaynaklı kaynak kodu sızıntısı da listede.
GenAI’da veri güvenliği neden farklı
Rehbere göre klasik veri güvenliği üç varsayıma dayanır. Verinin belirli bir yapısı (şeması) vardır, erişim bir kimliğe bağlıdır ve her işlem belirli bir sorguya karşılık gelir. Veritabanındaki bir satırı bir kullanıcı ya okuyabilir ya okuyamaz. GenAI sistemleri bu üç varsayımı aynı anda bozuyor. Hassas veri, yapısı ve satır düzeyinde sahibi olmayan embedding’lere, özetlere ve model ağırlıklarına dönüşüyor. Talimatlarla aynı alanda, bağlam penceresinde birleşiyor. Model, eğitim sırasında gördüğü veriyi cevaplarında aynen ya da yakın biçimde tekrar edebiliyor. Rehber bu yüzden mevcut kontrollerin hiçbirini atmıyor, şifreleme, kimlik yönetimi ve DLP gibi kontrollerin üzerine yapay zekâya özgü yeni bir katman ekliyor.
Bağlam penceresi sorunu
Rehberin üzerinde en çok durduğu konu bağlam penceresi. Sistem talimatı, kullanıcının mesajı, RAG ile çekilen belgeler, araç çıktıları ve konuşma geçmişi bu pencerede tek bir düz metin olarak birleşiyor ve aralarında hiçbir erişim kontrolü yok. Gizli bir kurum belgesinden çekilmiş bir parça, kullanıcının yazdığı metin ve bir saldırganın hazırladığı web içeriği modelin gözünde aynı güvenilirlikte duruyor. Bir içeriği “bunu düşünmek için kullan ama cevapta aynen verme” ya da “bu talimat değil, sadece veri” diye işaretlemenin yaygın bir yolu bulunmuyor.
Rehber prompt injection’ın yıllardır süren çalışmalara rağmen model katmanında çözülememesinin yapısal nedenini burada görüyor. Önerdiği kontrollerin bu sorunu çözmediğini, yalnızca etrafından dolaştığını da açıkça kabul ediyor. Bu yüzden her programın şu varsayımla kurulmasını istiyor: modele ulaşan her içerik, üretilen her cevabı etkileyebilir. Koruma da buna göre verinin sisteme girdiği, belgelerin çekildiği, araçların çağrıldığı ve cevabın üretildiği noktalara yerleştirilmeli.
Verinin yayıldığı yerler
Rehber, bir GenAI sistemindeki veriyi altı kategoriye ayırıyor:
| Kategori | Örnekler |
|---|---|
| Kaynak veri | Ham veri setleri, kullanıcı yüklemeleri, destek talebi geçmişi, bilgi tabanları, doküman arşivleri |
| Türetilmiş veri | Embedding’ler, vektör indeksleri, çekilen metin parçaları, özetler, sentetik veri setleri |
| Model dosyaları | Model ağırlıkları, kuruma özel eğitilmiş ek katmanlar (adaptörler), eğitim logları, model kayıt sistemleri |
| Çalışma anındaki veri | Prompt’lar, sistem talimatları, bağlam pencereleri, araçlara giden istekler, ajanlar arası mesajlar, oturum hafızası |
| Operasyonel kayıtlar | Uygulama logları, izleme kayıtları (trace), hata ayıklama kayıtları |
| Ajan durumu | Ajanların kısa ve uzun süreli hafızası, birbirine verdikleri görevler, önbellekte tutulan kimlik bilgileri |
Rehber bu tablodan iki önemli sonuç çıkarıyor. Birincisi, türetilen veri kaynağının hassasiyetini taşıyor ama erişim kurallarını taşımıyor. Gizli bir insan kaynakları belgesinden üretilen embedding de gizli. Ancak bu embedding’in durduğu vektör veritabanı çoğu zaman genel altyapı yetkileriyle korunuyor ve İK sisteminin satır bazlı erişim kuralları oraya taşınmıyor. İkincisi, veri yüzeyi sistem kullanılmaya başlandıktan sonra da büyümeye devam ediyor. Yeni bir MCP sunucusu eklemek ya da bir tarayıcı asistanını açmak, ilk risk analizinde hiç olmayan yeni veri türleri yaratıyor. Daha da önemlisi, bir aracın yaptığı iş, adresi aynı kalırken ve kurumda hiçbir değişiklik yapılmadan değişebiliyor. Onaylandığı günkü hâline göre yapılmış bir risk analizi, kimse fark etmeden eskiyor.
Bu durumun en somut sonucu silme işleminde görülüyor. Rehbere göre bir kişinin verisini kaynak veritabanından silip embedding’ini vektör veritabanında, izini log kayıtlarında ve etkisini eğitilmiş modelde bırakan bir silme işlemi, mevzuata uygun bir silme sayılmaz.
Bildiğimiz kontroller nasıl genişliyor
Rehber, klasik güvenlik kontrollerinin GenAI’da nasıl genişlemesi gerektiğini bir tabloyla gösteriyor. Öne çıkan satırlar şunlar:
| Klasik kontrol | GenAI’daki karşılığı |
|---|---|
| Şifreleme | Embedding’ler, ajan hafızası ve araçlara giden istekler de şifrelenir. Anahtar yenileme vektör veritabanlarını ve model kayıt sistemlerini de kapsar. |
| Kimlik ve erişim yönetimi | Ajanlar, MCP sunucuları ve araçlar da kimlik yönetimine dahil edilir. Kimlik bilgileri yalnızca ihtiyaç anında verilir, kalıcı yetki bırakılmaz. Belge bazında erişim kontrolü, belge saklanırken değil RAG ile çekilirken de uygulanır. |
| DLP | Kontrol prompt’un alındığı, belgenin çekildiği ve cevabın üretildiği noktalarda yapılır. Görsellerden okunan metin ve ses kayıtlarının dökümü de taranır. |
| Loglama | Varsayılan olarak mümkün olan en az şey loglanır. Hassas içerik izleme sistemlerine ulaşmadan maskelenir. Hata ayıklama kayıtları kısa süre saklanır. |
| Ağ ayrımı | Araçlar izole ortamlarda çalıştırılır. Ajanların dış ağa çıkışı kısıtlanır. Her MCP bağlantısı ayrı bir güven bölgesi sayılır. |
| Olay müdahalesi | Müdahale planları cevaplarda veri sızıntısı, RAG zehirleme, ajan kimliğinin kötüye kullanımı ve vektör veritabanının ele geçirilmesi gibi senaryoları da kapsar. |
Altı temel ilke
Rehberin 2. bölümü, serinin bütün parçalarında tekrar edecek altı ilke koyuyor. Rehber bu ilkelerin tek başına yeni olmadığını, yeni olanın GenAI’a uygulanışı olduğunu belirtiyor.
| İlke | Ne anlama geliyor |
|---|---|
| Veri minimizasyonu | Modele yalnızca o görev için gereken ve kullanıcının görme yetkisi olan veri verilir. Rehber “her şeyi bağlama koy, model ayıklasın” yaklaşımını açıkça reddediyor. |
| İzolasyon ve en az yetki | Her kullanıcı, oturum ve ajan için ayrı sınırlar çizilir. Ajanlara ve araçlara insan hesaplarına uygulanan özen gösterilir. Geri alınamayan ya da etkisi büyük işlemlerden önce insan onayı istenir. |
| Yaşam döngüsü disiplini | Saklama ve silme kuralları verinin türetilen bütün biçimlerine uygulanır. |
| Bütünlük ve köken takibi | Verinin sisteme girdiği ve dönüştürüldüğü her noktada kurcalama aranır. Model ve veri dosyaları imzalanır, veri setlerinin içerik listesi tutulur. |
| Sürekli izleme | Sistem büyüdükçe sabit kontroller eskir. Veri sürekli keşfedilir, sınıflandırılır ve izlenir. Rehber bunu AI-DSPM programı olarak tanımlıyor. |
| Modele sıfır güven | Modelin hata yapabileceği, yönlendirilebileceği ve kısmen ele geçirilmiş olabileceği varsayılır. Sistem talimatına yazılan bir kural kendiliğinden uygulanmış sayılmaz. Asıl korumayı cevap filtreleme, format kontrolü, araçların izole çalıştırılması ve insan onayı sağlar. |
Rehber yeni bir sistem kuran ekiplere bütün bölümleri aynı anda uygulamaya çalışmamalarını öneriyor. Önerilen sıra şöyle: önce sistemdeki verinin envanteri çıkarılır, sonra o sistem için en önemli DSGAI riskleri belirlenir, ilgili bölümlerdeki temel kontroller kurulur ve sistem büyüdükçe ileri seviyelere geçilir.
21 risk
Rehber, risk dokümanındaki 21 riski kolay başvuru için kendi içinde de listeliyor. Serinin her bölümü bu kodlara bağlanıyor:
| Kod | Risk (orijinal adı) | Türkçesi |
|---|---|---|
| DSGAI01 | Sensitive Data Leakage | Hassas veri sızıntısı |
| DSGAI02 | Agent Identity & Credential Exposure | Ajan kimliklerinin ve kimlik bilgilerinin açığa çıkması |
| DSGAI03 | Shadow AI & Unsanctioned Data Flows | Shadow AI ve onaysız veri akışları |
| DSGAI04 | Data, Model & Artifact Poisoning | Veri, model ve dosya zehirleme |
| DSGAI05 | Data Integrity & Validation Failures | Veri bütünlüğü ve doğrulama hataları |
| DSGAI06 | Tool, Plugin & Agent Data Exchange Risks | Araç, eklenti ve ajanlar arası veri alışverişi riskleri |
| DSGAI07 | Data Governance, Lifecycle & Classification for AI Systems | Veri yönetişimi, yaşam döngüsü ve sınıflandırma |
| DSGAI08 | Non-Compliance & Regulatory Violations | Mevzuata uyumsuzluk |
| DSGAI09 | Multimodal Capture & Cross-Channel Data Leakage | Görsel, ses gibi kanallar üzerinden veri sızıntısı |
| DSGAI10 | Synthetic Data, Anonymization & Transformation Pitfalls | Sentetik veri, anonimleştirme ve dönüştürme hataları |
| DSGAI11 | Cross-Context & Multi-User Conversation Bleed | Konuşmaların oturumlar ve kullanıcılar arasında sızması |
| DSGAI12 | Unsafe Natural-Language Data Gateways (LLM-to-SQL/Graph) | Doğal dili veritabanı sorgusuna çeviren güvensiz geçitler |
| DSGAI13 | Vector Store Platform Data Security | Vektör veritabanı güvenliği |
| DSGAI14 | Excessive Telemetry & Monitoring Leakage | Aşırı loglama ve izleme kaynaklı sızıntı |
| DSGAI15 | Over-Broad Context Windows & Prompt Over-Sharing | Bağlama gereğinden fazla veri konması |
| DSGAI16 | Endpoint & Browser Assistant Overreach | Bilgisayar ve tarayıcı asistanlarının yetki aşımı |
| DSGAI17 | Data Availability & Resilience Failures in AI Pipelines | Erişilebilirlik ve dayanıklılık sorunları |
| DSGAI18 | Inference & Data Reconstruction | Modelden verinin tahmin edilmesi ve yeniden oluşturulması |
| DSGAI19 | Human-in-the-Loop & Labeler Overexposure | Etiketleme ve insan onayı aşamasında verinin fazla açılması |
| DSGAI20 | Model Exfiltration & IP Replication | Modelin çalınması ve kopyalanması |
| DSGAI21 | Disinformation & Integrity Attacks via Data Poisoning | Veri zehirleme yoluyla dezenformasyon |
Üç olgunluk seviyesi
Rehberdeki kontroller üç seviyeye ayrılıyor: Tier 1 (temel), Tier 2 (sertleştirme) ve Tier 3 (ileri). Bu seviyeler riskin ne kadar ciddi olduğunu göstermiyor, kurumun ne kadar olgun olduğunu gösteriyor. Rehbere göre Tier 1, Tier 3’ün zayıf bir hâli olarak görülmemeli. Tier 1, canlıdaki bir GenAI sisteminin altına inmemesi gereken asgari seviye. Yapay zekâ güvenliğine yeni başlayan kurumların önce ilgili tüm alanlarda Tier 1’i kurması, sonra ilerlemesi bekleniyor. Kontroller ayrıca kurumun kendisinin mi geliştireceğine (Build), bir üründen mi alacağına (Buy) yoksa ikisini birlikte mi kullanacağına (Buy and Build) göre etiketleniyor.
AI-DSPM: verinin sürekli takibi
Part 1’in en uzun bölümü AI-DSPM’e (AI Data Security Posture Management) ayrılmış. AI-DSPM’i yapay zekâ sistemlerindeki verinin sürekli envanterini tutan, onu sınıflandıran ve güvenlik durumunu izleyen bir program olarak düşünebiliriz. Rehbere göre bu program, sonraki parçalardaki bütün kontrollere neyin nerede olduğunu söyleyen temel.
Rehber programı iki farklı soruya ayırıyor. İlki, bir ajanın ya da yapay zekâ sisteminin ne yapmak üzere yapılandırıldığı. İnternete açık bir MCP sunucusu, gereğinden fazla yetkisi olan bir ajan kimliği ya da herkese açık bırakılmış bir eğitim veri seti bu gruba giriyor. Bunlar sistem çalışmaya başlamadan önce de görülebilen ve düzeltilebilen sorunlar. İkinci soru, sistemin şu anda ne yaptığı. Bir ajanın kullanıcının izin verdiği işin dışına çıkması ya da vektör veritabanına alışılmadık sorgular gelmesi bu gruba giriyor. Rehber bunları doğrudan bir güvenlik olayı olarak sınıflandırıyor. Rehber bu iki alanın farklı ekipler, farklı araçlar ve farklı ölçütlerle yönetilmesini istiyor. İkisini tek bir iş gibi görmeyi programların en sık başarısız olma nedenlerinden biri olarak sayıyor.
Program 13 yetenekten oluşuyor ve bunlar üç katmanda toplanıyor:
| Katman | Yetenekler |
|---|---|
| Temel | Varlık envanteri, sınıflandırma, veri soy ağacı (verinin nereden gelip nereye gittiğinin kaydı), erişim yönetimi |
| Tespit ve uygulama | Prompt, RAG ve cevaplarda DLP; vektör veritabanı güvenliği; bütünlük ve zehirleme tespiti; log ve izleme sistemlerinin güvenliği; bağlantı (connector) yönetimi |
| Yönetişim ve yaşam döngüsü | Saklama ve silme, model eğitiminin yönetimi, dayanıklılık, Shadow AI kontrolleri |
Rehbere göre AI-DSPM programları en çok, yetenekler birbirinden kopuk kurulduğunda ve aralarında bilgi akmadığında başarısız oluyor. Bu yüzden aralarındaki bağların açıkça kurulmasını istiyor. Envanterde olmayan varlık sınıflandırılamaz, sınıflandırılmamış veri için DLP çalışamaz. Veri soy ağacı olmadan silme işleminin türetilen veriye ulaştığı kanıtlanamaz. Zehirleme tespiti bir olay müdahale sürecini başlatmıyorsa, gelen uyarılar fiilen kimse tarafından incelenmemiş olur. Shadow AI ise rehberin tarifiyle bağlantı envanterinde olması gerekip de olmayan her şey.
Kim sorumlu
Rehber, programların çoğunun güvenlik ekibi ile yapay zekâ platform ekibi arasındaki boşlukta başarısız olduğunu belirtiyor. Bir tarafta yapay zekâyı yeterince tanımayan güvenlik ekipleri, diğer tarafta güvenlik yetkisi olmayan platform ekipleri var. Bunun için her yetenek alanı için kimin sorumlu olduğunu gösteren bir tablo veriyor. Çoğu alanda nihai sorumlu CISO. Silme işlemlerinde bu rol veri koruma sorumlusuna, vektör veritabanları ve eğitim gizliliğinde yapay zekâ platform liderine geçiyor. Tepede, üst düzey bir yöneticinin başkanlık ettiği bir Yapay Zekâ Yönetişim Komitesi var. Komite aktif programlarda ayda bir, oturmuş programlarda üç ayda bir toplanıyor. Rehber bu yapıyı ISO/IEC 42001 standardının liderlik ve planlama maddeleriyle ilişkilendiriyor.
Rehber ürün seçimi için de bir çerçeve sunuyor ve kategori bazında örnek ürünler veriyor. Ürün adlarının yalnızca örnek olduğunu, OWASP’ın hiçbirini önermediğini özellikle vurguluyor. Pazarın 2025-2026’da hızla birleştiğini de not ediyor: Palo Alto Networks, Temmuz 2025’te Protect AI’ı satın almayı tamamladı ve CyberArk satın alımını 11 Şubat 2026’da kapattı. Veeam 2025 sonunda Securiti ile birleşme duyurdu, Cisco da Robust Intelligence’ı satın aldı.
365 günlük yol haritası
Rehber 13 yeteneğin aynı anda kurulmamasını istiyor ve üç aşamalı bir plan öneriyor:
| Aşama | Hedef | Başlıca adımlar |
|---|---|---|
| 0-90 gün: Temel | Gerçek durumu ortaya çıkarmak | Yönetişim komitesi kurulur. Bulut hesaplarındaki, vektör veritabanlarındaki ve izleme sistemlerindeki yapay zekâ varlıklarının envanteri çıkarılır. Shadow AI politikası yayımlanır. Onaysız yapay zekâ sitelerine giden veri için DLP devreye alınır. Ajanların ve araçların kimlikleri listelenir, kalıcı kimlik bilgileri yenilenir. |
| 90-180 gün: Sertleştirme | Tespiti güvenilir hâle getirmek ve etiketleri yaymak | Sınıflandırma etiketleri türetilen veriye de aktarılır. Veri soy ağacı kaydı başlar. RAG’de belge bazında erişim kontrolü kurulur. Loglardaki hassas veri maskelenir. Her MCP ve araç bağlantısı risk puanıyla kayda alınır. Silme talepleri türetilen veriyi de kapsar. |
| 180-365 gün: Olgunluk | Ölçülebilir ve dayanıklı olmak | Zehirleme tespiti olay müdahalesine bağlanır. Model eğitimine gizlilik kontrolleri eklenir. Vektör veritabanlarının yedekleri geri yükleme testleriyle doğrulanır. Performans göstergeleri için bir pano kurulur ve bir GenAI olayı üzerine masa başı tatbikat yapılır. |
Halihazırda yaygın GenAI kullanımı olan kurumlar için bu sürecin 12 yerine 12-18 ay sürmesi bekleniyor. Rehber bu kurumlara her şeyden önce varlık ve Shadow AI keşfine başlamalarını öneriyor, çünkü envanterdeki eksik neredeyse her zaman ilk tahminden büyük çıkıyor.
İlerleme nasıl ölçülür
Rehber 16 performans göstergesi (KPI) ve her biri için bir hedef veriyor. Birkaç örnek:
| Gösterge | Hedef |
|---|---|
| Otomatik olarak keşfedilen yapay zekâ varlıklarının oranı | 12 ay içinde %90’ın üzeri |
| Ajan ve araç kimlik bilgilerinin yenilenme süresi | 24 saat ve altı |
| DLP’nin hatalı alarm oranı | %5’in altı |
| Kiracı (tenant) ayrımı ve şifrelemesi olan vektör veritabanları | 6 ay içinde %100 |
| Hassas verisi maskelenen izleme kayıtları | 6 ay içinde %100 |
| Türetilen veriler dahil silme talebinin karşılanma süresi | 30 gün ve altı (GDPR üst sınırı) |
| Shadow AI bulgusunun giderilme süresi | 14 günün altı |
| Dış ağa çıkışı varsayılan olarak kapalı ajanlar | 6 ay içinde %100 |
Rehber bu değerlerin her kurum için ölçülmüş gerçek rakamlar olmadığını, uygulamacı deneyimine dayanan planlama örnekleri olduğunu belirtiyor. Mutlak değerden çok gidişatın önemli olduğunu da bir örnekle anlatıyor: tespit sayısı aynı kalırken düşen bir hatalı alarm oranı, hassasiyeti kısarak elde edilmiş düşük bir orandan daha sağlıklı bir işaret.
Mevcut güvenlik operasyonlarına bağlanmak
Rehbere göre AI-DSPM ayrı bir güvenlik operasyonu olarak yürütülmemeli. Üretilen kayıtlar kurumun mevcut SIEM sistemine standart formatlarda gitmeli. Böylece farklı sinyaller birleştirilebilir. Rehberin verdiği örnekte, vektör veritabanında ani bir tarama artışı ile aynı veritabanına bağlı ajan kimliğindeki bir anormallik birlikte görüldüğünde, ikisinin tek tek görünmesinden çok daha güvenilir bir alarm oluşuyor. Olay müdahale planları yeniden yazılmamalı, genişletilmeli. Her risk sınıfı için hangi sinyalin bakılacağı, hangi sorguyla kapsamın belirleneceği ve ajan kimliklerini iptal etmek, vektör indekslerini karantinaya almak ya da modeli sağlam bir önceki sürüme döndürmek gibi hangi adımların atılacağı tanımlanmalı. Uyum tarafında da AI-DSPM, ISO 27001, SOC 2 ve ISO 42001 denetimlerinin yürütüldüğü aynı yapıya bir kontrol ailesi olarak eklenmeli.
Sık yapılan beş hata
Rehber, kurumların AI-DSPM kurarken düştüğü beş hatayı sıralıyor. İlki, yönetişim kurmadan araç satın almak. Araç kimsenin sahiplenmediği bulgular üretiyor, alarm yorgunluğu başlıyor ve program dokuz ay içinde sessizce ölüyor. İkincisi bunun tersi: politika ve komite var ama veri yok, kararlar gerçek duruma göre değil anekdotlara göre veriliyor. Üçüncüsü 13 yeteneği aynı anda kurmaya çalışmak. Kaynaklar dağılıyor ve hiçbir yetenek olgunlaşmıyor. Dördüncüsü güvenlik ve platform ekiplerinin işi birbirinin üstünde sanması. Beşincisi programı bitiş tarihi olan bir proje gibi kurmak. Rehbere göre sürekli güncellenmeyen programlar devreye alındıktan sonraki 18 ay içinde işe yaramaz hâle geliyor.
Serinin geri kalanı
Part 1 çerçeveyi çiziyor, kontrollerin ayrıntısı sonraki parçalarda gelecek. Rehber serinin verinin sistemdeki yolunu takip ettiğini ve her parçanın bir öncekinin üzerine kurulduğunu söylüyor:
| Parça | Konu |
|---|---|
| 1 | Temel, kapsam ve AI-DSPM |
| 2 | Veri yönetişimi ve yaşam döngüsü: sınıflandırma, saklama, silme, veri soy ağacı |
| 3 | Model eğitimi, RAG, hafıza ve vektör veritabanları |
| 4 | Ajanlar, araçlar, eklentiler ve MCP |
| 5 | Prompt, bağlam ve cevap güvenliği |
| 6 | Yapay zekâ kimlikleri ve Shadow AI yönetimi |
| 7 | Log ve izleme güvenliği, görsel ve ses kanallarından sızıntı |
| 8 | Doğal dil veritabanı geçitleri ve yapay zekâ tedarik zinciri |
| 9 | Dağıtım modelleri ve gizliliği artıran teknolojiler |
| 10 | Modele yönelik saldırılara savunma, olay müdahalesi ve dayanıklılık |
| 11 | Mevzuat uyumu, yönetişim ve insan denetimi |
| 12 | Kuantum sonrası kriptografiye hazırlık ve kapanış materyalleri |
Rehber okuma önerisi de veriyor. CISO’lar ve risk yöneticileri için ağırlık merkezi 1, 6, 11 ve 12. parçalar. Güvenlik mimarları ve mühendisleri için 2-5 ve 7-10. parçalar, geliştiriciler ve yapay zekâ mühendisleri için 3-5 ve 8-9. parçalar.
Değerlendirme
Part 1’in güçlü yanı, yapay zekâ veri güvenliği gibi geniş bir konuyu ölçülebilir bir programa çevirmesi. Yol haritasındaki adımlar risk kodlarına, yetenekler sorumlulara, hedefler göstergelere bağlanıyor. Klasik kontrollerin GenAI’da nasıl genişlediğini gösteren tablo, bu alana yeni giren biri için iyi bir başlangıç noktası. ISO/IEC 42001, NIST AI RMF ve MITRE ATLAS gibi çerçevelere yapılan atıflar da mevcut bir yönetim sistemine uyarlamayı kolaylaştırıyor.
Okurken dikkat edilmesi gereken birkaç nokta da var. Elimizde serinin yalnızca ilk parçası var. Kontrollerin ayrıntısı, mimari örnekler ve uygulama adımları sonraki parçalarda gelecek. Yol haritası, rehberin kendi ifadesiyle zaten DSPM ve kimlik yönetimi altyapısı olan tipik bir büyük kurumu varsayıyor, küçük ekiplerin bunu kendi ölçeğine uyarlaması gerekecek. Dokümanın içinde bazı tutarsızlıklar da göze çarpıyor. EU AI Act’in yüksek riskli sistem yükümlülükleri için metin 2 Aralık 2027 tarihini veriyor, bir dipnotta ise 2 Aralık 2026 geçiyor. “On soruluk satıcı değerlendirmesi” başlığı altında 16 soru sıralanıyor. Rehber de denetimlerde ya da sözleşmelerde atıf yapmadan önce genai.owasp.org’daki güncel sürümün kontrol edilmesini öneriyor. Son olarak, rehberin andığı mevzuat arasında GDPR, CCPA, HIPAA ve LGPD gibi düzenlemeler var ama KVKK yok. Türkiye’deki kurumlar bu eşlemeyi kendileri yapmak zorunda kalacak.
Rehberin yazarları Emmanuel Guilherme Junior (OWASP GenAI Data Security Initiative lideri), Scott Clinton ve Kyriakos “Rock” Lambros. Dokümana 15 katkıcı ve 26 gözden geçirici emek vermiş. Rehber CC BY-SA 4.0 lisansıyla yayımlanıyor, yani kaynak gösterildiği sürece serbestçe paylaşılabiliyor ve uyarlanabiliyor.
Kaynak
OWASP GenAI Security Project, GenAI Data Security Best Practices, Version 2.0, Part 1, Ekim 2026.