AI Regulation for Danish Companies: A Practical Compliance Guide

Artificial intelligence is already embedded in Danish business. A manufacturer uses a model to predict equipment failure, a logistics company forecasts demand, a bank reviews documents, and a sales team drafts account research with a general purpose AI assistant. The important question is no longer whether a company uses AI. It is whether the company knows which systems are in use, what decisions they influence, what data they receive, which supplier controls them, and what evidence exists when a customer, employee, auditor, or authority asks.

This guide is for Danish B2B companies, including software businesses, manufacturers, professional services firms, distributors, and suppliers to the public sector. It is operational guidance, not legal advice. The legal position and official guidance described here are checked against sources available in September 2026. The EU AI Act is binding law. Guidance, voluntary codes, standards, and national implementation proposals are useful but are not automatically law. A company should confirm its own facts, sector rules, and application dates with qualified counsel.

The legal map for a Danish company

The starting point is Regulation (EU) 2024/1689, the EU AI Act, available on EUR-Lex. It applies across the Union and can also apply to organizations outside the EU when an AI system is placed on the Union market, put into service in the Union, or its output is used in the Union. It creates different obligations for providers, deployers, importers, distributors, product manufacturers, and authorized representatives. A Danish customer buying a cloud product will commonly be a deployer, while a Danish company building and marketing an AI product may be a provider.

The Act uses a risk structure. Some practices are prohibited. Certain systems are high risk and carry extensive requirements. Some systems trigger transparency duties. General purpose AI models have duties for their providers, with additional rules for models presenting systemic risk. Many ordinary business uses are not automatically high risk, but they can still be subject to GDPR, cybersecurity, consumer, employment, product safety, intellectual property, and contractual obligations. Read the European Commission overview of the AI regulatory framework alongside the Regulation, not as a replacement for it.

The Commission's implementation material changes over time. Codes of practice, harmonized standards, templates, delegated acts, and FAQs can make compliance easier, but their status differs. A binding provision in the Regulation is law. Commission guidance explains how the Commission understands or expects implementation. A voluntary code can be a useful route to good practice or conformity, but signing it does not by itself satisfy every legal obligation. A draft national bill or policy proposal is not a current legal duty. Keep these categories separate in the company's legal register.

Dates and the 2026 transition problem

The AI Act is phased. The prohibition rules and the AI literacy obligation began earlier than many high-risk and transparency duties. General purpose AI obligations have their own timetable. High-risk obligations can depend on whether a system is a safety component of a regulated product, whether it is an Annex III use, and which transitional rule applies. During 2026, amendments and implementation measures can alter the practical timetable for some high-risk systems. Use the current Commission AI Act timeline and the current EUR-Lex text rather than a calendar copied from an old blog post.

Create a transition register with the provision, system or role affected, original date, current date, legal source, interpretation owner, and required evidence. Mark a date from the Regulation as binding. Mark a Commission recommendation, standard, or internal target as guidance or a control choice. If a date depends on a future implementing act, record that dependency. This small distinction prevents a board paper from presenting an expected date as settled law or allowing a voluntary practice to be mistaken for a complete legal assessment.

Denmark's national implementation and supervisory roles

The AI Act is an EU regulation, so Denmark does not need to transpose its core duties into a new Danish act in the way it would transpose a directive. Denmark does need national arrangements for competent authorities, market surveillance, penalties, cooperation, sandboxes, accreditation, and practical enforcement. Those arrangements can involve legislation, administrative decisions, guidance, and coordination between authorities. Check the current Danish material from the Ministry of Digital Affairs, the Danish Agency for Digital Government, and Retsinformation for the status of national measures.

The Danish Data Protection Agency, Datatilsynet, remains the key Danish privacy authority. Its GDPR powers do not disappear because a system is described as AI. Where personal data is processed, Datatilsynet can be relevant to lawfulness, transparency, purpose limitation, data minimization, security, data subject rights, automated decisions, impact assessments, processors, and international transfers. The AI Act and GDPR may require different documents and controls for the same system.

Other authorities can matter according to the system and sector. Market surveillance bodies can address products and safety. The Danish Working Environment Authority may be relevant to workplace risks. The Danish Consumer Ombudsman can matter for consumer-facing marketing and practices. Sector regulators can have duties for financial services, health, transport, energy, or communications. The AI Act's national structure should not be read as one Danish AI regulator replacing all existing authorities. Identify the authority connected to the harm, product, data, workplace, or market in question.

A responsible Danish compliance policy should state the source and status of each proposition. For example: the AI Act is binding EU law; Datatilsynet guidance is authoritative supervisory guidance but does not amend the Regulation; a Danish ministry consultation or draft bill is a proposal; an industry code is voluntary unless incorporated into a contract or another legal instrument. Revisit the register when Denmark publishes a designation, penalty provision, sandbox arrangement, or official translation.

Start with an inventory, not a generic policy

A policy written before discovery usually describes an imaginary company. Build an inventory that covers purchased software, embedded product features, APIs, experiments, open source models, browser extensions, spreadsheet add-ons, customer integrations, and tools adopted by employees without procurement approval. Ask business units, IT, security, procurement, HR, finance, legal, product, and customer support to contribute. Include Danish and international systems used by Danish staff or used to make decisions about people in Denmark.

• Record the system, model or feature, version, interface, plug-ins, retrieval sources, connected tools, autonomous actions, and system owner.
• Describe the actual purpose, such as candidate ranking, invoice extraction, customer support, credit assessment, demand forecasting, quality inspection, or sales prioritization.
• Identify the provider, reseller, importer, hosting location, account owner, subprocessors, support channel, and contract.
• Map input and output data. Flag personal data, special category data, confidential information, trade secrets, financial records, customer content, children's data, and safety-related information.
• Record affected people, countries, business units, sector, scale, autonomy, impact, and whether an output changes access, price, employment, service, safety, or legal position.
• Document human decisions, override rights, escalation thresholds, logging, retention, known limitations, incidents, and planned retirement.

Give every entry an owner and a confidence rating. An invoice showing that a tool is being paid for is useful evidence even if the model version is unknown. Do not omit an entry because discovery is incomplete. Reconcile the inventory with software asset management, identity records, cloud bills, data processing registers, vendor lists, expense reports, product roadmaps, and security logs. Shadow AI is not just a policy failure. It is a discovery signal that employees may lack an approved workflow that is fast and usable.

Classify role and risk system by system

A Danish company can have several AI Act roles. It can be a deployer of a purchased assistant, a provider of a customer-facing application built on a third party model, an importer of a system from outside the EU, and a product manufacturer for an AI component embedded in equipment. A substantial modification or placing a system under the company's name can change the analysis. Put the role conclusion in the inventory and obtain sign-off for uncertain cases.

The first risk gate is prohibited practice screening under Article 5. The Act prohibits specified uses involving manipulation, exploitation of vulnerabilities, social scoring, certain biometric categorization, emotion recognition in restricted contexts, and other practices. Labels such as wellbeing, personalization, fraud prevention, or culture fit do not answer the legal question. A human reviewer cannot cure a prohibited use. Stop and escalate when the intended purpose, affected group, or technical behavior is unclear.

Next test whether the system is a safety component of a regulated product, an Annex III high-risk use, a general purpose AI model, a transparency use, or outside the Act's relevant categories. A powerful model drafting an internal email is not automatically high risk. A smaller model ranking candidates, evaluating workers, assessing access to an essential service, or supporting a safety function can be high risk because context and purpose matter.

Use a documented decision tree. Record intended purpose, actual purpose, users, affected people, input data, output action, autonomy, regulated product connection, exclusions, and legal rationale. Reassess after a new data source, new geography, new user group, new downstream action, model change, or expansion from internal use to customer use. A vendor's claim that a product is low risk is an input to review, not the company's classification decision.

GDPR and Danish privacy expectations

If an AI system processes personal data, start with the GDPR analysis before discussing model performance. Define the controller and processor roles, lawful basis, purpose, data categories, retention, recipients, transfers, security, and data subject rights. Explain the system in understandable language. Consider whether a data protection impact assessment is required or prudent, especially where processing is systematic, large scale, sensitive, or likely to create a high risk to individuals. The Datatilsynet GDPR guidance and its AI materials are essential Danish sources.

Do not treat pseudonymization as a universal answer. A model can still reveal personal information, infer attributes, memorize confidential text, or enable re-identification. Check prompts, retrieval stores, fine-tuning data, logs, evaluation sets, support tickets, and vendor training settings. Data minimization should affect the design: use the smallest useful context, mask unnecessary identifiers, restrict sensitive fields, and delete temporary inputs according to a documented schedule.

Automated decision rules need special care. Article 22 GDPR concerns decisions based solely on automated processing that produce legal effects or similarly significant effects, subject to its conditions and exceptions. A nominal human who accepts every model output without authority, time, or information to intervene may not make the process meaningfully human. Document the human role, the person's competence, the information they receive, override rates, reasons for overrides, and the route for a person to contest or request review.

Employment and workplace AI

Employment is one of the highest exposure areas for Danish companies. Recruitment ranking, promotion recommendations, scheduling, performance scoring, termination risk, worker monitoring, access control, and productivity analytics can affect livelihoods and dignity. Some employment and worker-management uses are high risk under the AI Act when the conditions apply. GDPR, Danish employment law, equality rules, working environment requirements, collective arrangements, and consultation duties may apply at the same time.

Before deploying workplace AI, define the legitimate business purpose and the decision boundary. Do not let a model silently convert proxy signals into a judgment about commitment, health, personality, loyalty, or future performance. Test outcomes across relevant groups, languages, job types, working patterns, and disability accommodations. Tell workers and candidates what the system does where required. Provide a route to human review and correction. Involve HR, legal, privacy, security, managers, and employee representatives early rather than presenting a finished system for approval.

Keep a record of the business case, alternatives considered, consultation, data sources, validation, bias testing, instructions, reviewer training, access controls, individual notices, complaints, and changes. If an external HR vendor supplies the model, the employer still owns the deployment context. Contractual assurances do not replace a Danish employer's responsibility to use the system lawfully and fairly.

Consumer transparency and customer trust

B2B companies often assume consumer transparency is irrelevant. That is unsafe when a business sells to individuals, serves employees of a customer, operates a public website, or supplies a customer-facing tool that a downstream company uses with consumers. Article 50 includes transparency duties for specified interactions and generated or manipulated content. The exact trigger and exception must be checked in the current Act and implementation material. Do not reduce the rule to a universal AI badge.

Tell a person when they are interacting with an AI system where the Act requires it, at the point of interaction and in clear language. Give customers a visible path to human help. For generated images, audio, video, or text, decide when labels, provenance metadata, or records are needed. Coordinate notices with GDPR information duties, consumer protection, advertising rules, accessibility, intellectual property, and Danish language expectations. A disclosure hidden in lengthy terms is poor evidence of meaningful transparency.

Test the experience, not only the text of the notice. A customer should understand what the system can do, what it cannot do, whether a person will review the case, how to correct an error, and who to contact. Keep approved notice wording, trigger conditions, translations, accessibility checks, screenshots, release versions, and sample conversations in the evidence record.

AI literacy is a practical duty

Article 4 requires providers and deployers to take measures to ensure, to the best of their ability, a sufficient level of AI literacy for staff and other people operating systems on their behalf. This is not satisfied by one generic annual slide deck. Training should match the system and role. A support agent needs to recognize fabricated answers, protect customer data, disclose AI use, and escalate. An engineer needs evaluation, prompt injection, security, documentation, and release skills. A manager needs to understand accountability, uncertainty, bias, and the limits of automation.

Maintain a training matrix with role, system, learning objective, delivery date, assessment, refresher trigger, and evidence. Include contractors and temporary staff where they operate systems for the company. Test practical competence with scenarios: refusing to paste a payroll export into an unapproved tool, challenging a biased recommendation, spotting a prompt injection, correcting a customer record, and stopping an autonomous action. Measure comprehension and behavior, not just attendance.

Vendor controls for Danish buyers

Buying a SaaS product does not outsource accountability. The vendor may be the provider of its AI system, while the Danish customer is a deployer responsible for instructions, lawful context, human oversight, monitoring, and records within its control. A vendor contract should make those boundaries explicit. Separate public chatbot terms, enterprise workspace terms, API terms, and embedded product terms. A salesperson's statement that data is not used for training is not enough. Check the contract, settings, subprocessors, retention, and technical behavior.

• Ask the supplier to identify its AI Act role, system purpose, model family, relevant versions, limitations, compliance route, and material dependencies.
• Request technical information for safe deployment, including data flows, logging, security, residency, retention, access, evaluation, and incident contacts.
• Define whether prompts, files, outputs, and telemetry train a model; how deletion and correction work; and what happens after a model change.
• Require notification of material model changes, new subprocessors, vulnerabilities, data exposure, serious incidents, outages, and loss of a stated compliance status.
• Reserve proportionate evidence, audit, cooperation, and regulator-response rights. Make the supplier preserve records needed to investigate an incident.
• Set exit terms for export, deletion, transition, service withdrawal, model retirement, and continued access to records.

Score vendors by use case rather than creating one huge questionnaire. A low-impact text assistant needs different evidence from a model affecting worker access, customer eligibility, safety, or regulated product conformity. Require a named internal owner who can reject a vendor or pause use. Procurement should not approve a tool without privacy, security, business, and risk review when the intended use warrants it.

Public procurement is not one category

A Danish private company selling to a public authority should distinguish at least three questions. First, what AI Act role does the company have for the product? Second, what obligations apply to the public authority as deployer or provider? Third, what does the procurement contract require? Public procurement requirements can demand transparency, documentation, data location, security, interoperability, accessibility, audit rights, sustainability, or human control even when the particular AI use is not high risk under the Act.

Do not describe every public sector purchase as a high-risk AI procurement. A procurement of ordinary software with an optional generative feature, a procurement of a regulated safety component, and a procurement of a system used to evaluate people have different legal and contractual analyses. Review the Danish Competition and Consumer Authority procurement guidance and the Danish Agency for Digital Government material for current public sector context. Treat tender requirements and contractual commitments as binding between the parties even when they are not AI Act obligations.

For a tender, prepare an evidence pack that explains architecture, data flows, role allocation, model changes, security, accessibility, human oversight, incident response, subcontractors, service levels, and exit. State clearly what is available now, what is configurable, and what depends on a supplier. Avoid promising that a product is simply AI Act compliant. Compliance depends on the system, role, configuration, purpose, and deployment.

Human oversight must work in practice

Human oversight is not a person clicking approve. Name the reviewer or team, define the information they can see, provide enough time and authority to challenge the output, and ensure they understand limitations. For significant uses, set confidence thresholds, automatic stops, dual review, escalation, and a route for correction. Test whether reviewers actually override questionable outputs and whether managers punish reasonable challenges through unrealistic productivity targets.

Create an oversight record that links input or case reference, model version, output, reviewer, decision, reason, override, downstream action, and incident or complaint. Minimize personal data and restrict access. Sampling is useful where full review is not required, but sampling must be designed to detect rare and serious failures. A process that reports a 99 percent approval rate without checking rejected or overridden cases may be measuring compliance theater.

Evidence, logging, and incident response

Evidence should be created as part of normal operations. Maintain an AI inventory, legal register, role and classification decisions, prohibited-use screens, data maps, impact assessments, vendor evidence, training records, system instructions, evaluations, notices, access reviews, change approvals, logs, human oversight samples, and incidents. Store the owner, date, version, source, approval, retention, and review date for each record. A folder full of undated screenshots is not a control system.

Log enough to reconstruct a material event while minimizing unnecessary personal data. Depending on the system, capture timestamp, version, input reference, relevant data source, output, confidence or signal, user, action, override, policy result, and incident link. Protect logs from unauthorized alteration, define retention, and separate sensitive prompts from broad support tickets. An entry saying only that the model ran successfully cannot explain an incorrect customer decision.

Define an AI incident as more than a security breach. It can include discrimination, a wrong recommendation, unsafe action, privacy exposure, prompt injection, misleading synthetic media, loss of traceability, unauthorized autonomous action, or failure of human oversight. The playbook should cover containment, access suspension, review of affected cases, vendor escalation, legal assessment, regulator notification where required, customer communication, root cause, corrective action, and controlled restart. Run tabletop exercises for a recruiting model producing unequal outcomes and a support agent exposing confidential information.

A practical implementation roadmap

Days 1 to 30 should create visibility. Appoint an executive sponsor, AI governance owner, privacy lead, security partner, procurement contact, and system owners. Set an interim rule for sensitive data, prohibited uses, and high-impact decisions. Collect the inventory across business units. Screen each entry for prohibited practices, high-risk indicators, GPAI dependence, transparency triggers, employment impact, and regulated products. Record unknowns with an owner and decision date.

Days 31 to 60 should create controls. Approve the role and classification method. Publish an acceptable-use standard and role-based training. Update vendor questionnaires and priority contracts. Configure identity, access, retention, logging, notices, human review, and incident intake for the highest exposure systems. Start a legal register that distinguishes EU law, Danish law, Datatilsynet guidance, Commission material, standards, proposals, and internal policy.

Days 61 to 90 should test effectiveness. Complete assessments for priority systems, run performance and group testing, sample human overrides, review supplier evidence, conduct an incident tabletop, and test rollback. Create a change gate for models, prompts, data, integrations, user groups, and purposes. Report open high risks, overdue evidence, training coverage, incidents, correction time, review quality, and upcoming application dates to leadership. Then move to a quarterly review cadence.

KPIs that show control

Track coverage and effectiveness together. Useful leading indicators include the percentage of systems inventoried, named owners, completed classifications, approved tool adoption, role-based training completion, vendor evidence coverage, tested rollback, and material changes reviewed before release. Useful operating indicators include review completion, override rate by use case, error rate by relevant group and language, unresolved incidents, time to contain, time to correct affected records, and customer or worker complaints.

Avoid vanity metrics. High training attendance can coexist with employees pasting customer data into personal accounts. A low override rate can mean a model is excellent, or that reviewers cannot challenge it. Pair each metric with a quality sample, threshold, accountable owner, and action. Report exceptions and trends, not only green percentages.

Common failure modes

• Treating a supplier's compliance statement as the company's classification, risk assessment, or deployment decision.
• Assuming all generative AI is prohibited, or assuming every productivity tool is outside regulation.
• Writing one broad policy without configuring access, data controls, notices, logging, human review, and incident response.
• Ignoring shadow AI instead of making the approved workflow safe, quick, and useful.
• Calling a reviewer human-in-the-loop when the person cannot see, understand, challenge, or stop the output.
• Using an old application calendar without checking current EU transition rules and Danish implementation material.
• Presenting guidance, a voluntary code, a standard, or a draft proposal as binding Danish law.
• Keeping sensitive prompts indefinitely or copying them into tickets with broad access.
• Testing only English performance when the system handles Danish customer, worker, or business data.
• Buying a compliance platform that creates a second inventory rather than integrating with procurement, privacy, security, product, and incident systems.

Build versus buy

Buy commodity controls where mature products already exist: identity, access management, asset discovery, training delivery, ticketing, evidence storage, monitoring, and vendor questionnaires. Build or configure the judgment layer: role mapping, use case taxonomy, risk appetite, prohibited-use gate, human review design, Danish language evaluation, escalation, and executive reporting. A platform can organize evidence. It cannot decide whether a worker-management use is high risk or whether a reviewer can genuinely override a recommendation.

A small or mid-sized Danish company can begin with a controlled register, approved tool catalogue, vendor addendum, training matrix, and incident workflow. A larger company should connect those controls to its GRC, privacy, security, quality, product lifecycle, and supplier management systems. The right architecture leaves an accountable trail without forcing every team to maintain a disconnected spreadsheet.

What can we do for you?

Magna Products helps Danish B2B companies turn scattered AI experiments into controlled, useful operations. We can map your AI inventory, classify roles and use cases, assess vendor and GDPR control gaps, design approved workflows for general purpose AI tools, build human review and evidence processes, and connect governance to the systems your teams already use. Talk with Magna Products to arrange a focused discovery workshop and leave with a prioritized 30, 60, and 90-day compliance backlog for your company.