Data, Integration and Operational Costs

In late 2025, MuleSoft and its research partners asked 1,050 IT leaders how many applications their organizations ran. The average was 957, up from 897 a year earlier. Only 27 percent of those applications were integrated with one another¹. The survey is sponsored by a company that sells integration software, so read it as a direction rather than a precise measure. The direction is hard to argue with.

Now think about what an AI system has to do to earn its keep. It must read from some of those applications and write its results into others: the record system, the scheduling tool, the finance ledger, the document store. It needs data that is clean enough to act on. It needs people for the cases it cannot handle, someone watching it, and a plan for the day it stops. Model, Compute and Infrastructure Costs priced the engine. This chapter prices everything the engine is bolted into, which is often the larger bill.

The core idea

The model is priced per request. Almost everything around it is priced by something else. That single observation explains why so many AI budgets go wrong in the same direction: a forecast that scales every cost with volume will be roughly right about the model and wrong about the rest.

This module uses one definition of total cost of ownership: build plus run plus operate plus change, over the system’s life, as Understanding AI Total Cost of Ownership set out. Data, integration and operations appear in every one of those families. The question this chapter answers is narrower and more practical: for each of them, what drives the cost, and which number should a leader ask for? To keep the arithmetic honest, one illustrative example runs through the chapter. Suppose a hotel group uses AI to read 40,000 incoming group-booking inquiries a year, extract the dates, rooms and event requirements, and route each one to the right hotel’s sales queue. The model and compute cost 200,000 a year.

Existing data is not free data

Data is a cost often entered as zero, because the organization already holds it. Holding data and being able to use it are different things, and the gap between them is paid for at four stages.

Acquiring means getting the data out of the systems that hold it, or licensing it from outside, with the contract, legal and engineering work each route brings. Preparing means cleaning, removing duplicates, matching records across systems and, often, labeling examples so the system’s quality can be tested. Pipelines move data in production: ingest, validate, store and serve. Freshness is a cost choice here, because data updated every minute costs more to move and check than data updated every night. Governing means controlling who can see what, keeping and deleting records on schedule, and being able to show an auditor what the system used.

The first two are mostly build costs. The last two are run and operate costs, and they never stop. In the hotel example, preparing the historical inquiries and the property directory costs 150,000 once, or 50,000 a year over a three-year life. Pipelines, storage and governance cost 200,000 a year. Data comes to 250,000 a year, more than the model.

The cheapest-looking choice, skipping preparation, often proves expensive. Poor data does not disappear; it returns downstream as wrong output, rework and manual review. Gartner predicted in February 2025 that through 2026 organizations will abandon 60 percent of AI projects unsupported by AI-ready data, and found that 63 percent of organizations did not have, or were unsure whether they had, the right data management practices for AI². The useful question is not “is our data good?” but “how much preparation does this outcome need?” Perfect data for every purpose is unaffordable; adequate data for one purpose usually is. Where the data is about people, reuse has a legal price too: a new purpose needs a lawful basis and must fit the purpose for which the data was collected, which the LEGAL note below sets out.

Integration is owned, not finished

An AI system that cannot reach the systems where work happens produces suggestions nobody acts on. Each connection to a record system, a scheduling tool or a finance ledger has a cost, and that cost has a life.

At build time the organization pays for interfaces, identity and access, mapping fields between systems, and testing. That is the part most business cases include. After go-live, every connection needs monitoring and failure handling, because when one link fails the whole workflow stops. Then, at a time the AI team does not choose, a connected system is upgraded and a field changes format. Requests start failing, and someone has to find out why.

The driver here is not volume. It is the number of connections multiplied by how often the systems at the other end change. A useful estimate is simple: connections, times interface-affecting changes per year, times the cost of absorbing one change. In the hotel example, three integrations cost 240,000 to build, or 80,000 a year over three years. Each connected system has about two changes a year that touch the interface, and each costs about 20,000 to absorb: 3 times 2 times 20,000 is 120,000 a year. Integration comes to 200,000 a year.

Two management levers follow. Fewer, standard connections cost less to own than many custom ones. And the cheapest change is the one you hear about in advance, so agreements with the owners of upstream systems about change notice are an economic control, not an administrative courtesy.

Operations: keeping it trustworthy

A production AI system needs people and routines that a pilot can do without. Someone monitors quality, not only uptime, because a system can be available and wrong. Someone re-tests it after each change to the model, the prompts or the data; Understanding AI Total Cost of Ownership showed that such changes arrive on a schedule. A support desk answers users. An incident process handles failures, which Human Oversight and AI Incidents in Module 06 covers in detail. And someone tracks the cost itself: the FinOps discipline treats measuring cost per unit of business value as a continuing practice, not a one-off report³⁴.

In the hotel example, monitoring, re-testing, support and incident response cost 150,000 a year. That is the smallest of the operating lines. The largest is often the people who handle the cases the system cannot.

Pricing the exception queue

The Economics of AI treated human review as a dial that every business case must set. Once it is set, the cost of the people behind it can be priced with three numbers: how many cases go to a person, how long each takes, and what an hour of that person’s time costs, fully loaded.

In the hotel example, 15 percent of inquiries cannot be routed with confidence. That is 6,000 cases a year. At 20 minutes each they take 2,000 hours, and at 100 an hour the exception queue costs 200,000 a year, every year. As the volume grows, so does the queue, and Understanding AI Total Cost of Ownership showed how such costs rise in steps as each new reviewer is hired.

The obvious lever is the review rate, and here there is a trap. In 1983 the psychologist Lisanne Bainbridge described the ironies of automation: the more a system automates, the more the work left to people consists of the unusual, difficult cases it could not handle⁵. Operational and Workforce Risk in Module 06 treats the human side of that irony. The economic side is simple. When the system improves, the easy cases leave the queue first, so the remaining cases take longer.

Suppose an improvement halves the review rate to 7.5 percent, or 3,000 cases. If each still took 20 minutes, the cost would halve to 100,000. If the cases left now take 30 minutes, they need 1,500 hours and cost 150,000. The saving is 50,000, a quarter, not the 100,000 the improvement’s sponsor will quote. Ask for the time per case after the improvement, not before it.

Resilience and the expected-value test

Reliability is a cost decision too. Failover, redundancy, backups and a tested manual fallback all cost money, and so does going without them. Outages are not cheap: in Uptime Institute’s 2026 analysis, 57 percent of respondents put their most recent major outage above 100,000 dollars⁶. An AI system in a critical workflow inherits that exposure.

One test decides whether a resilience investment is worth it. A one-off resilience cost pays off only if it avoids more expected downtime cost than it costs. Expected downtime cost is the cost of one hour down multiplied by the hours you expect to lose. If there is a 50 percent chance of a ten-hour outage in a year, the expected loss is five hours.

Suppose a failover setup costs 30,000 once and is expected to avoid five hours of downtime a year. In a critical workflow where one hour down costs 10,000 in delays, manual work and missed service, it avoids 50,000 a year and pays for itself in the first year. For an internal report where an hour down costs 1,000, it avoids 5,000 a year and only 15,000 over three years, half its cost. Criticality, not technical maturity, justifies resilience. The test also exposes a common gap: if nobody can say what one hour down costs, nobody can judge the spend.

Cost-to-serve: putting the lines together

The completed business outcome is the unit that ties these lines together. The Economics of AI asked which unit a system’s cost should be measured in, and Model, Compute and Infrastructure Costs priced the model’s share of a successful outcome. Cost-to-serve is the complete version: everything it takes to deliver one finished outcome, with data, integration, operations and people included⁴.

Add the lines in the hotel example: 200,000 for the model, 250,000 for data, 200,000 for integration, 200,000 for exceptions and 150,000 for operations. The complete cost is 1,000,000 a year, or 25 per inquiry. The model alone was 5 per inquiry, 20 percent of the total. Data, integration and exceptions together are 65 percent.

That split changes the management conversation. A cheaper model could remove at most a fifth of the cost. The larger levers are the review rate and time per case, the number and stability of connections, and how much data preparation the outcome truly needs. The split also tells you how the cost will move: exceptions and part of operations grow with volume, integration grows with change, and data grows with every new source.

Story: the clinics where the model was not the problem

A well-documented case of these costs comes from a health screening program, not a finance department. Diabetic retinopathy is a leading cause of blindness, and Thailand had about 4.5 million people with diabetes and roughly 200 retinal specialists to examine their eyes. Screening results could take up to 10 weeks to come back. A deep learning system that read eye photographs, built by a Google Health team, had shown more than 90 percent accuracy in the lab and could return a result in under 10 minutes⁷. In 2018 and 2019 the researchers deployed it in eleven clinics in two provinces and studied what happened, through observation and interviews with the nurses who used it⁸.

Their post-mortem, published in 2020, is unusually candid. More than a fifth of the images were rejected by the system as too poor to grade, often because they had been taken in poorly lit rooms⁷. On slow connections, each image could take 60 to 90 seconds to upload, and in one clinic a two-hour internet outage cut the number of patients screened from 200 to 100⁹. Patients whose images were rejected were told to see a specialist at another clinic on another day, and one nurse estimated that 40 to 50 percent of patients, a share of people rather than of images, did not take part because they thought they would have to go to the hospital⁹.

The study reports no money figures, and the translation into cost families is this chapter’s, not the authors’. But the shape is unmistakable. The model’s accuracy was not what the clinics struggled with. The quality threshold met the data that a busy, under-resourced clinic actually produced, and every rejected image became an exception handled by a nurse or a patient. The connection the system relied on decided how many patients a session could serve. And the exception path, a trip to a specialist elsewhere, imposed a cost on the very people the system was meant to help. The researchers’ own conclusion was that the system had to be evaluated in the setting where it would run, before it was deployed widely⁸. For a leader, the economic version of that lesson is to price the data, the connections and the exception path in the real setting before the business case is approved.

What this means for leaders

The discipline fits on one page. Ask for each cost family by its driver, not as a percentage of the model: data by source and freshness, integration by connection and change rate, operations by volume, exception rate and criticality. Ask for the exception queue as three numbers, and for the time per case after any improvement. Apply the expected-value test to resilience spend, which means someone must know what one hour down costs. And ask for cost-to-serve, the complete cost of one finished outcome, before you approve and every quarter after go-live.

Check yourself

1. Data the organization already holds costs close to nothing to use in an AI system.MythFact
2. Integration cost depends mainly on the number of connections and how often the connected systems change.MythFact
3. Halving the review rate halves the cost of handling exceptions.MythFact
4. A one-off resilience cost pays off only if it avoids more expected downtime cost than it costs.MythFact
5. If the model is a fifth of the complete cost, a cheaper model is the strongest lever.MythFact
6. In the Thai screening deployment, most problems sat in the data, connections and exception path around the model.MythFact

Reflection: price one outcome

What comes next

With data, integration and operations added to model and compute, the cost structure of an AI system is complete. What it does not yet show is time. A pilot can prove an idea with clean sample data, one connection and a team willing to check every output by hand. Running the same idea for thousands of users is a different economic proposition. That difference is the subject of Experimentation vs Production Economics.