AI Runs on People: Roles, Judgment, and Adoption

Every business process converts something into something else. A quote goes in, a signed contract comes out. A defect signal goes in, a corrective action comes out. A patient chart goes in, a discharge plan comes out. There is an input, there is a throughput — the work that happens in between — and there is an output that the business ultimately gets paid for.

AI can move any of the three. It can widen the input, so the process sees signals it used to miss. It can compress the throughput, so the work takes less time or fewer hands or fewer handoffs. It can lift the output, so the answer is more accurate, the case routed to the right person the first time, the quote priced within a tighter band. Each of those is a business outcome. Each of those is worth spending money on.

What is not worth spending money on is a deployment that leaves all three unchanged. Nine in ten large companies now use AI somewhere in the business. Roughly one in three can point to a line on the P&L that moved because of it. The gap is not a gap between good AI and bad AI. It is a gap between deployments that changed the input, throughput, or output of a real process and deployments that added a faster assistant on top of the process as it already existed.

Every executive who has looked at an AI business case in the last two years has seen the same slide: the model, the platform, the security review, the integration diagram. It is a technology slide. The problem is that none of the items on it drive the outcome. They are necessary conditions, in the same sense that plumbing is a necessary condition of a functioning restaurant. Nobody eats there for the plumbing.

The things that actually drive the outcome are unglamorous and mostly non-technical. A specific business case, tied to a specific process, with a number attached — not “improve customer service” but “reduce first-call resolution time on billing inquiries from six minutes to under three.” A redesigned workflow that says which steps a person does, which the model does, where the check happens, what an exception looks like. New roles, or at least meaningfully rewritten ones, so the person on Monday morning knows what her job now is. Training that reflects what actually changed in the work, not a policy briefing. Change management that treats the middle of the organization as a set of people whose participation you have to earn, not a broadcast list. And adoption sustainment — a named owner, a review cadence, and enough floor-level support in the first eight weeks that the tool does not quietly stop getting used.

Those items look soft on a business case. They are what separates the deployments that move the P&L from the deployments that produce a demo. On the programs we watch work, the spend on the software itself is the smallest line. The spend on the change work around it — process, roles, training, sponsorship time, first-weeks support — runs roughly three times the software line. Programs that budget the change work as a residual instead of a real line item consistently underperform their case. It is the most reliable failure mode in the category.

We watched a global industrial company approve a two-year, high-eight-figure AI program last year. The CIO chaired it. The CFO signed the business case. The functional owners were on the distribution list. Six months in, the program had produced a curated model marketplace, a governance policy, and a dozen bounded pilots. Everyone was doing what their role told them to do. Not one input, throughput, or output of a real business process had changed.

This is the ordinary shape of the failure. When an AI program reports only through the technology function, the outcomes it produces are technology outcomes. A platform gets stood up. Licenses get issued. A council gets formed. Worth doing, and not the same as changing how the business runs. The programs that show up on the earnings call have a business owner and a technology owner on the hook for the same number — not co-chairs of a steering committee, two names next to one outcome. When only one of them is chairing, the other is not really committed, and it is better to hear that in the first meeting than to find it out in the sixth month.

There is also the question of what the money is trying to do. Most companies are using AI to run the same process faster. A smaller group is using it to make the process better — pricing more accurately, catching a defect earlier, routing a case to the right person the first time, seeing a signal in the input that used to get missed. Faster is a productivity story. Better is a margin story. Only the margin story shows up in EBIT, and only the margin story requires the underlying work to be redesigned rather than the click to be accelerated.

The most visible cost of getting the outcome wrong is the reversal tax. Klarna is paying it now. Ford paid it in engineering. The Careerminds survey found that among companies rehiring after AI-driven cuts, roughly a third said the rehire cost more than the original savings, and another 42% said the two cancelled each other out. The strategic clarity, the executive attention, the trust of the middle of the organization — those are harder to put on a spreadsheet and do not come back as easily.

The quieter cost is the pipeline. Where AI takes on the junior version of a task — the first-pass code, the initial legal read, the starter analyst deck — the apprenticeship that used to build senior judgment quietly stops running. In the near term this looks like a productivity win. Over five to ten years it looks like a bench problem, and rebuilding a bench is more expensive than protecting one.

There is also an optionality cost, easier to see in the companies that have avoided it. The best programs we see are making smaller, reversible bets while they figure out where the value actually sits. They are running short cycles inside one or two workflows, seeing what the redesigned work needs, and then scaling into the design that the evidence supports. The programs that treated AI as an IT deployment tend to have signed long-term commitments to a specific stack before they knew what the redesigned work looked like. The second group ends up with less regret and more optionality left on the table.

The companies we watch getting real returns are not doing anything exotic. They are doing five things, none of which appear on the technology slide.

They start with the outcome. Not “we should use AI in claims” but “we want to move first-notice-of-loss triage accuracy from 78% to 92%.” The number sets the input, throughput, and output the program is on the hook for. Everything downstream — the model choice, the workflow redesign, the training, the exception handling — gets evaluated against that number. Programs that cannot name the outcome in one sentence rarely produce one.

They pick a small number of workflows — one to three — and redesign them end to end. Real business owner, measurable outcome, enough volume that a small percentage move is worth the trouble. One to three done properly beats twenty touched lightly, every time.

They put a business owner and a technology owner on the same line of the plan, accountable for the same number. Then they budget the change work — process redesign, role rewrites, training tied to what actually changed in the job, named floor-level support in the first weeks, and adoption sustainment past week eight — as its own line, not a residual. On the programs that work, that budget is roughly three times the software spend. On the programs that skip it, the tool quietly stops getting used by month four.

They write down where a person decides and where the model decides, before the model is live. Then they write down what happens when the model is wrong, because it will be, on a knowable percentage of cases. A workflow that does not plan for the exception is a hope, not a workflow.

And they treat adoption as a sustained program, not a launch. Named owner, review cadence, a small set of leading indicators — usage inside the redesigned workflow, exception rate, the outcome number itself — and enough attention in months two through six that the middle of the organization understands the tool is not going away. Adoption without sustainment is a stat that peaks in week three and decays quietly for the rest of the year.

The technology is almost never the constraint. Klarna’s chatbot did what its vendor said it would do. Ford’s automation tooling worked. What went wrong in both cases was a decision about the business outcome underneath — what the process was supposed to produce, for whom, and at what quality. That decision does not belong to a technology function. It does not belong to a vendor. It belongs to the operator running the business.

The uncomfortable part is that the decision has to be made without the certainty a leadership team would prefer. The technology is moving faster than the planning cycle. The evidence is thin, mixed, and often contradicted by the next release. The temptation is to defer — to run more pilots, to wait for one more benchmark, to see what the analysts say. But deferring is a choice too. Every quarter without a redesigned workflow tied to a real outcome is a quarter of licenses paying for the operation the company already had.

The organizations that will look back on this cycle with something to show for it are the ones that decided, deliberately, which inputs, throughputs, and outputs they wanted to move — and then did the unglamorous work of redesigning the process, the roles, and the way people got trained and supported to run it. Everyone else will have a very expensive collection of assistants and a growing suspicion that the technology was never the point.