EU AI Act in Denmark: supervision and next steps

This page explains who supervises the EU AI Act in Denmark, how those arrangements sit next to existing Danish data protection supervision under Datatilsynet, and what a company placing AI on the Danish market has to do now that enforcement powers are live.

What the Act says about national supervision

The AI Act is a regulation, so its substantive obligations apply directly in Denmark without transposition. What Denmark had to decide nationally is who enforces them. Article 70 requires each Member State to designate at least one notifying authority and at least one market surveillance authority, and to make those designations public. Article 74 gives market surveillance authorities their powers, including the ability to demand documentation, require corrective action, restrict availability of a system or withdraw it from the market. Article 77 requires Member States to identify the public bodies that supervise fundamental rights obligations and to give them the power to request documentation from providers and deployers of high-risk systems.

Denmark set this out in national supplementary legislation and designated the Agency for Digital Government (Digitaliseringsstyrelsen) as the coordinating market surveillance authority and single point of contact for the AI Act. Sectoral regulators keep supervision within their own domains, so a system embedded in a medical device, a financial service or a piece of machinery is likely to be supervised by the same authority that already regulates the product or the service. The Danish Data Protection Agency (Datatilsynet) holds supervisory responsibility for AI use in law enforcement, border and migration contexts, which is where the AI Act and the Danish Law Enforcement Data Protection Act overlap most directly. Confirm the current allocation for your sector before you assume which regulator will write to you.

How this interacts with Datatilsynet and the GDPR

The two regimes are separate and cumulative. Datatilsynet supervises personal data processing under the GDPR regardless of what the AI Act says. A high-risk recruitment tool trained on candidate CVs needs a lawful basis, a data protection impact assessment under Article 35 GDPR, and a data subject rights process, and it also needs an Article 9 risk management system, Article 10 data governance, Article 11 technical documentation, Article 12 logging and Article 14 human oversight under the AI Act. Passing a Datatilsynet inspection does not close out AI Act duties, and an AI Act conformity assessment does not close out GDPR duties.

The practical overlap is in evidence. Your data governance records under Article 10 will answer many of the same questions a DPIA asks about data sources, representativeness and bias. Article 26(9) also says that where a deployer carries out a DPIA, the information in the Article 13 instructions for use should be used to help complete it. Build one evidence base and map it to both regimes rather than maintaining two disconnected files.

Provider or deployer, and why it decides your workload

A provider develops an AI system or has one developed and places it on the market or puts it into service under its own name or trade mark. A deployer uses an AI system under its own authority in a professional capacity. Most Danish software companies selling to customers are providers. Most Danish companies buying an AI tool for internal use are deployers.

Providers of high-risk systems carry the bulk of the obligations: risk management, data governance, technical documentation, logging by design, transparency and instructions for use, human oversight design, accuracy and cybersecurity, a quality management system under Article 17, conformity assessment, CE marking and registration in the EU database. Deployers carry a shorter but real list under Article 26: use the system in line with the instructions, assign human oversight to competent people with the authority to act, monitor operation, keep the automatically generated logs for at least six months unless another rule requires longer, and inform the provider and the market surveillance authority if you identify a serious incident or a risk. Article 25 can turn a deployer into a provider, for example if you put your own name on the system or substantially modify it or change its intended purpose.

Note also Article 4, in force now, which requires providers and deployers to take measures to ensure a sufficient level of AI literacy among staff dealing with the systems. This applies whether or not you touch high-risk categories.

The dates that bind

• 2 February 2025. Article 5 prohibited practices apply. Danish authorities can act on these now.
• 2 August 2026. Enforcement powers, Article 50 transparency duties and Article 53 obligations for general purpose AI models became enforceable. This date has passed.
• 2 December 2027. Standalone high-risk obligations for Annex III systems apply, following the extension in the Digital Omnibus provisional agreement of May 2026, which is still pending formal adoption. This is the next hard date, 455 days away.
• 2 August 2028. High-risk obligations for AI embedded in Annex I regulated products apply.

Penalties under Article 99 reach 35 million euros or 7 per cent of worldwide annual turnover for breaches of Article 5, and 15 million euros or 3 per cent for most other provider and deployer obligations. Supplying incorrect or misleading information to a national authority carries up to 7.5 million euros or 1 per cent.

What to do next

1. Write down your role per product. One line per system stating provider or deployer, the intended purpose, and whether it falls in Annex III. Keep the reasoning, because that is what Digitaliseringsstyrelsen or a sectoral regulator will ask you to justify.
2. Screen against Article 5 today. Emotion inference in the workplace or in education, untargeted facial image scraping and social scoring are already prohibited. This is not a 2027 problem.
3. Turn on logging and set retention. Automatically generated logs for the lifetime of the system where you are the provider, and at least six months where you are a deployer under Article 26(6). Decide now where they are stored and who can export them.
4. Join up your DPIA and AI Act evidence. Map your existing Datatilsynet-facing records to Article 9, Article 10 and Article 11 requirements, and record the gaps as a dated backlog with owners.
5. Check the language of your instructions for use. Article 13 requires instructions in a language easily understood by deployers as determined by the Member State. If you sell into Denmark, verify whether Danish is required rather than assuming English is sufficient.

If you are not yet sure whether your system falls inside Annex III or which role you occupy, the free screener at https://www.getactcomply.com/check walks through the classification questions and returns the provisions that apply to your case.