A VP of Engineering told me about their AI project last year. Budget was $2M. Actual spend was $6.8M. When I asked what happened, she said: “We didn’t understand what we didn’t understand.”

That’s not a failure of planning. That’s a failure of the budgeting framework itself.

The organizations I’ve seen blow through AI budgets aren’t usually incompetent. They’re using budgeting frameworks that were built for a completely different kind of work. And they don’t realize it until six months in, when the budget is half-spent and the project is 20% complete.

Why Traditional Project Budgeting Fails For AI

Traditional software project budgeting assumes a few things: – You know what you’re building – You know roughly how long it will take to build – You know what “done” looks like – You know what success means

AI projects violate every one of these assumptions.

You think you’re building a recommendation system. Once you start, you realize your data quality isn’t good enough. You spend six weeks fixing data. Then you realize your features don’t predict what matters. You spend another eight weeks rebuilding features. Then the model works, but it produces biased outputs. You spend another month on fairness improvements. None of these were “surprises” in the sense that they were unknown risks. They were surprises in the sense that you didn’t know they were going to be the blocking issues.

The fundamental problem is that AI projects are exploration work disguised as execution work.

In traditional software, you explore during the design phase. You do architecture reviews. You write specs. You plan. Then you build. The build phase is well-understood. You have precedent. You have patterns. You have experienced people who know how long it takes.

In AI projects, the exploration doesn’t stop. You’re executing, and you’re discovering simultaneously. You’re building the model and learning what the model can do. You’re testing it and discovering what it fails at. You’re deploying it and discovering what real-world performance looks like. Each phase reveals information that changes the phase that comes next.

So you budget for the plan you made in month one. But month three reveals that the plan was 40% wrong. Do you stop and replan? Most organizations don’t. They replan and continue. Which means you’re now $800K into a $2M budget, and you’ve got $1.2M left to finish work that actually costs $1.8M based on what you know now.

Where The Costs Actually Hide

There are five categories of AI project costs that traditional budgeting frameworks don’t account for:

1. The Data Prep and Exploration Tax

You need training data. In traditional software, data is often already there. In AI, you often need to acquire, clean, label, and prepare data. A team of people might spend 40% of the project doing this. And you don’t really know how much you need until you build the first model and discover what’s missing.

One organization budgeted $200K for data prep. Actual spend: $800K. Why? They discovered their labels were inconsistent. They had to relabel a dataset of 100K examples. They discovered they needed geographic variation they didn’t have. They had to acquire new data. They discovered the time-window for some features was wrong. They had to rebuild the dataset. This isn’t incompetence. This is the normal cost of working with data when you don’t fully understand it upfront.

2. The Model Exploration and Iteration Tax

You build a model. It gets 87% accuracy. Is that good? You don’t know without a baseline. You don’t know without understanding what 87% accuracy means for your business. Does a model that’s 87% accurate but biased against a particular group meet your requirements? You don’t know until you measure it.

So you iterate. You try different architectures. You try different feature sets. You try different training approaches. Each iteration takes computational time and engineer time. A team might do 30-40 iterations before landing on something that’s both technically sound and meets business requirements.

Budget for this? Most organizations don’t. They budget for “build the model.” They don’t budget for “understand the model well enough to deploy it.”

3. The Validation and Governance Overhead

Before you deploy, you need to validate that the model does what you think it does. You need to test it against edge cases. You need to check it for bias. You need to make sure it handles distribution shift. You need to document the failure modes.

This is where governance overhead becomes a cost item, not a process item. A data scientist might spend 30% of their time building the model and 70% of their time validating, documenting, and preparing for governance review.

Most organizations budget for “build” and assume “validate” is 10-20% overhead. In practice, it’s often 50-70% overhead, and it compounds when the governance structure isn’t clear (which it usually isn’t on first AI projects).

4. The Integration and Infrastructure Overhead

The model doesn’t live in isolation. It lives in your product. To make that work, you need to: – Set up infrastructure to serve the model – Build monitoring to track model behavior – Set up logging to understand what the model is doing – Build feedback loops to collect data on what’s actually happening vs. what you predicted – Set up retraining pipelines so the model stays fresh – Build fallback systems in case the model fails

This is often 30-50% of the total project cost, and it’s rarely budgeted separately. It gets rolled into “engineering overhead” or “platform overhead.” Then halfway through the project, the infrastructure work surfaces as a separate project that wasn’t in the original plan.

5. The Expectation and Iteration Tax

You deliver the model. It works. But the business stakeholders have ideas. What if we changed the optimization target? What if we added this constraint? What if we included this data source?

Each of these is reasonable. Each is a couple weeks of work. But if you’ve got three business stakeholders with two ideas each, that’s six iterations that weren’t in the original plan.

This is particularly tricky because it’s not the AI team’s fault. It’s the normal cost of stakeholder collaboration. But it’s not in the budget.

How Projects Actually Fail (It’s Not What You Think)

Projects blow up not because the AI is hard. Projects blow up because one of these five cost categories explodes, and there’s no buffer.

You start with: – $500K for team salaries (data scientists, engineers) – $500K for computing costs – $300K for infrastructure – $700K for contingency

Then you discover in month four that your data quality problem requires reworking 60% of your dataset. That’s $200-300K of work that wasn’t in the “data prep” budget. You absorb it from contingency.

Then you discover in month six that the model architecture you chose doesn’t scale the way you expected. You need to rewrite the serving infrastructure. That’s another $150-200K. Contingency again.

Then your business stakeholder wants to optimize for a different metric because the business priorities shifted. That’s another $100-150K of model work and validation.

By month eight, your contingency is gone, your data team is burned out because they’ve been fighting data issues for six months, your infrastructure team is frustrated because they’re building stuff that’s changing based on model decisions, and you’ve got $500K left and need $800K more to finish.

The project doesn’t fail because AI is hard. It fails because the budgeting framework assumed these categories of work were known and fixed, when they’re actually variable and interdependent.

What Budgeting Actually Needs To Account For

If you’re going to budget for an AI project correctly, you need to plan for:

1. A discovery phase with explicit budget. Separate from the build phase. If you’re going to learn 40% of what you need to know from building, budget that as learning, not execution. This might be 2-3 months and $300-400K for a medium-sized project. The output is not a production model. It’s clarity on what the production model will require.

2. Variable data and exploration costs. Budget for data work separately and generously. Assume you’ll need to rework data. Assume you’ll need more data than you think. Assume you’ll iterate on features and labeling. A 40% buffer on data costs is normal, not unusual.

3. Governance and validation as a distinct work stream, with separate ownership. Not a 10% overhead tax. A separate team, separate timeline, separate budget. If you’ve got a data scientist building a model, you need a governance architect validating it. That’s a different resource, different cost.

4. Infrastructure and serving as a separate project. The model is not the product. The system that makes the model production-ready is. Budget these separately. Assume infrastructure will be 30-50% of the total project cost if you’re building new.

5. Explicit contingency for stakeholder iteration. If your business doesn’t know what success looks like, budget for them to figure it out while you’re building. That might be 1-2 iterations that weren’t in the spec. Budget them.

6. Explicit assumptions about model performance. Don’t budget based on “build a model.” Budget based on “build a model that achieves X accuracy on Y metric while satisfying Z constraints.” The constraints matter more than you think, and they cost real money to validate.

The Math That Actually Works

Here’s what a real budget might look like for a $2M AI project:

• Discovery phase: $300K, 2-3 months. Goal: understand data, validate problem, identify architecture approach.
• Build phase: $800K, 4-5 months. Build model, do initial validation, iterate on architecture.
• Governance and validation: $300K, 2-3 months. Deep validation, bias testing, failure mode analysis, documentation.
• Infrastructure and serving: $400K, 3-4 months. Build serving infrastructure, monitoring, retraining pipelines, integration.
• Iteration and contingency: $200K, ongoing. Handle stakeholder changes, unexpected issues, performance improvements.

Notice: the “model” is maybe 40% of the cost. Everything else is making the model real and acceptable.

Notice: governance is explicit, not overhead.

Notice: there’s actual contingency, and it’s for things you expect to happen.

This is a better framework not because it predicts perfectly. It’s better because it accounts for the actual sources of cost in AI projects, and it gives you room to manage them when they happen.

Your next AI project will blow up. Some part of it will cost more than you expected. The question is whether you budgeted for that or whether you pretended it wouldn’t happen.