GDPR, KVKK ve Unutulma Hakkı: Recommender'da Hukuk Uyumu
Bir recommender sistemi data subject rights (erişim, silme, taşıma) ile nasıl uyum sağlar? AB AI Act 2024-2026 takvimi, KVKK'nın 2025 güncellemesi, ML modelinden user data'sı çıkarma teknikleri (machine unlearning), audit log gereksinimleri.
Şükrü Yusuf KAYA
22 dakikalık okuma
Orta📜 Bu dersin amacı
Bu ders 'sıkıcı' görünebilir ama uyumsuzluk bir startup'ı 8 haneli para cezasıyla bitirir. Bir recommender mühendisi olarak hukuki temeli bilmek artık opsiyonel değil — sistem tasarım kararlarını doğrudan etkiliyor. Bu derste: GDPR (2018), KVKK (2016 + 2025 güncelleme), AI Act (2024-2026 takvimi) ve machine unlearning pratiği.
Düzenleme Manzarası (2026 İtibariyle)#
| Düzenleme | Yargı Alanı | Yürürlük | Recommender'a Etkisi |
|---|---|---|---|
| GDPR | AB | Mayıs 2018 | Çok yüksek — data subject rights |
| KVKK | Türkiye | Nisan 2016 | Yüksek — GDPR-benzer |
| AB AI Act | AB | Şubat 2025 - Ağustos 2026 | Yüksek — recommender bazıları "high-risk" |
| DSA (Digital Services Act) | AB | Şubat 2024 | Çok yüksek — algoritma transparansı |
| Çin PIPL | Çin | Kasım 2021 | Yüksek (Çin operasyonu için) |
| California CCPA/CPRA | ABD CA | Ocak 2023 | Orta |
Türkiye için: KVKK + AB pazarlarına satıyorsan GDPR + AB AI Act. Üçü birlikte uyum gerek.
Data Subject Rights — Bir Recommender İçin Ne Anlama Geliyor?#
GDPR (ve KVKK) bireylere veri kontrolü hakkı verir. Her birinin teknik karşılığı vardır:
1. Right to Access (Erişim Hakkı)#
- Hak: Bir birey "benim hakkımda hangi verileri tutuyorsun?" diye sorabilir.
- Recommender etkisi: User'ın click log'u, embedding'i, model tahminleri hepsi erişilebilir olmalı.
- Teknik: JSON export endpoint — .
GET /api/user/me/data-export
2. Right to Rectification (Düzeltme Hakkı)#
- Hak: Birey yanlış veriyi düzeltebilir.
- Recommender etkisi: "Bu öneri yanlış" feedback'i toplama ve action alma.
- Teknik: Negative feedback button, manuel preference editing.
3. Right to Erasure / "Right to Be Forgotten" (Silme/Unutulma Hakkı)#
- Hak: Birey "tüm verimi sil" diyebilir.
- Recommender etkisi: EN ZOR olanı — sadece raw log'u silmek yetmez, model embedding'inden de çıkarmak gerek.
- Teknik: Machine unlearning (aşağıda detaylı).
4. Right to Data Portability (Taşıma Hakkı)#
- Hak: Birey verisini başka servise taşıyabilir.
- Recommender etkisi: User'ın ekspresif tercihleri (rating, favori listesi) export edilebilir formatta.
- Teknik: JSON/CSV download — .
POST /api/user/me/export-portable
5. Right to Object / Restriction of Processing#
- Hak: Birey kişiselleştirmeyi reddedebilir.
- Recommender etkisi: "Kişiselleştirilmemiş sürüm" alternatifi sunma.
- Teknik: flag — fallback to popularity ranking.
user.personalization_enabled = false
6. Right Not to Be Subject to Automated Decision-Making#
- Hak: Birey "otomatik karar alma" yerine insan karar ister.
- Recommender etkisi: Genelde recommender'lar "decision making" değil, "öneri" — direkt etki dar. AMA: kredit scoring, iş başvuru ranking gibi recommender'lar bu hakka tabi.
- Teknik: Opt-out + human review mekanizması.
Machine Unlearning — Modelden Veri Çıkarmak#
Sorun#
Bir kullanıcı GDPR talebi ile "tüm verimi sil" diyor. Raw log'u silmek 1 dakika. Ama:
- O kullanıcının click'leriyle eğitilmiş embedding tablosu ne olacak?
- O kullanıcının davranışları CF model'in matris faktörlerinde kodlanmış — bu nasıl çıkarılır?
- Production modeli şimdi çalışıyor — yeniden eğitmek 6 saat sürer.
Üç Pratik Yaklaşım#
Yaklaşım 1: Full Retrain (En Güvenli, En Yavaş)
# Periyodik olarak (örn. haftalık) modeli sıfırdan yeniden eğit # DELETED_USERS = user'lardan oluşan set training_data = all_events.filter(~pl.col("user_id").is_in(DELETED_USERS)) model.fit(training_data)
Maliyet: 6 saat - 3 gün eğitim süresi. Bayağı pahalı.
Faydası: %100 garanti — user'ın izi tamamen siliniyor.
Yaklaşım 2: Incremental Forgetting (Daha Hızlı)
Embedding tablolarında silinmesi gereken user'ın embedding row'unu sil/sıfırla.
def forget_user(model, user_id): """User'ı embedding'den çıkar.""" idx = model.user_to_idx[user_id] model.user_embeddings[idx] = 0.0 # veya delete row del model.user_to_idx[user_id]
Sorun: User'ın etkisi diğer user'ların embedding'lerine sızmış olabilir (CF nature). Bu yaklaşım "yüzeysel" silme.
Yaklaşım 3: SISA Training (Bourtoule et al. 2021)
Modeli N parçaya böl, her parça user'ların disjoint subset'ini eğitsin. Bir user silineceğinde sadece o user'ın olduğu parçayı yeniden eğit.
Model = ensemble(submodel_1, submodel_2, ..., submodel_N) submodel_k eğitildi: user_partition_k üstünde
User u silinmek istendiğinde: u'nun olduğu submodel_k'yı yeniden eğit. Diğerleri dokunulmamış. N kat hızlı.
Trade-off: Model performansı tek monolithic model'e göre biraz düşebilir (sub-models bilgi paylaşmıyor).
Bourtoule et al. 2021 (USENIX Security)#
"Machine Unlearning" — SISA paper'ı. Recommender özelinde tam aynı değil ama core fikir uygulanabilir.
python
# compliance/audit.py — Audit log patternimport jsonfrom datetime import datetimefrom typing import Literal class AuditLog: """ GDPR/KVKK uyumlu audit log. Her data access ve modification kaydedilir. Tip 1: Veri erişimi (user kendi datasını gördü, admin erişti). Tip 2: Veri modifikasyonu (silme, düzeltme). Tip 3: Otomatik karar (öneri verildi). """ def __init__(self, db): self.db = db def log_data_access( self, accessor_id: str, accessor_role: Literal["self", "admin", "service"], data_subject_id: str, resource: str, legal_basis: str, ): record = { "timestamp": datetime.utcnow().isoformat(), "type": "data_access", "accessor_id": accessor_id, "accessor_role": accessor_role, "data_subject_id": data_subject_id, "resource": resource, # örn. "user.embedding" "legal_basis": legal_basis, # KVKK Article 5/2/c gibi } self.db.audit_logs.insert_one(record) def log_data_deletion( self, data_subject_id: str, deleted_resources: list[str], deletion_method: Literal["full_retrain", "incremental", "sisa"], completion_status: Literal["pending", "completed", "failed"], request_reference: str, # erasure request ID ): record = { "timestamp": datetime.utcnow().isoformat(), "type": "data_deletion", "data_subject_id": data_subject_id, "deleted_resources": deleted_resources, "deletion_method": deletion_method, "completion_status": completion_status, "request_reference": request_reference, } self.db.audit_logs.insert_one(record) def log_automated_decision( self, user_id: str, decision_type: str, # örn. "personalized_recommendation" model_version: str, decision_factors: dict, # explainability için ): record = { "timestamp": datetime.utcnow().isoformat(), "type": "automated_decision", "user_id": user_id, "decision_type": decision_type, "model_version": model_version, "decision_factors": decision_factors, } self.db.audit_logs.insert_one(record) # Usage patternaudit = AuditLog(db) # Bir recommendation servis edildiğinde:audit.log_automated_decision( user_id="user_12345", decision_type="homepage_recommendation", model_version="dcn-v2-2026-03-14", decision_factors={ "top_features": ["recent_views", "category_pref", "time_of_day"], "candidate_pool_size": 1500, "final_top_k": 12, },) # User silme talebi geldiğinde:audit.log_data_deletion( data_subject_id="user_12345", deleted_resources=["events", "user_embedding", "model_input"], deletion_method="incremental", completion_status="completed", request_reference="erasure_req_2026_03_14_abc",) GDPR/KVKK uyumlu audit log pattern — production'da MongoDB veya PostgreSQL'de saklanır.
AB AI Act — Recommender'a Etkisi (2025-2026)#
AB AI Act 1 Şubat 2025'te yürürlüğe girdi, 2 Ağustos 2026'da tam uygulanır. Recommender sistemlerin sınıflandırılması:
Risk Sınıfları ve Recommender'lar#
| AI Act Risk Sınıfı | Tanım | Tipik Recommender |
|---|---|---|
| Unacceptable Risk (Yasaklı) | Social scoring, manipülasyon | "Subliminal manipulation" yapan recommender (çocuklara) |
| High Risk | Kritik altyapı, eğitim, istihdam | İş başvurusu ranking, kredit recommender, sağlık tavsiyesi |
| Limited Risk | Şeffaflık gereken AI | Çoğu recommender (e-ticaret, içerik, müzik) |
| Minimal Risk | Sınırlı/yok düzenleme | Spam filter, genel sıralama |
Limited Risk için Şeffaflık Gereksinimleri#
- Bildirim: Kullanıcıya "bu içerik AI ile kişiselleştirildi" bilgisi verme.
- Açıklanabilirlik: "Niçin bu önerildi?" sorusuna anlamlı cevap.
- Opt-out: Personalization olmayan görünüm seçeneği.
High Risk için Ekstra Gereksinimler#
- Bias değerlendirmesi — özellikle korunan demografik gruplar için.
- Human oversight — kararı bir insan onaylamalı.
- Quality management system — ISO 27001 benzeri sertifikasyon.
Recommender Mühendisi İçin Pratik Etki#
Eğer Trendyol/Hepsiburada gibi e-ticaret'te çalışıyorsan: Limited Risk. Şeffaflık + opt-out bilgileri eklemen yeter.
Eğer iş ilanı eşleştirmesi (kariyer.net, LinkedIn) veya finansal ürün önerisi yapıyorsan: High Risk. Çok daha ağır gereksinimler.
KVKK 2025 Güncellemesi — Türkiye'deki Durum#
KVKK (6698 Sayılı Kanun) 2016'da yürürlüğe girdi, 2025'te önemli güncelleme aldı:
Önemli Değişiklikler (2025)#
- Açık rıza yerine "meşru menfaat" daha geniş — recommender için "kullanıcı deneyimini iyileştirme" meşru menfaat sayılır (yine de bilgilendirme şart).
- Veri sorumlusu sicili (VERBİS) zorunlu kayıt — çoğu mid-sized şirket için.
- Yurt dışı veri transferi — AB'ye transfer için Adequacy decision bekleniyordu, 2024'te kısıtlı verildi.
- Cezalar 2025'te artırıldı — maksimum 16M TL → 64M TL.
Recommender İçin Pratik#
- Privacy notice'inde recommender'ı belirt — "kullanıcı davranış analizi ile öneri kişiselleştirme".
- Cookie banner'da segmentation tracking için consent al.
- Çocuk koruma — 13-18 yaş arası özel kategori, ekstra rıza.
KVKK ile GDPR Farkları#
| Konu | GDPR | KVKK |
|---|---|---|
| Veri taşınabilirliği | Tam hak | Var ama daha sınırlı yorumlama |
| Otomatik karar alma | Açıkça düzenli | Daha az detaylı |
| Cezalar | Yıllık cironun %4'üne kadar | 64M TL tavanı |
| Otorite | EDPB + ulusal otoriteler | KVKK Kurumu |
Pratik Uyum Checklist'i — Recommender Mühendisleri İçin#
Bir recommender mühendisi olarak günlük işinde dikkat edeceğin 10 madde:
- ✅ Privacy notice güncel mi? — Recommender kullanımı açıkça belirtilmiş mi?
- ✅ Consent toplama doğru mu? — Cookie banner'da kişiselleştirme separated checkbox?
- ✅ Anonymization yeterli mi? — User ID'ler hash'lenmiş, IP'ler trimmed?
- ✅ Data retention policy uygulanıyor mu? — Eski log'lar otomatik silinen bir cron?
- ✅ Right to access endpoint'i var mı? — User kendi datasını JSON olarak indirebiliyor mu?
- ✅ Right to erasure işliyor mu? — Silme talebi 30 gün içinde tamamlanıyor mu?
- ✅ Audit log tutuluyor mu? — Veri erişim ve silme kaydı var mı?
- ✅ Opt-out from personalization seçeneği var mı? — Setting'lerde belirgin mi?
- ✅ Recommender explainability var mı? — "Neden bu öneri?" sorusuna cevap mekanizması?
- ✅ DPIA (Data Protection Impact Assessment) yapıldı mı? — High risk recommender için zorunlu.
🎉 Modül 2 Tamamlandı!
Veri, etiketleme, bias, hukuk — recommender mühendisliğinin görünmez ama kritik tarafı. Bir sonraki modülde Evaluation Protokollerine iniyoruz — RMSE'den NDCG'ye, A/B test'ten interleaving'e. Bu, 'modelim iyi mi?' sorusuna doğru cevap vermenin sanatı.
Sık Sorulan Sorular
Çoğu küçük-orta ölçekli şirket için: full retrain yeterli (haftalık veya aylık schedule ile). Ama büyük modeller (10TB embedding) için full retrain çok pahalı. SISA tarzı incremental yaklaşım büyük ölçekte para tasarrufu. KVKK için 30 gün içinde silme yeterli — günlük unlearning şart değil.
Yorumlar & Soru-Cevap
(0)Yorum yazmak için giriş yap.
Yorumlar yükleniyor...
İlgili İçerikler
Modül 0: Kurs Çerçevesi ve Atölye Kurulumu
Öneri Sistemleri Neden Bu Kadar Önemli? Bir Disiplinin Doğuşu, Bugünü ve Yarını
Öğrenmeye BaşlaModül 0: Kurs Çerçevesi ve Atölye Kurulumu
Recommender Engineer Kimdir? Yetkinlik Atlası ve Junior → Staff Kariyer Haritası
Öğrenmeye BaşlaModül 0: Kurs Çerçevesi ve Atölye Kurulumu
Kurs Felsefesi: Matematik → Manuel Kod → Kütüphane → Benchmark → Üretim
Öğrenmeye BaşlaBağlantılı Pillar Konular