GDPR og AI: hvordan laver I en risikovurdering af et værktøj, medarbejderne allerede bruger?

Begynd med det, der allerede sker, ikke med det, politikken siger. Øvelsen hedder risikovurdering. GDPR bygger på en risikobaseret tilgang, hvor risikoen for den enkelte afgør, hvor meget sikkerhed der skal til. En risikovurdering af et AI-værktøj handler om, hvad der kan gå galt for de mennesker, oplysningerne drejer sig om. Datatilsynet definerer risiko som muligheden for et negativt resultat, hvor størrelsen bestemmes af sammenhængen mellem sandsynlighed og konsekvens. For et AI-værktøj, medarbejderne bruger i forvejen, er sandsynligheden ikke et skøn. Den kan måles.

Hvad kræver GDPR af en risikovurdering?

Risikoen går igen i flere af forordningens artikler. Artikel 24 lægger ansvaret hos den dataansvarlige. Artikel 25 kræver, at databeskyttelse tænkes ind i design og standardindstillinger. Artikel 32 kræver et sikkerhedsniveau, der passer til risikoen. Artikel 33 og 34 handler om risikoen ved et konkret brud, og artikel 35 om konsekvensanalysen.

Der står ingen bestemt metode i loven. Der står, at niveauet skal passe til risikoen, og at I skal kunne vise, hvordan I nåede frem til det.

Artikel 32, stk. 2 peger på, hvad der navnlig skal vejes, nemlig risiciene ved hændelig eller ulovlig tilintetgørelse, tab, ændring, uautoriseret videregivelse af eller adgang til personoplysninger, der er transmitteret, opbevaret eller på anden måde behandlet. Ved et AI-værktøj er det især den uautoriserede videregivelse, der er i spil, fordi teksten forlader maskinen i samme sekund, medarbejderen sender beskeden.

Vurderingen handler om risikoen for personen, ikke om risikoen for organisationens omdømme. Det er den skelnen, de fleste hjemmelavede skemaer taber undervejs.

Begynd med det, medarbejderne allerede gør

Et værktøj, der er i brug, kan kortlægges. Spørg om fire ting, før I begynder at vurdere noget som helst: hvilke afdelinger bruger det, hvor ofte, til hvilke opgaver, og med hvilke konti.

Private konti er den vanskelige del. Er kontoen medarbejderens egen, har organisationen hverken aftale, indsigt eller mulighed for at bede om sletning. Det hører med i vurderingen af konsekvensen, ikke kun i vurderingen af sandsynligheden.

Tal slår mavefornemmelser. Ved I, at et værktøj bruges dagligt i tre afdelinger, er sandsynligheden ikke længere til diskussion, og vurderingen kan koncentrere sig om konsekvensen. Ved I det ikke, vurderer I i blinde, og så bør det stå i dokumentet, at kortlægningen mangler.

Hold jer til den it-faglige betydning af ordet risikovurdering hele vejen igennem. Her handler det om personoplysninger og behandlingssikkerhed, ikke om arbejdsmiljø.

Tjekliste: otte spørgsmål til et AI-værktøj

1. Hvilke personoplysninger ender realistisk i prompten? Almindelige oplysninger, CPR-numre, e-mailadresser eller oplysninger omfattet af artikel 9?
2. Hvilken tjeneste og hvilket abonnement er der tale om, og hvem ejer kontoen, organisationen eller medarbejderen?
3. Er der en databehandleraftale, og hvilke dele af brugen dækker den?
4. Hvor behandles og opbevares teksten, hvor længe, og hvem kan se den undervejs?
5. Bruges det, der skrives ind, til at træne modeller, og kan det slås fra for jeres konti?
6. Hvad er konsekvensen for personen, hvis teksten slipper ud? Er det ubehageligt, skadeligt eller direkte farligt?
7. Hvilke foranstaltninger har I allerede, og virker nogen af dem inde i browservinduet?
8. Hvad sker der, når en medarbejder alligevel indsætter for meget? Opdager I det, og hvor hurtigt?

Skriv svarene ned. Otte korte svar er en brugbar vurdering, mens et tomt skema med farvekoder ikke er.

Hvornår bliver risikovurderingen til en konsekvensanalyse?

Artikel 35 kræver en konsekvensanalyse, når behandlingen sandsynligvis vil indebære en høj risiko for fysiske personers rettigheder og frihedsrettigheder. Datatilsynet har en liste over behandlinger, der altid udløser kravet, og stiller skabeloner til rådighed, herunder en skabelon møntet på kunstig intelligens.

Konsekvensanalysen adskiller sig fra den almindelige risikovurdering ved at være en formaliseret proces. Den skal dokumenteres, og den skal inddrage de registreredes synspunkter, hvor det er relevant. Viser den, at risikoen fortsat er høj trods foranstaltningerne, skal Datatilsynet høres, før I går i gang.

Kravet udløses af risikoen, ikke af teknologiens navn. Det samme værktøj kan være lavrisiko i kommunikationsafdelingen og højrisiko i sagsbehandlingen.

Hvilke foranstaltninger sænker risikoen?

Datatilsynets katalog over foranstaltninger samler beskrivelser af tekniske og organisatoriske tiltag. Hver beskrivelse forklarer, hvilke risici tiltaget adresserer, og hvad man konkret kan gøre. Kataloget er hverken udtømmende eller absolut, og eksemplerne bygger blandt andet på Datatilsynets egne tilsyn, sager om sikkerhedsbrud og ISO-standarder.

Tre typer tiltag er relevante for AI-brug i browseren:

• Organisatoriske: en kort liste over godkendte tjenester, klare regler for, hvad der aldrig må indsættes, og et sted at spørge, når medarbejderen er i tvivl.
• Tekniske: begrænsninger på, hvad der overhovedet kan forlade maskinen, og på, hvor meget der sendes ad gangen.
• Indbyggede: artikel 25 kræver databeskyttelse gennem design og standardindstillinger, det der på engelsk kaldes privacy by design. Datatilsynet peger på pseudonymisering som en mulig relevant foranstaltning, og den understøtter samtidig dataminimeringen i artikel 5, stk. 1, litra c.

En foranstaltning, der først virker efter mødet i styregruppen, sænker ikke sandsynligheden for, at Anders Andersen indsætter et CPR-nummer i eftermiddag.

Hvem skriver under, og hvad sker der bagefter?

Ansvaret ligger hos den dataansvarlige, altså hos organisationen, ikke hos den enkelte medarbejder og ikke hos leverandøren. Databeskyttelsesrådgiveren rådgiver og følger op, men overtager ikke beslutningen.

Når vurderingen ligger, skal den holdes i live. Artikel 32, stk. 1, litra d kræver en procedure for regelmæssig afprøvning, vurdering og evaluering af, om foranstaltningerne virker. Skifter tjenesten abonnement, eller begynder en ny afdeling at bruge værktøjet, er vurderingen forældet.

Kravet til de tekniske foranstaltninger står i GDPR artikel 32 og AI, og hvad der sker, når det går galt, står i databrud, når persondata havner i en chatbot. Denne side er ikke juridisk rådgivning.

Se også: DPO-tjeklisten til AI-værktøjer og DPIA-udkastet på dokumentationssiden.