If you ship a SaaS product and have added any AI feature in the last eighteen months — a copilot, a summariser, a content moderator, a scoring model — the EU AI Act applies to you. The question is not whether it applies but which tier your feature lands in, because the tier determines the obligations, the documentation, and the budget you have to set aside for compliance before August 2026.
Most B2B SaaS AI features are either minimal risk or limited risk and require little more than a transparency notice. A smaller but operationally significant subset is high-risk because it falls under Annex III of the Act. This guide is the practical version: the risk-tier model, Annex III in plain English, worked examples for the AI features we see most often in SaaS products, and what high-risk classification actually requires of you in 2026.
The reason this matters now is timing. The Act entered into force in August 2024 with a phased application: prohibited practices in February 2025, GPAI provider obligations in August 2025, and the full high-risk framework in August 2026. If you ship AI features into the EU today and you have not classified them, you have until August 2026 to do the work — a year that goes faster than it looks. The teams that started in early 2025 are now filing their documentation in their normal release cadence. The teams that have not started are looking at a compressed run-up to a hard date.
The classification work is also the entry point for everything else. Once you know whether a feature is minimal, limited, or high-risk, the rest of the obligations map cleanly onto the tier. The difficulty is in the classification itself, because the regulation is written in legal language and the test cases are in the EU AI Office’s implementation guidance rather than in your product spec. The rest of this guide translates the regulation into the language a SaaS team uses when it ships features.
Key takeaways
- The EU AI Act uses four risk tiers: prohibited, high-risk, limited risk, and minimal risk. The obligations scale dramatically with the tier.
- Most B2B SaaS AI features are either limited risk (chatbots, copilots) or minimal risk (internal productivity tools). A smaller but operationally significant subset is high-risk because they fall under Annex III.
- Annex III lists eight categories that trigger high-risk classification, including employment, credit scoring, education, law enforcement, and access to essential services.
- If your AI feature influences a decision about hiring, firing, promotion, credit, school admission, or access to a public benefit, you are almost certainly high-risk.
- Human review in the loop does not automatically move a system out of high-risk — what matters is whether the human can meaningfully intervene, not whether the human clicks 'approve'.
- GPAI providers (the companies behind foundation models like GPT, Claude, or Llama) face separate obligations from SaaS deployers. Most SaaS companies are deployers, not providers.
- August 2026 is when most of the AI Act applies. If you ship AI features into the EU, the question is not whether you need to act, but which tier you sit in.
The short answer
The Act uses four risk tiers. If your AI feature influences a decision about hiring, firing, promotion, credit, school admission, or access to a public benefit, it is almost certainly high-risk. If it is a productivity tool, a chatbot that drafts replies, or a content generator, it is limited or minimal risk and you owe transparency at most. The deciding question is not whether your feature uses AI; it is whether its output affects a person’s rights.
Most of the SaaS AI features we review are limited risk: customer support copilots, marketing copy generators, meeting-note summarisers, code-review assistants. The compliance work for these is small — a one-line UI disclosure and an internal record of the feature. A meaningful minority is high-risk — resume screeners, credit decisioning, employee monitoring, insurance triage — and for those the work is substantial. The point of this guide is to help you classify correctly so you know which bucket you are in before August 2026 forces the question.
The four risk tiers
The AI Act organises every AI system into one of four tiers. The obligations scale dramatically with the tier, so the first job is figuring out where you sit. Most B2B SaaS AI features are limited risk or minimal risk, which is genuinely good news — the compliance work for those tiers is small. The high-risk tier is where the budget lives; the prohibited tier is rare enough that most SaaS teams can rule it out by inspection.
Prohibited
Social scoring by public authorities, manipulative AI that materially distorts behaviour, real-time remote biometric ID in public spaces (with limited exceptions), and emotion recognition in workplaces and schools. Out of scope for nearly all SaaS.
High-risk
AI used in any of the eight Annex III categories (covered below). Full lifecycle obligations: risk management, data governance, documentation, logging, transparency, human oversight, accuracy, post-market monitoring. Most compliance effort lives here.
Limited risk
AI that interacts with people or generates content. Transparency obligations: tell them they are interacting with AI, label synthetic content. Most customer-facing chatbots and copilots land here.
Minimal risk
Everything else. Internal productivity tools, marketing copy generators, spam filters. No AI Act obligations, though GDPR and other sectoral law still apply.
Annex III: the eight high-risk categories
Annex III is the part of the Act that decides whether your SaaS is in trouble. It lists eight categories of AI use; if your feature materially influences a decision in any of them, it is high-risk. The categories most likely to apply to a SaaS product are bolded in the headlines below; the rest are there for completeness. Read this list once before you read anything else in the guide — it is the shortest path to figuring out whether your AI features need the high-risk treatment at all.
Biometric identification and categorisation
Remote biometric identification, emotion recognition in education and workplaces, and biometric categorisation that infers sensitive attributes. Most SaaS companies are nowhere near this.
Critical infrastructure
AI used as a safety component in managing critical infrastructure — water, gas, electricity, traffic, digital infrastructure. Out of scope for most SaaS unless you sell to grid operators.
Education and vocational training
AI that decides access to education, evaluates learning outcomes, or detects cheating during tests. If your SaaS scores student essays or admissions essays, you are here.
Employment, workers management, and self-employment
AI used to recruit, screen CVs, evaluate candidates, decide promotions, allocate tasks, monitor performance, or terminate employment. This is where most SaaS HR-tech and productivity-monitoring tools land.
Access to essential private and public services and benefits
AI that decides eligibility for public benefits, credit scoring, insurance pricing and risk assessment, emergency services dispatch, or access to public services. If your fintech or insurtech SaaS prices risk or approves loans, you are here.
Law enforcement
AI used by law enforcement for risk assessment, polygraphs, evidence reliability evaluation, profiling, or recidivism prediction. Almost never a SaaS use case.
Migration, asylum, and border control
AI used to assess visa applications, asylum claims, or border management. Almost never a SaaS use case.
Administration of justice and democratic processes
AI that assists judicial authorities or influences the outcome of an election or referendum. Almost never a SaaS use case.
Worked examples for common SaaS AI features
This is where the tier assignment usually gets done in practice. We see most SaaS AI features fall into one of three buckets: limited risk for the productivity and customer-facing features, minimal risk for the marketing and copy features, and a smaller set of high-risk features that touch employment, credit, insurance, or education. The examples below are real patterns from the SaaS products we have reviewed in 2025 and 2026.
Customer-support copilot that drafts replies
Limited riskWhy: The AI assists a human agent. The agent reads, edits, and sends the message. No automated decision about a person is made; the AI is a productivity tool under human supervision.
Obligation: Transparency: tell the user they are talking to an AI-assisted agent. No Annex III.
Resume-screening model that ranks candidates
High-riskWhy: Annex III, category 4 (employment). The model materially influences a hiring decision. Even if a human reviews the ranking, the AI shapes the decision in a way the Act treats as a credit-or-rights-affecting automated process.
Obligation: Full high-risk obligations: risk management, data governance, technical documentation, logging, transparency to deployers and affected persons, human oversight, accuracy and robustness, post-market monitoring.
Marketing-copy generator
Minimal riskWhy: No decision about a person is being made. The output is a string of marketing text.
Obligation: None under the AI Act. GDPR may still apply to any personal data you process in the prompt or training pipeline.
Credit-risk model that approves or declines a loan
High-riskWhy: Annex III, category 5 (access to essential services and credit scoring). The decision materially affects the applicant's access to credit, which is a fundamental economic activity.
Obligation: Full high-risk obligations. Plus sectoral regulation under the Consumer Credit Directive and the EU's existing credit-scoring supervisory regime.
Meeting-notes summariser that records and transcribes calls
Limited riskWhy: Annex III does not apply. The tool processes content, not decisions about people.
Obligation: Transparency: tell participants the call is being recorded and summarised. GDPR applies to the personal data in the transcripts.
Performance-monitoring model that flags low engagement and proposes PIP
High-riskWhy: Annex III, category 4 (employment). The model influences a decision about a worker's evaluation and possible termination. Even if HR reviews the recommendation, the AI shapes the decision.
Obligation: Full high-risk obligations. Plus employment law and works-council notification in most EU jurisdictions.
Chatbot that answers product questions on your website
Limited riskWhy: The chatbot interacts with a user but does not decide anything about them. Disclosure is required.
Obligation: Article 50 transparency: the user must know they are talking to an AI. Otherwise no AI Act obligations.
Lead-scoring model that ranks inbound prospects by conversion likelihood
Minimal riskWhy: The output is a probability score for a sales pipeline entry, not a decision that affects a person’s rights. GDPR applies to any personal data used as input, but Annex III does not.
Obligation: None under the AI Act. Document the data fields used so the GDPR record of processing covers them.
Insurance-claims triage model that flags suspicious claims for review
High-riskWhy: Annex III, category 5 (insurance risk assessment and pricing). The model influences whether a claim is fast-tracked or investigated. The outcome materially affects the policyholder’s access to a benefit.
Obligation: Full high-risk obligations. Plus sectoral regulation under Solvency II and national insurance supervisors.
Adaptive-learning engine that personalises a student’s curriculum
High-riskWhy: Annex III, category 3 (education and vocational training). The model decides what material a student sees and in what order, which materially shapes their learning trajectory and assessment outcomes.
Obligation: Full high-risk obligations. Plus FERPA, national education law, and parental-consent requirements for minors.
Code-review assistant that flags potential bugs and security issues
Minimal riskWhy: No decision about a person is being made. The output is a code review comment for the engineer.
Obligation: None under the AI Act. GDPR may apply if the code being reviewed contains personal data, which is unusual but worth documenting.
Healthcare triage chatbot that advises patients on whether to seek care
High-riskWhy: Annex III category 5 (access to essential services) covers access to emergency healthcare dispatch; even outside emergency services, the output materially affects a patient’s medical decision-making and is treated as high-risk by the EU member-state authorities that have weighed in.
Obligation: Full high-risk obligations. Plus the Medical Device Regulation if your feature is classified as a medical device.
Common misclassifications we see in SaaS
The tier assignment is the part of the AI Act most SaaS companies get wrong, and the part that costs the most to fix after the fact. The patterns below come from the AI features we have reviewed this year.
“Our HR tool is just an LLM that summarises reviews”
If the summary influences a manager’s decision about promotion, compensation, or termination, it is in Annex III, category 4 (employment). The fact that the model only summarises text rather than scoring it is irrelevant — the output affects a worker’s evaluation. The Act treats the use case, not the architecture.
“A human reviews every AI recommendation”
Human review is a high-risk obligation (Article 14), not a way to avoid high-risk classification. The Act asks whether the AI materially shapes a decision that affects a person’s rights. If the answer is yes, you are high-risk and the human review must be designed to actually override the AI, not rubber-stamp it.
“Our customers configure the model, so we’re not the deployer”
A SaaS company that ships an AI feature to its customers is a provider of the system as integrated into the customer’s workflow. The customer is a deployer. You have provider obligations for the system you ship; the customer has deployer obligations for how they use it. Neither role exempts you.
“It’s just an AI assistant”
“Assistant” is a marketing label, not a regulatory category. If the assistant writes code, drafts emails, or answers product questions, it is limited risk and you owe transparency. If the assistant flags candidates for hiring, approves loans, or scores patient risk, it is high-risk. The function the assistant performs decides the tier; the word on your landing page does not.
“The training data is from the EU so GDPR is enough”
GDPR covers personal data in the AI pipeline. The AI Act covers the AI system itself, including non-personal-data training corpora, model architecture decisions, and post-deployment monitoring. The two regulations stack; one does not replace the other.
What high-risk classification actually requires
If your feature lands in Annex III, you inherit eight obligations. The work is not theoretical — these are the documents and processes an auditor will ask for first.
01Risk management system (Article 9)
A documented, iterative risk-management process across the lifecycle of the AI system: identification, estimation, evaluation, and mitigation of risks to health, safety, and fundamental rights. Reviewed and updated throughout the system's life. Treat it like a living design document, not a one-time artefact — the regulation expects continuous oversight, not a checkbox at launch.
02Data governance (Article 10)
Training, validation, and testing datasets must be relevant, sufficiently representative, and as free of biases as possible. Document data sources, preparation, and labelling decisions. This is the GDPR-on-steroids of the AI Act. For a SaaS deployer using a third-party model, you still need to document the data you send into the model and how the model's outputs are evaluated for bias in your context.
03Technical documentation (Annex IV)
A living document covering the system's purpose, architecture, training data choices, performance metrics, and risk-mitigation measures. Auditors will ask for this first. The Annex IV template lists nine sections; expect the document to run 30-80 pages for a typical SaaS AI feature.
04Record-keeping and logging (Article 12)
Automatic logging of events over the system's lifecycle, sufficient for post-hoc traceability of the system's functioning. Logs must be retained for an appropriate period, typically six months or longer for high-risk systems. Include the inputs to the model, the model's output, the deployer who received the output, and any human override or modification.
05Transparency and instructions for use (Article 13)
Clear instructions for deployers covering the system's intended purpose, known limitations, and oversight measures. End users affected by the system's decisions have a right to understand how the decision was made. For B2B SaaS this means a deployer-facing README plus an end-user-facing disclosure if the decision affects them directly.
06Human oversight (Article 14)
The system must be designed to allow effective human oversight during its use. This is not just 'a human in the loop' — the human must have the authority and the information to intervene, override, or disable the system. A manager who clicks 'approve' on every AI recommendation without seeing the underlying reasoning is not effective oversight; a manager who sees the reasoning, can drill into the model inputs, and can reverse the decision is.
07Accuracy, robustness, and cybersecurity (Article 15)
Appropriate levels of accuracy for the system's intended purpose, robust to errors and adversarial inputs, and protected against unauthorised access. For a SaaS deployer this includes model-prompt-injection resistance, access controls on the model's API surface, and monitoring for unusual input patterns that suggest abuse.
08Post-market monitoring (Article 72)
A documented plan to actively monitor the system's performance after deployment, report serious incidents, and update the risk assessment as the use evolves. Most SaaS teams already have product analytics; the question is whether those analytics feed back into the risk-management file, not just the product roadmap.
GPAI providers vs deployers
The Act draws a sharp line between GPAI providers and deployers. If you call an LLM API and build a product on top, you are almost always a deployer — not a provider. The provider’s obligations (transparency about training data, copyright compliance, model evaluation) are theirs. Your obligations are the deployer obligations attached to the risk tier of your feature.
This distinction matters because founders often assume that inheriting a third-party model’s compliance covers them. It does not. The deployer obligations are yours the moment you ship a feature whose output affects an EU user, regardless of what model sits underneath.
How the AI Act stacks with GDPR, NIS2, and DORA
The AI Act does not replace existing regulation. It sits on top of GDPR, NIS2, DORA, and sectoral law. For SaaS companies that touch more than one regime, the operational reality is a stack of overlapping obligations that have to be reconciled, not picked between.
GDPR + AI Act
GDPR covers any personal data processed in the AI pipeline — training data, prompts, model inputs, model outputs that contain personal data, and any human reviewer's notes. The AI Act covers the system itself: the model architecture, training data governance, post-market monitoring, and the documentation that explains how decisions are made. Both apply; one does not exempt the other. A high-risk AI feature processing EU personal data needs a GDPR record of processing entry, an Article 30 register entry, an AI Act risk-management file, and an AI Act Annex IV technical document. None of these replace the others.
NIS2 + AI Act
If your SaaS is an essential or important entity under NIS2 (which applies to many SaaS companies in digital infrastructure, digital services, or as managed service providers), the security and incident-reporting obligations in NIS2 stack with the AI Act obligations on your AI features. A breach caused by an AI feature triggers NIS2 incident reporting on a separate timeline from AI Act post-market monitoring.
DORA + AI Act
Financial-sector SaaS falls under DORA (Digital Operational Resilience Act) for ICT risk management, third-party risk, and incident reporting. The AI Act adds AI-specific obligations on top. A credit-scoring SaaS has DORA obligations for the resilience of its ICT stack and AI Act obligations for the AI features themselves.
Sectoral law + AI Act
Medical-device software, transport safety, education, employment law — each sector has its own EU or national regulation. The AI Act does not replace sectoral law; it sets a floor. If your AI feature is a regulated medical device, you need the Medical Device Regulation on top of the AI Act's high-risk obligations. The two compliance regimes run in parallel.
What auditors actually look at first
When a national supervisory authority audits a SaaS deployer of high-risk AI, the conversation starts in five predictable places. Plan for these signals in advance and the audit goes differently.
Risk-management file currency
Auditors first ask when the risk-management file was last reviewed and updated. If the file is older than the most recent feature release, the auditor assumes the file is stale. For a SaaS shipping weekly, the file should be reviewed at least monthly or at every major release — whichever is more frequent.
Annex IV technical documentation completeness
The nine sections of Annex IV are a checklist. Auditors verify each section exists and is non-trivial. Empty sections or sections that say 'to be completed' are an automatic finding. For a SaaS AI feature, the model architecture section and the data-governance section are the two that take the longest to write and are the most often incomplete.
Logging and traceability
Auditors ask for a sample trace: a single decision the AI made on a particular date, with the inputs, the model's output, the human override (if any), and the action taken. If you cannot produce that trace within an hour, your logging is insufficient. The Article 12 logging obligation is where most SaaS teams fall down, because product analytics are usually not designed for AI-system traceability.
Provider-deployer boundary
Auditors ask who your model provider is, what their obligations are, and how you are satisfying the deployer obligations on top. If your answer is 'we use OpenAI under their terms', you have not done the work. The deployer obligations sit on you regardless of the provider.
Post-market monitoring evidence
For a system that has been deployed for any length of time, auditors ask what the post-market monitoring plan produced. Findings, retraining triggers, bias incidents, accuracy drift — if your post-market monitoring file is empty six months after launch, the obligation is not being met.
Enforcement timeline
The Act enters force in phases. Most SaaS-relevant obligations arrive in August 2026; a smaller residual set in August 2027.
Prohibited AI practices apply
Article 5 prohibitions on social scoring, manipulative AI, real-time biometric ID in public spaces (with limited law-enforcement exceptions), and emotion recognition in workplaces and schools.
GPAI provider obligations apply
Providers of general-purpose AI models (GPT, Claude, Llama, etc.) face transparency, copyright, and training-data summary obligations. Most SaaS companies are not GPAI providers.
Most remaining obligations apply
High-risk system obligations (Articles 9-15), transparency obligations for limited-risk systems (Article 50), and the bulk of provider and deployer obligations. This is the date that matters for most SaaS companies.
Embedded high-risk systems
High-risk AI systems that are safety components of products covered by EU harmonisation legislation (medical devices, machinery, toys, etc.) come into scope. Out of scope for pure SaaS unless you sell to those verticals.
What SaaS teams should do in 2026
The work for a SaaS team that ships AI features in the EU is straightforward if you start before August 2026. The sequence:
- Inventory every AI feature. For each, write down the intended purpose, the data subjects affected, and the decision the feature influences. A simple spreadsheet is enough to start. Tag each feature with its risk tier and the date of the tier assignment so you can show the work was done.
- Assign each feature to a risk tier using Annex III as the reference. If a feature is borderline, document the reasoning — that record is what protects you in an audit. A one-paragraph rationale per feature is enough; the auditor expects the reasoning to exist, not for it to be perfect.
- For limited-risk features, add the Article 50 transparency disclosure. One sentence in the UI is usually enough; the requirement is that the user knows they are interacting with AI. The disclosure must be clear and conspicuous; a footnote in a 1,000-word terms of service is not enough.
- For high-risk features, stand up the eight obligations above as living documents. The risk-management file and the Annex IV technical documentation are the two an auditor will ask for first. Allocate one owner and one review cadence before you start writing. A risk-management file with no owner and no cadence is functionally non-existent.
- Review your vendor DPA register for any model provider you call into. Make sure the provider’s obligations cover what you deploy on top, including downstream model modifications and fine-tuning that may have shifted the provider’s own risk classification. If you fine-tune a model on your own data, you may have shifted the risk classification for the resulting system; document that decision.
- Re-run the inventory every time you ship a new AI feature. Most teams that get caught by the Act get caught because they shipped an AI feature and forgot to update the register. Bake the inventory review into the release checklist the same way you would a privacy review or a security review. A pre-release question — “does this feature touch AI and what tier is it?” — prevents the problem at the source.
- If you sell to customers in multiple EU jurisdictions, watch for national-level guidance. The Act is harmonising, but each national authority can issue sector-specific interpretations that tighten the obligations for AI features in regulated industries. Germany, France, and Spain have published the most national guidance so far; track those three as the bellwether.
- When a customer asks about your AI Act posture, treat it the way you would a SOC 2 question: document the answer, link to the underlying evidence, and have one canonical place where the posture is described. A “trust centre” page that links to the risk-management file and the Article 50 disclosures is usually enough to satisfy procurement.
The temptation is to wait for “clarifying guidance” from the EU before doing the inventory. Resist it. The Act is in force, and the obligations for high-risk systems scale with the documentation work you have already done. Starting the inventory in Q1 2026 is dramatically cheaper than starting it in Q3 2026 after a customer asks for evidence you do not have. The teams that get this right are the ones who treated the AI Act like GDPR: an operational discipline with a documented owner and a review cadence, not a project to be closed out before a deadline.
If your SaaS ships AI features into the EU and you need a third party to classify each feature, document the high-risk ones, and confirm that the deployer side of your stack meets the August 2026 obligations, AppCheck runs the same kind of review we describe here — automated checks across the ten coverage areas plus a human review of your AI feature inventory, your provider contracts, and your disclosure copy. Flat €500 per audit, delivered in days. Request an audit.
Frequently asked questions
Does the EU AI Act apply to my SaaS if I am not in the EU?
Yes, with the same logic as the GDPR. Article 2 reaches providers and deployers that place AI systems on the EU market or whose output is used in the EU, regardless of where the provider is established. If your customers are in the EU, the Act applies.
We use OpenAI / Anthropic under the hood. Are we a GPAI provider?
Almost certainly not. A GPAI provider is the entity that places a general-purpose model on the market — typically the model lab. If you build a SaaS product that calls an LLM API, you are a deployer of someone else's model, not a GPAI provider. The model lab's obligations are theirs; yours are deployer obligations.
What if our AI feature just makes recommendations and a human decides?
Human review does not automatically move you out of high-risk. Article 14 requires effective human oversight, but if the AI materially shapes the decision in a way that affects rights (hiring, credit, education, services), the system is high-risk whether or not a human clicks 'approve' afterwards. The standard is whether the human can meaningfully intervene, not whether the human exists.
What about internal tools that use AI but never face a customer?
Pure internal tools are generally minimal risk under the Act — the Act targets AI whose output is used to make decisions affecting people in the EU, not AI that helps your team write code or summarise meetings. The GDPR still applies to any personal data you process, but the AI Act does not.
Do we need to register our system with the EU database?
High-risk providers must register their system in the EU database before placing it on the market (Article 49). Deployers of high-risk systems do not register them but must keep records. Most SaaS deployers do not need to interact with the registration database; their providers do.
What's the fine for non-compliance?
Up to €35 million or 7% of global annual turnover for prohibited practices; up to €15 million or 3% for other breaches. For most SaaS companies, the operative number is the GPAI provider fine, which is the model lab's problem, not yours. Your exposure is deployer fines and the operational cost of being forced to retrofit at the last minute.
Does the AI Act require us to disclose our training data?
Only if you are a GPAI provider. SaaS deployers that call a third-party model are not required to disclose their prompts or their use of the model. You do, however, need to disclose to end users that they are interacting with AI (Article 50) and to document the data fields you pass into the model as part of your GDPR record of processing.
How does the AI Act treat multi-model orchestration?
Each model in the chain is its own AI system for the purposes of the Act. If your SaaS uses a retrieval-augmented generation (RAG) pipeline that calls an embedding model, a reranker, and an LLM, you have provider obligations for the integrated system even if every individual model is someone else's. The system as integrated into your product is what you ship to your customers.
What happens to existing AI features when the AI Act applies in August 2026?
They are treated as if newly placed on the market on that date. You have until 2 August 2026 to bring existing high-risk features into compliance. The transitional period is generous but finite — there is no grandfathering for AI features that are already deployed.
Does the AI Act apply to AI features in mobile apps?
Yes, with no carve-out. The Act applies to AI systems whose output is used in the EU, regardless of the deployment surface (web, mobile, API, embedded device). The same risk-tier framework applies.