AI Control Library / CF-09: Monitoring & Drift Detection
Designation: Core | Control types represented: Operational and Technical
Control requirement
Reassess monitoring coverage, metrics, baselines and response whenever material AI system changes alter behavior, data, authority or dependencies. Validate revised monitoring before relying on it for the changed deployment.
Why this matters
A monitor can continue running while observing the wrong event schema or comparison population. Recalibration should preserve evidence of change, not erase unfavorable history by redefining normal.
How the control types work together
Operational controls define scope, authority and the actions required when conditions are not met. Technical controls produce evidence or enforce the relevant boundaries. Both must apply to the same deployment and operating conditions.
When it applies
Model, prompt, retrieval, data, tool, permission, workflow and provider changes affecting monitoring assumptions.
Define the assessed boundary, dependencies and evidence limitations. Tailor depth and review frequency to potential impact, and document why a particular safeguard or exclusion is appropriate to the actual deployment.
Ownership
The system change owner coordinates monitoring and domain owners; release authority verifies readiness.
Implementation guidance
- Identify which monitoring assumptions and data paths the proposed change affects, linking them to its risk review.
- Revise coverage, metric definitions, reference windows and response authority for justified reasons, preserving prior versions and comparability limits.
- Test detections, data health and routing against the changed candidate, including denied actions and partial failures.
- Approve the revised monitoring with release conditions and post-change observation, investigating new adverse results rather than normalizing them automatically.
How to verify it
Use representative records and authorized controlled tests. Identify the relevant version, operating conditions and expected result before testing, and retain enough evidence to support the conclusion.
| Test | Expected result |
|---|---|
| Trace a material change | Its monitoring impact and readiness evidence precede expanded use. |
| Compare old and new baselines | Reasons and comparison limitations are explicit. |
| Exercise a changed event or tool path | Required detection and response still work. |
Record a finding when required results cannot be demonstrated or practice differs materially from the approved conditions. Missing evidence limits the conclusion; it should not be treated as a successful test.
Evidence to retain
- Monitoring impact assessment
- Versioned baseline and metric changes
- Readiness and routing tests
- Post-change review decisions
Protect evidence according to its sensitivity, access needs and retention rules. Avoid unnecessary copies of personal information, secrets or confidential material, while preserving the records needed for authorized review.
If the control fails
Escalate lost coverage or unjustified baseline reset to monitoring and release owners. Hold rollout or restrict affected operation until the changed system is meaningfully observed.
Example in practice
Hypothetical example: A model update changes the output schema. Recalibration repairs quality checks and tests them before rollout instead of leaving a healthy dashboard whose evaluator no longer parses the responses.
Related controls
- CF01-009: AI Change Management Policy & Procedures
- CF09-001: AI Monitoring & Drift Detection Policy
- CF04-013: AI Monitoring System Failure Reporting
Framework mappings
- NIST AI RMF (MANAGE 4.2)
- EU AI Act (Art. 72)
- ISO 42001 (Cl. 9.1)
Review and maintenance
Review at the interval approved by the control owner and after relevant changes, incidents or failed assessments. Update affected procedures and configuration, address evidence gaps and verify corrective action before closing findings.
Back to Monitoring & Drift Detection
Version 1.0