Gizlilik Yasaları Tasarımı Şekillendirir

🌐 28 dilde daha mevcut

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Görsel yapay zekâ ile üretilmiştir

Yapay zekâ ile çevrildi. Henüz topluluk tarafından incelenmedi. İngilizcesini oku

Data Architect kursunun 5. bölümü olan Veri Kalitesi ve Yönetişim bölümündeki 6 modülden 4.‘sü. Her modül kendi başına okunabilir. Önceki: Verinizi Tanıyın · Sonraki: Onay ve Unutulma Hakkı

Bu modülün yanıtladığı soru: Gizlilik ve sektör düzenlemeleri bir Salesforce tasarımından ne ister?

Avustralya’da çalışırken GDPR’ı hiç duymamış pek çok mimar adayıyla tanıştım. Avrupalılar da çoğu zaman Kaliforniya’nın, Kanada’nın ya da Brezilya’nın gizlilik yasasını duymamıştır. Bu doğaldır: çalıştığınız yerin kurallarını bilirsiniz. Ama bu yasalar sınırların ötesine uzanır ve hiçbiri Salesforce hakkında olmasa da sistem tasarımını şekillendirir. Dolayısıyla bir veri mimarisi kursuna aittirler.

Avukat olmanız gerekmez. Bir düzenlemenin verinin nerede saklandığını, neyi topladığınızı, onu kimin gördüğünü, neden kullanabileceğinizi, ne kadar süre sakladığınızı, nereye gönderdiğinizi, silip silemeyeceğinizi, hangi geçmişi tuttuğunuzu ve sonradan neyi kanıtlayabileceğinizi değiştirebileceğini görmeniz gerekir. Bunlar yalnızca hukuki sorular değil. Veri mimarisi sorularıdır.

Bu modül hukuki tavsiye değil, mimari rehberliktir. Hangi yasaların geçerli olduğuna ve neyi gerektirdiklerine hukuk ve uyumluluk ekipleri karar verir. Mimar bu gereksinimleri uygulanabilir bir tasarıma dönüştürür.

Yasalar Sınırda Durmaz

Önce en büyük yanılgı: “Avrupa’da değiliz, o halde GDPR geçerli değil.” Belki, belki de değil. GDPR’ın ülkesel kapsamı, AB’deki kişilere mal ya da hizmet sunan veya oradaki davranışlarını izleyen AB dışındaki kuruluşlara da uzanır (3. Madde, Regulation (EU) 2016/679 (opens in a new tab)). Dolayısıyla şirketinizin genel merkezinin nerede olduğu sorunun sonu değildir. Müşterileriniz, çalışanlarınız, verisini tuttuğunuz insanlar, sistemleriniz, veri işleyenleriniz nerede? Veri nereye gidiyor? Bu yine 4. bölümün haritası. Verinin nereye gittiğini bilmeden iyi gizlilik kararları veremezsiniz.

Tanımanız Gereken Düzenlemeler

İşte bir mimarın bilmesi gereken adlar ve her birinin neyi kapsadığı. Bu bir tanıma tablosudur, bir uygulanabilirlik matrisi değil: onu okuyup “Kaliforniya’da müşterilerimiz var, o halde X gereksinimi geçerli” diye karar vermeyin. Bu Hukuk’un kararıdır. Sizin işiniz, sistem inşa edilmeden önce soruyu soracak kadar bilmektir.

Yasa ya da standart	Nerede ya da ne	Bir mimarın onu neden tanıması gerektiği
GDPR (opens in a new tab)	Avrupa Birliği	Kişisel veri, hukuka uygun işleme, bireysel haklar, saklama, aktarımlar, tasarımda gizlilik
CCPA, CPRA ile değiştirilmiş hali (opens in a new tab)	Kaliforniya	Tüketicilerin, işletmelerin kendileri hakkında topladığı kişisel bilgiler üzerindeki hakları
PIPEDA (opens in a new tab)	Kanada	Özel sektör kuruluşlarının kişisel bilgileri nasıl ele aldığı
LGPD (opens in a new tab)	Brezilya	Brezilya’nın genel kişisel verilerin korunması yasası
Privacy Act 1988 (opens in a new tab)	Avustralya	Kuruluşların, Avustralya Gizlilik İlkeleri kapsamında kişisel bilgileri nasıl ele aldığı
HIPAA (opens in a new tab)	ABD sağlık sektörü	Kapsam dahilindeki bağlamlarda korunan sağlık bilgileri
PCI DSS (opens in a new tab)	Ödeme kartları	Ödeme kartı hesap verilerinin korunması
Sarbanes-Oxley (SOX) (opens in a new tab)	ABD halka açık şirketleri	Finansal raporlamanın arkasındaki kontroller ve kanıtlar
COPPA (opens in a new tab)	ABD, çevrimiçi çocuklar	Çocuklardan çevrimiçi toplanan kişisel bilgiler

Liste uzuyor (daha fazla ABD eyaletinin kendi yasası var) ve yasalar değişiyor. Bir tabloyu ezberleyip gizlilik mimarisini öğrendiğinizi düşünmenizi istememin nedeni bu. Adları öğrenin, sonra onlardan daha uzun yaşayan soruları öğrenin.

Yasaların Ortak Yönleri

Ayrıntılar farklıdır, ama büyük gizlilik yasaları hep aynı birkaç şeye geri döner ve her biri mimariye dokunur.

Haklar. İnsanlar verilerini görmeyi, düzeltmeyi, silmeyi ve yanlarında götürmeyi isteyebilir; Kaliforniya ve Brezilya yasalarına göre verilerinin satılmasını reddetme hakları da vardır. Bu taleplerin her biri, kişinin verisini, hepsini, bulmak demektir.

Aktarımlar. GDPR ve LGPD, kişisel verinin kendi yetki alanlarından çıkmasını denetler ve gittiği yerde yeterli koruma ister; PIPEDA, veriyi nerede olursa olsun üçüncü bir taraf işlediğinde aynı düzeyde koruma bekler. Yine harita: hangi oklar bir sınırı geçiyor?

İhlal bildirimi. Kişisel veri açığa çıktığında yasalar, yasaya göre değişen bir süre içinde yetkililere, bazen de etkilenen kişilere bildirmenizi bekler. Sahip olduğunuzu bilmediğiniz veri hakkında bildirim yapamazsınız; kopyaları bulamıyorsanız neyin açığa çıktığını da söyleyemezsiniz.

Hesap verebilirlik. Uyumluluğu gösterebilmeniz gerekir: neyi ve neden işlediğinize dair kayıtlar, yüksek riskli işleme için etki değerlendirmeleri ve GDPR ile LGPD kapsamında bir veri koruma görevlisi. Kayıtları mimarinin üretmesi gerekir.

Neyin Kişisel Olduğuyla Başlayın

Kişisel bilgiyi korumadan önce onu bulun. Bir kısmı açıktır: ad, ev adresi, telefon, e-posta. Bir kısmı değildir: konum, cihaz tanımlayıcıları, IP adresleri, görüntüler, davranışsal veri, bir kişiye geri bağlanabilecek her şey. Ve bağlam önemlidir. Bir Steve Trucking teslimatı Alıcının adını, adresini, telefon numarasını, teslimat notlarını ve fotoğrafları taşır. Bir fotoğraf verandada bir kutuyu, bir kişiyi ya da bir evin içini gösterebilir. Teslimat operasyonel veridir, ama özniteliklerinin bazıları kişiseldir. 3. modülün alanları sınıflandırmasının nedeni bu: gizlilik elinizde ne olduğunu bilmekle başlar.

Nerede Yaşıyor?

“Salesforce’ta.” Muhtemelen yalnızca Salesforce’ta değil. Bir Perakende Ortağından mı geldi? Snowflake’e mi kopyalandı, Data 360 tarafından mı alındı, bir entegrasyon günlüğüne mi yazıldı, bir kullanıcı tarafından mı dışa aktarıldı, alan geçmişinde mi kaldı, arşivlendi mi, bir sandbox’a mı kopyalandı, bir ortağa mı geçti, bir ajanın konuşmasında mı kullanıldı? Kişisel veri yayılır. Bu yüzden Hukuk “Bu kişinin bilgilerini nerede tutuyoruz?” diye sorduğunda “güncel değerin nerede olduğunu biliyoruz” bir yanıt değildir. Haritayı ve kökeni isterim: kopyaların nereye gittiğini.

Click to enlarge

Tek telefon numarası, pek çok kopya. Gizlilik kopyalar için de geçerlidir.

Onu Kullanmanıza Neden İzin Var?

Veriye sahip olmak ile onu kullanmaya izinli olmak aynı şey değildir. Steve Trucking, bugünkü teslimatı koordine etmek için bir Alıcının telefon numarasına sahip. Bu onu bir pazarlama listesi yapar mı? Hayır. Hukuki dayanak yargı yetkisine ve duruma bağlıdır ve buna Hukuk yol gösterir, ama mimari yanıtı taşımalıdır: neden toplandığı, hangi kullanımın yetkilendirildiği, onayın gerekip gerekmediği, verilip verilmediği, geri çekilip çekilmediği ve hangi kanal, adres ve amaç için olduğu. Veriyi kullanma izni veri olarak temsil edilebilmelidir, çünkü bir politika belgesi çalışma zamanında karar veremez. Bir sonraki modül bunu modelliyor.

Daha Az Toplamak Bir Mimari Karardır

En güçlü gizlilik kontrollerinden biri veriyi toplamamak ya da gerekmediği yere kopyalamamaktır. Snowflake’in Alıcının telefon numarasına ihtiyacı var mı? Analitiğin tam sokak adresine ihtiyacı var mı? Sandbox’ın gerçek teslimat fotoğraflarına ihtiyacı var mı? Bir ajanın bu soruyu yanıtlamak için Alıcının kişisel bilgilerine ihtiyacı var mı? Yoksa en güçlü kontrol onu oraya koymamak olabilir. Yapmadığınız her kopya güvenceye almanız, saklamanız, silmeniz, onayını takip etmeniz, denetlemeniz ya da bir ihlalde raporlamanız gerekmeyen bir kopyadır. Yönetmesi en ucuz hassas veri, hiç kopyalamadığınız veridir.

Saklama Modelin Bir Parçasıdır

“Şimdilik her şeyi saklayalım” bir saklama politikasıdır. Yalnızca kötü bir politikadır. Önemli veri için tasarım aşamasında ona ne kadar süre ve neden ihtiyacımız olduğunu, bir düzenlemenin bir alt sınır, bir diğerinin bir üst sınır koyup koymadığını, sürenin ne zaman başladığını ve sonunda ne olacağını bilmek isterim: silme, arşivleme, kimliksizleştirme ve kopyalar nerede? Finansal kayıtların belirli bir süre kalması gerekebilir. Bir Alıcının kapı şifresinin teslimattan yıllar sonra hiçbir amacı yoktur. Bu kararlar veritabanı büyüyene kadar beklemez.

Anonimleştirilmiş, Takma Adlandırılmış, Şifrelenmiş, Maskelenmiş

“Jane Smith”i 7F92A1 ile değiştirin. Jane anonimleştirildi mi? Başka bir tablo hâlâ 7F92A1 = Jane Smith diyorsa hayır. Bu takma adlandırmadır (pseudonymization): doğrudan tanımlayıcı değiştirilir, ama veri ayrı tutulan bilgiler kullanılarak yeniden bağlanabilir ve GDPR kapsamında takma adlandırılmış veri hâlâ kişisel veridir (4(5). Madde). Anonimleştirme daha ileri gider: veri artık makul ölçüde kişiye bağlanamaz (26. Gerekçe). Dolayısıyla biri “Silmemize gerek yok, sadece adı kaldırırız” dediğinde dikkatli olun. Kişi hâlâ makul ölçüde tanımlanabiliyorsa o çizgiyi geçmemişsinizdir. Bir sonucun yasayı karşılayıp karşılamadığı Hukuk’un kararıdır; mimarın işi sistemin tam olarak ne yaptığını söylemektir: yeniden bağlanabilir mi, hangi anahtarlar kalıyor, eşlemeler nerede?

Sözcükleri kesin kullanın, çünkü farklı sorunları çözerler. Şifreleme veriyi yetkisiz ifşadan korur; yetkili bir kullanıcı yine de şifresini çözebilir. Maskeleme belirli kullanıcıların ya da ortamların gördüğünü değiştirir. Takma adlandırma doğrudan kimliği ayırır ama geri dönüş yolunu korur. Anonimleştirme kişiyi tanımlamanın makul olanağını ortadan kaldırır. Veriyi “kişisel” olmaktan yalnızca sonuncusu çıkarır.

Düzenleme Gereksinimlere Dönüşür

Hukuk’un bana bir izin kümesi oluşturmamı söylemesi gerekmez; bu çizginin benim tarafım. Hukuk “bu kişisel bilgi kategorisine yalnızca meşru bir iş ihtiyacı olan çalışanlar erişebilir” diyebilir. Sonra ben tercüme ederim: onlar kim, kategoriyi nasıl tanımlıyoruz, erişim nasıl veriliyor, biri iş değiştirdiğinde ne oluyor, bir entegrasyon onu okuyabilir mi, bir ajan okuyabilir mi, dışa aktarılabilir mi ve onu kimin gördüğünü nasıl kanıtlıyoruz? Sahipler politikayı belirler; mimarlar uygular. Hukuk ve uyumluluk yükümlülüğü belirler, veri sahipleri iş politikasını belirler, mimar da uygulamayı tasarlar.

Click to enlarge

Düzenlemeden kanıta: Hukuk yorumlar, sahip politikayı belirler, mimar onu çalışır ve kanıtlanabilir kılar.

Ve uyumluluk bir ürün değildir. “Uyumluluk: açık” satın alamazsınız. Şifreleme bir gereksinimi destekleyebilir, denetim özellikleri kanıt sağlar, saklama araçları politikayı yürütür, onay verisi izin verilen kullanımı destekler; ama bir özelliği lisanslamak bir mimariyi uyumlu yapmaz. Uyumluluk tüm tasarımdan gelir: insanlar, politika, süreç, veri, kontroller ve kanıt. Salesforce onun bir parçasıdır, tamamı değil. Ve bir politika uygulanacak kadar önemliyse kanıtlanacak kadar önemli olup olmadığını sorun: 17 Mart’ta bu kayda kim erişti, bu alanı kim değiştirdi, o dışa aktarım neyi içeriyordu? 6. modül kanıtı ele alıyor.

Gizlilik Haritayı Değiştirir

Steve Trucking’de Alıcının kişisel verisi üç ortak entegrasyonu aracılığıyla gelir. Salesforce’un teslimatları yürütmek için ona ihtiyacı var; ekiplerin bir kısmına ihtiyacı var, yalnızca kendi durakları için, yalnızca o gün; Snowflake teslimat analitiği istiyor; finansın faturalamaya yetecek kadarına ihtiyacı var, ama ekibin gördüklerine değil. Ve bir Perakende Ortağı asla bir başkasının Alıcılarını görmemelidir. Gizlilik okları değiştirir: belirli alanlar Snowflake’e gitmez, analitik daha az tanımlanabilir bir sürüm alır, ekipler yalnızca kendi duraklarını görür, aşağı akıştaki saklama operasyonel saklamadan farklıdır. Gizlilik gereksinimi harita diyagramının yanında durmaz. Onu değiştirir.

Düzenlemelerden Daha Uzun Yaşayan Sorular

Düzenlemeler değişir; bu yüzden hassas ya da düzenlemeye tabi her veri için kalıcı bir soru kümesi taşıyın:

• Bu nedir? Kişisel, hassas, finansal, sağlık, ödeme, çocuklara ait ya da başka biçimde düzenlemeye tabi mi?
• Nerede yaşıyor? Her kopya: entegrasyonlar, geçmiş, analitik, arşivler, sandbox’lar, günlükler, yapay zekâ kullanımı.
• Onu neden kullanabiliriz? Hangi amaç ve hukuki dayanak geçerli? Onay söz konusu mu?
• Onu kim kullanabilir? İnsanlar, sistemler, ortaklar, entegrasyonlar, ajanlar.
• Onu ne kadar süre saklıyoruz ve sonunda ne oluyor?
• Kişi onun üzerindeki haklarını kullanabilir mi? Yasanın öngördüğü ölçüde erişim, düzeltme, silme, taşınabilirlik, itiraz.
• Ne olduğunu kanıtlayabilir miyiz? Erişim, değişiklikler, dışa aktarımlar, onay, silme, saklama.

Yapay Zekâ Yönetişimi Yasaya Dönüşüyor

Yapay zekâ, yönetilen verinin bir tüketicisini daha ekler. Bir yapay zekâ sistemi bu veriyi kullanabilir mi, hangi amaçla, temellendirme olarak mı, neyle birleştirilerek, çıktısında tekrarlanarak mı, nerede ve ne kadar süre günlüğe kaydedilerek? Yapay zekânın yönetişimi şirket politikasından yasaya geçiyor: Avrupa Birliği’nin Yapay Zekâ Yasası (Regulation (EU) 2024/1689 (opens in a new tab)) ilk kapsamlı örnek. Neyi gerektirdiği sisteme ve kullanıma bağlı. Mimarlar için yön açık: yapay zekâ yönetişimin dışında durmaz; yönetilen verinin bir başka tüketicisidir.

Mimarın Burada Karar Verdikleri

• Düzenlemeye tabi ya da hassas verinin harita genelinde nereden girdiği, nerede yaşadığı, nereye hareket ettiği ve nereye kopyalandığı.
• Mimar yasayı yorumlamadan hukuk ve uyumluluk politikasının nasıl uygulanabilir gereksinimlere dönüştüğü.
• Hassas veriyi alan her sistemin ona ihtiyacı olup olmadığı ya da daha az tanımlanabilir bir sürümün yetip yetmeyeceği.
• Saklama, silme, anonimleştirme, takma adlandırma, koruma ve kanıtın verinin yaşam döngüsünü nasıl şekillendirdiği.
• Önemli kontrollerin gerçekten işe yaradığını göstermek için hangi kanıtların var olması gerektiği.

Düzenlemeler adları bir slayta konarak mimariye dönüşmez. Verinin nasıl toplandığını, sınıflandırıldığını, taşındığını, korunduğunu, saklandığını, silindiğini ve kanıtlandığını değiştirdiklerinde mimariye dönüşürler.

Daha Fazlası

• Düzenlemelerin resmî kaynakları yukarıdaki tabloda bağlantılı (İngilizce ve diğer diller), kontrol tarihi 2026-10-14.
• Regulation (EU) 2016/679 (GDPR) (opens in a new tab): 3. Madde (ülkesel kapsam), 4(5). Madde (takma adlandırma), 26. Gerekçe (anonim bilgi).
• Regulation (EU) 2024/1689 (Yapay Zekâ Yasası) (opens in a new tab), EUR-Lex.