Journalisering when a model wrote the draft

A caseworker in a Danish municipality opens a case, asks an assistant to draft a decision letter, reads the draft, changes two paragraphs, and sends it. The letter is journalised, as letters are.

Four other things were created on the way. The instruction the caseworker gave. The documents the system retrieved to ground its answer. The draft the caseworker rejected before this one. The record of which model produced which version. Danish record-keeping duties were written before any of those existed, and they do not map onto them cleanly.

This is an architecture article rather than a legal one. The legal reading belongs with your own counsel and, for the questions below, quite possibly with Datatilsynet or Rigsarkivet. What follows is what the system has to be able to do so that the answer, whichever way it lands, remains available to you.

The questions without settled answers

Journaliseringspligt attaches to documents received or sent by an authority in connection with case handling, where the document has significance for the case. A generated draft is neither received nor sent while it sits in the interface. It plainly has significance.

The prompt records what the caseworker asked, which shapes what came back, and in a complaint it may be the most informative artefact in the file. The retrieved sources are the factual basis the draft rests on, and a duty to note factual information of significance is long established for information arriving by other routes. Whether either belongs in the case is unresolved.

The rejected draft may be an internal working document, which raises the question of whether the obligation to extract factual information still reaches into it. Arkivloven raises a further one: what belongs in the archival version once the case is closed, now that a faithful record of the process includes machine-generated intermediate states.

We do not know, and as far as we can find, nobody has published an answer. What we do know is that the cost of being wrong is asymmetric.

Why the asymmetry decides the design

If you capture these artefacts and the eventual answer is that you did not have to, you have retained more than required. That has a storage cost and a data protection consequence, both manageable with a retention rule.

If you do not capture them and the answer is that you should have, the material is gone. It cannot be reconstructed later, because the model that produced it may no longer exist in that version and the index it retrieved from has moved on. A case from 2026 becomes undocumentable in 2028.

Capture is reversible. A deletion policy can be applied later to material you kept. Nothing can be applied later to material you never recorded.

What to capture at generation time

• The instruction, as submitted, with the case identifier it was issued under
• The identifiers and versions of the documents retrieved, sufficient to reconstruct the factual basis even if those documents are later revised
• The model and prompt template version, so behaviour can be explained rather than guessed at
• The generated output, and whether a human accepted, amended, or rejected it
• The identity of the caseworker, since attributing a decision to a person is the point of the record

Note what is absent from that list. There is no requirement to journalise all of it into the case system by default. Capture and journalisation are separate decisions, and conflating them is what makes people reject the whole idea as unworkable.

Capture first, classify second

Write the artefacts to a store bound to the case identifier, with a retention rule and access control that match the case itself. Then decide, as a policy the authority owns rather than a default the supplier chose, which of them are journalised into the case, which are retained outside it, and which are deleted on a schedule.

That separation means a change of legal interpretation becomes a configuration change. It also means the authority can answer an access request about how a decision was produced, which is the question that will eventually be asked whether or not the law has caught up.

What we recommend

Treat generated material as case material until someone with authority decides otherwise, and build capture into the system from the first deployment rather than after the first complaint. Bind everything to the case identifier, apply the case retention rule, and keep the journalisation decision configurable.

Then ask the question properly. This needs an answer from Rigsarkivet and from the sector, not from each municipality separately reaching a different conclusion. Until then, the authorities that captured will have choices and the ones that did not will have gaps.

Does an AI-generated draft have to be journalised?

There is no settled answer. Journaliseringspligt attaches to documents received or sent in connection with case handling that have significance for the case, and a draft sitting in an interface is neither received nor sent while it clearly has significance. Treat it as case material until an authoritative interpretation says otherwise.

What about the prompt and the retrieved sources?

Both are strong candidates for the case record. The prompt records what was asked and shapes what came back. The retrieved documents are the factual basis the draft rests on, and duties to record factual information of significance are long established for information arriving by other routes.

Is capturing everything not a data protection problem?

It is a manageable one, provided the material is bound to the case identifier and inherits the case retention rule and access control. The alternative is worse. Deletion can be applied later to material you kept, and nothing can be applied to material never recorded.

How should this be built?

Capture at generation time into a store bound to the case, then treat journalisation as a separate configurable policy the authority owns. That way a change in legal interpretation is a configuration change rather than an unrecoverable gap in cases already closed.