What AI integration actually costs, and the part that is missing from every quote

Connecting a model to the systems your business already runs on, so that something happens as a result. Not a demo, not a chat window bolted to a website, but a model that reads from real data, produces an output, and that output reaches a person or a process that acts on it.

That definition matters because the phrase covers two very different purchases. Calling a hosted model from an existing tool is configuration, and it is cheap. Putting a model inside a workflow where its output is trusted is engineering, and the cost sits almost entirely in the parts that are not the model.

Most disappointment in this category comes from paying for the first and expecting the second.

Because the quote prices the build, and the build is the smaller half. Published analysis puts integration work alone at 35 to 50 percent of initial development cost, and names it as the most frequent source of overrun. That is before the model does anything.

Then the running costs begin, and they behave differently from ordinary software. Inference is charged by use, so the bill grows when the thing succeeds. Retraining and re-evaluation are recurring, not one off. Monitoring has to exist or failures stay invisible. Published figures put the 24 month total at 1.6 to 2.2 times the original build cost once those are included.

None of that is a vendor being dishonest. It is a scope question that nobody asked. The fix is simple and almost nobody does it: ask for the three year number rather than the build number.

The state of the data it reads from. A model pointed at clean, consistently structured records is a different project from one pointed at four systems that disagree. The second is a data problem wearing an AI label, and it is usually the larger piece of work.

How wrong the output is allowed to be. A suggestion a human reviews is cheap. An output that acts without review needs evaluation, fallback behaviour and monitoring, and those are engineering line items rather than model tuning.

How often the surrounding systems change. Every integration has a permanent relationship with the systems feeding it, and those systems are versioned, renamed and replaced without consulting it.

Volume, because inference scales with use. A pilot with twenty users and a rollout to two thousand are not the same cost shape, and the second is rarely modelled during the first.

It fails quietly. An automation or a model that stops working does not announce itself the way a crashed server does. It keeps returning answers and the answers get worse. Without monitoring in place from the start, the first person to notice is a customer.

The evaluation set never existed, so nobody can say whether a change made things better. A system you cannot measure cannot be improved safely, only altered hopefully.

And the knowledge leaves. The people who understood why a particular prompt, threshold or transformation exists move on, and what remains is a system nobody is willing to touch.

When nobody can name the decision the output will change. If the honest answer to "and then what happens" is that someone looks at it, the value is not there yet. That is the single most useful question to ask before committing anything.

When the underlying process is not written down. Automating an undocumented process encodes whatever it currently does, including the parts that are wrong, and makes them harder to see.

When the volume is low. The engineering, the monitoring and the maintenance do not get cheaper because the task is rare, and a rare task rarely earns them back however irritating it is.

And when the real driver is that competitors have announced something. That is a genuine force in these decisions and it is worth naming out loud, because it is often the one actually deciding.

Ask what is excluded. Testing, monitoring, evaluation, the integration work itself and post launch support are where a low number hides its real cost. Get the exclusions in writing.

Ask for the three year total, broken into build, running and change. If a vendor cannot produce that, they have not scoped the project, they have scoped a demo.

Ask who maintains it in year two and whether that person has been told. The answer is revealing more often than it should be.

And notice who is answering. The party explaining whether you should integrate AI is frequently the party paid to build it. That does not make them wrong, but it does mean the question is worth asking somewhere with nothing riding on the answer.