What an authority must now be able to show

Sundhedsdatastyrelsen holds some of the most sensitive health and demographic data on Danish citizens, and it did almost everything right. Staff were permitted to use Microsoft Copilot under a policy that explicitly forbade entering personal data or prompting with internal information. Then, on 13 May 2026, the agency reported a breach it had not caused and could not fully explain: an update pushed by Statens IT, the state's shared IT operator, had given Copilot access to the agency's Outlook environment.

The integration violates the agency's guidelines for the use of artificial intelligence and is therefore considered a breach of personal data security. It remains unknown how long the breach lasted, and it is likewise unknown what information Copilot had access to through employees' Outlook.

Datatilsynet has since closed the case. Sundhedsdatastyrelsen told Ingeniørens Radar it still has no complete overview of what Copilot reached, or for how long. Statens IT disputes that a breach occurred at all, and points to Microsoft's EU Data Boundary as its answer: the data stayed in the EU.

A location is not a record

That answer is offered to a question it does not address. Nobody asked where the servers sit. The question was what the system touched and when, and residency says nothing about either. Jan Trzaskowski, professor of EU law and data protection at Aalborg University, put the underlying mechanism plainly:

The more complex a system is, the greater the risk becomes. The more you automate, the greater the chance that something unintended happens. Automation is a form of outsourcing that makes some work processes easier, but you outsource the control and the risk along with it.

Nobody at Sundhedsdatastyrelsen decided to connect Copilot to Outlook. The authority accountable for the data did not choose the change, was not told about it in advance, and cannot reconstruct it after the fact. A correctly written policy failed because it governed a decision that was never made at the layer the policy could reach.

The same failure, twice, at lower competence

Glostrup Kommune had a policy too, an approved tool in Microsoft Copilot, and a compliance board. A citizen, Jonas Helmer, applied for disability support and noticed a phrase in the reply that read as machine written. He asked, and the municipality confirmed it: a caseworker had used Copilot and ChatGPT as support in handling his case. Asked by DR whether Helmer's personal data had been processed inside those tools, the municipality could not say. Not a denial. Not a confirmation. It does not know, and it has no way to find out, because ChatGPT sat outside every guideline the municipality had written.

Glostrup's own account of how that happened is honest, and it is not a defence:

The line between searching for information online and using AI has become razor thin, since search engines such as Google often switch automatically into AI mode, and that cannot be avoided.

They are right that it cannot be avoided at the browser. It can only be resolved one layer down, at the path a request actually travels.

Kerteminde Kommune had no policy at all. An aktindsigt request by ComplianceTech established that AI tools were in wide use across the municipality for case preparation, administrative support, and drafting, with no risk assessment and no impact analysis carried out for any of it, and with guidelines that staff and managers alike found unclear. Datatilsynet opened an investigation on its own initiative and recorded, as a fact worth stating in its own right, that the tools in question were typically browser-based platforms such as ChatGPT and Gemini. Not the use case. Not the policy. Where the model runs and who operates it.

The legal basis most authorities do not have

Allan Frank, IT security specialist at Datatilsynet, said something in the same reporting that is easy to read past and should not be:

You need statutory authority for that in Denmark, and public authorities generally do not have it.

A supervisory authority, on the record, saying that Danish public authorities generally lack the legal basis to use AI at all. Set that against the ambition the previous government attached to this technology: AI is meant to save the equivalent of 30,000 årsværk across the public sector by 2035. Municipalities are being asked to deliver a productivity target denominated in staff years, with a tool their own regulator says they generally may not use. That gap, not vendor politics, is the actual constraint kommuner are operating inside.

Frank made the second point to ComplianceTech earlier this year, about the platforms these tools run on:

When you buy an iceberg, you have to set aside resources to find out what lies beneath the part you can see above the waterline.

The complexity of a large vendor platform is not a mitigating circumstance. The duty to know what a system does with a citizen's data applies in full, regardless of how much of that platform an authority can actually see.

What changed on 2 August

All three cases now sit on the far side of a deadline. The AI Act's high-risk obligations for deployers took effect on 2 August 2026, and they cover exactly the decisions a municipality makes: employment, benefits, and access to public services. A public authority deploying such a system must complete a fundamental rights impact assessment and register it in the EU database. None of that is paperwork produced after the fact. A FRIA needs the same thing Kerteminde and Glostrup could not produce when asked: a record of what the system does, what data reaches it, and who is accountable for it.

The pattern across all three cases is not carelessness. Kerteminde had no policy. Glostrup had a policy and a compliance board. Sundhedsdatastyrelsen had a correct policy, a compliant licence, and a professional state IT operator. The failure did not shrink as competence rose, because policy governs intent, and none of these cases turned on intent. Each one turned on a decision made at a layer no policy reaches: which model a browser tab silently switched to, which integration an operator enabled without asking, which platform update ran overnight.

What a buyer can actually specify

The requirement that follows is not a stance on any particular vendor. It is a specification: the authority needs to be able to name, for any request that touched personal data, which model handled it, where it ran, and what it had access to. That is a property of the architecture a request travels through, not a property of a contract clause or a training session. A tender can ask for it directly, ahead of the FRIA it will eventually require anyway: a documented inference path, logging that records which model served which request, and access scoping that makes an integration like the one Statens IT enabled impossible to add without the accountable authority's own approval. None of the three authorities above could have produced that record when asked. Building the ability to produce it costs less before an aktindsigt request arrives than after.

What do Kerteminde, Glostrup, and Sundhedsdatastyrelsen have in common?

None of the three could tell a citizen, a journalist, or their own regulator what an AI system did with personal data in a specific case. Kerteminde had no policy, Glostrup had a policy that ChatGPT fell outside of, and Sundhedsdatastyrelsen had a correct policy defeated by an integration nobody at the agency chose. In every case the missing thing was the same: a record of what the system touched.

Does 'EU Data Boundary' or EU data residency satisfy this requirement?

No. Residency is a claim about where data is stored. The obligation that follows from these cases is a record of what a system did and when, which is a different property. Statens IT offered the EU Data Boundary as its answer to a question about what Copilot reached and for how long, and the two do not overlap.

What does the AI Act require of a Danish municipality specifically?

As of 2 August 2026, a public authority deploying a high-risk AI system for decisions on employment, benefits, or access to public services must complete a fundamental rights impact assessment and register the system in the EU database. Both require a record of what the system does and what data reaches it, which is the same evidence these three cases could not produce after the fact.

What should a buyer put in a tender to avoid this?

A documented inference path: which model or models can serve a given request, where each one runs, and what data it can reach. Logging that records which model handled which request. Access scoping that requires the authority's own approval before a new integration reaches personal data. All three are architectural properties, and all three are what these cases show public authorities currently lack.

1. Jonas var ikke i tvivl, og han fik ret: Kommunen brugte AI og brød reglerne — DR
2. Kommune i AI-bommert: Grænsen mellem at søge oplysninger på nettet og bruge AI er efterhånden hårfin — Version2
3. Fejl hos Sundhedsdatastyrelsen kom til at give amerikansk AI-værktøj adgang til interne data — Version2 / Ingeniørens Radar
4. Datatilsynet går ind i sag om Kertemindes brug af AI — ComplianceTech / Ingeniøren