---
title: "Does the EU AI Act apply to your SaaS?"
canonical: "https://auditbadger.com/blog/does-the-eu-ai-act-apply-to-your-saas/"
last-updated: "2026-08-23"
---

# Does the EU AI Act apply to your SaaS?

By Maciej • Published 2026-08-25 • 7 min read • Categories: Compliance Governance, Legal Regulations, Knowledge Hub

Created with AI assistance. AuditBadger retains editorial control and responsibility.

**TL;DR:** The EU AI Act (Regulation (EU) 2024/1689) sorts AI systems by risk, not by company size. Most small SaaS teams are not building high risk systems: that tier is a specific list of use cases in Annex III, including recruitment and candidate screening, education, essential services, biometrics and law enforcement. If you ship an LLM feature, run a support chatbot or publish AI assisted content, you are usually in the transparency tier instead, governed by article 50, which has applied since 2 August 2026. Article 50 asks four things in practice: tell people when they are talking to an AI rather than a human, mark synthetic audio, image, video and text in a machine readable way, tell people when they are exposed to emotion recognition or biometric categorisation, and disclose deep fakes and certain AI generated public interest text unless a human took editorial responsibility. Separately, article 4 has required both providers and deployers to ensure a sufficient level of AI literacy among their staff since 2 February 2025, which catches almost every company using AI at work. You usually wear two hats at once: provider for the AI you build into your product, deployer for the AI your team uses.

Short answer: if you sell software in the EU and there is any AI in it, the EU AI Act reaches you. But the tier you land in is almost certainly transparency, not high risk, and that is a very different amount of work.

The date that matters for most small software companies has already passed. Article 50, the transparency chapter, has applied since 2 August 2026. So this is not a horizon scanning exercise any more. It is a "check whether we are already behind" exercise, which is a much shorter conversation.

None of what follows is legal advice. It is an operational triage of one regulation, written for the common case of a small software company.

## The tiers, quickly

The AI Act is risk based. Four tiers, and you can usually place yourself in a couple of minutes:

- **Prohibited practices.** Social scoring, certain biometric categorisation, manipulative techniques and a short list of others. Banned since 2 February 2025. If you are doing one of these you already know.
- **High risk.** A defined list, not a vibe. Either an AI system used in one of the Annex III areas, or an AI system acting as a safety component of a product already regulated under EU product law. This tier carries the heavy obligations: risk management system, data governance, technical documentation, logging, human oversight, conformity assessment.
- **Transparency.** Article 50. Certain systems have to be honest about what they are, regardless of how harmless they are otherwise. This is where most SaaS lands.
- **Minimal risk.** Everything else, with no specific obligations under the Act.

## Why most SaaS is not high risk

Founders read "high risk" and assume that anything important to their customers qualifies. It does not work that way. High risk is a list of use cases, and the list is about what the AI decides for a person, not how critical your software is to a business.

The Annex III areas are biometrics, critical infrastructure, education and vocational training, employment and worker management, access to essential private and public services, law enforcement, migration and border control, and the administration of justice and democratic processes.

So "we use a model to summarise support tickets" is not high risk. Neither is "we generate a first draft of a document that a human edits", nor "we cluster usage data to suggest features".

But read the employment entry carefully if it is anywhere near your product. AI systems intended for recruitment or selection of people, including filtering applications and evaluating candidates, are high risk. If you build hiring software, an ATS feature that ranks applicants puts you in a different regime than the rest of this post describes, and you need more than a triage.

## Two hats: provider and deployer

This trips people up more than the tiers do, because most small companies wear both hats at the same time and the duties differ.

You are a **provider** of an AI system when you develop it, or have it developed, and put it on the market or into service under your own name or trademark. Your product's AI features make you a provider, even though you did not train the underlying model. Building on someone else's API does not make you a mere passer through.

You are a **deployer** when you use an AI system under your own authority. Your team using an assistant to draft copy, triage tickets or write code makes you a deployer.

Article 50 puts some duties on providers, such as making sure an interactive system tells people it is an AI and that synthetic output is marked, and others on deployers, such as disclosing deep fakes and certain published text. Deciding which hat you are wearing per feature is the actual work, and it is worth writing the answer down feature by feature rather than for the company as a whole.

## The duty almost everyone missed

Article 4 requires providers and deployers to take measures to ensure a sufficient level of AI literacy among the staff who deal with the operation and use of AI systems on their behalf. It has applied since 2 February 2025.

That one catches nearly every company, including ones with no AI in their product at all, because using AI tools internally makes you a deployer. It is not a certification. It is proportionate training, and it is the cheapest item on this entire list to close. If you already run [security awareness training with completion records](/blog/soc-2-evidence-collection-what-auditors-actually-want-with-examples/), add a module and you are most of the way there.

## What article 50 actually asks for

In plain words, four things:

1. **Tell people they are talking to a machine.** Systems intended to interact directly with people have to be designed so the person knows it is AI, unless that is obvious to a reasonably well informed user.
2. **Mark synthetic output.** Providers of systems that generate synthetic audio, image, video or text have to mark outputs in a machine readable format, detectable as artificially generated or manipulated, as far as is technically feasible.
3. **Disclose emotion recognition and biometric categorisation.** Deployers must inform the people exposed to it.
4. **Label deep fakes, and some published text.** Deployers generating or manipulating image, audio or video that constitutes a deep fake must disclose it. Text published to inform the public on matters of public interest must be disclosed as AI generated, unless it went through human review and someone holds editorial responsibility for it.

That last carve out matters a lot for anyone running a content operation, and it is the subject of the next post in this series.

## What to do this week

The order that gets you to an answer fastest:

1. **Inventory every AI feature in your product** , plus the AI tools your team uses. One line each.
2. **Mark each one provider or deployer.** Some will be both.
3. **Check each against Annex III** honestly. If nothing matches, you are in the transparency tier and the work is proportionate.
4. **Run the article 50 questions** per feature and write down the answer with a date on it.
5. **Close the AI literacy gap** , because it is already overdue and takes an afternoon.

For step four we built a free assessment. Nine plain language questions about your product, and out comes a dated applicability record: which transparency duties reach you, why, and an action plan with controls, evidence and owners. It is free, no email is required, and the answers are not stored. [Run the assessment here](/eu-ai-act-article-50/assessment/).

If you would rather read before answering anything, [the Article 50 operational pack](/eu-ai-act-article-50/) walks through every obligation in the same plain words: what the law says, what to actually do about it, and what to keep on file.

## Where this sits next to your other compliance work

Worth being clear about the boundaries, because these get conflated in sales conversations. The AI Act is EU product regulation. It is not a security framework and it does not replace one. SOC 2® and ISO 27001 say nothing about AI transparency, and the AI Act says nothing about your access controls.

They do meet in one practical place: evidence. Both want you to be able to show, on a date, what you decided and why. If you already keep control evidence properly, article 50 records slot in beside it rather than starting a new pile. We wrote about the security side of shipping LLM features in [SOC 2 for AI startups](/blog/soc-2-for-ai-startups-controls-for-llm-model-risk/), and about how agents are changing evidence work in [this piece on AI and evidence collection](/blog/how-ai-agents-are-changing-compliance-evidence-collection/).