Should organisations treat post-market monitoring as part of conformity assessment or as a separate control?

Should post-market monitoring live inside conformity assessment?

Yes, organisations should treat post-market monitoring as a continuation of the same control loop, not as a separate afterthought. For high-risk AI, the conformity decision is only credible if deployment telemetry, incident feedback, and performance drift all feed back into the same risk view that supported release. The European Commission’s EU AI Act regulatory framework reflects that lifecycle expectation.

The practical reason is continuity. conformity assessment establishes that the system met the required conditions at a point in time, but post-market monitoring tests whether those conditions still hold under real use, changing data, operational load, and user behaviour. If the organisation splits the two, it creates a gap between approval and operation that can hide degradation, new failure modes, or a change in intended use.

That means monitoring is not just observational. It is part of the evidence chain that supports ongoing compliance, because performance logs, complaint handling, human override records, and risk updates are the signals that tell you whether the deployed system is still aligned with the assessed design and safeguards.

What changes once the system is deployed?

Deployment changes the control objective from “did it pass assessment?” to “does it still behave within the approved envelope?” That shift matters because AI systems can drift, interact with new contexts, and produce different outcomes after release. A good post-market process therefore tracks not only defects, but also operational indicators that show whether the system remains safe, accurate, and appropriately bounded.

For organisations, the key question is whether monitoring results can trigger a formal update to risk management, documentation, or release conditions. If the answer is no, monitoring has been reduced to reporting. A compliant lifecycle approach uses the same governance record to capture assessment assumptions, runtime evidence, and follow-up actions.

This is where traceability matters most. The deployment record should make it possible to connect a live issue back to the control that was relied on during assessment, and to decide whether the issue requires correction, restriction, revalidation, or withdrawal from service.

Why a separate control creates avoidable gaps

A separate post-market process often fails because ownership gets fragmented. The team that approved the system may focus on initial documentation, while the operations team tracks incidents without the context needed to judge whether a trend breaks the original conformity basis. That split weakens escalation and makes it easier for risk acceptance to linger after conditions have changed.

It also increases the chance that important signals will be treated as optional, especially if they sit outside the release workflow. When monitoring is detached from conformity, organisations tend to underweight performance drift, insufficient human oversight, and emerging safety issues because they are not directly tied to the release gate. The result is continuity loss, not just administrative duplication.

Current guidance is moving toward lifecycle integration for exactly this reason: post-market evidence only has regulatory value when it informs the same risk decisions that governed deployment in the first place. Where that loop is broken, the organisation may still have data, but it no longer has a reliable compliance story.

Risk and Threat Considerations

Separating post-market monitoring from conformity assessment creates a governance blind spot. The system may appear compliant at launch while its real-world behaviour drifts outside the approved risk envelope, especially when usage context, input distributions, or operational dependencies change after deployment.

Failure mechanism: Monitoring signals are collected, but they are not tied to the original assessment, so drift, incidents, and performance regressions do not automatically trigger reconsideration of the conformity basis. That breaks the feedback loop between runtime evidence and release approval.

Impact: Organisations can miss material changes in safety, accuracy, or oversight requirements, which increases regulatory exposure, weakens accountability, and can leave an unsafe system in operation longer than intended.

Practitioner Guidance

What to prioritise: Treat the post-market process as evidence maintenance for the approved system, not as a separate operational dashboard. The first decision is whether monitoring outputs can change risk treatment, documentation, or deployment status without creating a parallel governance track.

What to verify: Confirm that the organisation can trace each live issue to the risk it affects, the control it challenges, and the person or function that must decide on remediation. If that path is unclear, the monitoring process is too detached to support conformity in practice.

Decision rule: If a monitoring signal can affect safety, performance, or intended use, route it back into the conformity and risk-management record. If it cannot influence those decisions, it is probably only operational telemetry, not post-market control evidence.

Practitioner takeaway: The test is not whether monitoring exists after release, but whether it still governs the same assumptions that justified release.

Related resources from NHI Mgmt Group

• Should organisations treat post-market monitoring as part of identity governance?
• Which compliance frameworks require organisations to treat Active Directory security as part of broader access control and monitoring obligations?
• Should organisations treat PAM as part of IAM governance or as a separate control?
• Should organisations treat AI agent authorization as part of PAM or as a separate control?