Artikler · Drift og governance · 8 min. læsning
Hvad skal I dokumentere, når I bygger jeres egen AI-løsning?
Hvis personen, der byggede jeres AI-løsning, stoppede i morgen, kunne en anden så overtage den? De fleste kender svaret, men det er sjældent noget, nogen har sagt højt.
Af Martin Egesø · Udgivet
Kort svar
I en AI-løsning er det værd at dokumentere det, en anden skal bruge for at overtage, rette og forklare den: formål, ejer, model og leverandør, data, input og output, integrationer, adgang, instruktioner, logging, begrænsninger, tests, risici, beslutninger, ændringer, hændelser og review. Det meste er god drift og god governance. Kun få dele er lovkrav, og de afhænger af, om løsningen bruger persondata eller er højrisiko.
I artiklen 9 afsnit
- Kunne en anden overtage løsningen?
- Hvad sker der, hvis I ikke dokumenterer?
- Hvad er værd at dokumentere?
- Hvad er god drift, god governance og lovkrav?
- Hvor meget skal I skrive?
- Før og efter: overdragelsen af en AI-assistent
- Hvor skal dokumentationen bo og holdes opdateret?
- Hvad kan I gøre nu?
- Ofte stillede spørgsmål
Det vigtigste
- Spørgsmålet er forretningsmæssigt: Kan en anden overtage løsningen, hvis den, der byggede den, stopper?
- Dokumentér det, en anden skal bruge for at forstå, finde, fejlfinde, ændre og forklare løsningen.
- Skeln mellem god drift, god governance og de få dele, der kan være lovkrav.
- For en lille intern løsning kan én side række. Jo vigtigere løsning, jo mere skal skrives.
- Dokumentationen skal have et fast sted at bo og en ejer, der holder den opdateret.
Kunne en anden overtage løsningen?
Dokumentation er ikke et mål i sig selv. Den skal gøre det muligt for en anden at overtage løsningen. Overtagelsestesten er min egen måde at måle det på, ikke en standard. En kollega skal kunne besvare fem spørgsmål ud fra dokumentationen alene:
- Forstå: Hvad gør løsningen, og hvorfor findes den?
- Finde: Hvilke data, modeller, adgange og forbindelser bruger den?
- Fejlfinde: Hvad gør jeg, når noget går galt?
- Ændre: Hvordan retter jeg uden at ødelægge noget?
- Forklare: Hvorfor blev den, som den er?
Svarer I nej til ét af dem, er der noget at skrive ned. Det er netop her, en go-live-tjek ofte stopper: Dokumentation er ét punkt på listen. Her tager vi den fulde liste.
Hvad sker der, hvis I ikke dokumenterer?
Uden dokumentation vokser fem problemer langsomt, til nogen har brug for løsningen i en fart:
- Personafhængighed. Viden om løsningen sidder i hovedet på én person. Er vedkommende væk, er løsningen uden ejer.
- Svært at fejlfinde. Når svarene bliver mærkelige, ved ingen, hvilke data, instruktioner eller model der ligger bagved.
- Svært at ændre. Hver rettelse er en risiko, fordi ingen ved, hvad der hænger sammen.
- Ukendt beslutningshistorik. I kan ikke se, hvorfor løsningen blev bygget sådan, eller hvem der besluttede det.
- Dårlig overdragelse. Den næste skal gætte sig til, hvordan det virker, eller starte forfra.
Det er driftsproblemer og ikke juridiske trusler. De koster tid, penge og tillid, især den dag, nogen skal bruge løsningen i en fart.
Hvad er værd at dokumentere?
Der er 17 punkter, som er værd at dokumentere. De er grupperet efter overtagelsestestens spørgsmål. Kolonnen "Type" viser, hvad punktet primært er: god drift, god governance eller noget, der kan være lovkrav. Skellet forklarer jeg i næste afsnit.
Forstå: hvad og hvorfor
| Punkt | Hvad I skriver ned | Type |
|---|---|---|
| Formål | Hvilket problem løser den, og hvad bruges den ikke til? | Drift |
| Ejer | Navngiven person og stedfortræder | Drift og governance |
| Begrænsninger | Hvad den ikke kan, og hvilke fejl der er kendt | Drift |
Finde: hvad den bruger
| Punkt | Hvad I skriver ned | Type |
|---|---|---|
| Model og leverandør | Model, version, leverandør og aftale | Drift og governance |
| Datakilder | Hvor data kommer fra, og om der indgår persondata | Drift. Kan være lovkrav ved persondata |
| Input | Hvad løsningen modtager, med eksempler | Drift |
| Output | Hvad den leverer, og hvem der bruger det | Drift |
| Integrationer | Forbindelser til andre systemer og hvem der ejer dem | Drift |
| Adgang | Hvem og hvad har adgang til hvad | Drift og governance |
Fejlfinde og ændre: hvordan det holdes i gang
| Punkt | Hvad I skriver ned | Type |
|---|---|---|
| Prompts og instruktioner, hvis de bruges | De faste instruktioner til modellen med version og dato | Drift |
| Logging | Hvad der logges, hvor længe, og hvem der kan se det | Drift. Kan være lovkrav ved højrisiko |
| Tests | Hvad der er testet, med hvilke eksempler og resultater | Drift |
| Ændringer | Hvad der er ændret, hvornår og af hvem. Se hvornår I bør vurdere et AI-værktøj igen | Drift og governance |
| Hændelser | Hvad der skete, effekten og hvad I gjorde. Se hvad I gør, når AI laver en fejl | Governance. Kan være lovkrav ved brud |
Forklare: hvorfor den blev, som den er
| Punkt | Hvad I skriver ned | Type |
|---|---|---|
| Risici | Kendte risici og hvordan de håndteres | Governance |
| Beslutninger | Hvad der blev besluttet, af hvem, hvornår og hvorfor | Governance |
| Review | Dato for næste gennemgang, ansvarlig og seneste resultat | Governance |
Hvad er god drift, god governance og lovkrav?
Ikke alt, der er værd at dokumentere, er et lovkrav. Skeln mellem tre slags grunde:
| Grund | Spørgsmålet | Hvem spørger |
|---|---|---|
| God drift | Kan løsningen rettes, ændres og overdrages? | Ejeren og de kolleger, der skal overtage |
| God governance | Kan vi forklare, hvem der besluttede hvad, og hvornår det sidst blev vurderet? | Ledelsen, kunder og samarbejdspartnere |
| Lovkrav, hvis det gælder | Kræver en regel, at det skrives ned? | Datatilsynet eller en tilsynsmyndighed |
Det meste af listen er god drift og god governance. Lovkrav gælder kun nogle punkter, og kun i bestemte situationer. Her er det, jeg har kunnet verificere, set den 3. oktober 2026:
- Fortegnelse over behandlinger. En dataansvarlig skal føre en fortegnelse over behandlinger af persondata. Pligten gælder som udgangspunkt ikke virksomheder med under 250 ansatte, medmindre behandlingen sandsynligvis udgør en risiko for de registreredes rettigheder, ikke er lejlighedsvis eller omfatter særlige kategorier af oplysninger eller oplysninger om straffedomme (GDPR, artikel 30).
- Dokumentation af brud. Brud på persondatasikkerheden skal dokumenteres med de faktiske forhold, virkningerne og de trufne afhjælpende foranstaltninger (GDPR, artikel 33, stk. 5). Se også ChatGPT og GDPR.
- Højrisiko-AI. For højrisiko-AI-systemer skal udbydere udarbejde teknisk dokumentation, før systemet bringes i omsætning eller ibrugtages, og systemerne skal teknisk kunne registrere logfiler (AI-forordningen, artikel 11 og 12). Idriftsættere skal opbevare logfiler i mindst seks måneder, medmindre anden ret gælder (artikel 26, stk. 6).
Højrisiko-reglerne gælder kun, hvis jeres løsning er højrisiko. Læs hvornår AI er højrisiko og tidslinjen for AI-forordningen for datoerne. Om et konkret krav gælder jer, er en juridisk vurdering, og jeg er ikke jurist.
Hvor meget skal I skrive?
Skriv så meget, at en anden kan overtage løsningen. Mere er spild, og mindre er en risiko. Min anbefaling, ikke et krav:
| Løsningen | Rimeligt niveau |
|---|---|
| Lille intern hjælper med få brugere | Én side, der svarer på overtagelsestestens fem spørgsmål |
| Bruges dagligt af mange eller sender noget til kunder | Alle 17 punkter, kort og opdateret |
| Bruger persondata eller vurderer mennesker | Alle 17 punkter og en juridisk vurdering af, hvilke krav der gælder |
Opdatér dokumentationen, hver gang løsningen ændres. Dokumentation, der er et år gammel, er værre end ingen, fordi nogen stoler på den.
Før og efter: overdragelsen af en AI-assistent
Et tænkt eksempel
En medarbejder byggede en AI-assistent, der foreslår svar på kundemails. Nu går vedkommende på orlov i seks måneder. Tabellen viser, hvad kollegaen står med uden og med dokumentation.
| Område | Uden dokumentation | Med dokumentation |
|---|---|---|
| Instruktioner | Ligger i byggerens notesblok | Gemt med version og dato |
| Data | Ingen ved, hvor de kommer fra | Datakilder er listet |
| Fejl | Man gætter og prøver sig frem | Kendte fejl og logning er beskrevet |
| Beslutninger | "Det besluttede vi på et møde" | Beslutning, dato og begrundelse er noteret |
| Ejer | Ingen | Navngiven ejer og stedfortræder |
| Review | Ingen | Dato for næste gennemgang |
Hvor skal dokumentationen bo og holdes opdateret?
Dokumentation havner let i mails, Teams, kode og hukommelse. Så bliver den forældet, og ingen ved, hvilken version der gælder. Den, der skal overtage løsningen, eller en kunde, der spørger, må lede.
Tekniske detaljer, som kode og instruktioner, kan blive, hvor de naturligt hører hjemme. Men det, der skal kunne findes igen, bør have ét fast sted: ejer, formål, data, aftaler, beslutninger, vurderinger, hændelser og review. Det er den del, SPOR er bygget til. Ud fra det, SPOR-siden beskriver, samler SPOR:
- et register over systemer og AI-værktøjer med formål, ansvarlig, pris og aftaler
- løsninger fra behov til drift, hvor beslutninger og dokumentation følger det, der bygges
- risiko pr. system og dataflowet vist som diagram
- hændelser, som registreres
- opgaver med ansvarlig og frist, så review ikke bliver glemt
SPOR skriver ikke dokumentationen for jer, logger ikke selve løsningen og er hverken certificering eller garanti for, at alle krav er opfyldt. Når jeg bygger en løsning, kan SPOR være dokumentationslaget omkring den, så den kan overdrages. Se SPOR og det enkle setup for AI governance. Et overblik over alle jeres AI-anvendelser får I med samme tilgang. Hvad registret skal indeholde, står i hvad et AI-register skal indeholde.
Hvad kan I gøre nu?
Gør dette i denne uge for den vigtigste AI-løsning, I har bygget:
- Spørg jer selv: Kunne en anden overtage den i morgen?
- Skriv de fem spørgsmål fra overtagelsestesten ned, og besvar dem på én side.
- Gå de 17 punkter igennem, og markér, hvad der mangler.
- Navngiv en ejer og en stedfortræder, og sæt en dato for næste review.
Kort sagt: Hvis systemet er vigtigt nok til at bruge, er det også vigtigt nok til at kunne overdrages. Er I i tvivl om, hvad der mangler, så send systemet, så kigger vi på det sammen. Bygger I en ny løsning, er artiklen om skræddersyet software et godt sted at starte, og hvornår en integration giver mening hjælper, hvis den kobler systemer sammen.
Næste skridt: Bevar overblikket, når løsningen er gået i drift. Læs Ny software er ikke færdig ved go-live: sådan bevarer I overblikket bagefter.
Ofte stillede spørgsmål
Skal prompts og instruktioner dokumenteres?
Ja, hvis løsningen bruger faste instruktioner til en AI-model. De styrer, hvordan løsningen svarer, så de bør gemmes med version, dato og begrundelse for ændringer. Det er god drift. Er løsningen højrisiko, gælder der særlige krav til dokumentation, som artiklen beskriver.
Kræver AI-forordningen, at man dokumenterer sin egen AI-løsning?
Kun for højrisiko-AI-systemer er der krav om teknisk dokumentation og logning, og kravene er forskellige for udbydere og idriftsættere. Er løsningen ikke højrisiko, stiller forordningen ikke disse krav. Om en løsning er højrisiko, er en vurdering, I kan få juridisk hjælp til.
Hvor lang skal dokumentationen være?
Så lang, at en anden kan overtage løsningen. For en lille intern løsning kan det være én side. Jo vigtigere løsningen er, og jo mere persondata den bruger, jo mere skal I skrive.
Hvem skal holde dokumentationen opdateret?
Løsningens ejer. Gør opdatering til en del af hver ændring, og sæt en dato for næste review, så dokumentationen ikke bliver forældet.
Om forfatteren
Martin Egesø er rådgiver og udvikler. Han hjælper virksomheder med at få mere ud af deres systemer og AI-værktøjer og bygger nye løsninger, når standarden ikke passer, med styr på brug, data og ansvar. Han driver MLE Gruppo ApS i Randers.
Mere om MartinArtiklen er generel vejledning og ikke juridisk rådgivning. Udgivet .