EU AI Act High-Risk AI Conformity Assessment 2026: Technical Documentation, Testing & CE Marking for SaaS

Post #3 in the sota.io EU AI Act High-Risk Classification 2026 Series

You've determined your AI system is high-risk under Annex III. Now what?

The EU AI Act does not just tell you to "be compliant" — it specifies exactly which documents you must produce, which tests you must run, which assessment procedure you must follow, and what mark must appear on your system before it enters the EU market. This post walks through the entire conformity assessment pipeline for high-risk AI systems, translated into concrete tasks for SaaS developers building on EU infrastructure in 2026.

The August 2, 2026 enforcement deadline for most Annex III systems is fixed. Conformity assessment is not a last-week checklist — it takes months to complete properly.

What Conformity Assessment Actually Means

Conformity assessment is the process a provider must complete to demonstrate that their high-risk AI system meets all requirements under Chapter III of the EU AI Act before placing the system on the EU market or putting it into service.

The output of conformity assessment is a Declaration of Conformity and, for most systems, the right to affix the CE marking. These are legal attestations — signing them incorrectly carries the same liability as false product declarations under EU product safety law.

The AI Act provides two conformity assessment procedures:

Procedure A — Internal Control (Annex VI): The provider conducts the full assessment themselves, without external auditors. This is available for most Annex III high-risk systems, with the exception of AI systems covered by Article 6(1) (which includes certain safety components in regulated sectors like medical devices and civil aviation).

Procedure B — Third-Party Assessment (Annex VII): Required when the system falls under an existing EU harmonised legislation sector and a notified body is designated for that sector, OR when the provider cannot demonstrate required capabilities for internal assessment. Also used voluntarily when providers want independent validation.

For most SaaS developers building general-purpose high-risk AI (hiring tools, creditworthiness systems, public authority decision support, critical infrastructure AI), Procedure A applies. You assess yourself — but the documentation burden is substantial.

The Technical Documentation Obligation: Annex IV

Article 11 requires providers to draw up technical documentation before placing the system on the market. Annex IV specifies precisely what this documentation must contain. This is not a one-page summary — the full Annex IV list runs to 15 categories of information.

Annex IV Section 1: General Description of the AI System

You must document:

• The intended purpose of the AI system, including the specific context and conditions of use
• A description of the AI system's capabilities and limitations (including accuracy levels and known failure modes)
• The version of the software and relevant updates
• All hardware components the system depends on
• The external data sources, databases, and third-party AI components the system consumes

What this means for SaaS: If your hiring AI calls a third-party embedding model or uses an external scoring API, those dependencies must appear in your Annex IV documentation. You cannot simply black-box external components — you must describe their role, limitations, and any known biases.

Annex IV Section 2: Detailed Description of System Elements

This section requires:

• Architectural diagrams showing how components interact
• The training, validation, and testing data characteristics (data sources, labelling methodology, data governance)
• A description of the training methodology and techniques
• Any pre-trained models used, including their origin and training data characteristics
• The metrics used to evaluate accuracy, robustness, and cybersecurity

Critical disclosure: If your model was trained on data that reflects historical human bias (e.g., historical hiring decisions that underrepresented certain demographics), this must be disclosed in the technical documentation. The EDPB's 2025 AI guidance amplifies this requirement for processing of personal data under GDPR Article 9.

Annex IV Section 3: Monitoring, Functioning, and Control

Providers must document:

• The validation and testing procedures applied and their results
• The measures taken to examine and address known and foreseeable risks to health, safety, and fundamental rights
• The post-market monitoring system and its data collection approach
• The human oversight measures built into the system (who can override, how, and what information they receive)

Annex IV Sections 4–15: Operational Requirements

The remaining sections cover:

• Detailed risk management records (see below)
• Technical measures for data governance (Article 10)
• Logging and audit trail specifications
• Instructions for use (Article 13)
• Transparency disclosures (Article 13(3))
• Cybersecurity measures (Article 15)
• The Declaration of Conformity
• EU representative details (for non-EU providers)

Scale of effort: A fully compliant Annex IV package for a mid-complexity high-risk SaaS typically runs 80–200 pages. Budget 4–8 weeks of dedicated engineering and legal time.

The Risk Management System: Article 9

Article 9 is the spine of the EU AI Act's technical requirements for high-risk systems. It requires a continuous risk management process — not a point-in-time assessment.

What Article 9 Requires

Identification and analysis of known and foreseeable risks associated with the high-risk AI system throughout its lifecycle:

• Risks arising from the intended purpose
• Risks arising from reasonably foreseeable misuse
• Risks to affected persons (including vulnerable groups — Article 9(2)(a))
• Risks to third parties beyond the direct user

Risk evaluation: For each identified risk, you must estimate the probability and severity of harm. The Act's proportionality principle means you weight risks against the benefit of the AI system's function.

Risk mitigation measures: For each unacceptable residual risk, you must implement mitigation. The Act specifies a priority order:

1. Eliminate the risk by design
2. Implement adequate protection measures
3. Provide information to users (residual risk disclosure in instructions)

Testing against risk mitigation: You must verify that your risk mitigation measures work. Article 9(7) requires testing "at the stage of design and development" — before deployment.

Article 9(9) — Cumulative Fundamental Rights Impact: Where risks to fundamental rights are identified, providers must consult their fundamental rights impact assessment under Article 27 and integrate its findings into the risk management system.

The Risk Register Format

The Act does not mandate a specific format, but the EU AI Office's draft guidance (released March 2026) recommends:

This register must be updated continuously — not just at initial assessment.

Testing Obligations Before CE Marking

Article 9(7) and the related standards framework (Article 40) set out the testing you must complete before declaring conformity.

Accuracy and Robustness Testing

You must test the system against the accuracy metrics specified in your Annex IV documentation. For most SaaS high-risk systems, this includes:

Performance testing: Measure the system's accuracy (precision/recall/F1 or equivalent) on a held-out test set that reflects the deployment population. The test set must not have been used in training or validation.

Robustness testing: Test performance degradation under:

• Input perturbations (noise, adversarial examples)
• Distribution shift (the test population differs from training data)
• Out-of-distribution inputs (inputs the model was not designed to handle)

Fairness testing: Article 9(2)(a) requires specific attention to vulnerable groups. You must test whether performance varies significantly across protected characteristics (gender, ethnicity, age, disability, etc.). Significant variance must either be technically mitigated or disclosed in instructions for use.

Recommended tooling: AI Fairness 360 (AIF360), Fairlearn, Responsible AI Toolbox, or equivalent. Document your tooling choice in the technical documentation.

Cybersecurity Testing

Article 15 requires AI systems to be designed to withstand known cybersecurity threats. For high-risk AI systems in SaaS deployments, this means:

• Input validation against adversarial attacks (model poisoning, evasion attacks)
• API security (authentication, rate limiting, audit logging)
• Data exfiltration prevention
• Model inversion attack resistance (particularly relevant for healthcare AI processing personal data)

Practical alignment: Map your cybersecurity testing to the AI-specific provisions of ENISA's "Secure by Design for AI" playbook (v0.4, May 2026 draft) and the emerging CRA cybersecurity baseline for AI products.

Logging and Traceability Validation

Article 12 requires automatic logging of events that enable monitoring of the system's operation. Before CE marking, verify your logging captures:

• Each inference or decision made
• The input data used (or a hash/identifier if raw data retention is privacy-constrained)
• The output and confidence score
• Human override events
• Any access control changes to the logging system itself

Logs must be retained for the minimum period specified in your instructions for use, and in any case for the duration of the system's high-risk classification.

The CE Marking Process

Step 1: Complete the Conformity Assessment (Procedure A or B)

Run through the full Article 9 risk management cycle. Compile the complete Annex IV technical documentation package. Verify all Article 8–15 requirements are met:

• Article 8: Compliance with requirements
• Article 9: Risk management ✓
• Article 10: Data governance and management
• Article 11: Technical documentation ✓
• Article 12: Record-keeping
• Article 13: Transparency and information provision
• Article 14: Human oversight
• Article 15: Accuracy, robustness, cybersecurity

Step 2: Draw Up the EU Declaration of Conformity

Article 47 requires a Declaration of Conformity stating:

• The provider's identity and contact details
• The AI system name, type, version, and serial number (if applicable)
• A statement that the system is in conformity with the EU AI Act
• References to any harmonised standards applied (Article 40)
• References to the common specifications applied (Article 41), if relevant
• The place and date of the declaration
• The name and signature of the authorised representative

One declaration covers all similar systems: Article 47(2) allows a single DoC to cover multiple systems where the same declaration applies — relevant for SaaS providers with modular AI products.

Step 3: Affix the CE Marking

Article 48 governs CE marking for high-risk AI systems:

• The CE marking must be affixed visibly, legibly, and indelibly to the AI system or its packaging, or to accompanying documentation
• For software-only systems (most SaaS AI), the CE marking appears in the product's user interface, documentation, and Terms of Service
• The CE marking is affixed by the provider, not by a third-party certifier (unless Procedure B applies and a notified body is involved)

Format: The CE marking must conform to Annex V (the standard CE mark graphic) with a minimum height of 5mm where space permits.

Step 4: Register in the EU Database

Article 71 requires providers of high-risk AI systems to register their systems in the EU AI Act database maintained by the EU AI Office before market placement.

Registration requires:

• Provider identity information
• System description and intended purpose
• Geographic scope of deployment
• The categories of persons affected
• Reference to the Declaration of Conformity

The database is publicly accessible (for most Annex III systems). Registration is not optional — operating without registration constitutes a violation subject to up to €30M / 6% global annual turnover fines under Article 99(3).

Procedure B: When You Need a Notified Body

Procedure B (Annex VII) requires involvement of a designated notified body in two scenarios:

Mandatory for safety-component AI: If your high-risk AI system is a safety component in a product covered by Union harmonisation legislation listed in Annex I (machinery, radio equipment, medical devices, etc.) and the underlying harmonisation legislation requires third-party conformity assessment, you need a notified body.

Voluntary for other Annex III systems: Any provider of an Annex III system may choose Procedure B for independent validation. This is increasingly expected in regulated sectors (financial services, healthcare, critical infrastructure) where deployers require third-party assurance before procurement.

Selecting a Notified Body

Notified bodies for AI Act purposes are designated by Member State national authorities and listed in NANDO (the New Approach Notified and Designated Organisations database). The designation process is ongoing in 2026 — the first wave of AI-specific notified body designations is expected Q3 2026.

For interim periods, providers in regulated sectors often use existing notified bodies designated under related legislation (medical device notified bodies, machinery notified bodies) where their scope includes AI components.

Cost expectation: Notified body assessments for high-risk AI systems typically cost €20,000–€80,000 depending on system complexity and body. Budget accordingly.

Post-Market Monitoring Obligations

Conformity assessment does not end at market placement. Article 72 requires a post-market monitoring system covering:

Continuous performance monitoring: Track the accuracy metrics declared in Annex IV against production data. Alert thresholds must be defined and monitored.

Serious incident reporting: Under Article 73, providers must report serious incidents (incidents resulting in death, serious harm to health, or significant property damage) to the national authority within 15 days of becoming aware. Life-threatening incidents require reporting within 2 days (Article 73(3)).

Substantial modification tracking: Article 16(e) requires re-assessment when a high-risk AI system undergoes a "substantial modification" — defined as any modification that changes the conformity assessment results or affects the purpose, function, or performance in ways that require Annex IV updates.

Annual reporting obligation: Providers of high-risk AI systems must submit annual post-market monitoring summaries to national market surveillance authorities.

Practical Timeline for SaaS Providers (August 2026 Deadline)

Given the August 2, 2026 enforcement start for most Annex III systems, here is the backwards-planned timeline for a provider starting conformity assessment now (late May 2026):

This is a compressed timeline. Providers in regulated sectors (healthcare, finance) with Procedure B requirements should add 8–12 weeks for notified body scheduling.

The Infrastructure Layer: Where Hosting Matters for Conformity

The conformity assessment addresses the AI system itself — but the infrastructure it runs on has direct bearing on several requirements:

Article 10 Data Governance: Your data management practices (storage location, access controls, data lineage tracking) must be documented. Hosting on EU infrastructure with documented data residency (Hetzner Germany, OVHcloud, etc.) simplifies the GDPR Article 35 DPIA integration required for systems processing personal data.

Article 15 Cybersecurity: The network security properties of your hosting environment (isolated networks, DDoS protection, encryption in transit and at rest) must be documented in Annex IV. EU-native providers typically offer stronger documentation and cooperation than US-based hyperscalers operating under CLOUD Act obligations.

Logging and Record-Keeping (Article 12): Your infrastructure must support the logging retention requirements. Consider where logs are stored and whether they're accessible to EU market surveillance authorities on request without triggering cross-jurisdictional data transfer complications.

For SaaS providers on EU-sovereign infrastructure, these requirements create a natural compliance advantage over providers on US-parent platforms — the data residency, access control, and regulatory cooperation questions resolve more cleanly on infrastructure that isn't subject to extraterritorial US law.

Key Takeaways for SaaS Developers

The conformity assessment is not primarily a legal exercise — it is a product discipline. Providers who treat it seriously will:

1. Discover and fix bias issues in their AI models before they cause harm and before enforcement finds them
2. Build monitoring infrastructure they should have had anyway
3. Create documentation that significantly reduces liability exposure when things go wrong
4. Gain a defensible compliance posture that enterprise buyers and regulated-sector customers increasingly require before procurement

The providers who will struggle are those who wait until July 2026 to start a process that requires 12 weeks minimum. The technical documentation requirements, testing obligations, and risk management cycle are not completable in a week.

Next in the series: Post #4 covers high-risk AI monitoring and post-market surveillance in depth — what systems you must build to comply with Article 72, what "serious incident" reporting requires, and how to design continuous monitoring into your AI system's production architecture.

This post is part of the sota.io EU AI Act High-Risk Classification 2026 Series. All five posts are available at the series index at sota.io/blog.