GDPR forbyder ikke AI i strategiarbejdet. Den kræver at du ved hvilke personoplysninger du behandler, at du kun sender det nødvendige, og at der er en grund til det. Klassificér dine datakilder én gang, så bliver resten indstillinger frem for vurderinger.
De fleste diskussioner om GDPR og AI ender med at nogen siger "det tør vi ikke", og så bliver der ikke lavet noget strategiarbejde med AI.
Det er en dyr måde at være forsigtig på, fordi den ikke er mere sikker. Den udskyder bare beslutningen til nogen gør det alligevel uden at spørge.
Her er den praktiske version.
De fire niveauer, og hvorfor rækkefølgen betyder noget
Klassifikation er ikke bureaukrati. Det er den ene beslutning der gør alle de følgende automatiske.
- PUBLIC. Offentlige nyheder, jeres vedtægter, offentliggjorte priser.
- INTERNAL. Interne analyser, mødereferater uden personoplysninger, salgspipeline.
- CONFIDENTIAL. Kontraktvilkår, indtjeningslogik, ikke-udmeldte prisbeslutninger.
- RESTRICTED. Personoplysninger, og eksakte økonomiske nøgletal. Ansættelsesvilkår, CPR, private kontaktoplysninger, omsætning, marginer, EBITDA, kundeanskaffelsespris og eksakte priser.
Niveauerne og grænsetilfældene er gennemgået i de fire klassifikationsniveauer.
Det vigtige er at klassifikationen ligger på kilden, ikke på den enkelte forespørgsel. Ligger den på forespørgslen, skal nogen tage stilling hver gang, og så bliver den taget forkert en travl torsdag.
Hvad der stopper data på vej ind
Der er tre lag mellem jeres data og modellen, og de kan noget forskelligt. Forskellen er værd at forstå, fordi den afgør hvad I kan regne med.
Feltklassifikation. Felter der er markeret følsomme fjernes ud fra hvad slags model der arbejdes med. Det her er det eneste lag der er kategorisk: det gætter ikke, det slår op. Er et felt RESTRICTED for den nodetype, sendes det ikke, og der findes ikke en formulering der får det med alligevel.
Secrets-scanner. Fanger nøgler, adgangskoder, tokens og certifikater i fritekst. Det lyder som noget der ikke sker i strategidokumenter. Det sker i mødereferater.
Personoplysninger under transport. Navne, e-mails, telefonnumre, CPR, IBAN og kortnumre håndteres af det lag der ligger nærmest udbyderen, tættest på selve kaldet.
De to sidste er mønstergenkendelse. Mønstergenkendelse fejler i begge retninger: den kan lade noget slippe igennem, og den kan blokere noget harmløst. Derfor er det klassifikationen der bærer ansvaret. De to andre lag er sikkerhedsnet, ikke en plan.
Det praktiske forløb ser sådan ud. Du beder om en analyse af jeres ti største kundesegmenter og vedhæfter kundelisten.
Du får ikke bare et svar. Afhængigt af hvilket lag der reagerer, sker der ét af to: forespørgslen afvises med en besked om at fjerne de følsomme oplysninger og prøve igen, eller personoplysningerne håndteres på vej til modellen, så analysen kører videre uden dem.
Begge udfald er brugbare, men de er ikke det samme, og forskellen er værd at kende. En afvisning er tydelig. En håndtering undervejs er det ikke, og det er derfor klassifikationen skal ligge på kilden: så ved du på forhånd hvad der aldrig kommer med, i stedet for at opdage det i en analyse der mangler noget.
Hvad der stopper data på vej ud
Indgangen er kun den ene halvdel. Modellen kan også komme til at skrive noget videre den fik med i konteksten.
Derfor findes der også en kontrol af svaret på vej ud. Indeholder det legitimationsoplysninger, kan det blokeres før det når frem, og personoplysninger håndteres af det lag der ligger om selve kaldet og dermed dækker begge retninger.
Vær opmærksom på at udgangskontrollen ikke er aktiv på alle veje gennem systemet. Den er et supplement, ikke en garanti, og det er derfor klassifikationen på indgangen er den der bærer sikkerheden.
Tænk på det som lufthavnens to kontroller. Den ene ser hvad du har med ind. Den anden ser hvad der kommer ud ved gaten. De fanger ikke det samme, og det er pointen.
Fire misforståelser der koster tid
"Er den EU-hostet, er den sikker." Nej. EU-hosting løser hvor data behandles. Den løser ikke hvad du sender. Sender du en uanonymiseret kundeliste til et EU-datacenter, er det stadig en behandling af personoplysninger du skal kunne begrunde.
"Er data anonymiseret, er der frit slag." Næsten. Kan modtageren udpege personen ud fra konteksten, er det stadig personoplysninger. "Kundesegment A" uden navne er reelt anonymt. "Den største kunde i Sønderjylland" er det ikke.
"Vi melder det bare til myndigheden bagefter." Det virker ikke sådan. Er der tale om et brud på persondatasikkerheden, gælder der en anmeldelsesfrist, og anmeldelsen gør ikke bruddet lovligt. Vend det med jeres rådgiver inden I begynder, ikke efter.
"De sletter data efter 30 dage, så er det fint." Sletning efter en fejl gør ikke fejlen tilladt. Behandlingen fandt sted.
Fire skridt inden næste ledelsesmøde
1. Klassificér kilderne, tredive minutter. Ikke alle data. De ti kilder I faktisk bruger til strategiarbejde. En tabel med kilde og niveau.
2. Skriv jeres egne røde linjer ned, tredive minutter. Ud over personoplysninger, hvad skal aldrig sendes hos jer? For nogle er det kundenavne. For andre er det finansielle fremskrivninger eller en patentansøgning der ikke er indleveret endnu. Det er en forretningsbeslutning, ikke en juridisk.
3. Stil leverandøren tre spørgsmål, ét minut. Hvor behandles vores data, bruges de til træning, og hvem er underdatabehandlerne? Få svaret på skrift. Det er én mail.
4. Start på PUBLIC. Lad ledergruppen køre en analyse på offentlige data først. Markedstendenser, konkurrenters årsrapporter. Ingen personoplysninger overhovedet. Når I kan se hvad systemet gør ved data I ikke er nervøse for, er det lettere at beslutte om I vil op på INTERNAL.
Det fjerde punkt er det der virker, og det er det der oftest springes over. Folk forsøger at afgøre spørgsmålet i abstrakt form på et møde, i stedet for at prøve det på noget ufarligt i tyve minutter.
Derfor ligger klassifikationen på nodetypen hos os
Det svage led i enhver dataklassifikation er at den skal huskes af et menneske i det øjeblik der er travlt.
I 360° Sprint er felter der er RESTRICTED derfor bundet til nodetypen frem for til brugeren. De sendes aldrig til nogen AI-udbyder, og det kan ikke slås fra i en indstilling. Alle tilstandsændringer logges, så det kan dokumenteres bagefter hvad der blev behandlet hvornår, hvilket er præcis det GDPR beder jer kunne.
Behandlingen sker på EU-territorium. Hvorfor det handler om hvor og ikke om leverandørens nationalitet, står i AI og datasikkerhed i EU, og hvad EU AI Act oven i det kræver af dokumentation, står i EU AI Act for SMV'er.
GDPR og AI kan sagtens fungere sammen. Det kræver bare at klassifikationen er lavet før forespørgslen, og ikke under den.
Den samlede vej fra spørgsmålet til en truffet beslutning står i må vi bruge AI på vores egne data.