Övervakning efter utsläppande på marknaden enligt EU:s AI-förordning (Art. 72): Skyldigheter för tillhandahållare av högrisk-AI

Efterlevnad slutar inte vid marknadsinträde. Art. 72 kräver att tillhandahållare av högrisk-AI-system underhåller ett aktivt system för övervakning efter utsläppande, samlar in prestandadata och rapporterar allvarliga incidenter. Här är vad du måste göra — och när.

Vad är övervakning efter utsläppande?

Bedömning av överensstämmelse och CE-märkning är inträdesbiljetten till EU-marknaden för ett högrisk-AI-system — inte mållinjen. Artikel 72 i EU:s AI-förordning inför en fortsatt skyldighet: tillhandahållare måste inrätta och driva ett system för övervakning efter utsläppande (PMM) som aktivt samlar in, analyserar och agerar på verkliga prestandadata under hela systemets operativa livstid.

Logiken är enkel. Ett AI-system validerat på ett fast dataset kan drifta allteftersom verkliga indata förändras, allteftersom användarpopulationen förändras eller allteftersom den miljö det verkar i förändras. Statiska konformitetssnapshots kan inte fånga detta. PMM är mekanismen som omvandlar efterlevnad till en kontinuerlig process snarare än en engångshändelse.

PMM-systemet måste vara proportionerligt mot det högrisk-AI-systemets art och risker. En kreditbedömningsmodell driftsatt i stor skala på miljontals konsumenter kräver intensivare övervakning än ett snävt dokumentklassificeringsverktyg som används internt av ett reglerat företag.

Vem måste inrätta ett PMM-system?

Obligatoriskt för:

• Tillhandahållare av Bilaga III fristående högrisk-AI-system — system listade i Bilaga III som inte är säkerhetskomponenter i en produkt (t.ex. AI som används i anställningsbeslut, tillgång till utbildning, brottsbekämpning, kreditvärdighetsbedömning, förvaltning av kritisk infrastruktur)
• Tillhandahållare av Bilaga I produktinbäddade AI-system — AI-säkerhetskomponenter integrerade i produkter som täcks av befintlig EU-harmonisationslagstiftning (medicintekniska produkter, maskiner, fordon)

Inte obligatoriskt för:

• Tillhandahållare av minimal-risk-AI-system (ingen formell PMM-skyldighet, men god praxis gäller)
• Tillhandahållare av enbart transparens-AI-system (Art. 50-skyldigheter sträcker sig inte till PMM)
• GPAI-modell­tillhandahållare — dessa lyder under ett separat regime enligt Art. 61–62, som inkluderar incidentrapportering för modeller med systemrisk men är strukturerat annorlunda än Art. 72 PMM

Driftsättarens roll är stödjande men inte valfri. Driftsättare måste driva AI-systemet i enlighet med tillhandahållarens anvisningar, aktivera och bevara den loggningsfunktionalitet som är inbyggd i systemet, och — kritiskt — rapportera allvarliga incidenter de känner till till tillhandahållaren utan onödigt dröjsmål. En driftsättare som observerar en allvarlig incident och underlåter att meddela tillhandahållaren är inte efterlevande.

Planen för övervakning efter utsläppande (Bilaga IV, punkt 12)

PMM-planen är en obligatorisk komponent i den tekniska dokumentationen (Bilaga IV). Den kan inte vara ett generiskt dokument: den måste vara specifik för systemet, dess driftsättningskontext och dess identifierade risker. Den måste som minimum definiera:

1. Datainsamling — vilka prestandamätvärden fångas (noggrannhet, felfrekvenser, beslututfall), hur data samlas in (automatiserad telemetri, driftsättarrapporter, användarfeedback) och med vilken frekvens
2. Feedback-loopar — mekanismen genom vilken driftsättare kan rapportera prestandaproblem, avvikelser eller incidenter tillbaka till tillhandahållaren på ett strukturerat och aktuellt sätt
3. Noggrannhetsövervakning — hur systemets prestanda spåras mot det validerade benchmark som användes under bedömning av överensstämmelse, inklusive metodologi för driftdetektering
4. Biasövervakning — för system där demografiska utfall är materiella (anställning, kredit, brottsbekämpning), löpande övervakning av statistiska skillnader bland skyddade grupper, med definierad metodologi och tröskelvärden
5. Uppdateringsutlösare — de specifika kvantitativa eller kvalitativa tröskelvärdena som ger upphov till korrigerande åtgärder, inklusive modelomträ­ning, parameteranpassning eller driftsättningsuppehåll
6. Granskningsschema — hur ofta PMM-planen i sig granskas och uppdateras, för att säkerställa att den förblir ändamålsenlig allteftersom driftsättningskontexten förändras

PMM-planen måste hållas uppdaterad. En föråldrad plan som inte längre speglar den faktiska övervakningsmetodologin uppfyller inte Art. 72.

Rapportering av allvarliga incidenter (Art. 73)

Vad utgör en allvarlig incident?

Artikel 73 definierar en allvarlig incident som en incident eller ett fel i ett högrisk-AI-system som direkt eller indirekt leder till:

• Dödsfall eller allvarlig skada på hälsan (fysisk eller psykologisk)
• En allvarlig och oåterkallelig störning av förvaltning eller drift av kritisk infrastruktur
• Ett allvarligt brott mot grundläggande rättigheter (integritet, icke-diskriminering, rättssäkerhet)
• En situation där en person just undvek något av ovanstående

Det är viktigt att AI-förordningen inte kräver att ett orsakssamband med AI-systemet fastställs innan rapportering. En rimlig misstanke om att AI-systemet bidrog till eller underlät att förhindra skadan räcker för att utlösa skyldigheten. Tillhandahållare som väntar på säkerhet innan rapportering riskerar bristande efterlevnad.

Rapporteringstidsfrister

15-dagarsklockan börjar när tillhandahållaren får kännedom om incidenten — vilket i praktiken innebär när driftsättaren meddelar dem. Tillhandahållare bör utforma sina förfaranden för driftsättarmeddelande så att information når dem tillräckligt snabbt för att uppfylla den nedströms rapporteringstidsfristen.

Vad en incidentrapport måste innehålla

En konform incidentrapport till den nationella marknadskontrollmyndigheten bör inkludera:

• Systemidentifiering: namn, version, EU-databasregistreringsnummer
• Beskrivning av incidenten: vad som hände, vilken skada som uppstod eller just undveks, datum och plats
• Berörda personer: antal och kategorier av berörda användare eller tredje parter (anonymiserade där GDPR kräver)
• Preliminär kausal analys: tillhandahållarens aktuella förståelse av hur incidenten uppstod, tydligt märkt som preliminär
• Omedelbara korrigerande eller säkerhetsåtgärder vidtagna: eventuella åtgärder som redan vidtagits för att begränsa ytterligare skada eller risk (t.ex. avstängning av påverkad funktionalitet, driftsättarmeddelanden)
• Kontaktpunkt: den person eller det team som ansvarar för uppföljningskorrespondens med myndigheten

Rapporten bör vara faktabaserad och proportionerlig. Preliminära rapporter kan kompletteras med uppföljningsrapporter allteftersom utredningen fortskrider.

Obligatorisk loggning (Art. 12)

Artikel 12 kräver att högrisk-AI-system är designade och byggda med kapacitet att automatiskt generera loggar på en granularitetsnivå som räcker för att möjliggöra:

• Övervakning efter utsläppande i enlighet med Art. 72
• Spårning av händelseförlopp som ledde till en allvarlig incident
• Utredning av nationella myndigheter

Detta är ett designkrav som åläggs tillhandahållaren. Tillhandahållaren måste bygga in loggningskapaciteten i systemet innan det placeras på marknaden.

Skyldigheten att aktivera och bevara dessa loggar faller på driftsättaren. Driftsättare får inte inaktivera loggningsfunktionaliteten och måste bevara loggar under den period som anges i tillhandahållarens anvisningar och tekniska dokumentation. Där ingen specifik bevarandeperiod definieras bör loggar bevaras under en period som är jämförbar med systemets operativa livscykel och eventuella sektorsspecifika krav (t.ex. finanssektorns dokumentationsregler enligt DORA eller MiFID II).

Väsentliga modifieringar och ny bedömning

Inte varje ändring av ett driftsatt AI-system utlöser en ny bedömning av överensstämmelse. Förordningen skiljer mellan mindre uppdateringar och väsentliga modifieringar.

En modifiering är väsentlig — och kräver en ny bedömning av överensstämmelse och uppdaterad teknisk dokumentation — när den:

• Förändrar systemets avsedda syfte (ens delvis)
• Innebär en väsentlig ändring av arkitekturen eller träningsmetodiken
• Använder nya träningsdata som väsentligt påverkar systemets prestanda på sätt som kan påverka efterlevnadsrelevant beteende
• Försämrar prestanda utöver tröskelvärden definierade i riskhanteringsdokumentationen på sätt som påverkar säkerhet eller grundläggande rättigheter

Mindre uppdateringar — säkerhetspatchar, felkorrigeringar som korrigerar tydligt identifierade defekter utan att ändra efterlevnadsrelevant beteende, kosmetiska gränssnittsändringar — kräver inte en full ny bedömning. De måste dock dokumenteras, och tillhandahållaren måste bevara en skriftlig bedömning som bekräftar att modifieringen inte utgör en väsentlig modifiering. Det registret är föremål för inspektion av marknadskontrollmyndigheter.

Praktisk implementerings­checklista

Följande checklista speglar minimioperativa krav enligt Art. 72, Art. 73 och Art. 12. Det ersätter inte juridisk rådgivning men ger en utgångspunkt för gapanalys.

• [ ] PMM-plan dokumenterad i den tekniska filen (Bilaga IV, punkt 12), specifik för systemet och dess driftsättningskontext
• [ ] Automatisk loggningskapacitet designad och inbyggd i systemet före marknadsplacering
• [ ] Driftsättaranvisningar inkluderar ett tydligt, skriftligt förfarande för incidentrapportering med eskaleringskontakt
• [ ] Intern kontaktpunkt för incidentrapportering inrättad och meddelad till den berörda nationella marknadskontrollmyndigheten
• [ ] Processer eller dashboards för bias- och noggrannhetsövervakning definierade, med dokumenterad metodologi och tröskelvärden
• [ ] Eskaleringströskelvärden för korrigerande åtgärder dokumenterade och länkade till riskhanteringssystemet
• [ ] Förfarande för bedömning av väsentlig modifiering på plats, med en beslutsdokumentsmall för varje uppdatering
• [ ] Policy för loggbevarande definierad, kommunicerad till driftsättare och anpassad till sektorsspecifika bevaranderegler

Korsreferenser: Teknisk dokumentation — Bilaga III högrisk-AI-system — Tillhandahållare kontra driftsättare