Which three requirements are we talking about?
| Requirement | What it covers | Basis and retention |
|---|---|---|
| Logging of uses of personal data logning af anvendelser af personoplysninger |
All uses by users, including reading, adding, searching, changing, extracting and deleting. | GDPR Articles 32 and 25. Activated no later than when the IT system is put into operation. Retention set by purpose, weighed against data minimisation. |
| Transaktionsspor transaction trail |
The connection between the individual posted entries and the company's annual accounts. | Bogføringsloven. Five years from the end of the financial year the material relates to. |
| Kontrolspor control trail |
The information that documents the correctness of the entries. | Bogføringsloven. Five years from the end of the financial year the material relates to. |
The distinction is not academic. The transaktionsspor answers where in the annual accounts did this entry end up. The kontrolspor answers why is the entry correct. Datatilsynet's logging answers who touched the personal data. A system can satisfy the first completely and the other two not at all — which is what typically happens when an integration posts an entry with a tidy reference to a source system, but with nothing documenting what triggered it.
The first step is banal and still rarely taken: establish which of the three your documentation satisfies, one at a time.
Why does the English phrase cause the problem?
Because English has one word where Danish has three, and the collapse loses information. The Danish umbrella term is revisionsspor, which itself translates as audit trail — but the two statutory terms underneath it, transaktionsspor and kontrolspor, are distinct requirements with distinct content, and Danish auditors ask about them separately.
This matters more to a group than to a domestic Danish company, for three reasons.
Vendor claims stop being checkable. A product datasheet that says full audit trail is not answering the Danish question. Ask which of the three it covers. Most agent and automation platforms produce something close to a control trail for their own actions and nothing at all that links to the annual accounts.
Group control descriptions become untranslatable at the worst moment. If your control narrative, your SOX or internal-control documentation and your ISAE report all say audit trail, a Danish auditor cannot map them onto the Danish requirement without doing the translation in the room, at your cost, during fieldwork. Write the Danish terms into the control description and the mapping is done in advance.
Scoping decisions get made against the wrong requirement. Satisfying yourself on personal-data logging says nothing about the bookkeeping trails, and the reverse. They are enforced by different authorities and tested by different people.
Why do application logs not qualify?
They satisfy none of the three, for three reasons independent of how thoroughly you log.
They rotate. Typically after days or weeks. The bookkeeping measure is five years from the end of the financial year the material relates to. Documentation that exists for thirty days does not exist by the time it is asked for.
They can be altered. A record that can be edited by the same people who operate the system does not document correctness. The bogføringslov attacks the same problem from the other side: posted transactions must not be capable of being changed, backdated or deleted, and corrections are made by new entries rather than by amending the old ones.
Their completeness is an operational setting. The log level is adjusted in production to save space or reduce noise, usually without a formal procedure. Datatilsynet's requirement runs the opposite way: logging must be activated no later than when the system goes into operation, and it covers all uses — including reading and searching, which are normally the first thing turned down.
When should the trail be written?
Before the action, not on the response. This is the single decision that most often determines whether the trail is usable.
A trail written when a successful response arrives contains, by construction, only the actions that succeeded. Calls that ran into a timeout, attempts that were refused along the way, and actions that completed in the receiving system without the response getting back leave nothing behind. After an incident those are precisely what the questions are about: how many attempts were made, what got through, and what now exists in two places.
The ordering has a useful side effect. If the trail is written first, the action must carry a durable operation identifier before it executes — and that identifier is also the idempotency control that stops a repeated attempt after a timeout from creating a duplicate entry.
What does an AI agent need that an ordinary process does not?
Two fields. The reason is mechanical, not cautious.
A deterministic process is audited by running the code again over the same input. You cannot do that with an agent. The same prompt against the same model may produce a different result, and the model may have been swapped out since. A repeat produces a new decision, not an explanation of the old one. So the basis of the decision has to be stored at the moment of the action — it cannot be recreated afterwards. The general form of this problem is set out under AI agent audit trails; what follows is what Denmark adds to it.
The input data the decision rested on
Not a reference to where the data was, but the content as it looked when the agent read it. A pointer to a record that has since been updated does not document the decision; it documents a different state of the world from the one the agent acted in.
The model and configuration version in force
Model version, policy version, prompt or instruction version, and the thresholds that were set. Without them you can establish that the agent made a decision, but not whether it accorded with what the ledelsesorgan (management body) approved — which is the question the NIS 2-loven § 7 duty turns into at an inspection.
And what about the initials for user or program?
The bogføringslov requires each entry to carry a sequential transaction number, a registration date and initials for the user or program. In manual bookkeeping that last field identifies a person. In automation at scale it usually identifies one shared service account under which five different processes post — technically compliant with the requirement, useless at an inspection.
The identification has to be finer than the account: the specific process, the specific run identifier and, where an agent is involved, the model and configuration version. Then the field the Act already requires carries the information that is actually asked about.
What must a foreign parent's Danish entity do differently?
The statute is the same for a domestic Danish company. The operational problems are not. Four differences are worth designing for.
You cannot run one group retention policy across these requirements. The bookkeeping material runs on a five-year clock from the end of the financial year it relates to. The logging of uses of personal data runs on a purpose-determined clock weighed against data minimisation, which points in the opposite direction — towards deleting sooner. A single group retention setting will satisfy one and breach the other. Separate them in the retention schedule rather than harmonising them, and record why they differ.
The obligation stays with the Danish entity even when the system is run elsewhere. Where the ERP is operated centrally in another country and the integration was built by a group team, the Danish entity still owes the transaktionsspor and the kontrolspor for its own books. Decide explicitly who produces that evidence and how quickly — an intercompany control question before a technical one.
The evidence has to read in both languages. A Danish auditor asks in Danish terms; a group audit committee reads the answer in English. Store the fields structurally — operation identifier, trigger, input snapshot, model and policy version, approver, outcome — so the same record answers both without a translation exercise.
The shared service account problem is specifically a group problem. Centralised operations are what produce one integration user under which many processes post — and a group with a shared service centre hits it in every entity at once.
Why is the 24-hour deadline the real test?
The NIS 2-loven, LOV nr 434 af 06/05/2025, came into force on 1 July 2025. Under § 13 an early warning must be sent within 24 hours, an incident notification within 72 hours and a final report no later than one month after the incident notification.
Twenty-four hours is not long to establish what has happened. If autonomous processes have performed a series of actions and you cannot determine within the first day which of them were authorised, the early warning goes out on an uncertain basis. The speed at which you can reconstruct a sequence therefore sets the quality of the notification — and for a group, the escalation path between a Danish entity and the people who can answer is usually itself several hours long.
And this is not only an operational matter. Under § 7 the ledelsesorgan must approve the measures, supervise their implementation and attend training. The sanctions in § 32 cover fines and criminal liability for legal persons under chapter 5 of the Danish Criminal Code — and in relation to væsentlige enheder (essential entities) the supervisory authority may temporarily prohibit an individual from exercising management functions. Supervision is sector-based, under Styrelsen for Samfundssikkerhed within Ministeriet for Samfundssikkerhed og Beredskab. The ability to reconstruct is therefore the management body's problem personally.
How do you test whether the trail exists?
Take a random action an agent performed at least three months ago. Reconstruct five things: what triggered it, which input data it rested on, which model and policy version were in force, who approved it and what they were shown, and what the outcome was. Without using application logs, and without asking a developer.
| Result | Interpretation |
|---|---|
| Under five minutes, from one place | The trail works. |
| Fifteen minutes across several systems | The data exists but is not a trail. It will not scale to an inspection covering hundreds of actions. |
| Requires a developer | There is no trail. What exists is a reconstruction capability held by a person — which is neither documentation nor available at three in the morning. |
| Cannot establish earlier failed attempts | The most common result. The trail is written after the response, not before the action. |
Run it on one entity per quarter rather than the whole group once: the failure modes differ by ERP instance and by who built the integration.
Does the AI Act change this?
Not in a way that lets you wait. There is a gap in the Danish implementation at present. LOV nr 467 af 14/05/2025, in force 2 August 2025, designates Digitaliseringsstyrelsen, Datatilsynet and Domstolsstyrelsen — but only for the prohibited AI practices under Article 5. The framework bill L 111 was tabled on 18 February 2026, reached first reading on 17 March 2026 and lapsed at the general election of 24 March 2026. As at 3 September 2026 it had not been reintroduced. Check it on ft.dk; the fuller picture is in AI Act supervision in Denmark.
Regulation (EU) 2026/1744, the Digital Omnibus on AI, came into force on 27 July 2026 and deferred the high-risk obligations: Annex III systems to 2 December 2027 and embedded Annex I systems to 2 August 2028. The transparency obligations were not deferred — they have applied since 2 August 2026. So the deferral is no reason to defer the trail: the Danish requirements this article is about apply already, and they are enforced by authorities that exist.
A checklist
- Establish which of the three requirements your documentation satisfies — one at a time.
- Move the writing of the trail to before the action executes, and record the failed and refused attempts too.
- Assign a durable operation identifier before the first attempt, and use it for idempotency.
- Store the input data as it stood at the moment of decision — not a reference to it.
- Store the model, policy and configuration version alongside every agent action.
- Replace the shared service account in initials for user or program with the specific process and run.
- Separate the retention policies: five years for the bookkeeping material, purpose-determined for the personal-data logging.
- Run the reconstruction test on an action at least three months old.
In practice
BarzelVault writes the record before the action executes, so the attempts that never returned are captured too, and stores the input data with the model and policy version against each agent action. That is the part of this set that cannot be reconstructed afterwards.
Frequently asked questions
Are transaktionsspor and kontrolspor the same as an audit trail?
No. Transaktionsspor is the connection between the posted entries and the annual accounts. Kontrolspor is the information documenting the correctness of those entries. English calls both, and Datatilsynet's logging as well, an audit trail — which is how a system comes to satisfy one and fail the others.
What does Datatilsynet require to be logged?
All uses of personal data by users, including reading, adding, searching, changing, extracting and deleting. Logging must be activated no later than when the IT system is put into operation. Retention is set by purpose and weighed against data minimisation. The basis is GDPR Articles 32 and 25.
Do application logs satisfy the requirement?
Rarely, and none of the three cleanly. They rotate after days or weeks, they can be altered, and their completeness depends on a log level that is adjusted in production without a formal procedure.
Why write the trail before the action rather than after?
Because a trail written on a successful response does not contain the attempts that never came back. Those are the ones that get asked about after an incident.
Which fields does an AI agent need that a normal process does not?
The input data the decision rested on, and the model and configuration version in force. An agent cannot be audited by running it again — a repeat gives a new decision, not an explanation of the old one.
Can we run one group retention policy?
Not across these requirements. Five years from the end of the financial year for the bookkeeping material; purpose-determined and weighed against data minimisation for the personal-data logging. One setting will satisfy one and breach the other.
Related reading
- NIS 2-loven § 7: the management body's personal duty
- AI Act supervision in Denmark: who oversees what
- AI agent audit trails — the general case
- Approval checkpoints in automated workflows
- Glossary of Danish and EU terms
- Corrections
In practice
Permission before the action. Evidence after it.
The duties on this page attach to the moment an automated system acts: who permitted it, on which data, under which policy version, and what a person saw before approving. Barzel enforces that decision before execution and writes the record an auditor, a regulator or a data subject can be shown.
429 days leftEU AI Act high-risk obligations (Annex III) apply from 2 December 2027
BarzelVault
The AI action firewall: decide what an agent may do before it does it.
- Approval thresholds and policy checks enforced before execution; human approvals that expire and escalate.
- Cryptographically signed audit receipts: trigger, inputs, policy version, approver, outcome.
- Credential isolation, spend and action limits, and an emergency kill switch.
Free tier: 10,000 calls a monthPaid plans from $199 a monthLive on MCPize
Barzel Central Gateway
The AI governance control plane: one inventory and one policy layer across every MCP server and agent.
- Registers and synchronises every tool; enforces identity, policy, region, cost and health per tool.
- Identity mapping through OIDC, Entra ID, Okta, SAML and SPIFFE, with credential brokerage.
- Trace and SIEM export (W3C trace context, OTLP) for the security team and the regulator.
Free tier: 1,000 calls a monthPaid plans from $10 a monthLive on MCPize
Enterprise: written quote by email within two business days. No sales call.
Sources
- Lov om bogføring (bogføringsloven), LOV nr 700 af 24/05/2022 — retsinformation.dk.
- Lov om foranstaltninger til sikring af et højt cybersikkerhedsniveau (NIS 2-loven), LOV nr 434 af 06/05/2025 — retsinformation.dk.
- Lov om supplerende bestemmelser til forordningen om kunstig intelligens, LOV nr 467 af 14/05/2025 — retsinformation.dk.
- Folketinget, bill L 111 (2025/1) — ft.dk. Lapsed at the general election of 24 March 2026.
- Regulation (EU) 2026/1744 (Digital Omnibus on AI) — in force 27 July 2026.
- Datatilsynet, Katalog over foranstaltninger: logning af brugernes anvendelser af personoplysninger.
- Erhvervsstyrelsen, Vejledning om bogføringsloven — definitions of transaktionsspor and kontrolspor and the five-year retention period.
This article is for information and does not constitute legal or audit advice. The Danish text of the instruments cited is the binding one. Position as at 3 September 2026.