Revisionsspor for AI-agenter: tre danske krav

Hvilke tre krav taler vi om?

Krav	Hvad det dækker	Grundlag og opbevaring
Logning af anvendelser af personoplysninger	Alle anvendelser foretaget af brugere, herunder læsning, tilføjelse, søgning, ændring, udtræk og sletning.	GDPR art. 32 og art. 25. Aktiveres senest ved idriftsættelsen af it-systemet. Opbevaringstid efter formålet, afvejet mod dataminimeringsprincippet.
Transaktionsspor	Sammenhængen mellem de enkelte bogførte registreringer og virksomhedens årsregnskab.	Bogføringsloven. Fem år fra udgangen af det regnskabsår, materialet vedrører.
Kontrolspor	De oplysninger, der dokumenterer registreringernes rigtighed.	Bogføringsloven. Fem år fra udgangen af det regnskabsår, materialet vedrører.

Sondringen er ikke akademisk. Transaktionssporet besvarer «hvor i årsregnskabet endte denne postering». Kontrolsporet besvarer «hvorfor er posteringen korrekt». Datatilsynets logning besvarer «hvem har rørt ved personoplysningerne». Et system kan opfylde det første fuldt ud og de to andre slet ikke — hvilket typisk sker, når en integration skriver en postering med en pæn reference til et kildesystem, men uden noget der dokumenterer, hvad der udløste den.

Første skridt er derfor banalt og bliver alligevel sjældent taget: afklar, hvilket af de tre krav jeres dokumentation faktisk opfylder — hver for sig, ikke under ét.

Hvorfor duer applikationslogs ikke?

De duer ikke til nogen af de tre. Tre grunde, uafhængigt af hvor grundigt der logges.

De roterer. Typisk efter dage eller uger. Bogføringslovens målestok er fem år fra udgangen af det regnskabsår, materialet vedrører. Dokumentation, der findes i 30 dage, findes reelt ikke, når den efterspørges.

De kan ændres. Et spor, der kan redigeres af de samme personer, som driver systemet, dokumenterer ikke rigtighed. Bogføringsloven angriber samme problem fra den anden side: bogførte transaktioner må ikke kunne ændres, tilbagedateres eller slettes, og rettelser sker ved nye posteringer.

Deres fuldstændighed er en driftsindstilling. Logniveauet justeres i produktion for at spare plads eller dæmpe støj, som regel uden formel procedure. Datatilsynets krav går den modsatte vej: logningen skal være aktiveret senest ved idriftsættelsen og dækker alle anvendelser — også læsning og søgning, som normalt er det første, der skrues ned.

Hvornår skal sporet skrives?

Før handlingen, ikke efter svaret. Det er den enkeltbeslutning, der oftest afgør, om sporet er brugbart.

Et spor, der skrives ved et vellykket svar, indeholder pr. konstruktion kun de handlinger, der lykkedes. Kald, der løb ind i timeout, forsøg der blev afvist undervejs, og handlinger, der blev gennemført i modtagersystemet uden at svaret nåede tilbage, efterlader ingenting. Efter en hændelse er det præcis dem, spørgsmålene handler om: hvor mange gange blev der forsøgt, hvad nåede igennem, og hvad står der to steder nu.

Rækkefølgen har en praktisk følgevirkning. Skriver man sporet først, skal handlingen have et varigt operations-id, før den udføres — og dermed har man også idempotenskontrollen, der forhindrer, at et gentaget forsøg efter timeout skaber en dubletpostering.

Hvad kræver en AI-agent, som en almindelig proces ikke gør?

To felter. Begrundelsen er mekanisk, ikke forsigtighed.

En deterministisk proces revideres ved at køre koden igen med samme input. Det kan man ikke med en agent. Samme prompt på samme model kan give et andet resultat, og modellen kan være skiftet ud siden. En gentagelse producerer en ny beslutning, ikke en forklaring på den gamle. Derfor skal beslutningsgrundlaget gemmes på handlingstidspunktet — det kan ikke genskabes bagefter.

De inputdata, beslutningen hvilede på

Ikke en henvisning til, hvor data lå, men indholdet som det så ud, da agenten læste det. En henvisning til en post, der siden er opdateret, dokumenterer ikke beslutningen; den dokumenterer en anden virkelighed end den, agenten handlede i.

Den model- og konfigurationsversion, der var i kraft

Modelversion, politikversion, prompt- eller instruktionsversion og de tærskler, der var sat. Uden dem kan man konstatere, at agenten traf en beslutning, men ikke afgøre, om den var i overensstemmelse med det, ledelsen godkendte.

Og hvad så med «initialer for bruger eller program»?

Bogføringsloven kræver, at hver postering får et fortløbende transaktionsnummer, en registreringsdato og initialer for bruger eller program. Ved manuel bogføring identificerer det sidste felt en person. Ved automatisering i skala identificerer det som regel én delt servicebruger, som fem forskellige processer bogfører under — teknisk set i overensstemmelse med kravet, ubrugeligt ved en kontrol.

Identifikationen skal være finere end kontoen: den konkrete proces, det konkrete kørselsid og — når en agent er involveret — model- og konfigurationsversionen. Så bærer det felt, loven allerede kræver, den information, der faktisk bliver spurgt om.

Hvorfor er 24-timers fristen den reelle test?

NIS 2-loven, LOV nr 434 af 06/05/2025, trådte i kraft 1. juli 2025. Efter § 13 skal der sendes tidlig varsling senest 24 timer, hændelsesunderretning inden for 72 timer og endelig rapport senest 1 måned efter hændelsesunderretningen.

24 timer er ikke lang tid til at fastslå, hvad der er sket. Har autonome processer udført en række handlinger, og kan I ikke inden for det første døgn afgøre, hvilke af dem der var autoriserede, går den tidlige varsling ud på et usikkert grundlag. Hastigheden, hvormed I kan rekonstruere et forløb, bestemmer altså kvaliteten af indberetningen.

Og det er ikke alene et driftsanliggende. Efter § 7 skal ledelsesorganet godkende foranstaltningerne, føre tilsyn med gennemførelsen og deltage i kurser. Sanktionerne i § 32 omfatter bøde og strafansvar for juridiske personer efter straffelovens kapitel 5 — og over for væsentlige enheder kan tilsynsmyndigheden midlertidigt forbyde en person at varetage ledelsesfunktioner. Tilsynet er sektorbaseret under Styrelsen for Samfundssikkerhed under Ministeriet for Samfundssikkerhed og Beredskab. Rekonstruktionsevnen er dermed ledelsens problem personligt.

Hvordan tester du, om sporet findes?

Tag en tilfældig handling, som en agent udførte for mindst tre måneder siden. Rekonstruér fem ting: hvad udløste den, hvilke inputdata den hvilede på, hvilken model- og politikversion der var i kraft, hvem der godkendte og hvad vedkommende fik at se, og hvad udfaldet blev. Uden at bruge applikationslogs, og uden at spørge en udvikler.

Resultat	Fortolkning
Under fem minutter, fra ét sted	Sporet virker.
Kræver en udvikler	Sporet findes ikke. Det, der findes, er en rekonstruktionsevne hos en person — og den er hverken dokumentation eller tilgængelig kl. 3 om natten.
Kan ikke fastslå tidligere mislykkede forsøg	Det almindeligste resultat. Sporet skrives efter svaret, ikke før handlingen.

Hvad med AI-forordningen?

Der er et hul i den danske gennemførelse lige nu. LOV nr 467 af 14/05/2025, i kraft 2. august 2025, udpeger Digitaliseringsstyrelsen, Datatilsynet og Domstolsstyrelsen — men alene for de forbudte former for AI-praksis efter artikel 5. Rammelovforslaget L 111 blev fremsat 18. februar 2026, nåede førstebehandling 17. marts 2026 og bortfaldt ved folketingsvalget 24. marts 2026. Pr. 2. september 2026 var det ikke genfremsat. Efterprøv det på ft.dk — det kan have ændret sig.

Digital omnibus-forordningen, forordning (EU) 2026/1744, trådte i kraft 27. juli 2026 og udskød højrisikoforpligtelserne: bilag III-systemer til 2. december 2027, indlejrede bilag I-systemer til 2. august 2028. Transparenskravene blev ikke udskudt — de gælder fra 2. august 2026. Udskydelsen er altså ingen grund til at udskyde sporet: de danske krav, artiklen handler om, gælder allerede.

Tjekliste

Afklar, hvilket af de tre krav jeres dokumentation opfylder — hver for sig.
Flyt skrivningen af sporet til før handlingen udføres, og registrér også de mislykkede og afviste forsøg.
Tildel et varigt operations-id før første forsøg, og brug det til idempotenskontrol.
Gem inputdata som de så ud på beslutningstidspunktet — ikke en henvisning.
Gem model-, politik- og konfigurationsversion sammen med hver agenthandling.
Erstat den delte servicebruger i «initialer for bruger eller program» med den konkrete proces.
Adskil opbevaringspolitikken: fem år for bogføringsmaterialet, formålsbestemt for logningen af personoplysninger.
Kør rekonstruktionstesten på en handling, der er mindst tre måneder gammel.

Ofte stillede spørgsmål

Hvad kræver Datatilsynet logget?

Alle anvendelser af personoplysninger foretaget af brugere, herunder læsning, tilføjelse, søgning, ændring, udtræk og sletning. Logningen skal være aktiveret senest ved idriftsættelsen af it-systemet. Opbevaringstiden fastsættes efter formålet og afvejes mod dataminimeringsprincippet. Grundlaget er GDPR art. 32 og art. 25.

Er transaktionsspor og kontrolspor det samme som et revisionsspor?

Nej. Transaktionsspor er sammenhængen mellem registreringerne og årsregnskabet. Kontrolspor er de oplysninger, der dokumenterer registreringernes rigtighed. Begge kaldes «audit trail» på engelsk.

Opfylder applikationslogs kravet til et revisionsspor?

Sjældent. De roterer efter dage eller uger, de kan ændres, og deres fuldstændighed afhænger af et logniveau, der justeres i drift uden formel procedure.

Hvorfor skal sporet skrives før handlingen og ikke efter?

Fordi et spor, der skrives ved et vellykket svar, ikke indeholder de forsøg, der aldrig kom retur. Det er dem, der bliver spurgt til efter en hændelse.

Hvilke felter skal registreres for en AI-agent, som ikke kræves for en almindelig proces?

De inputdata, beslutningen hvilede på, og den model- og konfigurationsversion, der var i kraft. En agent kan ikke revideres ved at køre den igen — en gentagelse giver en ny beslutning, ikke en forklaring på den gamle.

Relaterede artikler

BarzelVault skriver sporet før handlingen udføres, registrerer også de forsøg, der aldrig kom retur, og gemmer inputdata, model- og politikversion sammen med hver enkelt agenthandling — så rekonstruktionen kan gøres fra ét sted uden at involvere en udvikler.

I praksis

Tilladelse før handlingen. Bevis bagefter.

Forpligtelserne på denne side knytter sig til det øjeblik, et automatiseret system handler: hvem tillod det, på hvilke data, under hvilken politikversion, og hvad et menneske så, før der blev godkendt. Barzel håndhæver den beslutning før udførelsen og skriver den registrering, som en revisor, en tilsynsmyndighed eller en registreret kan få forevist.

430 dage tilbageAI-forordningen: højrisikoforpligtelser (bilag III) gælder fra 2. december 2027

BarzelVault

Firewallen for AI-handlinger: afgør, hvad en agent må gøre, før den gør det.

Godkendelsestærskler og politikkontroller håndhævet før udførelse; menneskelige godkendelser med udløb og eskalering.
Kryptografisk signerede revisionskvitteringer: udløser, input, politikversion, godkender, resultat.
Isolerede legitimationsoplysninger, forbrugs- og handlingsgrænser samt nødstop.

Gratis: 10.000 kald om månedenBetalte planer fra 199 USD om månedenTilgængelig på MCPize

Start gratis Spørg pr. e-mail Produktside Dokumentation

Barzel Central Gateway

Kontrolplanet for AI-governance: ét inventar og ét politiklag på tværs af alle MCP-servere og agenter.

Registrerer og synkroniserer hvert værktøj; håndhæver identitet, politik, region, omkostning og tilstand pr. værktøj.
Identitetsmapning via OIDC, Entra ID, Okta, SAML og SPIFFE, med credential brokerage.
Trace- og SIEM-eksport (W3C Trace Context, OTLP) til sikkerhedsteamet og tilsynet.

Gratis: 1.000 kald om månedenBetalte planer fra 10 USD om månedenTilgængelig på MCPize