AI Platform and Security · Module 5 · Delivery and Operations

Observability, Monitoring and Drift in Production

The lesson explains how to keep an AI system trustworthy after go-live. Participants distinguish data drift, concept drift and performance decay, design an observability stack that separates the unsampled record of events from sampled operational traces, define a drift detection job and service level objectives for a probabilistic service, plan sampled human review that avoids feedback loops, and extend incident management with an AI classification step, an impact query and a path back to evaluation.

Lesson 21 of 25Chapter 2190 minutes

Read the chapterThe whitepaperThe slides

All courses / AI Platform and Security / Module 5 / Chapter 21

Learning objectives

After the lesson the participant can:

Key concepts

Data drift and concept drift
Data drift occurs when the distribution of inputs changes while the relationship between inputs and outputs stays the same. Concept drift occurs when the relationship itself changes. Performance decay is the observable consequence of either.
Evidence pipeline
The route by which the record of events reaches an append-only store with retention locks. It is not sampled, because Article 12 of the AI Act requires automatic recording of events over the system's lifetime.
Drift detection job
Scheduled, versioned code that compares a reference window with a rolling current window for input drift, prediction drift and delayed-label accuracy. Its thresholds are the same values as in the post-market monitoring plan.
Blind sample
A small sample in which officers decide before seeing the system's suggestion, with a record of whether each decision was made with or without it. Without it, accuracy measured against decisions that follow the suggestion becomes meaningless.
Impact query
A query listing which decisions each model version made in which period, used for remediation after an incident. It is the reason the Article 12 record must be complete and unsampled.

Interactive exercises

Do them here and get feedback at once. Choose a card and then where it belongs, or drag it.

Interactive exercise 1 · Put in order

The AI incident runbook

Put the steps of Nordvik Region's AI incident runbook in the order the runbook gives them.

Interactive exercise 2 · Match

Indicators for a probabilistic service

Match each service level indicator with its definition in the chapter's table.

Teaching plan

10 minThe teacher describes a model as a frozen summary of the past and asks for examples of data drift and concept drift from participants' own domains.
20 minDraw the observability stack with its four telemetry sources and two pipelines, then read the drift job for the claims-routing classifier check by check.
15 minCover quality monitoring with sampled human review, the service level objectives table and the error budget for grounding rate.
35 minExercise: groups write a drift job and work through an incident tabletop with Nordvik Region's runbook structure.
10 minDebrief on awareness time, the rule against silenced alerts and what suspension requires of the fallback path.

Discussion

  1. Labels often arrive late or never. For which of your systems do you never learn the right answer, and what do you monitor instead?
  2. Suspension is called an architectural requirement: a tested switch and a fallback that absorbs the load. Could your organisation process the work manually for a week, and has it tried?
  3. Awareness time is recorded at detection because a time reconstructed later will be reconstructed generously. What else in an incident record is tempting to reconstruct afterwards?

Written exercise

Exercise · 35 minutes

A drift job and an incident tabletop

For one production AI system of your own, or for Nordvik Region's claims-routing classifier, define a drift detection job: the reference source, the current window and minimum sample, an input-drift check on named features, a prediction-drift check, a delayed-label check with the label delay you really face, and the actions on warning and on alert. Then run a tabletop: the input-drift alert has been in alert state for a day after a rule change. Write how you confirm it, how you assess whether it is real and matters, how you narrow the system before suspending it, what evidence you preserve, which notification questions you assess in parallel, and what you add to the golden dataset afterwards.

Deliverable: A drift job definition with thresholds and actions, and a completed incident sheet with awareness time, containment steps, notification assessments and the follow-up test case.

Self-test

Choose an answer to see whether it is right, or open the answer below each question.

  1. Why is the evidence pipeline in the collector configuration not sampled?

    Show the answer

    A. Because Article 12 of the AI Act requires automatic recording of events, and a sample is not a record
    The event log store is evidence kept for the regulatory period; the operational trace store is sampled because its cost should match its purpose.

  2. What does the chapter prescribe to counter a feedback loop in which case officers accept a decision support tool's suggestions by default?

    Show the answer

    C. Record whether the human decided with or without the suggestion, and keep a small blind sample
    Otherwise recorded decisions converge on the model's output, and the authority cannot show that human oversight is effective and not nominal.

  3. In Nordvik Region's drift runbook, how may a drift threshold be changed?

    Show the answer

    D. Through a pull request to the drift job, never a silenced alert
    Forbidding silenced alerts keeps the thresholds aligned with the post-market monitoring plan, which is generated from the same file.