Çok dilli bir sitede gizlilik politikası genellikle tek bir belge olarak tasarlanır, sonra diğer dillere çevrilir. Bu yaklaşım pazarlama metinleri için işe yarayabilir, ama hukuki bir belge için ciddi bir kör nokta yaratır: KVKK Türkiye'deki veri sahiplerine belirli haklar tanır, GDPR ise Avrupa Birliği vatandaşlarına farklı kapsamda ve farklı prosedürlerle işleyen haklar verir. Aynı şirketin Türkçe ve İngilizce sürümü, sadece dil değil, hangi hukukun hangi ziyaretçiye uygulandığı sorusunu da taşır.
Sorun, çoğu ekibin bu ayrımı gizlilik sayfasına değil, hukuk departmanının arka planda hazırladığı sözleşmelere bıraktığı noktada başlar. Site tarafında görünen tek şey, tek bir gizlilik metninin farklı dillere aktarılmış hali olur; oysa metnin içeriği, veri sahibinin hangi ülkede olduğuna göre gerçekten farklılaşması gereken maddeler taşır. Veri saklama süresi, aktarım yapılan üçüncü ülkeler, başvuru mercii ve itiraz süreci gibi kalemler KVKK ile GDPR arasında birebir örtüşmez.
Aşağıda bu ayrımın çok dilli sitede nasıl kurulması gerektiği, altı karar noktası üzerinden ele alınıyor: hangi ziyaretçiye hangi metnin gösterileceği, çevirinin hukuki uyum anlamına gelmediği, veri işleme dayanaklarının pazara göre değişebileceği, hreflang ve canonical kararı, ve mevzuat güncellenince dil sürümlerinin senkronizasyonu.
KVKK ve GDPR aynı gizlilik sayfasında nasıl bir arada durur?
İki mevzuatı aynı belgede birleştirmenin en yaygın yolu, ortak zemini paylaşan maddeleri (veri toplama amacı, hangi veri kategorilerinin işlendiği, güvenlik tedbirleri) tek bir bölümde tutup, hak ve başvuru mekanizmalarını ayrı alt başlıklarda ayırmaktır. KVKK madde 11 kapsamındaki haklar (bilgi talep etme, düzeltme, silme, itiraz) ile GDPR madde 15-22 arasındaki haklar (erişim, taşınabilirlik, unutulma) kavramsal olarak benzer görünse de, başvuru süresi, ilgili kurum ve gerekli kanıt standardı farklıdır. Tek bir "haklarınız" bölümü yazıp bunu iki dile çevirmek, her iki tarafın da kendi mevzuatına özgü prosedürünü kaybetmesine yol açar.
Daha sağlıklı kurulum, gizlilik sayfasının dil versiyonunu değil, hukuki kapsam versiyonunu ayırmaktır. Türkçe sayfa KVKK'ya göre yazılır ve Türkiye'deki Veri Sorumlusuna Başvuru Usul ve Esasları Tebliği'ne uygun başvuru formu bağlantısı taşır; İngilizce veya Almanca sayfa GDPR'a göre yazılır ve ilgili denetim otoritesine şikayet hakkını içerir. Bu ikisi aynı şablonun çevirisi değil, aynı veri işleme faaliyetinin iki farklı hukuki çerçeveden okunmuş halidir.
Bir şirket sadece Türkiye'de faaliyet gösteriyor ve yabancı dil sürümü yalnızca yabancı müşterilere bilgi vermek amacıyla varsa, GDPR'a tam uyum zorunlu olmayabilir; burada karar, verinin fiilen kimden toplandığına bağlıdır. AB'de yerleşik kişilerden veri toplanıyorsa (form doldurma, hesap açma, çerez ile takip), GDPR devreye girer; yalnızca bilgilendirme amaçlı bir sayfa söz konusuysa, GDPR'ın tam prosedürel yükü gerekmeyebilir. Bu karar hukuk danışmanıyla netleştirilmeli, teknik ekip sadece sonucu sayfa yapısına yansıtmalıdır.
Türkçe ziyaretçiye hangi metin, yabancı dil ziyaretçisine hangi metin gösterilir?
Dil ile hukuki kapsam çoğu zaman örtüşür ama her zaman birebir eşleşmez. Türkiye'de yaşayan ve İngilizce sayfayı tercih eden bir ziyaretçi hâlâ KVKK kapsamındadır; sadece dil tercihi İngilizce'dir. Buna karşılık, Almanya'da yaşayan ve Türkçe sayfayı okuyan bir ziyaretçi (örneğin Türkiye kökenli bir topluluk üyesi) GDPR kapsamına girer. Dil seçimini hukuki kapsamla birebir eşleştirmek, bu iki senaryoda yanlış mevzuata yönlendirme riski taşır.
Pratik çözüm, dil sürümü başına tek bir varsayılan hukuki çerçeve tanımlamak, ama sayfanın altına her iki mevzuat için de başvuru bilgisi eklemektir. Türkçe sayfa öncelikle KVKK'yı esas alır, ama "Avrupa Birliği'nde yerleşikseniz GDPR kapsamındaki haklarınız için buraya bakın" şeklinde net bir yönlendirme taşır. Bu, dil seçici tasarımındaki otomatik yönlendirme mantığıyla aynı ilkeye dayanır: ziyaretçinin coğrafi konumunu tahmin ederek onu sessizce bir tarafa yönlendirmek yerine, seçimi açık bırakmak ve doğru bilgiye ulaşmasını kolaylaştırmak daha güvenli sonuç üretir.
E-ticaret siteleri için bu ayrım daha kritik hale gelir çünkü ödeme ve teslimat adresi üzerinden ziyaretçinin fiilen hangi ülkede olduğu bilinir. Sipariş sürecinde toplanan adres bilgisi, hangi mevzuatın uygulanacağını dil tercihinden daha güvenilir şekilde gösterir; gizlilik metninin hangi sürümünün bağlayıcı kabul edileceği, kullanım şartlarında bu iki sinyal (dil ve teslimat ülkesi) çakıştığında hangisinin öncelikli olduğu açıkça belirtilerek netleştirilmelidir.
Çeviri, hukuki metni otomatik olarak uyumlu hale getirmez
Yerelleştirme ile çeviri arasındaki fark pazarlama içeriğinde okunabilirlik sorunuysa, hukuki metinde geçerlilik sorunudur. KVKK'ya uygun yazılmış bir gizlilik politikasının İngilizce'ye kelime kelime çevrilmesi, GDPR'ın gerektirdiği maddeleri (veri işleme dayanağının hukuki kategorisi, aktarım için kullanılan standart sözleşme hükümleri, otomatik profilleme varsa buna itiraz hakkı) otomatik olarak eklemez. Çeviri dilbilimsel bir işlemdir; mevzuat uyumu hukuki bir değerlendirmedir. İkisi aynı adımda gerçekleşmez.
Sahada en sık görülen hata, tek bir hukuk müşavirinin KVKK metnini hazırlaması, ardından bu metnin bir çeviri bürosu veya otomatik çeviri aracıyla diğer dillere aktarılmasıdır. Çeviri kalitesi yüksek olsa bile, GDPR'ın zorunlu kıldığı bazı maddeler (örneğin AB dışına veri aktarımında Standard Contractual Clauses referansı) KVKK metninde hiç bulunmadığından çeviriye de geçmez. Sonuç, dilbilgisi açısından kusursuz ama hukuki açıdan eksik bir GDPR sayfasıdır.
Doğru sıralama, her hukuki çerçeve için ayrı bir taslak hazırlanmasıdır: önce KVKK'ya uygun Türkçe metin, ayrı olarak GDPR'a uygun bir metin (bu ikinci metin İngilizce yazılabilir ama kendi başına bir hukuki belge olarak tasarlanır). Ancak bu iki taslak netleştikten sonra, ortak olan bölümler arasında çeviri/tutarlılık kontrolü yapılır. Çeviri son adımdır, ilk adım değildir.
Veri işleme dayanakları pazara göre değişince gizlilik sayfası da değişir
KVKK'da veri işleme için altı hukuki sebep tanımlanır (madde 5), GDPR'da ise altı farklı dayanak vardır (madde 6); kategoriler kısmen örtüşse de birebir aynı değildir. Örneğin GDPR'daki "meşru menfaat" (legitimate interest) dayanağı, KVKK'daki "veri sorumlusunun meşru menfaati için zorunlu olması" ile benzer görünür ama ispat yükü ve denge testi farklı işler. Bir şirket aynı veri toplama faaliyetini (örneğin site içi davranış takibi) Türkiye'de rıza almadan meşru menfaate dayandırırken, AB ziyaretçisi için açık rıza almak zorunda kalabilir.
Bu fark gizlilik sayfasına yansıtılmazsa, sayfa bir tarafta doğru bir tarafta yanlış olur. Rıza mekanizması varsa (örneğin pazarlama e-postası için opt-in), bu mekanizmanın hangi dil sürümünde nasıl işlediği, gizlilik metninde açıkça belirtilmelidir; Türkçe sayfa "e-posta almak için formu doldurduğunuzda rıza vermiş sayılırsınız" derken, GDPR sayfası "e-posta almak için ayrıca onay kutusunu işaretlemeniz gerekir" demelidir çünkü iki mevzuatın rıza standardı aynı değildir.
Çok pazarlı bir e-ticaret sitesinde bu fark, ödeme sayfasındaki onay kutularına kadar iner. Aynı checkout akışı, Türkiye'den gelen sipariş için tek bir genel onay metniyle çalışabilirken, AB'den gelen sipariş için ayrı çerez onayı ve ayrı pazarlama onayı gerektirebilir. Gizlilik sayfası bu farkı anlatmakla kalmaz, checkout akışının kendisi de pazara göre farklı davranmak zorunda kalır.
Gizlilik sayfasında hreflang ve canonical kararı
Hreflang'ın zorunlu olup olmadığı sorusu gizlilik sayfaları için farklı bir açıdan cevaplanır: burada mesele arama niyeti değil, hangi hukuki metnin hangi ziyaretçiye ulaştığının garanti edilmesidir. Türkçe ve İngilizce gizlilik sayfaları birbirinin doğrudan çevirisi değilse (yukarıdaki maddelerden dolayı gerçekten farklı içerik taşıyorlarsa), hreflang eklemek teknik olarak yanlış olmaz ama "bu iki sayfa eşdeğerdir" sinyalini de vermemelidir; hreflang alternate ilişkisi anlam bakımından eşdeğer içerik için tasarlanmıştır, hukuki kapsamı farklı iki belge için zorlama bir eşleştirmedir.
Pratikte çoğu site gizlilik sayfasını zaten noindex olarak işaretler, bu da hreflang tartışmasını büyük ölçüde anlamsız kılar; indekslenmeyen bir sayfa için arama motoruna hangi dilin öncelikli olduğunu bildirmenin SEO değeri yoktur. Buradaki asıl karar SEO değil, kullanıcı deneyimidir: gizlilik sayfasının üstünde net bir dil/bölge seçici bulunmalı, ziyaretçi kendi ülkesine uygun metne kolayca geçebilmelidir.
Canonical kararı ise basittir: her dil/mevzuat sürümü kendi URL'sini canonical olarak işaret etmelidir, çünkü bu sayfalar birbirinin kopyası değil, farklı hukuki belgelerdir. Bir sayfayı diğerine canonical yapmak, arama motoruna "asıl olan bu, diğeri onun bir varyantı" mesajı verir; oysa KVKK ve GDPR sayfaları hiyerarşik değil, paralel iki belgedir.
Mevzuat güncellenince tüm dil sürümleri aynı anda mı güncellenir?
KVKK'da bir tebliğ değişikliği veya GDPR'da bir denetim otoritesi kararı, gizlilik metninin güncellenmesini gerektirdiğinde, çok dilli sitelerde sık görülen hata, sadece ilgili mevzuatın geçerli olduğu dil sürümünün güncellenmesi, diğerlerinin eski haliyle kalmasıdır. Bu teknik olarak mantıklı görünür (KVKK değiştiyse neden İngilizce sayfa da değişsin), ama iki riski birden taşır: birincisi, ortak bölümler (veri güvenliği tedbirleri, iletişim bilgileri) genellikle her iki metinde de aynı kalması gerekirken senkronize güncellenmez; ikincisi, güncelleme tarihi (dateModified veya sayfa altındaki "son güncelleme" notu) sadece değişen dilde ilerler, diğer dil sürümü eski tarihte donup kalır ve bu tutarsızlık bir denetimde fark edilir.
Pratik yol, gizlilik metinlerini tek bir kaynaktan yönetmek değil (çünkü hukuki içerik pazara göre gerçekten farklıdır), ama bir değişiklik günlüğü tutmaktır: hangi maddenin hangi tarihte hangi mevzuat gerekçesiyle değiştiği, dil sürümü fark etmeksizin merkezi bir listede tutulur. KVKK değişikliği geldiğinde bu listeye bakılıp GDPR sürümünde karşılık gelen bir madde olup olmadığı kontrol edilir; yoksa değişiklik sadece bir tarafta kalır, ama bu bilinçli bir karardır, unutkanlık değil.
Teknik SEO denetim listesine eklenmesi gereken bir kontrol, her dil sürümündeki gizlilik sayfasının güncelleme tarihinin gerçekten o sürümdeki son hukuki değişikliği yansıtıp yansıtmadığıdır. Bir sayfanın güncelleme tarihi ileri gösterip içeriği değişmemişse, bu hem kullanıcı güvenini hem de olası bir denetimde şirketin durumunu zayıflatır.
Gizlilik sayfası çok dilli bir sitede diğer tüm sayfalardan farklı bir kategoriye girer: burada amaç arama motorunda görünürlük değil, hangi ziyaretçiye hangi hukuki koruma sunulduğunun doğru iletilmesidir. Dil versiyonlarını birbirinin çevirisi gibi ele almak, bu iletişimi teknik olarak tamamlanmış ama hukuki olarak eksik bırakır.
KVKK ve GDPR arasındaki fark zamanla küçülse de şu an tamamen örtüşmüyor; bu yüzden gizlilik sayfası kararı, dil ekibinin değil hukuk ekibinin öncülüğünde alınmalı, teknik ekip sadece bu kararın hangi URL yapısına, hangi canonical mantığına ve hangi güncelleme takibine oturacağını kurmalıdır.