Your EU AI Act obligations depend on two things: the role you play for each AI system, and the risk tier that system falls into. Most software teams start by asking “are we high-risk?”, but the better first question is “are we the provider or the deployer of this system?”, because that decides whose name goes on the paperwork.
On this page
- Does the EU AI Act apply to software teams outside the EU?
- What’s the difference between a provider and a deployer?
- When does a deployer become a provider?
- Which risk tier is your AI system in?
- What obligations attach to each role?
- What does the Act require for general-purpose AI models?
- What applies now, and what is still to come?
- Where should a software team start?
- When is this not the right approach?
- Frequently asked questions
This post walks through the roles, the risk tiers, what attaches to which, and the dates as they stand in October 2026, including the changes made by the Digital Omnibus on AI. This is not legal advice. Check the official text of Regulation (EU) 2024/1689 and talk to counsel before you rely on any classification.
Does the EU AI Act apply to software teams outside the EU?
Yes, in two common cases. It applies to providers that place AI systems on the EU market or put them into service there, wherever the provider is based. It also applies to providers and deployers outside the EU when the output of their AI system is used in the EU. Location alone doesn’t take you out of scope.
Both rules sit in Article 2(1). For a SaaS company in Sydney, Bangalore or New York with EU customers, the Act is usually relevant to at least part of the product.
What’s the difference between a provider and a deployer?
A provider develops an AI system, or has one developed, and puts it on the market or into service under its own name. A deployer uses an AI system under its own authority in a professional setting. If you sell an AI feature, you’re usually its provider. If you buy one and use it, you’re its deployer.
Four of the operator roles defined in Article 3 matter to most software companies:
| Role | What makes you one | Typical software team example |
|---|---|---|
| Provider | You develop the AI system (or have it built) and put it on the market or into service under your name | You ship a CV-screening feature inside your HR SaaS, built on a third-party LLM |
| Deployer | You use an AI system under your authority, other than for personal non-professional use | Your support team uses a vendor’s AI triage tool on customer tickets |
| Importer | You’re established in the EU and place on the market a system carrying the name of a non-EU company | Your EU subsidiary sells a model-based product built and branded by the parent company in India |
| Distributor | You make a system available on the EU market and you’re neither its provider nor its importer | You resell another vendor’s AI product as part of an implementation package |
Roles are assigned per system, not per company. You can be a provider for what you sell and a deployer for the tools you use.
When does a deployer become a provider?
A deployer, importer or distributor becomes the provider of a high-risk AI system in three cases: they put their own name or trademark on it, they make a substantial modification and it stays high-risk, or they change its intended purpose so that it becomes high-risk. This is the trap most product teams walk into.
These rules are in Article 25. The third case catches teams that point a general chatbot or model at a use listed in Annex III, such as ranking job applicants. You’re then the provider of a high-risk system.
Building on a model API doesn’t make you the model’s provider. The model company is the provider of a general-purpose AI model. You’re the provider of the system built on top.
Which risk tier is your AI system in?
The Act sorts AI systems into four tiers: prohibited practices, high-risk systems, systems with transparency duties, and minimal-risk systems with no specific rules. Most business software lands in the last two. A system is high-risk if it’s a safety component of a regulated product or falls under one of the use cases in Annex III.
| Tier | Examples | What it triggers |
|---|---|---|
| Prohibited | Social scoring, certain manipulative techniques, generating non-consensual intimate imagery | Banned outright |
| High-risk | Annex III areas such as employment, education, credit scoring, critical infrastructure; AI in products like medical devices (Annex I) | The full set of provider and deployer obligations below |
| Transparency | Chatbots, systems that generate synthetic text, images, audio or video, deepfakes | Disclosure and marking duties under Article 50 |
| Minimal | Spam filters, search ranking, most internal analytics | No specific obligations beyond AI literacy |
There’s an important escape hatch. Under Article 6(3), an Annex III system isn’t high-risk if it doesn’t pose a significant risk of harm and only does narrow procedural or preparatory work. You must document that assessment before launch and register the system. A system that profiles people is always high-risk.
What obligations attach to each role?
For high-risk systems, providers carry most of the load: a quality management system, technical documentation, logging, conformity assessment, registration and post-market monitoring. Deployers must use the system as instructed, assign human oversight, keep logs and inform affected people. Importers and distributors mainly check that the provider did its part.
| Role | Main obligations for high-risk systems |
|---|---|
| Provider | Quality management system (Art. 17), technical documentation (Art. 11), automatic logging (Art. 12), conformity assessment (Art. 43), EU declaration of conformity and CE marking, registration in the EU database (Art. 49), post-market monitoring (Art. 72), serious incident reporting (Art. 73). Non-EU providers appoint an authorised representative in the EU (Art. 22). |
| Deployer | Use per the instructions, human oversight by trained staff, relevant input data, monitoring, keeping logs for at least six months, informing workers and affected people (Art. 26). Public bodies and some others also do a fundamental rights impact assessment (Art. 27). |
| Importer | Verify conformity assessment, documentation, CE marking and authorised representative before placing on the market (Art. 23) |
| Distributor | Verify CE marking, declaration of conformity and instructions, and stop supply if non-compliance is suspected (Art. 24) |
Two duties reach beyond high-risk systems. Article 50 transparency rules require providers to tell people they’re interacting with an AI system and to mark synthetic content in a machine-readable way, and require deployers to disclose deepfakes and emotion recognition. Article 4 asks providers and deployers to support AI literacy among their staff. The Digital Omnibus softened that wording, so read the amended text rather than older summaries.
What does the Act require for general-purpose AI models?
Providers of general-purpose AI models must keep technical documentation, give downstream providers enough information to meet their own duties, have a copyright policy and publish a summary of training content. Models with systemic risk carry extra duties. Most software teams aren’t GPAI providers. They’re downstream users of someone else’s model.
These obligations have applied since 2 August 2025. Models already on the market before that date have until 2 August 2027 under Article 111(3). The Commission’s GPAI guidelines say that fine-tuning a model makes you its provider only when the modification uses more than a third of the original training compute. Prompting, retrieval and light fine-tuning don’t come close.
As a downstream team, ask your model vendor for its documentation and keep it on file. You’ll need it if your own system turns out to be high-risk.
What applies now, and what is still to come?
As of October 2026, the prohibitions, AI literacy, GPAI obligations and most transparency rules apply. High-risk rules for Annex III systems now start on 2 December 2027, and for AI in regulated products on 2 August 2028. Those later dates come from the Digital Omnibus on AI, which is adopted and in force.
The Omnibus is Regulation (EU) 2026/1744, published in the Official Journal on 24 July 2026 and in force since 27 July 2026.
| Date | What applies | Status in October 2026 |
|---|---|---|
| 1 August 2024 | The AI Act enters into force | Done |
| 2 February 2025 | Prohibited practices and AI literacy | Applies |
| 2 August 2025 | GPAI model obligations, governance, penalties | Applies |
| 2 August 2026 | General application, including Article 50 transparency; AI Office enforcement powers over GPAI | Applies |
| December 2026 | New prohibition on systems that generate non-consensual intimate imagery or child sexual abuse material, added by the Omnibus | Adopted, not yet applying |
| 2 August 2027 | Deadline for GPAI models placed on the market before 2 August 2025 | Adopted, not yet applying |
| 2 December 2027 | High-risk obligations for Annex III systems | Adopted (moved by the Omnibus) |
| 2 August 2028 | High-risk obligations for AI in products covered by Annex I | Adopted (moved by the Omnibus) |
Some details, such as the grace period for machine-readable marking on generative systems already on the market, are reported differently in different summaries, and the Commission’s article pages haven’t all been updated for the Omnibus yet. Check the consolidated text on EUR-Lex and the Commission’s AI Act page before you plan around a specific date.
Where should a software team start?
Start with an inventory of every AI system you build or use, then assign a role and a risk tier to each one, and write down why. That record is what an auditor, a customer’s procurement team or a regulator will ask for first, and it’s cheap to produce while the system list is short.
- Inventory. List each AI system, its model, owner and data, and whether its output reaches the EU.
- Assign roles. Record your role for each system, and watch for the Article 25 triggers.
- Classify. Check each system against the prohibited practices, Annex I and Annex III. If you rely on the Article 6(3) exception, document the reasoning.
- Fix what applies today. Chatbot disclosures, content marking and AI literacy apply now, and they’re usually small tasks.
- Collect vendor documentation and instructions for use from model and tool vendors.
- Plan for high-risk systems. Once you count the quality management system, testing and conformity assessment, December 2027 is close.
Our post on enterprise AI security covers the engineering controls that sit underneath the documentation.
When is this not the right approach?
If no output of your product reaches the EU, a full AI Act programme is probably wasted effort. A minimal-risk internal tool doesn’t need a high-risk quality management system either. Record the classification and move on.
It’s also worth being clear about what we don’t do. We’re engineers and GRC practitioners, not a law firm. We don’t issue legal opinions on classification, act as your EU authorised representative or work as a notified body. Where a classification is borderline, you need EU counsel, and we’ll say so.
We do the practical side: inventory, classification records, technical documentation, logging and evaluation, mapped to ISO/IEC 42001 or the NIST AI RMF. Our AI governance and security engagements start with a 2–6 week scoping phase, and they sit alongside our wider cybersecurity and GRC services.
Frequently asked questions
Does ISO/IEC 42001 certification prove compliance with the AI Act?
No. ISO/IEC 42001 makes compliance easier to organise and evidence, but it isn’t the law. Under Article 40, only harmonised standards whose references are published in the Official Journal give a presumption of conformity. Check the Commission’s AI Act pages for which, if any, have been published.
Does the AI Act replace the GDPR for AI systems?
No. The GDPR still applies whenever an AI system processes personal data, and the AI Act adds obligations on top. You’ll often run a data protection impact assessment and an AI Act classification for the same system, so do them together.
We’re a non-EU company. Do we need an EU representative?
If you’re the provider of a high-risk AI system and you’re established outside the EU, Article 22 requires you to appoint an authorised representative in the EU before the system goes on the market. GPAI model providers outside the EU have a similar duty. Deployers don’t.
How do the fines work for small companies?
Article 99 sets maximum fines as a fixed amount or a percentage of worldwide annual turnover. For most organisations the higher of the two is the cap. For SMEs and start-ups it’s the lower of the two. National authorities set the actual amount case by case.
