Souhlas a právo být zapomenut

🌐 K dispozici také v 29 jazycích

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

Obrázek vytvořený pomocí AI

Přeloženo pomocí AI. Komunita překlad zatím nezkontrolovala. Číst anglicky

Modul 5 z 6 kapitoly Kvalita dat a správa dat, kapitoly 5 kurzu Data Architect. Každý modul stojí sám o sobě. Předchozí: Zákony o ochraně soukromí formují návrh · Další: Chraňte, uchovávejte a prokazujte

Otázka, na kterou tento modul odpovídá: Jak navrhovat pro souhlas a pro výmaz osoby?

Steve Trucking má telefonní číslo příjemce. Jednoduchá otázka: můžeme mu poslat SMS? Možná. O dnešním doručení? O zítřejším? Můžeme číslo použít pro propagační akci? Co když řekl ne SMS, nebo ano aktualizacím o doručení, ale ne marketingu, a pak si to rozmyslel?

Teď opačný směr. Příjemce řekne: smažte mé osobní údaje. Kde jsou? V Salesforce, nejspíš, ale už víme, že to není celá odpověď. Přišly od maloobchodního partnera. Mohou být v platformě zákaznických dat, v historii polí, v archivu, v poznámce k doručení, v exportu, v logu integrace, v konverzaci agenta. Souhlas a výmaz znějí jako otázky zásad, ale nakonec na ně musí odpovědět systém. To je architektura.

Souhlas jsou data

První princip: souhlas jsou data. Nesnižujte ho na Has_Opted_In__c = true. Skutečná otázka nikdy nezní jen „dal souhlas?“ Zní souhlas s čím, přes jaký kanál, na jakou adresu nebo číslo, k jakému účelu, kdy, změnil se a dokážeme to prokázat? Pokud byznys podle těchto odpovědí rozhoduje, musí být uložené jako strukturovaná data. Odstavec v zásadách ochrany soukromí nestačí a zaškrtávací políčko na webovém formuláři také ne: políčko zachytí událost; architektura musí uchovat, co ta událost znamená.

Použijte model, který Salesforce už postavil

Můj postoj: kde to jde, používejte vestavěný model souhlasů, místo abyste totéž stavěli znovu ve vlastních polích. Datový model souhlasů v Salesforce spravuje souhlas na čtyřech úrovních, každá je konkrétnější otázkou (Understand the Salesforce Consent Data Model (otevře se v nové kartě)):

• Globální souhlas, na jednotlivci (Individual): kdo je ta osoba a řekla ne všemu?
• Souhlas pro kanál komunikace (Contact Point Type Consent): smíme použít tento druh kanálu, třeba SMS nebo e-mail?
• Souhlas pro kontaktní bod (Contact Point Consent): co toto konkrétní telefonní číslo nebo e-mailová adresa?
• Účel použití dat (Data Use Purpose): z jakého důvodu: oznámení o doručení, servis, marketing?

Dohromady dokáže architektura odpovědět na otázku „smíme použít informace této osoby, přes tento kontaktní bod, k tomuto účelu?“, což je mnohem užitečnější než „souhlas = ano“. Zapojit se může jakýkoli záznam, který se vztahuje k jednotlivci: zájemci, kontakty, osobní účty, uživatelé.

Kliknutím zvětšíte

Čtyři otázky, každá užší než ta předchozí. Jediný příznak přihlášení na žádnou z nich dobře neodpoví.

Na účelu záleží

Maloobchodní partner pošle Steve Trucking číslo příjemce, aby posádka mohla doručení koordinovat. To z příjemce nedělá marketingového zájemce. Stejná data mohou mít různá povolená použití: koordinace doručení, servisní kontakt, marketing, personalizace pomocí AI. Pokud s nimi zásady nebo zákon zacházejí různě, musí je model rozlišit. Otázka nezní máme telefonní číslo? Zní co s ním smíme dělat?

A souhlas není vždycky právním základem. Některá použití stojí na jiných důvodech, které zákon poskytuje, a to určuje právní oddělení. Nestavte architekturu, která předpokládá, že každé rozhodnutí o soukromí je zaškrtávací políčko přihlášení. Podporujte, cokoli zásada říká: pokud použití závisí na souhlasu, modelujte a vynucujte souhlas; pokud platí jiný základ, pořád ukládejte, co je potřeba k rozhodnutí, jestli je použití povolené.

Souhlas má životní cyklus a autoritu

Lidé souhlas udělují, odvolávají, mění preference, mění čísla. Byznys přidává nové účely; zákony se mění. Navrhněte tedy životní cyklus: co bylo zvoleno, kdy, jak, k jakému účelu a co se stane při odvolání. A tady to začne být zajímavé: když příjemce souhlas odvolá, Salesforce to ví. Ví to platforma pro zasílání zpráv? Analytika? Agent? Souhlas, který žije v jednom systému, zatímco ostatní jednají podle zastaralého povolení, není moc dobrá kontrola.

To znamená ptát se, který systém je pro souhlas autoritativní. Salesforce, platforma preferencí, něco jiného? Ať je odpověď jakákoli, nenechte pět systémů nezávisle rozhodovat, jestli stejná osoba souhlasila se stejným použitím. Souhlas potřebuje, co potřebují jakákoli řízená data: vlastníka, autoritativní záznam, způsob synchronizace a vynucení.

Teď osoba řekne: zapomeňte mě

Prvním instinktem je smazat kontakt a prohlásit to za hotové. Údaje osoby ale mohou být na kontaktu, na doručení, v poznámce k doručení, v případu, na fotce, v historii polí, ve Snowflake, v archivu, v logu integrace, ve vyhledávacím indexu nebo v historii konverzací agenta. Proto můj postoj k výmazu začíná dřív: výmaz je v praxi vzácný a těžký, takže nejdřív řiďte, kam osobní údaje jdou. Navrhněte to tak, aby přistály na co nejméně místech. Pak, když přijde žádost, je zamaskujte nebo od osoby oddělte tam, kde to zásadě vyhoví, a vypátrejte každou kopii: historii polí, archivy, Data 360 a teď i vyhledávací indexy a konverzace agentů.

Nezačínejte pátrat, až žádost přijde. Tehdy už je pozdě začínat chápat krajinu. Slovník, původ a klasifikace z modulu 3 nebyly papírování; právě ony to umožňují. Už víte, která pole drží osobní údaje a kam šly kopie.

Kliknutím zvětšíte

Žádost o zapomenutí je rozhodnutím pro každou kopii.

Hodiny běží

Tyto žádosti přicházejí s termíny. Podle GDPR musí organizace žádost osoby vyřídit bez zbytečného odkladu a do jednoho měsíce od jejího obdržení; u složitých nebo početných žádostí lze lhůtu prodloužit o další dva měsíce, ale osoba musí být informována během prvního měsíce, i s důvody (čl. 12 odst. 3, Nařízení (EU) 2016/679 (otevře se v nové kartě)). Jiné zákony stanoví vlastní lhůty; které platí, vám řekne právní oddělení. Tak či onak měsíc nestačí na to, abyste krajinu objevili. To je termín, který musí mapa kopií porazit.

Smazat, deidentifikovat, nebo uchovat?

Žádost nutně neznamená, že všechno všude zmizí. Některé záznamy se musí nebo smějí uchovat; některé provozní záznamy mohou zůstat, ale přestat osobu identifikovat; některá data lze deidentifikovat. Rozhodují platné zásady a zákon; architektura podporuje každý výsledek, místo po místu: smazat, deidentifikovat, nebo uchovat na základě schváleného požadavku (a pak kdo to smí vidět, jak dlouho, proč?).

Vzpomeňte si na rozlišení z modulu 4. Oddělení od osoby se počítá jako zapomenutí, jen když osobu nelze rozumně znovu identifikovat. Pseudonymizované údaje jsou pořád osobní údaje. Nepoužívejte maskování jako zkratku kolem zákonného požadavku.

Nemůžete smazat, co nenajdete

Než někoho vymažete, musíte ho najít. Žádost přijde z e-mailové adresy. Jeden maloobchodní partner poslal „Jane Smith“, jiný „J. Smith“ a telefonní číslo se změnilo. Příjemce vůbec není kontakt; jeho údaje sedí na každém doručení. Stejná osoba dostala doručení pro dva různé partnery. Jeden systém ji zná podle e-mailu, jiný podle externího ID. Výmaz závisí na identitě a nechcete smazat cizí data, protože bylo vaše párování příliš agresivní. Architektura identity je součástí architektury ochrany soukromí.

Steve Trucking to dělá ještě těžším. Jeden maloobchodní partner nikdy nesmí vidět doručení ani příjemce jiného. Pokud stejná osoba dostala doručení pro dva partnery, provoz musí ty vztahy držet odděleně, zatímco ochrana soukromí ji možná pořád potřebuje najít v obou. Neřešte ochranu soukromí prolomením bezpečnostní hranice a nechraňte hranici tím, že znemožníte žádosti o ochranu soukromí. Architektura musí dělat obojí.

I fotky a volný text jsou data

Je snadné vnímat ochranu soukromí jako pole: jméno, e-mail, telefon, adresa. Steve Trucking ale ročně pořídí miliony fotek z doručení a některé ukazují lidi nebo interiér domova. Zásada uchovávání nebo výmazu, která se dívá jen na strukturovaná pole, je neúplná; stejně tak ta, která ignoruje soubory, dokumenty, přepisy, logy a prompty a odpovědi AI.

A volný text je nebezpečný. Odstraníte jméno, telefon a adresu a pak najdete tuto poznámku k doručení: „Zavolejte Jane na 602-555-0198. Kód brány 4821. Pes je na zahradě.“ A je to tam. Klasifikace poznámek k doručení jako citlivých vám řekne, že tu může být problém; osobní údaje uvnitř textu nenajde a neodstraní. Někdy je nejlepší odpovědí vůbec nepustit zbytečné osobní údaje tam. Nejdřív řiďte, kam osobní údaje jdou.

Privacy Center je nástroj, ne celá architektura

Privacy Center od Salesforce pomáhá tyto procesy provozovat. Jeho zásady práva být zapomenut se staví po objektech, aby zachytily všechno, co chcete odstranit, a spouštějí se proti konkrétnímu záznamu zákazníka (Delete Data with Right to Be Forgotten Policies (otevře se v nové kartě)). To je užitečné. „Koupili jsme Privacy Center, takže máme hotovo“ ale není architektura. Údaje osoby mohou žít mimo dosah kteréhokoli jednoho nástroje: Data 360, datový sklad, systémy partnerů, archivy, logy, vyhledávání, soubory, konverzace agentů. Podnik pořád potřebuje podnikovou odpověď a vy potřebujete zkontrolovat, co každý nástroj skutečně pokrývá, než se na něj spolehnete.

Přenositelnost a důkaz

Některé zákony také dávají lidem právo dostat kopii svých dat. Všimněte si, že je to stejný problém hledání: výmaz se ptá kde jsou data této osoby, abychom s nimi mohli něco udělat? Přenositelnost se ptá kde jsou, abychom je mohli poskytnout? Obojí stojí na identitě, klasifikaci, původu, inventuře systémů a vlastnictví.

A pak: jak prokážete, že jste to udělali? Žádost přijata, identita ověřena, systémy prohledány, kroky provedeny, výjimky zaznamenány, uchovaná data zdůvodněna, dokončení zalogováno. Je tu skutečné napětí: odstraňujete něčí osobní údaje a zároveň si ponecháváte dost důkazů, abyste ukázali, že jste žádost vyřídili správně. Právě proto by si architekti neměli pravidla uchovávání vymýšlet sami. Které důkazy musí zůstat, rozhoduje právní a compliance oddělení; architektura je uchová, aniž by uchovala data, která měla odstranit.

Nad rámec zkoušky: co mění AI. AI vytváří nové účely a nové kopie. Povolení používat data k poskytování služby automaticky nepokrývá ukotvení agenta, personalizaci ani trénování; Data Use Purpose je přirozené místo, kde je od sebe odlišit. A osobní údaje mohou přežívat v promptech, kontextu pro ukotvení, konverzacích, souhrnech, vyhledávacích a vektorových indexech a v logech. „Smazali jsme zdrojový záznam“ není úplná odpověď, pokud si to vrstva AI pořád pamatuje.

Co tady rozhoduje architekt

• Jak se modeluje souhlas a povolené použití, aby systémy dokázaly odpovědět kdo, jaký kanál, jaký kontaktní bod a jaký účel.
• Který systém je pro souhlas autoritativní a jak se odvolání dostanou ke každému systému, který podle něj jedná.
• Kam se osobní údaje mohou šířit: pole, volný text, soubory, historie, analytika, archivy, integrace, vyhledávání a AI.
• Jak žádost najde správnou osobu a na každém místě řídí výmaz, deidentifikaci, nebo schválené uchování.
• Jaké důkazy zůstanou, aby prokázaly, že souhlas a žádosti o ochranu soukromí byly vyřízeny.

Souhlas a výmaz vypadají jako protiklady (smíme tato data používat? dokážeme přestat a odstranit je?), ale stojí na stejných základech: identitě, účelu, klasifikaci, původu, vlastnictví, vynucení a důkazech. Používejte standardní model souhlasů, řiďte, kam osobní údaje jdou, vězte, kde jsou kopie, a navrhněte proces výmazu dřív, než přijde první žádost. Když se někdo zeptá „můžete mě zapomenout?“, potřebuje architektura lepší odpověď než „myslíme, že ano“.

K prozkoumání

• Salesforce Help, Understand the Salesforce Consent Data Model (otevře se v nové kartě), ověřeno 2026-10-17.
• Nařízení (EU) 2016/679 (GDPR) (otevře se v nové kartě), čl. 12 odst. 3, lhůta pro vyřízení žádosti, ověřeno 2026-10-17.
• Salesforce Help, Delete Data with Right to Be Forgotten Policies (otevře se v nové kartě) (Privacy Center), ověřeno 2026-10-17.