Enterprise Risk Management

Before You Put AI Savings in the Budget

An AI pilot can succeed while its savings claim is wrong. Count the whole job, assign the freed capacity, and verify which expense will actually change.

By Kennedy Risk Group · Tue Oct 13 2026 · 9 min read

The AI pilot can be a success and the savings line can still be wrong.

A team may finish work faster without reducing a single invoice or payroll payment. That is not a reason to reject the pilot. It is a reason to decide what the freed capacity is for before putting cash savings in the budget.

Measure AI productivity against accepted work, including review and correction. Then connect the released time to an observable operating change. A faster draft is evidence about one task. A smaller contractor invoice is evidence about cash. They belong in different parts of the business case.

This distinction matters when Finance is asked to fund the next round of licenses. The strongest pilot proposal does not merely say how many hours the tool saved. It names the work that will change next, who can authorize that change, and the evidence that would make the sponsor revise the claim.

Research is a reason to test the workflow, not borrow a percentage

There is credible evidence that AI can improve productivity. There is also credible evidence that users can misjudge its effect on their own work.

In the published Quarterly Journal of Economics study Generative AI at Work, researchers examined a staggered rollout to 5,172 customer-support agents at one company. Access to the assistant increased issues resolved per hour by about 15% on average. Gains differed by experience and skill; the most experienced and skilled workers saw little productivity improvement. This was a particular support environment using an earlier generation of AI, not a general estimate of what a finance team should put in its budget.

METR's early-2025 randomized study reached a different result in a different setting: 16 experienced open-source developers worked through 246 tasks in repositories they knew well. Allowing AI made completion take 19% longer. Afterward, participants still believed AI had made them faster. The small, specialized sample and tools available at the time limit how far that result travels.

The later evidence matters too. In its February 2026 follow-up, METR said it believed newer tools were more helpful, but selection effects made a reliable current estimate difficult. Developers' willingness to work without AI, and which tasks they brought into the study, affected what could be measured.

These studies do not cancel each other out. They show why a company needs evidence about its own work. Neither a favorable study nor an enthusiastic user survey establishes a cash saving in your business.

Count the finished job

Consider a constructed quote-processing pilot. Every figure below is an illustrative scenario, not a KRG client result.

The team produces 1,200 accepted quotes a month. Before AI, preparation, review and correction together require 30 minutes of labor per accepted quote. That is 600 hours a month.

With AI, preparing the draft takes 12 minutes. A sponsor compares 12 with 30 and reports 360 hours saved each month.

But the old measure covered the whole job. The new measure stops at the draft. Add eight minutes for review and five minutes for corrections and exceptions, averaged across all quotes. The comparable figure is 25 minutes, or 500 hours a month. The workflow has released 100 hours, not 360.

The same team also spends 20 hours a month maintaining instructions, checking recurring problems and overseeing the tool. Those hours are additional to the per-quote review and correction already counted. Net released capacity is 80 hours a month.

Review time is not automatically a failure. It may be what makes the work safe to use. The error is leaving it outside the measurement boundary while counting the output as finished.

There is another check: an accepted quote must mean the same thing before and after the pilot. If faster output contains more pricing errors, missing approvals or returns for correction, the apparent gain may be borrowing time from the next person in the process. Track those failures alongside labor time. Also record elapsed turnaround time separately; less hands-on work does not necessarily shorten the customer's wait.

The calculation behind the capacity claim

The tempting 360-hour claim comes from 1,200 × (30 minus 12) ÷ 60. Its arithmetic works. Its comparison does not.

Give each freed hour a destination

Now the operational decision starts. The 80 hours are not automatically available wherever Finance wants them. Small fragments of time spread across people, shifts and locations may not combine into a usable block. The manager needs a plausible way to change assignments.

In this illustrative scenario, the team can consolidate the time and take on 40 hours of work previously performed by a contractor. The employees have the necessary skills, service quality is maintained, and the contract permits the reduction. At $75 an hour, the next monthly invoice falls by $3,000.

The remaining 40 hours go to an existing backlog. That can be worthwhile, but the example makes no claim that clearing it will produce incremental sales. Employee salaries remain unchanged.

Incremental software costs are $1,500 a month. The recurring cash improvement is therefore $1,500 a month: $3,000 less contractor spending, minus $1,500 for software. Any implementation costs would need a separate place in the investment appraisal; this recurring calculation is not total project ROI.

Multiplying all 80 hours by an employee cost rate and adding that amount to the contractor reduction would overstate the benefit. The salaries are still being paid, and some of the released time already explains the lower contractor bill.

If the contractor invoice cannot actually change, the $3,000 cash claim disappears. The capacity gain may survive. Management can still approve the tool for that reason, but it should approve a capacity investment with an incremental software bill.

The same discipline applies to growth claims. More selling time is not additional contribution margin until there is evidence connecting that time to incremental business, allowing for delivery costs and other constraints. Our discussion of risk interdependencies is useful here: improving one activity may expose the next bottleneck instead of increasing the system's output.

Design the next pilot so it can disappoint you

A pilot whose only question is whether participants like the tool will rarely settle a funding decision. Ask the workflow owner and Finance to agree on the comparison before results arrive.

Start with a narrow unit of accepted output: a reconciled account, an approved quote, or a support issue resolved without reopening. Define quality checks and decide who will record corrections. Keep the baseline and pilot boundaries identical, including work transferred to reviewers or other departments.

Where feasible, assign comparable tasks or teams to AI and non-AI conditions rather than letting people select only the easy cases. Record task difficulty, user experience and tool version. A before-and-after comparison may be the practical choice, but changes in workload, staffing or seasonality then remain competing explanations. Do not present that design as a controlled experiment.

Let the pilot run long enough to include representative exceptions and repeat work. A fixed number of days is not evidence of adequacy. If the test excludes month-end, complex customers or difficult cases that dominate the real workload, its conclusion should say so.

Keep user estimates of time saved as feedback. Compare them with observed completion records, correction work and accepted output. Do not silently substitute one measure for another when observation proves inconvenient.

Before expanding licenses, ask the sponsor to complete this sentence:

“If this gain persists, the operating change we will make is ___, authorized by ___, and we will verify it using ___.”

For the illustrative quote team, the answer is a reduced contractor assignment, authorized by the service owner and procurement, verified against the invoice and quality records. “People will have more time for higher-value work” leaves the hardest part unanswered.

Existing AI prompts for risk management can help organize the questions. They cannot establish the benefit. That requires records from the workflow and a person accountable for acting on the result.

Some worthwhile benefits will not become immediate cash

A strict cash-only rule can reject useful investments. Faster response, less exhausting work or extra capacity at month-end may justify a tool even when the payroll does not move.

The answer is to describe the benefit honestly and choose a measure that fits it. If the purpose is faster service, inspect turnaround times and missed commitments. If it is resilience, test whether the team can handle a defined workload spike without unacceptable errors or overtime. If it is employee experience, collect that evidence without converting every favorable response into dollars.

Nor should a pilot demand savings from every user. The support-agent study found unequal gains across workers. A sensible deployment may concentrate on the tasks or people who benefit, while preserving a different method elsewhere. That is an operating choice, not a failed company-wide transformation.

The funding discussion becomes more useful when management can say exactly what it is buying. The approved benefit might be cash, usable capacity or better service. What it cannot be is the same hour counted under each heading.

If your risk reporting cannot distinguish a promising activity from a verified business outcome, start by assessing that broader decision process. KRG's scorecard is a proportionate first step toward deciding whether your current risk work gives leaders evidence they can act on. It is not an AI productivity certification.

Assess your risk decision process