High-risk AI obligations under the EU AI Act
High-risk AI systems under the EU AI Act face a set of specific obligations: risk management, technical documentation, data governance, transparency, human oversight, and accuracy. This piece maps each obligation to the evidence that satisfies it.
High-risk AI systems under the EU AI Act face a set of pre-market obligations that must be satisfied before the system is placed on the market or put into service. These obligations are defined across Chapter III of the Act and cover six distinct areas: risk management, technical documentation, data governance, transparency, human oversight, and accuracy and robustness.
Each obligation has a specific evidence requirement. The question practitioners need answered is not “what does the law say?” but “what do I need to produce, and what does an AI security review contribute to that production?” This piece maps each obligation to its evidence requirement and to the artefacts a security review generates.
Who is subject to these obligations
The obligations in Articles 9–15 apply primarily to providers— organisations that develop, place on the market, or put into service high-risk AI systems in the EU. A provider is the organisation responsible for the system's design, training, and placement on the market.
Deployers — organisations that use high-risk AI systems in their own operations — have separate obligations under Article 26. These are narrower: ensuring the system is used as intended, implementing technical and organisational measures, monitoring for adverse effects, and reporting serious incidents.
The boundary between provider and deployer can shift. An organisation that makes a substantial modification to a high-risk AI system — retraining it, changing its intended purpose, or integrating it into a new pipeline in a way that changes its risk profile — becomes a provider for that modification and takes on full provider obligations. This is the most commonly overlooked provider scenario in enterprise deployments.
High-risk AI system obligations — six categories
Documented, iterative risk management covering the full lifecycle — identification, evaluation, treatment, and residual risk acceptance
Detailed technical documentation per Annex IV — system description, design process, architecture, data governance, validation results, known limitations
Training, validation, and testing data requirements — quality, relevance, representativeness, and known limitations of the datasets used
Instructions for use that allow deployers to understand the system's capabilities, limitations, and intended purpose
Technical and organisational measures enabling human monitoring, interpretation, and intervention — override capability must be built in
Documented performance levels, robustness against errors and adversarial inputs, cybersecurity measures proportionate to the risk
Article 9 — risk management
Article 9 requires providers to establish, implement, document, and maintain a risk management system. The system must be a continuous iterative process covering the full lifecycle of the high-risk AI system.
The six substantive requirements of Article 9 — risk identification, risk evaluation, risk treatment, residual risk acceptance, testing, and post-market monitoring — are described in detail in our Article 9 deep-dive. In summary, Article 9 requires documented evidence at each stage: a risk register, a control list linked to identified risks, a residual risk acceptance statement with a named acceptor, and a testing record covering both intended use and foreseeable misuse scenarios.
Annex IV — technical documentation
Annex IV defines the technical documentation that must exist before a high-risk AI system is placed on the market. This documentation must be prepared by the provider and kept up to date throughout the system's lifecycle.
Annex IV covers eight areas: general description of the system, description of the design and development process (including training methodology), system architecture, data governance documentation, performance metrics and validation results, known limitations, and expected lifetime and maintenance requirements.
For a detailed breakdown of each Annex IV requirement and the documentation gaps that appear most often, see our Annex IV technical documentation guide.
Article 10 — data governance
Article 10 sets requirements for the training, validation, and testing data used in high-risk AI systems. It requires that data management practices ensure data is relevant, representative, free of errors to the extent possible, and complete for the intended purpose.
Article 10 is structured around five requirements for training data practices:
- Relevant, representative, free of errors, and complete for the intended purpose
- Appropriate statistical properties, including for the persons or groups of persons on which the system will be used
- Examination for possible biases that could lead to risks to health, safety, fundamental rights, or discrimination
- Relevant data protection measures for personal data used in training
- Documentation of the origin, scope, and characteristics of the training dataset
For providers of foundation model-based systems — systems built on top of large pre-trained models — Article 10 data governance documentation requires disclosure from the upstream model provider. This is an area where many organisations have gaps: the foundation model provider's training data disclosure is limited, and the deployer-side documentation cannot fill what the provider has not disclosed.
Article 10 data governance is hardest to satisfy when you are building on top of a model you did not train. The obligation exists regardless of whether the model provider discloses sufficient information — the documentation gap is a control gap.
Article 13 — transparency
Article 13 requires providers to ensure that high-risk AI systems are sufficiently transparent to enable deployers to interpret the system's output and use it appropriately. This is achieved through instructions for use — a document that accompanies the system and provides deployers with the information they need.
The instructions for use must cover: the provider's identity and contact details; the system's capabilities and limitations; the level of accuracy and performance metrics; the intended purpose and conditions for use; the data required as input; and any known risks or foreseeable misuse scenarios.
Article 14 — human oversight
Article 14 requires that high-risk AI systems are designed and developed to allow effective human oversight during the period in which the system is in use. Oversight measures must enable those responsible for the system to understand its capabilities and limitations, monitor its operation, and intervene when necessary.
Article 14(4) specifies that natural persons assigned to human oversight must be able to: interpret the system's output; remain aware of the tendency to over-rely on AI output (automation bias); correctly interpret the system in the specific deployment context; and decide not to use the system or to disregard its output in any particular situation.
The critical evidence requirement for Article 14 is that the override capability exists technically, not just procedurally. A policy that says “humans can override the AI” is not sufficient if the system architecture makes override impractical. The human oversight measures must be built into the system design, and the evidence must demonstrate that the override pathway works.
Article 15 — accuracy and robustness
Article 15 requires that high-risk AI systems achieve an appropriate level of accuracy, robustness, and cybersecurity throughout their lifecycle. The regulation does not specify minimum accuracy thresholds — the requirement is that performance levels are documented, proportionate to the intended purpose, and consistent across the system's deployment context.
Robustness requirements address the system's resilience to errors, faults, and inconsistencies. Article 15(3) specifically addresses resilience against attempts to alter the system's behaviour through adversarial inputs — prompt injection, data poisoning, and similar attack vectors relevant to AI systems.
The cybersecurity requirements in Article 15(5) require that high-risk AI systems are resilient to attempts to exploit vulnerabilities that could result in harmful or unexpected behaviour. This requirement maps directly to the adversarial testing phase of an AI security review.
Evidence mapping — what a security review produces
An AI security review conducted at design time produces a defined set of artefacts. Many of those artefacts directly support EU AI Act high-risk obligations. The mapping is not perfect — some obligation areas require documentation that only the system provider can produce — but the overlap is substantial.
Obligation → evidence artefact → what a security review produces → common gap
| Obligation | Required artefacts | What a review produces | Common gap |
|---|---|---|---|
| Art. 9 — Risk management | Risk register, threat model, control list, residual risk acceptance statement | AI security review — threat modelling and control assessment phases | Residual risk acceptance without named acceptor or acceptance condition |
| Annex IV — Technical documentation | System description, architecture diagram, training methodology description, validation results, known limitations register | AI security review — system description and architecture review; supplemented by provider documentation | Architecture documentation that describes the intended design rather than the assessed system as deployed |
| Art. 10 — Data governance | Data flow diagram, training data provenance record, data quality assessment, bias analysis | AI security review — data governance section; may require provider disclosure for third-party models | Training data documentation for third-party models — providers are often reluctant to disclose training data composition |
| Art. 13 — Transparency | Instructions for use, system capabilities statement, intended purpose documentation, known limitations for deployers | AI security review — system description and capabilities assessment | Instructions that describe intended use without documenting foreseeable misuse scenarios or edge cases |
| Art. 14 — Human oversight | Human-in-the-loop (HITL) design documentation, override capability description, monitoring protocol | AI security review — HITL and oversight controls assessment | HITL described in process terms without evidence that the technical override capability exists and has been tested |
| Art. 15 — Accuracy and robustness | Performance metrics documentation, adversarial testing results, cybersecurity controls record | AI security review — accuracy assessment and adversarial testing phases | Performance metrics for the development context only, without evidence of performance in the deployment context |
The value of systematic evidence mapping is that it identifies which obligations have documentation and which have gaps. An organisation that has completed AI security reviews on its high-risk systems has a head start on EU AI Act documentation — the question is whether the review evidence has been structured to be reusable for regulatory purposes.
For a detailed gap analysis methodology — identifying which EU AI Act obligations are not yet covered by existing review evidence — see the evidence mapping guide.
Blog
Get new posts in your inbox
AI security review, OWASP Agentic Top 10, ISO 42001 evidence, and what AI Committees actually need. No cadence promises — we publish when there's something worth reading.
Map your high-risk obligations to evidence
Drel's AI security review process produces the artefacts that support EU AI Act high-risk obligations — from threat model to residual risk acceptance — structured for reuse as regulatory evidence.
A note on scope: Drel reviews assessed systems against documented architecture, configuration and intent. It does not ingest live telemetry from production environments. Dispositions reflect the assessed system at the time of review and the re-assessment triggers that govern when the disposition must be revisited.