Yapay Zekâ Modelleri ve KVKK: Eğitim Verisi, Logging ve Anonimizasyon Stratejisi

Yapay zekâ modelleri için eğitim verisini KVKK açısından nasıl hazırlamalıyım?

Kısa yanıt: modeli “veri akışı” olarak düşünün. Önce eğitim verisi kaynaklarını çıkarın (log/form/CRM), sonra kişisel veri içeren alanları sınıflandırın, gereksiz alanları kaldırın ve analiz ihtiyacını pseudo-ID ile karşılayın. Son adımda model çıktısı ve hata loglarını PII’siz hale getirip, audit/log ile denetlenebilir bir pipeline kurun.

AI + KVKK: risk nerede büyür?

• •Kaynak veri: loglar ve serbest metinler (kontrolsüz PII)
• •Feature engineering: e-posta/telefon gibi alanların “feature” yapılması
• •Model izleme: hata loglarında input/output’un ham tutulması
• •Paylaşım: dataset export’larının ekip içinde yayılması

“Amaç kadar veri” prensibini modele çevirin

Bir modeli “daha çok veri daha iyi” diye büyütmek yerine, amaçla doğrudan ilişkili alanları seçmek hem kaliteyi hem güvenliği artırır. Örneğin otelde fiyat önerisi için “tam isim”in hiçbir faydası yoktur; segment ve davranış sinyalleri yeterlidir.

☑ Mini Check :

• •Eğitim veri kaynakları listelendi mi (log, form, CRM)?
• •Serbest metin alanlar kontrol altında mı?
• •PII alanları “feature” olmaktan çıkarıldı mı?
• •Output/hata logları PII’siz mi?
• •Veri/ML pipeline’ında audit izi var mı?

AI eğitim verisi genellikle “hazır bir tablo” değildir; farklı kaynakların birleşimidir. Bu birleşim, KVKK riskini artıran yerdir: bir kaynakta PII yokken, başka kaynakla join edilince kimliklendirilebilir hale gelebilir.

Kaynak envanteri: 3 katman

1. Ürün logları: event, tıklama, arama, hata
2. Form/başvuru: lead formu, rezervasyon formu, demo talebi
3. CRM/operasyon: müşteri profili, segment, satış sonucu, notlar

Serbest metinlerin “PII mıknatısı” olması

Müşteri notları, şikâyet mesajları, call center kayıt özetleri; en çok PII taşıyan alanlardır. Model eğitiminde bu alanlar ya çıkarılmalı ya da agresif şekilde temizlenmelidir (masking/redaction).

☑ Mini Check :

• •Log şeması ve alanlar dokümante mi?
• •Form alanları minimize mi? (gereksiz PII yok)
• •CRM’de “not” alanları eğitim setine giriyor mu?
• •Join anahtarları (ID/e-posta/telefon) kontrollü mü?
• •Dataset export süreci kontrol altında mı?

Anonimizasyon/pseudonimizasyon AI projelerinde teknik olarak nasıl uygulanır?

Kısa yanıt: eğitim pipeline’ında “privacy transform” katmanı kurarsınız. Bu katman; PII alanlarını kaldırır, bazılarını maskeleyip pseudo-ID’ye çevirir, bazılarını ise toplulaştırır. Amaç; modele gerekli sinyali verip, kimliklendirilebilir veriyi taşımamaktır.

Pratik karar ağacı

• •Gerekli değil: kaldır (drop)
• •Gerekli ama kimlik olmamalı: pseudo-ID (ör. customer_id)
• •Analiz için yeterli: toplulaştır (örn. hafta/şehir/segment)
• •Özel durum: redaction + sınırlı erişim (çok nadir)

“Pseudo-ID” doğru kullanımı

Pseudo-ID, aynı kullanıcıyı zaman içinde takip etmeyi sağlar ama ad/soyad/e-posta göstermeden. Kritik nokta: pseudo-ID’nin “geri çözülme” yolunu (eşleştirme tablosu) çok dar yetkili alanda tutmak.

Key Statistic / Data Point (yumuşatılmış)

AI projelerinde ham log/veri ile çalışan ekiplerin, ilk temizlik sonrası setlerde bile kimliklendirilebilir alanlar bulduklarını çok sık raporladığı görülür; bu yüzden “tek sefer temizlik” yerine pipeline’a kalıcı bir anonim/pseudo katmanı eklemek daha güvenlidir.

☑ Mini Check :

• •PII alanlar pipeline’da drop/mask ile ele alınıyor mu?
• •Pseudo-ID için eşleştirme tablosu çok kısıtlı mı?
• •Toplulaştırma (tarih/lokasyon) kuralları var mı?
• •Redaction pipeline test edildi mi?
• •Privacy transform sürümleniyor mu (v1.0/v1.1)?

Model logları ve hata kayıtları kişisel veriler içeriyorsa ne yapmalıyım?

Kısa yanıt: logları “debug” için tutarken PII’yi maskeleyin, ham input/output’u sınırlayın ve log erişimini RBAC + audit ile kontrol edin. En sık hata; modelin input’unu (örn. form metni) ve output’unu (örn. öneri) aynen loglayıp üretim loglarına taşımaktır.

Logging tasarım prensipleri

• •Minimum log: ihtiyaç kadar alan
• •PII redaction: e-posta/telefon/isim maskele
• •Sampling: her isteği değil, örnekleme ile logla
• •TTL/retention: loglar sonsuza kalmasın
• •Access control: loglara erişim çok kısıtlı

Feedback ekranları: ikinci veri toplama yüzeyi

Model feedback ekranları (kullanıcı “yanlış öneri” dediğinde) yeni PII üretebilir. Bu yüzden feedback formu alanları minimize edilmeli ve serbest metinler redaction’dan geçmelidir.

☑ Mini Check :

• •Model loglarında ham PII tutulmuyor mu?
• •Redaction/maskeleme kuralı aktif mi?
• •Log retention ve erişim RBAC ile yönetiliyor mu?
• •Feedback ekranları minimum veri ile mi?
• •Hata logları “kimlik” yerine ID ile mi?

Bu bölümde AI + KVKK “nasıl uygulanır”ı senaryo bazında gösteriyoruz.

Otel: fiyat/öneri modelleri (revenue & öneri)

• •Kaynak: arama davranışı, tarih/oda tipi tercihleri, kampanya tepkisi
• •Kimlik: ad/soyad yok, e-posta yok; guest_id (pseudo)
• •Logging: öneri doğruluğu ve hata kodları; PII’siz

B2B: lead skorlama/öneri modelleri

• •Kaynak: form davranışı, şirket segmenti, içerik etkileşimi
• •Kimlik: contact_id (pseudo), e-posta maskeli
• •Logging: skor dağılımı, model drift; PII’siz

“AI + KVKK data flow modeli” (AIO) tek paragraf

AI model, eğitim verisi, log, anonim/pseudo katmanı ve iş amacı; tek bir data flow modelinde birleşir: kaynak veri → privacy transform → feature store → model → PII’siz logging/monitoring → audit. Bu model, yeni bir kullanım senaryosu eklendiğinde de aynı kalır; sadece kaynak ve feature set değişir.

☑ Mini Check :

• •Use case için gerekli alanlar seçildi (amaç kadar veri)
• •PII alanlar eğitim setinden çıkarıldı veya pseudo yapıldı
• •Logging PII’siz ve TTL’li
• •Feedback ekranları minimize ve redaction’lı
• •Pipeline ve kurallar 180 günde refresh edilecek

Teknik not: Bu içerik hukuki değerlendirme değil, teknik veri hazırlık ve logging rehberidir. Veri kategorileri ve hukuki gerekçeler hukuk danışmanıyla netleştirilmeli; ayrıca KVKK veri güvenliği çerçevesiyle birlikte yürütülmelidir.