Does a deployer have to run its own risk management system or is the provider's enough?

Both. The provider establishes the risk management system at the AI system level under Article 9 and produces the technical documentation under Article 11. The deployer has its own risk assessment obligation under Article 26 and the Article 14 human oversight obligation, both of which depend on a risk management view of the deployment context. The deployer's risk management is the operationalization of the provider's design assumptions in the deployer's environment.

Can the risk management system be combined with an existing enterprise risk management framework?

Yes, and Article 9 explicitly allows for integration with the deployer's existing risk management processes. The practical implementation is to map the Article 9 requirements onto the enterprise risk management framework's existing stages, with the AI-specific risks treated as a category alongside the operational, financial, and compliance risks the framework already handles. The Article 9-specific output is the AI risk register, the policy expressed at the AI request boundary, and the per-decision audit records that feed the post-market loop.

What counts as reasonably foreseeable misuse?

Reasonably foreseeable misuse is the use of the AI system in a way the provider has not intended but could anticipate, given the system's design and the typical operational environment. Examples in current deployments include using a hiring AI system for performance evaluation, using a credit-scoring system to inform insurance pricing, and using a customer-support AI system to handle PHI without the provider's intended PHI protections. The risk management system has to consider these uses and either prevent them through design or document them as risks the deployer is responsible for mitigating.

How does the post-market monitoring loop feed back into the risk management system?

Article 72 sets out the post-market monitoring obligation for providers, and Article 26 sets out the corresponding obligation for deployers. The data the post-market monitoring system produces, including incident reports, deployment patterns, and audit records, has to be reviewed and feed back into the risk management system. Where the data surfaces new risks or shows the existing risk management measures are inadequate, the system has to be updated. The per-decision audit records are the most granular input the loop receives.

What happens if the conformity assessment passes but the risk management system fails in operation?

The competent authority can take market surveillance action against a high-risk AI system whose risk management has failed in operation, regardless of the original conformity assessment. Article 79 provides the authority with the power to require corrective action, restrict deployment, or withdraw the system from the market. The deployer in this situation faces the operational disruption and the disclosure obligation, and the provider faces the supervisory action. The conformity assessment is the entry condition, not a permanent waiver.

EU AI Act Article 9: What the Risk Management System Obligation Requires

Article 9 of the EU AI Act requires a risk management system for every high-risk AI system, defined as a continuous iterative process across the system's lifecycle. The obligations include identification and analysis of known and reasonably foreseeable risks, estimation and evaluation of risks under intended use and reasonably foreseeable misuse, evaluation of risks emerging from post-market monitoring data, and adoption of targeted risk management measures. The August 2, 2026 deadline applies. Most enterprise AI deployments today treat risk management as a static document that the conformity assessment files away. The Article 9 reading expects an operating system that produces evidence at every decision point.

The Article 9 text describes a process. The implementation runs across model selection, deployment configuration, runtime enforcement, and post-market monitoring, with each layer producing evidence the next layer depends on.

I want to walk through what Article 9 requires at each stage of the iterative process, where the obligations intersect with Article 12 logging and Article 26 deployer monitoring, and what the architecture has to produce so the risk management system operates rather than just documenting.

What Article 9 actually requires

Article 9 is the operating framework for the high-risk AI obligation set. The text directs that the risk management system be established, implemented, documented, and maintained, with the framing of a continuous iterative process running through the lifecycle of the AI system. The process has four stages: identification of risks, estimation and evaluation of risks, evaluation of post-market monitoring data, and adoption of risk management measures.

The risks the system is required to address are the known and reasonably foreseeable risks the AI system can pose to health, safety, or fundamental rights when used in accordance with the intended purpose. Reasonably foreseeable misuse is also in scope: the risk management system has to consider how the AI system might be used outside its intended purpose and what risks that creates.

The risk management measures the regulation expects have a hierarchy: elimination or reduction of risks through design, implementation of mitigation and control measures for risks that cannot be eliminated, and provision of information and training to deployers. The measures have to be tested and validated. The validation evidence has to support the conformity assessment.

The iterative process the regulation describes

The iterative process means the risk management system runs continuously, not as a one-time documentation step. Three loops have to operate.

The first loop runs at design and validation, before the AI system enters the market. The provider identifies the risks in the use case, estimates likelihood and severity under intended use and foreseeable misuse, evaluates the residual risk after mitigation, and adopts the measures the residual risk requires. The output is the technical documentation under Article 11 and the conformity assessment under Article 43.

The second loop runs at deployment, before the deployer puts the AI system into operation. The deployer assesses the risks the deployment configuration creates: which users have access, which data classes the system can process, which decisions the system is permitted to inform, and which oversight functions are in place. The output is the deployer's own risk assessment and the configuration that satisfies it.

The third loop runs continuously during operation. Post-market monitoring data feeds back into the risk evaluation. New risks the system surfaces, incidents the deployer reports under Article 73, and emerging patterns from the audit records all have to feed the risk management measures. The system the regulation expects is an ongoing operation, not a snapshot.

Where current AI deployments fall short

Most enterprise AI deployments today implement the design-time loop in the form of a risk register that the legal and compliance teams maintain. The deployment loop is implemented as a procurement questionnaire that the buying team fills out at vendor selection. The runtime loop is implemented as ad hoc incident response.

The gap shows up when the auditor or the competent authority asks to see the evidence the iterative process produced. The risk register can show the risks the team identified. The procurement questionnaire can show the controls the team intended to operate. The audit records the runtime loop produced are the missing piece.

Without per-decision records produced at the AI request boundary, the deployer cannot demonstrate that the risk management measures operated as intended. The questions the auditor asks reach the operational layer: how often did the deployment configuration permit a request that the risk management policy would have blocked, how often did the human oversight function operate as designed, how often did the system surface a previously unidentified risk.

What the architecture has to produce

For the risk management system to operate rather than to document, the architecture has to produce records at three layers.

The design-time layer produces the risk register, the conformity assessment evidence, and the technical documentation under Article 11. This layer is the responsibility of the provider and feeds into the deployer's procurement.

The deployment-configuration layer produces the policy that defines what the AI system is permitted to do in the deployer's environment. The policy specifies the data classes the system can process, the user roles authorized to use the system, the action types the system is permitted to take, and the oversight requirements that apply. The policy is the operational expression of the deployer's risk assessment.

The runtime layer produces the per-decision evidence that the policy operated. For each AI request, the record captures the user identity, the data classification, the policy version in effect, the decision outcome, and a timestamp. The records aggregate into the post-market monitoring data that feeds the third Article 9 loop.

The architectural pattern is the per-decision evaluation at the AI request boundary, with the policy expressing the risk management decisions and the per-decision record producing the evidence. Without this layer, the third Article 9 loop has no input.

How Article 9 connects to the rest of the obligation set

Article 9 sits at the top of the high-risk obligation set. The risk management measures the system adopts drive the requirements that flow through Articles 10 through 15. Data governance under Article 10 follows from the risk identification. The technical documentation under Article 11 documents the measures. The record-keeping under Article 12 produces the evidence the post-market monitoring loop depends on. The transparency obligations under Article 13 transfer the relevant risk information to deployers. The human oversight requirements under Article 14 implement the oversight measures the risk management identified. The accuracy and security requirements under Article 15 close the residual risks.

For the deployer, Article 26 inherits the Article 9 framing: the deployer's monitoring, the Article 19 retention of automatically generated logs, and the Article 73 serious-incident reporting all assume the risk management system is operating.

The penalty tier under Article 99 for high-risk non-compliance is 15 million EUR or 3% of global annual turnover, whichever is higher. The supervisory authority assessing a deployer's posture during a market surveillance action will look first at whether the risk management system can be demonstrated as operating, and the per-decision records are the substrate for that demonstration.

DeepInspect

This is the architecture the Article 9 obligation expects. DeepInspect sits at the AI request boundary as a stateless proxy that operates the deployment-configuration layer and produces the runtime evidence layer. The policy expressed at the proxy captures the risk management decisions the deployer made: which user roles can access which AI systems, which data classifications are permitted, which actions the AI can take. The per-decision audit record captures the evidence the policy operated.

For the third Article 9 loop, the records aggregate into the post-market monitoring data that the deployer reviews. Emerging risk patterns surface in the records. Incidents reported under Article 73 trace back to specific records the deployer can produce on demand. The risk management system operates because the per-decision layer is operating.

If your high-risk AI deployment is treating Article 9 as a documentation exercise that ended at the conformity assessment, the August 2, 2026 deadline will test that assumption. Book a demo today.