EU AI Act
EU AI Act high-risk checklist: classification, Articles 9 to 15 and deployer duties
A high-risk AI system is one that falls under Annex III (eight areas) or is a safety component of, or is itself, a product under Annex I that needs third-party conformity assessment. Annex III obligations apply from 2 December 2027 and Annex I from 2 August 2028. This checklist walks classification, provider duties (Articles 9 to 15, 17) and deployer duties (Articles 26 and 27), and you can copy it to your own file.
Who this applies to
- Providers of high-risk AI systems
- Chapter III Section 2 (Articles 8 to 15) and the provider duties in Article 16, including a quality management system (Art. 17), conformity assessment, registration and post-market monitoring.
- Deployers of high-risk AI systems
- Article 26 duties, and Article 27 fundamental rights impact assessment for public bodies, private entities providing public services, and deployers of Annex III points 5(b) and 5(c).
- Anyone who changes a system
- Under Article 25 a deployer, importer or distributor becomes the provider by putting its name on a high-risk system, making a substantial modification, or changing a system's intended purpose so that it becomes high-risk.
Step 1: is the system high-risk?
Classification follows Article 6 and Annex III, both as amended by the Digital Omnibus.
| Route | Test | Applies from |
|---|---|---|
| Article 6(1), Annex I | The system is a safety component of a product, or is itself a product, covered by Annex I harmonisation law, and that product must undergo third-party conformity assessment. The Omnibus narrowed "safety component": AI used only for assistance, optimisation, efficiency, automation, convenience or quality control is not one unless its failure would endanger health or safety. | 2 Aug 2028 |
| Article 6(2), Annex III | The system is used in one of the eight Annex III areas listed below. | 2 Dec 2027 |
The eight Annex III areas:
- Biometrics, where permitted by law: remote biometric identification (not one-to-one verification), biometric categorisation by sensitive attributes, emotion recognition.
- Critical infrastructure: safety components in critical digital infrastructure, road traffic and the supply of water, gas, heating or electricity.
- Education and vocational training: access and admission, evaluating learning outcomes, assessing education level, monitoring prohibited behaviour in tests.
- Employment and workers management: recruitment and selection, decisions on terms, promotion or termination, task allocation based on behaviour or traits, performance monitoring and evaluation.
- Essential private and public services: eligibility for public benefits, creditworthiness and credit scoring (fraud detection is excepted), life and health insurance risk and pricing, emergency call classification, dispatch and triage.
- Law enforcement, where permitted by law.
- Migration, asylum and border control, where permitted by law.
- Administration of justice and democratic processes.
The Article 6(3) derogation. An Annex III system is not high-risk if it poses no significant risk to health, safety or fundamental rights and meets at least one of four conditions: it performs a narrow procedural task; it improves the result of a human activity already completed; it detects decision-making patterns or deviations without replacing or influencing the earlier human assessment absent proper human review; or it performs a preparatory task. It is always high-risk if it profiles natural persons. A provider that relies on the derogation must document the assessment before market placement and is subject to the registration duty in Article 49(2) (Article 6(4)). Commission draft guidelines published for consultation in May 2026 reportedly read these conditions narrowly (secondary source: Bird & Bird).
Step 2: provider duties, Articles 9 to 15 and 17
| Article | Requirement | Evidence a reviewer will ask for |
|---|---|---|
| Art. 9 | A continuous, iterative risk management system across the lifecycle: identify and analyse foreseeable risks to health, safety and fundamental rights, evaluate them under intended use and foreseeable misuse, adopt targeted measures, judge residual risk, and test against pre-defined metrics. Consider impact on under-18s and other vulnerable groups. | Risk register, test plans and results, residual-risk decision. |
| Art. 10 | Data and data governance: training, validation and testing data sets must be relevant, sufficiently representative and, as far as possible, free of errors and complete. | Data provenance and quality records. |
| Art. 11 | Technical documentation per Annex IV, drawn up before market placement and kept up to date. Simplified for SMEs and small mid-caps. | Annex IV file. |
| Art. 12 | Automatic recording of events (logs) over the system's lifetime. | Log specification and samples. |
| Art. 13 | Transparency: operation must be interpretable by deployers, with instructions for use covering identity, characteristics, capabilities, limitations and accuracy metrics. | Instructions for use. |
| Art. 14 | Human oversight: designed so natural persons can effectively oversee, understand limits, watch for automation bias, interpret outputs, and decide not to use, override or stop the system. | Oversight design, interface description. |
| Art. 15 | Appropriate accuracy, robustness and cybersecurity throughout the lifecycle, with accuracy metrics declared; measures against attacks such as data and model poisoning and adversarial examples. | Test results, security testing. |
| Art. 17 | A documented quality management system. Proportionate for small mid-caps; simplified for all SMEs after the Omnibus. | QMS manual and procedures. |
Providers also complete conformity assessment, draw up the declaration of conformity, apply CE marking, register the system, run post-market monitoring (Art. 72) and report serious incidents (Art. 73). Harmonised standards that would give a presumption of conformity have not yet been cited in the Official Journal, according to the Commission FAQ (updated 10 March 2026), so do not assume that following a standard shifts the burden of proof yet.
Step 3: deployer duties, Articles 26 and 27
From Article 26 and Article 27.
- Take technical and organisational measures to use the system according to the provider's instructions for use (26(1)).
- Assign human oversight to people with the necessary competence, training and authority, and give them support (26(2)).
- Where you control the input data, make sure it is relevant and sufficiently representative for the intended purpose (26(4)).
- Monitor operation. If use may create a risk, inform the provider or distributor and the market surveillance authority without undue delay and suspend use. For a serious incident, notify the provider first, then the importer or distributor, then the authorities (26(5)).
- Keep automatically generated logs under your control for a period suited to the purpose, of at least six months, unless other law sets a different period (26(6)).
- Before using a high-risk system at work, inform workers' representatives and affected workers (26(7)).
- Use the provider's Article 13 information to carry out your GDPR Article 35 DPIA (26(9)); see DPIA for AI.
- Where Annex III systems make or assist decisions about natural persons, inform those persons (26(11)).
- Cooperate with competent authorities (26(12)).
- If you are a public body, a private entity providing public services, or a deployer of Annex III 5(b) or 5(c) systems, carry out a fundamental rights impact assessment before first use and notify the market surveillance authority (Art. 27). It complements your DPIA.
Copy-and-complete checklist
High-risk readiness checklist
0 of 23 ticked
Ticks stay in your browser and are not sent to Swfte. This is a structure to complete, not legal advice.
How the platform supports it
Each row maps a requirement to a platform control, the evidence artifact it produces, and the Trust & Governance Fabric facets involved. Swfte provides the controls and the evidence. You remain responsible for the decisions.
| Requirement | Platform control | Evidence artifact | Fabric facets |
|---|---|---|---|
| Inventory, role and risk tier per AI system | Trust Profile: identity, owner, risk level, approved models, data classification, permitted systems. | Trust Profile export. | Identity, Risk, Compliance |
| Art. 9 and 15: risk management and testing evidence | Risk levels and thresholds that decide approval; monitoring of behaviour and policy denials. | Risk threshold configuration; monitoring records. | Risk, Monitoring, Security |
| Art. 10: data governance | Data classification and boundaries on what an agent can read and write. | Classification map and data-access records. | Data controls, Privacy |
| Art. 12 and Art. 26(6): logs of at least six months for deployers | Per-action audit trail tied to identity, model, tools, policy and outcome. | Exportable audit log with retention set by your policy. | Auditability, Traceability, Evidence |
| Art. 14 and Art. 26(2): human oversight | Human-approval rules and escalation by autonomy level. | Approval records per decision. | Human oversight, Access |
| Art. 26(5): monitoring and incident escalation | Live monitoring plus reconstructable action trace. | Incident timeline from the trace. | Monitoring, Traceability |
Compliance-by-design. Swfte provides the technical controls, governance mechanisms and evidence to support deployment within applicable requirements. The exact posture depends on your use case, jurisdiction, deployment and configuration. This is not legal advice.
Hosting today: customer data is stored in AWS eu-west-1 (Ireland), as stated on the trust page. EU region, in-country, dedicated and on-prem options are the platform position: what it is designed to let you do, scoped with you through a dedicated deployment engagement, not self-serve.
What this does not cover
- Swfte does not decide whether your system is high-risk or perform a conformity assessment. It cannot affix CE marking or register a system for you.
- It does not write your Annex IV documentation or your instructions for use. It supplies records that feed them.
- It does not give a presumption of conformity. No harmonised standard has yet been cited in the Official Journal for this purpose.
- If you build a high-risk system on a model from a third party, the model provider's documentation remains theirs to supply. Article 25(4) expects a written agreement on information and access.
Frequently asked questions
When do the high-risk obligations apply?
Annex III obligations apply from 2 December 2027 and Annex I product-embedded obligations from 2 August 2028, per Regulation (EU) 2026/1744. They were originally 2 August 2026 and 2 August 2027.
Is a CV-screening tool high-risk?
Employment recruitment and selection, including candidate evaluation and application filtering, is an Annex III area. The Article 6(3) derogation is narrow and does not apply to systems that profile natural persons. Classification depends on what your tool actually does, so take legal advice.
What must deployers keep logs for?
At least six months for automatically generated logs under their control, unless other EU or national law, such as data protection law, sets a different period (Article 26(6)).
Do we need a fundamental rights impact assessment?
Under Article 27, public bodies, private entities providing public services, and deployers of Annex III points 5(b) (creditworthiness) and 5(c) (life and health insurance) must carry one out before first use. It complements the GDPR DPIA.
Can we rely on ISO/IEC 42001 instead of a QMS?
Not as a substitute. The Commission FAQ says an AI management-system standard does not match the AI Act quality management requirement, which is why the Commission requested a dedicated quality-management standard. A management-system structure can still help you organise the work.
Does Swfte take care of our high-risk obligations?
No platform does that on its own. Swfte is built compliance-by-design: it provides the technical controls, governance mechanisms and evidence to support deployment within applicable requirements. The exact posture depends on your use case, jurisdiction, deployment and configuration.
Sources
Last verified 2026-10-06. Primary sources are EUR-Lex and European Commission pages. Items marked as secondary are commentary or trackers; check the primary text before relying on them.
- Regulation (EU) 2026/1744, the Digital Omnibus on AI (EUR-Lex) (Adopted 8 July 2026, published 24 July 2026, in force 27 July 2026.)
- AI Act Article 6, classification (AI Act Service Desk)
- AI Act Annex III (AI Act Service Desk)
- AI Act Article 9, risk management (AI Act Service Desk)
- AI Act Article 26, deployer obligations (AI Act Service Desk)
- AI Act Article 27, fundamental rights impact assessment (AI Act Service Desk)
- AI Act Article 25, responsibilities along the value chain (AI Act Service Desk)
- European Commission: understanding standardisation under the AI Act (FAQ) (Last updated 10 March 2026.)
- Regulation (EU) 2024/1689, the AI Act (EUR-Lex)
- Bird & Bird: the Commission's draft high-risk AI guidelines (Secondary commentary on draft guidelines.)
Across the platform
The controls on this page are part of the Trust & Governance Fabric that runs through every layer of the Sovereign Intelligence Platform.
AI governance
Governance that runs inside AI, not beside it.
AI sovereignty
Seven kinds of control over your AI estate.
Trust Profile
The record of what each AI system is and may do.
Trust centre
What Swfte can show today, and what it does not claim.
Build EU-first AI with the evidence already running
Start with one entry point. Add governance, in-region options and evidence as your requirements grow.