Kurumsal yapay zekâ projelerinde veri güvenliği: KVKK uyumlu RAG mimarisi

Büyük dil modelleriyle şirket içi belgeler üzerinde soru yanıtlayan asistanlar kurmak artık mümkün: sözleşme arşivinde arama yapan bir hukuk asistanı, ürün kılavuzlarından yanıt veren bir destek botu, prosedürleri anlatan bir iç bilgi asistanı. Bu projeler genellikle bir demoyla başlıyor. Demo çalışıyor, herkes heyecanlı; sonra bilgi işlem ya da hukuk birimi toplantıya katılıyor ve asıl sorular soruluyor: Veri nerede duruyor, kim erişiyor, kişisel veriler nasıl korunuyor? Bu soruları sonraya bırakan projeler, canlıya çıkmadan önce çoğu zaman geri dönüp mimariyi yeniden kurmak zorunda kalıyor.

Not: Bu yazı genel bilgilendirme amaçlıdır, hukuki görüş değildir. Projenize özel değerlendirme için hukuk danışmanınızla çalışın.

RAG nedir, neden bu kadar tercih ediliyor?

RAG (retrieval-augmented generation), dil modelini sizin verinizle yeniden eğitmek yerine, soru sorulduğu anda ilgili belge parçalarını bulup modele bağlam olarak veren bir yaklaşım. Kurumsal projelerde öne çıkmasının birkaç sebebi var:

• Belgeler güncellendiğinde modeli yeniden eğitmek gerekmiyor; dizini güncellemek yetiyor.
• Yanıtlar dayandıkları kaynak belgelere bağlanabiliyor, kullanıcı da doğruluğunu kontrol edebiliyor.
• Erişim kontrolü belgelerin getirildiği aşamada uygulanabiliyor; kullanıcı yalnızca görmeye yetkili olduğu içerikten yanıt alıyor.

Güvenlik tarafında RAG’i cazip kılan asıl özellik bu son madde. Ama kendiliğinden gelmiyor, doğru kurulması gerekiyor.

Katman katman güvenlik soruları

1. Veri alımı ve hazırlık

Belgeler kaynak sistemlerden (dosya sunucusu, doküman yönetim sistemi, e-posta arşivi vb.) alınıyor, metne çevriliyor ve parçalara bölünüyor. İlk sorulacak soru şu: asistanın amacı için hangi veri gerçekten gerekli? “Ne olur ne olmaz, hepsini koyalım” yaklaşımı, başlangıçta en sık karşılaştığımız hata. Amaca hizmet etmeyen kişisel veriler (T.C. kimlik numarası, telefon, sağlık bilgisi gibi) dizine girmeden önce maskelenmeli ya da çıkarılmalı.

2. Vektör veritabanı ve arama

Belge parçaları, anlamsal arama için sayısal temsillere (embedding) dönüştürülüp bir vektör veritabanında saklanıyor. Bu temsilleri kaynak metin kadar hassas kabul edin; çünkü çoğu kurulumda parçaların kendisi de yanlarında duruyor. Veritabanının nerede barındırıldığı, şifrelenip şifrelenmediği ve yedeklerin nerede tutulduğu baştan belli olmalı. Yedekler en kolay gözden kaçan kısım: canlı sistem Türkiye’deki bir sunucuda dururken otomatik yedeklerin başka bir bölgeye gönderilmesi pekâlâ mümkün.

3. Yetkilendirme

Sahada en sık gördüğümüz hata, bütün belgelerin tek bir dizine atılması ve herkesin aynı asistanı kullanması. Bir çalışanın kendi izin hakkını sorarken yanıtın başka birinin personel dosyasından derlenmesi, bu kurguda gayet olası. Her belge parçası, kaynak sistemdeki erişim yetkilerini taşıyan meta verilerle saklanmalı ve arama sırasında kullanıcının yetkisine göre süzülmeli. Böylece insan kaynakları dosyaları yalnızca yetkili kişilerin sorularında bağlama giriyor.

4. Dil modeli katmanı

İki temel seçenek var: açık ağırlıklı bir modeli kendi sunucularınızda ya da kontrolünüzdeki bir bulut ortamında çalıştırmak veya bir sağlayıcının API’sini kullanmak. API kullanacaksanız sağlayıcının verileri model eğitiminde kullanıp kullanmadığını, ne kadar süre sakladığını ve hangi bölgede işlediğini sözleşme düzeyinde netleştirin; web sitesindeki genel bir açıklama bu iş için yetmez. Kendi barındırdığınız model daha fazla kontrol sağlar, karşılığında donanım ve bakım maliyetini siz üstlenirsiniz.

5. Kayıt ve denetim

Kimin hangi soruyu sorduğu ve hangi belgelerin getirildiği kayıt altına alınmalı. Bu hem bir güvenlik olayını incelemek hem de yanıt kalitesini iyileştirmek için gerekli. Çoğu zaman atlanan nokta şu: bu kayıtların kendisi de kişisel veri içerebilir. Kullanıcılar asistana soru yazarken isim, telefon ya da müşteri bilgisi paylaşabiliyor. Kayıtlar için bir saklama süresi belirleyin ve erişimi kısıtlayın.

KVKK açısından dikkat edilecek başlıca noktalar

• Hukuki dayanak ve aydınlatma: Kişisel verilerin yapay zekâ asistanında işlenmesi için geçerli bir işleme şartı bulunmalı ve ilgili kişiler bu işleme hakkında aydınlatılmalı.
• Ölçülülük ve veri minimizasyonu: Amaç için gerekli olmayan veri sisteme hiç alınmamalı.
• Saklama ve imha: Kaynak belgeden silinen verinin dizinden, önbellekten ve kayıtlardan da silinmesini sağlayan bir süreç kurulmalı. Dosyayı sunucudan silmek, asistanın o dosyadan yanıt vermeyi bıraktığı anlamına gelmiyor.
• Özel nitelikli kişisel veriler: Sağlık, biyometrik veya ceza mahkûmiyeti gibi veriler ek güvenlik önlemleri gerektirir; mümkünse asistanın kapsamı dışında tutun.
• Yurt dışına aktarım: Model ya da veritabanı Türkiye dışında barındırılıyorsa bu bir yurt dışına aktarım sayılabilir. Aktarım kuralları 2024’te yapılan değişiklikle yeniden düzenlendi; bulut tabanlı bir hizmet seçmeden önce bu konuyu hukuk ekibinizle konuşun.
• Teknik ve idari tedbirler: Veri sorumlusu, verilerin hukuka aykırı işlenmesini ve erişilmesini önlemek için uygun güvenlik düzeyini sağlamakla yükümlü.

Uygulanabilir güvenlik önlemleri

1. Aktarımda ve depolamada şifreleme; anahtarların ayrı bir gizli bilgi yönetim sisteminde tutulması.
2. Rol tabanlı erişim ve tek oturum açma (SSO) entegrasyonu; işten ayrılan personelin erişiminin otomatik olarak kapanması.
3. Dizinlemeden önce kişisel verinin otomatik olarak tespit edilip maskelenmesi.
4. İstem enjeksiyonuna karşı önlemler: getirilen belge içeriğini talimat olarak değil veri olarak ele almak, modelin çağırabileceği araçları ve eylemleri sınırlamak. Bu önlem yoksa, bir PDF’in içine gizlenmiş “önceki talimatları yok say” cümlesi gerçekten işe yarayabilir.
5. Çıktı denetimi: yanıtlarda kişisel veri ya da gizli bilgi sızıntısını yakalayan filtreler.
6. Canlıya almadan önce ve düzenli aralıklarla kırmızı takım testleri.
7. Sonucu ağır olabilecek kararlarda (hukuki görüş, sağlık, finans) insan onayı.

Yanıtların doğru olduğundan nasıl emin olursunuz?

Güvenli ama yanlış yanıt veren bir asistan da kimsenin işine yaramaz. Gerçek kullanıcı sorularından bir test seti hazırlayın; her soru için beklenen kaynak belgeyi ve doğru yanıtı yazın. Sonra iki şeyi ayrı ayrı ölçün: sistem doğru belgeyi getiriyor mu, yanıt o belgeye sadık kalıyor mu? Model, dizin ya da parçalama yöntemi değiştiğinde testi yeniden çalıştırın. Kaynak gösteremeyen yanıtları da kullanıcıya açıkça belirtin; “bu konuda belge bulamadım” diyebilen bir asistan, boşluğu uydurarak dolduran bir asistandan çok daha güvenlidir.

Nereden başlamalı?

Küçük ve iyi tanımlanmış bir senaryo seçin: tek bir departman, sınırlı bir belge kümesi, ölçülebilir bir hedef. Veri envanterini ve yetki modelini baştan çıkarmak, sonradan güvenlik eklemeye çalışmaktan çok daha kolay.

İlk adım olarak şunu öneriyoruz: asistanın okuyacağı klasörlerin listesini çıkarın ve her klasörün yanına bugün ona kimlerin erişebildiğini yazın. Bu tablo hazır olduğunda yetki modelinin iskeleti de büyük ölçüde ortaya çıkmış oluyor. Tabloyla birlikte gelirseniz mimariyi kendi senaryonuz üzerinden konuşabiliriz; hukuk alanında çalışıyorsanız gizlilik yükümlülüğü yüksek bu alan için geliştirdiğimiz AdTouch Legal’ı da birlikte inceleyebiliriz.