The Integration Iceberg: Why the AI Model Is the Cheapest Part of Your Project

A proposal lands for an AI system that reads incoming invoices, matches them against purchase orders, and routes the strange ones to a human. The model usage line says $220 a month at your volume. Someone annualizes it, compares it to a salary, and the room relaxes. Eighteen months later the company has spent $240,000, the system handles about half the invoice flow, and the AP team still keeps the old spreadsheet open on a second monitor. Nobody lied about the price. The budget described the tip of the iceberg and ignored everything under the surface.

I've sat through enough of these post-mortems, first inside a large enterprise and now with mid-market owners, to spot the pattern in the budget before kickoff. If the spreadsheet has one line for "AI" and that line is an API fee or a per-seat license, the project is underfunded, usually by a factor of five or more. So this piece is about what actually sits below the waterline, what the research says happens to projects that ignore it, and how to price all of it before you sign anything.

Why the model line looks so cheap

Model pricing is genuinely cheap, and it keeps falling. Say your AP team processes 8,000 invoices a month, each needing a few thousand tokens of context in and a structured answer out. At current frontier-model rates that lands somewhere in the low hundreds of dollars a month, less if a smaller model handles the easy cases. Per-seat assistant licenses are similarly friendly, priced like software subscriptions rather than like the consultants they're supposedly replacing.

Those are also the only numbers a vendor can quote with real confidence, because they're the only ones that don't depend on your environment. Token prices are public. License tiers sit on a pricing page. The sales conversation naturally anchors there, and the buyer's mental model of what this costs forms around the one component that was never going to be the problem. The model is a commodity you rent, and everything expensive about the project is specific to you.

What sits below the waterline

Here's the inventory I now assume for any workflow AI project, whether the workflow is invoices, contracts, support tickets, or scheduling.

• Systems integration. The model has to read from and write to the places where work actually happens: the ERP, the CRM, the ticketing tool, the shared inbox that secretly runs the company. Some of those have modern APIs. Some have an "API" that is really a CSV export someone runs on Fridays. Building and hardening those connections is engineering work, and a single connection routinely costs more than a full year of model usage.
• Data plumbing and cleanup. Vendor names spelled four different ways, missing PO numbers, two systems that disagree about the same customer. Before the model can be right, somebody has to define what right means and clean the data enough to check it. On most mid-market projects this is the first genuine surprise, and it shows up around week three.
• Security and compliance review. Your counsel, your IT lead, and sometimes your customers' security teams all get a vote. Vendor assessments, data processing agreements, access scoping, audit logging, retention rules, plus whatever your sector adds on top. Most of this is calendar time and senior-people time, which makes it invisible in a software budget and very visible in the delivery date.
• Exception handling. The demo shows the cases that behave. The build cost lives in the rest: the review queue, the escalation path, the screen where a human corrects the model, the rules about what the system may do unsupervised. Designing the failure paths usually takes longer than wiring up the happy path.
• Testing and evaluation. You need a ground-truth test set built from your own historical cases, a way to score the system against it, and the discipline to re-run that scoring whenever the vendor swaps models under the hood. Skip it and you learn about regressions from your customers.
• Change management. Training, process redesign, the awkward months of running old and new in parallel, and the harder question of what the team does with the recovered hours. If nobody redesigns the job around the tool, people quietly return to the old way, and the usage dashboard tells you months after it happened.

The failed pilots all sank in the same place

This framing would be easy to dismiss if the failure data pointed somewhere else, and it doesn't. Last August, MIT's NANDA initiative published its "GenAI Divide" report, built on 150 executive interviews, a survey of 350 employees, and an analysis of 300 public deployments, and it found that about 95% of enterprise GenAI pilots produced no measurable P&L impact. Model quality barely features in the explanation. The authors point instead at workflow integration: generic tools that don't adapt to how work moves through a company stall out, while the roughly 5% that succeeded picked one process, integrated deeply, and held someone accountable for a business number.

Two more findings from the same MIT report belong in every budget meeting. In the MIT sample, purchased solutions from vendors reached successful deployment about 67% of the time, while internal builds succeeded roughly a third as often. The report also found companies pointing more than half of their GenAI budgets at sales and marketing, even though the clearest measured returns showed up in back-office automation, the unglamorous territory of documents, procurement, and finance operations. The organizations seeing money back, in other words, treat this as an integration problem and pay for it like one.

The forecasts suggest plenty more companies are about to run this experiment on their own budgets. Gartner expects 40% of enterprise applications to include task-specific AI agents by the end of 2026, up from under 5% in 2025, and the same firm has predicted that over 40% of agentic AI projects will be canceled by the end of 2027, with escalating costs first on its list of reasons. In the cancellations I've watched up close, the API bill was never the trigger. The submerged costs surfaced late, after the money was committed and the sponsor's credibility was already spent, and by then killing the project was the cheapest option left.

A rough allocation heuristic

Every project differs, but after watching a few dozen of these budgets settle, here is roughly where year-one money goes on a mid-market workflow project that was priced honestly. Treat it as a sanity check rather than gospel, and adjust for your own mess.

• Model usage and licenses: 10 to 15%. On smaller projects it rounds down toward five.
• Integration engineering: 25 to 30%. Connectors, middleware, auth, retry logic, the things no demo ever shows.
• Data work: 15 to 20%. Profiling, cleanup, and deciding which system wins when two disagree.
• Security, compliance, and legal: around 10%. Mostly people time, and more than that in regulated industries.
• Exception design, testing, and evaluation: around 15%. The ground-truth set, the review queue, the regression checks.
• Change management and training: 15 to 20%. The line most likely to be zero in a proposal, and the one that decides adoption.

The way I actually use this list is backwards. When a proposal's total comes to only two or three times its model line, the missing mass is still there, it just hasn't been priced yet, and it will arrive later dressed as change orders. My working rule says a first-year total below five times the visible model-and-license cost means something under the waterline is unfunded. I'd rather see the ugly number up front, and so would your CFO.

Line items to price before you sign

Before approving an AI project, and definitely before signing a vendor agreement, get written answers, with numbers attached, on each of these. None of them are exotic, they're just usually asked in month four instead of week one.

1. The systems list. Every system the AI reads from or writes to, the integration method for each, who builds and maintains it, and what happens when one of those systems changes its API or gets replaced next year.
2. The data audit. Hours to profile and clean the specific fields this workflow depends on, and who owns data quality after go-live. Insist on the audit before any fixed-price quote, because a quote issued before anyone has looked at your data is fiction with a signature block.
3. The review calendar. Weeks for internal security review, vendor questionnaires, and legal, held by named people who have other jobs. On mid-market projects this is the critical path more often than the engineering is.
4. The exception budget. The assumed automation rate, the expected human-review percentage, who staffs that queue, and what the staffing costs. If a proposal assumes 100% automation, hand it back.
5. The evaluation set. Who assembles a few hundred historical cases with known correct answers, and what score on that set gates each phase of rollout.
6. The model-change plan. What happens when the underlying model is upgraded, deprecated, or repriced. Someone re-runs the evaluation and re-tunes the prompts, and that someone bills hours.
7. The parallel-run period. How long the old process runs alongside the new one, and what the duplication costs. Teams that skip this step discover their exception cases in production.
8. The decommission date. When the old process actually turns off, because the savings only start once it does.

How to run the budget conversation

A few moves that have saved real money for people I work with, all of them doable this week.

• Ask every vendor for an 18-month total cost, split into the six buckets above. A vendor who can't produce the split hasn't delivered in an environment like yours, and the inability to answer is cheaper diligence than a reference call.
• Choose the pilot process for data readiness and a willing owner. A back-office process with structured inputs and a manager who wants the help will beat a flashy customer-facing use case with messy data, which is exactly the pattern MIT's numbers show.
• Default to buying over building for anything outside your core product. The deployment gap in the MIT study is large enough to be the default answer, and it saves your internal engineers for the integration seams that are unavoidably yours.
• Give the submerged items named budget lines. Integration, data, evaluation, and change management should each carry an owner and a number, so nobody can quietly raid them to make the topline prettier.
• Gate spending on integration milestones and evaluation scores instead of demo dates. A vendor can stage a convincing demo in a week. Your ground-truth set, scored while the system is connected to your real systems, is much harder to fake.

Price the whole thing, then decide

At FirmAdapt we stopped quoting workflow projects without a short data-and-systems audit first, mostly because every time we skipped that step, the iceberg sent change orders instead of an invoice. The lesson transfers even if you never hire anyone. Whoever prices the submerged 85% before signing gets to make a real investment decision. Whoever prices only the model line makes that same decision anyway, just later, with worse options and less credibility.

None of this argues against the spend. The economics of workflow AI hold up fine when the whole iceberg is priced, and the well-chosen back-office projects I've been around have paid for themselves inside a year even at five times the naive budget. Just get the six buckets into the spreadsheet, put a name and a number on each, and treat the cheap model line as the smallest and least interesting row in the file.