The most important EU AI Act question for many SaaS companies is not:
Do we use AI?
It is:
Does our AI system fall into a regulated risk category, especially high-risk?
That classification decision determines almost everything that follows: documentation, testing, human oversight, risk management, data governance, conformity assessment, registration, and post-market monitoring.
This became more urgent in May 2026, when the European Commission published draft guidelines on the classification of high-risk AI systems under Article 6 of the AI Act. The Commission says the guidelines are intended to help providers, deployers, and market surveillance authorities assess whether an AI system should be classified as high-risk and to support uniform enforcement of Article 6.
For SaaS teams, the practical lesson is simple:
You need a repeatable classification method before you ship AI features.
This article explains how to build one.
1. Why high-risk classification matters
The EU AI Act uses a risk-based structure. Some AI practices are prohibited, some AI systems are high-risk, some require transparency, and many systems remain lower-risk but still need good governance.
High-risk classification matters because high-risk systems are subject to strict requirements, including:
| Requirement area | What it means in practice |
|---|---|
| Risk management | Identify, evaluate, reduce, and monitor risks throughout the lifecycle |
| Data governance | Control training, validation, and testing data quality where relevant |
| Technical documentation | Maintain evidence of design, intended purpose, limitations, and compliance |
| Logging | Enable traceability and incident investigation |
| Transparency | Provide instructions for use and explain capabilities and limits |
| Human oversight | Design systems so people can understand, intervene, override, or stop use |
| Accuracy, robustness, cybersecurity | Define metrics and protect against errors, attacks, and misuse |
| Registration | Certain high-risk systems must be registered in the EU database |
The official AI Act text states that high-risk systems must be tested against defined metrics and probabilistic thresholds appropriate to their intended purpose. It also requires high-risk AI systems to be designed for appropriate accuracy, robustness, and cybersecurity throughout their lifecycle.
For a SaaS company, this means classification is not a legal formality. It affects product architecture, QA, monitoring, documentation, release gates, and customer contracts.
2. The two main routes into "high-risk"
Article 6 of the AI Act creates two main routes into high-risk classification.
| Route | Description | Typical SaaS relevance |
|---|---|---|
| Article 6(1): Product safety route | AI is a product, or safety component of a product, covered by EU harmonisation legislation listed in Annex I and requires third-party conformity assessment. | Medical devices, machinery, toys, vehicles, lifts, radio equipment, aviation, marine equipment |
| Article 6(2): Annex III route | AI is used for one of the sensitive use cases listed in Annex III. | HR, education, credit, essential services, biometrics, law enforcement, migration, justice, democratic processes |
For most SaaS companies, the second route is the more common one.
If you sell HR automation, candidate screening, student assessment, credit scoring, fraud-related access decisions, public-benefit eligibility tools, biometric identity products, or AI decision support for legal or administrative decisions, you should treat high-risk classification as a serious possibility.
The Commission's May 2026 draft guidelines are specifically intended to help providers and deployers assess whether their system is high-risk and what high-risk classification it may fall under.
3. Annex III: the use cases SaaS teams must check first
Annex III is the practical checklist for many software companies.
The AI Act identifies several sensitive domains where AI use can affect health, safety, or fundamental rights. These include biometrics, critical infrastructure, education, employment, access to essential services, law enforcement, migration and border control, administration of justice, and democratic processes.
For SaaS teams, these are the highest-priority areas:
| Annex III area | SaaS examples |
|---|---|
| Biometrics | Remote biometric identification, biometric categorisation, emotion recognition where not prohibited |
| Education and vocational training | Admission scoring, exam proctoring, learning outcome evaluation, student ranking |
| Employment and worker management | CV screening, candidate ranking, promotion decisions, termination risk scoring, task allocation, worker monitoring |
| Access to essential private or public services | Creditworthiness, insurance eligibility, public benefits, emergency dispatch prioritisation |
| Law enforcement | Risk assessment, evidence analysis, crime analytics, suspect profiling |
| Migration, asylum, border control | Visa support, risk scoring, identity or document analysis |
| Justice and democratic processes | Legal decision support, judicial research affecting cases, election influence systems |
The AI Act recitals explain why these areas are sensitive. For example, AI systems used in employment and worker management can have an appreciable impact on career prospects, livelihoods, and workers' rights. AI systems used to evaluate creditworthiness can determine access to financial resources or essential services such as housing, electricity, and telecommunications.
That is the core idea: high-risk classification is not about whether the model is large or technically impressive. It is about the intended purpose and the potential effect on people.
4. Start with intended purpose
The most important classification variable is the intended purpose.
The same AI model can be low-risk in one context and high-risk in another.
| AI feature | Likely lower-risk use | Possible high-risk use |
|---|---|---|
| Text classifier | Sort support tickets | Rank job candidates |
| Chatbot | Answer product FAQ | Advise on access to public benefits |
| Image model | Tag product images | Biometric identification |
| Prediction model | Forecast stock availability | Predict employee performance for promotion |
| Scoring model | Prioritise internal bugs | Determine creditworthiness |
| Voice model | Summarise meeting notes | Analyse worker emotion or performance |
This is why SaaS teams should not classify only the model. They should classify the system in context.
A practical internal definition:
Intended purpose = what the AI system is designed, marketed, configured, documented, or reasonably expected to do in real use.
Classification evidence should therefore include:
| Evidence | Why it matters |
|---|---|
| Product requirements | Shows what the feature is designed to do |
| Marketing copy | Shows how the feature is presented to customers |
| Customer onboarding | Shows expected deployment context |
| Prompt templates | Shows intended task and outputs |
| UI labels | Shows what users are told the system does |
| API documentation | Shows supported use cases |
| Sales materials | Shows target industry and claims |
| Logs and telemetry | Shows real usage patterns after deployment |
If your marketing says "AI candidate ranking for faster hiring decisions", you cannot later classify the system as a generic productivity assistant.
5. The Article 6(3) exemption: useful, but dangerous to overuse
The AI Act includes an important exception for some Annex III systems.
Article 6(3) says that an AI system referred to in Annex III is not considered high-risk where it does not pose a significant risk of harm to health, safety, or fundamental rights, including where it does not materially influence the outcome of decision-making. The Act then lists conditions such as performing a narrow procedural task, improving the result of a previously completed human activity, detecting patterns without replacing or influencing human assessment, or performing a preparatory task.
This matters because not every AI tool touching HR, education, or finance is automatically high-risk.
Examples that may require careful assessment:
| AI feature | Possible argument for lower-risk classification |
|---|---|
| Grammar correction for HR emails | Narrow procedural task, no effect on candidate evaluation |
| Duplicate detection in student records | Preparatory or administrative task |
| Summarising already-completed human review notes | Improves result of previous human activity |
| Detecting unusual patterns for human review | Does not replace or influence final assessment if properly controlled |
But there is a major limit.
The AI Act states that an Annex III AI system is always considered high-risk where it performs profiling of natural persons.
For SaaS teams, that is a critical warning. If your AI system builds, infers, predicts, or uses profiles about people in one of the Annex III contexts, you should be extremely cautious about claiming the exemption.
6. A practical high-risk classification workflow
Use this workflow before releasing any AI feature.
Step 1: Is it an AI system under the AI Act?
First confirm whether the feature is an AI system.
Document:
| Question | Evidence |
|---|---|
| Does it infer outputs from inputs? | Architecture notes |
| Does it generate predictions, recommendations, decisions, or content? | Product spec |
| Is it adaptive, statistical, ML-based, logic-based, or model-based? | Technical design |
| Is it only deterministic software? | Engineering review |
If the feature is not an AI system, the AI Act high-risk classification may not apply, although GDPR, consumer law, cybersecurity, accessibility, or sector rules may still matter.
Step 2: Is it prohibited?
Before high-risk, check whether the use case is banned or restricted.
Examples may include manipulative systems, certain biometric uses, social scoring, and other prohibited practices. If there is any possibility that the system falls into prohibited AI, escalate to legal review immediately.
Step 3: Does Article 6(1) apply?
Ask:
| Question | Example |
|---|---|
| Is the AI system a product or safety component of a product? | Medical device AI, vehicle safety AI |
| Is the product covered by Annex I legislation? | Medical devices, machinery, toys, aviation, vehicles |
| Does it require third-party conformity assessment? | Sector-specific product safety process |
If yes, the system may be high-risk under the product safety route.
Step 4: Does Annex III apply?
Map the intended purpose to Annex III.
| Domain | High-risk signal |
|---|---|
| Employment | Ranking, filtering, evaluating, monitoring, allocating tasks |
| Education | Admission, assessment, proctoring, learning-path decisions |
| Credit or essential services | Eligibility, scoring, access, prioritisation |
| Biometrics | Identification, categorisation, emotion recognition |
| Justice | Legal interpretation or decision support affecting cases |
| Democratic processes | Influencing voting behaviour or election outcomes |
If no Annex III domain applies, the system may not be high-risk under Article 6, but it may still have transparency, GDPR, or product-specific obligations.
Step 5: Does the system materially influence a decision?
Ask:
| Question | High-risk concern |
|---|---|
| Does the output rank people? | Ranking can materially influence decisions |
| Does the output score eligibility? | Scoring can affect access |
| Does the output recommend acceptance or rejection? | Decision support can shape outcomes |
| Does the output trigger automated action? | Strong material influence |
| Is the human reviewer likely to rely on it? | Automation bias risk |
| Is the output visible to the decision-maker? | Direct influence |
The Act's exemption logic depends partly on whether the system materially influences decision-making. But this should be interpreted carefully. A "recommendation" can still influence a human decision.
Step 6: Does profiling occur?
If the system profiles natural persons in an Annex III context, the high-risk conclusion becomes much stronger.
Examples of profiling-like behavior:
| System behavior | Example |
|---|---|
| Predicting personal traits | "Likely to leave job in 6 months" |
| Ranking people by suitability | Candidate ranking |
| Scoring risk | Fraud risk, credit risk, behavioural risk |
| Inferring preferences or vulnerabilities | Student learning-risk profile |
| Segmenting people for decisions | Benefit eligibility groups |
Because the AI Act states that Annex III systems performing profiling are always high-risk, this should be a hard checkpoint in your classification form.
Step 7: Can an Article 6(3) exemption be justified?
If you believe the system is not high-risk despite touching Annex III, document the reasoning before launch.
Article 6(4) says that a provider who considers an Annex III system not to be high-risk must document its assessment before placing it on the market or putting it into service, and must provide that documentation to national competent authorities upon request.
Your exemption memo should include:
| Section | What to document |
|---|---|
| System description | What the AI does |
| Intended purpose | Where and why it is used |
| Annex III mapping | Which Annex III area may be relevant |
| Exemption condition | Narrow task, preparatory task, etc. |
| No material influence analysis | Why the output does not shape the final decision |
| Profiling analysis | Whether profiling occurs |
| Human review | How humans review, override, or ignore output |
| Evidence | UI screenshots, product docs, logs, prompts, workflows |
| Residual risk | Remaining risk and mitigations |
| Approval | Legal, product, engineering sign-off |
Do not rely on a verbal "we think it is low risk". The AI Act expects documentation.
7. Examples for SaaS teams
Example 1: AI CV screening tool
Feature: AI ranks job applicants based on CVs and job descriptions.
Likely classification: High-risk.
Why: Employment and recruitment are explicitly sensitive. The system materially influences candidate selection and may affect career prospects and livelihoods. The AI Act recitals specifically mention recruitment and selection systems as high-risk due to impact on career prospects, livelihoods, and workers' rights.
Example 2: AI interview note summariser
Feature: Summarises notes written by a human interviewer after the interview.
Likely classification: Needs assessment.
Why: If the tool only improves the result of a previously completed human activity and does not rank, score, recommend, or profile candidates, an Article 6(3) exemption may be arguable. But if the summary changes emphasis, produces suitability judgments, or is used in hiring decisions, the risk increases.
Example 3: AI customer support chatbot
Feature: Answers questions about product settings.
Likely classification: Usually not high-risk.
Why: Generic support automation is usually outside Annex III. However, if the chatbot gives advice about credit, insurance, healthcare, legal rights, immigration, or public benefits, the classification changes.
Example 4: AI credit pre-qualification
Feature: Scores users for loan eligibility.
Likely classification: High-risk.
Why: The AI Act recitals state that systems used to evaluate credit scores or creditworthiness of natural persons should be classified as high-risk because they determine access to financial resources or essential services.
Example 5: AI student proctoring
Feature: Detects prohibited behaviour during online tests.
Likely classification: High-risk.
Why: The AI Act recitals mention AI systems used in education or vocational training, including monitoring and detecting prohibited student behaviour during tests, as high-risk because they can affect educational and professional paths.
Example 6: AI sales lead scoring
Feature: Scores companies based on likelihood to buy.
Likely classification: Usually not high-risk.
Why: B2B lead scoring is not normally an Annex III use case. But if it scores natural persons for access to essential services, credit, employment, or other sensitive decisions, reassess.
Example 7: AI worker productivity monitoring
Feature: Scores employees based on activity, messages, tickets, or screen time.
Likely classification: Likely high-risk.
Why: Employment and worker management systems used for monitoring or evaluation of people in work-related relationships are identified as high-risk in the AI Act recitals.
8. Product signals that increase high-risk likelihood
Even if the product team says "human decides", the system may still materially influence decisions.
High-risk signals include:
| Signal | Why it matters |
|---|---|
| Ranking people | Ranking affects attention and opportunity |
| Scores from 0–100 | Scores create decision anchors |
| Red/yellow/green risk labels | Labels can bias human reviewers |
| "Recommended decision" output | Strong influence on outcome |
| Auto-rejection or auto-approval | Direct decision effect |
| Alerts about individuals | Can trigger investigation or action |
| Personality, emotion, intent, risk inference | Profiling or sensitive inference risk |
| Use in employment, education, credit, benefits | Annex III context |
| Customer can configure thresholds | May automate decisions in deployment |
| Model output is logged into decision record | Becomes part of formal process |
A SaaS feature does not become low-risk just because there is a human somewhere in the loop. Human oversight must be meaningful.
The AI Act's human oversight provisions say that people assigned oversight should be able to understand the system's capabilities and limitations, remain aware of automation bias, correctly interpret outputs, decide not to use the system, override or reverse output, and intervene or stop the system where appropriate.
9. Documentation you should create before launch
Even if you conclude the system is not high-risk, keep a classification record.
Minimum documentation:
| Document | Purpose |
|---|---|
| AI system inventory | List all AI features and models |
| Intended purpose statement | Defines what the system is for |
| Risk classification memo | Explains prohibited, high-risk, transparency, lower-risk status |
| Annex III mapping | Shows whether sensitive domains apply |
| Data flow map | Shows inputs, outputs, users, affected persons |
| Human oversight design | Explains review, override, escalation |
| Evaluation report | Shows accuracy, failure modes, and test cases |
| Bias and fairness review | Especially important for people-impacting systems |
| Monitoring plan | Tracks drift, incidents, misuse, complaints |
| Customer usage constraints | Prevents unsupported high-risk use |
| Change control record | Reassesses classification after changes |
For ComplyTest-style tooling, this can become a machine-readable compliance artifact:
{
"system_name": "AI Candidate Summary Assistant",
"intended_purpose": "Summarise interviewer notes without ranking or recommending candidates",
"ai_act_status": "Annex III touched, high-risk exemption claimed",
"annex_iii_area": "Employment",
"material_influence": "Low, output is editable summary only",
"profiling": false,
"human_oversight": "Human recruiter reviews and edits all summaries",
"evidence": [
"product_spec_v1.4",
"ui_screenshots_2026-05-21",
"evaluation_report_2026-05-22"
],
"approval": {
"legal": "approved",
"product": "approved",
"engineering": "approved"
}
}
The goal is not bureaucracy. The goal is to prove that classification was reasoned, documented, and reviewed before deployment.
10. How classification can change after launch
AI Act classification is not a one-time decision.
A system can become high-risk later if its intended purpose changes or if a third party modifies it. The AI Act states that a distributor, importer, deployer, or other third party may be considered a provider of a high-risk AI system where they modify the intended purpose of an AI system in a way that makes it high-risk under Article 6.
Common triggers for reassessment:
| Change | Why it matters |
|---|---|
| New customer segment | Moving from generic SaaS to HR, education, credit, or healthcare |
| New output type | From summary to recommendation or score |
| New automation | From decision support to automatic decision |
| New data source | Adding behavioural, biometric, financial, or health data |
| New marketing claim | Positioning the product for hiring, eligibility, or risk scoring |
| New integration | Connecting AI output into operational workflows |
| New model | Different capabilities, risks, or failure modes |
| New geography | EU deployment or EU users |
| Customer configuration | Customer uses generic model for high-risk purpose |
Your release process should include an AI classification gate.
11. What deployers should ask vendors
If you buy AI software, do not accept vague claims like "AI Act ready".
Ask vendors:
| Question | Why |
|---|---|
| What is the intended purpose of the system? | Classification depends on intended purpose |
| Is the system classified as high-risk? | Determines obligations |
| Which Annex III area did you assess? | Shows legal reasoning |
| Are you claiming an Article 6(3) exemption? | Requires documentation |
| Does the system profile natural persons? | Can make Annex III systems always high-risk |
| What human oversight measures are built in? | Needed for safe deployment |
| What accuracy and robustness metrics are declared? | Required for high-risk systems |
| What logs are generated? | Needed for traceability |
| What data was used for training/testing? | Data governance and bias review |
| What uses are prohibited in your terms? | Prevents unintended high-risk deployment |
| How do you monitor post-market performance? | Lifecycle compliance |
This turns procurement into compliance evidence.
12. Suggested article checklist for readers
Use this simple checklist.
| Question | Yes / No |
|---|---|
| Have we listed all AI systems in the product? | |
| Have we defined intended purpose for each AI system? | |
| Have we checked prohibited AI practices? | |
| Have we checked Article 6(1), product safety route? | |
| Have we checked Annex III use cases? | |
| Have we assessed material influence on decisions? | |
| Have we assessed profiling of natural persons? | |
| Have we documented any Article 6(3) exemption claim? | |
| Have we reviewed human oversight design? | |
| Have we defined accuracy and robustness metrics? | |
| Have we checked marketing and sales claims? | |
| Have we added classification review to release/change control? | |
| Have legal, product, and engineering approved the classification? |
Conclusion
High-risk classification under the EU AI Act is not only a legal question. It is a product governance question.
For SaaS teams, the safe workflow is:
- define the AI system,
- document intended purpose,
- check prohibited uses,
- check Article 6(1),
- check Annex III,
- assess material influence,
- assess profiling,
- document any exemption,
- design oversight and testing,
- reassess after product or customer-use changes.
The May 2026 Commission draft guidelines confirm that providers and deployers need practical tools for classifying AI systems under Article 6.
The safest principle is:
If your AI system affects a person's job, education, credit, essential services, legal position, migration status, biometric identity, or democratic participation, do not treat classification as a checkbox. Treat it as a formal product-risk decision.
Sources
- European Commission, Draft Commission guidelines on the classification of high-risk AI systems, published 19 May 2026.
- European Commission, Targeted consultation on the draft guidelines for the classification of high-risk artificial intelligence systems, May 2026.
- Regulation (EU) 2024/1689, Artificial Intelligence Act, official EUR-Lex text.
- Regulation (EU) 2024/1689, Article 6 high-risk exemption and documentation requirement for Annex III systems.
- Regulation (EU) 2024/1689, recitals and provisions on high-risk employment, education, credit, emergency services, testing, human oversight, accuracy, robustness, cybersecurity, registration, and change of provider responsibility.