We only use a vendor's AI tool — does the EU AI Act apply to us?

Almost certainly yes, as a deployer. The Act defines a deployer as any party using an AI system under its own authority in a professional context, and Article 26 places obligations directly on deployers of high-risk systems: follow the provider's instructions for use, assign competent human oversight, monitor operation, keep the logs the system generates, and inform the provider or authority of serious incidents or risks. 'We just bought it' moves you out of the provider column, not out of scope. The deployer duties are lighter than a provider's but they are real and they are yours.

When can a deployer accidentally become a provider?

When you change what the system is. The Act treats a deployer as a provider — inheriting the full provider obligation set — if it puts its name or trademark on a high-risk system already on the market, makes a substantial modification to one, or modifies the intended purpose of a non-high-risk system such that it becomes high-risk. Fine-tuning a model, white-labelling a vendor tool under your own brand, or repurposing a system for a use it was not assessed for are the common triggers. The role is not fixed at purchase; it follows what you actually do with the system.

What is a GPAI provider and do GPAI rules apply to us?

A general-purpose AI model is one trained at scale that can perform a wide range of distinct tasks and be integrated into many downstream systems — the large foundation models. The provider of such a model carries the Chapter V obligations: technical documentation, information for downstream integrators, a copyright policy, and a public summary of training content, with extra systemic-risk duties for the most capable models. If you build on top of someone else's general-purpose model rather than training and placing one on the market yourself, you are a downstream provider or a deployer — not the GPAI provider — but the model provider's documentation is exactly what you need to meet your own duties.

Which EU AI Act dates are actually in force right now?

The Regulation entered into force on 1 August 2024 and applies in staged phases under Article 113. The prohibitions on unacceptable-risk practices and the AI-literacy duty applied from 2 February 2025. The governance and general-purpose-AI provisions applied from 2 August 2025. The bulk of the high-risk regime applies from 2 August 2026, with a later date of 2 August 2027 for high-risk systems that are safety components of products already covered by other EU product legislation. Plan against the date that matches your role and your system's classification, not the headline 2024 entry-into-force.

EU AI Act: your obligations depend on your role, not your tech stack

The first question a compliance team asks about the EU AI Act is usually "is our system high-risk?" That is the wrong first question. The Act does not hand you one obligation list keyed to risk. It hands you a different list depending on which economic role you occupy for a given system — and the same company can be a provider for one system, a deployer for another, and an importer for a third, all in the same week. Get the role wrong and you will either over-build controls you do not owe or, worse, miss the ones you do.

The Regulation — (EU) 2024/1689, in force since 1 August 2024 — defines six operator roles and assigns each a distinct obligation set. This post walks the role test, then the obligations per role with article references, then the "we just use a vendor's model" trap that catches more organisations than any other, and ends with the application dates that are actually in force rather than the headline ones.

The role test comes before the risk test#

An "AI system" under the Act is, roughly, a machine-based system that infers from input how to generate outputs — predictions, content, recommendations, decisions — that influence environments. Once something is in scope, the Act asks who you are to it. The six roles:

Provider — you develop an AI system or a general-purpose AI model, or have one developed, and place it on the market or put it into service under your own name or trademark, whether for payment or free.
Deployer — you use an AI system under your own authority in the course of a professional activity. (Purely personal, non-professional use is excluded.)
Importer — you are established in the EU and place on the market a system bearing the name or trademark of a party established outside the EU.
Distributor — you are in the supply chain, other than provider or importer, and make a system available on the EU market.
Product manufacturer — you place on the market or put into service an AI system together with your product and under your own name, where that product is already covered by EU sectoral product law.
GPAI model provider — you place a general-purpose AI model on the market, the foundation-model case, which the Act treats under its own chapter.

The test is functional, not contractual. A clause in a vendor agreement calling you "the customer" does not make you a deployer if what you actually do is rebrand the system and resell it — that makes you a provider. Run the role test per system, and re-run it whenever you change a system's branding, purpose, or substance.

Provider: the heaviest set#

If you are the provider of a high-risk AI system, you carry the core of the Regulation. The provider-obligations article — Article 16 — enumerates the duties and points to the substantive requirements that sit in the chapter on requirements for high-risk systems (roughly Articles 9 through 15). In practice a provider must:

Establish, document, and maintain a risk-management system that runs across the whole lifecycle (Article 9).
Meet data and data-governance requirements for training, validation, and testing data — relevance, representativeness, error examination, bias scrutiny (Article 10).
Draw up and keep current the technical documentation before the system goes to market (Article 11) and design the system for automatic record-keeping / logging over its lifetime (Article 12).
Build for transparency so deployers can interpret output and use it correctly, including instructions for use (Article 13), and for effective human oversight by the people running it (Article 14).
Achieve appropriate accuracy, robustness, and cybersecurity and declare those levels (Article 15).
Put a quality-management system in place, run the applicable conformity assessment, draw up the EU declaration of conformity, affix CE marking, and register the system in the EU database before placing it on the market.
Operate a post-market monitoring system and report serious incidents to the relevant authority.

That is the full weight, and it is why the provider/deployer line matters so much commercially: providers build a conformity dossier, deployers do not.

For AI systems that are not high-risk but interact with people or generate content, the provider still owes the transparency duties in the Act's transparency article (Article 50): users must be told when they are dealing with an AI system unless it is obvious, and synthetic audio, image, video, or text content must be marked as artificially generated or manipulated in a machine-readable way. A chatbot or a generative tool that is nowhere near "high-risk" can still trip this one.

If you want to test where a specific product or sector arrangement actually lands before you commit engineering, our sample AI Act readiness assessment shows how a system description maps to the article-level obligations that attach to it.

Deployer: lighter, but it still bites#

Here is the trap, stated plainly: "we just use a vendor's AI" does not put you out of scope. It puts you in the deployer column. And the deployer column has its own article — Article 26 — which lays obligations directly on you for high-risk systems. The headline duties:

Use the system per the instructions for use. The provider's instructions are not advisory; deviating from them can shift liability and, in some cases, role.
Assign human oversight to natural persons who have the competence, training, and authority to exercise it, and give them the support to do so (Article 26 read with the provider's human-oversight design under Article 14).
Ensure input data is relevant and sufficiently representative for the system's intended purpose, to the extent you control the input.
Monitor operation against the instructions and, where you have reason to believe use creates a risk or something has gone wrong, suspend use and inform the provider or distributor and the relevant authority.
Keep the logs the system automatically generates, for an appropriate period, where those logs are under your control.
Report serious incidents to the provider and then the importer/distributor and authority.
Cooperate with competent authorities on any action concerning the system.

Two deployer-specific duties deserve a flag because they catch organisations that assumed "we're only the user":

Workplace information. Before putting a high-risk system into use at work, a deployer that is an employer must inform affected workers and their representatives that they will be subject to it.
Fundamental-rights impact assessment (FRIA). Certain deployers — public bodies, and private operators providing public services, plus deployers of specified high-risk use cases such as creditworthiness and certain insurance scoring — must carry out a fundamental-rights impact assessment before deployment, under the Act's FRIA article (Article 27). This is a deployer obligation, not a provider one. If you are a bank deploying a vendor's credit-scoring model, the FRIA is yours to write, not your vendor's.

The deployer set is genuinely lighter than the provider set — no conformity assessment, no CE marking, no quality-management system. But "lighter" is not "none," and the FRIA and the worker-information duty are concrete, dated obligations that land on the party that runs the system, regardless of who built it. If your AI governance programme treats vendor tools as somebody else's compliance problem, Article 26 is the article that will surprise you.

When a deployer becomes a provider#

The role is not frozen at the point of purchase. The Act re-classifies a deployer (or distributor, or importer, or any third party) as a provider — inheriting the full Article 16 set — in three situations:

You put your name or trademark on a high-risk system already placed on the market (white-labelling).
You make a substantial modification to a high-risk system that is already on the market, such that it still qualifies as high-risk.
You modify the intended purpose of a system — including a general-purpose one — that was not high-risk, in a way that makes it high-risk.

Fine-tuning a foundation model for a regulated decision, rebranding a vendor's tool as your own product, or pointing a general-purpose tool at a high-risk use it was never assessed for are the everyday triggers. The practical consequence is severe: you go from owing five or six deployer duties to owing the entire conformity dossier. This is the single most expensive role mistake in the Act, and it is made by accident — usually by a product team that "just fine-tuned" something without realising they had become its provider in the eyes of the Regulation.

Importer and distributor: the gatekeeper checks#

If you bring a non-EU provider's system into the EU market, you are an importer, and your duties (Article 23) are verification duties, not engineering ones. Before placing the system on the market you must check that the provider has carried out the conformity assessment, drawn up the technical documentation, affixed the CE marking, and provided the declaration of conformity and instructions. You must not place a non-conforming system on the market, you keep a copy of the documentation available to authorities, and you ensure storage and transport conditions do not compromise compliance.

A distributor — anyone in the chain making the system available who is neither provider nor importer — owes a related set (Article 24): verify the CE marking, declaration, and instructions are present; not make available a system you know or should know is non-conforming; and act (corrective measures, withdrawal, recall, informing authorities) if you find a problem after the system is on the market. Importer and distributor duties are about checking the paperwork is real and stopping a bad system at the gate, not about building the system.

Product manufacturer: where the AI Act meets product law#

If you place an AI system on the market together with your product and under your own name — the system is a safety component of, or otherwise embedded in, a product already covered by EU sectoral product legislation (machinery, medical devices, and the rest of the Act's listed harmonisation legislation) — you are treated as the provider of that AI system and the AI Act's high-risk obligations are folded into your existing product-conformity route (Article 25). This is also the role tied to the later application date: high-risk systems that are safety components of such products get until 2 August 2027 rather than 2026, because their conformity has to ride on top of an already-complex product regime.

GPAI providers: the foundation-model chapter#

General-purpose AI models — the large foundation models trained at scale that can be adapted to many downstream tasks — get their own chapter (Chapter V). A provider of a GPAI model must (Articles 53–55):

Draw up and keep current technical documentation of the model, including its training and testing process.
Provide information and documentation to downstream providers who integrate the model into their own AI systems, so those parties can meet their obligations.
Put in place a policy to comply with EU copyright law, including respecting rights reservations expressed under the text-and-data-mining rules.
Publish a sufficiently detailed summary of the content used to train the model, following the template from the AI Office.

For models classed as carrying systemic risk (assessed against capability thresholds), the provider takes on additional duties: model evaluation including adversarial testing, assessment and mitigation of systemic risks, serious-incident tracking and reporting, and an adequate cybersecurity posture for the model and its physical infrastructure.

The asymmetry to understand: if you build a product on top of someone else's general-purpose model, you are not the GPAI provider — you are a downstream provider or a deployer of the system you build. But the GPAI provider's documentation under Article 53 is precisely the input you need to discharge your own duties. When you procure a foundation model, the documentation package is part of what you are buying, and its absence is a compliance gap you inherit.

The application dates that are actually in force#

The headline "EU AI Act entered into force in 2024" is true and almost useless for planning. The staged dates in Article 113 are what bind you:

1 August 2024 — entry into force.
2 February 2025 — the prohibitions on unacceptable-risk AI practices apply, and the AI-literacy duty (ensuring staff who deal with AI systems have a sufficient level of competence) applies.
2 August 2025 — the governance provisions and the general-purpose-AI model obligations (Chapter V) apply.
2 August 2026 — the general application date, including the bulk of the high-risk regime.
2 August 2027 — high-risk systems that are safety components of products already covered by other EU harmonisation legislation (the product-manufacturer case above).

Use the date that matches your role and classification. A deployer of a high-risk system in a non-product context plans against August 2026; a GPAI provider was already in scope from August 2025; a product manufacturer embedding AI in regulated hardware has until August 2027 for that specific path. Treating all of it as "2026" either rushes work that has a longer runway or, far more dangerously, lets a GPAI or prohibited-practice obligation that is already live sit unaddressed.

How we ground this, and why it matters here#

Every article reference in this post is the kind of claim that has to survive an auditor or a regulator, which is exactly the case where a confidently-worded but wrong citation is worse than no citation. The way we work compliance questions through the gateway is not "ask a model what Article 26 says" — it is to call typed corpus tools through the gateway against the EU regulations corpus (98 instruments, 5,008 provisions) and validate each citation deterministically before it ships. A claim that cannot be grounded gets marked unresolved rather than dressed up with an invented number.

That discipline is the difference between a readiness assessment you can hand to a board and a chat transcript you have to re-check by hand. If you want the article-level obligation map for a specific system rather than the general picture in this post, the AI Act readiness and gap analysis workflows take a system description and return the obligations that attach to your role, each with a validated citation. See /how-it-works for the split between your AI client doing the reasoning and the gateway supplying the grounded law, and /coverage for the corpora the EU AI Act analysis draws on.

The single decision that determines most of your obligation set is the one most teams skip: which role are you, for this system, today. Get that right first. The risk classification, the article list, and the date you are working towards all fall out of it — and the "we just use a vendor's AI" answer, comfortable as it sounds, is itself a role answer with its own list of things you owe.