I've made the case on this site that AI's real value on a struggling program is time — it reads the whole record and surfaces trouble weeks before a human would. I stand by that. But there's a second act to that story, and I've now watched it play out enough times to write it down. The program stands up risk detection. The first month, it's revelatory. By the third month, the agent is producing so many flags that the team has built an informal habit of skimming the digest and acting on none of it. The early-warning system still fires. Nobody's listening.
This isn't a new failure mode, and it isn't an AI failure mode. Healthcare has studied it for over a decade under the name alarm fatigue: research at Johns Hopkins found that 72% to 99% of clinical alarms are false, and the documented result is that clinicians — competent, motivated people whose patients' lives are on the line — become desensitized and slower to respond to all alarms, including the real ones. If a false-positive rate that high can train ICU nurses to tune out, it will train your workstream leads to tune out by the second sprint.
The cruel part is that alert fatigue is a product of success. The agent does exactly what you asked. It reads every ticket, every thread, every schedule slip, and it misses nothing — which means it flags everything. A dependency touched late. A sentiment dip in a channel. A ticket reopened twice. Each flag is individually defensible. Collectively they form a wall of yellow that no human can act on, and a wall of yellow is functionally identical to silence.
Why programs make this worse than hospitals do
Hospitals at least know alarm fatigue is a patient-safety issue and govern it. Programs stumble into the same trap with three habits that make it worse.
1. Sensitivity is set once, by the vendor's defaults
Nobody on the program decided that a two-day ticket stall warrants a flag. A default did. Thresholds that were never deliberately chosen are never deliberately reviewed — so the flag volume reflects a configuration file, not the program's actual risk appetite. Tuning is treated as a technical chore instead of what it is: a governance decision about what the leadership team wants to be interrupted for.
2. Every alert has the same volume
The Army solved this problem before computers did. Radio traffic carries a precedence — routine, priority, immediate, flash — because a net where every message sounds urgent is a net nobody trusts, and the discipline of assigning precedence forces the sender to decide how much of someone else's attention this message deserves. Most AI alert streams have no precedence at all. The slipped dependency that threatens go-live arrives in the same channel, at the same volume, as the ticket that changed status twice. When everything is flash traffic, nothing is.
3. No alert has an owner
A flag lands in a channel and everyone assumes someone else is on it. This is the same seam problem that breaks programs between teams, replayed in miniature dozens of times a week: an alert addressed to everyone is addressed to no one. Without a named owner and a required disposition, the flag's lifecycle is fire, scroll, forget.
An early-warning system is not measured by what it detects. It's measured by what it gets a human to do. Every alert that produces no action doesn't just waste attention — it actively trains your team to ignore the one that matters.
Triage is the deliverable, not the alert
On the programs I run, the alert stream gets designed with the same care as the detection itself — because detection without triage is just anxiety at scale. It looks like this. Every alert class carries a precedence, and precedence dictates the channel: flash-level findings page a named human, priority items go to the daily standup, routine signals roll into a weekly digest that's allowed to be skimmed. Every non-routine alert has an owner on arrival and requires a disposition — act, watch, or dismiss with a reason — so silence is never an acceptable response to something the system called urgent. Dismissals feed tuning: a rule that gets dismissed ten times in a row is a rule that's miscalibrated, and it gets adjusted or retired at a monthly review, the same way a hospital reviews its alarm settings. And the metric leadership sees isn't alert volume — volume rewards the machine for shouting — it's response rate and time-to-disposition on the top tier. What you want to know is not how much the system noticed. It's whether the humans still believe it.
Notice that none of this is model work. It's governance work — thresholds, ownership, escalation paths, review cadence. Which is exactly why it gets skipped: it's the unglamorous half of the capability, the part that doesn't demo well. But the teams that skip it end up somewhere worse than where they started. Before AI, they didn't know about the risk. After AI, they knew and scrolled past — and a safeguard everyone trusts and nobody attends is more dangerous than no safeguard at all, because it's carrying trust it no longer earns.
- Give every alert class a precedence, on purpose. If you can't say what tier a flag belongs to, you can't say why it deserves anyone's attention.
- Route by precedence, not convenience. One channel for everything is how flash traffic drowns in routine.
- Name an owner on arrival and require a disposition — act, watch, or dismiss with a reason. Silence is a data point, and it should be an alarming one.
- Treat repeated dismissals as calibration data. Ten dismissals in a row is not the team being lazy — it's the rule being wrong.
- Report response rate, not alert volume. A system that finds less and moves humans more is the better system.
The bottom line
The promise of AI risk detection is real — I've seen it buy programs the weeks that made the difference. But detection is the cheap half. The expensive half is the discipline that keeps a human on the other end of the wire: precedence, ownership, disposition, tuning. The boy who cried wolf wasn't wrong about wolves existing. He was wrong about what a warning costs — every false one spends trust you can't easily buy back. Build the triage before you build the detector, and the machine's warnings will still mean something on the day the wolf actually shows up.