EU AI Act Conformity Assessment: A Step-by-Step Path for High-Risk SaaS Features

A Munich HR-tech SaaS added an AI feature in 2025 that ranks inbound job applications. The team saw it as a productivity tool. Under the EU AI Act it is a high-risk AI system — employment-related candidate evaluation sits squarely in Annex III — and shipping it to EU customers after 2 August 2026 without a completed EU AI Act conformity assessment exposes both the vendor and its customers to enforcement risk and stalled procurement. The uncomfortable part: the team only learned this when an enterprise prospect's legal department asked for their CE marking documentation.

This post is the walkthrough we wish that team had: how to determine whether your SaaS features fall in scope, who actually owes the conformity assessment, what the assessment route looks like step by step, and which technical documentation you must keep ready for an audit.

Step 1: Run the Annex III Scope Test Before Anything Else

The high-risk category is not about how powerful your model is. It is about what the system is used for. Article 6(2) points to Annex III, a closed list of use cases. For SaaS products, the entries that bite most often are:

• Employment and worker management — CV screening, candidate ranking, interview scoring, task allocation, performance evaluation, promotion or termination decisions.
• Access to essential private services — creditworthiness scoring, risk pricing for life and health insurance.
• Education — admission decisions, learning-outcome evaluation, exam proctoring.
• Essential public services and benefits — eligibility checks for public assistance, emergency dispatch triage.
• Biometrics — identification, categorisation, and emotion recognition (the latter outright prohibited in workplaces and schools).

Run every AI feature through this list and write the result down, including the reasoning for features you classify as not high-risk. Article 6(3) provides a narrow carve-out: a system in an Annex III area escapes the high-risk label if it only performs a preparatory or narrow procedural task and does not materially influence the decision. If you rely on that carve-out, you must document the assessment and register the system in the EU database anyway — a silent self-exemption is not a defensible position.

A useful heuristic: if your feature's output feeds a decision about a person's job, money, education, or access to services, assume high-risk until your documented analysis says otherwise.

Step 2: Establish Whether You Are the Provider

The conformity assessment obligation falls on the provider — whoever places the system on the EU market under their own name or trademark. Calling a third-party model API does not move the obligation upstream. If your product is branded as your AI feature, you are the provider of the AI system, even though Anthropic or OpenAI is the provider of the underlying GPAI model.

Article 25 adds a trap for B2B SaaS: a customer (deployer) who substantially modifies a high-risk system, or puts their own brand on it, can themselves become the provider. White-label arrangements deserve contractual clarity here — spell out who owns conformity, who maintains the technical documentation, and who registers the system.

Step 3: The EU AI Act Conformity Assessment Route, Step by Step

For nearly all Annex III SaaS systems, Article 43 lets you use the internal control procedure of Annex VI — a self-assessment, with no external auditor involved. Only remote biometric identification systems (and certain biometric categorisation/emotion systems) may require a notified body under Annex VII. For everyone else, the route looks like this:

1. Build a quality management system (Article 17). This is the backbone the rest hangs on: a documented strategy for regulatory compliance, design and development procedures, data management practices, post-market monitoring, and incident handling. If you already run an ISO 27001-style ISMS, extend it rather than starting fresh — the structures overlap heavily.

2. Engineer the system to meet Articles 9–15. The substantive requirements: a risk management system that runs across the lifecycle (Art. 9), data governance covering training, validation and test data (Art. 10), automatic event logging (Art. 12), transparency and instructions for deployers (Art. 13), human oversight mechanisms (Art. 14), and accuracy, robustness and cybersecurity appropriate to the purpose (Art. 15). These are engineering work items, not legal prose — logging, evaluation pipelines, and override mechanisms have to exist in the codebase. Retrofitting them into an AI feature that grew organically is exactly the kind of work a structured code quality audit should scope before the deadline pressure arrives.

3. Compile the Annex IV technical documentation. Covered in detail below — this is the artefact an authority will actually request.

4. Run the Annex VI self-assessment. Verify that the quality management system complies with Article 17 and that the technical documentation demonstrates the system meets Articles 9–15. Record who assessed what, against which evidence, and when.

5. Draw up the EU declaration of conformity (Article 47). A signed, dated document identifying the system, the provider, and the requirements it conforms to. You keep it for ten years and hand it to authorities on request.

6. Affix the CE marking (Article 48). For software, the marking goes into the documentation, the UI, or the product information — digital CE marking is explicitly permitted.

7. Register the system in the EU database (Articles 49 and 71) before placing it on the market. The registration is public for most Annex III systems.

Conformity is not a one-shot event. A substantial modification — a change not foreseen in your original assessment that affects compliance or intended purpose — triggers a re-assessment. Continuous-learning systems get some breathing room: changes anticipated and documented in the original assessment do not count as substantial. Which is a strong argument for documenting your intended model-update cadence up front.

Step 4: Keep the Annex IV Technical Documentation Audit-Ready

Annex IV is the document set that decides whether an audit is an afternoon or a quarter. It must exist before market placement and stay current. The required contents, translated into engineering terms:

Annex IV section	What it means in practice
General description	Intended purpose, provider, version, how it interacts with the host product
Detailed system description	Architecture, model(s) used, key design choices and trade-offs
Development process	Training methodology, data provenance and labelling, evaluation results
Monitoring and control	Human oversight design, expected accuracy bounds, known failure modes
Risk management records	The living output of your Article 9 process
Lifecycle change log	Versions, substantial-modification analyses, re-assessment records
Standards applied	Harmonised standards or your justification for alternative solutions
Declaration of conformity	The signed Article 47 document
Post-market monitoring plan	How field performance and incidents feed back into the risk process

Two practical habits make this sustainable. First, keep the documentation in version control next to the code, owned by engineering with legal review — documentation that lives in a lawyer's drive drifts from reality within two release cycles. Second, generate what you can: evaluation reports, logging specifications, and model version histories should fall out of your CI pipeline rather than being written by hand. Teams building AI features on a solid engineering foundation — the kind of discipline we apply in custom software development — find Annex IV largely assembles itself from artefacts they already produce.

SME relief exists: Article 11 allows small and micro enterprises to provide Annex IV information in a simplified form, and the Commission provides a simplified template. Use it if you qualify, but note that enterprise customers will often expect the full set regardless.

Step 5: Plan Against the Real Timeline

The obligations land in phases. Prohibited practices and AI literacy duties have applied since 2 February 2025. GPAI model obligations started 2 August 2025. The high-risk regime for Annex III systems applies from 2 August 2026 — that is the date your conformity assessment, documentation, and registration must be complete for systems on the EU market. High-risk systems embedded in regulated products under Annex I get until 2027.

Penalties for non-compliance with high-risk obligations reach EUR 15 million or 3% of global annual turnover. But for most SaaS vendors, the practical enforcement arrives earlier and softer: procurement questionnaires. Enterprise buyers are already asking for AI Act conformity evidence in vendor reviews, and "we have not classified our systems yet" reads the same way "we have no SOC 2" read five years ago.

FAQ

Our AI feature only assists a human who makes the final call. Are we exempt? Not automatically. Human-in-the-loop is an Article 14 requirement for high-risk systems, not an exemption from the category. The Article 6(3) carve-out applies only to narrow preparatory tasks that do not materially influence decisions — and you must document and register that assessment.

We use a third-party model via API. Is the conformity assessment the model provider's job? No. The model provider owes GPAI obligations for the model. You owe the system-level conformity assessment for your product if it is high-risk. Their documentation feeds yours; it does not replace it.

Do we need an external auditor? Almost never. Annex III systems other than biometrics use internal control under Annex VI — a documented self-assessment. Biometric systems may require a notified body.

What if we discover mid-2026 that an existing feature is high-risk? Triage immediately: scope the gap against Articles 9–15, prioritise logging and human oversight (the longest engineering lead items), and consider gating the feature for EU customers until conformity is complete rather than shipping non-compliant.

Closing

An EU AI Act conformity assessment looks bureaucratic from the outside, but for a well-run SaaS team it is mostly an exercise in making existing engineering discipline legible: risk analysis, evaluation, logging, oversight, and documentation that matches the code. Teams that start from the Annex III scope test and work the steps in order will find the internal-control route entirely manageable before August 2026. Teams that wait for the first procurement questionnaire will do the same work under deal pressure.

Wolf-Tech helps EU SaaS teams classify their AI features, close the Articles 9–15 engineering gaps, and assemble audit-ready Annex IV documentation. If a high-risk classification is looming over your roadmap, contact us at hello@wolf-tech.io or visit wolf-tech.io for a free consultation.