Načelo minimizacije podatkov je inženirska disciplina
Obrazec z osemintridesetimi polji
Najdražji podatki v stavbi niso bili v skladišču. Bili so na prijavnem obrazcu. Osemintrideset polj, razporejenih na tri zaslone, s samozavestjo postopka, ki je preživel več reorganizacij in se iz njih ni ničesar naučil. Ekipa za izdelek je trdila, da je večina polj neobveznih. Ekipa za analitiko je dejala, da bi bila nekatera morda uporabna pozneje. Ekipa za podporo je povedala, da je dodaten kontekst pomagal pri robnih primerih. Pravna služba je dejala, da obvestilo o zasebnosti omenja zbiranje. Tehnična ekipa je povedala, da ima podatkovna zbirka že stolpce. Vsak je imel razlog. Uporabnik je imel boleč palec.
Nato je prispela zahteva za izbris od osebe, ki prijave nikoli ni dokončala. Sistem je shranil delno stanje obrazca, metapodatke o zapuščeni seji, podatke o napravi, tržno atribucijo, napake pri preverjanju, izrezke iz klepeta podpore in oceno goljufije, za katero se nihče ni spomnil, kdaj je bila dodana. Nekaj je bilo v glavni podatkovni zbirki. Nekaj v analitiki. Nekaj v dnevnikih. Nekaj v čakalni vrsti sporočil, ki se je običajno praznila, razen kadar se ni. Zahteva tehnično ni bila težavna, ker bi bili podatki dragoceni. Težavna je bila, ker so podatki vstopili brez jasnega razloga in se nato potikali po krajih z boljšo kavo kot disciplino.
Zato je minimizacija podatkov tehnična disciplina. Ni okusen stavek v politiki, ni načelo, prikazano med uvajanjem, in ni preglednica, ki jo enkrat letno pregledajo ljudje z junaškim razponom pozornosti. Je načrtovanje tega, kaj sme vstopiti, kakšno obliko sme imeti, kam sme potovati, kako dolgo sme živeti, kdo ga sme videti, kaj sme postati in kdaj ga mora sistem zavrniti. Minimizacija se zgodi pred zbiranjem, med obdelavo, v dnevnikih, v modelih in pri izbrisu. Če se zgodi samo v dokumentu, se ni zgodila.
Manj je tehnična odločitev
Ljudje minimizacijo pogosto obravnavajo kot zadržanost, kar je res, a nepopolno. Zadržanost je treba nekje izvesti. Obrazec potrebuje manj polj. Dogodek potrebuje manj lastnosti. Shema potrebuje namen za vsako polje. Cevovod potrebuje preverjanje, ki zavrača odvečne atribute. Naloga za usposabljanje modela potrebuje pravila o upravičenosti. Vrstica dnevnika potrebuje redakcijo. Nadzorna plošča potrebuje agregacijo. Varnostna kopija potrebuje razred hrambe. Izvoz potrebuje obseg. Orodje za razvijalce potrebuje varne privzete nastavitve. Sistem, ki ljudi le prosi, naj si zapomnijo manj podatkov, bo sčasoma zbral več podatkov, običajno ob 17:42 v petek, ko se rešitev zdi smiselna.
Tehnična odločitev se začne z namenom. Ne namen kot navdihujoč samostalnik, ampak namen kot operativna omejitev. Polje bi moralo imeti določeno uporabo, lastnika, pravno ali politično podlago, razred občutljivosti, obdobje hrambe, nadaljnje uporabnike in vedenje ob izbrisu. To zveni birokratsko, dokler ekipa ne poskuša odstraniti polja in odkrije, da nihče ne ve, zakaj obstaja. Stavek morda uporabno pozneje ni namen. Je načrt shranjevanja, ki ga je napisala tesnoba.
Tehnične ekipe razumejo omejitve, ko so konkretne. Proračuni pomnilnika, cilji zakasnitve, API pogodbe in omejitve hitrosti oblikujejo načrtovanje, ker so uveljavljeni. Proračuni podatkov si zaslužijo enak status. Storitev bi morala vedeti, katera polja sme sprejeti. Tabela bi morala narediti neobvezno zbiranje vidno, ne pa ga skriti za ničelnimi stolpci. Cevovod bi moral odpovedati, ko se pojavi prepovedan atribut. Trgovina s funkcijami bi morala vedeti, ali se funkcija lahko uporablja za analitiko, usposabljanje modelov, avtomatizirane odločitve ali samo za neposredno zagotavljanje storitev. Minimizacija postane resnična, ko ima sistem kaj povedati na vratih.
Izbirna polja so še vedno polja
Izbirna polja povzročajo več težav, kot njihova skromna oznaka nakazuje. Ekipe jih dodajajo, ker ne blokirajo uporabnika. To se sliši nedolžno. Toda izbirne podatke je še vedno treba razvrstiti, zaščititi, preizkusiti, izbrisati, izvoziti, pojasniti in zagovarjati. Še vedno se pojavljajo v dnevnikih. Še vedno vabijo analitiko. Še vedno ustvarjajo vzorce manjkajočih vrednosti, ki lahko postanejo signali. Še vedno zapletajo nadzor dostopa. Še vedno postanejo del miselnega modela sistema. Izbirno zbiranje je zbiranje z mehkejšim glasom.
Prosto besedilo je najbolj nadarjeni prestopnik. Obrazec zahteva dodatne informacije. Podporni zapisek vpraša, kaj se je zgodilo. Referent zapiše uporabno podrobnost. Uporabnik prilepi dokument. Nenadoma polje vsebuje zdravstvene podatke, članstvo v sindikatu, dolgove, družinske konflikte, politične pripombe, poverilnice in šalo, ki bo v postopku razkritja zastarela. Prosto besedilo je lahko potrebno, zlasti pri zapletenih storitvah. Vendar ni poceni. Potrebuje redakcijo, namenske meje, pravila dostopa, hrambo in disciplino iskanja. Polje za prosto besedilo so majhna vrata, skozi katera lahko vstopi ves svet, pogosto z napakami pri črkovanju.
Minimizacija ne pomeni prepovedi izbirnih polj ali prostega besedila. Pomeni, da postanejo njihovi stroški vidni. Ali lahko postopek deluje s kategorijo namesto z besedilom? Ali je polje lahko lokalno za potek dela in izključeno iz analitike? Ali je mogoče zaznati in redigirati občutljive vzorce? Ali lahko vrednost hitro poteče? Ali jo uporabnik lahko vidi in popravi? Ali je osebje mogoče usposobiti, da ne prileplja celotnih zgodovin v zapisek, ker jih je polje vljudno sprejelo? Inženiring mora podpreti te izbire. V nasprotnem primeru izbirno postane trajno po naključju.
Izpeljani podatki podedujejo težavo
Eden od razlogov, da se minimizacija v politiki zdi preprosta, v praksi pa težka, je, da sistemi ustvarjajo nove podatke. Datum rojstva postane starostna skupina. Poštna številka postane ocena prikrajšanosti. Zgodovina iskanja postane vektor interesov. Prepis podpore postane oznaka čustev. Vzorec transakcij postane signal goljufije. Dokument postane vdelava. Tok klikov postane verjetnost odhoda. Izvirno polje je lahko izbrisano, medtem ko izpeljanka še naprej nosi pomen. Sistem ni odstranil dejstva. Zamenjal mu je obleko.
Izpeljani podatki so lahko manj občutljivi kot surovi podatki. Agregacija, združevanje v skupine, zgoščevanje, tokenizacija in lokalno pridobivanje značilnosti lahko zmanjšajo izpostavljenost. Toda izpeljani podatki so lahko tudi bolj občutljivi, ker vsebujejo trditev, ki je uporabnik nikoli ni podal. Ocena tveganja, segment, izpeljana lastnost ali priporočilo lahko vplivajo na obravnavo. Če minimizacija ignorira izpeljanke, postane slovesnost, ki se izvaja na recepciji, medtem ko tovarna za njo še naprej proizvaja dejstva.
Inženirska disciplina pomeni, da občutljivost in namen potujeta skupaj s transformacijami. Funkcija mora poznati svoja izvorna polja, dovoljene uporabe, razred hrambe, meje kakovosti in odvisnosti pri izbrisu. Izhod modela mora vedeti, ali je začasen predlog, shranjen zapis, sprožilec za človeški pregled ali sestavni del avtomatiziranega odločanja. Indeks vdelav mora vedeti, kateri dokumenti so upravičeni, kdaj so bili indeksirani in kako se odstranjevanje širi naprej. Sledljivost podatkov ni okras. Je način, kako minimizacija sledi podatkom, potem ko ti prenehajo izgledati kot vhodna oblika.
UI naredi presežek videti dobičkonosen
Sistemi UI otežujejo minimizacijo, ker presežni podatki izgledajo kot prihodnja zmogljivost. Obdrži stare vstopnice, morda bodo izboljšale avtomatizacijo podpore. Obdrži prepise, morda bodo izurili boljši klasifikator. Obdrži dogodke vedenja, morda bodo pomagali pri personalizaciji. Obdrži zavrnjene prijave, morda bodo razkrile goljufije. Obdrži dnevnike, morda bodo pomagali pri vrednotenju. Včasih je to res. Podatki lahko izboljšajo modele. Toda res ni isto kot upravičeno. Shramba lahko vsebuje uporabne stvari in je še vedno požarna nevarnost, če nihče ne ve, kaj je v njej.
Učni podatki imajo dolgo senco. Ko se zapisi uporabijo za učenje, prilagajanje, vrednotenje ali pozivanje modelov, lahko vplivajo na vedenje na načine, ki niso tako preprosti kot vrstica v podatkovni bazi. Nekateri sistemi lahko odstranijo primere in se ponovno učijo. Nekateri lahko prikrijejo ali filtrirajo. Nekateri lahko le dokumentirajo omejitve. Prej ko se zgodi odločitev o minimizaciji, cenejša in čistejša je. Odločitev po učenju, da polje nikoli ne bi smelo biti vključeno, je možna v istem smislu, kot je odpečenje torte projektni načrt. Imela bo sestanke.
Ekipe za UI bi zato morale obravnavati upravičenost do učenja kot kontrolo prvega reda. Ni vsak servisni zapis učni material. Ni vsako stanje privolitve dovoljenje za ponovno uporabo. Ni vsaka podporna vstopnica namenjena vrednotenju. Ni vsak dnevnik primeren za kontekst poziva. Ni vsak dokument namenjen vstopu v indeks. Cevovod bi moral to uveljaviti, preden model vidi podatke. Če je kakovost modela odvisna od zaužitja vsega, ker nihče ni pravilno načrtoval naloge, problem ni, da je zasebnost težavna. Problem je, da arhitektura poskuša pojesti svojo domačo nalogo.
Telemetrija je tam, kjer vrlina pušča
Številni sistemi zmanjšajo količino podatkov o izdelku, nato pa vse skupaj zlijejo v telemetrijo. Sledi napak, analitični dogodki, posnetki sej, odkloni pri razhroščevanju, poročila o sesutjih, pozivi modelov, poizvedbeni nizi, glave, zastavice funkcij in podatki o zakasnitvah se nabirajo okoli storitve kot prah pod strežniškim regalom. Vsaka postavka je sama po sebi obrambno utemeljena. Skupaj lahko uporabnika poustvarijo bolj živo kot podatkovna zbirka, ki je bila skrbno zmanjšana. Opazovanje brez discipline je nadzor z pozivnikom.
Inženirske ekipe potrebujejo opazovanje. Sistemi, ki so slepi, niso varni, zasebni, zanesljivi ali poceni. Vprašanje ni, ali beležiti, temveč kaj beležiti, s kakšno stopnjo podrobnosti, za katero občinstvo, kako dolgo in s kakšnim prekrivanjem podatkov. Napaka v produkciji lahko potrebuje identifikator zahteve, različico storitve, razred napake in izbrane sklice. Verjetno ne potrebuje celotnega sporočila, surovega dokumenta, žetona za dostop in celotnega stanja uporabnikovega obrazca. Podrobnosti za razhroščevanje je mogoče vzorčiti, omejiti, prekriti ali začasno dvigniti po nadzorovanih postopkih. Ni naravnega zakona, ki bi zahteval, da vsaka izjema postane dnevniški zapis.
Telemetrija umetne inteligence si zasluži posebno pozornost. Pozivi lahko vsebujejo prilepljene zasebne podatke. Sledi pridobivanja lahko razkrijejo občutljive teme. Ustvarjeni izpisi lahko vključujejo dejstva, ki jih ne bi smeli shranjevati. Klici orodij lahko razkrijejo namere. Neuspele ocene lahko postanejo dolgoživi primeri. Dnevniki stroškov in zakasnitev lahko razkrijejo vzorce vedenja. Zmanjšan sistem ni tisti, ki noče opazovati samega sebe. Je tisti, ki opazuje z manjšimi in ostrejšimi instrumenti.
Hramba je funkcija, ne načrtovana naloga
Hramba se pogosto uvede pozno, kot načrtovano čiščenje in upajoča pripomba. Tako sistemi postanejo muzeji. Prava hramba se začne pri načrtovanju. Vsak razred podatkov potrebuje pričakovano življenjsko dobo. Nekateri zapisi so kratkotrajno operativno stanje. Nekateri so pravni dokazi. Nekateri so uporabniku vidni podatki o računu. Nekateri so agregatne metrike. Nekateri so gradivo za ocenjevanje modelov. Nekateri so ostanki varnostnih kopij. Če z vsemi ravnamo kot s trajnimi do nadaljnjega, to ni pragmatizem. To je kopičenje s cevovodom za uvajanje.
Uporabna zasnova hrambe odgovori na dolgočasna vprašanja zgodaj. Kdaj se ura začne. Kateri dogodek jo ponastavi. Katera kopija je avtoritativna. Kateri izpeljani podatki podedujejo rok trajanja. Kateri dokazi morajo ostati po izbrisu vsebine. Kako se obravnavajo varnostne kopije. Kako se dokaže izbris. Kaj se zgodi, ko veljajo zadržki zaradi sodnih sporov, revizij ali varnosti. Kdo lahko podaljša hrambo. Katere nadzorne plošče odpovejo, ko stari podatki izginejo. Če nihče ne more odgovoriti na ta vprašanja, bo čiščenje postalo simbolična metla v skladišču brez vrat.
Hrambo je treba tudi preizkusiti. Pot izbrisa, ki deluje le po srečni poti, ni pot izbrisa. Zajeti mora podatkovne zbirke, shrambe objektov, iskalne indekse, predpomnilnike, tokove dogodkov, analitiko, izvoze, shrambe funkcij, nabore za ocenjevanje in varnostne kopije, kjer je to potrebno. Zabeležiti mora potrdila, ne da bi ohranjala izbrisano vsebino. Napake mora narediti vidne. Biti mora dovolj dolgočasna, da ni treba vsakič sestaviti delovne skupine, ko uporabnik uveljavi svojo pravico. Dobra hramba ni dramatična. To je njen čar.
Nadzor dostopa ne more rešiti slabe zbirke
Obstaja mamljiv argument, da lahko ekipe zbirajo na široko in pozneje zaščitijo z nadzorom dostopa. Včasih je široko zbiranje potrebno, vendar nadzor dostopa ni moralni pralni stroj. Če se podatki zbirajo brez potrebe, jih mora vsaka naslednja plast braniti: identiteta, pooblastila, beleženje, šifriranje, spremljanje, izbris, filtri za usposabljanje, nadzor izvoza in odzivanje na incidente. Najcenejši podatki za zaščito so tisti, ki nikoli ne prispejo. To ni filozofija. To je operativni proračun, skrit v načelu.
Nadzor dostopa se pod pritiskom pogosto širi. Podporni primer potrebuje začasno vlogo. Analitik potrebuje širši nabor podatkov za rok. Migracija potrebuje skrbniški dostop. Vrednotenje modela potrebuje primere. Dobavitelj potrebuje nujno podporo. Vsaka zahteva je lahko razumna. Široko zbiranje spremeni razumne izjeme v veliko napadalno površino. Minimizacija ohranja nadzor dostopa pošten tako, da zmanjša, kaj lahko vloga sploh razkrije.
Dobra zasnova dostopa se povezuje z minimizacijo. Storitve prejmejo le polja, ki jih potrebujejo. Uporabniški vmesniki privzeto prikažejo manj. Analitiki delajo s pogledi, ki nosijo namen in redakcijo. Inženirji razhroščujejo z referencami in vzorci, ne s produkcijskimi izpisi. Agenti in avtomatizirana orodja prejmejo ozke obsege. Nujni dostop pusti močne dokaze. Sistem bi moral narediti najmanj invazivno pot lahko pot. Če varna pot zahteva tri odobritve in ročno napisan YAML uro, bodo ljudje našli pot okoli nje z ustvarjalnostjo, ki je običajno rezervirana za davčne obrazce.
Minimizacija zahteva produktno presojo
Inženirji minimizacije ne morejo opraviti sami. Lahko zgradijo nadzore, vendar se morajo produktne in domenske ekipe odločiti, kaj je potrebno za delo. Polje se lahko oblikovalcu podatkovne baze zdi pretirano, delavcu v obravnavi pa bistveno. Meritev se lahko produktnemu vodji zdi neškodljiva, osebi, ki jo merijo, pa invazivna. Funkcija modela lahko izboljša natančnost, hkrati pa spremeni sprejemljiv značaj storitve. To so presoje. Inženirska disciplina je, da presojo naredi izrecno, preverljivo in kjer je mogoče, povratno.
Najboljše razprave so konkretne. Kakšno odločitev bo to polje izboljšalo. Kako pogosto. Za koga. Kaj se zgodi, če ga ni. Ali ga je mogoče zbrati pozneje, ko je potrebno. Ali je lahko grobo. Ali ga je mogoče izračunati lokalno. Ali je lahko vidno le pregledovalcu. Ali lahko poteče. Ali ga je mogoče nadomestiti z manj osebnimi dokazi. Ali vnaša pristranskost, stigmo ali novo obveznost. Ekipa, ki ne more odgovoriti na ta vprašanja, se lahko še vedno odloči za zbiranje. Vsaj vedeti mora, da si sposojajo težave, ne da odkriva zrelost.
Tu pomaga tudi suhoparna operativna realnost. Vsako polje potrebuje teste. Vsako polje potrebuje migracije. Vsako polje potrebuje pravila dostopa. Vsako polje se pojavi v izvozih, ponaredkih, fiksnih podatkih, analitiki, dokumentaciji in podpornih orodjih. Vsako polje lahko postane napačno. Manjša shema ni le bolj zasebna. Pogosto je bolj razumljiva, zanesljivejša in cenejša za spreminjanje. Minimalizem ni estetika. Je prihodnje vzdrževanje, ki noče biti presenečeno.
Zanka, ki ohranja podatke majhne
Minimizacija ni enkratno čiščenje. Nove funkcije dodajajo polja. Nova analitika dodaja dogodke. Novi modeli želijo učne primere. Nova regulativa ustvarja dokaze. Novi incidenti ustvarjajo dnevnike. Novi vodje zahtevajo nadzorne plošče. Stari podatki dobijo sentimentalno vrednost, ker se nekdo spominja grafa iz leta 2021. Brez zanke se podatkovna posest raste kot vrt, ki ga zalivajo zapisniki sestankov.
Praktična zanka se začne pred zbiranjem. Vprašajte, kaj delo zahteva. Razvrstite polje ali dogodek. Oblikujte najmanjšo uporabno obliko. Uveljavite pogodbo ob vnosu. Izmerite, ali se podatki uporabljajo. Umaknite jih, ko namen preneha. Preglejte izpeljanke, dnevnike, izvoze in modele. Zabeležite odločitev. Ponovite, ko se delovni proces spremeni. To ni glamurozno, vendar je ceneje kot odkriti med incidentom, da organizacija v treh formatih in v pozabljeni čakalni vrsti hrani zasebni muzej.
Zanka mora ustvarjati dokaze zase. Sistem bi moral znati pokazati, zakaj polje obstaja, kdo ga lastni, katere storitve ga uporabljajo, kako pogosto se uporablja, kakšen rok hrambe velja in kako se izbris širi. To ni namenjeno le regulatorjem. Inženirjem pomaga odstranjevati stvari brez strahu. Večina sistemov hrani preveč, ker nihče ne ve, katera odstranitev je varna. Minimizacija postane lažja, ko organizacija loči nosilne podatke od okrasnega nereda.
Disciplina
Minimizacija podatkov ni proti podatkom. Je za namen. Ekipo sili, da pove, kaj potrebuje, zakaj to potrebuje, kako natančno mora biti, kdo ga sme uporabljati in kdaj naj preneha obstajati. Ta disciplina izboljšuje zasebnost, a tudi oblikovanje sistema. O manjših nosilcih podatkov je lažje razmišljati. Ožje sheme je lažje seliti. Krajši roki hrambe zmanjšujejo bolečino pri odkritjih. Čistejša telemetrija olajša razumevanje incidentov. Manj učnih primerov z jasnejšo upravičenostjo lahko premaga večji kup vprašljivega gradiva. Načelo je etično, zakonsko in globoko praktično.
Težji del je kulturni. Organizacije imajo rade podatke, ker se podatki zdijo kot možnost izbire. Hranjenje se zdi varno. Brisanje se zdi dokončno. Toda možnost izbire brez lastništva je dolg. Vsako dodatno polje je obljuba, da ga bomo zaščitili, pojasnili, popravili, izvozili in izbrisali. Vsaka izpeljana funkcija je nova trditev. Vsak dnevnik je potencialni zapis. Vsaka varnostna kopija je zapozneli argument. Minimizacija od sistema zahteva, da si zasluži, kar hrani. To je visoka letvica, zato je uporabna.
Obrazec z osemintridesetimi polji ni potreboval slogana o zasebnosti. Potreboval je manjšo shemo, boljše privzete vrednosti, strožji sprejem podatkov, razvrščeno telemetrijo, omejeno analitiko, pogoje za usposabljanje, potrdila o hrambi in dovolj izdelčnega poguma, da prizna, da »kasneje« ni namen. To je delo. Ne dramatično, ne mistično, ne sovražno do inovacij. Le inženirska disciplina, uporabljena na najstarejšo resnico v podatkovnih sistemih: tistega, česar nikoli ne zberete, ni mogoče razkriti, ni mogoče odtujiti, ni mogoče zlorabiti in ne potrebuje odbora, da bi to pozabil.