# Kişisel veriyi bir dil modeline ulaşmadan maskelemek.

> Bu saha notunda veridive, metin bir dil modeline ulaşmadan kişisel verinin nasıl maskeleneceğini anlatıyor: neyin maskeleneceği, maskelemenin takma adlandırma ve anonimleştirmeden farkı, TC kimlik numarası, IBAN, telefon numarası ve isimlerin yerelde tespiti, geri çevrilebilir yer tutucular, maskelemenin sessizce başarısız olduğu yerler ve tespitin kendi veri biçimlerinizde nasıl test edileceği.

Maskeleme model sağlayıcının gördüğünü azaltır ama anonimleştirme değildir ve sessizce başarısız olur. Tespiti yerelde yapın, yanıtın ihtiyaç duyduğu yerde geri çevrilebilir yer tutucular kullanın, tespiti kendi veri biçimlerinizde test edin ve maskelemeyi gizlilik planının tamamı saymayın.

## Öne çıkanlar

- Maskeleme model sağlayıcının gördüğünü azaltır ama anonimleştirme değildir; maskelenmiş verinin hâlâ kişisel veri sayılıp sayılmadığı hukuk danışmanının konusudur.
- Kişisel veriyi model çağrısından önce, yerelde tespit edin: kontrol haneli biçim kuralları, isim tanıma ve müşterinin zaten bilinen bilgileriyle.
- Yanıtın kişiden söz etmesi gerekiyorsa MUSTERI_1 gibi geri çevrilebilir yer tutucular kullanın ve gerçek değerleri yerelde geri koyun.
- Maskeleme bağlam, serbest notlar, taramalar ve ekler yüzünden sessizce başarısız olur; bu yüzden duyarlılığı kendi veri biçimlerinizde test edin.

Bir şikayet e-postası geliyor: içinde müşterinin adı soyadı, cep telefonu numarası ve para iadesinin yapılmasını istediği IBAN var. Ekip, yanıtı bir dil modelinin hazırlamasını istiyor. Metin sistemlerinizden çıkmadan önce adın, numaranın ve IBAN’ın da onunla gitmesi gerekip gerekmediğini sorun. Çoğu zaman gerekmez.

Kişisel veri maskeleme (PII redaction), yani kişisel veriyi model çağrısından önce yer tutucularla değiştirmek, bir dil modelinin çevresindeki en yararlı gizlilik önlemlerinden biridir; aşırı güven duyulmaya en açık olanlardan biri de odur. Anonimleştirme değildir ve başarısız olduğunda bunu belli etmez. Bu yüzden tespiti yerelde yapın, yanıtın ihtiyaç duyduğu yerde geri çevrilebilir yer tutucular kullanın, tespiti kendi veri biçimlerinizde test edin ve maskelemeyi gizlilik planının tamamı saymayın.

## Neler maskelenmeli ve neden?

Modelin görev için ihtiyaç duymadığı her şey: bir şikayete verilecek yanıt, müşterinin kimlik numarasına değil şikayetin kendisine ihtiyaç duyar. Olağan adaylar şunlardır:

- **Doğrudan tanımlayıcılar:** adlar, kimlik ve pasaport numaraları, e-posta adresleri, telefon numaraları.
- **Finansal bilgiler:** IBAN’lar, kart ve hesap numaraları.
- **Adresler,** daire numarasına kadar.
- **Bir araya gelince kimliği ele verenler:** doğum tarihi, küçük bir ekipteki unvan, nadir bir olay.
- **Serbest metindeki hassas ayrıntılar:** temsilci notlarındaki sağlık ya da aile bilgileri gibi. Bu tür verilerin hiç işlenip işlenemeyeceğini veri koruma görevlinize (DPO) sormanız gerekir.

Sağlayıcıya hiç ulaşmayan veri orada kaydedilemez, saklanamaz ya da açığa çıkamaz. Yolun geri kalanını [bir dil modeli kullandığınızda verilerinizin nereye gittiğini](https://veridive.com/tr/saha-notlari/llm-veri-gizliligi/) anlatan not ele alıyor.

## Maskeleme, takma adlandırma ve anonimleştirme arasındaki fark nedir?

Teknik açıdan:

| Teknik | Ne yapar | Kişiye geri ulaşılabilir mi? |
|---|---|---|
| Maskeleme | Bir değeri siler ya da [AD] gibi genel bir etiketle değiştirir | Maskelenmiş metinden ulaşılamaz |
| Takma adlandırma (pseudonymization) | Her değeri MUSTERI_1 gibi tutarlı bir yer tutucuyla değiştirir; eşleştirme ayrı tutulur | Evet, eşleştirmeyle |
| Anonimleştirme | Veriyi, başka bilgilerle bile kişinin makul biçimde yeniden tanınamayacağı şekilde dönüştürür | Tasarım gereği ulaşılamaz |

Dil modelleri için yapılan maskelemenin çoğu aslında takma adlandırmadır, çünkü yanıtta gerçek değerlerin yeniden yerine konması gerekir. Veri koruma mevzuatı bu terimleri kendine göre tanımlar. Maskelenmiş verinizin hâlâ kişisel veri sayılıp sayılmadığı teknik bir soru değildir; veri koruma görevlinize ya da hukuk danışmanınıza sorulmalıdır. [Onlara sorulacak soruları](https://veridive.com/tr/saha-notlari/kvkk-gdpr-ve-yapay-zeka/) ayrı bir notta derledik.

## Türkçe ve İngilizce metinde kişisel veri nasıl tespit edilir?

Yerelde, model çağrısından önce: bir metindeki kişisel veriyi bulmak için onu harici bir modele göndermek amacı boşa çıkarır. Farklı şeyleri yakalayan katmanlar kullanın:

1. **Biçim kuralları ve kontrol haneleri.** TC kimlik numaraları on bir hanelidir, sıfırla başlamaz ve ilk dokuz haneden türetilen iki kontrol hanesiyle biter; bu yüzden bir doğrulayıcı, sipariş numaraları gibi rastgele on bir haneli sayıların çoğunu eler. IBAN’ların da kendi kontrol haneleri vardır; Türkiye’deki IBAN’lar TR ile başlar ve yirmi altı karakterdir. Telefon numaraları +90 ile, 0 ile ya da öneksiz; boşluk, nokta veya tirelerle farklı yerlerden bölünmüş olarak karşınıza çıkar.
2. **İsim ve adres tanıma:** kendi altyapınızda çalışan bir varlık tanıma (NER) modeliyle, yani adları, yerleri ve kurumları etiketleyen bir modelle. Modeli Türkçe karakterli isimlerde, büyük harfle ya da Türkçe harfler olmadan yazılmış isimlerde (“Şükrü” yerine “SUKRU”) ve Deniz, Umut ya da Barış gibi aynı zamanda gündelik birer kelime olan isimlerde test edin. Türkçe adreslerin kendine özgü işaretleri vardır: Mah., Cad., Sok., No: ve Daire.
3. **Bilinen değerler.** Bağlı CRM kaydındaki ad, e-posta ve telefon numarası en güvenilir sinyallerdir; bunları birebir eşleştirin.
4. **Metindeki etiketler:** “Ad Soyad:”, “IBAN:” ya da “Name:” gibi, ardından ne geleceğini söyleyen etiketler.

**İş bittiğinde:** her varlık türü için, kendi örneklerinizde duyarlılığı (recall) ölçülmüş bir tespit aracı vardır. **Sık yapılan hata:** İngilizce metne göre ayarlanmış ve Türkçe isimleri kaçıran bir tespit aracı.

## Geri çevrilebilir yer tutuculara ne zaman ihtiyaç duyulur?

Çıktının kişiden ya da onun bilgilerinden söz etmesi gerektiğinde. Her değeri MUSTERI_1, TELEFON_1 ya da IBAN_1 gibi türü belli ve numaralı bir yer tutucuyla değiştirin, eşleştirmeyi kısa bir süre kendi tarafınızda tutun ve gerçek değerleri çıktıya yerelde geri koyun. Yönlendirme ya da sınıflandırmada olduğu gibi çıktının buna ihtiyacı yoksa tek yönlü maskeleyin ve hiç eşleştirme tutmayın.

Girişteki temsili şikayete dönelim. Yerel tespit, adı gönderenin CRM kaydından, cep telefonu numarasını kalıbından, IBAN’ı da kalıbından ve kontrol hanelerinden bulur. Modele şu metin gider: “Adım MUSTERI_1. SIPARIS_1 numaralı sipariş için benden iki kez ücret aldınız. Beni TELEFON_1 numarasından arayın ya da fazla alınan tutarı IBAN_1 hesabına iade edin.” Model, MUSTERI_1 için mükerrer tahsilatın incelendiğini teyit eden bir özür taslağı hazırlar. Yerelde yer tutucuların yerine gerçek değerler konur, taslakta unutulmuş ya da uydurulmuş yer tutucu kalıp kalmadığı kontrol edilir ve bir temsilci taslağı inceleyip gönderir. Para iadesinin kendisi ayrı bir adımdır; onu ödeme sisteminde bir insan onaylar. Sağlayıcı şikayeti gördü; adı, numarayı ya da IBAN’ı görmedi.

Çıktıdaki her yer tutucu eşleştirmede bulunmalıdır; uydurulmuş bir TELEFON_2 ya da bozulmuş bir “Müşteri 1” taslağı durdurur. Türkçe ekler de yer tutucuya değil gerçek isme uyar: “Ayşe’nin” ama “Burak’ın”. Modelden yer tutuculara ek getirmemesini isteyin ya da ekleri, gerçek değerler yerine konduktan sonra düzeltin.

## Maskeleme nerede başarısız olur?

> Kaçırılan bir IBAN hata vermez. Maskeleme bu yüzden güvene değil teste ihtiyaç duyar.

- **Bağlam kimliği ele verir.** “En küçük depomuzda güvenlik şikayetini dile getiren depo müdürü” kimsenin adını anmaz ama birini tanımlar.
- **Serbest notlar** sağlık bilgilerini, aile durumlarını ve tuhaf biçimlerde yazılmış telefon numaralarını barındırır.
- **Taramalar, görseller ve ekler** tespitin okuduğu metnin dışında kişisel veri taşır. Önce OCR (optik karakter tanıma) ile okuyun ya da hiç göndermeyin; okuma tarafını [Türkçe belgeleri yapay zekayla okuma notumuz](https://veridive.com/tr/saha-notlari/turkce-ocr-ve-belge-okuma/) ele alıyor.
- **Aşırı maskeleme** görevin ihtiyaç duyduğu ürün adlarını, tarihleri ya da tutarları siler; bu yüzden yanıt kalitesini maskeleme açıkken ölçün.
- **Eşleştirme sızar.** Uygulama kayıtlarına yazılan bir eşleştirme tablosu maskelemeyi boşa çıkarır. Onu kayıtların dışında ve şifreli tutun, takvimine göre silin.

Maskeleme, birkaç önlemden yalnızca biridir; veriyi en aza indirme, sağlayıcının saklama koşulları, erişim kontrolü ve kayıt tutma da bu önlemler arasındadır. [Koruma önlemlerimiz](https://veridive.com/tr/nasil-calisiyoruz/#guardrails) kimin neye erişebildiği ve verinin nerede işlendiği sorusuyla başlar.

## Maskeleme nasıl test edilir?

Her tespit aracı gibi, etiketli örneklerle:

1. **Kendi biçimlerinizde bir test seti oluşturun:** e-postalar, sohbetler, temsilci notları, formlar ve OCR çıktıları; gerçek ya da gerçekçi sentetik veriler, güvenli bir ortamda. Her kişisel veri öğesini etiketleyin.
2. **Duyarlılığı varlık türü bazında ölçün.** Önemli olan hatalar kaçırılan öğelerdir.
3. **Kesinliği (precision) de ölçün,** çünkü aşırı maskeleme kaliteye zarar verir.
4. **Zor vakaları dahil edin:** büyük harfler, eksik Türkçe harfler, yaygın birer kelime olan isimler, boşluklarla bölünmüş IBAN’lar, Türkçe ile İngilizcenin karıştığı metinler.
5. **Her değişiklikte yeniden çalıştırın:** tespit araçları, biçimler ya da kanallar değiştiğinde.

**İş bittiğinde:** varlık türü başına duyarlılık, veri koruma görevlisiyle kararlaştırılan eşiği karşılar ve test otomatik olarak çalışır.

## Nereden başlamalı?

Güvenli bir ortamda, tek bir iş akışından alınmış yüz gerçek mesajdaki kişisel verileri etiketleyin ve tespit aracınızı bunların üzerinde çalıştırın; kaçırılanlar nereden başlayacağınızı gösterir. İşleme yerlerini ve erişim rollerini haritalamak ve sistemi verinizin kalması gereken yerde kurmak [veri ve yapay zeka altyapısı](https://veridive.com/tr/hizmetler/veri-ve-yapay-zeka-altyapisi/) çalışmamızın parçasıdır; hukuki sorular veri koruma görevlinizde kalır.

Bu not genel bilgi amaçlıdır; hukuki tavsiye değildir.

## Sık sorulan sorular

### Dil modelleri için kişisel veri maskeleme nedir?

Dil modelleri için kişisel veri maskeleme; isim, kimlik numarası, telefon numarası ve banka bilgileri gibi kişisel verileri tespit edip metin bir dil modeline gönderilmeden önce çıkarmak ya da değiştirmektir. Değerleri yer tutucularla değiştirmek modelin işini yapmaya devam etmesini sağlar; geri çevrilebilir yer tutucular ise gerçek değerlerin sonradan, model sağlayıcı onları görmeden, kendi sisteminizde geri konmasına olanak verir.

### KVKK veya GDPR kapsamında maskelenmiş veri hâlâ kişisel veri sayılır mı?

Bu teknik değil, hukuki bir sorudur; yanıtını veri koruma görevliniz ya da hukuk danışmanınız verir. Maskeleme model sağlayıcının gördüğünü azaltır; ancak bir eşleştirme tablosu ya da bağlamı aracılığıyla bir kişiye bağlanabilen verinin hâlâ kişisel veri sayılıp sayılmadığı mevzuata ve ayrıntılara bağlıdır. Maskeleme tasarımınızı onlara anlatın ve kararı onlara bırakın.

## Kaynaklar

1. 6698 sayılı Kişisel Verilerin Korunması Kanunu. Mevzuat Bilgi Sistemi. https://www.mevzuat.gov.tr/mevzuatmetin/1.5.6698.pdf
2. Tüzük (AB) 2016/679 (Genel Veri Koruma Tüzüğü, GDPR), resmi metin. EUR-Lex. https://eur-lex.europa.eu/eli/reg/2016/679/oj
3. Üretken Yapay Zekâ ve Kişisel Verilerin Korunması Rehberi (15 Soruda). Kişisel Verileri Koruma Kurumu (KVKK). https://www.kvkk.gov.tr/Icerik/8547/uretken-yapay-zeka-ve-kisisel-verilerin-korunmasi-rehberi-15-soruda