2026'da Web Scraping'in Yasal Durumu: Mahkeme Davaları, GDPR, 152-FZ ve Uygulamalar

Giriş: Neden İş Dünyasının 2026'da Web Scraping'in Yasal Çerçevesini Anlaması Gerekiyor

Web scraping, mühendislerin aracından veri yönetimi için stratejik bir disipline dönüştü. 2026 yılında yasallığı yalnızca teknolojilerle değil, uluslararası hukukun nüanslarıyla belirleniyor: ABD'deki mahkeme kararları, GDPR'nin Avrupa'daki uygulanma pratikleri, Rus yasal düzenlemeleri (152-FZ) ve Roskomnadzor'un pozisyonu. Bu nedenle, aynı eylem bir yargı alanında yasal, diğerinde koşullu olarak uygun ve üçüncüsünde riskli olabilir. Bu rehber, yasal alanda güvenle yönelmenizi, "tasarım gereği" uyum sağlamanızı, riskleri minimize etmenizi ve açık verilerden maksimum değer elde etmenizi sağlayacak — düzenleyicilerle ve hak sahipleriyle çatışma yaşamadan.

Elinize geçecekler: veri kategorilerinin yasal anlamını sistematik olarak anlama; güncel içtihat incelemesi (son yıllardaki hiQ vs LinkedIn davası dahil), Avrupa düzenleyicilerinin ve Rus mahkemelerinin uygulamaları; yasallık değerlendirmeleri için net çerçeveler; süreçleri yapılandırmak için adım adım talimatlar; kontrol listeleri; araçlar; gerçek vaka çalışmaları ve yaygın hatalar. Basit bir dille ama profesyonel bir derinlikle konuşuyoruz ki, doğru uygulamaları bugünden hayata geçirebilesiniz.

Önemli Not: Bu materyal genel hukuki bilgi ve analitik öneriler sunmaktadır. Hukuki danışmanlık değildir ve bir müşteri-avukat ilişkisi oluşturmaz. Karar almadan önce, sektörünüz ve yargı alanlarınızla ilgili bilgili bir avukatla danışmanızı öneririz.

Temeller: Web Scraping Nedir ve Hukuk Verilere Nasıl Bakıyor

Anahtar Terimler ve Hukuki Anlamları

• Web Scraping — Halka açık HTML sayfalarından veya API’lerden otomatik veri çıkarımı. Hukuken önemli olan: erişim şekli (halka açık/kısıtlı), teknik engellerin varlığı, kullanım koşulları.
• Açık Veriler — İnsan tarafından okunmak için engel olmaksızın erişilebilen veriler. Önemli: "açıklık", telif hakkı, yan haklar, veri tabanı hakları ve kişisel veri gerekliliklerini ortadan kaldırmaz.
• Kişisel Veriler (KV) — AB/EEA'da GDPR kapsamında, tanımlanmış veya tanımlanabilir bir kişi ile ilgili her türlü bilgi. RF'de 152-FZ uyarınca — doğrudan veya dolaylı olarak Rusya Federasyonu vatandaşı ile ilgili her türlü bilgi.
• Halka Açık KV — AB'de: bir kişi veya üçüncü taraf tarafından yayınlanan kişisel veriler; tüm hukuki gereksinimlerin tam setine tabi olmaya devam ederler. RF'de: 2021 yılı değişiklikleri sonrasında yaygın olarak yayımlanmış veriler için ayrı bir onay gerekmekte; yayının durumunun serbest kullanımı ifade etmediğini belirtir.
• Kullanım Şartları (ToS) — Bir web sitesi veya API'nin sözleşmeli hükümleri. İhlali, medeni hukuki sonuçlar doğurur ve bazı yargı alanlarında, teknik önlemleri aşmakla ilgili normlarla ilişkilendirilebilir.
• robots.txt — Web robotları için öneriler içeren dosya. İndeksleme ve engel aşma için teknik kurallar içerir. Çoğu yargıda kendiliğinden yasal güç taşımaz, ancak ihmal edilmesi riski artırabilir (kötü niyetliliği ispatlar).
• API vs HTML — API üzerinden erişim genellikle lisanslı ve yapılandırılmıştır, HTML scraping halka açık arayüze odaklanır. Hukuki açıdan API daha avantajlıdır, fakat sözleşme sınırlamaları daha katıdır.

Temel Hukuki Değerlendirme Eksenleri

• Yargı Alanı: Siz, sunucular, kullanıcılar ve veri sahiplerinin nerede bulunduğu.
• Veri Türü: Kişisel/kişisel olmayan; ticari sırlar; telif ve yan haklar; veri tabanı hakları (AB'de).
• Erişim Yöntemi: Kayıt olmadan halka açık sayfa vs giriş gerektiren sayfa, captcha ve paywall aşmak, oturum kullanımı.
• İşlem Amacı: Gazetecilik, araştırma, uyum, rekabet, ticari analiz, güvenlik.
• Hacim ve Sıklık: "makul" tekil nesnelerin çıkarımı vs esaslı bir kısmın sistematik kopyalanması.

Derinlemesine İnceleme: Küresel Hukuki Çerçeveler ve Trendler

ABD: hiQ vs LinkedIn Davası ve İlgili Pozisyonlar

hiQ vs LinkedIn vakası, yıllar boyunca halka açık profillerin scrapingi konusundaki tartışmaya yön vermiştir. 2024 sonu itibarıyla, mahkeme makamları onaylamıştır ki, kimlik doğrulama aşılmadan genel sayfalara erişim, Amerikan Bilgisayar Dolandırıcılığı Yasası (CFAA) anlamında "yetkisiz erişim" anlamına gelmez, özellikle Van Buren davasının referans etkisi sonrasında. Ancak diğer hukuki kollar da mevcuttur: ToS çerçevesinde sözleşmeli talepler, veri tabanı ve içerik koruması, kötü niyetli rekabet, trespass to chattels ve diğer teoriler. Birçok yüksek profilli anlaşmazlık, uzlaşmalarla ve/veya platform uygulamalarında netleştirmelerle sonuçlanmıştır. 2025-2026 yıllarında, iş dünyası benzer davalardaki herhangi yeni gelişmeyi federal mahkemelerde takip etmelidir, ancak genel olarak halka açık sayfalar için temel çizgi CFAA'nın "sadece okuma" durumunda genişletilmeden uygulandığıdır.

Pratik Çıkarım: ABD'de kimlik doğrulama aşılmadan halka açık sayfaların scraping'i, bir bilgisayar suçu değildir. Ancak ToS'nun ihlali ve resmi protokollerin (robots.txt dahil) ihmal edilmesi medeni hukuki riskleri artırabilir ve özellikle kapsamlı kopyalama veya ticari parazitleme durumunda mahkemeye yol açabilir.

AB/EEA: GDPR, ePrivacy ve Veri Tabanı Hakları

• GDPR: Halka açık kaynaklardan alınan herhangi bir kişisel veri KV olarak kalır. Yasal bir temele ihtiyaç vardır (çoğunlukla "meşru menfaat"), madde 14 uyarınca bilgilendirme (veya muafiyetin gerekçesi), minimize etme, saklama süreleri, güvenlik ve veri sahiplerinin hakları için mekanizmalar. Düzenleyiciler (örn. CNIL, İrlanda DPC ve diğerleri) defalarca vurgulamıştır: "halka açık" olmak, "kontrolsüz" olduğu anlamına gelmez. İlkeler ihlal edildiğinde, büyük cezalarla sonuçlanıyor; toplu veri sızıntılarının ve scraping'in neden olduğu izinsiz profilleme gibi araştırmalar gösteriyor.
• Düzenleyici Kararlar: Avrupa denetleyicileri, yetersiz bir scraping korumasından dolayı büyük cezalar kesmiştir (yayınlanan verilere yönelik "privacy by design" eksikliğinden dolayı) ve scrapingciler tarafından yasadışı sonraki işleme konusuna da ceza verilmiştir. Halka açık görüntü ve sayfalar üzerinden biyometrik ve davranışsal profiller oluşturan hizmetler üzerinde yapılan uygulama, belirsiz işleme ve yasal temelin yokluğuna karşı sert bir yaklaşım sergilemektedir.
• Sui generis Veri Tabanı Hakları (96/9/EC Tüzüğü): Önemli bir kısmın çıkarımını veya tekrar kullanımını yasaklar, ayrıca esaslı bir kısmın sistematik çıkarımını zarar vermekle yasaklar. AB Adalet Divanı'nın temel davaları, ekonomik değeri artıran meta arama motorları ve veri tabanının kopyaları üzerindeki yasağı vurgular. Bu, başkalarının veri tabanını "yansıtarak" bir ürün inşa eden projeler için kritik öneme sahiptir.

Rusya: 152-FZ ve Roskomnadzor'un Pozisyonu

Rusya'da, tanımlanabilir bir kişiyle ilgili her türlü bilgi kişisel veridir. 2021 yılı düzenlemeleri, "halka açık KV" rejimini sertleştirmiştir: bunların dağıtımı için ayrı bir onay gereklidir ve erişim koşullarını ayarlama imkanı vardır. Böyle verileri toplayan bir agregatör, KV operatörü haline gelerek tüm yükümlülükleri taşır: amaçlar, yasal nedenler, Roskomnadzor'a bildirim (gerektiğinde), yerelleştirme (242-FZ), veri sahiplerinin hakları, güvenlik.

Rusya'da mahkeme uygulamaları ve denetim, internet üzerindeki bilginin yayılmasının "serbest lisans" oluşturmadığı anlayışını benimsemektedir. Kişisel verilerin izinsiz scraping'i ve agregatörlerde yayınlanması, mahremiyet korunması taleplerine, Roskomnadzor'un talimatlarına ve idari cezalara yol açmaktadır. Kişisel olmayan veriler için anahtar konular, telif hakkı, ticari sırlar ve kötü niyetli rekabet olmayı sürdürmektedir. Teknik kısıtlamaların ihlali ve korunmanın aşılması, hukuksuz erişimle ilgili ceza normlarına girebilir.

Robots.txt, ToS, API: Hukuk Teknik ve Sözleşme Sinyallerine Nasıl Bakıyor

• robots.txt: çoğunlukla hukuken teknik bir politika olarak yorumlanır, ancak yasada kelime anlamında bir yasak değildir. Ancak kanıt açısından önemlidir: ihmal edilmesi, açık kuralları aşma niyetini gösterebilir ve ToS ile captcha'lar ile birlikte, bir anlaşmazlığın kaybedilme ihtimalini artırır.
• ToS: AB'de ToS ihlali bir sözleşme meselesidir; ABD'de medeni dava riski (sözleşme, tort). RF'de bu, kamuya açık teklif/sözleşme olarak nitelenir. Anahtar: ToS ile kabul edip etmediğiniz (kabul), iletişimin nasıl kaydedildiği ve kötü niyetli kullanıma dair bir gerekçe olup olmadığı.
• API: lisans anlaşmaları ve rate limitler net hukuki çerçeveler oluşturur. Artılar: veri öngörülebilirliği ve kalitesi. Eksiler: hacim ve amaç sınırları. API limitlerini aşma girişimleri, HTML scraping veya proxy kullanımı, genellikle riskleri artırır.

2026 Trendleri

• Platformların "care duty" üzerindeki odaklanması: Düzenleyiciler, web site sahiplerinden kişisel verilerin yasadışı scraping'ini önlemeleri ve riskler hakkında kullanıcıları bilgilendirmeleri konusunda beklentileri artırıyor.
• Verilerin yerelleştirilmesi ve egemenliği: KV'lerin yerel olarak saklanmasına yönelik daha fazla gereklilik ve sınır ötesi aktarımın kısıtlanması.
• Veri tedarik zincirinin şeffaflığı: kaynaklardan tüketiciye — kontrol edilebilir hukuki temeller ve sözleşmeler gerekliliği.
• Etik ve güven: Şirketler yalnızca veri miktarıyla değil, aynı zamanda bu verilerin kökeni ve işlenmesindeki "etikliği" ile de rekabet ediyor.

Uygulama 1: A'dan Z'ye Scraping'in Hukuki Değerlendirme Çerçevesi

Adım 1. Verilerin ve Amaçların Haritalanması

1. Scraping'in amacı: fiyat analizi, piyasa araştırması, bilimsel amaçlar, kalite kontrol, risk izleme.
2. Veri türünü sınıflandırın: kişisel, meta veriler, sıradan iş verileri (fiyatlar, SKU, takvimler), korunması gereken unsurlar (biyometrik, finansal tanımlayıcılar).
3. Erişilebilirliği değerlendirin: halka açık sayfa, kayıt gerekli mi, captcha, paywall, token var mı.
4. Yargı alanlarını belirleyin: neredesiniz, sunucu nerede, veri sahipleri nerede, veriler nereye aktarılıyor.

Adım 2. Yasal Temel (GDPR) ve Yasal Rejim Seçimi (RF)

• AB/EEA (GDPR): genellikle - "meşru menfaat" (md. 6(1)(f)). Legitimate Interest Assessment (LIA) yapılması gereklidir: menfaatin, işleme gereksiniminin açıklanması, veri sahiplerinin haklarıyla dengelenmesi, koruma önlemlerinin uygulanması (minimize etme, takma ad kullanma, amaçların sınırlandırılması).
• RF (152-FZ): kişisel verileri işlemiyor olduğunuzu belirleyin. Eğer işliyorsanız — yasal bir dayanak gerekmektedir: onay, yasa, sözleşme, diğer öngörülen nedenler. "Halka açık KV" için ayrı bir onay ve erişim koşullarının varlığını kontrol edin. Yerelleştirme (242-FZ) ve Roskomnadzor'a bildirim gereksinimlerini dikkate alın.

Adım 3. Şeffaflık ve Bildirim

• GDPR md. 14: KV'ler, veri sahibinden toplanmazsa bilgilendirme gereklidir. Bilgilendirme sağlanmasının imkansız olduğu veya orantısız çaba gerektirdiği durumlar için muafiyet mümkündür; o zaman işleminizdeki genel kamuya açık bilgileri sağlayın, veri sahiplerinin haklarının gerçekleştirilmesini kolaylaştırın, orantılılık değerlendirmesinin kaydını tutun.
• RF: KV'lerinizi kapsayan düzenlemelerle veri sahiplerini bilgilendirin; başvuru ve silinme mekanizmaları sağlayın. Kısıtlamalarla yayımlanan veriler için, veri sahibinin belirlediği düzenlemeleri yerine getirin.

Adım 4. Sözleşmesel Temizlik

• Kaynağın ToS'sini analiz edin: otomatik toplama üzerinde bir yasak var mı, ticari kullanım kısıtlaması, lisanslama koşulları.
• API olanaklarını kontrol edin: API mevcutsa ve ihtiyaçları karşılarsa, çoğunlukla tercih edilen olacaktır.
• Veri tabanı hakkını (AB): önemli bir bölümün çıkarılması veya sistematik şekilde içeriğin yeniden üretilmesi riski var mı değerlendirin.

Adım 5. DPIA ve Koruma Önlemleri

• Risk yüksekse (toplu KV, profil oluşturma, hassas gruplar) — DPIA gerçekleştirin: tehditler, önlemler, kalıntı riski, azaltma planı.
• Minimize edin: yalnızca gerekli alanları alın, mümkün olduğunca az saklayın, belirli bir takvime göre silin.
• Sınır ötesi aktarımları kontrol edin: AB — standart sözleşme hükümleri ve varış ülkesinin değerlendirilmesi.

Adım 6. Kayıtlar ve Operasyonel Prosedürler

• RoPA (işleme kayıtları): amaçlar, veri kategorileri, alıcılar, saklama süreleri, güvenlik önlemleri.
• DSR Prosedürleri (veri sahipleri talepleri): erişim, silme, işleme itirazı.
• Olay Yönetimi: ihlal bildirim politikası, iç iletişim, tepki planı.

Sonuç: Karar Alma Matrisi

Tüm bunları "risk haritası" içinde birleştirin: veri türü × erişim şekli × yargı alanları × amaç. Yeşil alan — halka açık, kişisel olmayan, API, açık lisans. Sarı alan — halka açık KV ve LIA, bilgilendirme, minimize etme. Kırmızı alan — engelleri aşma, sistematik kopyalama, özel kategori KV.

Uygulama 2: Tekniğin Tasarımı ve Scraping Etikleri

"Privacy & compliance by design" İlkeleri

• Kaynağa Saygı: robots.txt'yi temel politika olarak izleyin; bir şey yasaksa, yasal nedenleri ve yardımcı önlemleri değerlendirin ya da alternatif kaynakları araştırın.
• Rate Limit ve Yük: isteklerin sınırını koyun, önbellek kullanın ve "uyku" süreleri belirleyin; kaynağın işleyişine müdahale etmemek için zirve saatleri kontrol edin.
• Kendinizi Tanımlayın: anlaşılır bir User-Agent, şikayetler için iletişim emaili sağlayın; bu, riskleri azaltır.
• Veri Kalitesi: geçerliliği kontrol edin, hash değerlerini ve scraping tarihini saklayın; denetim için kaynağı kaydedin.
• Minimize Ediniz: son derece gerekli olmayan hassas alanları toplamayın; takma ad kullanın.
• Güvenlik: depolamada ve aktarma sırasında şifreleme, erişim kontrolü, kayıt tutma, izleme için kalıcı tanımlayıcılar.

Aşamalı Uygulama

1. Taramak: robots.txt ve ToS denetimi, URL haritası ve veri kalıpları, captcha ve sayfa dinamiğinin değerlendirilmesi.
2. İstek Planı: istek sıklığı limiti, zaman aralıkları, üstel bekleme ile yeniden deneme, sonuç düzeyinde bir önbellek.
3. Ekstraksiyon: açık bir şema ile parsel, hedefe uymayan alanları atlayarak.
4. Temizlik: filtreleme, normalizasyon, yasal temel olmaksızın açık kişisel alanların silinmesi.
5. Saklama: kaynaklara göre segmentasyon, verilerin yaşam süresi, silme politikaları.
6. Kontrol: hata izleme, 4xx/5xx, arızalarda kaynağı bilgilendirme.

Etik Normlar

• Site normal işleyişini engelleyen bir yük oluşturmayın.
• Teknik erişim engellerini aşmayın ve gerçek kullanıcı davranışını izinsiz taklit etmeyin.
• Hariç tutma ve veri silme taleplerine saygı gösterin.
• Veri sahiplerinin çıkarlarını göz önünde bulundurun, hatta yasal bir temel olmasına rağmen.

Uygulama 3: Sözleşmesel Hukuk Stratejisi: ToS, Lisanslar, API

„Anlaş” veya “kısıtla” Modeli

• İlk Seçenek — API: iş hedeflerini karşılıyorsa, erişimi düzenleyin. Artılar: öngörülebilirlik, SLA, hukuki kesinlik. Eksiler: limitler ve maliyet.
• İçerik Lisansı: sistematik olarak üçüncü taraf web verilerini kullanmayı düşünüyorsanız, lisans anlaşmasını dikkate alın. Veriler kritikse, bu, dava açmaktan daha ucuzdur.
• ToS-farkındalığı ile scraping: eğer ToS botları yasaklıyorsa, yazılı izin alma, küçük hacimlerde kullanım, ortaklık imkanı kontrol edin.

Veri Tabanı ve İçerik Haklarının Kontrolü

• AB: "önemli bir bölüm" çıkarıyor musunuz veya ekonomik değerini mi yeniden üretiyorsunuz değerlendirin. Düzenli olarak veri tabanını çoğaltan talepler risklidir.
• Telif Hakkı: metinler, görüntüler, sayfa yapıları; alıntı ve adil kullanım sınırlıdır.

Ön Sözleşme Analizi Çerçevesi

1. Verilerin ticari değeri ve alternatifleri.
2. Erişim hacmi ve sıklığı.
3. Veri rejimi (KV/kişisel olmayan), yargı alanları, sınır ötesi aktarım.
4. Lisanslama modelleri ve uyum masrafları vs. dava riski.

Uygulama 4: Altyapı ve Proxy: Yasal ve Şeffaf Nasıl Kullanılır

Proxy Kullanımında Hukuki Kılavuzlar

• Amaç: Proxy'ler trafik dengesi, coğrafi test, kesintisiz çalışma ve altyapının gizliliği için kullanılabilir — fakat erişim yasaklarını aşmak veya ToS ihlallerini gizlemek için değil.
• Yasal Durum ve Onay: yalnızca kaynağı yasal olarak elde eden ve çıkış IP sahiplerinin onayını alan sağlayıcıları kullanın (özellikle mobil proxy durumunda). Yetkisiz botnet ve gri ağları hariç tutun.
• Şeffaflık: IP kaynaklarını, coğrafyayı kaydedin, belirli yargı alanlarında izin alıp almadığınızı ve şikayetleri nasıl ele aldığınızı belirtin.

Yasakları Aşmadan Operasyonel Model

1. Proxy Politikası: captcha, paywall, kimlik doğrulama ve site sahibinin belirlediği rate limitleri geçmek için proxy kullanımını yasaklayan bir belge.
2. Segmentasyon: test, üretim ve geri bildirim için proxy havuzlarını ayırın, böylece olayları araştırabilirsiniz.
3. Etik Sınırlamalar: kodun ve proxy geçidinin düzeyinde, ortalama kullanıcının altındaki maksimum istek miktarını belirleyin ve "sessizlik" aralıklarına uyun.
4. Kayıtlar: taleplere yanıt vermek ve kötüye kullanımları dışlamak için loglar (hashlenmiş tanımlayıcılar) tutun.
5. Kaynak Kaydı: her sağlayıcı için - sözleşme, yargı alanı, iletişim, abuse bildirimleri için SLA.

Mobil Proxy: Ne Zaman Uygun ve Nasıl Güvenli

• Use-cases: mobil arayüzlerin coğrafi test edilmesi, erişilebilirlik kontrolü, hız ve kalite ölçümü.
• Uyum Kontrolü: IP kaynaklarının yasallığı açısından sağlayıcı denetimi; son kullanıcıların onayına ilişkin yazılı beyanlar; şikayetlere yanıt verme süreçleri.
• Teknik Önlemler: alan adları için beyaz liste (nerelere izin verildiği), hız sınırlaması, şifreleme olmadan proxy üzerinden kişisel tanımlayıcıların gönderilmesinin yasağı.

Prensip Olarak: Proxy'ler bir ağ mühendisliği aracıdır, yasakları aşma aracı değil. Herhangi bir "engellerin aşılması ve tespit edilmesi için" senaryo, hukuki riski artırır ve etik ile çelişir.

Uygulama 5: Süreçlerin Belgelendirilmesi: Uyumun Kontrol Edilebilir Olmasını Sağlayın

Denetçi ve Düzenleyici İçin Belgeler

• Data Map: kaynaklar, veri kategorileri, alanlar, yargı alanları, amaçlar.
• RoPA: her amaç için işleme kaydı; değişikliklerde güncellenir.
• LIA: meşru menfaatin gerekçesi (AB), veri sahiplerinin haklarıyla denge, azaltma önlemleri.
• DPIA: yüksek riskli senaryolar için (toplu profil oluşturma, hassas veriler).
• Politikalar: scraping politikası, proxy politikası, saklama ve silme politikası, olaylara yanıt politikası.
• Bildirim Şablonları: şeffaflık sayfası (md. 14), DSR taleplerine yanıtlar, onayların geri alınma süreçleri (RF: KV'nin yayılması için koşullar).

Aşamalı İşleyiş

1. Bir süreç sahibi (Data Steward) atayın ve Hukuk × Mühendislik × Güvenlik ilişkisini tanımlayın.
2. End-to-end hattını tanımlayın: toplama, işleme, depolama, erişim, silme.
3. KPI belirleyin: DSR'ye yanıt süresi, minimize edilmiş alanların oranı, verilerin ortalama yaşam süresi, denetimlerin başarı oranı.
4. Bir masaüstü tatbikatı gerçekleştirin: veri sahibinin şikayet senaryosu, düzenleyicinin talebi, hak sahibinin talebi.
5. Önemli kaynakların ToS ve robots.txt'sini düzenli olarak gözden geçirin.

Elinizde Bulunması Gereken Şablonlar

• Kısa form LIA şablonu (amaç, gereklilik, denge, önlemler, sonuç).
• DPIA şablonu (risk kaydı, olasılık, etki, karşı önlemler).
• DSR'ye yanıt şablonu (talep sahibi tanımlaması, süreler, istisnalar dahil).
• Web site sahibi ile scraping için onay talebi şablonu (kapsam, amaçlar, sıklık, iletişim bilgileri ile birlikte).

Uygulama 6: İçerik ve İS: Sınırı Aşmamak İçin Nasıl Yapılır

Telif Hakkı

• Korunanlar: metinler, fotoğraflar, tasarım, kod; gerçekler kendiliğinden değildir, ancak toplanmaları ve yerleştirilmeleri korunabilir.
• Doğru Kullanım: sınırlıdır, yargı alanına bağlı; bunu temel strateji olarak düşünmeyin.

Veri Tabanı Hakları (AB)

• Önemli Çıkarım ve esaslı olmayan kısımların sistematik kopyalanmaktan kaçının, bu ekonomik değeri yeniden kazanabilir.
• Teknik Önlemler: seçici örnekleme, kaynak yeniden inşa edilmeden toplama, doğrulama için birincil kaynağa bağlantılar.

Ticari Sır ve Kötü Niyetli Rekabet

• Kapalı bölümlerin çıkarımını yapmayın; engelleri aşarak erişimi sağlanan başkalarına ait sırları kullanmayın.
• Kaynağınızla bir ortaklık veya bağlılık varsa, bunun varlığı olmayan bir illüzyon yaratmayın.

Uygulama 7: API vs HTML: Nasıl Seçmeli ve Birleştirmeli

API Ne Zaman Daha İyidir

• Sürdürülebilir ihtiyaçlar ve SLA kritik süreçler olduğunda.
• Hukuki ve teknik bir destek almak gereklidir.
• Limitlere ve lisanslara uyulması önemlidir ve şemaların güncellemeleri alınmalıdır.

HTML Ne Zaman Uygundur

• Veriler basit, kişisel olmayan, API yoksa ve halka açık erişim belirgin bir durumsa.
• Pazarın hızlı bir anlık görüntüsüne ihtiyacınız varsa.

Hibrit Model

• Ana akış — API üzerinden; HTML — boşlukları doğrulama ve kapatma için yedek olarak, sıkı limitler ve etik kurallar altında.

Tipik Hatalar: Neler YAPILMAMALI

• ToS ve robots.txt'yi göz ardı etmek "teknik olarak mümkün olduğu için".
• Her şeyi toplamak: minimize etme ilkesinin ihlali.
• Sonsuz süreyle saklamak: silinme ve güncelleme sürelerinin olmaması.
• Verileri sınırlar arasında taşımak yasal mekanizmalar olmaksızın.
• Bildirim eksikliği ve Art. 14 (AB) veya 152-FZ gerekliliklerine göre şeffaflık.
• Şüpheli proxy'ler kullanmak, bunlar botnetler ve sahiplerin onayı ihlaliyle ilişkilidir.
• Captcha ve kimlik doğrulama aşmak: yüksek hukuki ve itibar riski.

Araçlar ve Kaynaklar: Neler Kullanılmalı

Hukuki ve Uyum Araçları

• LIA/DPIA için jeneratörler ve şablonlar ve işleme kayıtları.
• DSR yönetimi ve denetim için platformlar.
• Kaynakların şeffaflığı için veri kökenlerinin ve dizin sistemlerinin izlenmesi.

Teknik Araçlar

• Rate limiting, yeniden deneme ve önbellek desteği olan scraping çatıları.
• Anonimleştirme ve takma ad kullanma araçları.
• SIEM/kayıt tutma, erişim kontrolü, veri tabanı ve taşıma kanalında şifreleme.

Operasyonel Uygulamalar

• Ana alan adlarının ToS ve robots.txt'lerinin periyodik kontrolü.
• Yeni bir kaynağın başlatılması öncesinde iç kontrol listeleri.
• Ekibin scraping etikleri ve "minimize etme" ilkeleri üzerine eğitim.

Vaka Çalışmaları ve Sonuçlar: İş Dünyasından Örnekler

Vaka 1: KV Olmadan Fiyat İzleme

Şirket X, elektronik eşya ticareti yapmaktadır. Amaç — rakiplerin fiyatlarının günlük izlenmesi. Veriler: ürün adları, SKU, fiyat, mevcutluk. Uygulamalar: ToS analizi (endekslemede yasak yok; içerik kopyalamasında yasaklar mevcut). Teknik olarak: agresif önbellek, giriş gereksinimi yok, domain başına 0.1 RPS rate limiting, gece pencereleri. Hukuk: kişisel veri değil; veri tabanı haklarının analizi (AB) — sadece seçilmiş pozisyonlar; veri tabanı yeniden inşası yok. Sonuç: şikayet olmadan istikrarlı bir akış, alım maliyetlerinde %3.7 azalma, 12 ay içerisinde herhangi bir olay yok.

Vaka 2: İş İlanı Agregatörü (AB)

Şirket Y, işveren web sitelerinden iş ilanlarını topluyor. Veriler: başlıklar, açıklamalar, lokasyonlar, zaman zaman işe alımcıların iletişim emaili (KV). Hukuk: LIA, m. 14 bilgilendirme ile halka açık sayfa ve opt-out mekanizması, taleple ilk temasta email adreslerinin silinmesi, minimize etme (email’leri işe alımcıyla iletişime geçene kadar hashlenmiş olarak saklama). Sözleşme çalışması: ToS'u botlara yasaklayan büyük web siteleriyle lisans teklifleri. Sonuç: 10 ortaklık anlaşması, uyumun devam etmesi, ceza olmaması; pazar kapsamının %18 artması.

Vaka 3: Rus Pazarlama Analisti

Şirket Z, serbest piyasa platformlarında açık profilleri analiz ediyor. Veriler: kullanıcı adı, portföy, teklifler, yorumlar; kişisel veri olabileceği düşünülebilir. RF hukukunda: KV operatörü olarak tanımlama, faaliyet bildiriminde bulunma, kopyaların RF’de yerelleştirilmesi, işleme politikası; talep üzerine indeksten çıkarma; yalnızca halka açık alanları toplama; telefon numaralarını ve email adreslerini hariç tutma (yayınlama onayı yoksa). Sonuç: hukuken temiz bir ürün, önlemler yok, platformlarca sadakat (akış değişimi).

SSS: 10 Anahtar Soru

1. Giriş yapmadan sayfaları yasaldan scrape etmek mümkün mü?

Eğer sayfa halka açık ise ve teknik engeller aşılmadıysa, birçok yargı alanında bu yasadışı erişim olarak değerlendirilmiyor. Ancak riskler var: ToS ihlali, veri tabanı (AB), KV (GDPR/152-FZ). Yasal dayanağı, minimalizasyonu, bilgilendirmeyi kontrol edin ve robots.txt’ye saygı gösterin.

2. Hukuk robots.txt'ye nasıl bakıyor?

Bu bir teknik tavsiye olup, yasadır. Bununla birlikte, yok sayılması, kötü niyetteki ve ToS ihlalleriyle ilgili kanıtları artırabilir. Uyum uygulamalarında, robots.txt'yi varsayılan olarak dikkate almak gerekir.

3. Veriler halk arasında da olsa GDPR kapsamında bir yasal temele ihtiyaç var mı?

Evet. Halka açıklık, GDPR gerekliliklerini ortadan kaldırmaz. En sık olarak uygun olan meşru menfaat, LIA ile birlikte olacaktır. Minimalizasyon, şeffaflık (madde 14), saklama süreleri ve veri sahiplerinin hakları için olan mekanizmalar zorunludur.

4. hiQ vs LinkedIn davasında 2026 itibarıyla ne değişti?

2024 sonu itibarıyla temel dalga şöyledir: kimlik doğrulama aşılmadan halka açık sayfaların scraping'i, CFAA suçu olarak kendiliğinden değerlendirilmemektedir. 2025-2026 dönemi boyunca, benzer davalarda yeni kararları takip edin. CFAA’ya bir "af" olarak güvenmeyin: ToS, telif hakkı, veri tabanı ve diğer normlar hala geçerlidir.

5. İletişim email’lerini scrape etmek mümkün mü?

Bu durumda risk yüksektir, çünkü bunlar kişisel verilerdir. AB için - LIA ve madde 14 bildirim veya muafiyet, sıkı minimalizasyon ve amaç gereklidir. RF için - 152-FZ’ye göre gereklilikler ve dağıtım koşullarına saygı. Bazı durumlarda, email adreslerini başlangıçta toplamaktan kaçınmak daha iyi olabilir.

6. Mobil proxy'ler ne durumda?

Yalnızca yasal kaynakları kullanın, yasakları aşmak için değil. Politika belirtin, hız limitini kısıtlayın, log tutun ve şikayetlere yanıt verin. Proxy üzerinden captcha/kimlik doğrulama geçmek, ihlal riskini artırır.

7. ToS ihlali ne gibi sonuçlar doğurur?

Sivil davalar, yasaklamalar, kötü niyetli rekabet ve fikri mülkiyet talepleri ile ilgili olası itirazlar. Belirli senaryolarda, hareketlerin bir araya gelmesi, yasadışı erişim olarak değerlendirilebilir.

8. Roskomnadzor'u bilgilendirmek gerekiyor mu?

Bu, KV işlemesinin niteliğine ve nedenlerine bağlıdır. Eğer KV operatörüyseniz, bildirim, yerelleştirme ve politika gerekliliklerini kontrol edin. Şüphe durumunda — uzmanla denetim yaptırın.

9. Çok sayıda veri sahibi varsa madde 14'ü nasıl uygulamak gerekir?

"Orantısız çaba" durumunu değerlendirin: uygunsa, kamuya açık bildirim kullanın, net opt-out kanalları sağlayın ve KV miktarını azaltın. Değerlendirmeyi kaydedin.

10. AB'deki veri tabanlarıyla ilgili talepleri nasıl önleyebiliriz?

Önemli bir kısmı çıkarın ve ekonomik değeri yeniden kazandırmayın. Örnekleme, birleştirme, birincil kaynakla bağlantı oluşturma ve mümkünse lisansla çalışın.

Sorumluluk: Cezalar, Davalar, İtibar

AB/EEA

• GDPR: 20 milyon euroya veya küresel cirosunun %4'üne kadar; toplu scraping olayı, KV'leri izinsiz çıkarma durumunda koruyamayan operatörler ve izinsiz sonraki işleme durumunda scrapingciler için büyük cezalara yol açmıştır.
• Veri Tabanları: mahkeme yasaklamaları, tazminat, kazancın elden çıkarılması.

ABD

• ToS, telif hakkı, kötü niyetli rekabet, trespass to chattels ihlali nedeniyle sivil davalar; mahkeme yasaklamaları ve tazminat talepleri.

Rusya

• 152-FZ ve KoAP: KV işlemlerinde ihlaller nedeniyle idari cezalar, düzeltme talimatları, web siteleri/agregatörler için faaliyet kısıtlamaları.
• Ceza Kanunu: korumanın aşılması durumunda bilgisayar bilgilerine yasadışı erişim için cezai düzenlemeler.
• Medeni Davalar: kişilik hakları, onur, mahremiyet, fikri mülkiyet talepleri; tazminat talepleri.

İtibar

Hukuki olarak kabul edilen scraping bile şeffaflık eksikliği durumunda olumsuz bir etki yaratabilir. Proaktif iletişim, etik ve net hariç tutma mekanizmaları riski azaltır.

Kontrol Listeleri ve Hazır Çerçeveler

Pre-scrape Kontrol Listesi

• Amaç ve minimum alan seti belirlendi.
• ToS, robots.txt, API varlığı kontrol edildi.
• Kişisel/kişisel olmayan, yargı alanları sınıflandırıldı.
• Gerekirse LIA/DPIA hazırlandı.
• Saklama ve silme süreleri belirlendi.
• Rate limitler ve önbellek ayarlandı.
• DSR ve opt-out mekanizmaları tanımlandı.

“4 Dörtlü” Çerçevesi

• Veriler: KV vs. kişisel olmayan.
• Erişim: halka açık vs. kısıtlı.
• Hukuk: AB/ABD/RF/diğer.
• Amaç: meşru menfaat/araştırma/gazetecilik/pazarlama.

Post-scraping Kontrol Listesi

• Kalite kontrolü, gereksiz alanların silinmesi.
• Kaynaklar ve tarihlerin kaydedilmesi.
• Kayıtların güncellenmesi (RoPA), LIA/DPIA.
• Sınır ötesi aktarımın kontrolü.
• Şeffaflık sayfası ve SSS'nin güncellenmesi.

2025-2026'da Neleri İzleyeceksiniz

• hiQ vs LinkedIn davasına benzer davalardaki yeni kararlar ve mahkemelerin bileşen davalara bakış açısı (ToS + fikri mülkiyet + kötü niyetli rekabet).
• Avrupa düzenleyicilerinin (CNIL, DPC vb.) kişisel verilerin toplu scraping’i konusundaki kararları, platformlara "privacy by design" gereklilikleri dahilinde.
• Rus pratiği, "halka açık KV", yerelleştirme ve Roskomnadzor'a ilişkin düzenlemeleri; idari ceza düzenlemeleri hakkında gelişmeleri takip edin.
• ePrivacy'deki güncellemeler ve kamu kaynaklarının izlenmesi konusundaki olası açıklamalar.

Sonuç: Sürdürülebilir Scraping Stratejisi

Yasal web scraping, bir dizi hile değil, hukukun, mühendisliğin ve etiğin kesişiminde sistematik bir disiplindir. Doğru sorular şunlardır: bu verilere neden ihtiyacımız var, daha azı ile yapabilir miyiz, veri sahibi ve web site sahibine ne söyleyeceğiz, bir yıl içinde iyi niyetimizi nasıl kanıtlayacağız. 2026'da kazanacak olan, "doğru olarak yasal süreçler oluşturmayı" kendi alışkanlıkları haline getirenlerdir: robots.txt ve ToS'ye saygı göstermek, mümkünse API tercih etmek, yasal temelleri belgelemek, verilerin toplanmasını minimize etmek, verileri korumak ve kaynaklarla ve veri sahipleriyle açık bir şekilde etkileşimde bulunmaktır. Bu yaklaşım riskleri azaltır, onayları hızlandırır ve güven oluşturur — kopyalanması zor olan ve hiçbir şekilde scrape edilemeyen bir kaynak.

Sonraki adımlar: mevcut kaynakları kontrol listeleriyle denetleyin; LIA/DPIA'nın güncellemelerini gerçekleştirin; proxy ve scraping etiği politikalarını uygulayın; şeffaflık sayfası ve DSR süreçlerini oluşturun; ekibi eğitin ve sahipler atayın; önemli kaynakların ToS'lerini düzenli olarak gözden geçirin ve düzenleyici pratikleri takip edin. Sürdürülebilir uyum, rekabet avantajıdır. Bunu kullanın.