Chapter III · Section 3 · Obligations of providers and deployers of high-risk AI systems and other parties
Article 16 — Obligations of providers of high-risk AI systems
▼ Primary text, verbatim. Our annotations appear below, visibly separated.
Providers of high-risk AI systems shall:
(a) ensure that their high-risk AI systems are compliant with the requirements set out in Section 2;
(b) indicate on the high-risk AI system or, where that is not possible, on its packaging or its accompanying documentation, as applicable, their name, registered trade name or registered trade mark, the address at which they can be contacted;
(c) have a quality management system in place which complies with Article 17;
(d) keep the documentation referred to in Article 18;
(e) when under their control, keep the logs automatically generated by their high-risk AI systems as referred to in Article 19;
(f) ensure that the high-risk AI system undergoes the relevant conformity assessment procedure as referred to in Article 43, prior to its being placed on the market or put into service;
(g) draw up an EU declaration of conformity in accordance with Article 47;
(h) affix the CE marking to the high-risk AI system or, where that is not possible, on its packaging or its accompanying documentation, to indicate conformity with this Regulation, in accordance with Article 48;
(i) comply with the registration obligations referred to in Article 49(1);
(j) take the necessary corrective actions and provide information as required in Article 20;
(k) upon a reasoned request of a national competent authority, demonstrate the conformity of the high-risk AI system with the requirements set out in Section 2;
(l) ensure that the high-risk AI system complies with accessibility requirements in accordance with Directives (EU) 2016/2102 and (EU) 2019/882.
This text is meant purely as a documentation tool and has no legal effect. The Union's institutions do not assume any liability for its contents. The authentic versions of the relevant acts, including their preambles, are those published in the Official Journal of the European Union and available in EUR-Lex.
What this means for you
In your terms · Data and data governance
Dataset lineage is yours: where each set came from, how it was prepared, what its gaps are, and the bias examination that was actually run.
- Dataset cards with provenance
- Bias examination report
Failure smells likeSomeone asks which data the model was trained on and the answer is a bucket path, with no record of how the set was assembled or what it was assumed to represent.
In your terms · Data and data governance
Lineage only holds if the pipeline records it: per-training-run records tying model versions to exact dataset versions.
- Per-run lineage records
In your terms · Data and data governance
The data assumptions are yours to state. Article 10(2)(d) asks for the assumptions about what the data is supposed to measure and represent, and that is a product claim about a population, not an engineering detail.
- Stated assumptions per data set
- Representativeness note for the target population
In your terms · Data and data governance
Bias-correction processing of sensitive data has its own conditions; that trade-off is decided with your privacy function.
In your terms · Technical documentation
The Annex IV file describes your system, and drift makes it wrong. Generate what can be generated from the source of truth instead of hand-maintaining prose.
- Annex IV technical file
- Doc generation wired into CI
Failure smells likeThe documentation describes the system as it was designed two releases ago, and nothing in the pipeline forces it to move with the code.
In your terms · Technical documentation
Intended purpose, as written here, bounds everything else: it decides classification and what misuse means.
In your terms · Technical documentation
Decide early whether the simplified SME form applies to you; it changes the documentation workload materially.
- Documentation format decision on record
In your terms · Automatic recording of events
Logging capability is a design-time decision, not a config you bolt on later: correlation IDs and event coverage live in the code.
- Decision-correlation IDs across services
In your terms · Automatic recording of events
You already have the pipeline. The gap is usually schema and retention: events rich enough to reconstruct one specific decision on one specific date, protected against tampering.
You already haveA log pipeline and retention config. The gap is decision-grade fidelity, not plumbing.
- Inference event schema
- Tamper-evident log storage
- Replay runbook
Failure smells likeA regulator asks why one decision happened on one date, and the best answer available is a dashboard screenshot.
In your terms · Automatic recording of events
This is the obligation that makes answering why the system decided something possible at all.
In your terms · Automatic recording of events
Long-retention, full-fidelity decision logs are a real storage line item and a real privacy surface; budget both.
In your terms · Transparency and instructions for deployers
Interpretability of output is partly interface design: expose confidence, provenance and known failure modes where the deployer can see them.
- Output metadata deployers can read
In your terms · Transparency and instructions for deployers
Part of the instructions is operational fact: Article 13(3)(e) wants the computational and hardware resources, the expected lifetime and the maintenance and update cadence. Those numbers come from you, and whatever gets printed becomes the commitment operations is held to.
- Resource, lifetime and maintenance inputs for the instructions
In your terms · Transparency and instructions for deployers
The instructions for use are a product artifact: what the system is for, what it must not be used for, and what the deployer has to set up.
- Instructions for use per system
Failure smells likeA deployer uses the system for something it cannot actually do well, and the instructions never said where the edge was.
In your terms · Human oversight
The stop and override paths have to exist in the architecture, tested like any other critical path.
- Kill switch and override, with tests
In your terms · Human oversight
Oversight needs operational teeth: alerting a human can act on, and a runbook for actually stopping the system.
- Oversight runbook
In your terms · Human oversight
Oversight is a runtime capability with real access paths: who can override, on what screen, with what information in front of them.
- Oversight UX with override path
Failure smells likeThe oversight step exists on the screen, but the person doing it has no basis on which to disagree with the output and no way to stop the system.
In your terms · Accuracy, robustness and cybersecurity
Adversarial input, prompt injection and poisoning resistance are test suites, not adjectives.
- Adversarial and injection test suite
In your terms · Accuracy, robustness and cybersecurity
Declared once, held every day after: the accuracy and resilience levels in the documentation become production SLOs with monitoring behind them.
- Model performance SLOs with alerts
Failure smells likeThe accuracy declared in the technical file drifts from production metrics with nobody watching the gap.
In your terms · Accuracy, robustness and cybersecurity
Article 15(3) requires the accuracy levels and the relevant metrics to be declared in the instructions for use. Whichever number you publish becomes the promise the system is measured against, so it is a product decision before it is a benchmark.
- Declared accuracy levels and metrics
In your terms · Accuracy, robustness and cybersecurity
The declared levels go into the technical documentation; overdeclaring creates a standing gap between paper and production.
In your terms · Risk management system
Risk treatments become design constraints and test cases; each identified risk should map to something you can point at in the codebase.
- Risk-to-control mapping in the design docs
In your terms · Risk management system
Risk management is not a document you sign once. Article 9(2)(c) feeds it from the post-market monitoring system, which is your telemetry: the risks that only appear in the field reach the register through you or they do not reach it.
- Field-risk signal feed into the register
- Escalation path for emergent risk
In your terms · Risk management system
Foreseeable misuse is a product question: how will people actually use, and abuse, this feature.
- Foreseeable-misuse analysis per release
In your terms · Risk management system
Someone has to own the loop: a living risk register wired into how the system actually changes, reviewed on a cadence you can evidence.
- Living risk register with review cadence
Failure smells likeThe risk register's last edit predates the last three releases.
Obligations derived from this article
Scenarios that touch this provision
A CV-screening feature in your product
Illustrative
You are about to ship a feature that ranks and filters job applications for the companies that use your hiring product.
- Your role
- ProviderDeployer
- Where it lands
- High risk 2 Dec 2027
- Decided by
- Annex III, point 4(a): systems intended to be used for the recruitment or selection of natural persons, in particular to analyse and filter job applications and to evaluate candidates.
What applies
- Risk management system
- Data and data governance
- Technical documentation
- Automatic recording of events
- Transparency and instructions for deployers
- Human oversight
- Accuracy, robustness and cybersecurity
- Conformity assessment
- EU declaration of conformity and CE marking
- Registration in the EU database
- Keeping the automatically generated logs
- Post-market monitoring
- Serious incident reporting
What you have to be able to produce
- Adversarial and injection test suite
- Annex IV technical file
- Authority notification runbook
- Bias examination report
- Conformity route decision per system
- Dataset cards with provenance
- Decision-correlation IDs across services
- Declared accuracy levels and metrics
- Doc generation wired into CI
- Documentation format decision on record
- Escalation path for emergent risk
- EU declaration of conformity per system
- Field-data review cadence
- Field-risk signal feed into the register
- Foreseeable-misuse analysis per release
- Incident classification with regulatory branch
- Inference event schema
- Instructions for use per system
- Kill switch and override, with tests
- Living risk register with review cadence
- Model performance SLOs with alerts
- Named reporting roles
- Output metadata deployers can read
- Oversight runbook
- Oversight UX with override path
- Per-run lineage records
- Post-market monitoring plan
- Registration entries per system
- Replay runbook
- Representativeness note for the target population
- Resource, lifetime and maintenance inputs for the instructions
- Restore test on aged logs
- Retention budget and DPO sign-off
- Retention policy meeting the six-month floor
- Risk-to-control mapping in the design docs
- Stated assumptions per data set
- Tamper-evident log storage
- Versioned field telemetry
What would change the answer
- The Article 6(3) derogation is the only way out, and a system that performs profiling of natural persons never qualifies. Ranking candidates is hard to argue as a narrow procedural task.
- Your customers are deployers of this system and carry Article 26 duties, including keeping the logs under their control and telling candidates they are subject to it.
- A customer who puts its own brand on your feature becomes its provider under Article 25(1)(a), and you stop being it.
If you would rather not read the law
The basics page explains the Regulation's own categories in order: scope, role, tier, date. The engineering view groups the obligations by the platform capability they demand.