İçeriğe geç

KVKK Uyumlu Kurumsal Yapay Zeka: RAG ve Ajan Sistemlerinde Veri Sınırı

KVKK uyumlu yapay zeka için kişisel verinin RAG ve ajan sistemlerinde hangi duraklardan geçtiği, yurt dışına aktarım, maskeleme, arama anında erişim kontrolü, loglama ve kontrol listesi.

Yayınlanma:

KVKK uyumlu bir yapay zeka sistemi kurmanın özü, kişisel verinin nereye gittiğini, kimin görebildiğini ve ne kadar saklandığını mimari düzeyde önceden belirlemektir. RAG ve ajan sistemlerinde bu üç sorunun cevabı tek bir yerde değil, verinin geçtiği her durakta verilir: belgenin parçalanıp vektöre çevrildiği an, arama sonucunun modele gönderildiği an, modelin cevabının kaydedildiği an ve ajanın bir sistemde işlem yaptığı an. Bu durakların her birinde veri sınırı yazılı olarak çizilmemişse, en iyi niyetli proje bile denetimde açıklanması zor bir veri akışıyla karşınıza çıkar.

Bu yazı, kurum içinde RAG tabanlı bir asistan veya sistemlerde işlem yapan bir yapay zeka ajanı planlayan teknik liderler, ürün sahipleri ve uyum ekipleri için hazırlandı. Hukuki görüş değildir; mühendislik tarafında hangi kararların verilmesi gerektiğini ve bu kararların hangi KVKK kavramlarına dokunduğunu anlatır. Kendi durumunuza özgü yükümlülükleri mutlaka hukuk danışmanınızla doğrulayın.

KVKK yapay zeka projelerinde neden ayrı bir tasarım konusu?

Klasik bir web uygulamasında kişisel veri genellikle bilinen tablolarda, bilinen alanlarda durur. Yapay zeka sistemlerinde ise veri biçim değiştirir ve çoğalır. Bir PDF parçalara bölünür, her parça bir vektöre dönüşür, arama sonucunda seçilen parçalar bir istemin içine yerleştirilir, istem bir model sağlayıcısına gider, cevap ve çoğu zaman istemin kendisi kayıt altına alınır. Aynı kişisel veri, birkaç saniye içinde dört farklı yerde ve dört farklı biçimde bulunabilir.

Bu yüzden KVKK açısından sorulan temel sorular değişmese de cevapları bulmak zorlaşır:

  • Hangi kişisel veriler işleniyor? Belgelerin içinde müşteri adları, TC kimlik numaraları, sağlık bilgisi veya çalışan değerlendirmeleri olabilir. Çoğu kurum bunu belgeleri yüklerken değil, ilk yanlış cevapta fark eder.
  • Veri nereye aktarılıyor? Model sağlayıcısının sunucuları yurt dışındaysa, istemin içindeki kişisel veri yurt dışına aktarılmış olur.
  • Kim erişebiliyor? Belge yönetim sisteminde yetkisi olmayan bir çalışan, asistan üzerinden aynı belgenin içeriğine ulaşabiliyorsa erişim kontrolü delinmiş demektir.
  • Ne kadar saklanıyor? Vektör veritabanı, istem kayıtları ve sağlayıcının kendi kayıtları ayrı saklama sürelerine sahiptir ve çoğu zaman kimse bunları birlikte düşünmez.

RAG sisteminde veri hangi duraklardan geçer?

Kurumsal RAG güvenliği, verinin yolculuğunu durak durak çizmekle başlar. Tipik bir RAG akışında beş durak vardır ve her birinin kendine ait bir riski bulunur.

  1. Kaynak sistem: Belgelerin bulunduğu yer (dosya sunucusu, belge yönetim sistemi, CRM, e-posta arşivi). Risk: kapsam dışı belgelerin toplu olarak içeri alınması.
  2. Hazırlama ve parçalama: Belgelerin metne çevrilip parçalara bölündüğü adım. Risk: kişisel verinin maskelenmeden işlenmesi.
  3. Gömme (embedding) ve vektör veritabanı: Parçaların vektöre çevrilip saklandığı yer. Risk: gömme modelinin harici bir API olması ve parçaların yetki bilgisi olmadan saklanması.
  4. Arama ve istem oluşturma: Kullanıcının sorusuna göre parçaların seçilip modele gönderildiği an. Risk: kullanıcının yetkisi olmayan parçaların cevaba karışması.
  5. Model ve kayıt: Cevabın üretildiği ve istem ile cevabın loglandığı yer. Risk: kayıtların süresiz saklanması ve sağlayıcının veriyi kendi amaçları için kullanması.

Bu listeyi bir veri akış şeması olarak çizip her durağın yanına "hangi kişisel veri, hangi ülkede, kim erişebilir, ne kadar süre" bilgisini yazmak, projenin hem teknik hem uyum tarafı için en değerli tek belgedir.

Model sağlayıcısına giden veri yurt dışına aktarım sayılır mı?

Kişisel veri içeren bir istem, sunucuları Türkiye dışında olan bir model sağlayıcısına gönderiliyorsa, bu genellikle yurt dışına kişisel veri aktarımı olarak değerlendirilir. KVKK'nın 9. maddesi 2024'te yapılan değişiklikle yeniden düzenlendi. Yeni düzende aktarım için önce yeterlilik kararı aranıyor; yeterlilik kararı yoksa standart sözleşme, bağlayıcı şirket kuralları veya Kurul izniyle taahhütname gibi uygun güvencelerden biri gerekiyor. Standart sözleşme yolunda sözleşmenin imzalandıktan sonra belirli bir süre içinde Kişisel Verileri Koruma Kurumu'na bildirilmesi de yükümlülükler arasında.

Mühendislik tarafında bu, şu soruları proje başında cevaplamak anlamına gelir:

  • Model sağlayıcısının veri işleme sözleşmesi (DPA) ne diyor? Gönderilen veri model eğitiminde kullanılıyor mu, kullanılmıyorsa bu yazılı olarak taahhüt ediliyor mu?
  • Sağlayıcı veriyi hangi bölgede işliyor ve saklıyor? Bölge seçimi yapılabiliyor mu?
  • Sağlayıcı kötüye kullanım denetimi için istemleri ne kadar süre saklıyor? Bu süre sıfırlanabiliyor mu?
  • Aktarım için hangi güvence kullanılacak ve bu güvencenin gerektirdiği bildirim veya izin süreçlerini kim yürütecek?

Bu soruların hukuki cevabı sizin veri sorumlusu olarak yapacağınız değerlendirmeye bağlıdır. Teknik ekibin görevi ise bu değerlendirmeyi mümkün kılacak bilgiyi eksiksiz çıkarmak ve mimariyi, verilen karara göre değiştirilebilir kurmaktır. Hukuk danışmanınızla doğrulamadan, "sağlayıcı büyük, sorun olmaz" varsayımıyla yola çıkmayın.

Kişisel veriyi gömmeden önce nasıl ayıklarsınız?

En güvenli kişisel veri, sisteme hiç girmeyen kişisel veridir. Bir RAG asistanının cevap verebilmesi için çoğu zaman müşterinin adına veya kimlik numarasına ihtiyaç yoktur; prosedürün, sözleşme maddesinin veya teknik açıklamanın kendisi yeterlidir. Bu yüzden hazırlama adımında üç teknik birlikte kullanılır:

  • Kapsam filtresi: Hangi klasörlerin, hangi belge türlerinin ve hangi tarih aralığının sisteme gireceği yazılı olarak belirlenir. "Tüm paylaşılan sürücüyü yükleyelim" yaklaşımı, en sık görülen veri sınırı hatasıdır.
  • Anonimleştirme: Cevap için gerekmeyen kişisel veri, gömmeden önce metinden çıkarılır. Geri döndürülemez şekilde yapılan anonimleştirme, verinin kişisel veri olma niteliğini ortadan kaldırabilir; ancak bunun gerçekten geri döndürülemez olduğundan emin olmak gerekir.
  • Takma adlandırma (pseudonymization): Kişiye bağlantı gerekli ama modele gönderilmesi gerekmiyorsa, ad ve kimlik numarası gibi alanlar bir anahtarla değiştirilir. Eşleştirme tablosu ayrı ve erişimi kısıtlı bir yerde tutulur. Takma adlı veri hâlâ kişisel veridir, ama modele ve sağlayıcıya giden içerik daralır.

Maskeleme kurallarını sadece düzenli ifadelerle kurmak yetersiz kalır; adlar, adresler ve serbest metin içindeki sağlık bilgileri kalıba uymaz. Pratikte kural tabanlı tespit ile bir varlık tanıma modeli birlikte kullanılır ve sonuç örnek belgeler üzerinde ölçülür. Kaç kişisel verinin kaçırıldığını gösteren bir test seti olmadan "maskeleme yapıyoruz" demek bir güvence değildir.

Erişim kontrolü arama anında nasıl uygulanır?

Kurumsal RAG güvenliğindeki en sinsi açık, asistanın herkese aynı belgeleri göstermesidir. İnsan kaynakları klasörüne erişimi olmayan bir çalışan, "maaş skalası nedir" diye sorduğunda cevabı asistandan alabiliyorsa, sistem belge yönetimindeki yetki modelini fiilen devre dışı bırakmış olur.

Doğru yaklaşım, yetkiyi cevap üretildikten sonra değil, arama sırasında uygulamaktır:

  • Her parça, kaynak belgenin erişim listesini (kullanıcı, grup veya rol) meta veri olarak taşır.
  • Arama sorgusu, soran kullanıcının kimliği ve grupları ile filtrelenir; yetkisi olmadığı parçalar aday listesine hiç girmez.
  • Kaynak sistemde yetki değiştiğinde vektör veritabanındaki meta veri de güncellenir. Bu senkronizasyonun gecikmesi ölçülür ve yazılı bir hedefe bağlanır.
  • Cevapla birlikte kaynak belge gösterilir; kullanıcı kaynak belgeyi açamıyorsa cevapta da o belgeye dayanan bilgi olmamalıdır.

Modele "kullanıcının yetkisi olmayan bilgiyi paylaşma" diye talimat vermek bir erişim kontrolü değildir. Model o parçayı gördüyse, bir şekilde cevaba sızdırabilir. Yetki, modelin önüne gelen veriyi belirleyen katmanda uygulanmalıdır.

Ajan sistemlerinde veri sınırı nasıl çizilir?

RAG sistemi okur; ajan ise iş yapar. Bir ajan CRM'de kayıt güncelleyebiliyor, e-posta gönderebiliyor veya veritabanını sorgulayabiliyorsa, KVKK açısından risk okumanın ötesine geçer: yanlış kişiye veri gönderme, yetkisiz değişiklik ve kayıt dışı işlem. Bu konuyu yapay zeka ajanlarını üretime almak üzerine yazımızda ayrıntılı ele aldık; veri sınırı açısından öne çıkan kurallar şunlar:

  • En az yetki: Ajan, işini yapmak için gereken en dar yetkiyle çalışır. Okuma yeterliyse yazma yetkisi verilmez, tek tablo yeterliyse tüm veritabanı açılmaz.
  • Kullanıcı adına yetki: Ajan, kendi geniş servis hesabıyla değil, işlemi başlatan kullanıcının yetkileriyle çalışır. Böylece ajan, kullanıcının zaten yapamayacağı bir şeyi yapamaz.
  • İnsan onayı kapıları: Dışarıya veri gönderen, kayıt silen veya toplu değişiklik yapan işlemler, bir insan onaylamadan çalışmaz.
  • Araç düzeyinde sınır: Ajanın kullandığı her araç ne yapabildiğini ve hangi alanları döndürdüğünü tanımlar. MCP gibi protokollerde asıl değer, bu tanımların ve üzerine oturan yetkilendirme katmanının merkezi olarak yönetilebilmesidir.

Loglama ve saklama süresi nasıl belirlenir?

Yapay zeka sistemlerinde loglama iki zıt ihtiyaç arasında kalır. Bir yandan hangi kullanıcının ne sorduğunu, hangi belgelerin kullanıldığını ve ajanın hangi işlemi yaptığını kaydetmek hem hata ayıklama hem hesap verebilirlik için gereklidir. Öte yandan istemlerin tam metni, içindeki kişisel verilerle birlikte süresiz saklanırsa, log deposu kurumun en hassas veri kümesine dönüşür.

Dengeli bir yaklaşım şöyle kurulur:

  • Denetim izi (kim, ne zaman, hangi belge, hangi işlem) ile içerik kaydı (istemin ve cevabın tam metni) ayrı tutulur.
  • İçerik kayıtlarında kişisel veri maskelenir ve saklama süresi kısa tutulur; süre dolduğunda kayıt otomatik silinir.
  • Saklama süreleri vektör veritabanı, uygulama logları, izleme araçları ve model sağlayıcısının kendi kayıtları için ayrı ayrı yazılır. Kurumun kişisel veri saklama ve imha politikasıyla uyumlu olup olmadığı kontrol edilir.
  • İlgili kişi başvurusunda (verinin silinmesi talebi gibi) bir kişiye ait verinin vektör veritabanından ve loglardan nasıl bulunup silineceği önceden tasarlanır. Bu, sonradan eklenmesi en zor özelliklerden biridir.

Açık ağırlıklı modelleri kendi sunucunuzda çalıştırmak ne zaman mantıklı?

Veri sınırını en net çizmenin yolu, verinin kurumun kontrolündeki altyapıdan hiç çıkmamasıdır. Son dönemde yayımlanan açık ağırlıklı modeller, birçok kurumsal iş için yeterli kaliteye ulaştı ve kendi sunucunuzda veya kontrolünüzdeki bir bulut ortamında çalıştırılabiliyor. Bu seçenek özellikle şu durumlarda değerlendirilmeye değer:

  • Belgeler sağlık verisi gibi özel nitelikli kişisel veri içeriyorsa.
  • Sektör düzenlemesi veya müşteri sözleşmeleri verinin belirli bir ülkede kalmasını gerektiriyorsa.
  • Kullanım hacmi yüksek ve öngörülebilir olduğu için kendi altyapınızın maliyeti API maliyetinin altına iniyorsa.

Bedeli de açık: modeli işletmek, güncellemek, izlemek ve güvenliğini sağlamak artık sizin işiniz olur ve en güçlü kapalı modellerin bazı yeteneklerinden vazgeçebilirsiniz. Pratikte sık görülen orta yol, hassas veriyi işleyen adımları (gömme, sınıflandırma, maskeleme) kendi altyapınızda çalıştırmak, maskelenmiş içerikle yapılan üretimi ise harici bir modele bırakmaktır. Mimarinin modelden bağımsız kurulması, bu kararı sonradan değiştirebilmenin ön şartıdır.

Proje başlamadan risk değerlendirmesi nasıl yapılır?

Yüksek riskli veri işleme faaliyetlerinde, işe başlamadan önce yazılı bir etki değerlendirmesi yapmak iyi bir uygulamadır. GDPR'daki veri koruma etki değerlendirmesine (DPIA) benzer bir yaklaşım, KVKK kapsamında da riskleri görünür kılmak için kullanılabilir. Bir yapay zeka projesi için bu değerlendirme en az şu başlıkları içermelidir:

  • İşleme amacı ve bu amaç için gerçekten gereken veri kategorileri.
  • Veri akış şeması ve her duraktaki ülke, sağlayıcı ve saklama süresi.
  • Hukuki dayanak ve gerekiyorsa aydınlatma metninin güncellenmesi.
  • Yurt dışına aktarım varsa kullanılan güvence.
  • Erişim kontrolü modeli ve arama anında nasıl uygulandığı.
  • Ajan yetkileri ve insan onayı gerektiren işlemler.
  • Kalan riskler ve bunları kimin kabul ettiği.

Bu belge sadece uyum için değil, proje kapsamını netleştirmek için de değerlidir. Hangi verinin gerçekten gerektiği sorusu, çoğu zaman projeyi hem daha güvenli hem daha ucuz hale getirir.

KVKK uyumlu yapay zeka için kontrol listesi

  • Veri akış şeması çizildi; her durakta ülke, sağlayıcı ve saklama süresi yazılı.
  • Sisteme girecek belge kapsamı yazılı olarak belirlendi.
  • Kişisel veri gömmeden önce maskeleniyor ve kaçırma oranı test setiyle ölçülüyor.
  • Model sağlayıcısının veri işleme sözleşmesi incelendi; eğitimde kullanım ve saklama süresi netleşti.
  • Yurt dışına aktarım varsa güvence türü ve bildirim süreci hukuk danışmanıyla netleştirildi.
  • Erişim kontrolü arama anında, kullanıcının kimliğiyle uygulanıyor.
  • Kaynak sistemdeki yetki değişiklikleri vektör veritabanına senkronize ediliyor.
  • Ajanlar en az yetkiyle ve kullanıcı adına çalışıyor; riskli işlemler insan onayına bağlı.
  • Denetim izi ile içerik kaydı ayrı; içerik kayıtlarının saklama süresi kısa ve otomatik.
  • Bir kişiye ait verinin tüm katmanlardan silinme yolu tasarlandı ve denendi.
  • Özel nitelikli veri varsa kendi altyapıda çalışan model seçeneği değerlendirildi.
  • Risk değerlendirmesi yazıldı ve kalan riskler sahibine onaylatıldı.

Sık sorulan sorular

ChatGPT veya benzeri bir API'ye kişisel veri göndermek KVKK'ya aykırı mı? Tek başına aykırı değildir, ama bu genellikle yurt dışına aktarım anlamına gelir ve KVKK'nın 9. maddesindeki şartlardan birinin sağlanmasını gerektirir. Ayrıca sağlayıcının veriyi nasıl işlediği ve sakladığı sözleşmeyle netleşmelidir. Kendi durumunuzu hukuk danışmanınızla doğrulayın.

Vektörler kişisel veri sayılır mı? Gömme vektörleri metnin sayısal temsilidir ve bazı tekniklerle kaynak metne dair bilgi geri çıkarılabilir. Ayrıca vektör veritabanları çoğu zaman parçanın kendisini de saklar. Bu yüzden vektör deposunu, kaynak belgelerle aynı hassasiyette korumak doğru yaklaşımdır.

Anonimleştirme yaparsak KVKK kapsamından çıkar mıyız? Gerçekten geri döndürülemez anonimleştirme yapılmış veri, kişisel veri niteliğini kaybedebilir. Takma adlandırma ise bu sonucu doğurmaz; veri hâlâ kişisel veridir. Hangisini yaptığınızı ve sonucun geri döndürülemez olup olmadığını ölçerek gösterebilmeniz gerekir.

Açık kaynak model kullanırsak tüm sorunlar çözülür mü? Yurt dışına aktarım sorusu büyük ölçüde ortadan kalkar, ama erişim kontrolü, loglama, saklama ve ajan yetkileri aynen geçerlidir. Model nerede çalışırsa çalışsın, veri sınırını mimari belirler.

Kurumunuzda RAG tabanlı bir asistan veya ajan sistemi planlıyorsanız, veri akışını ve yetki modelini birlikte çıkarabiliriz. Yapay zeka çözümleri hizmetimizde çalışma şeklimizi, yapay zeka entegrasyonu yapan şirket seçimi rehberimizde tedarikçiye sorulacak soruları bulabilirsiniz. Projenizi konuşmak için hızlı teklif formunu doldurmanız yeterli.

Bir projeniz mi var?

Bu yazıda bahsettiğimiz teknolojileri projenizde hayata geçirelim.

Ücretsiz Keşif Görüşmesi İste