AI Control Library / CF-09: Monitoring & Drift Detection
Designation: Core | Control types represented: Operational and Technical
Control requirement
Monitor AI runtime and infrastructure failures across the dependencies needed for reliable service, including model loading, inference, queues, tool connections and resource limits. Verify user-visible outcomes and safe failure behavior.
Why this matters
A process can be running while inference stalls, outputs are incomplete or tool requests accumulate. Health monitoring should follow the service’s actual success conditions rather than a single endpoint check.
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
AI serving infrastructure, managed endpoints, retrieval services, accelerators, queues, tools and shared dependencies.
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 platform operations owner maintains health monitoring; service owners define impact and continuity responses.
Implementation guidance
- Map critical dependencies and define health, capacity, latency and error signals with meaningful service context.
- Instrument failure, saturation, retries and backlog, including provider limits and partial responses.
- Route actionable alerts to covered responders and define safe fallback, restriction or suspension behavior.
- Exercise dependency failures and recovery, verifying that retries and queued work do not create uncontrolled cost or repeated actions.
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 |
|---|---|
| Fail a model or retrieval dependency in a controlled test | Monitoring identifies affected service and expected restriction. |
| Saturate an approved test workload | Capacity and queue behavior remain within defined conditions. |
| Recover from failure | Outstanding requests and repeated actions are reconciled. |
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
- Service health and dependency map
- Monitoring and capacity configuration
- Failure and recovery exercises
- Response and continuity records
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 material service failure to operations and the business owner. Apply the approved fallback and prevent unsafe retry or action accumulation during recovery.
Example in practice
Hypothetical example: A provider rate limit creates an increasing agent queue. Monitoring limits retries and pauses consequential work instead of allowing the backlog to execute unexpectedly after recovery.
Related controls
- CF04-013: AI Monitoring System Failure Reporting
- CF01-S07: AI Continuity Planning
- CF09-011: Agentic System Action Monitoring
Framework mappings
- CSA AICM (MDS-11)
- 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