Tjekliste til AI-forordningen for idriftsættere

Det her er en arbejdstjekliste, ikke juridisk rådgivning. Den er skrevet fra en arkitekturvinkel: hvert spørgsmål peger på noget, et system enten gør eller ikke gør. Hent den juridiske vurdering hos jeres egen rådgiver, og bekræft den gældende tidsplan, før I planlægger efter den, da den er blevet ændret, siden forordningen trådte i kraft.

Kør den per system frem for per organisation. Svarene er forskellige, og et organisatorisk gennemsnit skjuler netop det system, der kommer til at give problemet.

1. Anvendelsesområde og rolle

• Står systemet på jeres opgørelse over AI-systemer, og har den opgørelse en navngiven ejer?
• Er I idriftsætter, eller er I blevet udbyder ved at sætte jeres navn på systemet, ændre det væsentligt eller ændre dets formål?
• Hvad er det angivne formål, og svarer den faktiske anvendelse fortsat til det?
• Falder systemet i en forbudt kategori, en højrisikokategori eller ingen af delene, og hvem traf den vurdering?

Findes opgørelsen ikke, så stop her og lav den. Alle øvrige spørgsmål er ubesvarlige i organisatorisk skala uden den, og de fleste organisationer opdager systemer, de ikke vidste kørte.

2. Menneskeligt tilsyn

• Er en bestemt rolle ansvarlig for tilsynet med systemet, navngivet frem for underforstået?
• Giver grænsefladen den person mulighed for at forkaste eller tilsidesætte et output, eller kun for at se det?
• Har vedkommende kompetencen til at bedømme outputtet og bemyndigelsen til at handle på bedømmelsen?
• Registreres det, når der tilsidesættes, så tilsynet kan vises at være reelt frem for formelt?

Den typiske fejl er et godkendelsestrin uden mulighed for at forkaste. En person, der kun kan se på, udfører ikke tilsyn, og en grænseflade uden tilsidesættelse kan ikke dokumenteres til at blive det.

3. Data og input

• Kan I beskrive, hvilke data systemet forbruger, og hvor hver kilde kommer fra?
• Er de inputdata relevante og tilstrækkeligt repræsentative for det angivne formål?
• Behandler systemet personoplysninger, og på hvilket behandlingsgrundlag?
• Kan I for et givet output spore, hvilke input og kilder der frembragte det?

4. Logning og dokumentation

• Genererer systemet logs automatisk frem for på anmodning?
• Er der fastlagt en opbevaringsperiode, og rækker lagringen faktisk så langt?
• Fanger loggene nok til at rekonstruere en afgørelse, herunder model- og kontekstversion?
• Kunne I fremskaffe registreringen for én navngiven sag inden for en arbejdsdag?

Det sidste spørgsmål er det nyttige. Opbevaringspolitikker er lette at skrive, og hullet viser sig som regel, når nogen forsøger at finde en bestemt interaktion fra fire måneder siden.

5. Gennemsigtighed og mennesker

• Hvor systemet interagerer med mennesker, står det klart for dem, at de har med en maskine at gøre?
• Hvor det genererer indhold, bliver indholdet mærket som syntetisk allerede ved frembringelsen?
• Hvor det bruges på arbejdspladsen, er medarbejdere og deres repræsentanter informeret inden idriftsættelsen?
• Har de medarbejdere, der arbejder med systemet, tilstrækkelig forståelse af, hvad det gør, og hvor det fejler?

Hvert spørgsmål her besvares af systemet eller slet ikke. En politik, der beskriver den ønskede adfærd, er ikke dokumentation for, at adfærden finder sted.

At læse resultatet

Et system, der fejler på logning eller tilsyn, har et arkitektonisk hul, og udbedringen er udviklingsarbejde med en leveringstid. Et system, der fejler på spørgsmålene om anvendelsesområde, har et governance-hul, som er hurtigere at lukke og som regel afdækker flere fejl andre steder.

Fejler et system på det meste af afsnit 1, er det ikke klar til en compliance-samtale. Få først fastlagt, hvad det er, og hvem der ejer det.

Det vi anbefaler

Lav opgørelsen før vurderingen. Arbejd derefter listen igennem på jeres to eller tre mest eksponerede systemer frem for at forsøge hele porteføljen, eftersom mønstret i hullerne gentager sig, og at lukke det ét sted som regel lukker det bredt.

Vær konservativ i klassificeringen. Argumentationen skal kunne holde senere, og det er billigere at overforberede et grænsetilfælde nu end at forsvare et tyndt argument under et tilsyn. Hvor et system ligger tæt på grænsen, er det ofte billigere end begge dele at redesigne det, så det tydeligt ligger under.

Hvor bør en parathedsvurdering efter AI-forordningen begynde?

Med en opgørelse over de AI-systemer, der allerede kører, inklusive dem der blev taget i brug uden et projekt. Notér formål, ansvarlig ejer, berørte data, og om I er udbyder eller idriftsætter. Alle andre spørgsmål er ubesvarlige i skala uden den liste.

Hvad tæller som menneskeligt tilsyn i praksis?

En navngiven rolle med kompetencen til at bedømme et output og bemyndigelsen til at tilsidesætte det, med en grænseflade der reelt tilbyder at forkaste, og hvor tilsidesættelser registreres. Et godkendelsestrin, der kun tillader visning, er ikke tilsyn og kan ikke dokumenteres til at blive det.

Hvilken logning kræves der til et AI-system i drift?

Automatisk genererede logs, en fastlagt opbevaringsperiode, som lagringen faktisk overholder, og nok registreret til at rekonstruere en afgørelse, herunder model- og kontekstversion. Den praktiske prøve er, om I kunne fremskaffe registreringen for én navngiven sag inden for en arbejdsdag.

Skal vi vurdere alle systemer eller begynde med nogle få?

Begynd med de to eller tre mest eksponerede systemer. Mønstret i hullerne gentager sig som regel på tværs af porteføljen, så at lukke det ét sted lukker det bredt, og en fuld gennemgang før enhver udbedring udskyder det arbejde, der betyder noget.