Hvad dokumentationsforpligtelsen dækker

Artikel 11 og bilag IV fastsætter dokumentationsindholdet for systemer med høj risiko. Pakken omfatter det ønskede formål, designvalg, udviklings- og testhistorik, ydeevnekrav og de risikostyringsforanstaltninger, der faktisk er gennemført. Kommissionen opsummerer direktivet som et risikobaseret rammeværk med tungere pligter for højrisikoanvendelser; start med denne ramme, før du opfinder en brugerdefineret skabelon (Europæisk Kommission — AI-direktivet).

Den bindende tekst er selv reguleringen på EUR-Lex (Forordning (EU) 2024/1689). Sekundære blogs og præsentationsfiler er kun nyttige, når du kan pege på artikel- og bilagnummeret, der understøtter hver påstand. Jeg behandler dokumentation som en levende fil under versionskontrol, ikke en engangsexporterede PDF-fil ugen før en demo.

Livscyklus, ikke et freeze-frame

Hvis modellen ændres, træningsmængden opdateres eller en sikkerhedsregulering omkonfigureres, skal dokumentationen vise delta. Ændringsnoter, ejere og datoer er lige så vigtige som den første skrivning. Når en udgiver spørger "hvilken build var i produktion tirsdag?", skal du svare fra den samme post, der understøtter overensstemmelse — ikke fra en Slack-tråd.

Trin-for-trin-arbejdsgang, som vi bruger, før vi kalder en pakke "klar"

- Bekræft, at systemet er højrisiko (eller vil behandles som sådan) under Artikel 6 / Bilag III, før du opfinder en dokumentationsstruktur. Hvis det ikke er højrisiko, skal du ikke overdriveligt påstå Bilag IV's fuldstændighed i salgs kopien. - Åbn Bilag IV og opret en mappe eller billet per tema: generel beskrivelse, designspecifikationer, udviklingsproces, data, risikostyring, test, overvågning og menneskelig overvågning. - Tildel en enkelt ejer per tema. Fælles ejerskab uden navn er, hvordan sektioner bliver tomme. - Udkast med produkt og ingeniør i rummet. Juridiske gennemgange kræver beviser; ingeniører leverer bevisstier (konfigurationer, dashboards, testrapporter). - Link hver påstand til en artifact: en datasætssammenfattning, en log-skema, en kørebog, en risikoregister-række. Ulinket prosa er en lugt. - Gennemgå pakken mod det levende system: matcher log-konfigurationen Artikel 12-påstandene? Matcher omgangsvejen i brugergrænsefladen Artikel 14-teksten? - Planlæg en opdateringstrigger: modelversionsspring, materiel datasætsændring, ny deployerklasse eller alvorlig-ulykke nærmest.

VendorVet omdanner disse temaer til en arbejdende tjekliste. Det erstatter ikke meddelelse om domstolens eller rådgivningens dom. Brug produktet til at fange omissions tidligt; brug Den Officielle Journal til at afklare diskussioner.

Oplysninger om datasæt, som teams springer over (Artikel 10)

Artikel 10 forventer datastyring: trænings-, validerings- og testdata skal være relevante og repræsentative for det ønskede formål, med undersøgelse af fordomme og huller, der ville skade ydeevnen for de personer, systemet vil påvirke. Revisorer søger efter en opsummering af, hvilke data der er blevet brugt, og hvordan de er blevet undersøgt - ikke en markedsføringsmodelkort med tre tilfældige adjektiver.

En checklisterække, der siger "data gennemgået" med ingen opsummering bagved, fejler den første alvorlige gennemgang. Skriv opsummeringen, så en ny ingeniør kan svare: kilde-domæner, tidsvinduer, kendte skævheder, eksklusionsregler og hvordan mærkerne blev produceret eller gennemgået. Hvis persondata befinder sig i pipeline, skal du holde dine GDPR-roller og -grundlag konsistente med, hvordan du beskriver behandlingen andre steder; EDPB-retningslinjebiblioteket er det praktiske kontrolpunkt for det sprog (EDPB-retningslinjer og bedste praksis).

Checkliste - databevis

- Inventar af trænings-/validerings-/test-sæt med ejerskab og seneste opdateringsdato - Noter om repræsentativitet knyttet til det ønskede formål (hvem er omfattet, hvem er udenfor) - Metode til undersøgelse af fordomme og fejl - selvom den er uperfekt - med resterende risiko angivet - Mærknings- eller annoteringsproces, herunder kvalitetskontroller - Regler for opbevaring og adgang til datasættene selv

Human-oversigt design (Artikel 14)

Artikel 14 kræver meningsfuld human oversigt: grænseflader og kontroller, der giver en person mulighed for at overvåge, fortolke og omgå udgangspunkter, når det er nødvendigt. "Mennesker forbliver i løkken" er ikke en mekanisme. Dokumentér den specifikke omgåelsesvej, hvem der kan udøve den, hvordan systemet signalerer, at et menneske skal gribe ind, og hvad der sker, når mennesket ikke er tilgængeligt.

I agentprodukter betyder dette ofte en hård stop før en konsekvensfuld handling (udgivelse af shortlist, kreditaftale, opdatering af sagfil), og ikke en dekorativ godkendelsesknap, der automatisk aktiveres efter tre sekunder. Par UI-beskrivelsen med runtime-policyen: hvilke roller, hvilke miljøer, hvilke overvågningsbegivenheder aktiveres, når omgåelse bruges.

Checkliste — bevis for oversigt

- Navngivne oversigtsroller og eskalationsvej - UI- eller API-kontroller, der faktisk pauserer eller omgår AI-handlingen - Signaler / grænseværdier, der kræver menneskelig gennemgang - Uddannelse eller kørebog for de mennesker, der har oversigt - Bevis for, at omgåelseshændelser er logget

Overvågning og logning efter markedsføring (Artikler 12 og 72)

Artikel 12 kræver automatisk logning, der er tilstrækkelig til sporing, med en minimumsbevarelse på seks måneder for systemer med høj risiko. Artikel 72 tilføjer pligter til rapportering af alvorlige hændelser. Holdene dokumenterer modellen og glemmer planen for runtime-bevis. Par dokumentationen med den faktiske logningskonfiguration, så de to er enige.

Hvis du allerede kører GenAI-overvågning, kan du tilknytte spans og begivenheder til spørgsmål, som en post-markeds-gennemgang vil stille: hvilken indtastningsklasse, hvilken modelversion, hvilken beslutningspolitik, hvilken menneskelig handling. OpenTelemetris GenAI-konventioner er en praktisk ingeniørreference for navngivning af disse felter konsistent på tværs af tjenester (OpenTelemetry — GenAI-overvågning). Loven kræver ikke OTel; konsistente spor gør det bare lettere at forsvare krav i artikel 12.

Tema | Artikel/bilag-hængsel | Almindelig fejl | Bevis, der lander Generel beskrivelse og formål | Art. 11 / Bilag IV | Markedsføringspitch i stedet for ønsket formål | Formålsudtalelse + brug uden for området Datastyring | Art. 10 | "Dataset gennemgået" uden sammenfatning | Dataset-inventar + bias-eksam-noter Risikostyring | Art. 9 | Statiske risiko-PDF fra sidste år | Levende register med ejere og resterende risiko Logning | Art. 12 | Logninger påstået, men bevarelse < 6 måneder | Skema + bevarelse-konfiguration-screenshot/eksport Menneskelig overvågning | Art. 14 | Slogan uden omgåelsesvej | UI/runbook + rollematrix Post-markeds-/hændelser | Art. 72 | Ingen alvorlig-hændelses-playbook | Udløser-definitioner + rapporteringskontakter

Almindelige fejl, vi ser i dokumentationspakker

- Skrivning til brochuren, ikke bilagen. Pæne diagrammer, der aldrig citerer bilag IV-temaer, spilder gennemgangstid. - Kopiering af en US RMF-ark og omdøbning af det til "AI Act-pakke." NIST's AI-risikostyringsramme (NIST AI RMF) er nyttig til procesvokabular, men det er ikke en erstatning for artikel 11 / bilag IV-indhold. - Dokumentation af yesterdays model. Produktionen er allerede flyttet; pakken gjorde det ikke. - Lad deployer-instruktioner stå tomme. Artikel 13-transparens til deployere er let at springe over, når provider-teamet kun taler med sig selv. - At kalde en checkliste "certificeret." Den sprogbrug overdrager. Checklister reducerer udeladelsesrisiko; de certificerer ikke overensstemmelse.

Beslutningskriterier: sende pakken vs. fortsætte med udarbejdelse

Behandle pakken som en blokerende udgivelse til en højrisiko-lancering, når en af følgende betingelser er opfyldt:

- Ingen dataset-sammenfatning, som en tredjepart kan følge - Ingen beskrevet menneskelig tilsynsmekanisme knyttet til en reel kontrol - Logopbevaring under seks måneder eller logfiler, der ikke kan genskabe en beslutning - Risikoregister med ingen ejere af restrisiko - Tilsigtet formål så vagt, at Annex III-mapping er umulig

Du kan stadig sende interne prototyper, der aldrig berører EU's højrisiko-brug. Vær ærlig om omfanget i skriftlig form. Tvetydig "vi overholder ånden"-sprog er værre end en tydelig "endnu ikke højrisiko / endnu ikke på EU-markedet"-status.

Hvad dette ikke er

Denne side er ikke juridisk rådgivning, ikke en vurdering fra en underrettet myndighed, og ikke en garanti for, at dit system overholder forordning (EU) 2024/1689. VendorVet gør ikke krav på 100% dækning, opfinder ikke kundevindingsrater, og erstatter ikke rådgivere eller en konformitetsvurdering, hvor en sådan er påkrævet. En checkliste hjælper dig med at samle og verificere temaer; den bindende pligt forbliver den dokumentation, der er beskrevet i artikel 11 og bilag IV, ejet af kvalificerede personer i din organisation.

Afslutning

Start med teksten fra Den Officielle Journal, tilknyt temaer fra Bilag IV til ejere, og udfyld derefter de tre huller, som revisorer åbner først: data, tilsyn og logging. Hold pakken versioneret med systemet. Når modellen eller datasættet ændres, flyttes dokumentationen i samme udgivelsesrække. For beslutningen om risikoniveau, der ligger opstrøms fra alt dette, læs vores søstervejledning om EU AI Act-risikoniveauer.

Referencer

- Forordning (EU) 2024/1689 (EUR-Lex) - Den Europæiske Kommission — AI-akt - EU AI-akt — Implementeringstidsplan - NIST AI-risikostyringsramme - EDPB — GDPR-retningslinjer og bedste praksis - OpenTelemetry — GenAI-overvågning

Relaterede artikler

- EU AI Act risikoniveauer: en praktisk introduktion (2026) - Udforsk det fulde AI mikro-SaaS emne matrix →