Většina problémů s dodržováním předpisů jsou problémy návrhu

Pokud stavíte software v EU, dodržování předpisů se zřídka objeví na začátku. Stává se relevantním, když na systému začne záležet. Máte uživatele, možná zákazníky, a architektura se rozrostla nad rámec toho, co lze plně pochopit v hlavě. To je obvykle okamžik, kdy se objeví první skutečné otázky. Ne abstraktní, ale velmi konkrétní. Lze data uživatele skutečně smazat napříč systémem? Kam tato data končí, jakmile opustí vaši aplikaci? Co přesně se stane, když je zpracovává služba třetí strany? Zpočátku se tyto otázky jeví jako právní nebo administrativní záležitosti. V praxi tomu tak není. Jsou to otázky týkající se chování systému. Pokud na ně nedokážete odpovědět, obvykle to není proto, že by regulace byla nejasná. Je to proto, že systém samotný.

Kde se věci skutečně pokazí

Logování je dobré místo, kde začít, protože téměř každý systém na něm závisí. V raných fázích se logování přidává pro usnadnění ladění. Logujete ID požadavků, pak ID uživatelů, pak možná e-mailové adresy, protože usnadňují sledování případů podpory. Později zahrnete části datových polí požadavků, protože pomáhají reprodukovat okrajové případy. Každý krok je užitečný a žádný z nich se nezdá problematický. Nyní zvažte, co se stane, když uživatel požádá o smazání svých dat: Odstraníte jeho účet z vaší hlavní databáze. Tato část je přímočará. Ale jeho e-mailová adresa stále existuje v logech, které byly zapsány před měsíci. Tyto logy mohou být uloženy v centrálním systému logování, replikovány napříč regiony a uchovávány z provozních důvodů. Mohly být také předány externí službě k analýze. I kdybyste tato data chtěli smazat, rychle narazíte na praktická omezení. Logy jsou často pouze pro zápis. Zálohy jsou neměnné. Externí nástroje udržují vlastní úložiště a retenci. V tomto okamžiku není problém, zda je smazání vyžadováno. Problém je, že smazání nikdy nebylo součástí návrhu systému. Systém byl optimalizován pro pozorovatelnost a spolehlivost, nikoli pro řízené odstraňování dat.

Když váš systém přestane být jen vaším systémem

Podobný vzorec se objevuje u integrací třetích stran. Vezměte běžné nastavení. Používáte platebního poskytovatele pro zpracování transakcí, analytický nástroj pro pochopení chování uživatelů a platformu podpory pro správu zákaznických požadavků. Každý z těchto nástrojů vyžaduje pro svou funkci nějakou formu uživatelských dat. Když se uživatel zaregistruje, jeho data proudí více cestami: jsou uložena ve vaší databázi, odeslána platebnímu poskytovateli pro fakturaci, předána analytice pro sledování a případně zahrnuta do ticketů podpory, pokud vás kontaktují. Nyní si představte, že vám je položena jednoduchá otázka. Co se stane s daty tohoto uživatele, pokud zruší svůj účet? Abyste na to řádně odpověděli, musíte sledovat každou cestu, kterou data prošla. Nestačí je smazat z vaší vlastní databáze. Musíte vědět, zda existují v analytických systémech, zda jsou uvedeny v nástrojích podpory a zda je uchovávají externí poskytovatelé. Většina týmů v tomto okamžiku zjistí, že nemají jasnou mapu těchto toků. Ne proto, že by problém ignorovali, ale proto, že každá integrace byla přidána nezávisle, bez úplného obrazu o tom, jak data proudí systémem jako celkem.

Proč regulace toto odhaluje

Regulace tyto problémy nezavádí. Nutí vás se s nimi konfrontovat. Rámce jako GDPR nebo AI Act vyžadují, abyste vysvětlili, co váš systém s daty dělá. Co se shromažďuje, jak se používá, kde je uloženo a kdo k němu má přístup. Toto nejsou abstraktní požadavky. Přímo odpovídají skutečnému chování systému. Pokud váš systém posílá uživatelská data do tří různých služeb, vaše vysvětlení musí zahrnovat všechny tři. Pokud váš systém nemůže odstranit data z určitých komponent, tato omezení se stanou viditelnými. Proto se dodržování předpisů často zdá obtížné. Ne proto, že by pravidla byla inherentně složitá, ale proto, že systém nebyl nikdy navržen tak, aby poskytoval jasné odpovědi.

Jak se systémy stávají těžko pochopitelnými

Základní problém je zřídka jediné špatné rozhodnutí. Je to akumulace: Uchováváte logy déle, než je nutné, protože by mohly pomoci s budoucím laděním. Ukládáte další atributy uživatelů, protože by mohly být užitečné pro budoucí funkce. Přidáváte nástroje, protože řeší okamžité problémy. Časem se data ocitnou na více místech, často s různými retenčními lhůtami a řízením přístupu. Některá jsou aktivně používána, některá ne a některá jsou jednoduše zapomenuta. Například e-mail uživatele může existovat ve vaší primární databázi, v historických logech, v exportovaných datových sadách analytiky a v archivovaných konverzacích podpory. Každé z těchto míst je samo o sobě platné. Dohromady ztěžují odpověď na jednoduchou otázku, jako je „kde jsou uložena data tohoto uživatele?“ Bez jasného modelu distribuce a správy dat je jakýkoli požadavek závislý na kontrole těžko implementovatelný.

Co se změní, pokud k tomu přistoupíte jako k problému návrhu

Alternativou není zavádět těžkopádné procesy dodržování předpisů. Je to explicitněji se rozhodovat dříve. Při návrhu logování se rozhodnete, jaký druh dat tam patří. Můžete se například rozhodnout logovat interní identifikátory místo přímého logování osobních údajů a mapování uchovávat na řízeném místě. Tímto způsobem logy zůstávají užitečné pro ladění, ale jsou méně citlivé a snáze spravovatelné. Při integraci externích služeb definujete, jaká data jsou sdílena a za jakým účelem. Místo předávání celých uživatelských objektů analytice můžete posílat pouze data na úrovni událostí, která jsou pro analýzu dostatečná, ale neexponují zbytečné detaily. Při ukládání dat definujete, jak dlouho by měla zůstat relevantní. Například podrobnější provozní logy mohou být potřeba pouze po omezenou dobu, po které postačují agregovaná data. Učinění tohoto rozlišení včas zabrání systému v nekonečném hromadění dat. Tato rozhodnutí neodstraňují složitost, ale udržují ji v mezích. Důležitější je, že zajišťují, že systém se chová předvídatelně.

Užitečnější rámec

Dodržování předpisů je často považováno za checklist nebo milník. V praxi se chová spíše jako vlastnost systému. Pokud je chování systému nejasné, dodržování předpisů bude vždy vyžadovat úsilí. Každá otázka vyvolá vyšetřování. Každý požadavek bude vyžadovat úpravy napříč více komponentami. Pokud je chování systému definováno návrhem, dodržování předpisů se stává otázkou popisu těchto chování. Stejný systém, který je snáze provozovatelný a laditelný, je také snáze vysvětlitelný.

Relevance tohoto v návrhu

Pro týmy stavějící v EU se tyto otázky dříve či později objeví. Až se tak stane, náklady na změnu závisí na tom, jak byl systém navržen: Pokud jsou datové toky implicitní a široce distribuované, jejich změna je obtížná. Pokud jsou explicitní a řízené, změny jsou lépe zvládnutelné. Většina problémů s dodržováním předpisů vzniká v běžných rozhodnutích. Co se loguje, co se ukládá, co se sdílí a jak dlouho to přetrvává. Tato rozhodnutí definují systém dlouho předtím, než jsou hodnocena z hlediska dodržování předpisů. Pochopení toho je výchozím bodem.