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.
Why a one-time audit breaks down under Article 9
A one-time audit can show that a model was acceptable at a point in time, but Article 9 is about whether risk management remains effective as the system changes in use. Once deployment starts, performance drift, new data, changed workflows, and real user behaviour can alter the risk profile. That is why ongoing monitoring and re-validation matter more than a launch-time sign-off.
What Article 9 is really asking you to prove
Article 9 expects the provider or deployer to maintain a continuous AI management system rather than a one-off compliance event. The practical test is not whether a control existed during approval, but whether the control still works after the system enters production, interacts with real users, and encounters edge cases that were not visible in testing.
This is why a single audit snapshot is weak evidence. It can confirm documented intent, but it cannot prove that governance, data quality, human oversight, logging, and mitigation measures stayed aligned with the live operating environment. Article 9 is concerned with the durability of control effectiveness, not just the quality of the original review.
That expectation is closely related to the way NIST AI RMF treats AI risk as a lifecycle problem. If the model, deployment context, or downstream decision process changes, the earlier assessment no longer fully describes current risk. In practice, you need recurring evidence that the system still behaves within the assumptions that justified approval.
Why the live operating environment changes the answer
A production AI system is not static. Model updates, prompt and policy changes, tool integrations, retraining, shifting user populations, and changes in downstream business rules can all alter behaviour after the initial assessment. A one-time audit rarely captures those later conditions, which means it can miss the point where a previously acceptable control becomes incomplete.
This is especially important where the system influences decisions affecting rights, safety, or access. If the evidence base is frozen at launch, the organisation may fail to notice that the original risk assessment no longer matches the actual deployment. The issue is not that auditing is useless, but that the audit must be part of an ongoing assurance loop.
External assurance standards reinforce the same logic. The SOC 2 Trust Services Criteria are built around sustained control operation, not a single evidence pack assembled once and forgotten. That is a useful comparator because it shows why auditors and regulators usually care about operating effectiveness over time, not just design at a fixed date.
How to interpret the compliance burden in practice
Article 9 is best read as an obligation to keep the risk management system current, traceable, and evidenced throughout the lifecycle. The organisation should be able to show that it monitored for material change, reassessed risks when change occurred, and updated mitigations when performance or context shifted. That makes monitoring evidence, incident review, and change management part of compliance, not optional extras.
A useful way to think about this is that the audit must answer a question of continuity: do the controls still work in the conditions where the system actually operates? If the answer depends on assumptions that are no longer true, the original audit has limited value. The stronger your production telemetry and change records, the easier it is to defend that the system stayed within the intended risk envelope.
Risk and Threat Considerations
A one-time audit creates a false sense of stability. Once the model is exposed to new prompts, new data, new integrations, or new operational pressure, weaknesses can emerge that were absent during the original review. In regulatory terms, the danger is not just non-compliance at launch, but silent drift away from the approved risk posture.
Failure mechanism: The initial audit freezes the evidence set, while the real system continues to evolve, so mitigations may decay without being detected.
Impact: Controls can appear compliant on paper even after they stop matching live behaviour, which raises legal, operational, and reputational exposure if harms or failures emerge.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST AI RMF sets the technical controls, while ISO/IEC 42001:2023 and SOC 2 (AICPA) define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| ISO/IEC 42001:2023 | A.5.2 — AI policy | Article 9 requires ongoing AI governance and reassessment across the lifecycle. |
| Recommendation — Establish AI governance processes that keep risk controls current after deployment. | ||
| NIST AI RMF | GOVERN — Govern | The question is about lifecycle AI risk management and sustained oversight. |
| Recommendation — Set governance routines that require periodic review of live AI risk. | ||
| SOC 2 (AICPA) | CC7.2 — Change management | A one-time audit fails when production change can invalidate prior control evidence. |
| Recommendation — Track and review changes so control effectiveness is revalidated after updates. | ||
Practitioner Guidance
What to verify: Treat the audit as the start of an evidence trail, not the end state. Verify that monitoring covers the live deployment, that model or workflow changes trigger reassessment, and that someone owns the decision to reopen risk review when material drift appears.
What good looks like: You can point to recurring control checks, documented change impact reviews, and production evidence that mitigations still operate as intended. If those artefacts do not exist, the organisation is relying on a historical assessment rather than current assurance.
Decision rule: If the AI system can change after approval, compliance should be treated as an ongoing operating condition. A one-time audit may support the file, but it cannot by itself satisfy a requirement that depends on continued effectiveness in production.
Practitioner takeaway: For Article 9, the question is not whether the system once passed review, but whether the organisation can prove that risk controls stayed effective after the system met real users, real data, and real operational change.
Related resources from NHI Mgmt Group
- When do NHI access reviews create more value than a one-time cleanup?
- When does Article 9 create more governance risk than a one-time audit?
- Why do compliance programs fail when teams treat framework requirements as one-time projects?
- Why does one access review report fail to satisfy leadership and audit needs?