AI and regulation

EU AI Act SaaS compliance: transparency now, high-risk later than you think

2026-05-26 · 6 min read · ACloud.Solutions

Your product summarises support tickets using a third-party model. A customer's procurement team has asked how you comply with the EU AI Act. Somebody has forwarded you an article about high-risk systems and conformity assessments, and it is forty pages of obligations that appear to require a quality management system.

Almost none of that applies to you, and the parts that do have been in force since August. Eu ai act saas compliance for a small B2B software company is mostly a much smaller job than the coverage suggests, and it is more urgent, which is an awkward combination.

What eu ai act saas compliance requires today

The dates that matter, from the Commission's own implementation timeline:

Note the ordering. Transparency is already live. High-risk is over a year away for standalone systems and nearly two for embedded ones.

That is not the original schedule. High-risk obligations for Annex III systems were due on 2 August 2026 and were deferred by the Digital Omnibus on AI, adopted as Regulation (EU) 2026/1744, which entered into force on 27 July 2026. The Commission's announcement describes it as targeted simplification, and alongside the deferral it expanded regulatory sandboxes, simplified obligations for small and mid-cap companies, and streamlined registration for exempted systems.

The mechanism matters as much as the dates. The timeline was changed by a regulation amending the original regulation, which means it can be changed again. Treat any date here as current rather than settled, and check the timeline page before making a commercial commitment on the strength of it.

Which obligations you are actually under

This is where most reading goes wrong, because the Act imposes different duties on different roles and the words are specific.

Provider means you develop an AI system and put it on the market under your own name. If your product has an AI feature that your customers use, you are probably a provider of that AI system, even though the model underneath is somebody else's.

Deployer means you use an AI system in your own operations. If your support team uses a third-party AI tool internally, you are a deployer of it.

You are frequently both, in different directions, and the obligations differ.

The one worth correcting explicitly: Article 26 covers deployers of high-risk systems, so it tracks the high-risk timeline rather than applying now. A lot of commentary implies deployer obligations are live for everybody. For a non-high-risk system they largely are not, and the duties that do apply to you today are the transparency and literacy ones below.

Article 50, which is live and probably applies

Article 50 covers transparency, and it is the obligation most likely to touch a B2B SaaS product. In broad terms it requires that people are told when they are interacting with an AI system, and that certain generated or manipulated content is disclosed or marked as such.

For a typical product that means three practical things.

If a user talks to a chatbot or an assistant, it should be evident that it is an AI system rather than a person. In practice this is a label, not a legal notice.

If your product generates content that a person might take for human-authored or authentic, that needs to be disclosed. The marking and detection requirements have transitional arrangements for systems that were already on the market, and the detail there is worth reading in the text rather than taking from a summary, including this one.

If you use AI for emotion recognition or biometric categorisation, there are specific and stricter duties. Most B2B SaaS does not, and if you do, this note is not sufficient.

Article 4 covers AI literacy, and it applies to providers and deployers now. The Omnibus amended it: the Commission's AI literacy questions and answers states that literacy remains an obligation for providers and deployers but no specific sufficient level is mandated, while for deployers of high-risk systems the obligation to train staff for human oversight remains. So the duty is real and the bar is not numerically defined, which in practice means doing something deliberate and recording it.

What to do, in about a day

Five things, none of which require a lawyer to start.

Build an inventory. Every feature that uses AI, the model, the provider, what data goes to it, the purpose, and who uses it. This is the artefact everything else hangs off and it is a separate note because it is the piece of work that actually takes time.

Classify each entry. Prohibited, high-risk, limited-risk with transparency duties, or minimal. Most B2B SaaS features land in the third or fourth category. Write down the reasoning, because the reasoning is the thing you will be asked for.

Fix the transparency gaps. Where a user interacts with an AI system and it is not obvious, make it obvious. This is usually a label and a line in the documentation.

Do something about literacy and record it. A short internal session on what the tools are, what data must not go into them, and who to ask. Dated, with an attendance list.

Check the supplier side. Your model provider is a supplier processing your data, which makes this a supplier assessment and a data processing question rather than a novel one.

What ISO 27001 already covers

If you hold ISO 27001, a good deal of this exists under different labels.

Your asset register becomes the basis for the AI system inventory. Your supplier assessments cover the model providers. Your risk register can take AI-specific risks as new entries rather than needing a parallel process. Your change management covers releasing a feature that calls a model. Your data flow documentation covers what leaves your estate.

What is genuinely new is the classification exercise and the transparency obligations. Everything else is re-labelling, which is the useful thing to know before somebody proposes buying an AI governance platform.

If you do not hold ISO 27001, doing the inventory and the supplier assessments now is not wasted work, because it is the same material certification will ask for.

Questions

Does the AI Act apply to a UK company?

It can. The Act has extraterritorial reach where an AI system's output is used in the EU, so a UK SaaS company with EU customers may be in scope. This is a question to take advice on rather than to settle from a blog post, and it turns on specifics of who your users are and where.

We only use a third-party model through an API. Are we a provider?

Possibly. Putting an AI system on the market under your own name can make you a provider even where the underlying model is somebody else's, and the model provider has its own separate obligations. This is the distinction most worth getting right and most worth taking advice on if the answer is commercially material.

Was the high-risk deadline really moved?

Yes. Annex III high-risk obligations moved from 2 August 2026 to 2 December 2027, and Annex I to 2 August 2028, by Regulation (EU) 2026/1744, in force since 27 July 2026. Since the timeline has already changed once by amendment, check the Commission's timeline page rather than relying on any secondary source.

Do we need an AI governance platform?

Almost certainly not at forty people. The obligations that apply to you today are an inventory, a classification with reasoning, some transparency labels, a literacy session and a supplier assessment. That is a spreadsheet and a day, and the same argument applies as for compliance automation platforms.

What happens if we do nothing?

For a non-high-risk product the immediate exposure is commercial rather than regulatory: customers are already asking, and an unanswerable questionnaire costs you deals long before an authority takes an interest. The transparency obligations are in force, so doing nothing is not a neutral position, but the realistic pressure arrives through procurement first.