Most enterprise IT leaders underestimate the integration costs of AI development. The standard guidance is to multiply the vendor quote by three or four, allocate a share of the budget to data preparation and integration engineering, and hold a contingency buffer. That gets first-year totals into a realistic range and still leaves the largest integration cost outside the model.
The gap is structural. Data preparation, model selection, and testing are project costs that end. Every connection an AI system depends on is an operating cost that starts at go-live and continues for as long as both systems exist. This article sets out how to budget the second kind.
Key takeaways
- Integration is the only line in an AI budget that never closes. Budgeting it as a percentage of a one-time project underfunds it from year two onward.
- Gartner expects at least 50% of GenAI projects to overrun their budgets through 2028, citing poor architectural choices and a lack of operational know-how, and notes that production systems can cost orders of magnitude more than pilots.
- Transaction-priced integration becomes unforecastable once autonomous agents are the actors, because the bill grows in proportion to how well the agents work.
- When a connection fails, the process it serves stops: customers wait, service levels slip toward penalty, and the repair hours are the smallest part of the bill.
- Budget integration per connection per year, separate internal connections from those crossing into customer and partner environments, and project three years.
For the operating model behind Managed Integration Services, the Integration Ops book covers lifecycle phases, ownership patterns, and playbook examples in depth. Download it free.
What are AI integration costs?
AI integration costs are the full cost of connecting an AI system to the data sources it reads and the systems it acts on, across the life of each connection. They cover the initial build, the ongoing operation of every connection, and the change work forced whenever a connected system is upgraded, migrated, or replaced. Build is a one-time cost. Operation and change recur annually for as long as the connection exists.
That split is the practical difference between an AI budget that holds and one that does not. Our analysis of integration total cost of ownership across delivery models covers the general case; this article applies it specifically to AI programmes, where the number of new connections rises quickly and the pressure to show value arrives early.
Why percentage-of-project budgeting breaks
Standard AI cost models allocate a proportion of the project budget to each category: a share to data preparation, a share to integration engineering, a share to testing and change management. The method is sound for the categories where the work finishes.
Integration is different. When an AI programme connects an agent to an ERP, that connection becomes a permanent obligation. It has to keep working through the next platform release, and somebody has to do the work that keeps it working. It needs credential rotation, monitoring, and repair, and it needs those things in 2031 as much as in the first quarter after launch.
Funding a permanent obligation as a percentage of a temporary budget produces a predictable pattern. Year one lands close to plan. Year two carries the accumulated run cost of everything year one built, plus the run cost of what year two adds, with no line item to absorb either. By year three the integration estate is maintained out of engineering capacity that was allocated to something else.
Getting this wrong costs more than IT hours. An underfunded connection fails more often and takes longer to repair, and every hour of repair is an hour in which the process that depends on it stands still: tickets stop moving between systems, records stop updating, customers wait, and any service level attached to the process moves toward penalty. That is the exposure a percentage-based budget leaves unpriced.
Four of the six recur. Most published AI cost breakdowns detail the first two well and compress the last four into a single maintenance percentage, which is where the underfunding starts.
Three cost drivers specific to AI programmes
Generic integration cost models were written for a world where humans triggered the transactions and connection counts grew slowly. Agentic systems change three variables at once.
Per-transaction pricing meets a machine-speed actor. A meaningful share of enterprise integration is priced per transaction: every record created or updated through the connection adds to the bill. That model behaves predictably while people generate the actions. An autonomous agent works continuously, and when an agent programme succeeds the transaction count rises by an order of magnitude. Cost then grows with how well the agents perform, which makes the line impossible to forecast. Teams looking at alternatives to transaction-priced native integration usually arrive there through this exact arithmetic.
Production writes cost more than pilot reads. Pilots pull data from a few systems in one environment. Production writes into systems of record governed by change control, owned by other teams, and often owned by other companies. Gartner's observation that production systems can cost orders of magnitude more than pilots has a concrete mechanism behind it, and a large part of that mechanism is the write path. The write path also carries the heavier failure consequences: a broken read leaves a report stale, while a broken write halts the process it serves, with customers and service commitments on the receiving end. Our analysis of what changes when AI agents enter your integration layer covers the technical side of this distinction.
Connection count grows faster than use case count. A single agent workflow rarely touches one system. Resolving an incident end to end might read from monitoring, check an asset database, update the ITSM record, and notify a partner. That is four connections for one use case, each with its own annual run cost, and the next use case reuses some of them and adds others.
Not all connections cost the same
A connection to a modern SaaS platform your team administers is well described by standard estimates. A connection into a customer or partner environment is a different object.
It requires two security reviews, agreement between two data models, an explicit decision about which fields may cross the organisational boundary, an escalation path both parties accept, an audit trail for disputed service levels, and a change process where neither side can compel the other. Establishing one takes longer and operating one costs more, because every change on either side is a negotiation. And when one fails, the disruption crosses the boundary with it: the customer's process stops as well as yours, and the service level you have committed to runs against you while both sides diagnose the fault.
For service providers connecting into client ITSM platforms, these cross-boundary connections are the majority of the estate. Any AI budget that prices all connections at one rate will understate the total by the proportion of the estate that crosses a company line.
"Before, 100%, it was very complex... every time you add a customer, there's another environment to go into." That is Michael at MHP, describing the multiplier that most business cases leave out.
What the Gartner forecasts say about AI budgets
Two predictions are directly relevant to how integration is funded.
Gartner expects at least 50% of GenAI projects to overrun their budgeted costs through 2028, attributing it to poor architectural choices and a lack of operational know-how. The second reason is the one integration budgets should answer: the cost of operating what the project builds.
Gartner also expects over 40% of agentic AI projects to be cancelled by the end of 2027, with escalating costs among the leading drivers. Escalation in an agent programme has a common source: the agent needs to reach systems nobody had connected, so connections get bought one at a time at project rates, during the period when the sponsor is asking for evidence of value.
What executives say goes wrong
There is buyer-side evidence for where these budgets fail. In PwC's 2026 Digital Trends in Operations Survey, which polled 767 US operations executives, 89% said their technology investments have not fully delivered the expected results. Asked why, they put integration complexity first: 52% named it, ahead of data issues at 46% and user adoption at 43%. Only 11% said their investments delivered as expected.
Read that ranking against this article's argument. The top reason results miss sits in the connections between systems, and those connections are exactly the line items the budgeting method above prices.
How to budget AI integration costs in four steps
- Count the connections behind each use case. For each AI use case, list every system it reads from and writes to. Mark which sit inside your organisation and which cross into a customer or partner environment, and note which ones carry a process that stops when they fail.
- Establish your own annual run cost per connection. Take it from the estate you already operate: engineering hours on maintenance, monitoring, and incident response over the past year, divided by the number of live integrations. This number is specific to your organisation and more reliable than any published benchmark. The method is set out in how to calculate and control the cost of service integrations.
- Apply a boundary multiplier. Price cross-organisational connections above internal ones, using your own delivery history for the ratio.
- Project three years, not one. Year one is build plus a partial year of run. Year two is the full run cost of everything built in year one, plus year two's build and run. Year three shows whether the model scales.
Add the build to the three-year run total and the resulting figure is the number to take into the approval conversation. It will be larger than the multiplier method produces, and it will still be there in year two.
Where a Managed Integration Service changes the numbers
A Managed Integration Service moves the four recurring line items to a provider under a subscription with a service commitment. Three effects follow in the budget.
The recurring cost becomes a single forecastable figure, which is the condition for planning it at all. Cross-organisational connections stop carrying a premium per customer, because any-to-any connectivity is what the service provides. And the transaction-pricing exposure disappears, since a subscription does not grow when the agents get better at their jobs.
ONEiO's own benchmarking points to substantially lower total integration cost under this model. Treat that as ONEiO's figure and run the four steps above against your own estate before relying on it.
When this is not the right choice. If your AI use cases connect only to modern platforms your own team administers, the connection count is small, and you have integration engineers with time available, the internal route is cheaper and simpler. The case for a managed service strengthens with the number of connections, the proportion crossing into other organisations, and the rate at which the connected systems change.
Bottom line on AI integration costs
The 3x to 4x multiplier is a reasonable correction to vendor optimism and every AI programme should apply something like it. It cannot fix the underlying category error, which is treating a permanent operating cost as an underestimated project cost.
Integration is the one line in an AI budget that behaves like rent. It is charged per connection, it recurs annually, it rises when the systems on either end change, and it continues after the programme that created it has closed. Underfund it and the consequences appear outside IT, in the processes, customers, and service commitments the AI programme was meant to improve.
Budget it that way. Count the connections, price a year of running one, separate the ones that cross a company boundary, and project three years. The number will be larger than the multiplier method produces, and it will still be accurate in year two.
Not sure where your integration layer stands? The Integration Ops maturity assessment gives you a structured read on ownership, monitoring, and change readiness across your estate.
