Procuring AI Systems in Denmark (2026): What Contracting Authorities and Suppliers Need to Know

AI procurement Denmark is now a live compliance problem for every contracting authority issuing tenders and every supplier bidding to deliver algorithmic systems to Danish public bodies in 2026. The phased entry into application of the EU AI Act, with its classification of high-risk systems, conformity duties, documentation requirements and supplier warranties, intersects directly with Denmark’s established procurement framework under Udbudsloven. This guide translates those overlapping legal duties into concrete tender wording, evaluation criteria, scoring grids and contract clauses so that buyers and suppliers can act with confidence rather than guesswork. Read it as a practical playbook, not an academic overview, because tenders being planned today should already reflect these obligations.

Key takeaways, what contracting authorities and suppliers must do now

Time is the scarce resource in AI procurement Denmark right now. The following six actions capture the essential compliance posture for 2026 tenders.

• Confirm applicability first. Determine whether the EU AI Act governs the system you are buying or supplying before drafting a single specification.
• Classify the risk. Map the intended use of the AI system to the AI Act’s high-risk categories, because that classification drives almost every downstream obligation.
• Update your tender documents. Existing templates rarely capture conformity, transparency, logging and human-oversight requirements, refresh them now.
• Embed mandatory contract clauses. Warranties, technical documentation, audit rights and incident reporting must appear in the contract, not just the specification.
• Design defensible scoring. Award criteria must be objective, transparent and linked to the subject matter of the contract under Udbudsloven while still rewarding genuine AI compliance.
• Build the audit trail. Document every classification decision, evaluation score and supplier declaration so the award survives challenge.

Lawyer tip: Treat the AI Act classification decision as the pivot of the whole procurement, get it wrong and every specification, award criterion and contract clause that follows will be misaligned.

Why 2026 matters, EU AI Act and Danish implementation for procurement

2026 is a year in which AI procurement Denmark shifts from theory to enforceable practice, as the AI Act’s obligations phase in over a staggered timetable set out in the Regulation itself. Contracting authorities can no longer treat AI as ordinary software; the regulatory expectations attached to certain systems now shape how tenders should be written, evaluated and contracted. The practical effect is that procurement teams face a compliance problem the moment they consider a contract notice for an AI-enabled solution.

EU AI Act, short legal summary

The EU AI Act (Regulation (EU) 2024/1689) establishes a risk-based framework that assigns obligations according to the potential harm an AI system may cause. The European Commission’s AI Act materials set out the policy intent and the tiered structure, while the definitive statutory language and article numbering are available through EUR-Lex. High-risk systems attract the heaviest duties, conformity assessment, technical documentation, logging, transparency and human oversight, and while many of these duties fall primarily on providers, they translate into practical obligations for the public bodies that deploy such systems. Note that different obligations apply from different dates under the Regulation’s phased timetable, so verify which duties are in force for the specific system and date in question.

The core insight for procurement is that the AI Act allocates responsibilities between the party that develops or places the system on the market and the party that uses it. A contracting authority that procures and then operates an AI system will typically act as a deployer, and deployer duties cannot be contracted away entirely. That reality must be reflected in both the specification and the contract.

How national implementation affects Danish contracting authorities

The AI Act operates alongside, not instead of, Denmark’s domestic procurement regime. Udbudsloven, the Danish Public Procurement Act, accessible via Retsinformation, remains the procedural framework governing how public contracts are advertised, evaluated and awarded, and it implements the EU procurement directives in Denmark. National measures determine which authorities supervise the AI Act in Denmark and how they interact with existing data protection oversight from Datatilsynet. The practical effect is that authorities must satisfy both bodies of law simultaneously: the procedural discipline of Udbudsloven and the substantive AI-specific duties of the AI Act. For 2026 tenders, that means procurement officers should not rely on legacy templates that predate the AI Act.

Does the AI Act apply to your procurement? Scope and practical test

Before investing in tender drafting, establish whether the AI Act governs the transaction at all. Getting this scope question right prevents both over-engineering low-risk purchases and under-protecting high-risk ones. This is the first structured decision in any AI procurement Denmark exercise.

Public sector as deployer versus provider responsibilities

The distinction between provider and deployer is the hinge of the applicability analysis. A provider develops an AI system or places it on the market under its own name; the provider carries the conformity assessment, technical documentation and CE-related obligations. A deployer, which is what most Danish contracting authorities become, uses the system under its authority and carries duties around appropriate use, human oversight, monitoring and, where relevant, cooperation on incident reporting.

In a typical procurement, the supplier is the provider and the authority is the deployer. However, an authority that substantially modifies a system, or that commissions a bespoke system placed on the market under the authority’s name, may itself assume provider duties. The contract should make the allocation explicit so that neither party discovers an unassigned obligation after award.

Step-by-step applicability checklist

Use the following questions with your tender team at the earliest planning stage.

1. Does the procurement involve a system that qualifies as an AI system under the AI Act definition set out on EUR-Lex?
2. Will a Danish public authority deploy or operate the system?
3. What is the intended purpose, and does that purpose fall within a listed high-risk category?
4. Is the supplier the provider, or will the authority place the system on the market under its own name?
5. Does the system process personal data, triggering parallel obligations under the framework overseen by Datatilsynet?
6. Will the system be modified after delivery in ways that could change the responsible party?

If the answers indicate an AI system deployed by a public authority for a high-risk purpose, the fuller set of AI Act obligations is likely to apply and the tender should be built around them. If not, lighter transparency duties may still be relevant, but the procurement burden is materially reduced.

Assessing high-risk classification for tenders, checklist and comparison

High-risk classification is the single most consequential determination in AI procurement Denmark. It dictates the documentation you demand, the clauses you impose, how you weight evaluation criteria and what post-award monitoring you build. Classify carefully and record your reasoning.

High-risk categories commonly relevant for public procurement

The AI Act designates certain use cases as high-risk, and several of these arise frequently in public-sector buying. Procurement teams should pay particular attention to systems used for:

• Employment and worker management. CV-screening, candidate scoring and tools that influence hiring, promotion or termination.
• Access to essential public services and benefits. Systems that assess eligibility for, or allocation of, welfare and social benefits.
• Biometric identification and categorisation. Systems performing biometric identification or categorisation, subject to the AI Act’s specific rules and prohibitions.
• Critical infrastructure. AI used as a safety component in the management and operation of critical digital or physical infrastructure.
• Law enforcement and migration-adjacent functions. Systems supporting enforcement or administrative decision-making where individual rights are engaged.

The definitive list, exemptions and precise boundaries must be read from the AI Act text on EUR-Lex; the categories above are the ones most likely to surface in Danish public tenders.

Practical evidence checklist for suppliers

Where a system is high-risk, suppliers must be able to substantiate compliance. Require the following as evidence within the bid or as a condition of award, to the extent the relevant AI Act obligations are in force:

• A declaration of conformity and evidence of the relevant conformity assessment.
• Technical documentation demonstrating the system meets AI Act requirements.
• A description of the risk-management system and data-governance measures.
• Logging capability documentation and an explanation of record-keeping.
• A human-oversight design describing how meaningful oversight is achieved.
• Where relevant, CE marking evidence for the placed-on-market system.

Lawyer tip: Ask for classification reasoning in writing from suppliers, then form your own independent view. You cannot outsource the classification decision to the bidder, the authority owns the consequences.

High-risk AI versus other AI: procurement obligations and implications

Designing tender documents and lawful evaluation criteria for AI systems

Once classification is settled, the tender must convert legal duties into enforceable requirements without breaching Udbudsloven’s principles of equal treatment, transparency and proportionality. Well-drafted public tenders for AI systems in Denmark make compliance measurable and award criteria defensible.

Technical specifications, what to require from suppliers

Frame specifications around outcomes and evidence rather than proprietary architecture, which keeps the tender non-discriminatory while still capturing AI Act duties. Require:

• Documentation of training, validation and testing datasets and their governance.
• Performance metrics against defined operating conditions, including accuracy and robustness measures.
• Evidence of bias testing and data-quality controls.
• A human-oversight design that identifies who intervenes, when and how.
• Logging and traceability functionality sufficient for audit and incident reconstruction.
• Data protection measures aligned with the GDPR and the framework administered by Datatilsynet, including support for any required data protection impact assessment.

Award criteria and scoring for AI procurement Denmark

Award criteria must be objective, published in advance and linked to the subject matter of the contract. For high-risk systems you may lawfully reward superior transparency, robustness, data governance and oversight design, provided each criterion is measurable and non-discriminatory. A defensible structure separates minimum compliance thresholds (pass/fail) from quality criteria (scored). Set out the scoring method, the weighting and the evidence on which scores will be based, so that unsuccessful bidders can see how the decision was reached.

Lawyer tip: Never score a criterion you cannot evidence from the bid. Vague “quality of AI governance” scoring invites challenge, tie every point to a documented, verifiable input.

Selection and exclusion grounds, supplier declarations and competence checks

Use selection criteria to confirm that bidders have the technical and professional ability to deliver and maintain compliant AI systems. Require declarations covering conformity capability, relevant experience, quality-management systems and, where subcontractors deliver AI components, declarations extending to those subcontractors. The mandatory and voluntary exclusion grounds under Udbudsloven continue to apply, and a supplier’s inability to substantiate a mandatory conformity requirement may be treated as non-compliance with a minimum requirement rather than a scored deficiency.

Mandatory contract clauses and supplier obligations, clause bank and drafting notes

The contract is where AI Act duties become enforceable against the supplier. Specifications describe the system; clauses create the remedies. A robust AI procurement contract clauses set should map directly to the obligations identified during classification, and the clause bank below covers the essentials. Every snippet is illustrative.

Suggested language, adapt and legal review required. The clause snippets below are starting points only and must be reviewed against the final contract, the AI Act text on EUR-Lex and Udbudsloven before use.

Required compliance warranties and supplier declarations

Warranties convert regulatory compliance into a contractual promise with remedies attached. Cover conformity, ongoing compliance and accuracy of documentation.

• “The Supplier warrants that the System complies, at delivery and throughout the term, with all applicable requirements of Regulation (EU) 2024/1689 (the AI Act) and any implementing measures, and that all conformity documentation supplied is accurate and complete.”
• “The Supplier warrants that it has performed the conformity assessment required for high-risk AI systems and will provide the declaration of conformity and supporting technical documentation on request.”

Audit, documentation, testing and deliverables

Authorities must be able to verify compliance independently, both at acceptance and during operation. Build in inspection rights and defined deliverables.

• “The Supplier shall maintain and, on [X] days’ notice, make available to the Authority and its auditors the technical documentation, logs and testing records necessary to demonstrate ongoing conformity.”
• “Acceptance is conditional on the System passing the agreed test protocol, including accuracy, robustness and bias tests as set out in Annex [X].”

Liability, indemnities and insurance for AI systems

Allocate risk deliberately, recognising that public-law and general contract-law constraints may limit how far a supplier can cap or exclude liability for core failures. Address AI-specific harms such as erroneous automated decisions and data breaches.

• “The Supplier shall indemnify the Authority against losses arising from the System’s non-conformity with applicable AI or data protection law, subject to the liability provisions of this Contract.”
• “The Supplier shall maintain insurance appropriate to the risks of an AI system of this classification, with cover of not less than [amount].”

Beyond these, a complete clause set for procuring AI in Denmark should address transparency obligations to affected individuals, human oversight arrangements, logging retention, incident and breach reporting timelines, data protection cooperation consistent with the GDPR and guidance from Datatilsynet and the European Data Protection Board, maintenance and update duties, subcontracting controls, and termination rights triggered by persistent non-conformity. Where the system processes personal data, controller and processor roles must be defined and a data processing agreement attached.

Managing supplier performance and post-award compliance

Compliance does not end at signature. High-risk systems carry ongoing duties, and the authority’s deployer responsibilities continue for the life of the contract. Active management protects both the public interest and the authority’s legal position.

Incident reporting and breach management

Define what constitutes a reportable incident, the notification window and the escalation path. Require the supplier to report serious malfunctions and safety-relevant events promptly, to cooperate with any regulatory notification, and to coordinate with the authority on personal data breach notification obligations under the GDPR and the framework overseen by Datatilsynet. Keep a shared incident log that supports both contractual remedies and regulatory reporting.

Version control, updates and ongoing conformity assessment

AI systems change through retraining and updates, and material changes can affect conformity. Impose change-control obligations that require the supplier to assess whether an update alters the system’s risk profile or conformity status, to document that assessment, and to re-run acceptance testing where appropriate. Monitor agreed KPIs, require periodic conformity confirmations and schedule audits proportionate to the system’s classification.

Supplier checklist, how to prepare compliant bids for AI tenders in Denmark

Suppliers win on evidence, not assertion. A bid that anticipates the authority’s compliance needs is easier to score and harder to reject. Buying AI software in Denmark from a supplier’s perspective means assembling the following before submission.

Bid annex checklist

• Declaration of conformity and evidence of conformity assessment for high-risk systems.
• Complete technical documentation package, indexed to the tender requirements.
• Data governance statement covering datasets, quality and bias controls.
• Human oversight plan naming roles and intervention points.
• Test results for accuracy, robustness and bias.
• Maintenance, update and support plan with change-control procedures.
• Subcontractor declarations for any third-party AI components.
• Insurance evidence proportionate to the system’s risk classification.

Lawyer tip: Cross-reference every checklist item to the exact tender requirement number. Evaluators reward bids they can score quickly, and traceability signals a supplier that understands its AI Act obligations.

Sample evaluation grid and contract clause annex

To support implementation, authorities should prepare two adaptable assets: an evaluation scoring matrix and a clause bank containing the editable snippets referenced above. A compact inline version of the scoring grid is shown below; both assets should carry a version date and a legal-review disclaimer.

Weightings are illustrative and must be set for each procurement in line with Udbudsloven and the subject matter of the contract.

Next steps, resources and legal disclaimers

For AI procurement Denmark projects launching in the coming months, authorities should audit pipeline tenders for AI content, classify each system, refresh specifications and clause banks, and brief evaluation panels on defensible scoring. Suppliers should assemble conformity evidence and bid annexes early. Every sample clause and grid in this guide is a starting point that requires legal review before use, and any statutory reference should be verified against the primary texts, including the current, in-force version of the AI Act and Udbudsloven. Consult the Denmark, Public Procurement practice page and the GLE Lawyer directory, filter: Denmark / Public Procurement for tailored advice. This article is general information and not legal advice.

Sources

1. European Commission, AI Act overview and policy materials
2. EUR-Lex, EU law database (Regulation (EU) 2024/1689)
3. Datatilsynet, Danish Data Protection Agency
4. Retsinformation, Danish official legislation portal
5. European Data Protection Board (EDPB)
6. OECD, AI Principles and policy guidance