Budget for the whole AI capability

An AI budget should describe the capability the organisation intends to operate. Model access and software licences are visible purchase items, but they do not define the full commitment. The business also needs dependable information, usable integration, evaluation, support, and people who can take responsibility when the service behaves unexpectedly.

Leaving those requirements outside the proposal does not make them disappear. It transfers the work to teams that may already be fully committed. A pilot can then look inexpensive because its designers absorb effort informally. Scaling exposes that hidden dependence when the same people can no longer supervise every interaction.

Distinguish building from operating

I would separate initial preparation from recurring service work. Preparation includes understanding the decision, arranging appropriate data access, connecting systems, testing the workflow, and preparing users. Operation includes monitoring, resolving exceptions, reviewing changes, supporting employees, and maintaining the information on which the service relies.

Consider an illustrative assistant that helps staff interpret internal procedures. Its first demonstration may use a small set of clean documents. An operational version needs owners who approve revisions, withdraw obsolete material, resolve contradictory guidance, and decide who can access each source. Those are knowledge-management responsibilities with an ongoing cost.

The budget should identify where that effort will sit. Existing employees may be able to perform it, but their capacity still has an opportunity cost. A business case should state which responsibilities they will reduce, what additional support they need, or why the new work fits within available capacity. Assuming that maintenance is free creates a fragile operating plan.

Model the work created by use

Usage can change costs in ways that a licence estimate misses. More requests may increase review demand, support tickets, or exception handling. A higher volume of generated recommendations can also create more work for the teams expected to act on them. The value depends on the organisation’s ability to convert those outputs into useful decisions.

I would therefore build a small set of operating scenarios: limited use in one team, wider routine use, and a difficult period with elevated exceptions. Each scenario should identify the people, systems, and controls it requires. The purpose is to expose the conditions under which the proposed benefit becomes credible, rather than produce a precise forecast from weak assumptions.

The comparison should include alternatives. A conventional workflow, better source information, or a narrower AI service may deliver the important benefit with a smaller operating burden. An ambitious use case can remain on the roadmap while foundational work receives the first investment. Sequencing is a financial and architectural choice.

Give expansion an explicit funding decision

Pilot funding should buy learning within a defined scope. Production funding should support an accountable service. The transition deserves a review of actual usage, acceptable completion, human effort, support requirements, and the business outcome. A successful demonstration provides evidence for that review; it does not settle every operating question.

The service owner should also have a plan for changing providers or withdrawing the capability. Records, workflows, employee responsibilities, and customer commitments may outlast the initial tool. Understanding those dependencies helps leaders assess the durability of the investment and the work required to unwind it.

A complete budget makes the business case more useful. It lets leaders see what the organisation must sustain to obtain the promised result, compare that commitment with other priorities, and fund AI at a scale the enterprise can actually support.