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-10-15. Not legal advice.

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

TL;DR. A business that uses an AI tool under its own authority is a deployer under the EU AI Act (Article 3(4)), although a buyer that puts a general-purpose system to a high-risk use can become its provider (Article 25(1)(c)). Regulation (EU) 2026/1744 (the Digital Omnibus), in force since 27 July 2026, fixed the high-risk dates at 2 December 2027 for Annex III uses and 2 August 2028 for Annex I products. The prohibitions have applied since 2 February 2025, and two added prohibitions apply from 2 December 2026. The obligations on GPAI model makers have applied since 2 August 2025. The Article 50 transparency duties have applied since 2 August 2026, and generative systems already on the market by then have until 2 December 2026 to mark their output. Deployer obligations depend on the use case rather than the vendor, so buying Copilot does not exempt the buyer from running its own deployer assessment.

The roles and which one a buyer takes

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. The Act defines six operator roles (Article 3(8)): provider, product manufacturer, deployer, authorised representative, importer and distributor. Those that matter most to buyers are below.

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 fall here for their respective products.
Deployer. Uses an AI system under its own authority, other than in the course of a personal non-professional activity (Article 3(4)). A business buyer using a vendor's AI tool is in this role.
Importer / Distributor. An importer is located or established in the EU and places on the market a system that bears the name or trademark of a person established outside the EU (Article 3(6)). A distributor is any other person in the supply chain, apart from the provider and the importer, that makes a system available on the EU market (Article 3(7)). An integrator that sells a system under its own name, or changes a system's intended purpose so that it becomes high-risk, is a provider (Articles 3(3) and 25).
Affected person. The natural person the AI system's output is used on. This is not an operator role: affected persons hold rights under the Act and carry no obligations under it.

A company that uses ChatGPT Enterprise to filter CVs for roles in the EU is putting a general-purpose system to an Annex III use (point 4(a)). Under Article 25(1)(c), a deployer that changes the intended purpose of a system, including a general-purpose system, so that it becomes high-risk is treated as the provider of a high-risk system, with the provider obligations in Article 16, and the company should assess whether that has happened. Where it has, OpenAI is no longer treated as the provider of that specific system (Article 25(2), as amended). Article 25 applies to Annex III systems from 2 December 2027. A UK company is caught where the output is used in the EU (Article 2(1)(c)). A UK company using ChatGPT Enterprise to draft marketing emails is a deployer, and the use is not high-risk. The vendor and the product are the same in both cases; the obligations differ because the use differs.

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, applying since 2 February 2025)

Article 5 has prohibited eight practices since 2 February 2025 (Article 113, third paragraph, point (a); a fixed date):

subliminal, purposefully manipulative or deceptive techniques that materially distort a person's behaviour and cause, or are reasonably likely to cause, significant harm (point (a));
exploiting the vulnerabilities of a person or group due to age, disability or a specific social or economic situation, with the objective or effect of materially distorting their behaviour in a way that causes, or is reasonably likely to cause, significant harm (point (b));
social scoring by any public or private body that leads to detrimental treatment in unrelated contexts, or to treatment that is unjustified or disproportionate (point (c));
assessing the risk that a person will commit a criminal offence based solely on profiling or on personality traits (point (d));
creating or expanding facial recognition databases through untargeted scraping of facial images from the internet or CCTV footage (point (e));
inferring emotions in the workplace or in education, except for medical or safety reasons (point (f));
biometric categorisation to deduce or infer race, political opinions, trade union membership, religious or philosophical beliefs, sex life or sexual orientation (point (g));
using real-time remote biometric identification in publicly accessible spaces for law enforcement, except where strictly necessary for one of three listed objectives and authorised (point (h)). Remote biometric identification outside law enforcement is not prohibited by Article 5; Annex III, point 1(a), lists it as a high-risk use.

Regulation (EU) 2026/1744 adds two prohibitions that apply from 2 December 2026 (Article 113, third paragraph, point (a), as amended; a fixed date). Point (ba) covers AI systems that generate or manipulate realistic images, video, audio or similar material of an identifiable person's intimate parts, or of an identifiable person engaged in sexually explicit activities, without that person's explicit consent. Point (bb) covers AI systems that generate or manipulate child sexual abuse material within the meaning of Article 2, points (c) and (e), of Directive 2011/93/EU, except where a "without right" defence applies under national law. Placing such a system on the market or putting it into service is prohibited where that generation is its intended purpose, or where the system's design, training, architecture, capabilities or user-facing functions make it a reasonably foreseeable and reproducible outcome, without requiring significant technical modification, and the system lacks reasonable and adequate safeguards to prevent it reliably. Using it is prohibited where the deployer uses the system for that purpose (Article 5(1a)).

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

High-risk systems (Annex III from 2 December 2027; Annex I from 2 August 2028)

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

Regulation (EU) 2026/1744 (the Digital Omnibus) entered into force on 27 July 2026. It amended Article 113 so that the high-risk rules in Chapter III, Sections 1 to 3, apply from 2 December 2027 for systems classified as high-risk under Article 6(2) and Annex III, and from 2 August 2028 for systems classified as high-risk under Article 6(1) and Annex I (Article 113, third paragraph, point (c), as amended). Both dates are fixed and do not depend on the availability of standards.

An Annex III system is not high-risk where it does not pose a significant risk of harm to health, safety or fundamental rights and meets one of the conditions in Article 6(3). An Annex III system that profiles people is always high-risk (Article 6(3), last subparagraph). A provider relying on this exception must document its assessment and register the system (Articles 6(4) and 49(2)).

From 2 December 2027, deployers of Annex III systems must, under Articles 26 and 27:

use the system in accordance with its instructions for use;
assign human oversight to people with the necessary competence, training and authority;
make sure that input data under their control is relevant and sufficiently representative;
monitor the system's operation, and inform the provider and the authorities of risks and serious incidents;
keep the logs under their control for at least six months;
inform workers and their representatives before using the system at work, and inform people that they are subject to the system where it makes or assists decisions about them;
carry out a fundamental rights impact assessment (FRIA) where Article 27 applies.

Data governance, technical documentation and post-market monitoring are provider obligations (Articles 10, 11 and 72).

A high-risk system placed on the market or put into service before its Chapter III date is caught only if its design changes significantly after that date (Article 111(2), as amended). Even without such changes, those earlier systems, where intended for use by public authorities, must comply by 2 August 2030 (a fixed date).

Buyers should still classify any in-scope deployment now, because building the controls during the transition period is easier than retrofitting them in late 2027.

General-purpose AI (GPAI) obligations (applying since 2 August 2025)

The obligations on providers of general-purpose AI models have applied since 2 August 2025 (Article 113, third paragraph, point (b); a fixed date). Models placed on the market before that date must comply by 2 August 2027 (Article 111(3); a fixed date that the Omnibus did not change). The Commission's power to fine GPAI providers (Article 101) applies from 2 August 2026. Providers must keep technical documentation, give documentation to providers that integrate the model into their own systems, keep a copyright policy and publish a summary of the training content (Article 53(1)). Providers of models with systemic risk must also evaluate and adversarially test the model, assess and mitigate systemic risks, report serious incidents and maintain cybersecurity (Article 55(1)).

These obligations fall on the model maker rather than the buyer. The buyer's interest is indirect: the documentation a GPAI provider must give to providers that integrate its model (Article 53(1)(b)) matters to a buyer that builds its own system on the model.

Transparency obligations (Article 50, applying since 2 August 2026)

Article 50 has applied since 2 August 2026, the Act's general date of application (Article 113; a fixed date). It sets five duties:

Providers must design AI systems that interact directly with people so that the people are informed they are interacting with AI, unless that is obvious (Article 50(1)).
Providers of systems that generate synthetic audio, image, video or text must mark the output in a machine-readable format so that it is detectable as artificially generated (Article 50(2)). Systems placed on the market before 2 August 2026 have until 2 December 2026 to comply (Article 111(4), inserted by Regulation (EU) 2026/1744; a fixed date).
Deployers of emotion recognition or biometric categorisation systems must inform the people exposed to them (Article 50(3)).
Deployers must disclose deep fakes. For evidently artistic, creative, satirical or fictional works, the duty is limited to disclosing that generated content exists, in a way that does not hamper the work (Article 50(4), first subparagraph).
Deployers must disclose AI-generated or manipulated text published to inform the public on matters of public interest, unless it has been through human review or editorial control and someone holds editorial responsibility for it (Article 50(4), second subparagraph).

The information must be given clearly, at the latest at the first interaction or exposure (Article 50(5)). Buyers running customer-facing chatbots, AI-generated voiceovers, or AI-generated marketing imagery should map their deployments against these now.

Minimal-risk systems

Systems outside the categories above carry no obligations specific to their tier. Article 4 on AI literacy applies to every provider and deployer, whatever the risk. It has applied since 2 February 2025, and since 27 July 2026 (as replaced by Regulation (EU) 2026/1744) it requires providers and deployers to take measures to support the AI literacy of their staff and others operating AI systems on their behalf, without guaranteeing any particular level. 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 prohibited (Article 5), high-risk (Annex III or Annex I), subject to an Article 50 transparency duty, or minimal-risk? For an Annex III use, does an Article 6(3) condition apply, and does the system profile people (in which case it is always high-risk)? Has the buyer changed the intended purpose of a general-purpose system so that it becomes the provider (Article 25(1)(c))?
Provider documentation collected. GPAI summary, system documentation, any provider-side risk assessment the vendor publishes.
Input data. Where the buyer controls the input data, whether it is relevant and sufficiently representative for the intended purpose (Article 26(4), for high-risk systems), 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.
Monitoring and logs. Monitor the system's operation against the instructions for use, report risks and serious incidents, and keep logs for at least six months (Article 26(5) and (6), for high-risk systems). Post-market monitoring is the provider's system (Article 72).
Fundamental Rights Impact Assessment (FRIA) where required. A FRIA is required before an Annex III system is deployed by a body governed by public law or by a private entity providing public services. It is also required of any deployer of a creditworthiness or credit-scoring system, or of a risk-assessment and pricing system for life and health insurance (Annex III, point 5(b) and (c)). Systems for critical infrastructure (Annex III, point 2) are excluded (Article 27(1)). The duty applies from 2 December 2027 (a fixed date).
Interaction with GDPR. The Article 35 DPIA and the AI Act assessment answer different questions and often share evidence. Article 27(4), as amended by Regulation (EU) 2026/1744, allows a FRIA (required from 2 December 2027) to cross-refer to the relevant sections of the DPIA or to include parts of it. Keep the two analyses distinct, but reuse the DPIA evidence.

How each profiled vendor is classified

The table follows each vendor's CompanyScope profile.

| Vendor | Provider role (EU) | Buyer-side note | Profile | |---|---|---|---| | OpenAI | GPAI provider; system provider for ChatGPT products | A buyer whose staff use ChatGPT is a deployer; a buyer that builds its own system on the API and puts it into service under its own name is that system's provider and a downstream provider (Articles 3(3) and 3(68)). HR or education uses bring high-risk obligations, and putting ChatGPT or the API to an Annex III use can make the buyer the provider of a high-risk system (Article 25(1)(c)) | 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. OpenAI and Anthropic are the GPAI providers of the models behind it. Mistral and SpaceXAI models, available in Copilot Studio (and, for SpaceXAI, Copilot Cowork), fall outside Microsoft's Product Terms and DPA | Drafting, summarising and searching office content are not Annex III uses. Configuring Copilot or a Copilot Studio agent for recruitment, promotion, termination or performance monitoring is an Annex III use, which can make the buyer the provider of a high-risk system (Article 25(1)(c)), with obligations from 2 December 2027 | Microsoft 365 Copilot | | Google Gemini (Workspace) | GPAI provider; system provider for Workspace Gemini | Risk depends on the use case. An Annex III use, such as recruitment, carries the high-risk obligations from 2 December 2027 whichever model is used, and can make the buyer the provider (Article 25(1)(c)) | Google Gemini | | Perplexity | System provider for Perplexity products | Search with citations is not an Annex III use. As provider, Perplexity carries the Article 50(1) and (2) duties, and its profile places typical search use at minimal or limited risk. Choosing the Enterprise tier is a contractual and data-protection decision rather than an AI Act requirement | Perplexity | | ElevenLabs | System provider for its voice products (text to speech, voice cloning, ElevenAgents); carries the Article 50(2) marking duty, and Article 50(1) for ElevenAgents | Buyers must disclose any output that is a deep fake, such as a clone of a real person's voice presented as authentic (Article 50(4)). A voice agent used for an Annex III purpose, such as recruitment screening, is high-risk unless an Article 6(3) condition applies, and always high-risk if it profiles people (Article 6(3), last subparagraph) | ElevenLabs |

The Meta Business Agent profile covers that product's UK GDPR questions and does not classify it under the AI Act.

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. Prohibited? 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. A FRIA is required where a body governed by public law or a private entity providing public services deploys an Annex III system (other than for critical infrastructure), and for any deployer of a creditworthiness or life and health insurance pricing system. Other private-sector deployments do not need one.
Write the deployer assessment. The eight-section structure above. CompanyScope's suggestion is to keep it to 4 to 8 pages.
Design the human oversight checkpoint. Who reviews, with what override authority, on what cadence. Document the answer before go-live, not after.
Set the monitoring cadence. The Act requires deployers of high-risk systems to keep logs for at least six months (Article 26(6)) but does not set a review frequency. CompanyScope suggests quarterly log review for any deployment involving personal data, and monthly review for any high-risk use.

What the postponement does not cover

The deferral covers Chapter III, Sections 1 to 3, for both providers and deployers: from 2 December 2027 for Annex III systems and from 2 August 2028 for Annex I systems (both fixed). It does not cover:

Article 4 on AI literacy, as replaced from 27 July 2026
Article 5, which has applied since 2 February 2025, with points (ba) and (bb) applying from 2 December 2026
the GPAI model obligations, which have applied since 2 August 2025, with models already on the market given until 2 August 2027
Article 50, which has applied since 2 August 2026, with until 2 December 2026 to meet Article 50(2) for generative systems already on the market
the GDPR, which continues to apply in full

Buyers whose deployments fall under these provisions need the matching controls in place by the dates above. Buyers with Annex III uses have until 2 December 2027 to put the high-risk controls in place.