A tool that ignores how people already work gets used less, not more
A multiyear field study tracked 72 sales experts across 12 business units at a multinational pharmaceutical company after it introduced an AI system that recommended sales targets and objectives. The outcome split cleanly on one variable: whether the tool was tailored to how each salesperson already worked.
Salespeople who received a version tailored to their cognitive style sold significantly more than before. Salespeople who received an untailored version generally experienced it as interference. They used it less, and their sales performance declined. One participant using the untailored tool put it directly: "We got this super tool, and at the same time, I felt like [I was] in prison. There was no freedom to work the way I wanted to work."
The study period predates current large language model tools, but the mechanism is not specific to any model generation. A system that a team routes around is not a smaller version of a working system. It is a different outcome, and it shows up in adoption data before it shows up in a performance review.
Adding AI to a decision does not automatically improve it
A systematic review and meta-analysis of 106 studies compared the performance of humans alone, AI alone, and human-AI combinations across a range of tasks. On average, humans or AI working independently significantly outperformed the human-AI combination.
The combination did produce gains on content-creation tasks and on tasks where humans already outperformed AI on their own. On decision-making tasks specifically, the combination produced performance losses. The researchers concluded that designing how humans and AI combine on a given task deserves as much attention as designing the AI system itself.
This cuts against a common pitch in AI rollouts, that adding a model into a decision is a safe, additive improvement. The evidence says the combination has to be designed for the specific task, not assumed.
The split needs a framework, not an assumption
Both findings point to the same fix: decide, before deployment, what the system retrieves, drafts, or recommends, what a person decides or approves, and where the two hand off. NIST's AI Risk Management Framework Playbook organizes exactly this kind of decision into four functions: govern, map, measure, and manage. It is voluntary guidance, not a certification, and its own documentation is explicit that organizations should borrow the parts that fit their use case rather than apply it as a checklist.
Used that way, it gives an implementation team a shared structure for the questions the two studies above raise directly: who does the work today, where does the new tool actually sit in that process, and what will be measured to know if the combination is working better than either part alone.
What this means before the next pilot scales
Treat the interface between person and system as a design decision, not a byproduct of the technology chosen. That means walking the current process with the people who do it, identifying the exact step where the system will retrieve, draft, or recommend, and naming what a person still decides.
Then measure adoption and outcome separately. A system can be accurate in testing and still get routed around in practice, and a system that gets used is not automatically making the decision better. Both signals matter, and the research above shows they can move in opposite directions.