AI Control Library / CF-09: Monitoring & Drift Detection
Designation: Core | Control types represented: Operational
Control requirement
Establish a monitoring and drift-detection policy defining observation objectives, baselines, ownership, thresholds, review, response and reassessment for deployed AI. Require explicit treatment of visibility gaps and monitoring failure.
Why this matters
Deployment changes the evidence available about a system. Monitoring needs to connect observed behavior to decisions, rather than assume that pre-release performance remains valid indefinitely.
How the control types work together
Operational controls establish the assigned responsibilities, review processes and response decisions described here. Their effectiveness depends on performing the work and using evidence to guide action, rather than approving a document alone.
When it applies
Production and consequential pilot AI deployments, including provider-managed models and agentic workflows.
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 AI operations owner maintains policy with domain, security and risk owners.
Implementation guidance
- Define required coverage for quality, drift, fairness, security, action authority and service health according to risk.
- Assign baselines, review intervals, alert recipients and authority to investigate, restrict, recalibrate or stop.
- Require privacy-conscious collection and explicit limitations where outcomes or provider internals are not observable.
- Integrate monitoring readiness into release and review policy after material changes, incidents or failed observation.
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 |
|---|---|
| Inspect a consequential service | Owned monitoring and response cover its material operating risks. |
| Trigger a representative issue | The defined team acts rather than merely receiving a dashboard update. |
| Remove a required observation path | A failure response or operating restriction activates. |
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
- Approved monitoring policy
- Coverage and responsibility records
- Readiness and response tests
- Review and exception 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 unowned monitoring or material visibility loss to system and risk owners. Restrict operation where accepted conditions depend on unavailable observation.
Example in practice
Hypothetical example: A vendor changes its model version. The policy requires quality and behavior checks for the actual service instead of assuming a healthy endpoint means the approved model performance continues.
Related controls
- CF01-018: Post-Deployment Monitoring Plan
- CF09-010: AI Monitoring Metrics & Reporting
- CF04-013: AI Monitoring System Failure Reporting
Framework mappings
- CSA AICM (LOG-01)
- NIST AI RMF (MANAGE 4.1)
- 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