EU AI Act compliance for SaaS: what UK teams must do now

An EU customer's procurement questionnaire has a new line: "State the EU AI Act risk classification of each AI feature in your product." Your team ships a support chatbot, an AI writing assistant and a candidate-ranking feature, and nobody owns the answer. The deal waits while you work it out.

EU AI Act compliance for a SaaS firm starts with an inventory of every AI feature, your role for each one (provider or deployer) and its risk tier. Since 2 August 2026 the Article 50 transparency rules apply, so a chatbot must tell people it is AI and generated content must be machine-detectable. The high-risk rules for Annex III uses follow on 2 December 2027.

This guide is for founders, CTOs and COOs of UK B2B SaaS firms selling to EU or regulated customers. It gives you a feature-by-feature routine, the duties that already apply, and the evidence enterprise buyers ask for.

What does EU AI Act compliance mean for a SaaS firm?

EU AI Act compliance for a SaaS firm means knowing, for every AI feature, which role you hold, which risk tier the feature sits in and which duties follow. The duties attach to the feature and its intended purpose, not to your company as a whole, so one product can carry several different sets of obligations.

For what the Act is, who it reaches and how the UK fits in, start with our EU AI Act overview. This guide assumes the Act applies to you, because you place AI features on the EU market or your EU customers use them, and moves straight to the work.

The routine has five steps:

1. List every AI feature, including those built on a third-party model.
2. Decide your role for each feature.
3. Sort each feature into a tier.
4. Ship the duties that apply now.
5. Prepare the evidence your EU customers will ask for.

A product does not have a risk tier. Each feature does.

Are you the provider or the deployer of each AI feature?

You are the provider of an AI feature when you build it, or have it built, and sell it under your own name or trademark. You are a deployer when you use an AI system under your authority, such as a tool your support team runs. A SaaS firm is usually the provider of the AI features it sells.

The definitions sit in Article 3 of Regulation (EU) 2024/1689. A provider is a person or body that "develops an AI system or a general-purpose AI model or that has an AI system or a general-purpose AI model developed and places it on the market or puts the AI system into service under its own name or trademark". A deployer is a person or body "using an AI system under its authority".

Why does building on a third-party model still make you a provider?

Building on a third-party general-purpose AI model does not pass your duties to the model vendor. The vendor provides the model. You provide the AI system you build on it and sell under your brand: the chatbot, the drafting assistant, the scoring feature. The Act treats the model and the system as separate things, with separate providers.

That is why the model vendor's documentation answers questions about the model, not about your feature. Your EU customer is buying your feature, and the questionnaire is addressed to you.

The model vendor's compliance is not your compliance.

When does Article 25 make you the provider of someone else's system?

Under Article 25, a distributor, importer, deployer or other third party becomes the provider of a high-risk AI system in three cases. You put your name or trademark on it. You make a substantial modification so it stays high-risk. Or you change the intended purpose of a non-high-risk system, including a general-purpose AI system, so that it becomes high-risk.

The third case is the one SaaS teams meet. Wrapping a general-purpose system in a feature that ranks job applicants changes its intended purpose into an Annex III use, and you take on the provider's obligations under Article 16.

Regulation (EU) 2026/1744, the AI Omnibus, rewrote Article 25(2) to list what the initial provider must hand over to you. That list covers technical documentation, known limitations and failure modes, and targeted technical access for testing. The amended Article 25(4) adds AI models to the suppliers who must set this out in a written agreement. The handover duty does not apply where the initial provider has clearly said its system is not to be turned into a high-risk system, so check the vendor's terms first. Then put the clause in your model vendor contract before you build the feature.

How do you sort each AI feature into a risk tier?

Sort each feature against three tests in order. First, does it fall under an Article 5 prohibition? Second, does it match an Annex III high-risk use? Third, if it does, does the Article 6(3) exemption apply, with a documented assessment? Anything left is minimal risk, though the Article 50 transparency duties may still apply.

The first test catches little in B2B SaaS, but check it. Article 5 already bans systems that infer the emotions of people in the workplace and in education, except for medical or safety reasons. From 2 December 2026 the AI Omnibus adds bans on systems that generate non-consensual intimate images of identifiable people or child sexual abuse material.

The second test matters most for SaaS firms selling to regulated buyers. Three Annex III uses are the ones to check first:

• Employment (point 4). Recruiting and selecting people, including filtering applications and evaluating candidates, and systems that decide promotion or termination, allocate tasks or monitor and evaluate performance.
• Creditworthiness (point 5(b)). Evaluating the creditworthiness of individuals or setting their credit score. Systems used to detect financial fraud are excluded.
• Life and health insurance (point 5(c)). Risk assessment and pricing for individuals in life and health insurance.

The third test is the Article 6(3) exemption. An Annex III system is not high-risk when it poses no significant risk of harm to health, safety or fundamental rights. One of four conditions must apply: a narrow procedural task, improving a completed human activity, detecting patterns without replacing human assessment, or a preparatory task. An Annex III system that profiles individuals is always high-risk.

An exemption you have not written down is an exemption you cannot show. Article 6(4) requires a provider relying on it to document its assessment before the system is placed on the market, and to register the system in the EU database under Article 49(2). The Omnibus simplified that registration content but kept the duty.

A worked triage for a typical SaaS product looks like this:

Your own answers depend on each feature's intended purpose, so treat the table as a pattern, not a verdict. The Commission calls the Article 50 tier "transparency risk". A questionnaire that asks about "limited risk" means the same tier, and the Regulation defines neither label. The Commission's AI Act Service Desk compliance checker, still in beta, is a useful first pass on each feature.

What do the EU AI Act Article 50 transparency obligations require now?

Article 50 applies from 2 August 2026. Providers must design chatbots so people know they are dealing with AI, unless that is obvious, and must mark synthetic audio, image, video and text in a machine-readable, detectable way. Deployers must disclose deepfakes, and AI-generated text published to inform the public unless it had human editorial review.

The four duties a SaaS team checks are:

1. Article 50(1), providers. An AI system that interacts directly with people tells them so, unless it is obvious to a reasonably well-informed person in context.
2. Article 50(2), providers. Systems that generate synthetic audio, image, video or text mark their outputs in a machine-readable format, detectable as AI-generated. Assistive editing that does not substantially alter the input is exempt.
3. Article 50(3), deployers. People exposed to emotion recognition or biometric categorisation are told.
4. Article 50(4), deployers. Deepfakes are disclosed, and so is AI-generated text published to inform the public on matters of public interest, unless it had human review or editorial control and someone holds editorial responsibility for publishing it.

Article 50(5) sets the timing: the information must reach people "at the latest at the time of the first interaction or exposure". The Commission published guidelines on the Article 50 transparency obligations on 20 July 2026, and they are the reference for how to meet each duty.

There is one transition. Under a new Article 111(4) added by the Omnibus, providers of generative systems placed on the market before 2 August 2026 have until 2 December 2026 to comply with Article 50(2). A feature launched after 2 August 2026 gets no grace period. The chatbot disclosure in Article 50(1) has no transition either.

One line on AI literacy: the Omnibus replaced Article 4, so providers and deployers now "take measures to support the development of AI literacy" of their staff, with no guaranteed level. Your staff's own use of AI tools is a separate governance job.

What do EU enterprise customers need from you as a provider?

An EU customer deploying your high-risk feature has its own duties under Article 26, and it can only meet them with information from you. Expect requests for instructions for use, human oversight guidance, log retention support and the material for its data protection impact assessment. Answer them once, in a pack you can reuse.

Article 26 requires deployers of high-risk systems to use them in line with the instructions for use and to assign human oversight to competent people. They must also keep the logs under their control for at least six months and inform workers before using a high-risk system at work. Where a data protection impact assessment is needed, they must use your Article 13 information in their GDPR data protection impact assessment. Lenders and life or health insurers using a point 5(b) or 5(c) system must also run a fundamental rights impact assessment under Article 27.

Article 13 sets what your instructions for use must contain, starting with your identity and contact details and the system's characteristics, capabilities and limitations. We recommend building one AI Act pack for each feature:

• the feature's intended purpose, role and tier, with the reasoning;
• the Article 6(3) assessment, where you rely on it;
• instructions for use, including limitations and human oversight measures;
• how logs are generated and how customers retain them;
• your Article 50 disclosure and marking approach;
• the model supplier and the written agreement behind it.

Then answer each questionnaire line from the pack, not from memory. Our guide to security questionnaires shows how to build an answer library that stays true over time.

The firm that answers the AI Act question in one email wins the deal the others are still scoping.

Do you need an EU authorised representative?

A UK provider of a high-risk AI system needs an EU authorised representative. Article 22 requires providers established in third countries to appoint one by written mandate before making a high-risk system available on the EU market. The representative must be established in the EU and acts for you under that mandate.

The mandate must let the representative verify that the declaration of conformity and technical documentation exist. The representative also keeps your contact details, the declaration and the documentation available to authorities for 10 years after the system is placed on the market. Plan the appointment alongside the Annex III work, not after it. Features that carry only Article 50 duties, such as a chatbot, do not trigger the Article 22 duty.

What fines apply to SMEs and small mid-caps after the AI Omnibus?

The Article 50 transparency duties, the provider obligations in Article 16 and the deployer duties in Article 26 share one fine tier. A breach can cost up to EUR 15 million or 3% of worldwide annual turnover. For SMEs, including start-ups, and now small mid-caps, the cap is whichever figure is lower; for larger firms it is the higher.

Article 99(6) already gave SMEs the lower cap. The Omnibus added Article 99(6a), which extends it to small mid-cap enterprises for fines under Article 99(4) and (5). It also added the Article 25(2) and (4) value-chain duties to the list of breaches that Article 99(4) covers. Member States must take the economic viability of SMEs and small mid-caps into account when setting penalties. The full penalty tiers sit on our EU AI Act overview.

The Omnibus also lets SMEs and small mid-caps file the Annex IV technical documentation for high-risk systems in a simplified form, using a form the Commission is to establish.

Which EU AI Act dates does a SaaS team act on?

A SaaS team acts on five dates. The AI Omnibus took effect on 27 July 2026, and the Article 50 transparency rules applied from 2 August 2026. The Article 50(2) transition and new bans follow on 2 December 2026, Annex III high-risk rules on 2 December 2027 and Annex I product rules on 2 August 2028.

Each date is taken from the Omnibus text (its entry-into-force clause, Article 113 as amended and the new Article 111(4)) and matches the AI Act Service Desk timeline. The Article 5 prohibitions and the AI literacy duty have applied since 2 February 2025.

How do you keep EU AI Act compliance running?

Keep EU AI Act compliance running by treating the feature list as a living register. Each new AI feature, new model or new intended purpose triggers the role and tier check again, before release. A named owner signs off each entry, and the AI Act pack for each feature is updated in the same change.

ISO/IEC 42001 is the AI management system standard that carries this work as a repeatable cycle of inventory, risk assessment, controls and review.

Ownership matters more than tooling. Our view on why every AI system needs a named accountable owner applies here: a register nobody owns goes stale by the second release.

What are the most common EU AI Act compliance mistakes?

The three most common mistakes are treating the model vendor's compliance as your own, assuming the AI Omnibus delayed everything, and classifying the product instead of each feature. Each one leaves a gap that an EU customer's procurement team will find before a regulator does.

• Treating the model vendor's compliance as yours. The vendor answers for the model. You answer for the feature you built and sell, and for Article 50 on that feature.
• Assuming the Omnibus delayed everything. It moved the high-risk dates. Article 50 applied on 2 August 2026 as planned, and only generative features already on the market got until 2 December 2026.
• Classifying the product, not the feature. One risk label for a whole product that also ranks job applicants is a wrong answer in a questionnaire, and a costly one later.

Frequently asked questions