When an AI initiative goes to the executive committee for funding, the engineering team usually arrives prepared for technical questions. They have benchmarks. They have an architecture diagram. They have a comparison of model options. They are usually less prepared for the CFO's questions, and the CFO's questions are the ones that decide the funding.
Here are the questions I have heard finance leaders ask in these reviews, and how to be ready for them.
What is the unit cost, and how does it scale
The CFO wants to know what the marginal cost is per transaction the system performs, fully loaded, including inference, infrastructure, monitoring, and human review. They want to know how that cost changes as volume grows. They want to know whether the cost is dominated by fixed components or variable components.
This is not a question you can answer with a model card. You need a unit-cost model that decomposes the production cost into its components, with each component traceable to a line item in the budget. If you cannot produce that decomposition, the CFO's read is that you have not run the numbers.
What is the breakeven volume, and what is your confidence
For systems with non-trivial fixed costs, the CFO will ask when the unit economics turn positive. They want to know the volume threshold and they want to know how confident you are in the volume forecast.
The right answer has two parts. The threshold is a number, calculated from the unit cost model. The confidence is a range, with named assumptions. If your forecast assumes a ramp curve, the CFO will want to see the ramp. If the ramp depends on adoption from a specific business unit, the CFO will want to see the commitment from that unit.
What is the failure cost
Every AI system has an error rate. The CFO wants to know what a wrong answer costs. They want to know that cost in dollars, and they want to know it weighted by the rate of error.
For systems where errors are caught by humans, the failure cost is the cost of the review and the cost of remediation. For systems where errors propagate to customers, the failure cost includes the customer impact, the reputational cost, and any regulatory exposure. These are uncomfortable numbers to estimate. The CFO would rather see your estimate than have to generate one themselves.
What is the displacement story, and what is the assumption behind it
If the business case relies on cost savings from labour displacement, the CFO will want to know what specifically is being displaced and over what period.
The honest answer is usually less aggressive than the business case suggests. AI deployments rarely eliminate roles on the timeline that the business case claims. They more commonly shift the work, change the headcount mix, or absorb growth that would otherwise have required additional headcount. The CFO has seen enough business cases that overstated displacement to be skeptical of any case that claims it. A more measured claim, with a clear mechanism, is more credible than an aggressive one.
What is the dependence on a single vendor
The CFO is alert to vendor concentration risk in a way that engineering teams are sometimes not. They will ask what happens if your model provider raises prices, deprecates the model you depend on, or has an outage. They will ask how quickly you could migrate to an alternative.
The right answer is an honest one. The migration cost is non-zero. There is a switching path. The architecture abstracts the model behind an interface that makes substitution feasible. Quantify the switching cost in person-weeks if you can.
What does the operating cost look like in year three
Year-one numbers usually look good. Year-three numbers tell the truer story. The CFO will want to know the maintenance load, the model upgrade cost, the monitoring overhead, and the expected efficiency gains as the team learns to operate the system.
A common failure of AI business cases is to show a flat or declining cost curve in year three that has no engineering basis. Production AI systems have steady operational costs. Pretending otherwise is the kind of thing the CFO will catch and remember.
What is the value at risk if this fails
The CFO's job is to think about the downside. They will ask what happens if the system does not deliver on its promised benefits. They want to know how much was spent before the question can be answered, and how much was committed beyond that point.
A good business case has a checkpoint structure. After phase one, with a defined spend, you will know whether the unit economics work. After phase two, with a further spend, you will know whether the volume materialises. The CFO can fund phase one without committing to phase two. This structure protects the company and increases the odds of funding, because it bounds the downside.
The framing that gets funded
The AI business cases that get funded share a property. They are denominated in financial units the CFO uses, with assumptions stated and confidence intervals attached. They have checkpoint structures that bound the downside. They do not promise more than the engineering can deliver.
This framing is not a translation problem. It is a preparation problem. Engineering teams that work with their finance partners during the business case construction produce stronger cases, get funded more often, and ship more often.