Your Dashboards Show Uptime. Your Models Quietly Drift.

Your SRE board is green. Latency sits inside the budget. Error rates look boring. Someone still asks why the answers got worse last month, and nobody can point at a chart that explains it.

That gap is normal when you treat models like services. Services fail loudly. Models fail politely. They keep responding, keep returning 200s, and quietly stop being useful.

Uptime is the wrong primary signal

Classic observability answers a simple question: is the system reachable and fast enough? That matters. It is also incomplete for production AI.

A retrieval path can stay hot while the wrong documents climb the ranking. A classifier can stay online while a shift in customer language erodes precision. An agent can complete every tool call while choosing the wrong tool more often. From the infrastructure view, nothing broke. From the business view, trust did.

If your only production story is CPU, memory, p95, and availability, you are flying with half a cockpit.

Drift rarely announces itself

Model drift is usually gradual. Vendors change behaviour behind a stable API. Your own fine-tunes age against new tickets, new product names, and new policy wording. Prompt templates accumulate small edits. Knowledge bases grow without the same hygiene you demand from application code.

None of that trips a pager by default. Teams notice through support tickets, auditor questions, or a sponsor who stops believing the demo. By then you are debugging culture, not a regression test.

What to instrument instead

Keep the infrastructure stack. Add quality signals that map to decisions people actually make.

• Task success, not just response success. Did the user finish the job, or only receive a fluent reply?
• Groundedness and citation health for RAG systems. Track empty retrieval, low-overlap answers, and broken source links.
• Agreement with human review on a rolling sample, with clear severity labels rather than a single accuracy number.
• Policy and safety outcomes as first-class events: blocked actions, escalations, and false refusals.
• Cost per successful outcome, so cheaper models that create rework do not look like a win.

These signals do not need to be perfect on day one. They need owners, thresholds, and a place on the same operating rhythm as incident review.

Put quality into the release path

Shipping a model change through the same door as a static website is how blind deployments happen. Treat evaluation as a gate, not a slide.

Before promote:

1. Run a fixed eval set that mirrors production tasks, not toy prompts.
2. Compare against the currently live behaviour on the same cases.
3. Require an explicit go or no-go from the product owner for quality, and from security for tool and data access changes.
4. Canary with production traffic and watch quality metrics, not only latency.
5. Keep a rollback that restores the previous model, prompt bundle, and retrieval config as a unit.

If you cannot name the last time you blocked a release on quality, you do not have a release path. You have a hope path.

Make ownership boring and visible

Somebody must own answer quality the way SRE owns availability. In many Australian enterprises that role is still informal, which means it disappears under delivery pressure.

Write it down. Who watches the weekly quality pack? Who can pause an agent? Who updates the eval set when the business process changes? Who signs off when a vendor model version moves underneath you?

Without that, dashboards stay green and trust decays in the dark.

A practical starting board

You do not need a research lab to begin. Start with five tiles next to uptime:

• Weekly human-rated sample score by use case
• Groundedness or retrieval miss rate
• Escalation and override rate
• Regression count against the golden eval set
• Time to detect a quality drop after a change

Review them in the same meeting where you review incidents. Promote them when they catch real pain. Retire vanity charts that never change a decision.

The point

Production AI is not healthy because the container is up. It is healthy when the organisation can see answer quality moving, explain why, and stop a bad change before customers do.

Keep your latency graphs. Just stop pretending they speak for the model.