Onay ve Unutulma Hakkı

🌐 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 5.‘i. Her modül kendi başına okunabilir. Önceki: Gizlilik Yasaları Tasarımı Şekillendirir · Sonraki: Koruyun, Saklayın ve Kanıtlayın

Bu modülün yanıtladığı soru: Onay için ve bir kişiyi silmek için nasıl tasarım yaparsınız?

Steve Trucking’in bir Alıcının telefon numarası var. Basit soru: ona mesaj atabilir miyiz? Belki. Bugünkü teslimat hakkında mı? Yarınki? Numarayı bir promosyon için kullanabilir miyiz? Peki ya mesaj istemediğini söylediyse ya da teslimat güncellemelerine evet ama pazarlamaya hayır dediyse ve sonra fikrini değiştirdiyse?

Şimdi öbür yön. Alıcı diyor ki: kişisel bilgilerimi silin. Nerede? Muhtemelen Salesforce’ta, ama bunun yanıtın tamamı olmadığını öğrendik. Bir Perakende Ortağından geldi. Bir müşteri veri platformunda, alan geçmişinde, bir arşivde, bir teslimat notunda, bir dışa aktarımda, bir entegrasyon günlüğünde, bir ajanın konuşmasında olabilir. Onay ve silme politika soruları gibi görünür, ama sonunda sistemin onları yanıtlaması gerekir. Bu mimaridir.

Onay Veridir

İlk ilke: onay veridir. Onu Has_Opted_In__c = true değerine indirgemeyin. Asıl soru hiçbir zaman yalnızca “onay verdi mi?” değildir. Onay neye, hangi kanal üzerinden, hangi adreste ya da numarada, hangi amaçla, ne zaman verildi, değişti mi ve kanıtlayabilir miyiz? İş bu yanıtlara göre karar veriyorsa yapılandırılmış veri olarak saklanmaları gerekir. Bir gizlilik politikasındaki bir paragraf yeterli değildir, bir web formundaki onay kutusu da: onay kutusu bir olayı yakalar; mimari o olayın ne anlama geldiğini saklamalıdır.

Salesforce’un Zaten Kurduğu Modeli Kullanın

Pozisyonum: mümkün olan her yerde hazır onay modelini kullanın; aynı şeyi özel alanlarda yeniden inşa etmeyin. Salesforce’un onay veri modeli onayı dört düzeyde yönetir; her biri daha belirli bir sorudur (Understand the Salesforce Consent Data Model (opens in a new tab), İngilizce):

• Genel onay, Individual (Birey) kaydında: bu kişi kim ve her şeye hayır dedi mi?
• Etkileşim kanalı onayı (Contact Point Type Consent): SMS ya da e-posta gibi bu tür bir kanalı kullanabilir miyiz?
• İletişim noktası onayı: bu belirli telefon numarası ya da e-posta adresi için ne durumdayız?
• Veri kullanım amacı: hangi nedenle: teslimat bildirimleri, servis, pazarlama?

Bunlar bir araya geldiğinde mimari “bu kişinin bilgilerini, bu iletişim noktası üzerinden, bu amaçla kullanabilir miyiz?” sorusunu yanıtlayabilir; bu da “onay = evet”ten çok daha yararlıdır. Bir bireyle ilişkili her kayıt buna katılabilir: potansiyel müşteriler, kişiler, kişi hesapları, kullanıcılar.

Click to enlarge

Her biri bir öncekinden daha dar dört soru. Tek bir onay bayrağı hiçbirini iyi yanıtlamaz.

Amaç Önemlidir

Bir Perakende Ortağı, ekip teslimatı koordine edebilsin diye Steve Trucking’e bir Alıcının numarasını gönderiyor. Bu, Alıcıyı bir pazarlama potansiyel müşterisi yapmaz. Aynı verinin farklı izin verilen kullanımları olabilir: teslimat koordinasyonu, servis takibi, pazarlama, yapay zekâ ile kişiselleştirme. Politika ya da yasa bunları farklı ele alıyorsa model onları birbirinden ayırabilmelidir. Soru telefon numarasına sahip miyiz? değildir. Onunla ne yapmamıza izin var? sorusudur.

Ve onay her zaman hukuki dayanak değildir. Bazı kullanımlar yasanın öngördüğü başka dayanaklara dayanır ve bu Hukuk’un belirleyeceği bir şeydir. Her gizlilik kararının bir izin onay kutusu olduğunu varsayan bir mimari inşa etmeyin. Politika ne diyorsa onu destekleyin: bir kullanım onaya bağlıysa onayı modelleyin ve uygulayın; başka bir dayanak geçerliyse yine de kullanımın izinli olup olmadığına karar vermek için gerekeni saklayın.

Onayın Bir Yaşam Döngüsü ve Bir Yetkilisi Vardır

İnsanlar onay verir, geri çeker, tercihlerini değiştirir, numaralarını değiştirir. İş yeni amaçlar ekler; yasalar değişir. Bu yüzden yaşam döngüsünü tasarlayın: ne seçildi, ne zaman, nasıl, hangi amaç için ve geri çekildiğinde ne olur. Ve işin ilginçleştiği yer şu: bir Alıcı onayını geri çektiğinde Salesforce bunu bilir. Mesajlaşma platformu biliyor mu? Analitik? Ajan? Tek bir sistemde yaşayan ve diğerlerinin bayat izne göre hareket ettiği onay pek bir kontrol sayılmaz.

Bu, onay için hangi sistemin esas olduğunu sormak demektir. Salesforce mı, bir tercih platformu mu, başka bir yer mi? Yanıt ne olursa olsun, beş sistemin aynı kişinin aynı kullanıma onay verip vermediğine bağımsız olarak karar vermesine izin vermeyin. Onayın, yönetilen her verinin ihtiyaç duyduğu şeye ihtiyacı vardır: bir sahip, esas bir kayıt, bir eşitleme yolu ve uygulama.

Şimdi Kişi Diyor ki: Beni Unutun

İlk içgüdü kişi kaydını silip işi bitti saymaktır. Ama kişinin verisi bir kişi kaydında, bir teslimatta, bir teslimat notunda, bir vakada, bir fotoğrafta, alan geçmişinde, Snowflake’te, bir arşivde, bir entegrasyon günlüğünde, bir arama dizininde ya da bir ajanın konuşma geçmişinde olabilir. Silme konusundaki pozisyonumun daha erken başlamasının nedeni bu: silme pratikte nadir ve zordur; bu yüzden önce kişisel verinin nereye gittiğini kontrol edin. Mümkün olduğunca az yere düşecek şekilde tasarlayın. Sonra bir talep geldiğinde, politikayı karşıladığı yerlerde onu gizleyin ya da bağlantısını koparın ve her kopyanın peşine düşün: alan geçmişi, arşivler, Data 360 ve artık arama dizinleri ve ajan konuşmaları.

Aramaya talep geldiğinde başlamayın. O zaman haritayı anlamaya başlamak için çok geçtir. 3. modülün sözlüğü, kökeni ve sınıflandırması evrak işi değildi; bunu mümkün kılan onlardır. Hangi alanların kişisel veri tuttuğunu ve kopyaların nereye gittiğini zaten bilirsiniz.

Click to enlarge

Bir beni unut talebi, her kopya için bir karardır.

Süre İşliyor

Bu talepler süreyle gelir. GDPR kapsamında kuruluş, bir kişinin talebine gereksiz gecikme olmadan ve talebi aldıktan sonra bir ay içinde işlem yapmak zorundadır; karmaşık ya da çok sayıda talep için bu süre iki ay daha uzatılabilir, ama kişiye ilk ay içinde nedenleriyle birlikte bilgi verilmelidir (Madde 12(3), Regulation (EU) 2016/679 (opens in a new tab), İngilizce). Diğer yasalar kendi sürelerini koyar; hangilerinin geçerli olduğunu Hukuk size söyler. Her iki durumda da bir ay, haritayı keşfetmeye yetecek kadar uzun değildir. Kopyaların haritasının yetişmesi gereken süre budur.

Silmek mi, Kimliksizleştirmek mi, Saklamak mı?

Bir talep, her şeyin her yerden yok olması anlamına gelmek zorunda değildir. Bazı kayıtların saklanması gerekir ya da saklanabilir; bazı operasyonel kayıtlar kalıp kişiyi tanımlamayı bırakabilir; bazı veriler kimliksizleştirilebilir. Geçerli politika ve yasa karar verir; mimari her sonucu konum konum destekler: silmek, kimliksizleştirmek ya da onaylı bir gereksinim altında saklamak (o zaman onu kim, ne kadar süre, neden görebilir?).

4. modüldeki ayrımı hatırlayın. Bağlantıyı koparmak, ancak kişi makul ölçüde yeniden tanımlanamadığında unutmak sayılır. Takma adlandırılmış veri hâlâ kişisel veridir. Gizlemeyi yasal bir gereksinimin etrafından dolaşmak için bir kısayol olarak kullanmayın.

Bulamadığınızı Silemezsiniz

Birini silmeden önce onu bulmanız gerekir. Talep bir e-posta adresinden geliyor. Bir Perakende Ortağı “Jane Smith”, bir diğeri “J. Smith” gönderdi ve telefon numarası değişti. Alıcı bir kişi kaydı bile değil; bilgileri her teslimatta duruyor. Aynı kişi iki farklı ortak için teslimat aldı. Bir sistem onu e-postasıyla, bir diğeri harici bir kimlikle biliyor. Silme kimliğe bağlıdır ve eşleştirmeniz fazla agresif olduğu için başka birinin verisini silmek istemezsiniz. Kimlik mimarisi gizlilik mimarisinin bir parçasıdır.

Steve Trucking bunu daha da zorlaştırıyor. Bir Perakende Ortağı asla bir başkasının teslimatlarını ya da Alıcılarını görmemelidir. Aynı kişi iki ortak için teslimat aldıysa operasyonlar bu ilişkileri ayrı tutmalıdır; gizlilik ise kişiyi her ikisinde de bulmak zorunda kalabilir. Gizliliği güvenlik sınırını bozarak çözmeyin, sınırı da gizlilik taleplerini imkânsız kılarak korumayın. Mimari ikisini birden yapmalıdır.

Fotoğraflar ve Serbest Metin de Veridir

Gizliliği alanlar olarak düşünmek kolaydır: ad, e-posta, telefon, adres. Ama Steve Trucking yılda milyonlarca teslimat fotoğrafı çekiyor ve bazıları insanları ya da bir evin içini gösteriyor. Yalnızca yapılandırılmış alanlara bakan bir saklama ya da silme politikası eksiktir; dosyaları, belgeleri, dökümleri, günlükleri ve yapay zekâ istemlerini ve yanıtlarını görmezden gelen de öyle.

Ve serbest metin tehlikelidir. Adı, telefonu ve adresi kaldırırsınız, sonra şu teslimat notunu bulursunuz: “Jane’i 602-555-0198’den arayın. Kapı şifresi 4821. Köpek bahçede.” İşte orada. Teslimat notlarını hassas olarak sınıflandırmak size bir sorun olabileceğini söyler; metnin içindeki kişisel veriyi bulup kaldırmaz. Bazen en iyi yanıt, gereksiz kişisel ayrıntıların oraya hiç düşmesini engellemektir. Önce kişisel verinin nereye gittiğini kontrol edin.

Privacy Center Bir Araçtır, Mimarinin Tamamı Değil

Salesforce Privacy Center bu süreçleri yürütmeye yardım eder. Unutulma hakkı politikaları, kaldırılmasını istediğiniz her şeyi yakalamak için nesne başına oluşturulur ve belirli bir müşteri kaydına karşı çalıştırılır (Delete Data with Right to Be Forgotten Policies (opens in a new tab), İngilizce). Bu yararlıdır. Ama “Privacy Center aldık, o halde işimiz bitti” bir mimari değildir. Kişinin verisi herhangi bir aracın ulaşamayacağı yerlerde yaşayabilir: Data 360, ambar, ortak sistemleri, arşivler, günlükler, arama, dosyalar, ajan konuşmaları. Kurumun yine de kurumsal bir yanıta ihtiyacı vardır ve her aracın gerçekte neyi kapsadığını ona güvenmeden önce kontrol etmeniz gerekir.

Taşınabilirlik ve Kanıt

Bazı yasalar insanlara verilerinin bir kopyasını alma hakkı da verir. Bunun aynı keşif sorunu olduğuna dikkat edin: silme bu kişinin verisi nerede ki ona göre işlem yapabilelim? diye sorar. Taşınabilirlik nerede ki onu sağlayabilelim? diye sorar. İkisi de kimliğe, sınıflandırmaya, kökene, sistem envanterine ve sahipliğe dayanır.

Ve sonra: bunu yaptığınızı nasıl kanıtlarsınız? Talep alındı, kimlik doğrulandı, sistemler tarandı, işlemler yapıldı, istisnalar kaydedildi, saklanan verinin gerekçesi gösterildi, tamamlanma günlüğe kaydedildi. Burada gerçek bir gerilim var: talebi doğru ele aldığınızı gösterecek kadar kanıt tutarken birinin kişisel verisini kaldırıyorsunuz. Mimarların saklama kurallarını kendi başlarına icat etmemesinin nedeni tam olarak bu. Hangi kanıtın kalması gerektiğine hukuk ve uyumluluk karar verir; mimari onu, kaldırması gereken veriyi tutmadan saklar.

Sınavın ötesinde: yapay zekânın değiştirdikleri. Yapay zekâ yeni amaçlar ve yeni kopyalar yaratır. Veriyi bir hizmet sağlamak için kullanma izni, bir ajanı temellendirmeyi, kişiselleştirmeyi ya da eğitimi otomatik olarak kapsamaz; Data Use Purpose (veri kullanım amacı) bunları ayırmanın doğal yeridir. Ve kişisel veri istemlerde, temellendirme bağlamında, konuşmalarda, özetlerde, arama ve vektör dizinlerinde ve günlüklerde yaşamaya devam edebilir. Yapay zekâ katmanı hâlâ hatırlıyorsa “kaynak kaydı sildik” tam bir yanıt değildir.

Mimarın Burada Karar Verdikleri

• Sistemler kim, hangi kanal, hangi iletişim noktası ve hangi amaç sorularını yanıtlayabilsin diye onayın ve izin verilen kullanımın nasıl modellendiği.
• Onay için hangi sistemin esas olduğu ve geri çekmelerin ona göre hareket eden her sisteme nasıl ulaştığı.
• Kişisel verinin nereye yayılabileceği: alanlar, serbest metin, dosyalar, geçmiş, analitik, arşivler, entegrasyonlar, arama ve yapay zekâ.
• Bir talebin doğru kişiyi nasıl bulduğu ve her konumda silmeyi, kimliksizleştirmeyi ya da onaylı saklamayı nasıl yönlendirdiği.
• Onayın ve gizlilik taleplerinin ele alındığını kanıtlamak için hangi kanıtların kaldığı.

Onay ve silme birbirinin zıddı gibi görünür (bu veriyi kullanabilir miyiz? durdurup kaldırabilir miyiz?), ama aynı temellere dayanırlar: kimlik, amaç, sınıflandırma, köken, sahiplik, uygulama ve kanıt. Standart onay modelini kullanın, kişisel verinin nereye gittiğini kontrol edin, kopyaların nerede olduğunu bilin ve ilk talep gelmeden silme sürecini tasarlayın. Biri “beni unutabilir misiniz?” diye sorduğunda mimarinin “sanırım”dan daha iyi bir yanıtı olmalıdır.

Daha Fazlası

• Salesforce Help, Understand the Salesforce Consent Data Model (opens in a new tab) (İngilizce), kontrol tarihi 2026-10-14.
• Regulation (EU) 2016/679 (GDPR) (opens in a new tab) (İngilizce), Madde 12(3), bir talep üzerine işlem yapma süresi, kontrol tarihi 2026-10-14.
• Salesforce Help, Delete Data with Right to Be Forgotten Policies (opens in a new tab) (Privacy Center, İngilizce), kontrol tarihi 2026-10-14.