Kısa yanıt
Bir AI projesinin KVKK uyumu üç soruya net cevap vermekle başlar: Hangi kişisel veriyi, hangi hukuki sebeple ve nereye aktararak işliyorsunuz? Teknik tarafta ise dört önlem projelerin çoğunda yeterlidir: modele gönderilmeden önce maskeleme, amaçla sınırlı veri minimizasyonu, denetlenebilir loglama ve sağlayıcı ile veri işleyen sözleşmesi. Hassas veri söz konusuysa kurum içi ya da bölgesel model kurulumu tercih edilir.
Bu içerik teknik uygulama rehberidir, hukuki mütalaa değildir. Nihai değerlendirme için kurumunuzun hukuk müşaviriyle çalışmanız gerekir.
AI projelerinde KVKK neden farklı?
Klasik bir yazılım projesinde veri akışı öngörülebilirdir: form doldurulur, veritabanına yazılır, rapor üretilir. AI projelerinde ise üç yeni durum ortaya çıkar:
- Veri sınırın dışına çıkar. Model çağrısı çoğu zaman yurt dışındaki bir sağlayıcıya gider; bu bir aktarımdır.
- Amaç kayması kolaydır. Destek amacıyla toplanan kayıtların satış tahmininde kullanılması, amaçla sınırlılık ilkesini zorlar.
- Karar otomatikleşir. Sistem kişi hakkında sonuç doğuran bir değerlendirme yapıyorsa (kredi, işe alım, sigorta riski), şeffaflık ve itiraz mekanizması gerekir.
12 maddelik kontrol listesi
- Veri envanteri çıkarın. AI akışının dokunduğu her alanı listeleyin; hangi alanın kişisel veri, hangisinin özel nitelikli veri olduğunu işaretleyin.
- Hukuki sebebi yazın. Her işleme faaliyeti için açık rıza, sözleşmenin ifası, meşru menfaat gibi sebeplerden hangisine dayandığınızı belgeleyin.
- Amaçla sınırlayın. Model çağrısına yalnızca o görev için gerekli alanlar gitsin. "Ne olur ne olmaz" diye tüm kaydı göndermek en sık yapılan hatadır.
- Maskeleyin. TCKN, telefon, adres, IBAN gibi tanımlayıcıları çağrı öncesinde takma değerlerle değiştirin, yanıt döndükten sonra geri eşleyin.
- Özel nitelikli veriyi ayırın. Sağlık, biyometrik ve benzeri veriler ayrı bir güvenlik rejimi ister; genellikle kurum içi modelle işlenmesi doğru olur.
- Aktarımı belgeleyin. Sağlayıcı, sunucu bölgesi, veri kategorileri ve süre; aktarım kaydı olarak dosyalanmalı.
- Veri işleyen sözleşmesi imzalayın. Hem model sağlayıcısıyla hem de sistemi kuran çözüm ortağıyla.
- Eğitimde kullanılmama taahhüdü alın. Kurumsal API katmanlarında bu ayar genellikle mevcuttur; sözleşmeye yazdırın ve teknik olarak doğrulayın.
- Saklama süresi tanımlayın. İstem (prompt) ve yanıt logları da kişisel veri içerebilir; otomatik silme politikası kurun.
- Erişim yetkisi ayırın. Agent'ın veritabanı kullanıcısı yalnızca ihtiyaç duyduğu tablolara ve yalnızca gereken işlem tipine (okuma/yazma) sahip olmalı.
- Denetim izi tutun. Hangi kayıt, ne zaman, hangi modele, hangi amaçla gitti — sorulduğunda cevaplanabilir olmalı.
- Aydınlatma metnini güncelleyin. Otomatik değerlendirme, profilleme ve yurt dışı aktarımı açıkça yazın; ilgili kişi başvuru sürecini tanımlayın.
Teknik önlem: maskeleme ve veri minimizasyonu
Pratikte en çok işe yarayan önlem, model çağrısından hemen önce çalışan bir maskeleme katmanıdır. Kişisel tanımlayıcılar takma değerlerle değiştirilir, model işini takma değerler üzerinden yapar, dönen yanıtta değerler geri konur:
Ham kayıt : "Ayşe Yılmaz (TCKN 123...), 0532 000 00 00, Beşiktaş"
Modele giden : "[KISI_1] ([KIMLIK_1]), [TELEFON_1], Beşiktaş"
Model yanıtı : "[KISI_1] için randevu 14:00'e alındı"
Kullanıcıya : "Ayşe Yılmaz için randevu 14:00'e alındı"
Bu katman iki fayda sağlar: aktarılan kişisel veri miktarı ciddi biçimde düşer ve olası bir veri ihlalinde etki alanı daralır. Çoğu senaryoda modelin işini yapabilmesi için ismi bilmesi zaten gerekmez.
Yurt dışındaki model sağlayıcıları meselesi
Kurumların en çok takıldığı nokta burası. Üç yol var ve seçim veri hassasiyetine göre yapılır:
| Yaklaşım | Veri nereye gider | Uygun olduğu durum | Maliyet |
|---|---|---|---|
| Kurumsal API + maskeleme | Yurt dışı, takma adlandırılmış | Genel iş süreçleri, belge işleme | Düşük |
| Bölgesel özel bulut kurulumu | AB / seçilen bölge, izole | Finans, sigorta, müşteri verisi yoğun | Orta |
| Kurum içi açık kaynak model | Şirket altyapısından çıkmaz | Sağlık, özel nitelikli veri, savunma | Yüksek (donanım) |
Doğru cevap çoğu zaman melezdir: hassas alanları kurum içi küçük bir model işler, genel dil işleri için dış API kullanılır. Bu ayrımı mimari aşamada yapmak, sonradan taşımaktan çok daha ucuzdur.
Uyumlu mimari seçenekleri
- Tek çıkış noktası. Tüm model çağrıları tek bir servis üzerinden geçsin; maskeleme, loglama ve bütçe kontrolü orada uygulansın.
- Yetki kapsamı dar tutulmuş araçlar. Agent'ın kullandığı her fonksiyon, erişebileceği veri kümesiyle birlikte tanımlansın.
- Ayrıştırılmış loglar. Teknik log (süre, maliyet, hata) ile içerik logu ayrı saklansın; içerik logu kısa ömürlü ve şifreli olsun.
- İnsan onay kapıları. Kişi hakkında sonuç doğuran kararlarda son onay insanda kalsın; bu hem uyum hem güven açısından belirleyicidir.
Hazırlanması gereken belgeler
- Güncellenmiş kişisel veri işleme envanteri (AI akışları dahil)
- AI özelinde genişletilmiş aydınlatma metni
- Model sağlayıcısı ve çözüm ortağıyla veri işleyen sözleşmeleri
- Yurt dışına aktarım kaydı ve gerekçesi
- Saklama ve imha politikasının log/prompt kayıtlarını kapsayan güncellemesi
- Yüksek riskli işlemeler için etki değerlendirmesi
- Erişim yetki matrisi (hangi agent hangi tabloya, hangi yetkiyle)