Monitoring

Monitoring watches a deployed AI system over time. It looks for quality drops, data drift, subgroup failures, unusual user behavior, policy violations, latency problems, and signs that the system is being used outside its intended scope.

Monitoring is most valuable when it is connected to action. A dashboard that no one owns is a decoration. A monitor should define a signal, threshold, owner, investigation path, and response.

Wire Signals to Thresholds and Owners

A recommendation system needs monitoring. Set each signal's alert threshold and assign an owner. Too sensitive creates alert fatigue; too loose hides concentrated harm.

Input drift score
sensitive (noisy)loose (blind)

Likely alert fatigue — too many false alarms

Complaint rate by group
sensitive (noisy)loose (blind)

Likely alert fatigue — too many false alarms

Override / appeal rate
sensitive (noisy)loose (blind)

Well-tuned threshold

Latency & tool failures
sensitive (noisy)loose (blind)

Well-tuned threshold

Blind spots

0

Noisy signals

2

Unowned signals

2

A dashboard nobody owns is decoration. A monitor needs a signal, a threshold tuned to the risk, an owner, and a response — or it will be ignored.

Choose signals based on the risk. A recommendation model may track click quality, complaint rate, and diversity. A fraud model may track chargeback outcomes, false positives by merchant segment, and input drift. A generative assistant may track groundedness, harmful output reports, escalation rate, and tool-call failures.

Some outcomes arrive late. In those cases, teams use leading indicators such as drift, override rates, or user appeals while they wait for labels.

Alert Fatigue

Too many low-quality alerts teach teams to ignore the system. Prefer fewer alerts with clear thresholds, owners, and playbooks.

Checkpoint

A model's overall accuracy is stable, but complaints from one user group doubled. What should monitoring do next?