AI Procurement Policy for the EU AI Act: Keep Risk Out Before the Contract Is Signed

Guide10 July 2026· 14 min read

Build an AI procurement policy for the EU AI Act: intake questions, risk-tier approval gates, contract clauses, and a named owner — with a worked example.

A buyer at a 280-person payments company signs a one-year contract for an AI support tool. Overnight the company becomes its deployer under Regulation (EU) 2024/1689, holding obligations nobody assessed — because the only review the tool ever got was a price negotiation. That is the gap an AI procurement policy closes. It is the standing, repeatable rulebook that decides how every new AI tool or vendor enters your organisation: the intake questions each buy must answer, the approval gate that fires by risk tier, the contract clauses you demand before signing, and the one named owner accountable for it. This guide is the policy layer — the governing framework — not the per-purchase review or the vendor questionnaire that review uses.

What an AI Procurement Policy Is — and Why It Sits Above the Questionnaire and the Checklist

The AI procurement policy is not an artefact you produce once and file. It is the process that governs every AI buy, on repeat, for as long as your organisation procures software. Treat it as the front door: nothing AI-shaped passes through without being triaged against it. Three things are easy to confuse, and the policy depends on keeping them apart.

The procurement policy (this page) is the governing framework — the rules that decide which buys get scrutinised, how hard, and who signs off.
The AI due diligence checklist is the one-off review the policy triggers for a specific purchase.
The AI vendor questionnaire is the assessment artefact that review uses to collect answers from the vendor.

The policy is what makes diligence happen consistently on every buy — not only on the ones someone remembers to scrutinise.

Why intake belongs in procurement, not after go-live

The goal is plain: stop unmanaged EU AI Act exposure from entering through a signed contract, before it hardens into the deployer's standing obligation. Once the contract is live, you inherit the duties whether or not anyone classified the system. Intake is the only point where a no-go costs you nothing but a deal you had not yet made. And most buys are not high-risk — a policy that routes every buy through the full high-risk stack gets routed around within a quarter, and the tools reappear as shadow AI, so tier the gate and name an owner from the first line.

The Intake Questions Every New AI Tool or Vendor Must Answer

Intake is a fixed set of questions. Each answer maps to a downstream duty, and the policy records it so the obligation is owned at purchase — not discovered after an incident.

Intended purpose: vendor's claim vs the buyer's real use

Capture two things, not one: the vendor's stated intended purpose and your actual intended use. Divergence between them is the root of most misclassification — a tool sold as "drafting assistance" that you plan to point at hiring decisions is a different system in the eyes of the Act. Screen Article 5 prohibitions first, as a hard stop, before classifying further.

Role and the Article 25 provider-flip trigger

Confirm that your organisation is the deployer, and whether the vendor is provider, importer or distributor. Then flag the flip. Under Article 25, a deployer becomes a provider — inheriting the far heavier provider obligations — if it puts its name or trademark on a high-risk system, makes a substantial modification, or changes the intended purpose so a system becomes high-risk. Intake must ask whether the planned use does any of these, because the flip usually happens after purchase, when a team quietly repurposes a tool.

GPAI dependencies and pass-through documentation

Ask whether the tool is built on a general-purpose AI model. If it is, capture the downstream documentation the vendor can pass through under the GPAI obligations (Articles 53 and 55, with the technical-documentation elements in Annex XII). These have applied since 2 August 2025, so it is a live question, not a future one.

Data governance and Article 50 transparency posture

Two posture questions close intake. Article 10 data governance evidence is required for high-risk procured systems — record whether the vendor can supply it. And Article 50 transparency obligations apply wherever procured AI output reaches employees, customers or other third parties: chatbots must disclose they are AI, and synthetic content must be disclosed as artificially generated. Record where the output lands, because that determines whether the duty bites.

Approval Gates by Risk Tier

Tier the gate to the answer, not to the spend — a €2,000 hiring-screening tool carries far more EU AI Act weight than a €200,000 back-office automation buy. Each tier names who signs off and what evidence is required before contract, so the gate is auditable rather than discretionary.

The four-tier gate: prohibited, high-risk, limited, minimal

Prohibited (Article 5) — automatic no-go. No sign-off can rescue it.
High-risk (Article 6, Annex III) — full diligence plus governance-owner sign-off.
Limited-risk (Article 50 transparency) — a lightweight gate confirming the disclosure duty is met.
Minimal-risk — register and proceed.

Most buys land in the lighter two tiers, so the gate's job is to clear them fast while catching the few that belong in the top two.

Risk-tier gate table: trigger, evidence, owner, outcome

Risk tier (EU AI Act anchor)	Intake trigger	Required evidence	Approval owner	Contract clause set	Outcome
Prohibited (Article 5)	Use case is a banned practice	None — screen is a hard stop	AI governance lead	None	No-go
High-risk (Article 6, Annex III)	Annex III use area, e.g. employment (point 4) or critical infrastructure (point 2)	Technical documentation, conformity evidence, Article 10 data governance	AI governance lead + legal	Full clause set	Conditional / no-go
Limited-risk (Article 50)	AI output reaches third parties	Transparency-disclosure plan	Procurement + product owner	Trimmed set (transparency clause)	Conditional go
Minimal-risk	No third-party output, no Annex III area	Register entry only	Procurement	Standard terms	Go

The four rows match the four tiers above — no fifth path exists, and that is deliberate.

Anchoring each gate to penalty exposure

The gate has teeth because the fines are real. A prohibited-practice breach draws administrative fines up to €35 million or 7% of total worldwide annual turnover, whichever is higher (Article 99(3)). High-risk and most other operator-obligation breaches reach up to €15 million or 3% of total worldwide annual turnover, whichever is higher (Article 99(4)). Supplying incorrect, incomplete or misleading information to authorities draws up to €7.5 million or 1% of total worldwide annual turnover, whichever is higher (Article 99(5)). For SMEs and start-ups, Article 99(6) caps each fine at the lower of the percentage or fixed amount.

The Contractual Clauses to Demand Before Signing

Clauses are demands you place on the vendor — distinct from your own standing obligations as deployer, but the means by which you secure the inputs to meet them. Make the clause set proportionate to tier: high-risk buys carry the full set, lower-risk buys a trimmed one, so the policy stays usable.

Documentation, conformity and instructions-for-use access

Demand the right to obtain and retain the technical documentation, instructions for use, and conformity evidence you need to meet your deployer obligations. You cannot follow instructions you were never given, nor demonstrate conformity on evidence the vendor withholds.

Incident cooperation under Article 73

Require the vendor to cooperate with, and supply information for, serious-incident reporting under Article 73. The reporting timelines are yours to meet, but you cannot report what you cannot see.

Change-notification and the reclassification trap

Demand advance notice of substantial modifications, model swaps, or intended-purpose changes. A vendor's quiet model swap or your own repurposing can push a system into high-risk or trigger an Article 25 provider flip on your side — and without notification, you discover it during an audit, not before.

Audit, logging and post-market information rights

Secure the right to verify ongoing compliance and to receive the information you need for record-keeping and logging (Articles 12 and 19) and post-market monitoring (Article 72). These rights are what make the high-risk obligations operable after go-live rather than theoretical.

Naming the Owner and Wiring the Policy Into the Buying Workflow

A policy nobody owns is a document nobody enforces. Name the owner, name the board, and wire the gate into the workflow that already exists.

The named owner and the standing review board

Name a single accountable owner — typically an AI governance lead or compliance officer — and stand up a review board drawn from procurement, legal and security who clear each gate. The owner holds the register, sets the cadence, and is the person an auditor asks for when a buy goes wrong.

Embedding the gate in the purchase order and access flow

Wire intake into the existing purchasing flow so it cannot be skipped: no AI tool gets a purchase order, a contract signature, or SSO and data access without passing the gate first. The control works because it sits on the rails the money and access already run on.

Register, renewal cadence and shadow-AI control

Maintain a register of every triaged AI buy — including the minimal-risk ones — so the policy doubles as your inventory feed. Set a review cadence: re-run the gate on renewal, on a vendor's substantial modification, and when EU AI Act obligations newly bite. A light, fast minimal-risk path is what keeps teams from routing around the front door.

Worked Example: A 280-Person Fintech Buying an AI Support-Automation Tool

Lumera Pay, a 280-employee EU payments company, is evaluating an AI customer-support copilot that drafts and sends replies to cardholders.

Intake. The intended purpose is customer-support automation — not credit decisions — so the first-pass Article 5 screen is clear. The tool is not Annex III high-risk, because it makes no creditworthiness decisions about natural persons. The realistic duties are Article 50 transparency (cardholders must be told they are interacting with AI) and Article 4 AI literacy for the support staff.

Article 25 watch. The policy flags a risk at intake: if Lumera Pay later repurposes the copilot to score applicants or adjust credit limits, that intended-purpose change could push the system into high-risk and flip Lumera into a provider under Article 25. The change-notification clause and the intake record are what surface that flip before an audit does.

Gate outcome. Limited-risk path, conditional go, contingent on three clauses: a transparency-disclosure clause for the cardholder-facing output, an Article 73 incident-cooperation clause, and change-notification covering model swaps.

Contrast tier. Run the same policy against a hiring-screening tool and the outcome inverts. Candidate screening sits in Annex III point 4(a) (recruitment), so it routes to the high-risk gate with full documentation and conformity evidence required before signing. For the deeper pre-purchase review that high-risk path demands, the policy hands off to the AI due diligence checklist.

When EU AI Act Obligations Bite — Timing the Policy Has to Plan Around

The policy has to timestamp each gate decision against the live deadline.

Already in force. Article 5 prohibitions and Article 4 AI literacy since 2 February 2025; GPAI obligations (Articles 51–55) since 2 August 2025. These constrain buys today.
Landing 2 December 2026. A new CSAM / "nudifier" prohibition, and Article 50 content-marking and watermarking duties for synthetic output — relevant to any generative-AI buy whose output reaches third parties.
High-risk classification. Stand-alone Annex III systems (Article 6(2)) read 2 August 2026 in the statute; product-embedded Annex I systems (Article 6(1)) read 2 August 2027.

The policy should carry one note honestly. The Digital Omnibus was adopted in June 2026 — the European Parliament voted on 16 June 2026 and the Council adopted it on 29 June 2026 — deferring stand-alone high-risk Annex III obligations to 2 December 2027. The deferral is fixed calendar dates (the "stop the clock" variant was rejected), not a blanket delay; not everything moves. Entry into force follows Official Journal publication, expected before 2 August 2026. Plan procurement against the adopted 2 December 2027 deadline for stand-alone high-risk Annex III — a buy made today is covered either way.

How Confir helps

Confir turns this policy into a working gate. Each intake answer maps to the EU AI Act obligation it triggers, the risk tier is assigned against the live deadline, and the required evidence and contract clauses surface before a purchase order can clear. The synthesis engine is deterministic and rule-based — no model inference, no hallucination — so a tier decision is traceable to the Article that produced it, which is what an auditor asks for. The register doubles as your AI inventory feed, and renewal triggers re-run the gate.

Frequently asked questions

What is an AI procurement policy under the EU AI Act?

It is a standing, repeatable rulebook governing how every new AI tool or vendor enters your organisation. It defines the intake questions each buy must answer — intended purpose, Annex III exposure, provider-vs-deployer role, Article 25 flip risk, GPAI dependencies, and data and transparency posture — the approval gate that applies by risk tier, the contract clauses to demand, and the named owner accountable for it. Its job is to keep unmanaged EU AI Act exposure out before a contract is signed, not discover it after go-live.

How is a procurement policy different from a vendor questionnaire or a due diligence checklist?

They operate at three levels. The procurement policy is the governing framework — the standing process that decides which buys get scrutinised and how. The AI due diligence checklist is the one-off review the policy triggers for a specific purchase. The vendor questionnaire is the assessment artefact that review uses to collect answers from the vendor. You need the policy so diligence happens consistently on every buy, not just the ones someone remembers to check.

Which contract clauses should an AI procurement policy require?

For high-risk buys: documentation and conformity-evidence access so the deployer can meet its own duties; an incident-cooperation clause supporting Article 73 reporting timelines; change notification covering substantial modifications, model swaps and intended-purpose changes; and audit and information rights supporting logging (Articles 12 and 19) and post-market monitoring (Article 72). Lower-risk buys carry a trimmed set — at minimum a transparency clause where output reaches third parties under Article 50. Make the clause set proportionate to the risk tier so the policy stays usable.

Does every AI purchase need to go through the full high-risk gate?

No. Most general business AI — support bots, productivity tools, content generation, back-office automation — is not high-risk under the EU AI Act. The realistic duties there are Article 4 AI literacy, Article 50 transparency where AI output reaches third parties, and data governance. A good policy tiers the gate: prohibited practices (Article 5) are an automatic no-go, high-risk buys (Article 6, Annex III) get full diligence, and limited- and minimal-risk buys pass a light, fast gate so teams do not route around the process into shadow AI.

What is the Article 25 provider flip and why does it belong in procurement?

Under Article 25, a deployer, distributor or importer becomes a provider — inheriting the much heavier provider obligations — if it puts its name or trademark on a high-risk system, makes a substantial modification, or changes the intended purpose so a system becomes high-risk. This often happens after purchase, when a team repurposes a tool. The procurement policy flags the flip risk at intake and requires change notification in the contract, so a future repurposing does not silently reclassify your company into a provider.

When do the EU AI Act deadlines that shape procurement actually bite?

Article 5 prohibitions and Article 4 AI literacy have applied since 2 February 2025; GPAI obligations (Articles 51–55) since 2 August 2025. A new CSAM/nudifier prohibition and Article 50 content-marking duties land 2 December 2026. For high-risk stand-alone Annex III systems the statute originally read 2 August 2026; the Digital Omnibus, adopted by Parliament and Council in June 2026, defers that to 2 December 2027, with entry into force pending Official Journal publication, expected before 2 August 2026.

Who should own the AI procurement policy?

A single accountable owner — typically an AI governance lead or compliance officer — supported by a standing review board drawn from procurement, legal and security who clear each gate. The owner maintains the register of triaged buys, sets the renewal and re-review cadence, and ensures no AI tool gets a purchase order, signature or data access without passing the gate. A procurement policy without one named owner becomes decoration that nobody enforces.

Manage your EU AI Act compliance in one place

Confir automates risk classification, technical documentation, and audit trails for any company. No consultants. No 6-month projects. 14-day free trial.

Start free trial →