Minimalizácia dát GDPR: API v reálnom case
Aktualizované pre rok 2026
GDPR clanok 5(1)(c) hovorí: zbierajte len to, co potrebujete. Toto je pravidlo minimalizácie dát. Väcšina tímov ho porušuje dizajnom formulárov, nie zlým úmyslom. Polia volného textu priahujú mená, adresy a císla ID, na ktoré nikto nepocítal.
Neskorší cistenie databázy to neopraví. K porušeniu došlo, ked ste dáta zbierali. Zastavenie ho pri zdroji je jediným skutocným riešením. Kontrola API v reálnom case pri odoslaní formulára zabrauje nadmernému zberu skôr, ako zacne.
Najdite náš prehad súladu a bezpecnostné postupy pre podporu GDPR clanku 5.
Preco formuláre zbierajú nadbytocné dáta
Polia volného textu vo webových aplikáciách zhromažujú PII, na ktorú nikto neplánovato:
- Polia "dôvod" v lístkoch podpory vyplnené anamnézami a císlami poistenia
- Sekcie "iné komentáre" v prieskumoch obsahujúce plné mená a telefónne císla
- Stlpce "poznámky" HR s rokmi neštruktúrovaných osobných podrobností
- Polia "poznámky" objednávky obsahujúce císla ID zákazníkov zadané na pomoc s problémami
Pravidlo minimalizácie vyžaduje, aby táto PII nikdy neenterd do vašich systémov. Retroaktívne cistenie liecy symptóm. Detekcia v reálnom case odstrauje príicinu.
Preco retroaktívne cistenie nestací
Tímy, ktoré cistia uložené PII, celia štyrom problémom.
Úplnos. Pattrenové porovnávanie nachádza zjavné PII, ako sú e-mailové adresy a císla ID. Vynecháva kontextové referencie. "Moja sestra Sofia mala rovnaký problém" obsahuje meno, ktoré väcšina skenov preskocí.
Právne nacasovanie. K porušeniu dochádza pri zbere. Cistenie dát o mesiace neskôr to neopraví. Ak regulátor skúma obdobie, ked boli dáta uložené, porušenie je už zaznamenané.
Neúplné vymazanie. Databázy sa zálohujú. Systémy zapisujú logy. Nástroje analýzy exportujú dáta. Aj po vymazaní z hlavnej databázy môžu kópie zostavat v záložných súboroch a audit logoch.
Expozícia pri porušení. Medzi zberom a cistením nadmerne zozbieraná PII sedí vo vašich systémoch. Porušenie pocas tohto okna uvádza do rozsahu nadmerne zozbierané dáta.
Zastavenie zberu pri zdroji rieši všetky štyri. Dáta, ktoré nikdy neenterd, nemôžu by porušené, nevyžadujú vymazanie a nerátajú sa ako porušenie.
Vzory detekcie pre validáciu formulárov
Existujú tri spôsoby, ako pridat detekciu PII v reálnom case do formulára.
Na strane klienta (rozšírenie Chrome). Rozšírenie sleduje udalosti vloženia v poliach prehliadaca. Ked používate vloží text s PII, okamžite zvýraznení entity. Používate ich odstráni pred odoslaním. Nie je potrebné volanie API - detekcia prebieha lokálne. Definície typov entít nájdete v glosári.
Na strane servera (integrácia API). Formulár sa odošle na váš server. Pred zápisom databázy váš kód zavolá detekné API. API vráti typy entít so skóre dôvery. Zhody s vysokou dôverou blokujú odoslanie s jasnou správou. Zhody so strednou dôverou vyzvú na krok preskúmania. Dáta sú cisté pred uložením.
Hybridný (odporúcaný). Zvýraznenie na strane klienta dáva používatelom rýchlu spätnú väzbu. Kontroly na strane servera poskytujú záruky súladu. Ak používate ignoruje varovanie klienta, kontrola servera stále zachytí PII. Nic nedosiahne databázu bez kontroly. Bežné otázky o prahoch detekcie nájdete v našich FAQ.
Príklad: Zdravotnícky portál pre pacientov
Portál pre pacientov umožuje pacientom opísa svoje symptómy v polo volného textu pred objednaním. Pole pravidelne dostáva záznamy obsahujúce mená iných pacientov, císla ID a domáce adresy. Nic z toho nepatrí do plánovacieho systému.
Pred detekciou v reálnom case:
- PII v poli symptómov: asi 12 % odoslaní
- Metóda cistenia: týždenný dávkový proces
- Stav súladu: reaktívny - k porušeniu clanku 5(1)(c) došlo pri zbere
Po integrácii API pri odoslaní:
- API detekuje PII s vysokou dôverou pred akýmkovek zápisom do databázy
- Pacient vidí: "Vaša správa zjavne obsahuje osobné informácie. Prosím, odstránte ich pred odoslaním."
- Pacient opraví a znova odošle
- Databáza dostane len popis symptómov
V tomto scenári klesla PII v poli z asi 12 % na menej ako 1 % odoslaní. Súlad je teraz preukázaný cez logy detekcie na strane servera, nie retroaktívnymi cistiacimi cyklami.
Auditové záznamy v mieste zberu
Regulátori zaobchádzajú s reaktívnymi tímami inak ako s tými, ktoré majú zavedené kontroly. GDPR clanok 25 - ochrana cez dizajn a predvolene - odmeuje posledné menované.
Detekcia v mieste zberu vytvára užitocné auditové záznamy:
- Log detekcie. Každé skenovanie formulára je uložené s nájdenými typmi entít, skóre dôvery, uskutocnenou akciou a výsledkom.
- Mesacné správy. Súhrny ukazujú mieru detekcie podla pola a typu entity, a ako používatelia reagujú.
- Záznamy konfigurácie. Nastavenia prahu, pokryté polia a sledované typy entít - toto ukazuje jasnú, spravovanú politiku.
Tieto záznamy pomáhajú pri preskúmaniach regulátorom. Podporujú aj interný audit a záznamy spracovania. Príklady kontrol v mieste zberu nájdete v našich prípadových štúdiách.
Nástroje AI a minimalizácia dát
Agenti podpory casto vkladajú e-maily zákazníkov do nástrojov na tvorbu textov AI. Tieto e-maily môžu obsahova mená, adresy a císla úctov. Ich odoslanie modelu AI môže prejs rámec toho, co je potrebné.
Server MCP pridáva krok detekcie pred dosatím textu k modelu. Mená zákazníkov sa stanú [CUSTOMER]. Konkrétne podrobnosti sú ocistené. AI vypracuje odpoved pomocou ocistieného textu. Agent pridá spä len to, co odpoved potrebuje.
Toto splna pravidlo minimalizácie dát pre použitie AI. Model dostane len to, co je potrebné - casto žiadne PII vôbec. Kompletný zoznam typov entít, ktoré detekujeme, nájdete na entitách.