EU AI Act High-Risk Classification: The 57-Day Sprint for SaaS Developers

Post #3 in the sota.io EU AI Act Final Countdown Series

High-risk AI classification is the most consequential determination you will make under the EU AI Act — and also the most commonly misunderstood. Most SaaS teams either assume they are not high-risk (often wrong) or assume they are covered by their model provider's compliance (also wrong).

This guide focuses on Post #3 in the series. Post #1 covered the overall deadline picture and obligation tracks. Post #2 covered Art.50 transparency implementation. This post covers Annex III classification, the six core high-risk obligations, and what you need to complete before August 2, 2026.

The Annex III Test: Are You High-Risk?

Article 6 of the EU AI Act establishes a two-path classification for high-risk AI systems. Path A covers AI systems that are themselves safety components of products regulated under specific EU directives (machinery, medical devices, vehicles). Path B — the path that catches most SaaS — is Annex III.

Annex III lists eight categories of AI systems that are automatically classified as high-risk regardless of technical sophistication:

For most SaaS companies, categories 3, 4, and 5 are the primary risk vectors.

The "Intended Purpose" Test

Classification depends on the intended purpose declared by the provider — not how users actually deploy the system. This distinction matters: if your product's documentation, marketing copy, or API reference describes the system as performing screening, ranking, categorisation, or evaluation of persons in any of the Annex III domains, you have declared your intended purpose.

The practical implication: SaaS teams that added employment screening, educational assessment, or credit-adjacent features without legal review may have unintentionally classified themselves as high-risk AI providers.

Common Misclassification Patterns in SaaS

"We just provide the API, the customer decides how to use it" — incorrect. If your API is designed for candidate screening, the intended purpose is employment screening regardless of API documentation caveats.

"Our AI gives recommendations, not decisions" — insufficient. Art.6 applies to systems that assist in making decisions, not just systems that make them autonomously. A recommendation engine used in CV shortlisting is high-risk.

"We're B2B, not B2C" — irrelevant to classification. Annex III categories apply based on the domain and function, not the customer relationship model.

"Our model is too small / not sophisticated enough" — classification is domain-based, not capability-based. A simple logistic regression used for credit scoring is as high-risk as a large language model performing the same function.

The Six Core High-Risk Obligations

If you determine that your system falls under Annex III, the following obligations apply to you as a provider. These must be in place before you place the system on the market or put it into service — which for SaaS means before August 2, 2026 for systems already deployed.

1. Risk Management System (Art.9)

Art.9 requires a documented, iterative risk management system covering the full lifecycle of the AI system. The system must:

• Identify and analyse known and reasonably foreseeable risks for the intended purpose
• Estimate and evaluate risks arising from intended use and reasonably foreseeable misuse
• Evaluate risks in light of reasonably foreseeable misuse based on likely end-user behaviour
• Implement appropriate risk management measures based on the analysis

The word "iterative" is operationally important: the regulation requires the risk management system to be updated throughout the lifecycle, not completed once at deployment. You need processes for ongoing risk identification, not just a one-time risk assessment document.

Minimum documentation: Risk identification register, risk estimation methodology, residual risk evaluation, risk management measures implemented, evidence that residual risks are acceptable.

2. Data Governance (Art.10)

Art.10 applies to high-risk AI systems that use training data and establishes quality standards for how that data is selected, processed, and managed. Key obligations:

• Training, validation, and test datasets must meet specified quality criteria
• Data must be relevant, sufficiently representative, and free from errors
• Providers must examine datasets for possible biases that could lead to discrimination
• Limitations in the dataset must be identified and documented

For SaaS teams that use third-party models (OpenAI, Anthropic, Cohere, Mistral etc.): Art.10 applies to your fine-tuning data and prompt engineering decisions, not to the base model's training data. Your responsibility is the data layer you control.

What this means practically: Document what training data you used (if any fine-tuning was done), where it came from, what bias analysis was performed, and what limitations were identified. For teams using foundation models without fine-tuning, document the data you inject via prompts (RAG, context injection, user data) and the representativeness and bias implications.

3. Technical Documentation (Art.11, Annex IV)

Art.11 requires providers to establish technical documentation before placing the system on the market. The content of that documentation is specified in Annex IV. The Annex IV package includes:

• General description of the AI system (purpose, version, intended use, users, affected persons)
• Description of the elements of the AI system and the development process
• Information about monitoring, functioning, and control (metrics, performance thresholds)
• Description of appropriateness of performance metrics
• Detailed description of the risk management system
• Description of any change made to the system through its lifecycle
• List of harmonised standards applied
• Copy of the EU declaration of conformity

For SaaS teams: this is a living document package, not a one-time PDF. It must be updated when you change the system and retained for 10 years after the system is placed on the market.

4. Transparency for Deployers (Art.13)

Art.13 requires high-risk AI providers to ensure that their systems are sufficiently transparent to enable deployers (your B2B customers) to understand and use the system appropriately. Specifically, providers must accompany high-risk AI systems with instructions for use that include:

• Identity and contact details of the provider
• System characteristics, capabilities, and limitations
• Level of accuracy, robustness, and cybersecurity
• Known or foreseeable circumstances that may lead to risks
• Human oversight measures
• Expected lifetime and maintenance arrangements

What this means for B2B SaaS: Your technical documentation, terms of service, and product documentation collectively constitute the Art.13 disclosure. Many existing SaaS agreements do not address accuracy limitations, known failure modes, or human oversight requirements in the terms that Art.13 requires. Legal review of your standard agreement is necessary.

5. Human Oversight Measures (Art.14)

Art.14 requires that high-risk AI systems are designed to allow human oversight. The specifics:

• The system must allow individuals assigned to human oversight to understand the capabilities and limitations of the AI system
• The system must allow oversight personnel to detect malfunctions, failures, and unexpected performance
• The system must allow oversight personnel to disregard, override, or interrupt the system's output
• Where relevant, the system must allow the oversight function to intervene via a stop button or equivalent

For SaaS systems: Art.14 does not require you to build a "kill switch" into every output. It requires that the human oversight function is technically feasible — that a person responsible for oversight could, if they chose to, review, override, or stop the system's outputs. The obligation is partly design (build interfaces that allow human review) and partly documentation (specify the oversight roles and procedures).

6. Accuracy, Robustness, and Cybersecurity (Art.15)

Art.15 sets general performance requirements: high-risk AI systems must achieve appropriate levels of accuracy, and must be resilient against errors, faults, and adversarial inputs. Accuracy levels must be declared in the accompanying instructions.

Cybersecurity requirements mean that high-risk AI systems must be resistant to attempts to alter their use, behaviour, or performance. This includes adversarial attacks, model inversion, data poisoning, and prompt injection in systems using language models.

The 8-Week Sprint Plan (Through August 2, 2026)

If you have confirmed Annex III classification applies, here is the minimum-viable sprint to reach compliance before the deadline.

Weeks 1–2 (June 6–20): Classification and Gap Analysis

• Complete the Annex III classification determination for all AI features in your product
• Identify which features are high-risk, which are general-purpose, and which are neither
• Map existing documentation against the Annex IV requirements — identify gaps
• Audit your standard customer agreement against Art.13 requirements
• Assign human oversight responsibility for each high-risk feature

Output: Scope document listing every affected feature, gap analysis against Art.9–17, responsible owners for each obligation.

Weeks 3–4 (June 20 – July 4): Risk Management and Data Documentation

• Draft the Art.9 risk management system — identify risks, estimate severity and likelihood, document mitigations
• Document data sources for all training data, fine-tuning data, and prompt context data
• Perform or commission a bias evaluation for each high-risk feature
• Document accuracy metrics and acceptable performance thresholds

Output: Risk register (draft), data governance documentation, bias evaluation results, accuracy declarations.

Weeks 5–6 (July 4–18): Technical Documentation Package

• Compile the Annex IV documentation package for each high-risk feature
• Draft or update the EU declaration of conformity
• Update customer-facing technical documentation to meet Art.13 requirements
• Review and update standard customer agreement to include required disclosures

Output: Annex IV documentation package (draft), updated customer agreement, Art.13-compliant product documentation.

Weeks 7–8 (July 18 – August 2): Human Oversight Implementation and Final Checks

• Implement or document technical controls for Art.14 human oversight
• Verify that customers can disregard, override, or interrupt high-risk system outputs
• Internal review of full documentation package
• Update Art.15 accuracy and cybersecurity measures — patch adversarial input vulnerabilities
• Final internal audit against Art.9–17 checklist

Output: Compliance documentation package, updated product interfaces, internal audit record.

EU AI Act Compliance in a Regulated Environment: Procurement

One practical issue that rarely appears in compliance guides: if you sell to the EU public sector, your customers' procurement rules may require you to provide compliance declarations before contract renewal. Several EU member states are updating procurement frameworks to require AI Act compliance evidence. This creates a near-term revenue consequence for SaaS providers who cannot produce Annex IV documentation: lost B2G contract renewals in the September–December 2026 procurement cycle.

The procurement timeline runs ahead of the enforcement timeline. You need documentation in place before August 2 not just for regulatory compliance but because RFPs landing in Q3 2026 will include AI Act compliance requirements.

Deployer Obligations Are Separate

Everything above covers obligations for providers — companies that develop and place high-risk AI systems on the market. If you are a deployer (a company that uses another provider's high-risk AI system in its operations), a separate set of obligations applies under Art.26:

• Designate a person responsible for overseeing the use of the AI system
• Ensure appropriate human oversight as specified in the provider's instructions
• Monitor system operation using the provider's instructions for use
• Inform providers of serious incidents involving the system

Many SaaS companies are simultaneously providers (for their own products) and deployers (for AI tools they use internally, e.g., HR platforms using GPT-4 for candidate screening). Both tracks require assessment.

What's Next in This Series

This post covered the Annex III classification test and Art.9–17 obligations. The series continues:

• Post #4: GPAI model obligations (Art.51–53) — what SaaS teams using foundation models need to comply with before August 2
• Post #5: Complete EU AI Act compliance checklist — a single-document reference combining all three obligation tracks

Hosting your AI system on EU infrastructure doesn't just reduce regulatory complexity — it reduces data transfer risk under GDPR, simplifies your Annex IV documentation, and gives you a cleaner story for Art.10 data governance. sota.io provides EU-sovereign compute for SaaS teams running compliance-sensitive AI workloads.