What "high-risk" actually costs you
In b1 you learned to classify. The hard news is that a high-risk classification is not a label - it is a programme. The system must satisfy seven requirements. The provider must wrap it in a quality and documentation regime, prove conformity, mark it, and register it. And the deployer who uses it carries its own duties. This session gives you the full inventory so you can build a checklist that leaves nothing unowned.
The seven the system must meet 8 min live
Articles 9 through 15 set out seven requirements every high-risk system must satisfy. They are not optional extras - they are the definition of a compliant high-risk system. Learn them as a set of seven.
| Requirement | Article | What it means |
|---|---|---|
| Risk management system | Art 9 | A continuous, documented process across the whole lifecycle - identify, estimate, and mitigate risks; test; repeat. |
| Data + data governance | Art 10 | Training, validation, and test data relevant, representative, and as error-free as possible; identify and mitigate harmful bias. |
| Technical documentation | Art 11 | Drawn up before the system goes to market, per Annex IV; kept current; proves the system meets the requirements. |
| Record-keeping / logging | Art 12 | Automatic logging of events over the system's lifetime, enabling traceability of how it behaved. |
| Transparency + instructions | Art 13 | Design and instructions for use let deployers interpret output and use the system correctly. |
| Human oversight | Art 14 | Built so natural persons can effectively oversee it - intervene, override, and stop. |
| Accuracy, robustness, security | Art 15 | Appropriate levels of accuracy; resilient to errors and misuse; resistant to attempts to alter use or performance. |
LiveRisk management + data and bias (Art 9-10)3 min▶
- Risk management (Art 9): not a one-off assessment - a system that runs across the whole lifecycle. You identify known and foreseeable risks, estimate them, mitigate, then test that the mitigations work, and keep iterating as the system and its use evolve.
- Data governance (Art 10): the training, validation, and test datasets must be relevant, representative, and as free of errors as possible for the intended purpose - and you must examine them for and mitigate harmful bias. This is where a hiring model earns or loses its fairness case.
LiveDocumentation, logging, transparency (Art 11-13)3 min▶
- Technical documentation (Art 11): drawn up before the system is placed on the market, following Annex IV, and kept up to date. It is the evidence file that shows the system meets the requirements.
- Record-keeping (Art 12): the system logs events automatically over its lifetime, so behaviour is traceable and post-market monitoring and incident review are possible.
- Transparency + instructions (Art 13): the system and its instructions for use are designed so a deployer can understand and correctly interpret its output - capabilities, limitations, and the conditions it was built for.
LiveHuman oversight + accuracy and security (Art 14-15)2 min▶
- Human oversight (Art 14): the system is designed so natural persons can effectively oversee it while in use - understand it, monitor it, spot when to intervene, and override or stop it. Oversight has to be genuinely possible, not a rubber stamp.
- Accuracy, robustness, cybersecurity (Art 15): the system performs at an appropriate accuracy level, is resilient to errors and misuse, and resists attempts to alter its use or performance (for example data poisoning or adversarial attacks).
The provider wrapper + the deployer's part 8 min live
The seven requirements are about the system. Around them, the provider carries a wrapper of organisational duties - and the deployer who puts the system to work carries a separate set. Both matter, and they are frequently the same company wearing two hats.
LiveQuality management system (Art 17)2 min▶
- QMS (Art 17): the provider must run a documented quality management system - written policies, procedures, and instructions covering the whole compliance strategy: design, development, testing, data management, risk management, post-market monitoring, and record-keeping.
- Why it exists: it is the organisational backbone that makes the seven system requirements repeatable and auditable, not a one-time heroic effort for one release.
LiveKeep docs (18), keep logs (19), then prove it3 min▶
- Keep documentation (Art 18): retain the technical documentation, QMS records, approvals, and changes, and make them available to authorities on request for the required period.
- Keep logs (Art 19): retain the automatically generated logs (from Art 12) to the extent they are under the provider's control.
- Conformity assessment (Art 43): before the system goes to market, run the applicable conformity assessment procedure to demonstrate it meets the requirements.
- Declaration of conformity (Art 47) + CE marking (Art 48): draw up the EU declaration of conformity and affix the CE marking - the visible sign it has passed.
- EU database registration (Art 49): register the high-risk system in the EU database before placing it on the market.
Vantage builds the seven for its hiring tool. Vantage, a Singapore firm selling a CV-screening tool into the EU, is the provider. It stands up an Article 9 risk process, cleans and de-biases its training data under Article 10, writes the Annex IV documentation, wires in Article 12 logging, designs Article 14 oversight so a recruiter can override any ranking, and hardens accuracy and security under Article 15. Then it wraps them: a QMS (Art 17), retained docs and logs (18 and 19), a conformity assessment (43), a declaration (47), CE marking (48), and EU-database registration (49). Only then can it ship.
LiveThe deployer's duties (Art 26)3 min▶
The company that uses a high-risk system is the deployer, and Article 26 gives it its own list - separate from the provider's:
- Use per instructions: operate the system according to the provider's instructions for use.
- Human oversight: assign oversight to natural persons who are competent, trained, and have the authority to act.
- Input data: ensure input data is relevant and representative for the intended purpose, to the extent it controls that data.
- Monitor + suspend: monitor operation, and where use may present a risk, suspend and inform the provider.
- Keep logs: retain the logs the system generates for at least 6 months (unless other law says otherwise).
- Inform workers: before putting a high-risk system to use in the workplace, inform workers and their representatives.
- Report incidents + check registration: report serious incidents, and check the system is registered in the EU database before use.
Build the high-risk obligations checklist ★ 10 min
Turn the map into a checklist for one real high-risk system, and put a name on every line.
List the seven. Write Art 9-15 as seven checklist rows. For each, note whether it exists today, is partial, or is missing for your system.
Add the provider wrapper. Add rows for QMS (17), keep docs (18) + logs (19), conformity (43), declaration (47), CE (48), and registration (49).
Add the deployer duties. If you use the system, add the Article 26 rows - use per instructions, oversight, input data, monitor/suspend, 6-month logs, inform workers, report incidents, check registration.
Assign an owner. Put a named person or team against every single row. Any row without an owner is the real risk - flag it.
Before session b3 ◐ 40 min total
- Finish the seven-requirement audit for your highest-priority high-risk system: exists / partial / missing on each.
- Complete the provider wrapper rows and mark which artefacts (QMS, Annex IV docs, declaration) you can produce today.
- If you deploy the system, write your Article 26 duties and confirm the 6-month log retention is actually configured.
- Read: EU AI Act Articles 9-19 and Article 26 - the system requirements, provider obligations, and deployer duties.
Official sources covered
Taught from the EU AI Act text. This page covers ~80% of the working content on high-risk obligations.
Three questions before you go 🎯 ◐ 90 seconds
1 · How many core requirements must a high-risk system itself satisfy (Articles 9-15), and can you skip one?
Articles 9-15 set seven requirements: risk management, data governance, documentation, logging, transparency, human oversight, and accuracy/robustness/security. The system is compliant only when every one is met.
2 · Which obligation belongs to the DEPLOYER (the company using the system), not the provider?
Article 26 is the deployer list: use per instructions, assign oversight, keep logs at least 6 months, inform workers, monitor and report. Documentation, CE marking, and provider registration sit with the provider.
3 · Under Article 10, training data for a high-risk system must be...
Article 10 requires training, validation, and test data to be relevant, representative, and as free of errors as possible for the purpose - and requires examining for and mitigating harmful bias.