A CFO's guide to AI spend: What to ask before you approve anything

When a CFO reviews a request for new manufacturing equipment or a real estate lease, the standard is well established: a defined cost, a projected return, a downside case, and a clear point where the company walks away if the numbers don't hold. AI spend rarely gets the same treatment. It moves through approval on a single confident number. There is no agreed-upon way to check that number against reality once the money is spent.

N-iX has watched this play out repeatedly through our AI consulting services, running adoption engagements inside engineering organizations across finance, logistics, and manufacturing. The pattern holds regardless of industry: the tool gets funded, a workshop introduces it to the team, and six months later nobody can say with confidence whether it changed anything that shows up in the numbers finance actually tracks.

This guide sets out the questions worth asking before that happens again. They are drawn from what we have seen: separate AI investments that pay for themselves from money that just accumulates. It also covers how to structure the commitment itself, so that if the answer turns out to be no, finding that out costs you very little.

Key takeaways

Here's what this CFO's guide to AI spend comes down to:

• Most AI spending is approved based on a single confident number and is never checked against reality once the money is spent.
• License cost is usually the smallest part of what AI actually costs once implementation, integration, and monitoring are counted.
• A financial case with only one scenario hasn't calculated the risk; it's hidden it.
• Funding in phases, tied to evidence at each stage, is what makes a wrong bet cheap to discover.
• Kill criteria set in writing before a pilot starts are what separate a serious proposal from an open-ended one.
• A pilot too small to trust, either way it comes out, costs more than an honestly scoped one.

Why most AI spend requests don't survive a real review

Most AI spend requests read well in the room they're presented in. Few survive a check against delivery data six months later.

In the demo, the vendor shows the tool solving a real problem in real time. Backing that up, a slide claims a percentage improvement in output, though the source is the vendor's own customer base. On top of that, the CTO or head of engineering vouches for the technology, and the requested budget looks modest compared to headcount costs.

None of that holds up once someone builds a baseline and checks it against reality. Vendor-supplied ROI numbers come from an adoption curve built on the vendor's best customers. Real rollouts look different:

• Adoption spreads quickly: some engineers use the tool within the first week, while others never open it.
• Training and integration costs rarely appear in the pitch because no one asked the vendor to account for them.
• The hours a senior engineer spends reviewing AI-generated output get absorbed into normal work, so they never show up as a cost anywhere.

Finance teams trying to justify a completed AI spend usually reach for individual productivity numbers instead: suggestions accepted or lines of code generated. None of those connect to what a CFO actually needs to know: whether the organization ships faster or with fewer defects than before the tool arrived.

A 2025 study from METR found that experienced developers using AI coding tools on complex tasks took 19% longer to complete than without the tools, despite believing they'd been about 20% faster.

That gap, between what an engineer feels and what a sprint retrospective shows, is exactly what a proposal built on individual sentiment can't close, no matter how enthusiastic the pilot team was.

Governance usually gets pushed to the end, and that's exactly when it costs the most. Most AI spend requests treat security review and compliance vetting as something to sort out once the tool has proven its value. But engineers don't wait for that sign-off. The moment a tool is approved, developers are running proprietary code through third-party servers. In some cases, this happens before final approval. Nobody has checked those servers for data residency or access controls.

Business teams outside engineering build their own prototypes without involving IT. Some reach production before security has reviewed them. So by the time a governance review actually catches up, AI spend has already produced technical debt and compliance exposure that are live, and unwinding both costs far more than doing the review upfront ever would have.

A request survives the room it's presented in, but fails the six-month test because nothing in it was built to be checked. The number that got the proposal approved and the number that would prove it worked were never the same number to begin with.

Questions CFOs should ask before investing in AI

In our AI consulting engagements, these are the questions that consistently separate an AI spend proposal worth funding from one that's just well presented. They're the same questions we ask before running a pilot with a client's own engineering team.

Can they show one workflow, before and after, or only a demo?

A demo proves the tool works in a controlled setting with clean data and a script nobody has interrupted yet. It doesn't prove the tool works in your environment, on your codebase, with your team's actual habits. Ask for one specific workflow: a named process, the time or cost it took before, and what changed after someone on your team actually ran it. If the answer comes back as a general capability pitch instead of a single measured example, the proposal isn't ready for a budget decision. It's still in the sales stage. A workflow with a before-and-after number tells you the tool has been tested against reality at least once. A demo tells you it works when nothing goes wrong.

What is the cost of AI once implementation and monitoring are counted?

License cost is usually the smallest part of what you'll actually pay. Ask for a breakdown across every category before approving anything:

• Integration work to connect the tool to existing systems and data;
• Security and compliance review before the tool touches anything sensitive;
• Training time for the team, and the productivity dip while they climb the learning curve;
• Ongoing monitoring: the hours someone spends checking output and fixing what the tool gets wrong;
• What each of those costs looks like if usage scales past the pilot group.

A vendor who can only quote the seat price has not accounted for implementation, integration, or the ongoing cost of someone reviewing what the tool produces. Ask for the full breakdown before approving anything.

Does the financial case include a conservative scenario, or only the vendor's best case?

Every AI ROI framework for CFOs assumes something about adoption speed, accuracy, and how much of the projected time savings actually gets used for anything valuable. The assumption usually comes from the vendor's best customer. Ask for three numbers: a conservative case built on your own past adoption patterns, a base case, and the vendor's optimistic case. The gap between conservative and optimistic tells you how much risk you're actually approving. A proposal with only one scenario has not calculated the risk. It has presented the best case and called it the plan.

What data does this tool touch, and what happens to it if the vendor is acquired?

This question gets skipped more often than any other on this list, and it's the one with the longest tail if it goes wrong. Ask exactly what data the tool reads, whether that includes proprietary code or customer information, and whether any of it is used to train the vendor's models. Then ask what happens to that data and to your contract terms if the vendor gets acquired or shuts down. A vendor with a clear answer to both questions has thought about this before you asked. A vendor who needs to check with legal and get back to you hasn't done so, which tells you something about how they'll handle the rest of the relationship, too.

What would make you recommend killing this, and who decides?

Ask the team presenting the proposal to name, in writing, the specific result that would prompt them to recommend stopping. Not a vague sense that it "isn't working," but a number: adoption below a certain threshold after a set period, no measurable change in the metric it was meant to move, cost exceeding a defined ceiling. 

Every phase has a point where we stop and check the numbers together. If they don't justify the next step, we say so. That's not a risk for the client. It's the only way to build something that lasts. Yaroslav Kisylychka, Director, Head of GenAI Value Lab

Yaroslav Kisylychka

Director, Head of GenAI Value Lab at N-iX

Teams that can name their own kill criteria in advance have thought seriously about what success looks like. Teams that can't are asking you to fund something open-ended, which is a different and much riskier request than the one on the page.

Who signs off after launch, and what triggers a second look?

Someone specific needs to own the review of the tool's output on a defined schedule. There also needs to be a trigger for revisiting the decision: a drop in the target metric, a spike in errors traced to AI-generated work, or a significant gap between how the team uses the tool and how it was pitched. If nobody can name that person or that trigger, the tool will run unexamined until something breaks badly enough to force a conversation nobody wanted to have on that timeline.

If this works, what's the plan to get it in front of the next team? If it doesn't, what's the off-ramp?

A successful pilot that stays with the pilot team isn't a success. It's an isolated result that costs money to produce and won't compound into anything larger unless someone has already planned how it would spread. Ask what the path to the next team looks like before you approve the pilot. Ask the same question about failure: what does canceling actually involve, what's the notice period, what data or access needs to be revoked, and how much of the investment is recoverable. A proposal that answers both questions looks like an AI business case CFO will approve. A proposal without them was built to get through this meeting.

How to structure AI spend without betting the whole budget upfront

Every question in the previous section assumes someone already has the information to answer it. Getting there requires a commercial structure that produces evidence early, before the company has committed enough money to make walking away expensive. Most AI engagements are priced and structured the way software licensing has worked for twenty years, and that structure is wrong for a category where nobody yet knows which workflows will actually pay back. Here's how we structure AI spend at N-iX, and why each piece exists.

We fund it in phases, tied to evidence

A single upfront commitment forces you to bet the entire AI spend on the overall outcome before you have any data on any part of it. An annual license, a multi-year platform contract, a fixed-scope implementation project quoted at six or seven figures: all of these ask you to believe a projection before your own team has produced a single measured result. If the projection is wrong, you've already paid for it.

We split funding into three phases, and each one is contingent on what the previous phase actually produced:

• Assessment: a defined cost, an output limited to a baseline measurement, and a shortlist of workflows worth testing. Nobody's committing to the technology yet. We're finding out together whether it's worth committing to.
• Pilot: runs on real production work, testing the top workflow from the shortlist. At the end, there's a number: did the workflow show a measurable gain in throughput, cycle time, or defect rate, or didn't it?
• Scale: only for what the pilot proved. A workflow that worked for one team gets rolled out to others with a documented playbook. A workflow that didn't work gets dropped without ceremony.

We put the go/no-go criteria for each transition in writing before the first phase starts, along with the cancellation terms at every stage. We set both before there is a relationship to protect, because criteria set after the results often justify the outcome instead of evaluating it.

We help you decide whether to build, buy, or borrow before we price anything

Before any of the phased structure above gets negotiated, there's a prior decision that changes what "reasonable cost" even means:

• Build it internally when the capability sits close to your core product, and you have engineers who can own it long-term. Reaching a working result almost always takes longer and costs more than the initial estimate. The estimate rarely accounts for the learning curve of a team building something for the first time.
• Buy a pre-built product when the use case is common enough that it's already been solved elsewhere. It's the fastest path, but you inherit someone else's roadmap, pricing changes, and security posture along with the tool.
• Borrow the expertise through an engagement like ours, where we embed with your team temporarily. It sits between the two: faster than building from zero, and it leaves your engineers with the skill and the workflow once we leave.

The deciding factor is usually speed against control. If the business needs the capability to live within weeks and the workflow is common across the industry, buying or borrowing beats building every time. If the capability is going to differentiate the product for years and the team has the bandwidth to own it, building starts to make sense despite the slower start. We tell clients this even when it means recommending against working with us. Getting this decision wrong is expensive. Teams that build when they should have bought spend months on infrastructure that already exists elsewhere. Teams that buy when they should have borrowed end up locked into a tool that does not fit the workflow, with no internal capability to change it.

We put exit terms in writing before you need them

Most engagements in this category define what happens if everything goes well and say almost nothing about what happens if it doesn't. That gap gets discovered at the worst possible time, usually a few months in, when the pilot data isn't looking good, and someone finally reads the termination clause closely for the first time.

We put four things in writing before signing anything:

• The notice period required to cancel at each phase;
• What happens to your data and access on exit;
• Whether any unused portion of prepaid spend converts to a credit or gets refunded;
• Who owns the code, prompts, or configurations built during the engagement.

This matters more with AI work than with typical software procurement, because what you're often exiting isn't just a subscription. It's access to your codebase, your data pipelines, sometimes a fine-tuned model trained on your own information. Walking away cleanly means actually walking away, with nothing of yours retained on our side that shouldn't be.

We price pilots to answer the question

There's a temptation to make the pilot phase as inexpensive as possible so it's an easy approval. We've seen where that leads: a pilot priced low enough to approve without much scrutiny usually comes with a scope too thin to produce a trustworthy answer either way.

A pilot that's too small tends to fail in the same few ways:

• One narrow task was tested instead of a representative slice of real work;
• One enthusiastic engineer running it instead of a normal mix of skill levels;
• One good week measured instead of enough sprint cycles to average out noise.

If it "succeeds" under those conditions, you've bought confidence nobody's earned. If it "fails," you may have killed something that would have worked with a fairer test.

We don't price a pilot at the lowest number a client will approve. We price it at the smallest scope that still includes enough engineers, enough sprint cycles, and enough workflow variety to produce a result worth trusting either direction. That number is usually higher than a bare-minimum pilot and considerably lower than a full rollout. The difference is worth paying, because the entire value of a pilot is the reliability of what it tells you. A cheap pilot that produces an unreliable answer costs more than an honestly scoped one, once you count what gets decided based on it.

What structured AI adoption looks like when N-iX runs it

Everything in this guide so far has been a framework for evaluating AI spend. A CFO reading it deserves proof that it produces something specific. The examples below come from N-iX's own AI-augmented engineering engagements: a baseline measured first, a pilot run on real production work, and a decision to scale made only once the numbers justified it.

From 13% to 91% AI adoption across 140 engineers

A transportation company had 140 engineers spread across six workstreams, with AI tool adoption stuck at 13%. Most engineers had access to a coding assistant. Almost none of them used it in their daily workflow because no one had connected the tool to a measurable outcome anyone cared about. Adoption rose from 13% to 91% after the same assessment-then-pilot sequence described earlier: baseline first, a scoped pilot on the workflows most likely to show results within weeks, then a rollout built on what actually worked. Sprint velocity increased 27%. Onboarding time for new engineers dropped from two weeks to three days.

Cutting post-release bugs from 15 to 4 per cycle

A housing management company had a QA issue that surfaced after release. 15 post-release bugs per cycle; test coverage at 55%. The fix wasn't a new testing tool bought and handed to the team. It was a rebuilt QA workflow, with AI doing the parts of test generation and review that were consuming engineer time without improving the actual outcome. Post-release bugs dropped to four. Test coverage rose to 81%.

See how the QA workflow itself changed: Read the housing management case study.

Making knowledge search 120x faster

An enterprise software company had a knowledge search problem that cost engineers time every single day. Finding the right internal documentation, code reference, or prior decision meant manual lookup across scattered sources, repeated by every engineer who hit the same wall. AI-powered search, built on top of the existing knowledge base, was tested against the manual process using real queries and measured directly. Search that used to require manual digging now returns results 120 times faster.

See how the before-and-after comparison was measured: Read the enterprise knowledge search case study.

What to do with the next AI reaches you

This CFO's guide to AI spend comes down to one habit: pull the next proposal out and check it against three things before anything else. First, does it name one specific workflow, its current cost, and the metric it's supposed to move, or does it describe a general capability instead? Second, is the cost broken down across implementation, integration, and ongoing monitoring, or does it stop at the license line? Third, does the financial case show a conservative scenario alongside the best case, or just the one number that got it this far?

If it fails any of those three, send it back before it goes further. Send it back to close the gap: name the workflow, get the full cost breakdown, build the conservative case. A proposal that can't survive that request within a week probably won't survive six months of actual use either.

If it passes, the next decision is structural. Don't approve the full spend in one commitment. Instead:

• Fund a scoped assessment first;
• Run a short pilot on real work;
• Put the go/no-go criteria and cancellation terms in writing before phase one starts;
• Make the scaling decision only once the pilot produces a number.

That single change, funding in stages instead of all at once, is what turns a proposal you're guessing about into one you're actually testing.

Let N-iX look at your next AI proposal

The questions CFOs should ask before investing in AI don't change once you're talking to us. The checklist above works whether or not you talk to us. But knowing what to ask and having a team that can deliver the answer are different things. That gap is usually where a second or third AI initiative stalls, even after the first one is approved correctly.

N-iX runs the AI spend evaluation sequence described in this guide as a standing engagement, built on the same APEX framework behind the case studies above. A GenAI Productivity Assessment Lead and a small team of specialty architects, drawn from a bench of over 200 AI and data professionals across a 2,400-person engineering organization, spend one to three weeks inside your engineering team before anything gets deployed. They audit the tools already in use, separate what's producing measurable output from what's sitting idle, and identify which workflows are worth piloting based on effort-versus-impact data. By the time a pilot starts, the baseline is already documented, so the before-and-after numbers going to the board are real.

What comes out of it is a scoreboard your own engineers run without us once the engagement ends: throughput, adoption percentage, cycle time, and change failure rate. Governance gets built into the assessment itself, so data residency and access controls are settled before a tool touches production. It's the same approach N-iX has run for clients from Fortune 500, over 23 years in the market.

If there's a proposal on your desk that needs a second opinion, or your team needs help building the baseline before committing to anything, contact the N-iX team. The first conversation takes time to describe what's on the table and will tell you within a week whether the proposal is worth pursuing at all.

FAQ

What is the AI ROI formula CFOs should use?

The AI ROI framework for CFOs we use starts with one formula: ROI = (Financial Benefit − Total Cost) ÷ Total Cost, where Financial Benefit combines time savings, cost avoidance, and any revenue uplift. Time savings should be calculated as the baseline time minus the AI-assisted time, multiplied by volume and the fully loaded hourly rate.

What should be in an AI total cost of ownership model?

License cost is usually the smallest piece. A complete model adds implementation, integration, change management, ongoing monitoring, and, for high-volume or agentic use, the variable cost of token and inference consumption.

What questions should CFOs ask AI vendors before signing?

Ask what data the tool touches, what happens to that data if the vendor is acquired, and whether they can show a bad output alongside how a reviewer would catch it. A vendor with clear answers has thought about this before being asked.

What's a realistic payback period for enterprise AI investment?

A short pilot should show a directional signal within weeks. Full-scale, infrastructure-heavy AI investment tends to compound value over a longer horizon, and treating both timelines the same is a common reason boards lose patience with initiatives that were never designed to pay back in year one.

How do you build an AI business case a CFO will actually approve?

An AI business case CFO will approve names one specific workflow, its current cost, and the metric it's meant to move, then show conservative, base, and upside financial scenarios side by side. A case built on a single confident number, without a baseline to compare against, rarely survives scrutiny past the approval meeting.