Zákony o ochraně soukromí formují návrh

🌐 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 4 z 6 kapitoly Kvalita dat a správa dat, kapitoly 5 kurzu Data Architect. Každý modul stojí sám o sobě. Předchozí: Znejte svá data · Další: Souhlas a právo být zapomenut

Otázka, na kterou tento modul odpovídá: Co od návrhu v Salesforce chtějí předpisy o ochraně soukromí a odvětvové předpisy?

Když jsem pracoval v Austrálii, potkal jsem spoustu začínajících architektů, kteří o GDPR nikdy neslyšeli. Evropané zase často neslyšeli o kalifornském zákoně o ochraně soukromí, ani o kanadském nebo brazilském. Je to přirozené: znáte pravidla tam, kde pracujete. Tyto zákony ale sahají přes hranice a formují návrh systémů, přestože žádný z nich není o Salesforce. Proto patří do kurzu datové architektury.

Nemusíte se stát advokátem. Musíte ale vidět, že předpis může změnit, kde se data ukládají, co sbíráte, kdo je vidí, proč je smíte používat, jak dlouho je uchováváte, kam je posíláte, jestli je můžete smazat, jakou historii uchováváte a co můžete později prokázat. To nejsou jen právní otázky. Jsou to otázky datové architektury.

Tento modul je architektonické vodítko, ne právní rada. Které zákony platí a co vyžadují, rozhodují právní a compliance týmy. Architekt tyto požadavky převádí na vynutitelný návrh.

Zákony se nezastaví na hranici

Nejdřív největší omyl: „nejsme v Evropě, takže GDPR se na nás nevztahuje.“ Možná, možná ne. Územní působnost GDPR sahá i na organizace mimo EU, které nabízejí zboží nebo služby lidem v EU, nebo tam monitorují jejich chování (čl. 3, Nařízení (EU) 2016/679 (otevře se v nové kartě)). To, kde má vaše firma sídlo, tedy otázku neuzavírá. Kde jsou vaši zákazníci, zaměstnanci, lidé, jejichž data držíte, vaše systémy, vaši zpracovatelé? Kam data cestují? To je zase krajina z kapitoly 4. Bez znalosti toho, kam data jdou, nemůžete dělat dobrá rozhodnutí o soukromí.

Předpisy, které byste měli poznat

Tady jsou názvy, které by měl architekt znát, s tím, co každý pokrývá. Je to tabulka k rozpoznání, ne matice použitelnosti: nečtěte ji a nerozhodujte „máme zákazníky v Kalifornii, takže platí požadavek X“. To rozhoduje právní oddělení. Vaším úkolem je vědět dost na to, abyste se zeptali dřív, než se systém postaví.

Zákon nebo standard	Kde nebo co	Proč by ho měl architekt poznat
GDPR (otevře se v nové kartě)	Evropská unie	Osobní údaje, zákonné zpracování, práva jednotlivců, uchovávání, předávání, ochrana soukromí už od návrhu
CCPA, ve znění CPRA (otevře se v nové kartě)	Kalifornie	Práva spotřebitelů k osobním informacím, které o nich firmy sbírají
PIPEDA (otevře se v nové kartě)	Kanada	Jak organizace soukromého sektoru zacházejí s osobními informacemi
LGPD (otevře se v nové kartě)	Brazílie	Obecný brazilský zákon o ochraně osobních údajů
Privacy Act 1988 (otevře se v nové kartě)	Austrálie	Jak organizace zacházejí s osobními informacemi podle Australian Privacy Principles
HIPAA (otevře se v nové kartě)	Zdravotnictví v USA	Chráněné zdravotní informace v pokrytých kontextech
PCI DSS (otevře se v nové kartě)	Platební karty	Ochrana dat účtů platebních karet
Sarbanes-Oxley (SOX) (otevře se v nové kartě)	Veřejně obchodované společnosti v USA	Kontroly a důkazy za finančním výkaznictvím
COPPA (otevře se v nové kartě)	USA, děti online	Osobní informace sbírané online od dětí

Seznam roste (další státy USA mají vlastní zákony) a zákony se mění. Proto nechci, abyste se naučili tabulku nazpaměť a mysleli si, že jste se naučili architekturu ochrany soukromí. Naučte se názvy a pak otázky, které je přežijí.

Co mají zákony společného

Podrobnosti se liší, ale velké zákony o ochraně soukromí se pořád vracejí k několika stejným věcem a každá z nich dopadá na architekturu.

Práva. Lidé mohou žádat, aby viděli svá data, opravili je, smazali je a vzali si je s sebou; podle kalifornského a brazilského zákona mohou také odmítnout jejich prodej. Každá z těch žádostí znamená najít data té osoby, všechna.

Předávání. GDPR a LGPD kontrolují osobní údaje opouštějící jejich jurisdikci a požadují přiměřenou ochranu tam, kam jdou; PIPEDA očekává stejnou úroveň ochrany, když data zpracovává třetí strana, ať je kdekoli. To je zase krajina: které šipky překračují hranici?

Ohlašování porušení zabezpečení. Když dojde k úniku osobních údajů, zákony očekávají, že to oznámíte úřadům a někdy i dotčeným lidem, ve lhůtě, která se podle zákona liší. Nemůžete ohlásit data, o kterých jste nevěděli, že je máte, ani říct, co uniklo, když nenajdete kopie.

Odpovědnost (accountability). Musíte umět soulad doložit: záznamy o tom, co zpracováváte a proč, posouzení vlivu u vysoce rizikového zpracování a podle GDPR a LGPD pověřence pro ochranu osobních údajů. Ty záznamy musí architektura vytvářet.

Začněte tím, co je osobní

Než začnete chránit osobní informace, najděte je. Některé jsou zjevné: jméno, adresa bydliště, telefon, e-mail. Některé ne: poloha, identifikátory zařízení, IP adresy, obrázky, data o chování, cokoli, co lze zpětně spojit s osobou. A záleží na kontextu. Doručení ve Steve Trucking nese jméno příjemce, adresu, telefonní číslo, poznámky k doručení a fotky. Fotka může ukazovat krabici na verandě, nebo osobu, nebo interiér domova. Doručení jsou provozní data, ale některé jeho atributy jsou osobní. Proto modul 3 klasifikoval pole: ochrana soukromí začíná tím, že víte, co držíte.

Kde to žije?

„V Salesforce.“ Nejspíš ne jen v Salesforce. Přišlo to od maloobchodního partnera? Zkopírovalo se to do Snowflake, načetlo do Data 360, zapsalo do logu integrace, vyexportoval to uživatel, zůstalo to v historii polí, archivovalo se to, zkopírovalo do sandboxu, předalo partnerovi, použilo v konverzaci agenta? Osobní údaje se šíří. Když se tedy právní oddělení zeptá „kde držíme informace o této osobě?“, odpověď „víme, kde je aktuální hodnota“ nestačí. Chci krajinu a původ: kam šly kopie.

Kliknutím zvětšíte

Jedno telefonní číslo, mnoho kopií. Ochrana soukromí platí i pro kopie.

Proč to smíte používat?

Mít data a smět je používat není totéž. Steve Trucking má telefonní číslo příjemce, aby mohl koordinovat dnešní doručení. Dělá to z něj marketingový seznam? Ne. Právní základ závisí na jurisdikci a situaci a vede ho právní oddělení, ale architektura musí nést odpověď: proč se data sbírala, jaké použití bylo povoleno, jestli byl potřeba souhlas, jestli byl dán, odvolán, a pro jaký kanál, adresu a účel. Povolení data používat musí být reprezentovatelné jako data, protože dokument se zásadami nedokáže rozhodovat za běhu. Další modul to namodeluje.

Sbírat méně je architektonické rozhodnutí

Jednou z nejsilnějších kontrol ochrany soukromí je data nesbírat, nebo je nekopírovat tam, kde nejsou potřeba. Potřebuje Snowflake telefonní číslo příjemce? Potřebuje analytika celou adresu ulice? Potřebuje sandbox skutečné fotky z doručení? Potřebuje agent osobní údaje příjemce, aby odpověděl na tuto otázku? Pokud ne, nejsilnější kontrolou může být je tam nedávat. Každá kopie, kterou neuděláte, je kopie, kterou nemusíte zabezpečovat, uchovávat, mazat, sledovat u ní souhlas, auditovat ani hlásit při úniku. Nejlevnější citlivá data na správu jsou ta, která jste nikdy nezkopírovali.

Uchovávání je součástí modelu

„Zatím si necháme všechno“ je politika uchovávání. Jen špatná. U důležitých dat chci už při návrhu vědět, jak dlouho je potřebujeme a proč; jestli nějaký předpis stanovuje minimum a jiný maximum; kdy začíná běžet lhůta; a co se stane na konci: smazat, archivovat, deidentifikovat, a kde jsou kopie? Finanční záznamy může být nutné uchovávat stanovenou dobu. Kód brány příjemce nemá roky po doručení žádný účel. Tato rozhodnutí nečekají, až bude databáze velká.

Anonymizováno, pseudonymizováno, šifrováno, maskováno

Nahraďte „Jane Smith“ za 7F92A1. Je Jane anonymizovaná? Ne, pokud jiná tabulka pořád říká 7F92A1 = Jane Smith. To je pseudonymizace: přímý identifikátor je nahrazen, ale data lze znovu propojit pomocí informací uchovávaných zvlášť, a podle GDPR jsou pseudonymizované údaje pořád osobní údaje (čl. 4 bod 5). Anonymizace jde dál: data už nelze rozumně spojit s osobou (bod odůvodnění 26). Když tedy někdo řekne „nemusíme to mazat, jen odstraníme jméno“, buďte opatrní. Pokud lze osobu pořád rozumně identifikovat, tu hranici jste nepřekročili. Jestli výsledek splňuje zákon, rozhoduje právní oddělení; úkolem architekta je přesně říct, co systém dělá: dá se to znovu propojit, jaké klíče zůstávají, kde jsou mapování?

Používejte slova přesně, protože řeší různé problémy. Šifrování chrání data před neoprávněným zpřístupněním; oprávněný uživatel je pořád může dešifrovat. Maskování mění, co vidí konkrétní uživatelé nebo prostředí. Pseudonymizace odděluje přímou identitu, ale ponechává cestu zpět. Anonymizace odstraňuje rozumnou možnost osobu identifikovat. Jen ta poslední vyjme data z kategorie „osobní“.

Z předpisu se stávají požadavky

Právní oddělení mi nemusí říkat, ať vytvořím sadu oprávnění; to je moje strana hranice. Právní oddělení může říct „k této kategorii osobních informací smějí přistupovat jen zaměstnanci s oprávněnou obchodní potřebou“. Pak překládám: kdo to je, jak identifikujeme tu kategorii, jak se přístup uděluje, co se stane, když někdo změní práci, může to číst integrace, může agent, dá se to exportovat a jak prokážeme, kdo to viděl? Vlastníci stanovují zásady; architekti je vynucují. Právní a compliance oddělení stanoví povinnost, vlastníci dat stanoví obchodní zásadu a architekt navrhne vynucení.

Kliknutím zvětšíte

Od předpisu k důkazu: právní oddělení vykládá, vlastník stanovuje zásadu, architekt zajistí, aby fungovala a byla prokazatelná.

A soulad (compliance) není produkt. Nemůžete si koupit „compliance: zapnuto“. Šifrování může podpořit požadavek, auditní funkce poskytují důkazy, nástroje pro uchovávání provádějí zásady, data o souhlasu podporují povolené použití, ale licence na funkci z architektury soulad neudělá. Soulad pochází z celého návrhu: lidé, zásady, proces, data, kontroly a důkazy. Salesforce je jeho součástí, ne celkem. A pokud na zásadě záleží natolik, abyste ji vynucovali, zeptejte se, jestli na ní záleží natolik, abyste ji prokazovali: kdo přistupoval k tomuto záznamu 17. března, kdo změnil toto pole, co obsahoval ten export? Důkazy pokrývá modul 6.

Ochrana soukromí mění krajinu

Ve Steve Trucking přicházejí osobní údaje příjemců přes tři integrace partnerů. Salesforce je potřebuje k provozu doručení; posádky potřebují jejich část, jen u svých vlastních zastávek a jen v daný den; Snowflake chce analytiku doručení; finance potřebují dost na fakturaci, ale ne to, co vidí posádka. A jeden maloobchodní partner nikdy nesmí vidět příjemce jiného. Ochrana soukromí mění šipky: určitá pole nejdou do Snowflake, analytika dostane méně identifikovatelnou verzi, posádky vidí jen své zastávky, uchovávání po proudu se liší od provozního. Požadavek ochrany soukromí nesedí vedle diagramu krajiny. Mění ho.

Otázky, které přežijí předpisy

Předpisy se mění, takže si pro citlivá nebo regulovaná data noste trvalou sadu otázek:

• Co to je? Osobní, citlivé, finanční, zdravotní, platební, dětské nebo jinak regulované?
• Kde to žije? Každá kopie: integrace, historie, analytika, archivy, sandboxy, logy, použití AI.
• Proč to smíme používat? Jaký účel a právní základ platí? Hraje roli souhlas?
• Kdo to smí používat? Lidé, systémy, partneři, integrace, agenti.
• Jak dlouho to uchováváme a co se stane na konci?
• Může osoba uplatnit svá práva? Přístup, oprava, výmaz, přenositelnost, námitka, jak zákon stanoví.
• Dokážeme prokázat, co se stalo? Přístup, změny, exporty, souhlas, výmaz, uchovávání.

Správa AI se stává zákonem

AI přidává dalšího spotřebitele řízených dat. Smí systém AI tato data používat, k jakému účelu, jako ukotvení, v kombinaci s čím, opakovaná ve svém výstupu, zalogovaná kde a jak dlouho? Správa AI se přesouvá z firemních zásad do zákona: akt Evropské unie o umělé inteligenci (Nařízení (EU) 2024/1689 (otevře se v nové kartě)) je prvním širokým příkladem. Co vyžaduje, závisí na systému a použití. Směr pro architekty je jasný: AI nestojí mimo správu dat; je to další spotřebitel řízených dat.

Co tady rozhoduje architekt

• Kde regulovaná nebo citlivá data vstupují, žijí, pohybují se a kopírují napříč krajinou.
• Jak se zásady právního a compliance oddělení stávají vynutitelnými požadavky, aniž by architekt vykládal zákon.
• Zda každý systém, který dostává citlivá data, je potřebuje, nebo by stačila méně identifikovatelná verze.
• Jak uchovávání, výmaz, anonymizace, pseudonymizace, ochrana a důkazy utvářejí životní cyklus dat.
• Jaké důkazy musí existovat, aby ukázaly, že důležité kontroly skutečně fungovaly.

Předpisy se nestávají architekturou tím, že jejich názvy dáte na slajd. Stávají se jí, když mění, jak se data sbírají, klasifikují, přesouvají, chrání, uchovávají, mažou a prokazují.

K prozkoumání

• Oficiální zdroje předpisů jsou odkázané v tabulce výše, ověřeno 2026-10-17.
• Nařízení (EU) 2016/679 (GDPR) (otevře se v nové kartě): čl. 3 (územní působnost), čl. 4 bod 5 (pseudonymizace), bod odůvodnění 26 (anonymní informace).
• Nařízení (EU) 2024/1689 (akt o umělé inteligenci) (otevře se v nové kartě), EUR-Lex.