İçeriğe geç

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
GDPR, KVKK ve Unutulma Hakkı: Recommender'da Hukuk Uyumu
📜 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üzenlemeYargı AlanıYürürlükRecommender'a Etkisi
GDPRABMayıs 2018Çok yüksek — data subject rights
KVKKTürkiyeNisan 2016Yüksek — GDPR-benzer
AB AI ActABŞubat 2025 - Ağustos 2026Yüksek — recommender bazıları "high-risk"
DSA (Digital Services Act)ABŞubat 2024Çok yüksek — algoritma transparansı
Çin PIPLÇinKasım 2021Yüksek (Çin operasyonu için)
California CCPA/CPRAABD CAOcak 2023Orta
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:
    user.personalization_enabled = false
    flag — fallback to popularity ranking.

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 pattern
import json
from datetime import datetime
from 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 pattern
audit = 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ımTipik Recommender
Unacceptable Risk (Yasaklı)Social scoring, manipülasyon"Subliminal manipulation" yapan recommender (çocuklara)
High RiskKritik 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 RiskSınırlı/yok düzenlemeSpam 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)#

  1. 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).
  2. Veri sorumlusu sicili (VERBİS) zorunlu kayıt — çoğu mid-sized şirket için.
  3. Yurt dışı veri transferi — AB'ye transfer için Adequacy decision bekleniyordu, 2024'te kısıtlı verildi.
  4. 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ı#

KonuGDPRKVKK
Veri taşınabilirliğiTam hakVar ama daha sınırlı yorumlama
Otomatik karar almaAçıkça düzenliDaha az detaylı
CezalarYıllık cironun %4'üne kadar64M TL tavanı
OtoriteEDPB + ulusal otoritelerKVKK Kurumu

Pratik Uyum Checklist'i — Recommender Mühendisleri İçin#

Bir recommender mühendisi olarak günlük işinde dikkat edeceğin 10 madde:
  1. Privacy notice güncel mi? — Recommender kullanımı açıkça belirtilmiş mi?
  2. Consent toplama doğru mu? — Cookie banner'da kişiselleştirme separated checkbox?
  3. Anonymization yeterli mi? — User ID'ler hash'lenmiş, IP'ler trimmed?
  4. Data retention policy uygulanıyor mu? — Eski log'lar otomatik silinen bir cron?
  5. Right to access endpoint'i var mı? — User kendi datasını JSON olarak indirebiliyor mu?
  6. Right to erasure işliyor mu? — Silme talebi 30 gün içinde tamamlanıyor mu?
  7. Audit log tutuluyor mu? — Veri erişim ve silme kaydı var mı?
  8. Opt-out from personalization seçeneği var mı? — Setting'lerde belirgin mi?
  9. Recommender explainability var mı? — "Neden bu öneri?" sorusuna cevap mekanizması?
  10. 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

Bağlantılı Pillar Konular

Bu yazının bağlandığı pillar konular