Hvad AI-forordningen kræver af idriftsættere

Det første, der skal afklares, er, hvilken rolle I har efter AI-forordningen. Udbydere bringer et AI-system i omsætning. Idriftsættere anvender et under eget ansvar. Forpligtelserne er væsentligt forskellige, og de fleste organisationer, vi arbejder med, er idriftsættere, der tror, de er udbydere, eller udbydere, der ikke har opdaget, at de er blevet det.

Artiklen er skrevet fra en arkitekturvinkel frem for en juridisk. Læs den som en beskrivelse af, hvad forpligtelserne betyder for systemdesign, og hent den juridiske vurdering hos jeres egen rådgiver. Særligt tidsplanen er blevet ændret, siden forordningen trådte i kraft, så bekræft de gældende datoer, før I planlægger efter dem.

Sådan bliver man udbyder uden at ville det

Rollen som idriftsætter er ikke permanent. Sætter I jeres eget navn eller varemærke på et højrisikosystem, foretager I en væsentlig ændring af et, eller ændrer I formålet med et system, så det bliver højrisiko, overgår udbyderforpligtelserne til jer.

Det har betydning for et udbredt mønster: at tage en generel model, lægge søgning og prompts omkring den og sætte den i drift til et formål, den oprindelige udbyder aldrig beskrev. Om det udgør en væsentlig ændring, er en juridisk vurdering, men det er en, det er værd at foretage bevidst frem for at opdage under et tilsyn.

Hvad idriftsættere reelt bliver bedt om

For højrisikosystemer er forpligtelserne overvejende driftsmæssige, og derfor lander de i arkitekturen frem for i et politikdokument.

• Anvend systemet i overensstemmelse med udbyderens brugsanvisning, hvilket kræver, at anvisningen findes i jeres driftsdokumentation frem for i en PDF, ingen har åbnet
• Placer det menneskelige tilsyn hos personer med både kompetencen og bemyndigelsen til at tilsidesætte et output, ikke kun til at se det
• Sørg for, at inputdata er relevante og tilstrækkeligt repræsentative for formålet, hvilket er en egenskab ved datapipelinen
• Overvåg driften, og underret udbyder og myndigheder, når en alvorlig hændelse eller risiko opstår
• Opbevar automatisk genererede logs i en fastlagt periode, hvilket betyder, at logning skal designes ind frem for stikprøves
• Informer medarbejdere og deres repræsentanter, før et system tages i brug på arbejdspladsen

Læs den liste som en systemspecifikation. Hvert punkt er noget, en arkitektur enten understøtter eller ikke understøtter, og at eftermontere et af dem i en kørende installation koster mere end at designe efter det.

Gennemsigtighed gælder langt under højrisiko

Systemer, der interagerer med mennesker, skal som udgangspunkt gøre det klart, at man har med en maskine at gøre, og syntetisk indhold skal som udgangspunkt mærkes som sådant. De pligter er lettere end højrisikoreglerne og rammer en langt bredere kreds af installationer, herunder den assistent, nogen satte op i en servicedesk uden at fortælle det til nogen.

Der gælder også en kompetenceforpligtelse. Organisationer forventes at sikre, at medarbejdere, der arbejder med disse systemer, har tilstrækkelig forståelse af dem. Det er en uddannelses- og dokumentationsopgave med en reel omkostning, og den er nem at glemme i en projektplan.

Hvorfor det er et arkitekturproblem

Compliance gribes normalt an som dokumentation, der produceres, efter et system er bygget. For de her forpligtelser holder den rækkefølge ikke, fordi de fleste af dem kun kan opfyldes gennem egenskaber, systemet enten har eller mangler.

I kan ikke opbevare logs, I aldrig genererede. I kan ikke påvise menneskeligt tilsyn, hvis grænsefladen ikke giver mulighed for at forkaste et output. I kan ikke vise, at inputdata var egnede, uden dataherkomst. I kan ikke mærke syntetisk indhold, efter det er distribueret. Hver af delene afgøres under designet og er dyr at tilføje bagefter.

En politik beskriver, hvad der bør ske. Kun systemet afgør, hvad der sker, og kun systemet kan fremlægge dokumentationen.

Hvor I begynder

Begynd med at få overblik. De fleste organisationer kan ikke fremvise en liste over de AI-systemer, der allerede kører hos dem, og en forpligtelse, I ikke kan opgøre, er en, I ikke kan opfylde. Notér for hvert system, hvad det gør, hvem der er ansvarlig for det, hvilke data det berører, og hvilken rolle I har for det.

Klassificér derefter ærligt. Fristelsen er at argumentere hvert system ned i en lavere kategori. Den argumentation skal kunne holde til et eftersyn senere, så det er billigere at være konservativ nu, og endnu billigere at redesigne et grænsetilfælde, så det tydeligt ligger under grænsen.

At klassificere et system ærligt er en arkitekturmæssig vurdering, før det er en juridisk en: hvad systemet reelt beslutter, og for hvem, skal kunne spores i designet snarere end argumenteres bagefter. Det er det samme udgangsspørgsmål bag enhver gennemgang af systemarkitektur, vi laver — ikke hvilket niveau et system bør ligge på, men hvad der skulle være sandt om det, for at svaret var indlysende.

Er vi udbyder eller idriftsætter efter AI-forordningen?

Anvender I et AI-system under eget ansvar, er I idriftsætter. I påtager jer udbyderforpligtelser, hvis I sætter jeres eget navn eller varemærke på et højrisikosystem, ændrer det væsentligt, eller ændrer formålet, så det bliver højrisiko. At bygge et produkt oven på en generel model kan flytte jer over den grænse.

Hvad betyder idriftsætterforpligtelserne for, hvordan et system bygges?

De fleste af dem er egenskaber ved systemet frem for papirarbejde: opbevarede logs, en grænseflade der reelt lader et menneske tilsidesætte et output, dataherkomst nok til at vise, at input var egnede, og overvågning der bringer hændelser frem. De er billige at designe ind og dyre at eftermontere.

Gælder AI-forordningen for interne værktøjer?

Anvendelse inden for jeres egen organisation er stadig anvendelse. Interne installationer bliver ofte overset i opgørelser, og anvendelse på arbejdspladsen udløser en yderligere pligt til at informere medarbejdere og deres repræsentanter, før systemet tages i brug.

Hvor bør en organisation 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 jeres rolle for hvert af dem. Klassificering og udbedring er overkommelige, når listen findes, og umulige før.