Innsikt · 1. mai 2026 · 9 min

Article 9–15-pakken: hva må faktisk være i et conformity assessment-sett?

Du har klassifisert systemet. Det er high-risk under Annex III. Du har lest Article 9 til 15 to ganger. Det er fortsatt uklart hva sluttproduktet er. Denne artikkelen er for fagfolket som er forbi oversikten og trenger å vite hvordan en faktisk leveranse ser ut: hva slags fil, hvor mange sider, hvem som signerer, hvilken kadens.

Article 9–15 er ikke sju dokumenter. Det er ett sammenhengende kvalitetsregime der hver artikkel produserer artefakter som peker på hverandre. En revisor som åpner risk registeret skal kunne navigere til mitigeringen i teknisk dokumentasjon, til testresultatene i accuracy-rapporten, og til logging-konfigurasjonen som beviser at mitigeringen virker i drift. Hvis pakken ikke henger sammen, er den ikke audit-klar — uansett hvor pent dokumentet er formatert.

Oversikten: Article → leveranse → eier → effort

Tallene er for ett system av middels kompleksitet (én modell, én bruksflyt, ett deployment-miljø). Ganger med antall systemer, ikke antall artikler. Pakken er reusable mellom systemer for ca. 50–60 prosent av innholdet.

Article 9 — risk management system

Selve artefaktet er to ting: en risk management policy (5–10 sider, signert av systemeier, beskriver prosessen) og et risk register (regneark eller database, én rad per identifisert risiko, oppdatert kontinuerlig).

Et brukbart risk register har minimum disse kolonnene: ID, beskrivelse, kilde (er det modellrisiko, datarisiko, bruksrisiko, eller systemrisiko?), sannsynlighet, konsekvens, mitigering, status, ansvarlig, dato for siste vurdering. Mange legger på «affected fundamental right» som egen kolonne — det er nyttig fordi Article 9(2)(a) eksplisitt krever vurdering av risiko mot grunnleggende rettigheter, og en revisor leter etter det.

Kadens: Article 9 krever at risikoarbeidet er kontinuerlig, ikke punktvis. I praksis betyr det kvartalsvis gjennomgang som minimum, og umiddelbar oppdatering når systemet endres materielt (ny modellversjon, nytt bruksområde, ny dataset). Eier signerer hver gjennomgang.

Article 10 — data governance pack

Tyngste artikkelen for de fleste. Pakken består av tre lag: dataset cards (én per datasett brukt i trening, validering, og test), bias-evaluering (rapport med metode + resultater + konklusjon), og lineage (hvor kom dataene fra, hva ble gjort med dem, hvem signerte hvert steg).

Et dataset card på 4–8 sider dekker: navn og versjon, formål, kilde og lovlig grunnlag, antall poster og fordeling på relevante demografiske variabler, kjente skjevheter, preprocessing-steg, eier. Google sin dataset-card-mal og Hugging Face sitt dataset-card-spec er begge brukbare utgangspunkt — ikke skriv fra null.

Bias-evalueringen må svare på et konkret spørsmål: presterer modellen tilsvarende på tvers av relevante grupper? «Relevante» bestemmes av bruksområdet. For en kredittscoringsmodell betyr det demografi (kjønn, alder, geografi, eventuelt etnisitet hvor lovlig). For et ansettelsesverktøy betyr det det samme pluss utdanningsbakgrunn. Rapporten skal ha tall, ikke kvalitative betraktninger. Forskjeller på over 5 prosentpoeng i false-positive-rate mellom grupper er typisk noe en revisor vil reagere på.

Lineage-diagrammet er ofte glemt. Det er ikke en arkitektur-tegning. Det er en spesifikk kjede: rådata → preprocessing-script → versjonert tabell → treningssett → modell-artefakt → produksjonsdeployment. Hver pil er sporbar (commit-hash, dataset-versjon, modellversjon). Hvis dere ikke har dette i dag, må det bygges som del av Article 12-arbeidet.

Article 11 — teknisk dokumentasjon

Annex IV i forordningen lister innholdet ganske detaljert. Ikke prøv å være kreativ med strukturen — bruk Annex IV som table of contents direkte. En revisor som åpner dokumentet leter etter spesifikke seksjoner i kjent rekkefølge.

Typisk TOC for et reelt system:

• 1. General description (1–3 sider): formål, intended use, brukergrupper, deployment-modell.
• 2. Detailed system description (10–25 sider): arkitektur, modellvalg, treningsmetodikk, datapipelines, integrasjon med andre systemer.
• 3. Monitoring, functioning and control (3–8 sider): hvordan systemet overvåkes i drift, hva som trigger inngrep.
• 4. Performance metrics (5–15 sider): benchmark-resultater, accuracy, robustness-tester, validation across deployment scenarios.
• 5. Risk management documentation (referanse til Article 9-pakken).
• 6. Changes log (1–3 sider): hver materiell endring siden første versjon, med dato og begrunnelse.
• 7. Standards og spesifikasjoner (1–2 sider): hvilke standarder følges (ISO 42001, ISO 27001, evt. harmonised standards når de blir publisert).
• 8. Declaration of conformity (1 side): selve attestasjonen.

Total sidetall: 25–60 for et middels system. Lengre er ikke bedre — en revisor som må lese 200 sider tenker at dere prøver å gjemme noe.

Article 12 — logging

Den artikkelen som krever mest reell systemendring. Logging må være designet før første dag i produksjon, ikke retrofittet.

Hva som logges ved inferens: input (eller hash av input hvis personopplysninger), modellversjon, output, konfidensnivå hvor relevant, tidsstempel, bruker-ID (pseudonymisert), eventuell human-override. Hva som logges ved trening: dataset-versjon, hyperparametre, treningskode-commit, validation-metrics, eier av treningskjøringen.

Retention er en politikk-beslutning. Article 12 sier «appropriate to the intended purpose» — i praksis 6 måneder til 5 år avhengig av sektor. Finanstilsynet vil typisk forvente 5 år. Helsesektor kan ha lengre krav via journalforskriften. DPO og legal må signere policyen.

Logger må være immutable og tamper-evident. Append-only datastore, hash-chain, eller WORM-storage. En applikasjons-database der noen kan kjøre UPDATE er ikke en compliance-logg.

Article 13 — transparency

To leveranser: instructions for use (et dokument for deployer/operatør, typisk 8–15 sider) og user-facing disclosure (kortere tekstblokker som vises i grensesnittet).

Instructions for use beskriver: hva systemet er, hva det ikke er, hvordan det skal brukes, kjente begrensninger, ytelsesnivå under ulike forhold, og hva som skjer når systemet er usikkert. Dette er ikke markedsføring. Dette er ærlig spesifikasjon. Et eksempel på en god capability statement: «Modellen er testet på norsk språk og presterer 92 prosent F1 på vår validation-set. Den er ikke testet på samisk eller engelsk og bør ikke brukes der.»

User-facing disclosure er kortere og mer brukerrettet. En akseptabel formulering for et chatbot-grensesnitt: «Du snakker med en AI-assistent. Svarene kan være feil. Sensitive saker skal videresendes til saksbehandler ved å klikke her.» Article 50 har bredere transparency-krav for visse system-typer (deepfakes, emotion recognition); sjekk om de overlapper.

Article 14 — human oversight

Operatørens grensesnitt er artefaktet, ikke et dokument om grensesnittet. Skjermbilder og en kort design-rasjonale (3–5 sider) som forklarer hvorfor grensesnittet faktisk muliggjør tilsyn er det som leveres.

Designkrav som ofte mangler: operatøren må kunne se hvorfor systemet foreslo det det foreslo (ikke nødvendigvis full forklaring, men minst de viktigste input-faktorene), operatøren må kunne overstyre uten å måtte gjenta hele saksgangen, og det må være mulig å pause systemet hvis noe åpenbart er feil. «Approve all»-knapp uten kontekst tilfredsstiller ikke Article 14, selv om det teknisk er en human-in-the-loop.

Operatør-trening hører hjemme her. Et trenings-curriculum på 1–2 sider med bevis på gjennomført trening (signaturer, kursrapport) er minimum. Article 14(4) sier eksplisitt at oversiktspersoner må forstå systemets capabilities og limitations.

Article 15 — accuracy og robustness

Benchmark-suiten er artefaktet. Ikke ett tall, men en rapport med fire komponenter: accuracy på en holdout-set som representerer reell bruk, robustness mot input-variasjon (typografiske feil, atypisk fordeling, edge cases), adversarial-tester (prompt injection for LLM-systemer, perturbation for klassifiseringsmodeller), og en drift-overvåkningsplan.

Drift-planen sier: hvilke metrikker måles i produksjon, hvor ofte, hva er terskelen for alarm, hvem mottar alarmen. «Vi sjekker engang i kvartalet» er ikke en drift-plan. «P95 latency, accuracy mot dagens labels-batch, og output-distribusjon-shift måles daglig; alarm til ML-team ved 5 prosent degradering på 7-dagers rullende vindu» er en drift-plan.

Adversarial-test-kategorier for et LLM-system bør minst dekke prompt injection, jailbreaking, sensitiv-informasjon-ekstraksjon, og hallucination under uvanlige forhold. For en klassifiseringsmodell: data-poisoning-resistens, out-of-distribution-deteksjon, og confidence-calibration. Test-resultatene logges i benchmark-rapporten.

Tre ting selskaper gjør feil

1. Risk register som blir et risiko-essay

Et risk register med 12 rader, hver med en lang fritekstbeskrivelse og ingen kvantifisering, er ikke et register. Det er et notat. En revisor scanner kolonner. Hvis dere ikke kan filtrere på «alle risikoer over middels med åpen mitigering», har dere ikke noe å revidere mot. Hold beskrivelser korte (én setning), kvantifiser sannsynlighet og konsekvens, og pek på spesifikke mitigeringer i andre artefakter.

2. Article 11 som statisk PDF

Teknisk dokumentasjon som ikke oppdateres ved hver materielle systemendring er foreldet på utstedelsesdagen. En PDF i SharePoint som ble signert 1. juni 2026 og aldri rørt igjen vil bli avvist av enhver kompetent revisor i 2027. Dokumentasjonen må være levende — versjonert sammen med systemet, oppdatert ved hver release, og linket til endringsloggen i punkt 6.

3. Mangler post-market monitoring-planen

Article 72 krever en post-market monitoring-plan, men den glemmes ofte fordi den ikke er i 9–15-rekken. Planen beskriver hvordan dere overvåker systemet etter at det er deployd, hva som trigger insidentrapportering til myndigheter (Article 73, alvorlige hendelser innen 15 dager), og hvordan post-market-data mater tilbake i Article 9-risk-arbeidet. Uten planen er pakken ikke komplett, uansett hvor god dokumentasjonen ellers er.

Sekvens: hva gjøres først

Hvis dere starter nå med 13 uker til frist, er rekkefølgen pragmatisk og bestemt av hva som krever systemendring versus hva som er dokumentasjon:

1. Uke 1–2: Article 12 (logging) og Article 14 (human oversight UI). Begge krever kode-arbeid og kan ikke kompresseres på slutten.
2. Uke 1–3: Article 9 (risk register) og Article 10 (data governance pack) parallelt. Risk-arbeidet trenger å være «operativt» i flere uker for å være troverdig.
3. Uke 3–6: Article 15 (benchmarks) og Article 13 (instructions for use). Benchmarks krever ferdig modell og test-infrastruktur.
4. Uke 5–8: Article 11 (teknisk dokumentasjon). Skrives sist fordi den oppsummerer alt det andre.
5. Uke 7–9: Post-market plan + conformity-attestasjon. Siste skritt før systemet er audit-klar.

Article 11 sist er kontraintuitivt for jurister, som ofte vil starte der. Men teknisk dokumentasjon kan ikke skrives før de andre artefaktene finnes — den refererer til dem.

Selvattest eller notified body?

For de fleste Annex III-systemer er svaret selvattestasjon. EU AI Act Article 43 krever notified body-involvering primært for biometrisk identifisering (Annex III(1)) og noen sikkerhetskomponenter under Annex I. For kredittscoring, HR-AI, forsikringsprising, og offentlig saksbehandling er internal control-prosedyren i Annex VI tilstrekkelig — dere attesterer selv basert på Article 9–15-pakken.

Ikke gå til notified body med mindre regimet krever det eller dere selger til kunder som krever det. Notified body-prosessen tar 3–6 måneder ekstra og koster typisk 200–400k for et middels system. For et selskap som skal være klar til 2. august 2026, er det realistisk for ekstremt få caser i 2026.

Vil dere ha pakken levert?

Hvis dere ikke vil sette sammen artefaktene selv, leverer Eksponent dette som en fast pakke på 4–6 uker for ett system: alle sju artefakter, lineage-diagram, benchmark-suite kjørt på deres modell, og post-market-plan. Pris 350–500k. Detaljene står på SKU-siden.

Ta gratis EU AI Act-vurdering →

Se EU AI Act Conformity Sprint →

Skrevet av Eksponent. Denne artikkelen er generell informasjon og er ikke juridisk rådgivning. Konkrete tilfeller bør vurderes av kvalifisert jurist eller compliance-rådgiver. Sidetall, timestall, og eksempler er basert på gjennomført arbeid og vil variere per system.