Topic guide

EU AI Act for AI buyers: what you actually have to do

Independent compliance reference from Janus Compliance. Reviewed by Michael K. Onyekwere, CIPP/E. Last reviewed 2026-05-30. Not legal advice.

Share this EU AI Act for AI buyers: what you actually have to do profile:Share on X Bluesky

TL;DR. Most buyers of AI tools sit in the deployer role under the EU AI Act. The high-risk obligations were postponed by the Council/Parliament agreement to 2027-12-02, but the provider transparency obligations, the GPAI obligations on the model maker, and the prohibited-use rules are already in force. Deployer-side obligations turn on the use case, not the vendor — buying Copilot does not exempt the buyer from running their own deployer assessment.

The four roles and where buyers usually land

The Act assigns obligations by role. The same vendor can be a provider in one transaction and a deployer in another, so the role is a per-deployment classification.

Provider. Develops the AI system and places it on the EU market or puts it into service under its own name. OpenAI, Anthropic, Google, Microsoft, Perplexity, and ElevenLabs all sit here for their respective products.
Deployer. Uses an AI system under its own authority in the course of professional activity. This is almost every business buyer.
Importer / Distributor. Brings the system into the EU market or makes it available without modifying it. Resellers and integrators frequently land here.
Affected person. The natural person the AI system's output is used on. Not an obligation-bearer but a rights-holder.

A UK company using ChatGPT Enterprise to triage applicant CVs is a deployer of a high-risk AI system (the use case is hiring, not the tool itself), even though OpenAI is the provider. A UK company using ChatGPT Enterprise to draft marketing emails is a deployer of a non-high-risk use case. Same vendor, same product, different obligations.

The risk tiers and what each one means

The Act stacks obligations by risk tier, with prohibited uses at the top and minimal-risk uses at the bottom.

Prohibited uses (Article 5, in force 2025-02-02)

Eight categories of AI use are banned outright in the EU: subliminal manipulation causing harm, exploitation of vulnerabilities, social scoring by public authorities, predictive policing based purely on profiling, untargeted facial-image scraping, emotion inference in workplace or education (with narrow safety carve-outs), biometric categorisation by protected characteristic, and real-time remote biometric identification in public spaces (with narrow law-enforcement carve-outs).

Buyers should treat the prohibited list as a hard procurement gate. A vendor whose product is sold for any of the eight should not enter the procurement pipeline.

High-risk systems (Annex III, deployer obligations postponed to 2027-12-02)

Annex III lists eight high-risk use case categories:

Biometrics
Critical infrastructure
Education and vocational training
Employment, worker management, access to self-employment
Access to and enjoyment of essential private services and public services
Law enforcement
Migration, asylum, border control
Administration of justice and democratic processes

The 2027-12-02 postponement, agreed in Parliament/Council political agreement and now in force at the time of this review, does not eliminate the obligations. It moves the high-risk deployer-side requirements (data governance, human oversight, technical documentation, post-market monitoring, FRIA where applicable) to 2027-12-02. The provider-side high-risk obligations also moved, but providers placing high-risk systems on the EU market before that date still face the future obligations and most are designing in advance.

Buyers should still classify any in-scope deployment now. The transition window is the cheapest time to build the controls; trying to retrofit them in November 2027 is the expensive path.

General-purpose AI (GPAI) obligations (in force 2025-08-02)

GPAI provider obligations (technical documentation, copyright policy, training-data summary) and the additional obligations for GPAI with systemic risk (model evaluations, adversarial testing, incident reporting) sit on the model maker, not on the buyer. The buyer's interest in the GPAI obligations is indirect: the documentation the GPAI provider publishes is part of what the deployer needs to satisfy its own information obligations downstream.

Transparency obligations (in force 2026-08-02)

Three transparency duties land on providers and deployers in parallel:

AI systems interacting with natural persons have to disclose they are AI (deployer-facing obligation in many B2C deployments).
Synthetic audio, image, video, or text output has to be marked as artificially generated where possible (provider obligation).
Deepfakes have to be labelled (deployer obligation).
Emotion recognition and biometric categorisation systems have to inform the natural person (deployer obligation).

Buyers running customer-facing chatbots, AI-generated voiceovers, or AI-generated marketing imagery should map their deployments against these now.

Minimal-risk systems

Everything else. No specific obligations under the Act, though the buyer's own GDPR, sector-specific, and product-liability obligations continue to apply.

What a deployer assessment actually contains

A deployer-side assessment is the artifact the buyer's compliance owner needs on file before the deployment goes live. It is not a vendor questionnaire — the vendor cannot make this assessment for the buyer.

Use case description. What the staff or app will actually do with the AI system, in plain language.
Risk tier classification. Is the use case prohibited (Article 5), high-risk (Annex III), GPAI-with-systemic-risk-adjacent, transparency-tier, or minimal-risk?
Provider documentation collected. GPAI summary, system documentation, any provider-side risk assessment the vendor publishes.
Data governance. Quality and representativeness of input data, any pre-processing, any human review checkpoints.
Human oversight design. Who reviews outputs, with what authority to override or stop the system, on what cadence.
Logging and post-market monitoring plan. What the deployment logs, who reviews the logs, on what cadence.
Fundamental Rights Impact Assessment (FRIA) where required. Annex III deployments in public administration or essential-service contexts trigger FRIA.
Interaction with GDPR. The Article 35 DPIA and the AI Act assessment are separate artifacts that often share evidence. Run them in parallel, do not collapse them into one document.

Where the six vendors land on the buyer-side read

| Vendor | Provider role (EU) | Buyer-side note | Profile | |---|---|---|---| | OpenAI | GPAI provider; system provider for ChatGPT products | Most ChatGPT-API deployments are deployer-side non-high-risk; HR or education use cases bring high-risk obligations onto the buyer | OpenAI | | Anthropic | GPAI provider; system provider for Claude products | Same deployer-side pattern as OpenAI; consumer claude.ai use needs its own deployer policy because no enterprise contract covers it | Anthropic | | Microsoft 365 Copilot | System provider (Microsoft); Anthropic and OpenAI are subprocessors | Tenant-bound default makes most office-productivity uses minimal-risk; HR Copilot agents move the deployment into high-risk Annex III territory | Microsoft 365 Copilot | | Google Gemini (Workspace) | GPAI provider; system provider for Workspace Gemini | Workspace defaults push retention to the buyer's environment, which simplifies the deployer-side logging obligation | Google Gemini | | Perplexity | System provider for Perplexity products | Search-with-citations use cases sit minimal-risk; regulated-industry deployments require Enterprise tier and a deployer assessment | Perplexity |

ElevenLabs sits separately because voice synthesis triggers the Article 50(4) deepfake labelling obligation on most public-facing uses. The ElevenLabs profile covers the deployer-side specifics.

The procurement workflow under the Act

The version below assumes a UK / EU buyer with a procurement gate and a DPO or compliance owner.

Map the use case. Annex III? Transparency-tier? Minimal-risk? The vendor cannot answer this — only the buyer's description of what staff will do with the system answers it.
Pull the provider's technical documentation. GPAI model card or system documentation depending on the product. Note the version.
Pull the DPA in parallel. The DPA and the AI Act documentation answer different questions but both feed the procurement gate. See DPA for AI vendors.
Decide on FRIA. Public administration, essential services, and law enforcement contexts trigger FRIA. Most private-sector business deployments do not.
Write the deployer assessment. The eight-section structure above. Keep it short — 4-8 pages is realistic.
Design the human oversight checkpoint. Who reviews, with what override authority, on what cadence. Document the answer before go-live, not after.
Set the post-market monitoring cadence. Quarterly log review is the realistic floor for any deployment with personal data; monthly for any high-risk use case.

The 2027-12-02 postponement is not a holiday

The deferral applies to the deployer-side high-risk obligations, not to:

Prohibited uses (Article 5, in force since 2025-02-02)
GPAI provider obligations (in force since 2025-08-02)
Transparency obligations (in force 2026-08-02)
The whole of GDPR, which continues regardless

Buyers running any of the three live tiers now should already have the matching controls in place. Buyers in Annex III territory have a 18-month window to design the controls properly; using the window is cheaper than the alternative.