AI-datasikkerhed: hvor ender jeres ordredata og bilag?

Tegn dataflowet, før I vurderer leverandøren

Begynd med én afgrænset opgave, eksempelvis at klargøre en ordre fra en mail. Tegn de steder, hvor indholdet behandles: mailkonto, dokumentudtræk, AI-behandling, eventuelt søgeindeks, log og systemet, der modtager ordrekladden. En funktion kan involvere flere leverandører, selv om medarbejderen kun ser én skærm.

Ud for hvert sted skriver I data, formål, adgang, opbevaring og ansvar. Markér det, I endnu ikke ved. Et ubesvaret spørgsmål er lettere at håndtere end en antagelse, der senere bliver til en sikkerhedsgaranti.

Adskil personoplysninger fra andre fortrolige oplysninger. Navn og direkte kontaktoplysninger kan være personoplysninger, mens kundeaftaler og indkøbspriser også kan kræve beskyttelse af forretningsmæssige grunde. Ikke alle sikkerhedsspørgsmål kan reduceres til GDPR.

Send kun det, opgaven har brug for

GDPR artikel 5 beskriver blandt andet formålsbegrænsning, dataminimering og opbevaringsbegrænsning. I et ordreflow kan det betyde, at en unødvendig mailsignatur eller en historisk tråd ikke skal følge med til hver behandling. Bevar det nødvendige dokumentationsgrundlag dér, hvor det hører til, men undgå ukritisk at kopiere hele arkivet.

En illustrativ ordre lyder: Lever 12 kasser vare A fredag til vores kendte leveringsadresse. Hvis kunden og adressen kan findes i godkendte stamdata, kan opgaven ofte beskrives med en kundereference og den relevante ordretekst. Om det er tilstrækkeligt, skal testes på jeres arbejdsgang; fjernelse af kontekst må ikke skabe forkerte kundematches.

Pseudonymisering er heller ikke det samme som anonymisering. Et kundenummer, som kan kobles tilbage til en person, kan stadig være en personoplysning. Beskriv derfor den faktiske koblingsmulighed i jeres vurdering.

Stil særskilte spørgsmål om træning, logning og sletning

At en leverandør ikke bruger indhold til modeltræning, fortæller ikke i sig selv, hvor længe data ligger i driftslogs, sikkerhedskopier eller søgeindekser. Omvendt er brug af en eksternt leveret model ikke alene bevis for, at virksomhedens oplysninger bruges til offentlig træning. Læs den aftale og de indstillinger, der faktisk gælder for den anvendte tjeneste.

Når en leverandør behandler personoplysninger på jeres vegne, skal rollefordeling og aftalegrundlag afklares. GDPR artikel 28 beskriver krav til brug af databehandlere og underdatabehandlere. Behandling uden for EU/EØS kræver desuden vurdering af de relevante overførselsregler. En serveradresse er ikke hele svaret på, hvem der kan få adgang.

Test adgangen gennem svaret og handlingen

En medarbejder, som ikke må se en anden kundes priser, skal heller ikke kunne få dem gennem et resumé. Test med mindst to forskellige roller og en adgang, der efterfølgende bliver fjernet. Kontrollér både søgeresultater, uddrag, svar og tilladte systemhandlinger.

En teknisk integrationskonto kan have andre rettigheder end brugeren. Derfor skal kontrollen håndhæves i applikationen og de tilsluttede systemer; en prompt med beskeden del ikke fortrolige data er ikke en erstatning. En mail eller et bilag må heller ikke give modellen nye beføjelser, blot fordi teksten beder om det.

GDPR artikel 32 kræver passende tekniske og organisatoriske foranstaltninger i forhold til risikoen. Den konkrete test bør derfor også omfatte et forkert kundematch, en fratrådt medarbejder og et mislykket systemkald, som ellers kunne efterlade følsomt indhold i fejlbeskeder.

Gør godkendelsen af piloten efterprøvbar

Saml dataflow, åbne spørgsmål, aftaler og testresultater på én side. Udpeg den, der godkender anvendelsen, og aftal hvornår vurderingen skal gentages, eksempelvis ved nyt formål, ny datakilde eller ændret leverandør. En konsekvensanalyse efter GDPR artikel 35 kan være nødvendig, når behandlingen sandsynligvis indebærer høj risiko; det er ikke et universelt krav til enhver AI-pilot.

I en NoraOS-afklaring bør I bede om at se de konkrete adgangsområder, godkendelser og aftaledokumenter for jeres løsning. Denne guide er en metode til at stille spørgsmålene, ikke en erklæring om bestemte hostinglande, slettefrister eller træningsvilkår i alle NoraOS-opsætninger.

Begynd med anonymiserede eller konstruerede testbilag, indtil databehandlingen er afklaret. Det skal stadig være realistiske test: forskelle i kundenavne, enheder og rettigheder skal være med, så en pæn demonstration ikke skjuler den fejl, der vil ramme driften.