AI model monitoring should detect when a deployed system is no longer behaving within approved expectations. Auditing that monitoring requires more than checking whether a dashboard exists. The auditor needs to understand which risks are monitored, how baselines and thresholds were set, whether data is complete, how exceptions are investigated, and whether material changes trigger revalidation.

The current ISACA AAIA outline explicitly includes AI lifecycle monitoring and the monitoring and reporting of AI-specific KPIs and KRIs. Current ISACA AAISM tasks also call for AI security metrics, regular control review, and risk-based human oversight. Those expectations make monitoring a control system in its own right, not a post-deployment visualization.

Define what “healthy” means for the use case

Start with business objectives, unacceptable outcomes, user population, decision impact, and model role. A forecasting model, fraud detector, recommendation engine, classifier, and generative assistant need different measures. Monitoring should reflect the harm that matters to the use case.

Document approved performance ranges, quality expectations, safety constraints, privacy limits, latency, availability, cost, and human-review requirements. If the system can take action, include authorization failures, tool errors, and override rates.

Auditors should challenge metrics that are convenient but not decision relevant. An aggregate accuracy score may hide poor performance for a critical class or population.

Establish a reproducible production baseline

Record the model version, configuration, feature definitions, prompt or system instruction, retrieval sources, tool permissions, thresholds, evaluation dataset, and expected metric range at approval time. Without a baseline, later monitoring cannot distinguish drift from undocumented change.

The production baseline should reflect realistic data and operating conditions. A model validated on a clean historical dataset may behave differently with live missing values, new product categories, changing user behavior, or adversarial input.

Preserve the evaluation method as well as the result. If the metric definition changes, annotate the trend so management does not compare incompatible periods.

Distinguish data drift, concept drift, and performance degradation

Data drift occurs when the input distribution changes. Concept drift occurs when the relationship between inputs and the target changes. Performance degradation is the observed decline in the outcome measure. These conditions can be related but are not interchangeable.

Monitoring should identify meaningful feature shifts, missing-data changes, category growth, changes in source systems, and new populations. For supervised models, compare predictions with later ground truth where available. For generative systems, use evaluation sets, user feedback, groundedness or policy checks, and targeted review.

Auditors should verify that the monitoring process can explain which change triggered an alert and whether the response is appropriate. A statistical shift that has no business impact may not require retraining; a small shift in a safety-critical class may be urgent.

Audit bias and subgroup performance over time

A model can meet its aggregate target while performance worsens for a subgroup, language, geography, product type, or edge case. Determine which segments were identified as material during design and whether monitoring preserves that visibility in production.

Review how sensitive attributes are handled. Fairness testing may require protected or sensitive data that the operational application does not otherwise need. Existing controls for AI data privacy should therefore be applied to monitoring datasets and analyst access.

Do not accept a single fairness metric as universal proof. The appropriate measure depends on the decision context, baseline rates, legal obligations, harm model, and affected stakeholders.

Test thresholds, alerts, and exception workflow

For each monitored metric, document target, warning threshold, escalation threshold, owner, frequency, and required response. Thresholds should be justified using validation results, risk tolerance, operational experience, regulatory expectations, or business impact.

Inspect alert history. Determine whether alerts are timely, investigated, documented, and closed with evidence. Look for alert suppression, repeated overrides, chronic threshold breaches, and cases where the same failure is reclassified to avoid escalation.

Measure response time and backlog. A sophisticated drift detector provides little control value if alerts wait months for review.

Evaluate human oversight as an operating control

Human review should be designed around risk, not added as a ceremonial approval. Determine which outputs require review, what information the reviewer sees, whether the reviewer has authority to reject the model, and how disagreements are recorded.

Test for automation bias. Give reviewers cases where the model is confidently wrong or where source evidence conflicts with the recommendation. If reviewers almost always accept the model without independent analysis, the control may be ineffective despite a high completion rate.

Monitor override rates and outcomes. Sudden increases can indicate model degradation; near-zero overrides can indicate either excellent performance or weak challenge.

Control model, prompt, data, and provider changes

Monitoring results are difficult to interpret when production changes are not linked to the trend. Record model upgrades, retraining, threshold adjustments, feature changes, prompt edits, retrieval-source changes, safety-setting changes, new tools, and provider-managed updates.

Define which changes require full validation, limited regression testing, or management approval. A cosmetic prompt change may be low risk, while giving an agent a new production tool can materially alter the control environment without changing the model itself.

Auditors should trace a sample of changes from request through testing, approval, deployment, monitoring, and post-change review.

Verify monitoring data and metric calculations

Reconcile production records to the monitoring population. Confirm that failed requests, rejected outputs, manual overrides, edge regions, and high-risk users are not accidentally excluded. Missing the difficult cases can make performance appear better than reality.

Reperform selected metrics from raw data and inspect calculation code or queries. Validate time windows, denominators, filtering, label delays, deduplication, and treatment of missing ground truth.

Protect the monitoring pipeline itself. Restrict access to metric logic and thresholds, log changes, version code, and separate duties when manipulation could conceal poor performance.

Traditional predictive models and generative systems need different monitoring evidence. A classifier may have delayed ground truth that permits precision, recall, or error-rate calculation. A generative assistant may need sampled evaluation of groundedness, task completion, policy compliance, harmful content, citation quality, tool-use correctness, and human override. The audit should verify that the chosen measures fit the model’s actual role.

Delayed labels create a specific assurance challenge. Credit defaults, fraud outcomes, equipment failures, or customer churn may become known weeks or months after prediction. Monitoring should separate immediate proxy indicators from later validated performance and explain how the organization acts when the two disagree.

Champion-challenger or shadow testing can reduce deployment risk. A candidate model can run beside the production model without making final decisions so teams can compare behavior on live data. Audit evidence should show how comparison criteria were defined, whether sensitive data was permitted in the shadow process, and who approved promotion.

Operational monitoring belongs in scope too. Cost spikes, latency, quota exhaustion, repeated retries, unavailable dependencies, and tool-call failures can change user behavior or encourage unsafe workarounds. A model that is statistically accurate but operationally unreliable can still create material business risk.

Monitoring coverage itself should be measured. Track models without current baselines, missing data feeds, overdue validation, stale thresholds, unowned alerts, and periods where telemetry failed. This prevents the monitoring program from appearing healthy simply because only functioning monitors are visible.

Auditors should also inspect retraining triggers. Some systems retrain on a schedule, others when drift crosses a threshold, and some vendors update continuously. Verify who approves retraining, which data is permitted, how contaminated or low-quality data is excluded, how the new model is evaluated, and whether rollback remains possible.

Feedback loops deserve specific attention. User ratings, corrections, human overrides, or downstream outcomes may feed future training or prompt changes. If feedback is biased, manipulated, or incomplete, the system can reinforce poor behavior. Monitoring should therefore assess feedback quality and access as well as model output.

Document monitoring limitations. Some harms are hard to measure automatically, some labels arrive late, and some populations are too small for reliable statistics. A mature program states those gaps, adds targeted manual review where needed, and avoids presenting the absence of an alert as proof that no risk exists.

For high-impact systems, compare monitoring with independent periodic evaluation. A production monitor can become blind to the same assumptions built into the model. Independent challenge using separate test data, red-team cases, or different reviewers can reveal failure modes that the routine monitoring pipeline never flags.

Audit reporting should distinguish a monitoring-design weakness from an actual model failure. Missing thresholds, incomplete populations, or unreliable data are control deficiencies even when no harmful output has yet been observed. That distinction helps management fix the assurance mechanism before a production incident occurs.

Where monitoring uses automated evaluators or secondary models, audit those evaluators too. A weak judge model can create false assurance if its own errors, bias, or version changes are not understood.

Connect monitoring to incidents and revalidation

Define when a monitoring breach becomes an incident, when the model should be suspended, and when it must be revalidated. Triggers can include severe performance loss, harmful output, privacy leakage, model compromise, repeated tool misuse, unexplained data drift, or loss of critical monitoring data.

Incident response should preserve the model version, configuration, inputs, outputs, tool actions, monitoring state, and relevant logs. That evidence helps determine whether the cause was model behavior, data, integration, attack, configuration, or human process.

The monitoring disciplines reflected in ISACA certifications ultimately lead to three assurance questions: can the organization detect meaningful deterioration, can it trust the evidence, and do people act when limits are breached? A green dashboard is not assurance unless the organization can prove what green means and how it was measured.