engineering notes
Adopting AI in a company: where to start and what it costs
AI adoption pays off on specific repeated processes: where to start, how to compute cost and effect, what not to do.
In brief for executives. AI adoption pays off not when “the company now has AI”, but when one specific repeated process with a measurable effect is automated. Most failed adoptions fail not on technology but on framing: they automate “AI in general” instead of a process, measure the effect “across the company” instead of a concrete operation, and expect a result from a capability demo rather than a working process in production. Where to start and what it costs are questions that can be answered before the start if the process is chosen correctly.
“We need to adopt AI” almost always sounds at the company level, and the payback always lives at the process level. This gap is the main reason AI budgets go into demos without reaching the effect. Let’s go through where to start so adoption pays off, and what drives the price.
A process pays off, not “AI adoption”.
Hypothesis: you adopt a process, not “AI”
“Adopt AI” is not a goal but a phrasing without an object. The goal sounds different: “cut handling time of a request from three hours to twenty minutes”, “stop keeping two people on reconciling statuses across systems”. AI here is a tool inside a specific process, and payback is counted by that process, not by the fact of adoption.
Per IDC, of 33 launched pilots only about 4 reach production. The cause of failure is not technology — it is the underestimated complexity of taking it to a process.
Problem: the budget goes into a capability demo
A typical failed-adoption path: an impressive, not a payback-bearing, task is chosen; a demo everyone likes is built; scaling is attempted and hits the fact that a process was never really chosen. Money spent, no effect, and the company concludes “AI doesn’t work for us” — though it was the framing, not the technology, that didn’t work. The second common mistake is measuring the effect “in general”. If you cannot name a specific operation whose time or cost changed, then the effect is declared, not measured.
Why the usual approaches don’t work
“Let’s make an AI assistant and see” doesn’t work because it has no success criterion: it is unclear what counts as a result, so the result becomes the launch itself. “Automate everything at once” doesn’t work because different processes have different error cost and data readiness; trying to cover all of it stretches time-to-effect and kills trust. “AI for AI’s sake” doesn’t work arithmetically: automating a process that is rare or unstable doesn’t pay off — there’s nothing to save on.
Engineering model: how to pick a process and drive it to effect
Adoption that pays off follows a clear sequence.
Choosing a process by three signs. The process is repeated (happens often, not once a quarter), has a measurable output (time, cost, volume), and tolerates a controlled error (there’s a place where a human checks expensive decisions). Processes that fail these signs are poor candidates for a first adoption, however impressive.
Data and step audit. Before development it is determined whether data exists in the needed shape and where in the process decisions are made that can be removed from people. Often it turns out here that half the promised effect is not AI but cleaning up data.
A pilot with measurable effect and a human in the loop. One process is automated, expensive decisions stay with a human, metrics are taken before and after. The pilot’s goal is not “show capabilities” but get a number: it was this much, it became this much.
Scaling from a confirmed effect. The next process is taken only when the first has a confirmed number. This guards against “rolled out everywhere, paid off nowhere”.
Practical takeaway for business: where to start and what it costs
Where to start: pick one process where people mostly repeat similar decisions and where you can name a metric. Not the most visible — the most repeated and measurable. That is where adoption pays off fastest.
What it costs. There is no flat price for “AI adoption”, because you pay not for AI but for automating a specific process. Cost is composed of process complexity and the number of decisions in it, data and integration state, control and operation requirements, and the cost of models in operation. The right question to a contractor is not “what does AI cost” but “what does it cost to automate this process and over what period does it pay off”. If it isn’t answered with a number and a term — the process is chosen wrong or not analyzed.
What counts as effect. Repetitive work removed from people, shortened cycle time, fewer approvals. Not “AI adopted” but “this operation now costs this instead of that”. The goal is to scale operations without a linear headcount increase, not to cut people: these are different framings, and the second usually doesn’t pay off as promised.
Apply this to your processes — .
Open questions
Where the limit of automation without quality loss lies depends on the process and is set on the pilot, not a general rule. How to compute payback when the effect is removed coordination, not an explicit salary saving, is a task without a single standard; we count by cycle time and number of approvals, but that is a model, not an industry norm. How many processes to take in parallel after the first success is a question of manageability, not ambition; the answer is usually “fewer than you’d like”.
If you can name a process where people repeat the same decisions day after day — name the metric, and its payback can be estimated before the start. — we’ll work out whether it pays off and where to begin.