NISTs nye AI-dokumentation: Fra modelkort til levende praksis

Problemet er sjældent, at der slet ikke findes et dokument

Mange organisationer har allerede spor af AI-dokumentation. Der ligger et leverandørnotat i indkøb, en risikovurdering hos jura, en testfil hos produktteamet og et par beslutninger i et møde­referat. Problemet er, at ingen enkelt del giver et samlet og brugbart svar på, hvad systemet er, hvad det må bruges til, og hvor det går galt.

NIST – det amerikanske National Institute of Standards and Technology – forsøger nu at skabe et mere fælles sprog. 2026-07-29 offentliggjorde instituttet et første offentligt udkast med vejledning og skabeloner til dokumentation af AI-modeller og datasæt. Høringsfristen er 2026-09-16.

Timingen gør udkastet aktuelt, men det bør læses med den rigtige etikette: »initial public draft«. Det er ikke en vedtaget standard, ikke en certificering og ikke et facit for EU-ret. NISTs plan er, at gennemarbejdede nuludkast senere kan sendes ind i den almindelige, konsensusbaserede standardisering, hvor indholdet kan ændre sig.

Hvad forsøger NIST at standardisere?

Udkastets konkrete fokus er offentlig dokumentation af AI-modeller og AI-datasæt. Det vil sige materiale, som hjælper andre aktører med at forstå egenskaber, anvendelse og begrænsninger. Det kan være modelkort, datakort eller tilsvarende dokumentationsartefakter i web-, PDF- eller maskinlæsbar form.

NIST skelner vigtigt mellem en dokumentationsartefakt og dokumentationsprocessen. Artefakten er det synlige produkt. Processen er de aktiviteter, beslutninger og roller, der skaber og vedligeholder det. Et pænt modelkort kan derfor stadig være svagt, hvis ingen ved, hvem der opdaterer det, eller hvis det beskriver en gammel modelversion.

Omvendt behøver god dokumentation ikke begynde med 50 felter. Den kan begynde med en ærlig, kort beskrivelse af systemets formål, data, test og kendte begrænsninger – og vokse i takt med, at brugen og risiciene bliver tydeligere.

De vigtigste felter i menneskesprog

Udkastets bilag er detaljerede. For en almindelig virksomhed kan de oversættes til otte spørgsmål:

1. Identitet: Hvilken model eller hvilket datasæt beskriver vi, fra hvilken leverandør og i hvilken version?
2. Tiltænkt brug: Hvilke opgaver og brugssituationer er løsningen lavet til – og hvilke er den ikke lavet til?
3. Rettigheder og begrænsninger: Hvad må vi bruge, dele, ændre eller videredistribuere?
4. Oprindelse og udvikling: Hvilke datakilder, træningstrin eller væsentlige designvalg er relevante at kende?
5. Evaluering: Hvordan er kvalitet og egnethed testet, af hvem og under hvilke betingelser? NIST anbefaler blandt andet at skelne mellem automatiske, menneskelige og kombinerede evalueringer.
6. Begrænsninger: Hvor falder præstationen, hvilke grupper eller situationer er dårligt dækket, og hvor friske er testresultaterne?
7. Risici og påvirkninger: Hvilke kendte sårbarheder og negative konsekvenser findes, hvilke tiltag er taget, og hvilke rest­risici er tilbage?
8. Vedligeholdelse: Hvem overvåger systemet efter lancering, hvordan opdages ændringer, og hvornår udfases en version?

Dokumentation skal begynde før lanceringen

En af udkastets mest praktiske anbefalinger er at undgå at vente, til modellen eller datasættet næsten er færdigt. Planlagte datakilder og indsamlingsprocesser kan dokumenteres allerede i designfasen. Senere kan materialet udbygges med faktiske testresultater, hændelser og erfaringer fra drift.

Det ændrer dokumentation fra oprydning til arbejdsredskab. Når teamet tidligt skal formulere en tiltænkt brug, opdager det ofte, at »hjælpe kundeservice« er for upræcist. Skal systemet finde artikler, foreslå svar, prioritere sager eller træffe afgørelser? De fire opgaver kræver forskellig test og menneskelig kontrol.

På samme måde kan et felt om begrænsninger afsløre, at ingen endnu har prøvet svære danske fagudtryk, vrede kunder eller dokumenter med dårlig scanning. Dokumentationen skaber ikke evidensen, men den gør hullet synligt, før hullet bliver til et produktløfte.

Mere er ikke altid mere gennemsigtigt

NIST advarer også mod at fylde alt i et offentligt dokument. Oplysningerne skal være relevante for målgruppen og egnede til offentliggørelse. Personoplysninger, forretningshemmeligheder, ulovligt materiale og detaljer, der gør misbrug lettere, kan kræve udeladelse eller en mere overordnet beskrivelse.

Det afgørende er derfor ikke maksimal længde, men brugbar gennemsigtighed. En indkøber har brug for andre detaljer end en modeludvikler. En borger har brug for andre forklaringer end et internt sikkerhedsteam. NIST peger på, at både menneskeligt læsbare og maskinlæsbare formater kan være relevante, men at hvert format bør tilpasses sin funktion.

En stærk offentlig version kan derfor suppleres af en mere detaljeret intern version. De to bør have samme identitet og versionsdato, så man kan se, at de beskriver den samme løsning.

En enkel skabelon til jeres næste AI-system

Hvis I ikke udvikler grundmodeller, kan I stadig bruge principperne. Lav et systemkort på to til fire sider med følgende faste felter:

• Navn, ejer, leverandør, modelversion og seneste opdatering.
• Konkret opgave, målgruppe og forbudte anvendelser.
• Datakilder, adgang og opbevaring på et passende niveau.
• Tre til fem vigtigste kvalitetsmål og seneste testresultat.
• Kendte fejlmønstre og grupper eller situationer med usikker dækning.
• Menneskelig kontrol, eskalation og mulighed for at tilsidesætte output.
• Hændelser siden sidste version og ændringer, der er foretaget.
• Dato og ansvarlig for næste gennemgang.

Tilføj kun felter, der ændrer en beslutning. Hvis ingen bruger dokumentet til at godkende, købe, overvåge eller forbedre systemet, er det sandsynligvis enten for uklart eller placeret det forkerte sted.

Giv dokumentationen en rigtig ejer

Udkastet bruger betegnelsen »documentarian« om den person, der koordinerer dokumentationsprocessen og frigivelsen af materialet. Det behøver ikke være en fuldtidsrolle. Pointen er, at nogen skal samle bidrag fra produkt, data, sikkerhed, jura og drift og holde styr på versionen.

Ejeren bør ikke alene skrive alt. Produktejeren beskriver formål og ændringer. Fagfolk definerer realistiske opgaver. Sikkerhed og databeskyttelse beskriver kontroller og begrænsninger. Testansvarlige leverer evidens. Ledelsen accepterer eventuelle rest­risici. Dokumentation er stærkest, når ansvaret følger de faktiske beslutninger.

Start med ét system, som allerede har betydning for kunder eller medarbejdere. Udfyld den korte skabelon, markér ukendte felter åbent, og brug næste driftsmøde til at fordele hullerne. Det er mere værdifuldt end at vente på den perfekte standard.

Det aktuelle udkast er en invitation – ikke en facitliste

NIST modtager input til og med 2026-09-16, og indsendte bidrag bliver en del af det offentlige materiale. Organisationer med konkret erfaring kan derfor pege på felter, der mangler, er uklare eller er urealistiske i drift.

For alle andre er nyheden en anledning til at se på egen praksis. Hvis jeres AI-dokumentation kun fortæller, hvad systemet kan på en god dag, mangler den sandsynligvis det vigtigste. Et menneskecentreret systemkort beskriver også, hvem der kan blive ramt af fejl, hvem der opdager dem, og hvordan løsningen bliver ændret eller stoppet.

Læs også

• Sådan vurderer I en AI-leverandør
• Fra AI-idé til drift – sådan tester I løsningen

Kilder og videre læsning

Kilderne er kontrolleret den 2026-09-03. Artiklen bygger på de primære kilder nedenfor; de er ikke en erstatning for konkret juridisk rådgivning.

• NIST: AI Standards – offentliggørelse og høringsfrist
• NIST: Zero Drafts Pilot Project
• NIST: Guidance and Templates for Public-Facing AI Documentation, initial public draft
• NIST: AI Risk Management Framework