AI Act guide
AI Act by design: the technical requirements for high-risk AI systems
Updated: · General information, not legal advice.
In short
Designing an AI system with the AI Act in mind means building the seven requirements of Articles 9 to 15 into the architecture from the start: risk management, data governance, technical documentation, record-keeping, information to deployers, human oversight, and accuracy, robustness and cybersecurity. For high-risk systems under Annex III, these requirements apply from 2 December 2027; for those under Annex I, embedded in regulated products, from 2 August 2028.
The AI Act is a framework to comply with. No tool makes a system compliant on its own: compliance depends on the use, the organisation's role and the assessments set out in the regulation.
The current timeline
| Date | What applies | Source |
|---|---|---|
| 2 February 2025 | Prohibited practices (Article 5) | Regulation (EU) 2024/1689, Article 113 |
| 2 August 2025 | Obligations for general-purpose AI models, governance | Regulation (EU) 2024/1689, Article 113 |
| 2 August 2026 | General date of application | Regulation (EU) 2024/1689, Article 113; Regulation (EU) 2026/1744, recital 40 |
| 2 December 2027 | Requirements for Annex III high-risk systems (Article 6(2)) | Regulation (EU) 2026/1744, recital 40 |
| 2 August 2028 | Requirements for Annex I high-risk systems (Article 6(1)) | Regulation (EU) 2026/1744, recital 40 |
Regulation (EU) 2026/1744, known as the digital omnibus on AI, was published in the Official Journal on 24 July 2026. It postponed the dates originally set for high-risk systems. Sources: EUR-Lex, Regulation 2024/1689; EUR-Lex, Regulation 2026/1744.
First step: is the system high-risk?
An AI system is high-risk in two cases:
- it is a safety component of a product covered by the Annex I harmonisation legislation (machinery, medical devices, toys, etc.), or is that product itself;
- it falls within one of the Annex III areas: biometrics, critical infrastructure, education, employment, access to essential services (including creditworthiness assessment and life and health insurance pricing), law enforcement, migration, justice and democratic processes.
Article 6(3) provides that an Annex III system is not high-risk if it does not pose a significant risk, for example because it performs a narrow procedural task. This is assessed case by case and must be documented. For a sector view: AI Act and regulated sectorsFR.
The 7 requirements of Articles 9 to 15
| Article | Requirement | What the design must provide |
|---|---|---|
| 9 | Risk management system | A continuous process across the life cycle: identify, estimate and evaluate risks, adopt measures, test |
| 10 | Data and data governance | Relevant, documented training, validation and test sets, with an examination of possible biases |
| 11 | Technical documentation | The file described in Annex IV, drawn up before placing on the market and kept up to date |
| 12 | Record-keeping (logging) | Automatic recording of events over the lifetime of the system |
| 13 | Transparency and information to deployers | Instructions for use: capabilities, limitations, human oversight measures, logging mechanisms |
| 14 | Human oversight | Tools that let a person understand the system, interpret its outputs, decide not to use them, override them and interrupt the system |
| 15 | Accuracy, robustness and cybersecurity | An appropriate, declared level of accuracy, resilience to errors and protection against AI-specific attacks |
Article 12: what logs must make possible
Logs must record the events relevant for:
- identifying situations that may present a risk or lead to a substantial modification;
- facilitating post-market monitoring;
- monitoring the operation of the system by the deployer.
Source: AI Act Service Desk, Article 12.
How long to keep logs
Providers (Article 19) and deployers (Article 26(6)) keep the automatically generated logs under their control for a period appropriate to the intended purpose of the system, of at least six months, unless otherwise provided in Union or national law, in particular on personal data protection. Financial institutions keep them as part of the documentation required under financial services law.
Source: AI Act Service Desk, Article 19.
Article 14: the five human oversight capabilities
The system must enable the people assigned to oversight to:
- understand its capacities and limitations, and monitor its operation;
- remain aware of the tendency to rely automatically on its outputs (automation bias);
- correctly interpret its outputs;
- decide not to use it, or to disregard, override or reverse an output;
- intervene or interrupt it through a stop button or a similar procedure.
Source: Regulation (EU) 2024/1689, Article 14(4).
Provider or deployer: who does what
| Obligation | Provider (develops or has developed, and places on the market under its name) | Deployer (uses the system under its authority) |
|---|---|---|
| Meeting Articles 9 to 15 | Yes (Article 16) | No, unless it becomes a provider (Article 25) |
| Quality management system | Yes (Article 17) | No |
| Conformity assessment, EU declaration, CE marking, registration | Yes (Articles 43, 47, 48, 49) | Registration for certain public authorities |
| Use in line with the instructions | Not applicable | Yes (Article 26(1)) |
| Human oversight by competent, trained people with the necessary authority | The system must enable it | Yes (Article 26(2)) |
| Keeping logs, at least six months | Yes (Article 19) | Yes (Article 26(6)) |
| Fundamental rights impact assessment | No | For public bodies, private entities providing public services, and certain credit and insurance uses (Article 27) |
| Informing people subject to a decision | No | Yes (Article 26(11)) |
A deployer becomes a provider if it puts its name on the system, substantially modifies it, or changes its intended purpose so that it becomes high-risk (Article 25).
What a tool can cover, and what stays with the organisation
| Requirement | What a technical tool can provide | What stays with the organisation |
|---|---|---|
| Risk management (9) | Data on observed deviations and incidents | The process, the decisions on measures, the tests |
| Data (10) | Traceability of the sources used in each answer | Choosing data sets, their quality and the bias review |
| Documentation (11) | Exports of rules, versions and histories | Writing the Annex IV file |
| Logging (12, 19, 26) | Automatic recording and retention | Retention period, access, GDPR compliance of the logs |
| Information (13) | A description of limits and controls | The instructions for use and their distribution |
| Human oversight (14) | Validation points, holding a result, showing divergences | Appointing and training people, and giving them real authority |
| Accuracy and robustness (15) | Comparing several models, rejection rules | Setting thresholds, testing, cybersecurity of the whole system |
| Classification, conformity assessment, impact assessment | Nothing | Entirely the responsibility of the organisation and its advisers |
What KOREV AI offers and does not claim
KOREV systems are designed for regulated environments. They make some requirements easier to implement:
- Logging: KOREV Evidence keeps the steps followed and the source of each piece of information. The verifiable decision record format makes it possible to detect an altered, truncated or incomplete history (research note).
- Human oversight: validation points are defined process by process. When the policy requires a review, the output is held until a designated person, who sees the divergences, validates it.
- Robustness: KOREV PRISM has several models compare their conclusions on critical processing and holds the result if the quorum or the rules are not met (multi-model consensus).
KOREV AI claims no certification, does not carry out conformity assessments and does not provide legal advice. The AI Act assessment is a self-assessment for guidance.