EU AI-forordningens eftersalgsovervågning (Art. 72): Forpligtelser for højrisiko-AI-udbydere

Overholdelse slutter ikke ved markedstilgang. Art. 72 kræver, at udbydere af højrisiko-AI-systemer opretholder et aktivt eftersalgsovervågningssystem, indsamler præstationsdata og rapporterer alvorlige hændelser. Her er hvad du skal gøre — og hvornår.

Hvad er eftersalgsovervågning?

Overensstemmelsesvurdering og CE-mærkning er adgangsbilletten til EU-markedet for et højrisiko-AI-system — ikke målstregen. Artikel 72 i EU AI-forordningen pålægger en fortsat forpligtelse: udbydere skal etablere og drive et eftersalgsovervågningssystem (PMM), der aktivt indsamler, analyserer og handler på virkelighedens præstationsdata gennem hele systemets operationelle levetid.

Begrundelsen er ligetil. Et AI-system valideret på et fast datasæt kan drifte, efterhånden som virkelighedens input skifter, efterhånden som brugerpopulationen ændrer sig eller efterhånden som miljøet, hvori det opererer, udvikler sig. Statiske overensstemmelsessnapshots kan ikke indfange dette. PMM er mekanismen, der gør overholdelse til en kontinuerlig proces frem for en engangsbegivenhed.

PMM-systemet skal stå i rimeligt forhold til arten og risiciene ved det pågældende højrisiko-AI-system. En kreditvurderingsmodel implementeret i stor skala på tværs af millioner af forbrugere vil kræve mere intensiv overvågning end et snævert dokumentklassificeringsværktøj, der bruges internt af en reguleret virksomhed.

Hvem skal etablere et PMM-system?

Obligatorisk for:

• Udbydere af Bilag III selvstændige højrisiko-AI-systemer — systemer oplistet i Bilag III, der ikke er sikkerhedskomponenter i et produkt (f.eks. AI brugt i ansættelsesbeslutninger, adgang til uddannelse, retshåndhævelse, kreditvurdering, forvaltning af kritisk infrastruktur)
• Udbydere af Bilag I produktintegrerede AI-systemer — AI-sikkerhedskomponenter integreret i produkter dækket af eksisterende EU-harmoniseret lovgivning (medicinsk udstyr, maskiner, køretøjer)

Ikke krævet for:

• Udbydere af minimal-risiko-AI-systemer (ingen formel PMM-forpligtelse, selvom god praksis gælder)
• Udbydere af kun-gennemsigtighed-AI-systemer (Art. 50-forpligtelserne strækker sig ikke til PMM)
• GPAI-modeludbydere — disse er underlagt et separat regime under Art. 61-62, som inkluderer hændelsesrapportering for modeller med systemisk risiko, men er struktureret anderledes end Art. 72 PMM

Deployerens rolle er støttende men ikke valgfri. Deployere skal drive AI-systemet i overensstemmelse med udbyderens retningslinjer, aktivere og opbevare den logningsfunktionalitet, der er indbygget i systemet, og — kritisk — rapportere eventuelle alvorlige hændelser, de bliver opmærksomme på, til udbyderen uden unødig forsinkelse. En deployer, der observerer en alvorlig hændelse og undlader at underrette udbyderen, er ikke compliant.

Plan for eftersalgsovervågning (Bilag IV, punkt 12)

PMM-planen er en obligatorisk komponent af den tekniske dokumentation (Bilag IV). Det kan ikke være et generisk dokument: det skal være specifikt for systemet, dets implementeringskontekst og dets identificerede risici. Mindst skal det definere:

1. Dataindsamling — hvilke præstationsmetrikker fanges (nøjagtighed, fejlrater, beslutningsresultater), hvordan data indsamles (automatisk telemetri, deployerrapporter, brugerfeedback) og med hvilken hyppighed
2. Feedback-sløjfer — den mekanisme, hvorved deployere kan rapportere præstationsproblemer, anomalier eller hændelser tilbage til udbyderen på en struktureret og rettidig måde
3. Nøjagtighedsovervågning — hvordan systemets præstation spores mod det validerede benchmark brugt under overensstemmelsesvurderingen, herunder eventuel driftdetektionsmetodik
4. Skævhedsovervågning — for systemer, hvor demografiske resultater er materielle (ansættelse, kredit, retshåndhævelse), løbende overvågning af statistiske forskelle på tværs af beskyttede grupper, med defineret metodik og tærskler
5. Opdateringsudløsere — de specifikke kvantitative eller kvalitative tærskler, der prompt korrigerende handling, herunder modelgenträning, parameterjustering eller suspenderet implementering
6. Gennemgangsplan — hvor ofte PMM-planen selv gennemgås og opdateres, og sikrer, at den forbliver egnet til formålet, efterhånden som implementeringskonteksten udvikler sig

PMM-planen skal holdes opdateret. En forældet plan, der ikke længere afspejler den faktiske overvågningsmetodik, opfylder ikke Art. 72.

Rapportering af alvorlige hændelser (Art. 73)

Hvad udgør en alvorlig hændelse?

Artikel 73 definerer en alvorlig hændelse som enhver hændelse eller fejlfunktion i et højrisiko-AI-system, der direkte eller indirekte fører til:

• Død eller alvorlig sundhedsskade (fysisk eller psykologisk)
• En alvorlig og uoprettelig forstyrrelse af forvaltningen eller driften af kritisk infrastruktur
• En alvorlig krænkelse af grundlæggende rettigheder (privatliv, ikke-diskriminering, retfærdig rettergang)
• En situation, hvor en person næsten undgik nogen af ovenstående

AI-forordningen kræver ikke, at der er etableret en årsagssammenhæng til AI-systemet inden rapportering. En rimelig mistanke om, at AI-systemet bidrog til eller undlod at forhindre skaden, er tilstrækkelig til at udløse forpligtelsen. Udbydere, der venter på sikkerhed inden rapportering, risikerer manglende overholdelse.

Rapporteringstidslinjer

15-dages uret starter, når udbyderen bliver opmærksom på hændelsen — hvilket i praksis er, når deployeren underretter dem. Udbydere bør designe deres deployer-underretningsprocedurer, så information når dem hurtigt nok til at opfylde den efterfølgende rapporteringsfrist.

Hvad en hændelsesrapport skal indeholde

En overensstemmende hændelsesrapport til den nationale markedsovervågningsmyndighed bør inkludere:

• Systemidentifikation: navn, version, EU-databaseregistreringsnummer
• Beskrivelse af hændelsen: hvad skete der, hvilken skade opstod eller var nær-undgået, dato og sted
• Berørte personer: antal og kategorier af berørte brugere eller tredjeparter (anonymiseret, hvor GDPR kræver det)
• Foreløbig årsagsanalyse: udbyderens nuværende forståelse af, hvordan hændelsen opstod, tydeligt mærket som foreløbig
• Øjeblikkelige korrigerende eller sikkerhedsforanstaltninger truffet: eventuelle skridt allerede taget for at begrænse yderligere skade eller risiko (f.eks. suspendering af berørt funktionalitet, deployer-underretninger)
• Kontaktpunkt: den person eller det team, der er ansvarlig for opfølgningskorrespondance med myndigheden

Rapporten bør være faktuel og proportional. Foreløbige rapporter kan suppleres af opfølgningsrapporter, efterhånden som undersøgelsen skrider frem.

Obligatorisk logning (Art. 12)

Artikel 12 kræver, at højrisiko-AI-systemer er designet og bygget med kapaciteten til automatisk at generere logfiler på et granularitetsniveau, der er tilstrækkeligt til at muliggøre:

• Eftersalgsovervågning i overensstemmelse med Art. 72
• Sporing af hændelser, der førte til en alvorlig hændelse
• Undersøgelse af nationale myndigheder

Dette er et designkrav pålagt udbyderen. Udbyderen skal bygge logningskapaciteten ind i systemet, inden det markedsføres.

Forpligtelsen til at aktivere og opbevare disse logfiler påhviler deployeren. Deployere må ikke deaktivere logningsfunktionalitet og skal opbevare logfiler i den periode, der er specificeret i udbyderens retningslinjer og tekniske dokumentation. Hvor ingen specifik opbevaringsperiode er defineret, bør logfiler opbevares i en periode, der svarer til systemets operationelle livscyklus og eventuelle sektorspecifikke krav (f.eks. regler om registrering af finansielle tjenester under DORA eller MiFID II).

Væsentlige modifikationer og genvurdering

Ikke enhver ændring af et implementeret AI-system udløser en ny overensstemmelsesvurdering. Forordningen skelner mellem mindre opdateringer og væsentlige modifikationer.

En modifikation er væsentlig — og kræver en ny overensstemmelsesvurdering og opdateret teknisk dokumentation — når den:

• Ændrer systemets tilsigtede formål (selv delvist)
• Involverer en væsentlig ændring af arkitekturen eller træningsmætodig
• Bruger nye træningsdata, der materielt påvirker systemets præstation på måder, der kan påvirke overensstemmelses-relevant adfærd
• Forringer præstationen ud over tærsklerne defineret i risikostyringsdokumentationen på måder, der påvirker sikkerhed eller grundlæggende rettigheder

Mindre opdateringer — sikkerhedsrettelser, fejlrettelser, der korrigerer klart identificerede defekter uden at ændre overensstemmelses-relevant adfærd, kosmetiske interface-ændringer — kræver ikke en fuld genvurdering. Dog skal de dokumenteres, og udbyderen skal opbevare en skriftlig vurdering, der bekræfter, at modifikationen ikke udgør en væsentlig modifikation. Den pågældende optegnelse er underlagt inspektion fra markedsovervågningsmyndigheder.

Praktisk implementeringstjekliste

Følgende tjekliste afspejler de minimale operationelle krav under Art. 72, Art. 73 og Art. 12. Det er ikke en erstatning for juridisk rådgivning, men giver et udgangspunkt for kløftanalyse.

• [ ] PMM-plan dokumenteret i den tekniske fil (Bilag IV, punkt 12), specifik for systemet og dets implementeringskontekst
• [ ] Automatisk logningskapacitet designet og bygget ind i systemet inden markedsplacering
• [ ] Deployer-retningslinjer inkluderer en klar, skriftlig hændelsesrapporteringsprocedure med eskaleringskontakt
• [ ] Hændelsesrapporteringskontaktpunkt etableret internt og meddelt den relevante nationale markedsovervågningsmyndighed
• [ ] Skævheds- og nøjagtighedsovervågningsprocesser eller -dashboards defineret med dokumenteret metodik og tærskler
• [ ] Eskaleringstærskler for korrigerende handling dokumenteret og forbundet til risikostyringssystemet
• [ ] Procedure for vurdering af væsentlig modifikation på plads med en beslutningsoptegnelsesskabelon for hver opdatering
• [ ] Logopbevaringspolitik defineret, kommunikeret til deployere og tilpasset sektorspecifikke opbevaringsregler

Krydsreferencer: Teknisk dokumentation — Bilag III højrisiko-AI-systemer — Udbydere vs. deployere