The cars that drove into rivers
Drivers following satellite navigation into a river is not an urban legend. There are multiple reported cases.
In Ripon, England, a truck driver followed guidance into a shallow ford and had to be rescued when the river rose with rain. At a lake in Massachusetts a driver went straight into the water and the car was submerged. In Washington State, what someone took for a road in the middle of the night was a boat launch ramp.
What is worth noting is that most of them saw the signs. They saw there was water. They saw it and trusted the screen more.
This failure has a name. And the failure in exactly the opposite direction has its own name. Put the two on one table and where AI adoption goes wrong lines up.
1997: four ways of relating to automation
This is the taxonomy Raja Parasuraman and Victor Riley set out. The paper's title is the list itself: humans and automation, use, misuse, disuse, abuse.
First, use. The normal choice of turning automation on and off. The paper also identifies what drives that choice: how much you trust the tool, how busy you are right now, and how risky you feel this task is.
Second, misuse. Leaning on it too much. Monitoring lapses and judgment tilts toward the automation. The river cases above are this.
Third, disuse. Having it and not using it. The state where a tool is bought and nobody turns it on.
Fourth, abuse. Different in character from the other three. This is not the user's behavior but the designer's and the manager's. Introducing automation without considering the consequences for human performance, in which case the operator's role is left undesigned, defined as a byproduct of the automation.
Hold these four against your current situation and most of the trouble in AI adoption lands inside this table.
Misuse: it worsens as reliability rises
There is a counterintuitive part to misuse. It gets worse when automation almost never fails than when it fails often.
The reason is simple. Checking a tool that is right ninety nine times out of a hundred feels like waste every single time. And in most cases it really is waste. So stopping the check hardens into what looks like a rational choice.
The problem is the remaining one time. When that one arrives with the checking gone, there is no line of defense left. And that one time is generally not an ordinary situation but a rare one. The structure from episode ten holds here unchanged.
This is why the people who drove into rivers were not unusual people. That machine had been right hundreds of times. The accident happens at the moment that accumulation outweighs a road sign.
The same in AI. Because summaries are mostly accurate, you stop opening the source, and from the moment you stop, an inaccurate summary passes straight through.
Disuse: the boy who cried wolf makes it
The opposite side is disuse. The tool is there and people do not use it.
The most common cause is false alarms. When an alert cries wolf often, people turn it off or ignore it. That is not laziness but learning. Experience so far has taught them that this notification is usually nothing.
Clinical settings are the textbook case. Of the alarms that sound on a hospital ward, only a minority actually require action; the rest are a patient shifting position or a sensor briefly slipping. The result is alarm fatigue. The sound becomes background, and response is slow when a real alarm finally goes off. This has been the subject of formal safety warnings.
What matters here is where the cause sits. The cause of disuse is not human attitude but threshold design. That is why you measure the false alarm rate before asking why people are not using it.
The same shape appears with AI tools. Someone who got wrong answers the first few times never opens that tool again. They do not open it even after the tool improves. The first impression served as the threshold.
But disuse is not always wrong
One caution here. Do not treat disuse as resistance to be overcome in every case.
Below a certain line, inaccurate automation does not help a person; it gets in the way. Pooling multiple studies, one reported boundary sits near a reliability of 0.7. Below that, using the tool is no better than not using it.
Think about why and it is obvious. Use a low reliability tool and you have to recheck every result. That simply adds a checking task on top of the original work. And the property that checking loosens when an answer sits beside you stacks on as well.
So when the question why is nobody using this tool comes up in an organization, there are two answers. One is genuine disuse driven by a first impression. The other is a sound judgment that the tool really does not help on this work. Fail to separate them and push usage rates alone, and the first goes unfixed while the second becomes a loss.
Abuse: the only one of the four that is not the user's behavior
The fourth is the substance of this episode.
Abuse is introducing automation without considering the consequences for human performance. The change of subject has to be underlined. Misuse and disuse are behaviors of the person using the tool; abuse is the behavior of whoever decided to adopt it.
In AI adoption this shape appears as follows. The tool is chosen first and the process is fitted afterward. What remains for the human is not discussed. Review gets no scheduled time, exceptions have no owner, and only accountability when things go wrong is clearly assigned to the person.
And the symptoms in a person placed in that state are exactly what the previous episode described. The remaining work got harder while chances to practice vanished, and they are told to monitor with a capacity that has dulled from disuse.
So if episode ten covered the symptoms, abuse is the name of the cause.
Abuse is the most expensive of the four
The other three are visible. Trust too much and there is an accident; do not use it and you can see the tool sitting idle. Both show up in metrics.
Abuse does not. The tool runs well and the adoption metrics look good. Volume rises and turnaround falls. Meanwhile the human side quietly degrades.
And it surfaces late. Usually it first surfaces when a rare situation arrives, which is to say at the moment the human has to intervene. By then the capacity is gone.
Accountability lands in the wrong place too. The state was created by whoever decided the adoption, while the failure occurs where the person doing the work stands. So the conclusion after an incident easily becomes individual carelessness, and the cause stays exactly where it was.
One term only: trust calibration
Trust calibration is aligning the trust a person places in a tool with the tool's actual reliability.
Misuse is trust higher than warranted; disuse is trust lower. So the goal is neither raising nor lowering trust but matching it.
There is a practical reason this phrasing helps. Discussions of AI adoption usually set the goal as usage rate or acceptance. Getting people to use it more becomes the objective. Set trust calibration as the goal and the question changes: how far should this tool be trusted?
And matching requires one condition. People have to know where the tool goes wrong. Without that, trust stays high or low on no grounds. That is where this episode's practical items start.
Which of the four is your organization in: four questions
Misuse? Over the past month, how many AI outputs went out as they were? Of those, in how many did a person actually find something wrong? If that second number is zero, review is a formality. Having reviewed and never caught anything probably means it was not read, not that it was perfect.
Disuse? Of the tools adopted, how many are actually used at least weekly? When you ask why not, do you hear because it was wrong once? Then check when that experience was and whether it still holds. As the previous section showed, it may be justified disuse.
Abuse? When this tool was adopted, was the remaining human work defined in a document? Is time for review in the schedule? Is it settled who handles exceptions? If none of the three, it is abuse.
Calibrated? Can your people state in one sentence what kind of work this tool gets wrong? If not, trust sits high or low on no grounds.
Note that only the abuse question has a different respondent. The other three are asked of the people using it; that one is asked of whoever decided the adoption.
So what changes tomorrow
Attach a one line where it goes wrong to each tool. Put it at the top of the usage document. This tool is weak on recent information; this tool often drops numbers inside tables. That kind of line. It is the cheapest form of trust calibration.
Work on reducing false alarms first. The cause of disuse is threshold design, not human attitude. Measure the false alarm rate before asking why nobody uses it. And if the rate is high, fix the threshold rather than run training.
Put the human share into the adoption document as its own section. Write only what gets automated and not what is left to the person, and what is left gets defined as residue. That one section separates abuse from proper adoption.
Record the number of errors caught in review. This number shows the health of an adoption better than usage rate does. A run of zeros signals that review has become a formality, and that is the moment to rework the review process.
In short: make the goal how correctly it is trusted, not how much it is used.