GDPR kapsamındaki verileri yöneten her veri bilimi ekibi bu betiğin bir versiyonunu yazmıştır:

import re
def anonymize_email(text):
    return re.sub(r'[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+.[a-zA-Z]{2,}', '[EMAIL]', text)

Bu, GDPR uyumluluğu değildir. Bu, e-posta adresi değiştirmedir. Veri seti hala isimler, telefon numaraları, tıbbi kayıt kimlikleri ve uyumluluk ihlallerine neden olacak bir düzine başka PII kategorisi içermektedir.

"E-postaları anonimleştirdim" ile "bu veri seti ML eğitimi için GDPR uyumlu" arasındaki boşluk büyüktür, sonuçları önemlidir ve genellikle göz ardı edilir.

GDPR'nın amaç sınırlaması ilkesi (Madde 5(1)(b)), kişisel verilerin belirli, açık ve meşru amaçlar için toplanabileceğini ve bu amaçlarla uyumsuz bir şekilde daha fazla işlenemeyeceğini belirtir.

Siparişin yerine getirilmesi için toplanan müşteri verileri, bir öneri modelini eğitmek amacıyla toplanmamıştır. Tedavi için toplanan sağlık kayıt verileri, yeniden kabul tahmin modeli eğitmek amacıyla toplanmamıştır. Ürün geri bildirimi için toplanan anket yanıt verileri, bir duygu analizi modelini eğitmek amacıyla toplanmamıştır.

Bu verilerin ML eğitimi için kullanılması, ya:

Her veri sahibinden ML eğitim amacı için açık rıza (operasyonel olarak karmaşık, genellikle geriye dönük olarak imkansız)
Eğitim amacının orijinal toplama ile uyumlu olduğunu gösteren meşru çıkar değerlendirmesi (hukuken belirsiz, DPA'ya bağımlı)
Anonimleştirme — PII'yi kaldırmak veya değiştirmek, böylece veri artık GDPR kapsamında kişisel veri olmaktan çıkmaktadır.

Doğru anonimleştirme, en az direnç ve en büyük hukuki kesinlik yoludur. Zorluk, bunu doğru ve tutarlı bir şekilde yapmaktır.

Geçici Anonimleştirme Betikleri ile İlgili Sorun

Her yeni veri seti için tek seferlik Python betikleri yazan veri bilimi ekipleri, birikimli sorunlar yaratır:

Tamamlanmamış kapsama: Bir veri setinin şemasını ele almak için yazılan bir betik, son şema güncellemesinden bu yana eklenen sütunlardaki PII'yi atlar. 6 ay önce eklenen klinik notlar alanı: regex deseninde yok. Müşteri ikinci adı alanı: regex yalnızca FIRST_NAME ve LAST_NAME desenlerini işler.

Veri setleri arasında tutarsızlık: Veri seti A, script_v1.py ile anonimleştirildi. Veri seti B, script_v3.py ile anonimleştirildi. Veri seti C, script_v3.py hakkında bilgi sahibi olmayan farklı bir ekip üyesi tarafından anonimleştirildi. Birleştirilmiş eğitim veri seti üç farklı anonimleştirme metodolojisine sahiptir. DPO bunu onaylayamaz.

Denetim izi yok: Betik çalıştı. Ne değiştirdi? Hangi varlıklar bulundu? Hangi satırlarda? İşleme meta verisi olmadan, uyumluluk belgeleri imkansızdır. Bir DPA denetçisi "bu eğitim veri setinin anonimleştirildiğini nasıl biliyorsunuz?" diye sorduğunda, "bir Python betiği çalıştırdık" tatmin edici bir cevap değildir.

Model kayması: 2023 verilerinde çalışan regex desenleri, 2024 verilerinde tanıtılan yeni tanımlayıcı formatlarını tespit etmez (yeni SSN formatı, farklı e-posta alanı desenleri, gelişen telefon numarası formatları). Betikler kendilerini güncellemez.

Parti İşleme Yaklaşımı

Bir sağlık AI şirketinin veri bilimi ekibi, ABD ekibinin AB ofisinden erişebilmesi için 8,000 hasta kaydını anonimleştirmek zorundadır (Schrems II sınır ötesi veri transfer kısıtlaması geçerlidir).

Geleneksel yaklaşım: Bir veri mühendisi özel bir Python anonimleştirme betiği yazar. Süre: 2-3 gün geliştirme, 1-2 gün DPO ile test ve inceleme, 1 gün iterasyon. Toplam: 4-6 gün. ML proje zaman çizelgesi kayar.

Parti işleme yaklaşımı:

8,000 kaydı CSV olarak dışa aktar (standart veri bilimi formatı)
Parti işlemeye yükle
Varlık türlerini yapılandır: PERSON, EMAIL_ADDRESS, PHONE_NUMBER, US_SSN, MEDICAL_RECORD, DATE_OF_BIRTH, LOCATION
Yöntemi seç: Değiştir (ML eğitimi için veri seti yapısını korumak için gerçekçi sahte verilerle değiştirme)
İşle: 8,000 kayıt için 45 dakika
Anonimleştirilmiş CSV'yi indir
DPO işlem meta verilerini gözden geçirir (kayıt başına bulunan varlıklar, uygulanan yöntemler): 2 saat
DPO onaylar, veri paylaşımı devam eder

Toplam süre: 45 dakika işleme + 2 saat DPO incelemesi, 4-6 gün mühendislik karşısında. ML zaman çizelgesi yolunda kalır.

Değiştirme vs. Kapatma için ML Eğitim Verisi

Anonimleştirme yönteminin seçimi, ML faydası için önemlidir:

Kapatma (siyah çubuk / yer tutucu değiştirme): PII'yi [REDACTED] veya benzeri bir token ile değiştirir. Ortaya çıkan veri seti, PII'nin bulunduğu yerlerde tutarlı yer tutucu token'ları içerir. PII'yi tespit etmek için eğitilen NLP modelleri için bu, etiketli bir veri seti oluşturur. Aşağı akış görevleri (duygu, sınıflandırma, öneri) için eğitilen modellerde, [REDACTED] token'ı doğal dil modellemesini bozar — model, [REDACTED]'nin özel bir token olduğunu öğrenir, gerçek isimlerin ve değerlerin dağılımından öğrenmek yerine.

Değiştirme (gerçekçi sentetik ikame): "John Smith" yerine "David Chen" (gerçekçi ama farklı bir isim) koyar. E-posta "jsmith@company.com" "dchen@synthetic.com" olur. Ortaya çıkan veri seti, doğal dil dağılımlarını — cümle yapısı, varlık yerleşimi, birlikte bulunma desenleri — korur; bu, NLP model eğitimi için önemlidir.

Özellikle ML eğitim verisi için, Değiştirme uygun yöntemdir. Model, belirli sahte değerleri tahmin etmeyi öğrenmez (rastgele ikameler), ancak isimlerin, e-postaların ve diğer varlıkların metin içinde nasıl göründüğüne dair yapısal ve bağlamsal desenlerden öğrenir.

Schrems II ve Sınır Ötesi Veri Akışları

Schrems II kararı (CJEU, 2020), AB-ABD Gizlilik Kalkanı'nı geçersiz kıldı ve AB'den ABD sunucularına veri transferleri için belirsizlik yarattı. Veri bilimi üzerindeki pratik etki: AB kökenli eğitim verileri, yeterli transfer güvenlik önlemleri olmadan ABD merkezli ML altyapısına (AWS US-East, GCP US-Central) gönderilemez.

Yeterli güvenlik önlemleri şunları içerir:

Transfer Etki Değerlendirmesi ile Standart Sözleşme Maddeleri (SCC)
Grup içi transferler için Bağlayıcı Kurumsal Kurallar (BCR)
Anonimleştirilmiş veriler için istisna: Doğru bir şekilde anonimleştirilmiş veriler, GDPR kapsamında kişisel veri değildir ve transfer kısıtlamalarına tabi değildir.

AB kökenli verilerle ABD merkezli ML altyapısını kullanan ekipler için, doğru anonimleştirme tamamen Schrems II sorununu ortadan kaldırır. Anonimleştirilmiş veri seti artık kişisel veri değildir — herhangi bir altyapıda transfer edilebilir, depolanabilir ve işlenebilir, transfer mekanizması gereklilikleri olmadan.

DPO Onayı için Belgeler

Anonimleştirilmiş eğitim verilerini DPO'ya onay için sunarken, şunları sağlayın:

Kaynak veri açıklaması: Orijinal veri seti neydi, toplama amacı neydi, hangi kişisel veri kategorilerini içeriyordu?
Anonimleştirme yapılandırması: Hangi varlık türleri tespit edildi ve değiştirildi? Hangi yöntem uygulandı?
İşleme meta verisi: Kayıt başına tespit edilen varlık sayısı, tespit güven puanları, işlenen toplam kayıt sayısı
Kalan risk değerlendirmesi: Anonimleştirilmiş veri setinden herhangi bir bireyin yeniden tanımlanma olasılığı nedir? Yapılandırılmış metne uygulanan 285+ varlık türü ile Değiştirme yöntemi anonimleştirmesi için bu olasılık çoğu eğitim veri seti için çok düşüktür.
Amaçlanan kullanım: Hangi ML modeli eğitilecek? Eğitim amacı nedir?

Parti işlemeye ilişkin işleme meta verisi, 2-3. noktaları otomatik olarak sağlar. 1, 4 ve 5. noktalar veri bilimcisinin katkısını gerektirir.

Sonuç

GDPR uyumlu ML eğitim verisi, geçici betik yazmadan, çok günlük mühendislik gecikmeleri olmadan ve model eğitimi için veri seti faydasından ödün vermeden elde edilebilir. Değiştirme anonimleştirme yöntemi, verilerin NLP model eğitimi için yararlı olmasını sağlayan doğal dil özelliklerini korurken, GDPR yükümlülüğü oluşturan kişisel veri özelliklerini ortadan kaldırır.

45 dakikalık parti işleme, zaman çizelgesini geciktiren bir uyumluluk incelemesi ile basit bir DPO onayı arasındaki farktır.

Kaynaklar:

İlgili Makaleler

Teknik

Verilerinizi korumaya hazır mısınız?

48 dilde 285+ varlık türü ile PII anonimleştirmeye başlayın.

Ücretsiz Deneme Başlat Özellikleri Görüntüle

GDPR Uyumlu ML Eğitim Verisi: Kod Yazmadan 10,000...