Article 9 Risk management system: requirements and evidence

What the Article 9 risk management system requires before a high-risk AI system reaches the market

A provider placing a high-risk AI system on the EU market must run a documented risk management system that stays active for the whole life of the system, not only until launch. Article 9 asks the provider to keep identifying known and reasonably foreseeable risks to health, safety and fundamental rights, estimate how serious and how likely each one is under the intended purpose and foreseeable misuse, and evaluate what the system does once it is in use. The risk this addresses is harm that appears only after deployment: a model that performs well on a validation set but fails for a subgroup of users, a workflow where staff trust the output too readily, or a use that the vendor never designed for but that customers adopt anyway. The provider has to plan for these before the system ships, then keep the plan current.

The difficulty is ownership. Product teams own the use case, data science owns the model, security owns the infrastructure, and compliance owns the documentation, and no single role sees the whole system. Risk registers are often written once for a launch review and then left alone while prompts, training data, integrations and customer contexts change. Under Article 9, a register that does not change with the system is evidence of a failure, not of a process. Before market placement, the provider should confirm who signs off each risk decision, how post-market data from monitoring reaches the register, and which trigger forces a re-assessment. Those answers, more than the template chosen, determine whether the process holds up at audit.

Start by mapping the system to its intended purpose and listing the people and groups it touches, including any likelihood that minors or other vulnerable people will be exposed. Then ask who owns each risk, what evidence would show the risk is controlled, and what happens when the evidence changes. Providers already running an information security or quality management process may be able to fold these steps into it, as Article 9 allows, but the AI-specific hazards still need their own entries. Confirm with your legal and notified body advisers which Annex and which timeline apply to your system, since the 2026 amendments changed the application dates for high-risk rules.

Which systems, teams and third parties Article 9 reaches in practice

Article 9 applies only once a system is confirmed as high-risk, and the size of the risk management effort depends on a few early scoping choices. The cards below cover the decisions that most change who does the work and how much evidence has to be built.

Annex III or Annex I route

A system becomes high-risk either because it falls within a use case listed in Annex III or because it is a safety component of, or a product covered by, a sectoral law listed in Annex I. The route determines which conformity assessment applies and which dates govern the work. Under the 2026 amendment, Annex III systems follow the 2 December 2027 date and Annex I product systems follow 2 August 2028. Confirm the route in writing before scoping Article 9 evidence, because Annex I products may need notified body involvement that Annex III systems usually do not.

Provider or deployer role

Providers own the full risk management system, including the design-stage analysis, testing against predefined metrics and the residual risk decision. Deployers have narrower duties tied to how they use the system, such as following the provider's instructions and monitoring the system in their own context. An organization that customizes a vendor system for its own use may move into the provider role. Map each system to a role before allocating Article 9 tasks, and record the reasoning so an assessor can follow it.

Teams that hold risk inputs

Article 9 is a cross-functional process. Product teams define intended purpose and foreseeable misuse, data teams know training and validation limits, security teams own adversarial and cyber threats, legal teams interpret obligations and affected rights, and customer support sees real-world failures first. Each team holds inputs the risk file needs. Name an owner for each input, set a review cadence, and confirm how post-market feedback from support reaches the risk register.

Systems built on third-party models

When a system is built on a general-purpose model supplied by another company, risk ownership splits. The model provider documents the model's known limits, while the organization building the high-risk system must assess how that model behaves in its own intended use, data and users. Request the upstream model documentation, version history and change notices in the contract. Ask the supplier which risks it has already evaluated so that your team does not duplicate or miss them.

Folding Article 9 into existing risk rules

Article 9(10) allows providers already subject to internal risk management rules under other Union law to make the Article 9 steps part of those procedures or combine them. Financial entities under DORA or organizations under NIS2 often run such processes. The practical check is whether the existing procedure covers health, safety and fundamental rights, lifecycle review and the residual risk test. Where gaps exist, extend the existing process rather than building a parallel one. Ask the compliance lead to confirm the mapping in writing.

How an assessor tests the Article 9 risk management system

This table compares each part of Article 9 by how an assessor tests it, the evidence requested and the findings that most often appear. Read it as a chain: every risk should lead to a measure, a test and a post-market check, and the review route depends on whether the system falls under Annex III internal control or a notified body.

Article 9 element	Test approach	Evidence requested	Common findings
Documented process	Confirm a written risk management system exists, covers the full lifecycle and is run as a continuous, iterative process rather than a one-time exercise	Risk management policy, process description, roles, review cycle and dated version history	Process exists on paper but no evidence of reviews after launch; ownership unclear
Identification and estimation	Sample risks and check they cover intended use and reasonably foreseeable misuse, including effects on health, safety and fundamental rights	Risk register with hazard descriptions, scenarios, affected persons and estimation method	Misuse cases missing; risks framed only as technical failures and not as harms to people
Residual risk acceptability	Check each residual risk is judged acceptable, that elimination by design was considered first, then controls, then information for deployers	Residual risk assessment, acceptance decisions with named approver, Article 13 information and training material	Acceptance recorded without rationale; mitigations referenced but not tested
Testing against predefined metrics and thresholds	Verify metrics and probabilistic thresholds were defined before testing and fit the intended purpose, with results before market placement	Test plans with metrics fixed in advance, threshold justification, test reports and pass or fail decisions	Metrics chosen after results are known; thresholds not linked to the intended purpose
Post-market feedback	Trace whether monitoring data, incidents and deployer feedback feed back into risk estimates and measures	Post-market monitoring plan, incident log, change records showing risk register updates	Monitoring data collected but never reviewed against the risk register
Persons under 18 and vulnerable groups	Check the provider considered whether the system is likely to affect minors and other vulnerable groups, and what was done about it	Impact analysis for affected groups, decisions on safeguards or exclusions, and rationale when none were needed	Analysis absent or generic; no evidence the findings changed design or instructions
Traceability chain	Select a risk and follow it to a measure, a test result and a post-market check	Linked records across risk register, design documentation, test reports and monitoring logs	Links broken between documents, so the assessor cannot confirm the risk was actually addressed
Review route	Confirm whether internal control under Annex VI or a notified body reviews the system, based on its Annex III or Annex I category	Conformity assessment route decision, technical file index and, where applicable, the notified body's certificate	Route chosen without checking whether the system is covered by a notified body requirement

Building an Article 9 risk management system in sequence

This sequence turns Article 9 from a principle into a documented, repeatable process that covers each high-risk system from scoping through post-market review. Each step names the record it produces, so an assessor can trace a decision back to its evidence.

Scope the systems and intended purposes
Start by listing every AI system in scope and stating, for each one, its intended purpose, the people it affects, the context of use and the deployer roles involved. The organization owns this step, with input from product, legal and the business owners who will rely on the outputs. It is done when each system has a one-page scope record that names its intended purpose and boundaries, and that record is approved by a named accountable owner. Confirm early whether each system falls under Annex III or Annex I, because that determines the dates that apply.
Build the risk register with hazards and misuse
For each scoped system, identify known and reasonably foreseeable risks to health, safety and fundamental rights. Estimate each risk under intended use and under foreseeable misuse, and record the hazard, the affected groups, the likelihood basis and the potential harm. Include the possibility of use by minors and other vulnerable groups, which Article 9(9) asks providers to consider. Done means a register where every hazard has an identifier, an estimate and an owner, and where misuse cases have been reviewed by people outside the build team.
Set acceptability criteria and the residual risk rule
Define in writing what counts as acceptable residual risk for each hazard and for the system overall. Document the decision order that Article 9(5) describes: eliminate by design first, then mitigate and control, then provide information to deployers under Article 13 and, where appropriate, training. Name the approver who signs off each residual risk decision and the conditions that would reopen it. The output is an acceptability policy and a residual risk sign-off record for each hazard. Confirm with counsel and your notified body or auditor, if one is involved, how they expect the criteria to be justified.
Define test metrics and thresholds before development
Before engineering work reaches its testing phase, set the metrics that will show whether each mitigation works and the probabilistic thresholds that define a pass. Article 9(6) and 9(8) expect these to be defined in advance and suited to the intended purpose. Record the metric, the threshold, the test data source, the test environment and the reason the threshold fits the purpose. Done means the metrics are version-controlled and locked before the test cycle starts, so that results cannot be reinterpreted after the fact.
Run and record pre-market tests
Execute the tests against the predefined metrics during development as appropriate and, in any event, before the system is placed on the market. Keep the raw results, the configuration tested, the tester, the date and any failures with their remediation. Where the tests include adversarial or misuse scenarios, log each attempt and outcome so the evidence can be reviewed. Done when every hazard in the register links to a test result and an accepted residual risk decision, and any test that failed is either fixed and retested or formally accepted. Tooling such as garak can produce attempt-level reports for language model probes, but the organization must still decide what the results mean.
Set post-market review and re-assessment triggers
Define how post-market data will be collected, reviewed and fed back into the register. Article 9(2) requires evaluation of post-market data, and Article 9(7) allows real-world testing under Article 60 where it applies. List the triggers that force a new assessment, such as a material model change, a new deployment context, a serious incident, drift in monitored metrics or new complaints. The output is a monitoring plan with data sources, review thresholds and a documented re-assessment procedure. Confirm how these triggers connect to the incident and post-market monitoring duties in the provider obligations.
Assign owners and set the review cadence
Name one accountable owner for each risk management record and a delegate, and define who reviews the register, how often, and who can approve changes. Record the review cadence in the governance policy and link the risk management process to any existing risk procedures, which Article 9(10) allows you to combine. Done means every record has an owner, a review date and a change log, and the management body has seen the summary. Where you plan to align documents to prEN 18228, the AI risk management standard under public enquiry until the end of July 2026, confirm its status with CEN-CENELEC before you map your procedures to it.

Judging residual risk, predefined metrics and minors and vulnerable groups

Auditors probe three judgment points in Article 9 more than any other: whether residual risk is acceptable, whether testing was run against metrics fixed in advance, and whether the provider considered minors and vulnerable groups. For residual risk, Article 9(5) requires the provider to judge the remaining risk for each identified hazard and for the system overall as acceptable. The order of measures matters. The provider should first try to eliminate the risk through design, then apply mitigation and controls, and only then rely on information under Article 13 and, where appropriate, training for deployers. A residual risk register that records each hazard, the measure applied at each step, the reasoning for accepting what remains, and who signed off is the evidence an assessor will ask for first.

Article 9(6) and 9(8) require testing against metrics and probabilistic thresholds defined before testing starts, suited to the intended purpose. Fixing these values after results come in is the most common weakness an assessor finds, so the metrics, thresholds and test datasets should be versioned and approved before the first test run. Where the system is tested in real conditions, Article 9(7) allows this under Article 60, and the conditions of that testing need their own records. Article 9(9) requires the provider to consider whether the system is likely to adversely affect persons under 18 and, as appropriate, other vulnerable groups. Confirm with your legal team how age and vulnerability are defined in your markets, and record the analysis even when the conclusion is that no specific measures are needed.

*Illustrative example:* a provider of a high-risk system that ranks job applicants sets a threshold that the false-negative rate for applicants in one age band may not exceed a value agreed before testing. Testing shows the threshold is missed for the youngest applicants. The register then shows elimination was considered (for instance, removing a feature that correlates with age), mitigation was added, and the remaining risk was judged against the documented threshold before release.

Evidence that passes an Article 9 review and how to keep it current

Article 9 is judged on documents that show a risk management process actually ran across the lifecycle. The cards below cover the artifacts an assessor or market surveillance authority is likely to ask for, and the routine that keeps each one current between formal reviews. Tools can hold and generate parts of this evidence, but the organization still owns the decisions behind it.

Risk management file and version history

This is the master document describing the risk management system: scope, roles, the process steps, the review cadence and the criteria used to judge risk. Article 9 treats the process as continuous, so the file must show how it changed over time, not just its current state. Keep a dated version history with the reason for each change, the approver and the system version it applies to. Check at each release that the file still matches how the team actually works. Tools such as CISO Assistant (AGPL-3.0-only) can hold risk and compliance assessments, but you must confirm that it fits your model and environment before relying on it for this file.

Hazard and misuse register

The register lists known and reasonably foreseeable risks to health, safety and fundamental rights, estimated under intended use and foreseeable misuse. Each entry should name the hazard, the affected persons, the cause, the likelihood and severity estimate, and the measure that addresses it. Refresh it when post-market data, incidents or new use cases arrive, and record entries that were closed as well as those still open. Assessors often test whether misuse scenarios were considered at all, so review the list against real deployment feedback and document what was ruled out and why.

Residual risk decisions with sign-off

For each hazard and for the system overall, the file must record a judgment that the residual risk is acceptable. The record should show the order of measures applied: elimination by design first, then mitigation and controls, then information for deployers and training where appropriate. Name the accountable person who signed each decision, the evidence relied on and the conditions attached. Revisit these decisions whenever a measure changes or a new hazard is added, and keep the superseded decisions so the history stays readable.

Pre-market test plans and results

Article 9 expects testing against metrics and probabilistic thresholds defined before testing starts, during development where appropriate and in any event before the system is placed on the market. Keep the test plan with its predefined metrics and thresholds, the datasets used, and the results against each threshold, including failures and the fixes that followed. For language model components, garak (Apache-2.0) writes a JSONL report of every probe and attempt plus a hit log of successful ones, which can serve as raw test output. Confirm that its probes match your intended purpose and environment.

Post-market monitoring and re-assessment triggers

Post-market data feeds back into the risk process, so the file needs monitoring records and a written list of triggers that force a re-assessment, such as a new model version, a changed intended purpose, a serious incident or a shift in the user population. Log each trigger, the review performed and the outcome. Langfuse (MIT) traces capture inputs, outputs, tool executions, timing, token usage and metadata for each request, which can support this monitoring if you have confirmed the data handling and retention settings meet your obligations.

Link to existing risk procedures

Article 9(10) allows providers already bound by risk management rules under other Union law to fold these steps into those procedures or run them together. If you use this route, keep a mapping record that shows which AI Act steps sit inside which existing procedure, who owns each step and where the evidence is stored. Review the record whenever either the AI Act process or the sector procedure changes, and confirm with counsel that the combined approach covers every element of Article 9 rather than only the overlapping parts.

What meeting Article 9 costs in money and effort

This table compares the main cost components of an Article 9 risk management system, who gets paid for each, whether it is one-time or recurring, and what moves it up or down. Use it to build a written scope and to ask vendors and assessors for figures, since no prices or durations are published here.

Cost component	Who is paid or who bears it	One-time or recurring	What drives it up or down
Tooling and licenses	Software vendors, or no license fee for self-hosted open-source tools	Recurring if subscriptions apply; one-time setup for self-hosting	Open-source tools such as CISO Assistant (AGPL-3.0-only) remove license spend but still need hosting, configuration and staff time
Risk workshops and documentation	Internal risk, product and legal staff, plus any consultant facilitating	One-time for initial register, recurring for each material change	Number of hazards, intended purposes and deployer contexts; a clear scope reduces repeat sessions
Engineering time for testing and metrics	Internal ML and platform engineers, or an implementation partner	One-time to define metrics and test harness, recurring to run them	Number of models, metric complexity and how many probabilistic thresholds must be justified
Adversarial and red team testing	External testing firms or internal security teams; tooling such as garak (Apache-2.0) is free to run	Recurring per release or test cycle	Attack surface, number of interfaces and whether testing covers vulnerable groups scenarios
Logging and monitoring for post-market data	Internal platform teams; tracing tools such as Langfuse (MIT) are open source	One-time integration, recurring storage and review	Request volume, data retention needs and how often post-market evidence is reviewed
Evidence upkeep after each release	Internal compliance and engineering staff	Recurring	Release frequency, model changes and whether risk records are versioned with code
Independent review or notified body fees	Notified bodies or independent assessors, where applicable	Recurring for reassessment where a conformity route requires it	Annex I status, biometric systems and whether Annex VI internal control applies; confirm the route with your assessor

What your team, an implementation partner and the auditor each own

Your organization is the provider or deployer, so it owns the risk management system in law. Your people define the intended purpose, decide which hazards and foreseeable misuse cases matter, set the metrics and thresholds the system must meet, and judge whether each residual risk is acceptable. They also decide what happens after launch when monitoring data shows a new risk.

Intended purpose and scope: Name the use case, the affected people and the settings where the system will run, because every risk estimate depends on these.
Risk decisions: Approve the risk register entries, the risk owners and the measures chosen to eliminate, mitigate or inform about each risk.
Residual risk acceptance: Record who signed off each residual risk and the overall residual risk, with the reasoning, under your governance policy.
Post-market response: Review monitoring and incident data on a schedule and trigger updates to the risk file when conditions change.
Minors and vulnerable groups: Document whether persons under 18 or other vulnerable groups could be affected and how you considered them.

Confirm with your legal and compliance leads which named individuals hold these decisions and how the approvals are logged.

Where Article 9 programs usually fall short and how to close each gap

Article 9 programs tend to fail in the same few places: the risk file describes hazards without describing how the system will be misused, sign-off happens without a stated bar, and testing has no agreed pass criteria. The cards below pair each gap with a closing action you can assign and check before an assessor or market surveillance authority asks for the evidence.

Risk register lists hazards, not misuse

Many registers record technical hazards such as drift or false positives but omit how the system could be used outside its intended purpose. Article 9 requires estimation under both intended use and reasonably foreseeable misuse. Add a misuse column to each risk entry, populated by people who run the system in production, not only by the developers. Check that every entry names the user role, the context and the consequence for health, safety or fundamental rights.

Residual risk signed off without criteria

A residual risk is often marked as accepted with a name and a date but no stated test for acceptability. Article 9 expects each residual risk, and the overall residual risk, to be judged acceptable against a documented basis. Write the acceptability criterion before the review meeting, tie it to the hazard severity and affected groups, and record who holds the decision and what evidence they reviewed. Re-open the decision whenever the criterion or the system changes.

Tests run without predefined metrics

Teams often run accuracy, robustness or bias tests and then choose the metric that looks best afterwards. Article 9 requires testing against metrics and probabilistic thresholds defined in advance and suited to the intended purpose, before the system is placed on the market. Fix the metrics, thresholds and test datasets in a versioned test plan approved before the run. Store the results next to the plan so an assessor can see that the pass criteria came first.

Incidents never reach the risk file

Post-market incidents, complaints and monitoring alerts frequently stay in support or operations tickets and never update the risk management file. Article 9 treats the process as continuous and requires post-market data to be evaluated and fed into targeted measures. Define a rule that routes every incident with a health, safety or rights dimension into a risk review, and record the link between the ticket, the risk entry and the change made. Observability logs such as those from Langfuse can supply the trace data for these reviews.

Minors and vulnerable groups not assessed

Risk files often describe the average user and skip people under 18 or other groups who may be more exposed to harm. Article 9 requires the provider to consider whether the system is likely to adversely affect persons under 18 and, as appropriate, other vulnerable groups. Add a documented assessment step for the intended user population, state the conclusion even when it is that no such group is reached, and list any mitigations such as age checks, restricted features or added human review.

Duplicate risk process beside enterprise procedures

Some organizations run an AI risk process beside an enterprise risk or quality process that already covers the same hazards, which creates two registers that drift apart. Article 9(10) allows providers already subject to internal risk management rules under other Union law to make the Article 9 steps part of those procedures or combine them. Map the AI-specific steps onto the existing procedure, confirm with legal or compliance which Union rules already apply, and keep one register with AI fields added. Tools such as CISO Assistant can hold the framework mappings for audit work.

Questions buyers ask about Article 9 cost, timing and in-house work

How much does Article 9 risk management work cost?

No fixed figure applies to every system, because the cost follows the scope of the system and the state of the organization's existing risk processes. The main drivers are the number of high-risk systems in scope, how many hazards and fundamental-rights risks each one carries, whether the organization already runs an enterprise risk or ISO-style management system that Article 9(10) allows it to extend, the volume of test evidence needed against predefined metrics, and how often the risk file must be reviewed after launch. Costs fall into one-time work (building the process, the first risk assessment and test plan) and recurring work (post-market review, retesting after changes, and audit support). Ask any partner for a fixed-scope quote that lists the systems, the deliverables, the evidence formats and the review cycle, and state which items are excluded.

When must Article 9 be in place for high-risk AI systems?

Under the 2026 amendment, the high-risk rules in Chapter III Sections 1 to 3 apply from 2 December 2027 for Annex III systems and from 2 August 2028 for Annex I product systems. Article 9 is part of those rules, so the risk management system must be operating before the relevant date for any system placed on the market or put into service after it. The practical timeline is driven by how long it takes to inventory systems, classify them, define intended purpose, build the process and run the first full set of tests. Systems already on the market, and changes that count as substantial modifications, may need the process applied earlier than a new launch would. Confirm the dates and transitional rules against the consolidated text of the Regulation with your legal team.

Can our team run Article 9 risk management in-house?

Yes, many organizations can run it in-house if they have people who understand the system's design, its data, its users and the affected groups, and who can write and test against measurable criteria. The work requires a named owner, a repeatable process, and reviewers who are independent of the team that built the system. In-house teams often struggle with three things: defining acceptable residual risk in terms they can defend, designing tests with probabilistic thresholds that match the intended purpose, and keeping the file current after updates. An implementation partner can prepare the process, templates, test harnesses and evidence store, but the organization keeps ownership of the risk decisions. Only an independent assessor or notified body, where one is required, issues conformity outcomes.

What does Article 9 require from engineering and product teams?

Article 9 needs input from engineering and product before, during and after development, not only at the end. Product teams must document intended purpose, foreseeable misuse, users and deployment context. Engineering must identify hazards in the design, model and data pipeline, build tests against defined metrics, and feed post-market monitoring data back into the risk file. Common technical work includes:

Logging test runs and model versions so results can be reproduced
Building evaluation sets that cover minors and vulnerable groups where the system may affect them
Adding guardrails, human checks or design changes that reduce residual risk
Connecting incident and monitoring data to the risk register

Confirm with your product owner which changes count as substantial modifications that reopen the risk file.

Does a notified body have to review our Article 9 work?

Usually no. Most Annex III high-risk systems use the internal-control conformity assessment in Annex VI, under which the provider checks its own compliance, including the Article 9 process. Notified bodies are involved for some biometric systems and for Annex I products where sectoral law requires third-party assessment (Article 43). Even when no notified body is required, many buyers and internal auditors ask for independent review of the risk file, which an external assessor or audit firm can provide. Confirm which conformity route applies to each system in your inventory before you budget for third-party work, and check whether a harmonised standard will be used to show presumption of conformity.

Do compliance tools satisfy Article 9 on their own?

No tool satisfies Article 9 on its own. Article 9 is a documented process with decisions, owners and evidence, and a tool can only store, track and test parts of it. CISO Assistant, for example, runs audits and assessments against more than 200 frameworks and can help manage a risk register and control mapping, but a human still has to judge risks and accept residual risk. For model testing, garak probes language models for issues such as prompt injection, data leakage and jailbreaks and writes JSONL reports of every attempt and hit log of successful ones, while Langfuse captures traces of model and tool calls. Those outputs can be evidence for testing, but the organization must define the metrics, thresholds and acceptance decisions. Confirm with each vendor which capabilities the current release provides before relying on them.

How DeployOpen scopes and prepares Article 9 evidence for your systems

DeployOpen helps organizations prepare the risk management evidence Article 9 asks for, working inside the client's own infrastructure on self-hosted open-source platforms. The organization owns its risk decisions and residual risk acceptance, while DeployOpen prepares the systems, records and documents that show the process running.

How we scope

We agree a written scope listing the high-risk AI systems, lifecycle stages and risk registers included.
Scope names which intended uses, foreseeable misuse cases and affected groups are covered for each system.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts; ongoing support is available as a retainer.

How we build

We set up a risk register workflow that records identified risks, estimates, evaluations and linked mitigations per system.
We configure test harnesses that run predefined metrics and probabilistic thresholds before release and after changes.
We instrument logging and tracing so post-market monitoring data can feed back into the risk register as a recurring input.

How we hand over

We deliver a documented risk management process, with roles, review cadence and records the organization can maintain.
We hand over test results, threshold justifications and residual risk summaries for the organization's sign-off.
We document how minors and vulnerable groups were considered, so the organization can confirm and extend the analysis.

How we support

We can run continuous testing and upgrades under a retainer as systems and intended uses change over time.
We help the organization prepare evidence for its independent assessor; DeployOpen does not issue audit reports or certifications.
We recommend confirming the applicable harmonised standards and the current status of prEN 18228 with the organization's counsel and assessor.