--- title: "Kazınan Verilerde Kişisel Veri (PII) Nasıl Yönetilir?" description: "Kazınan veriler çoğu zaman kişisel veri taşır: adlar, profil linkleri, metindeki e-posta ve telefonlar. Bunları bulma, azaltma, maskeleme ve saklama yolları." url: https://proxynet.io/tr/blog/personal-data-in-scraped-datasets date: 2026-09-28 author: "Acar Diveroli" category: "Web Scraping, Proxy 101" lang: tr --- # Kazınan Verilerde Kişisel Veri (PII) Nasıl Yönetilir? En sık hangi şikâyetlerin dile getirildiğini görmek için 20.000 ürün yorumunu kazıdığınızı düşünün. Plan, yalnızca puanları ve yorum metinlerini almaktı. CSV dosyasını açtığınızda ise yorum yazarlarının adlarını, profil sayfalarının linklerini ve birkaç yüz yorumda yazarın metne kendi eliyle eklediği bir e-posta adresini ya da telefon numarasını da görüyorsunuz. Bunların hiçbiri analize katkı sağlamıyor; ama artık hem dizüstü bilgisayarınızda hem de dün geceki yedekte duruyor. Bu yazıda, kazınan bir veri setinde neyin kişisel veri (İngilizce kaynaklarda sık geçen adıyla PII, yani "personally identifiable information") sayıldığını, "zaten herkese açıktı" demenin konuyu neden kapatmadığını ve bu verinin nasıl ele alınacağını anlatıyoruz: daha az toplamak, gözden kaçanı maskelemek, ihtiyaç duyduğunuz anahtarları takma adlandırmak ve belirli bir takvime göre silmek. Bir e-postanın hash'ini almanın göründüğünden neden daha zayıf bir koruma olduğunu da gösteriyor, test edilmiş bir Python maskeleme betiği paylaşıyor ve GDPR'daki, KVKK'daki ve Kaliforniya'nın CCPA düzenlemesindeki ilgili maddelere değiniyoruz. > **Not: Kısa cevap** > > Kimliği belirli ya da belirlenebilir bir kişiye ilişkin her bilgi kişisel veridir; bu veriyi herkese açık bir sayfadan kazımak, GDPR'a göre de KVKK'ya göre de bunu değiştirmez. Önce amacı belirleyin ve yalnızca bu amaca hizmet eden alanları toplayın. İhtiyacınız olmayan adları ve profil linklerini atın, serbest metindeki e-posta ve telefon numaralarını veri içeri alınırken maskeleyin, saklamak zorunda olduğunuz kimlikleri anahtarlı bir hash ile değiştirin, depolamayı şifreleyip erişimi kısıtlayın ve ham dosyaları sabit bir takvime göre silin. Takma adlandırılmış veri hâlâ kişisel veridir; yalnızca artık hiç kimseyle ilişkilendirilemeyen veri anonimdir. > **Uyarı: Bu bir hukuki tavsiye değildir** > > Bu yazı teknik uygulamaları anlatır ve mevzuata yalnızca yol göstermesi için atıf yapar. Belirli bir veri setini toplayıp kullanıp kullanamayacağınız; amacınıza, hukuki dayanağınıza, sitenin kullanım koşullarına ve işin içindeki ülkelere bağlıdır. Gerçek bir proje için kişisel verilerin korunması alanında uzman bir avukata ya da şirketinizin veri koruma görevlisine danışın. ## Kazınan bir veri setinde ne kişisel veri sayılır? GDPR'ın [4. maddesinin 1. bendindeki](https://eur-lex.europa.eu/eli/reg/2016/679/oj/eng) tanım geniştir: kimliği belirli ya da doğrudan veya dolaylı olarak belirlenebilir bir gerçek kişiye ilişkin her türlü bilgi. Madde ayrıca ad, kimlik numarası, konum verisi ve çevrim içi tanımlayıcı gibi örnekler sayar. 6698 sayılı Kişisel Verilerin Korunması Kanunu (KVKK) da 3. maddesinde özünde aynı tanımı kullanır: kimliği belirli veya belirlenebilir gerçek kişiye ilişkin her türlü bilgi. Bir veri kazıma projesinde kişisel veri üç yerde karşınıza çıkar: - **Bilerek seçtiğiniz alanlar.** Yazar adları, kullanıcı adları, profil URL'leri, avatarlar, şirket sayfalarındaki unvanlar, pazaryerlerindeki satıcı adları. - **Serbest metin.** İnsanların e-posta adresini, telefon numarasını, sokak adını ya da araç plakasını yazdığı yorumlar, forum gönderileri ve ilan açıklamaları. - **Kendi loglarınız.** İstek logları ve hata dökümleri çoğu zaman sayfanın tüm HTML'ini, yani yukarıdakilerin hepsini saklar. Fark edilmesi daha zor olanlar ise tek başına kimseyi tanımlamayan alanlardır. Bir kullanıcı adı, bir şehir, bir tarih ve nadir bir ürün bir araya geldiğinde tek bir kişiyi gösterebilir. Bu nedenle "ad" sütunu olmayan bir veri seti de kişisel veri içerebilir. ## Herkese açık olması serbestçe kullanılabileceği anlamına mı gelir? Genel olarak hayır; cevap da mevzuata göre değişir. - **GDPR.** Herkese açık kişisel veriler için bir istisna yoktur. Kazınan verinin de bir hukuki dayanağı olmalı ve 5. maddedeki ilkelere uyulmalıdır. 14. madde, verisini doğrudan kendisinden değil başka bir kaynaktan elde ettiğiniz kişilere karşı bilgilendirme yükümlülüklerinizi düzenler. - **KVKK.** 5. madde, açık rıza aranmadan işleme yapılabilecek şartları sayar. Bunlardan biri, verinin ilgili kişinin kendisi tarafından alenileştirilmiş olmasıdır. Ancak bu sınırsız bir izin değildir: 4. maddedeki belirli, açık ve meşru amaçlar için işleme ile amaçla bağlantılı, sınırlı ve ölçülü olma gibi ilkeler yine geçerlidir. - **CCPA.** Kaliforniya Medeni Kanunu'nun [1798.140. bölümündeki](https://leginfo.legislature.ca.gov/faces/codes_displaySection.xhtml?lawCode=CIV§ionNum=1798.140) kişisel bilgi tanımı, IP ve e-posta adreslerini tanımlayıcılar arasında sayar; ardından "publicly available" (kamuya açık) bilgiyi kapsam dışında bırakır. Ancak bu kavramı dar tanımlar: örneğin kamu kayıtları ya da tüketicinin genel kamuoyuna açtığı bilgiler. Kullanım koşulları ve telif hakkı dahil daha geniş hukuki çerçeveyi [Web Scraping (Web Kazıma) Yasal mı?](/tr/blog/web-scraping-legal) yazısında ele aldık. ## Kazıma sürecinde kişisel veri nasıl ele alınır? GDPR'ın 25. maddesi "tasarım yoluyla ve varsayılan olarak veri koruma" ister: güvenceler en sonda yapılacak bir temizlik işi değil, tasarımın bir parçası olmalıdır. Bir scraper için bu şu anlama gelir: 1. **Amacı yazıya dökün.** "Ürün başına en sık görülen teslimat şikâyetlerini bulmak" bir amaçtır. "İşe yarar diye yorumları toplamak" bir amaç değildir. 2. **Amaca hizmet eden alanları listeleyin.** Yukarıdaki örnek için: ürün, tarih, puan, metin. Yazar adı ve profil URL'si bu listede yok. 3. **Toplama aşamasında filtreleyin.** Kullanmayacağınız alanı hiç seçmeyin. 4. **Serbest metni içeri alırken maskeleyin.** Satır herhangi bir yere yazılmadan önce e-posta ve telefon numaralarını yer tutucularla değiştirin. 5. **İhtiyaç duyduğunuz anahtarları takma adlandırın.** Tekrar yorum yazan kişileri saymanız gerekiyorsa yazar kimliği yerine onun anahtarlı hash'ini saklayın. 6. **Anahtarı ayrı tutun.** Takma adlandırma anahtarı veri setinde ya da aynı depoda değil, bir gizli bilgi yöneticisinde (secrets manager) veya ortam değişkeninde durmalıdır. 7. **Depolamayı güvenli hâle getirin.** Veriyi diskte şifreleyin, erişimi projede çalışan kişilerle sınırlayın ve ham dökümleri ortak sürücülerden uzak tutun. 8. **Takvime göre silin.** Ham HTML ve maskelenmemiş dosyalar kısa bir saklama süresine tabi olsun; temizlenmiş veri setinin de amaca bağlı kendi saklama süresi olsun. 9. **Yaptıklarınızı kayda geçirin.** Amacı, alanları, saklama süresini ve hukuki dayanağı kısa bir notta toplayın. ## Maskeleme, takma adlandırma ve anonim hâle getirme arasındaki fark Bu terimler birbirinin yerine kullanılamaz ve aralarındaki fark, verinizin hâlâ mevzuat kapsamında olup olmadığını belirler. | Teknik | Ne yapar? | Kişi yeniden tanımlanabilir mi? | Hâlâ kişisel veri mi? | |---|---|---|---| | Toplama anında silme | Alan hiç saklanmaz | Hayır, veri mevcut değil | O alan için hayır | | Maskeleme | Değeri `[EMAIL]` gibi bir yer tutucuyla değiştirir | Maskelenmiş değerden hayır, ama diğer alanlardan belki | Satırda kalan bilgiye bağlı | | Takma adlandırma (pseudonymization) | Tanımlayıcıyı bir token ile değiştirir; bağlantıyı kuran bilgi ayrı ve korunan bir yerde durur | Evet, anahtar ya da eşleme tablosuyla | Evet (GDPR 26. gerekçe) | | Anonim hâle getirme | Veriyi, makul ölçüde kullanılabilecek araçlarla kimse tanımlanamayacak hâle gelene kadar siler veya genelleştirir | Hayır | Hayır | | Şifreleme | Veriyi anahtar olmadan okunamaz kılar | Evet, anahtara sahip olan herkes için | Evet | | Toplulaştırma | Yalnızca sayıları, ortalamaları veya grupları tutar | Yalnızca gruplar çok küçükse | Gruplar yeterince büyükse genellikle hayır | ### GDPR takma adlandırma hakkında ne diyor? 4. maddenin 5. bendi takma adlandırmayı, kişisel verilerin ek bilgi kullanılmadan artık belirli bir veri sahibine atfedilemeyecek şekilde işlenmesi olarak tanımlar; şartı da bu ek bilginin ayrı tutulması ve korunmasıdır. 26. gerekçe (Recital 26) ise sınırı çizer: ek bilgiler kullanılarak bir kişiye atfedilebilecek takma adlandırılmış veriler, kimliği belirlenebilir bir gerçek kişiye ilişkin bilgi olarak kabul edilmelidir. Anonim bilgiler ise tüzüğün kapsamı dışındadır. Birinin kimliğinin belirlenebilir olup olmadığına karar verirken 26. gerekçe, maliyet, zaman ve mevcut teknoloji dahil makul ölçüde kullanılması muhtemel tüm araçların hesaba katılmasını ister. Kazınan metni anonim hâle getirmenin zor olmasının nedeni budur: yorum hâlâ kasabayı, tarihi ve araç modelini anıyorsa adı silmek pek işe yaramaz. Avrupa Veri Koruma Kurulu (EDPB), [takma adlandırmaya ilişkin 01/2025 sayılı Kılavuzu](https://www.edpb.europa.eu/our-work-tools/documents/public-consultations/2025/guidelines-012025-pseudonymisation_en) Ocak 2025'te kabul etti. Avrupa Komisyonu'nun Kasım 2025 tarihli "Digital Omnibus" teklifi, kişisel veri tanımının takma adlandırılmış verilere nasıl uygulanacağını değiştirecek; Avrupa Parlamentosu'nun [yasama süreci sayfasına](https://www.europarl.europa.eu/legislative-train/theme-a-new-plan-for-europe-s-sustainable-prosperity-and-competitiveness/file-digital-package) göre bu yazı yazıldığında teklif henüz kabul edilmemişti. Bir değişiklik yürürlüğe girene kadar takma adlandırılmış veriyi kişisel veri olarak ele alın. KVKK takma adlandırmayı tanımlamaz. 3. maddesi anonim hâle getirmeyi, kişisel verilerin başka verilerle eşleştirilerek dahi hiçbir surette kimliği belirli veya belirlenebilir bir gerçek kişiyle ilişkilendirilemeyecek hâle getirilmesi olarak tanımlar. 7. madde de işlenmesini gerektiren sebepler ortadan kalktığında kişisel verilerin silinmesini, yok edilmesini veya anonim hâle getirilmesini şart koşar. ## Bir e-postanın hash'ini almak neden anonim hâle getirme değildir? Sık başvurulan bir kestirme, `sha256(email)` çalıştırıp sütunu anonim ilan etmektir. Oysa iki nedenle anonim değildir. Birincisi, hash her seferinde aynı çıkar. Elinde bir e-posta listesi olan herkes, örneğin bir veri ihlalinde sızmış bir listeye sahip olan biri, listedeki her adresin hash'ini alıp eşleşme arayabilir; bizim testimizde iki maddelik bir tahmin listesi "anonim" adresi hemen buldu. Aynı sızmış listeler [credential stuffing](/tr/blog/what-is-credential-stuffing) saldırılarını da besler; bu da ihtiyacınız olmayan ham e-postaları saklamamak için bir neden daha. İkincisi, bazı tanımlayıcıların arama uzayı küçüktür. Bir ülkedeki telefon numarası sınırlı sayıda haneden oluşur; bu aralıktaki olası tüm numaraların hash'ini almak sıradan donanımla yapılabilir ve eşleşen token numarayı geri verir. Daha iyi sonuç veren yöntemler: - **Gizli bir anahtarla anahtarlı hash (HMAC).** Anahtar veriden ayrı saklanır. Sonuç anonim değil, takma adlandırılmış veridir. - **Rastgele token ve eşleme tablosu.** Eşlemeyi geri çevirmeniz gerekiyorsa tablo ayrı yerde saklanır. - **Hiç tanımlayıcı tutmamak.** Yalnızca sayılara ihtiyacınız varsa önce toplulaştırın, sonra anahtarı atın. ## Python örneği: e-posta ve telefon numaralarını maskelemek Betik, kazınmış yorumları içeren bir CSV dosyasını okur ve temizlenmiş bir kopyasını yazar: gereksiz sütunları atar, serbest metin sütunundaki e-posta ve telefon numaralarını maskeler, tekrar yorum yazanlar yine de sayılabilsin diye yazar kimliğini anahtarlı bir hash ile değiştirir. Yalnızca standart kütüphaneyi kullanır; Python 3.13 ile test edildi. ```python import csv import hashlib import hmac import os import re # Analizde hiç ihtiyaç duymadığımız sütunlar: içeri alırken atılır DROP_COLUMNS = {"author_name", "profile_url"} # Yalnızca takma ad olarak tuttuğumuz sütun: tekrar yorum yazanları saymak için PSEUDONYM_COLUMN = "author_id" # İnsanların iletişim bilgisi yazdığı serbest metin sütunları; yapılandırılmış sütunlara dokunulmaz TEXT_COLUMNS = {"text"} EMAIL_RE = re.compile(r"[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,}") # Telefona benzeyen diziler: isteğe bağlı + veya ( ile başlar, aralarında boşluk, nokta, tire ya da parantez olabilen 9-15 hane PHONE_RE = re.compile(r"(? str: text = EMAIL_RE.sub("[EMAIL]", text) return PHONE_RE.sub("[PHONE]", text) def pseudonym(value: str) -> str: # Anahtarlı hash (HMAC-SHA256): anahtar olmadan kimse tahminlerin hash'ini alarak eşlemeyi yeniden kuramaz return hmac.new(SECRET, value.encode(), hashlib.sha256).hexdigest()[:16] def clean_row(row: dict) -> dict: out = {} for col, value in row.items(): if col in DROP_COLUMNS: continue if col == PSEUDONYM_COLUMN: out[col] = pseudonym(value) elif col in TEXT_COLUMNS: out[col] = mask_text(value) else: out[col] = value return out def main(src: str, dst: str) -> None: if not SECRET: raise SystemExit("Set PSEUDONYM_KEY first") with open(src, newline="", encoding="utf-8") as f_in, \ open(dst, "w", newline="", encoding="utf-8") as f_out: reader = csv.DictReader(f_in) fields = [c for c in reader.fieldnames if c not in DROP_COLUMNS] writer = csv.DictWriter(f_out, fieldnames=fields) writer.writeheader() for row in reader: writer.writerow(clean_row(row)) if __name__ == "__main__": main("reviews_raw.csv", "reviews_clean.csv") ``` Betiği, anahtarı ortam değişkenine atadıktan sonra (Linux ve macOS'ta `export PSEUDONYM_KEY=...`, PowerShell'de `$env:PSEUDONYM_KEY="..."`) `python mask_pii.py` komutuyla çalıştırın. Uydurma örnek verimizde "Beni +90 532 000 00 00 veya (0212) 000-0000 numarasından arayın" cümlesi "Beni [PHONE] veya [PHONE] numarasından arayın" oldu, e-postalar `[EMAIL]` ile değişti ve aynı yazarın iki yorumu aynı token'ı aldı. Sınırları bilin: - **Düzenli ifade gereğinden fazlasını yakalar.** Testlerimizde telefon deseni 13 haneli bir ISBN'i, 10 haneli bir sipariş numarasını ve saatle bitişik yazılmış bir tarihi de maskeledi. Betiğin yalnızca serbest metin sütunlarına dokunmasının nedeni bu. - **Düzenli ifade bazılarını da kaçırır.** Yazıyla yazılmış numaralar, "ad at alanadi nokta com" gibi yazımlar, IBAN'lar, adresler ve metin içindeki adlar yakalanmaz; bunlar için bir varlık tanıma (NER) modeli ya da bir örneklem üzerinde elle kontrol gerekir. - **Maskeleme anonim hâle getirme değildir.** Satırda metin, tarih ve ürün kalır; bunların tek başına bir kişiyi gösterip gösteremeyeceğini kontrol edin. Bu adımı sonradan çalışan bir iş olarak değil, satırların ilk yazıldığı yerde çalıştırın. [pandas ile veri temizleme rehberi](/tr/blog/clean-scraped-data-with-pandas) bu adımın eksiksiz bir temizlik sürecinde nereye oturduğunu gösteriyor; [kazınan veriyi CSV, JSON ve SQLite'a kaydetme](/tr/blog/save-scraped-data-csv-json-sqlite) yazısı da depolama tarafını anlatıyor. ## Depolama güvenliği, erişim ve saklama süresi GDPR'ın 32. maddesi riske uygun bir güvenlik düzeyi ister ve bunun için takma adlandırma ile şifrelemeyi, dayanıklı sistemleri, bir olaydan sonra verinin geri yüklenebilmesini ve düzenli testleri sayar. KVKK'nın 12. maddesi de veri sorumlusuna benzer bir veri güvenliği yükümlülüğü getirir. Bir scraper için bu şunları gerektirir: - **Diskte şifreleme.** Ham kazıma verilerini tutan diskler, bucket'lar ve veritabanları şifrelenmeli. - **Ayrı bölgeler.** Ham HTML ve maskelenmemiş satırlar erişimi kısıtlı tek bir yerde; temizlenmiş veri seti ise analistlerin çalıştığı yerde durmalı. - **Asgari erişim.** Ham bölgeyi yalnızca ona gerçekten ihtiyaç duyan kişiler ve servis hesapları okuyabilmeli. - **Kod olarak saklama süresi.** Zamanlanmış bir silme işi, bir politika belgesinden daha etkilidir. - **Yedekler de sayılır.** Bir yıl önce alınmış bir yedekte duran dosya silinmiş sayılmaz. Verinin ve yedeklerin saklama sürelerini birbiriyle uyumlu hâle getirin. [Veri güvenliği](/tr/data-security) sayfamız proxy'lerin güvenlik çalışmalarındaki yerini anlatıyor; bir proxy isteğin çıktığı IP adresini değiştirir, sakladığınız veriyi değil. ## Bu konu nerelerde karşınıza çıkar? - **Fiyat ve stok takibi.** Ürün sayfalarında nadiren kişisel veri bulunur, ancak pazaryerlerindeki satıcı adları kişisel veri olabilir. Bkz. [rakip fiyat takibi](/tr/blog/competitor-price-tracking). - **Yorum ve duygu analizi.** Yazar alanları ve metin içindeki iletişim bilgileri. Bkz. [pazar araştırması](/tr/market-research). - **Araştırma ve veri madenciliği.** Forum gönderileri kişisel veriyle doludur; toplulaştırmayı erken yapın. Bkz. [Veri Madenciliği Nedir?](/tr/blog/what-is-data-mining) - **Büyük taramalar.** Genel amaçlı bir [web crawler](/tr/web-crawler) sayfaların tamamını toplar; filtrelemezseniz sayfadaki her şey depolamanıza düşer. - **Potansiyel müşteri listeleri.** Kişilere ulaşmak amacıyla bireylerin iletişim bilgilerini toplamak, burada sayılanlar arasında en yüksek riskli durumdur; önce mevzuatı ve sitenin kullanım koşullarını kontrol edin. ## Sık yapılan hatalar - "Ne olur ne olmaz" diye sayfanın tamamını kazıyıp ham dökümü süresiz olarak depoda bırakmak. - Bir e-postanın SHA-256 hash'ine "anonim hâle getirilmiş" demek. - Takma adlandırma anahtarını veriyle aynı depoda ya da bucket'ta saklamak. - Analiz tablosunu maskeleyip logları, hata dökümlerini ve hata ayıklama için saklanan HTML'i unutmak. - Veri "zaten herkese açık" diye `robots.txt` dosyasını ve sitenin kullanım koşullarını görmezden gelmek. [robots.txt](/tr/blog/robots-txt), site sahibinin tarayıcıların neyi çekmesine izin verdiğini söyler. - Silme işinin sorumlusu olmadığı için veriyi proje bittikten sonra da saklamak. - Veri setindeki kişiler başka ülkelerde yaşarken yalnızca kendi ülkenizin kurallarının geçerli olduğunu varsaymak. ## Karar rehberi | İhtiyaç | Öneri | |---|---| | Fiyat, stok ya da ürün verisi analizi | Satıcı ve kullanıcı alanlarını hiç toplamayın | | Yorum veya görüşlerin metin analizi | Yazar alanlarını atın, metindeki iletişim bilgilerini içeri alırken maskeleyin | | Tekrar yazan yazarları saymak ya da bir hesabı zaman içinde izlemek | Kimliğin anahtarlı hash'i (HMAC), anahtar ayrı yerde | | Veri setini bir müşteriyle paylaşmak ya da yayımlamak | Önce toplulaştırın, sonra küçük grupları ve nadir kombinasyonları kontrol edin | | Hata ayıklama için ham HTML saklamak | Kısa saklama süresi, erişimi kısıtlı bölge, şifreleme | | Amaç bireylerin iletişim bilgilerinin kendisi | Durun ve toplamadan önce hukuki destek alın | ## Sıkça sorulan sorular ### Kazınan herkese açık veriler GDPR'dan muaf mı? Hayır. GDPR'da herkese açık kişisel veriler için genel bir muafiyet yoktur. Yine bir hukuki dayanağa ihtiyacınız vardır, 5. madde yine geçerlidir ve 14. madde, verisini doğrudan kendisinden toplamadığınız kişilere karşı bilgilendirme yükümlülüğünüzü düzenler. ### IP adresi kişisel veri midir? Olabilir. GDPR 4. maddenin 1. bendinde çevrim içi tanımlayıcıları sayar; CCPA da "Internet Protocol address" (IP adresi) ifadesini tanımlayıcı örnekleri arasında anar. Veri kazımada bu konu en çok kendi loglarınız açısından önem taşır. ### Hash almak veriyi anonim hâle getirir mi? Hayır. Bir e-postanın ya da telefon numarasının düz hash'i, bir tahmin listesinin hash'leri alınarak geri çözülebilir. Başka yerde saklanan gizli bir anahtarla alınan anahtarlı hash ise takma adlandırmadır ve GDPR bunu hâlâ kişisel veri olarak kabul eder. ### KVKK, kişinin kendisinin alenileştirdiği veriler hakkında ne diyor? 5. madde, verinin ilgili kişinin kendisi tarafından alenileştirilmiş olması hâlinde açık rıza aranmadan işlenmesine izin verir. Ancak 4. maddedeki belirli, açık ve meşru amaçlar ile ölçülülük gibi ilkeler yine geçerlidir. ### Kazınan kişisel verileri ne kadar süre saklayabilirim? Yalnızca amacın gerektirdiği süre kadar. GDPR'ın 5. maddesi buna "saklamanın sınırlandırılması" der; KVKK'nın 7. maddesi de işlenmesini gerektiren sebepler ortadan kalktığında verinin silinmesini, yok edilmesini veya anonim hâle getirilmesini şart koşar. ### Proxy kullanmak yükümlülüklerimi değiştirir mi? Hayır. Proxy, istekleri farklı bir IP adresi üzerinden yönlendirir. Neyi topladığınızı, nerede sakladığınızı ya da hangi mevzuatın uygulanacağını değiştirmez. ## Özet Kazınan bir veri setine kişisel veri nadiren biri onu istediği için girer; çoğu zaman sayfayla birlikte gelir. Çözüm büyük ölçüde mühendislik işidir: amacı belirleyin, yalnızca ona hizmet eden alanları toplayın, serbest metne sızanı maskeleyin, anahtarları başka yerde saklanan bir sırla takma adlandırın, depolamayı şifreleyin ve takvime göre silin. Takma adlandırılmış veri GDPR'a göre hâlâ kişisel veridir; anonim veri ise makul ölçüde kullanılabilecek araçlarla kimsenin tanımlanamadığı veridir. Toplama tarafı için [veri kazıma](/tr/data-scraping) sayfamıza bakın: [Residential Proxy](https://proxynet.io/tr/residential-proxy) adresleri ülke ve şehir hedefleme sunar, [Rotating Proxy](https://proxynet.io/tr/rotating-proxy) istekleri farklı IP'lere dağıtır, [proxy](/tr/proxy) sayfamız da tüm ürünleri listeler.