Nothing broke. It drifted.
The failure mode of a mature AI process isn’t a crash. It’s drift: the slow, silent loss of fit between what the process does and what you actually need. Nothing errors. The reports still arrive. But the answers are a little more often wrong and the edge cases a little more frequent, until one day it’s doing more harm than good and nobody can say when that started. Drift comes from three directions at once:
| Where drift comes from | What it looks like | What catches it |
|---|---|---|
| The model changes | Outputs subtly shift after a provider update | A small regression test set you re-run on any change |
| The business changes | A new product, customer, or rule it never saw | A feedback loop that surfaces new edge cases early |
| The purpose creeps | People bolt on jobs it was never built for | A written statement of what it’s for, revisited |
First, write down what it’s for
The most skipped step, and the one that makes drift catchable at all: a plain sentence saying what problem this process exists to solve and what ‘working’ means. ‘Cut quote follow-up from 20 hours a week to under two, without a customer ever getting a duplicate.’ If you can’t write that sentence, you have no way of knowing when the process has stopped delivering it — you’re just hoping. Everything else here hangs off having named the target.
Should you make it do more?
A process that works invites scope creep — ‘it handles quotes, can it also chase invoices?’ Sometimes the answer is yes. The test is simple: does the new job share the same inputs and the same definition of right? If it does, extend it. If it doesn’t, you’re bolting a second process onto the first, and it will drag both out of alignment. One process with one clear job is far easier to keep honest than one clever process quietly doing five.
Get it out of your head
Drift is impossible to spot if the process lives only in one person’s memory. Document the purpose, the inputs it expects, the edge cases it can’t handle, the prompts and rules (with versions), and who owns it — in a shared workspace, not on a laptop. That’s what lets someone else debug it, take it over, or notice it’s wandered. A process nobody can read is a process nobody can tell is drifting.
Track what it costs and what it saves
You can’t manage what you don’t measure. Capture a baseline before you build — how long the manual job took, times how often it runs. Then track three numbers: time saved, what the AI costs to run, and how often it gets escalated or corrected. The first two tell you whether it’s still worth running; the third is your early-warning light — a climbing escalation rate is drift showing up in the data before it shows up as a complaint. It’s also the only way to defend the process to whoever signs the cheque. That discipline is half of applied AI done properly.