EU AI Act Article 9 turns risk management into a live control system

At a glance

What this is: This is an analysis of EU AI Act Article 9 and its key finding that high-risk AI governance must be continuous, evidence-backed, and updated as systems and contexts change.

Why it matters: It matters because AI governance teams, IAM-adjacent control owners, and risk leaders need operational proof that safeguards are working in production, not just documented at launch.

By the numbers:

• Conformity assessment failures under the EU AI Act can cost up to €30M or 6% of global revenue.

Context

Article 9 of the EU AI Act treats risk management as a live control system, not a paper exercise. For high-risk AI systems, the core governance problem is that risk can change after launch when models retrain, deployment conditions drift, or production monitoring reveals failure modes that were not visible during testing.

That creates a direct governance gap for AI, IAM, and broader control owners: documentation alone does not prove operational control. The regulation pushes organisations toward continuous evidence, where testing, monitoring, and documented mitigation must stay aligned with the system state that is actually in production.

Key questions

Q: How should security teams implement continuous AI security testing for high-risk systems under the EU AI Act?

A: Security teams should treat testing as an ongoing control, not a one-time assessment. For high-risk AI systems, build a repeatable programme that exercises data poisoning, model evasion, adversarial examples, and confidentiality attack scenarios across the full lifecycle. Tie results to documented mitigations, change management, and evidence retention so auditors can verify the system remains resilient as models, data, and threats evolve.

Q: Why does a one-time audit fail to satisfy Article 9 requirements?

A: Because Article 9 expects risk management to stay aligned with the live system, not the launch state. AI behaviour, deployment context, and user interaction can change after approval, so a single audit cannot prove that mitigations still work. Compliance depends on ongoing evidence that controls remained effective in production.

Q: What are the signs that an AI risk management programme is failing?

A: An AI risk programme is failing when risk controls stay ad hoc, metrics are absent or superficial, and teams only react after deployment issues surface. Other warning signs include weak cross-functional coordination, unclear accountability, and no process for adapting controls as the system evolves. If risk treatment is disconnected from development and operations, the programme is mostly performative.

Q: Should organisations use the EU AI Act Article 9 process or rely on internal model governance alone?

A: Use Article 9 as the compliance backbone and treat internal model governance as supporting structure. Internal policies are useful only if they produce the evidence chain Article 9 expects, including testing, monitoring, and reassessment. Standalone governance without auditable proof will not hold up when conformity is challenged.

Technical breakdown

Why Article 9 is a lifecycle control, not a launch checklist

Article 9 requires providers to build, implement, document, and maintain a risk management system across the AI lifecycle. That means the control must operate during design, testing, deployment, monitoring, and retirement, rather than stopping at approval. The practical issue is evidence continuity: each risk decision must remain traceable to the version of the model and the environment in which it ran. A spreadsheet or static policy cannot show that relationship once the system changes. Continuous control means the governance process must evolve with the system itself, including retraining events, changed usage patterns, and newly observed failure modes.

Practical implication: Treat risk management as an operating control with versioned evidence, not a document review.

How validation and post-market monitoring create proof

The Article 9 model depends on two linked mechanisms: pre-release testing against defined thresholds and post-market monitoring that feeds production data back into the risk process. Testing establishes whether mitigation measures work before release. Monitoring then checks whether those measures still hold as the system encounters real users, new data, and changing context. This is closer to closed-loop control than annual compliance. If the feedback loop breaks, the organisation may still have policy language but loses the ability to demonstrate that controls are effective in practice. That is why the regulation treats production behaviour as compliance evidence, not just an operational signal.

Practical implication: Connect test results, monitoring outputs, and risk updates in one auditable control loop.

What breaks when compliance is frozen at launch

A frozen compliance model fails because AI systems do not remain static after approval. Retraining can shift behaviour, deployment context can change how outputs are used, and post-market incidents can expose risks that design-time reviews missed. Article 9 assumes those changes are foreseeable enough to require reassessment. The control problem is not just discovering risk, but proving that risk responses were updated when the system changed. In practice, this makes version control, evidence retention, and production telemetry part of governance. Without those pieces, the organisation may be able to describe controls but not demonstrate that they remained valid over time.

Practical implication: Build governance triggers for retraining, deployment drift, and incident-driven reassessment.

Threat narrative

Attacker objective: The objective is not theft but regulatory failure, where the organisation cannot substantiate that its AI controls worked in production.

1. Entry begins when a high-risk AI system is deployed into a regulated use case and then changes through retraining or altered operating context.
2. Credential access is not the issue here; the failure mode is governance drift, where the approved control set no longer matches the live system.
3. Impact occurs when the provider cannot prove that testing, monitoring, and mitigation remained effective, so conformity assessment collapses under regulatory review.

Breaches seen in the wild

• Salesloft OAuth token breach: hackers stole OAuth tokens to access Salesforce data via Salesloft.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Article 9 turns AI governance into a continuous assurance problem: the regulation does not ask whether a risk assessment was completed, but whether the control system keeps producing valid evidence as the model changes. That shifts the burden from policy ownership to operational proof. For practitioners, the decisive question is whether the governance process is coupled tightly enough to the live system state.

Evidence, not intention, becomes the compliance currency: testing results, monitoring outputs, and updated risk records must all line up with the deployed version of the system. Static documentation may support an audit narrative, but it will not survive scrutiny if production behaviour diverges from the approved assumptions. The practical conclusion is that evidence chains need to be designed into the AI operating model.

Continuous AI risk management creates a new governance gap we can call compliance drift: the approved control framework can remain intact on paper while the actual system evolves beyond it. That gap is especially important for organisations running model retraining, changing prompts, or shifting deployment contexts. The practitioner lesson is to treat drift detection as a control objective, not a monitoring afterthought.

For identity and access teams, Article 9 reinforces a broader control lesson: governance fails when assurance is decoupled from runtime behaviour. AI systems that make decisions in production need the same discipline seen in mature access governance, where lifecycle state, evidence, and accountability stay synchronised. The implication is that AI risk management must be built as an operating system for control, not a filing cabinet for approvals.

Regulatory pressure will expose tooling gaps as much as policy gaps: organisations that cannot connect test, monitor, and reassess workflows will struggle to show conformity even if their written policies are sound. Article 9 rewards integrated control telemetry over fragmented assurance. The practitioner conclusion is to design for traceability first, because traceability is what turns governance into defensible compliance.

What this signals

Compliance drift: this article shows why AI governance cannot stop at approval. Once a model retrains or a deployment context shifts, the organisation has to prove that the control environment moved with it, otherwise the compliance story and the live system diverge.

For AI programmes, Article 9 pushes governance closer to runtime assurance than document management. That means control owners need telemetry, versioned evidence, and formal reassessment triggers if they want regulatory review to succeed.

For practitioners

• Build a continuous Article 9 control loop Link design-time risk identification, validation results, production monitoring, and reassessment triggers into one governed workflow with version history.
• Tie testing to predefined thresholds Document acceptance thresholds before release, then retain the exact test evidence that shows whether mitigations met those thresholds in the deployed system.
• Create reassessment triggers for system drift Trigger formal review when models retrain, deployment context changes, or monitoring surfaces new failure modes, and record the resulting control changes.
• Keep technical documentation in sync with production Maintain a single evidence trail that connects the current deployed version, risk controls, testing outcomes, and post-market monitoring records.

Key takeaways

• Article 9 treats AI risk management as a live control system that must keep pace with retraining, monitoring, and deployment drift.
• The main failure mode is not absent policy but absent proof that mitigations were tested and remained effective in production.
• Organisations need versioned evidence, reassessment triggers, and a continuous feedback loop if they want conformity assessments to stand up under scrutiny.

Key terms

• Continuous Risk Management: A governance model that updates vendor or control risk as conditions change rather than only at scheduled review points. It combines live signals, policy thresholds, and accountable escalation so decisions reflect current exposure instead of historical evidence.
• Post-market monitoring: Post-market monitoring is the ongoing collection and review of system behaviour after deployment so emerging risks, drift, and incidents can be detected and corrected. In regulated AI programmes, it is part of the evidence chain and must connect operational telemetry back to governance decisions.
• Conformity assessment: A conformity assessment is the formal process used to show that a high-risk AI system meets the obligations required before it is placed on the market. It combines documentation review, technical verification, and evidence of operational controls, rather than relying on policy statements alone.
• Deployment Drift: Deployment drift is the gap between how a system is documented or intended to operate and how it actually runs in production. In identity and access management, drift can weaken trust boundaries, hide dependencies, and create failures that appear only when support or response is urgently needed.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and identity lifecycle control. It helps practitioners connect governance models to the operational evidence that security programmes need.