Your 2027 AI budget is not an AI shopping list

An AI budget can be neat, approved and already incomplete.

The licence line is present. There is an allowance for model or API consumption. A cloud estimate has been added. The business case carries an ambitious productivity target.

What is missing is the work required to make the capability useful, controlled and economically accountable: data permissions, knowledge preparation, integration, testing, monitoring, security, workflow redesign, management time, user support and a mechanism for stopping initiatives that do not produce sufficient value.

That omission matters because the 2027 planning environment is already tight. Gartner projects average IT budget growth of 3.7% in 2027, while funding for agentic AI is expected to rise by an average of 31.8%. In the same research, 58% of CIOs reported growing pressure to produce AI-driven cost savings, while 51% expected AI to increase total cost of ownership over the technology life cycle.¹

These are survey-based planning signals, not a universal forecast for every organisation. The tension they expose is more important than the precise numbers: AI ambition is rising faster than the budgets, controls and workforce plans around it.

A second Gartner survey, covering 1,303 respondents at organisations with annual revenue of at least $50 million, found that only 22% had scaled AI across multiple business units or adopted an AI-first approach. Roughly 11% did not know what their function had spent on AI in 2025.²

The 2027 budget question is therefore not simply how much to spend on AI. It is whether the budget contains the operating system needed to turn AI spending into a controlled portfolio of work.

The software price is only the first invoice

When leaders discuss an AI budget, the conversation often begins with products: enterprise copilots, specialist applications, model access, agents, cloud capacity and external advisers. Those costs are visible because vendors can price them.

The surrounding work is less visible because it sits across existing functions. Data work may appear in an information programme. Integration may sit in IT. Legal review appears under compliance. Training moves to HR. Process redesign is absorbed by operational teams. Management time is rarely priced at all.

The result is a budget that can understate the real cost without containing a single incorrect number.

Open full-size graphic.

Deloitte's 2026 enterprise AI research illustrates the operating gap. More organisations reported confidence in their AI strategy, yet they felt less prepared in infrastructure, data, risk and talent. Only one in five reported a mature governance model for autonomous AI agents.³ An OECD survey of more than 2,000 small and medium-sized enterprises also found that strategic and secure integration remained uneven, with maintenance costs, time constraints, skills gaps and cybersecurity continuing to hinder implementation.⁴

The scale of those costs will differ sharply by organisation. A low-risk writing assistant used on public information is not equivalent to an agent that can access customer records, change an order or trigger a payment. An organisation with clean data, modern identity controls and mature technology-cost management starts from a different position from one with fragmented systems and unclear information ownership.

That is why a useful AI budget should not begin with a universal percentage. It should begin with a complete cost architecture.

Build the budget in three layers: Run, Control, Change

A practical way to structure the budget is to divide it into three layers.

Run AI covers the capability itself and the foundations needed to operate it: access, consumption, data, knowledge, integration and infrastructure.

Control AI covers the work needed to see and govern what is happening: security, evaluation, monitoring, auditability, risk management, cost allocation and value measurement.

Change the work covers the organisational consequences: workflow redesign, role changes, training, management capacity, adoption support and controlled experimentation.

This is not a recommended percentage split. It is a completeness test.

Every material AI proposal should show what it requires in each layer, even when the answer is zero or not applicable. A zero should be an explicit judgement with an owner and a reason, not a silent omission that becomes an emergency request later.

Open full-size graphic.

Seven lines a complete 2027 AI budget should show

1. Access and consumption

This is the line most organisations already recognise. It includes licences, model and API usage, agent execution, storage, data movement, support tiers, development environments and any premium charges for AI features embedded in existing software.

The important improvement is to budget for behaviour, not merely purchase price.

A seat-based licence may be predictable, but usage-based services can change quickly as adoption rises. An agent may call several models and systems to complete one task. A successful pilot can create more inference, logging, storage and support demand than the initial test revealed. A department may also buy a specialist tool while paying for overlapping AI capability inside an existing platform.

The proposal should therefore show at least three scenarios: expected use, high adoption and an agreed cost ceiling. It should also identify duplicate capability, minimum commitments, renewal points and exit costs.

Hard question: What happens to cost if adoption succeeds and usage doubles?

2. Data and knowledge readiness

AI systems do not become useful merely because an organisation owns data. The relevant information must be findable, current, permissioned, interpretable and suitable for the intended use.

That creates budget lines for information ownership, permissions clean-up, data quality, retrieval, knowledge architecture, content maintenance, retention rules and the evaluation of whether the system is using the right sources.

This is not always a large technical programme. It may begin with a narrow knowledge domain and a named content owner. The mistake is assuming the work is free because the documents already exist.

Poor information foundations create two costs. The first is direct rework, as teams clean, restructure and reconnect material after deployment. The second is decision risk, as users receive confident answers from outdated, duplicated or inappropriate sources.

Hard question: Which information must become usable, trusted and permissioned before the system can deliver value?

3. Integration and agent infrastructure

A standalone assistant can help an individual. A workflow changes when AI can interact with the systems where work is recorded and completed.

That step requires connectors, identity and access controls, orchestration, test environments, logging, observability, exception handling and operational support. It may also require a model gateway, additional hosting capacity or new controls over third-party components.

Integration is where a promising demonstration often meets organisational reality. The technical problem is not only whether the system can call another application. Leaders must also decide what it is allowed to do, which actions require human approval, how failures are detected and who supports the workflow when one component changes.

Budgeting for integration means funding the route into the workflow and the route back out when the system behaves unexpectedly.

Hard question: Who pays to connect AI to the workflow rather than merely place it beside the workflow?

4. Governance, security and evaluation

A policy document is not an operating control.

A production budget may need to cover system inventory, risk classification, approval workflows, privacy assessment, security testing, red teaming, performance evaluation, human oversight, output review, monitoring, audit logs, incident response and periodic reassessment.

NIST's Generative AI Profile treats trustworthiness as a life-cycle concern spanning design, development, use and evaluation.⁵ ISO/IEC 42001 similarly frames AI management as an organisational system of policies, objectives and continuing processes, rather than a one-off declaration.⁶

For organisations affected by the EU AI Act, the timetable can make this work particularly concrete. From 2 December 2027, specified high-risk AI systems in sensitive areas are due to face obligations including risk management, data quality, activity logging, documentation, human oversight, robustness, cybersecurity and accuracy.⁷ Applicability depends on jurisdiction, role and system classification, so this is a planning trigger rather than legal advice.

The budget should reflect the risk of the use case, not the novelty of the technology. A low-risk internal drafting tool may need proportionate controls. An agent acting on customer, employee, financial or regulated information may require substantially more assurance.

Hard question: What must be tested, recorded and monitored before this use can move into production?

5. People and workflow redesign

Training is necessary, but it is the most visible part of a broader organisational cost.

Deloitte found that insufficient worker skills were seen as the biggest barrier to integration, while education was the most common talent response. Its survey also found that 30% of organisations were redesigning key processes around AI and 34% reported deeper business reimagination, while 37% were still using AI with little or no change to existing processes.³

A credible budget should therefore include process mapping, role and responsibility changes, manager time, quality assurance, user support, incentives, communications and the temporary cost of running old and new methods together.

That transition cost matters. A business case may assume that AI removes effort immediately, while the organisation is actually paying for training, review, exception handling and double running. If the budget recognises only the future saving, the implementation team begins by appearing to miss its target.

Workflow redesign also determines whether the value is real. Giving people a faster drafting tool may save minutes. Redesigning the approval, handoff or case-resolution process can change the economics of the whole activity. The second result usually requires more organisational work than the first.

Hard question: What work will change, and who has been funded to redesign and absorb that change?

6. AI economics and measurement

AI cost management needs its own line because visibility does not appear automatically.

The budget may need to fund usage tagging, cost allocation, dashboards, baselines, benefit measurement, quality metrics, portfolio reviews and people who can translate technical consumption into business economics.

The Gartner survey finding that 11% of organisations did not know their functional AI spend is an obvious warning.² The more important point is that spend visibility alone is insufficient. Leaders need to connect cost to an outcome, an owner and a decision.

For a service workflow, the useful measure might be cost per correctly resolved case, not tokens. For software development, it might be cost per accepted change with quality and security held constant. For a knowledge assistant, it might combine time saved, answer quality, adoption and the cost of keeping the knowledge base current.

The FinOps Foundation reported in 2026 that 98% of surveyed FinOps practitioners were already managing AI spend, up from 31% two years earlier.⁸ That is a self-selected practitioner population, not a measure of all organisations. It is still a useful signal that AI economics is becoming part of a broader technology-value discipline rather than remaining an experimental expense.

Hard question: Can finance connect every material AI cost to an owner, an outcome and a stop-or-scale decision?

7. A controlled experimentation reserve

A 2027 budget also needs room for discovery. The answer is not a vague innovation fund.

A controlled experimentation reserve should have a defined purpose, capped consumption, approved environments, low-risk data rules, a named sponsor, an expiry date and a decision point. It should distinguish exploration from production so that a useful test does not quietly become an unsupported permanent service.

The evidence required to continue should match the use case. A simple internal productivity test may justify a short proof window. A regulated or integration-heavy workflow may need longer to establish safety and value. The discipline is not an arbitrary deadline. It is the requirement to decide what must be learned, what the test may cost and what happens when the evidence is weak.

A reserve also reduces shadow purchasing. Teams have a legitimate route to test a capability without hiding subscriptions or using unapproved data simply because the formal process cannot accommodate small experiments.

Hard question: What can be tested without quietly creating a permanent service or subscription?

How the missing budget appears

Illustrative scenario, not a reported case study.

A mid-sized professional-services organisation approves enterprise copilots for several hundred employees. The licence cost is clear, the productivity case is attractive and the initial deployment appears straightforward.

Within weeks, staff ask the system to use internal precedents and client material. That exposes inconsistent permissions, duplicated documents and uncertain content ownership. Teams want the assistant connected to the customer relationship system and matter-management tools. Security requests testing and stronger logging. Legal asks how confidential information is handled. Managers need guidance on review standards. The service desk receives questions it was not staffed to answer.

None of this necessarily means the purchase was wrong. It means the original budget funded access but not operation.

The new costs appear under IT, information management, legal, HR and operations. Finance sees an AI line that appears to be overrunning. IT argues that scope has expanded. Business leaders complain that value is arriving too slowly. Users continue to copy and paste between systems because integration was never funded.

A whole-cost budget would have staged the decision. It would have funded a narrow knowledge domain, permissions work, evaluation, support and measurement before expanding access. It might have bought fewer licences initially, but it would have created a more credible route to scale.

Allocate by outcome and maturity, not by vendor

Once the seven lines are visible, allocation becomes a portfolio decision rather than a shopping exercise.

Begin with the outcome. Is the initiative intended to improve productivity, service quality, revenue, risk control or organisational learning? Define a baseline before assigning a benefit.

Then classify the maturity of the work.

Explore funding supports bounded discovery: approved tools, a safe environment, a small data set, user research and a capped learning objective.

Prove funding supports evidence: workflow integration, evaluation, operational testing, a credible baseline and a decision on whether the use should proceed.

Operate and scale funding supports reliability: production controls, support, monitoring, training, knowledge maintenance, vendor management and continuing value review.

Each initiative should also have named ownership for the business outcome, technical operation, risk and financial case. Those roles may sit with different people. The mistake is allowing cost to disperse while accountability remains with a single central technology team.

Finally, set the reallocation rule before enthusiasm becomes sunk cost. Gartner's September survey described high performers as organisations that tracked return, treated AI as a portfolio and regularly reallocated or discontinued underperforming initiatives.² That does not prove the practice alone caused higher returns, but it is consistent with a basic budgeting discipline: investment should be able to move when the evidence changes.

The 2027 AI Budget Review: a meeting-ready checklist

Use this table before approving a material AI proposal. Every row should contain a number, an explicit zero or a justified not-applicable judgement.

On a narrow screen, each budget line is shown as a separate card.

Five approval rules

1. No software line without a named outcome owner.
2. No scaling decision without a usage-cost scenario and a quality baseline.
3. No production use without a proportionate control and monitoring budget.
4. No savings claim without transition, review and double-running costs.
5. No pilot without an expiry, evidence threshold and stop-or-scale decision.

Buy less blindly, fund more completely

A fixed AI percentage is attractive because it appears decisive. It is also likely to be false precision.

The right level of spending depends on the organisation's starting architecture, use cases, risk exposure, workforce, ambition and ability to measure value. Two organisations buying the same software can face very different operating costs.

The more useful 2027 discipline is to make the whole system visible. Fund the capability. Fund the controls. Fund the changes to work. Connect costs to outcomes and owners. Keep a legitimate route for experimentation, but preserve the ability to stop.

A complete budget may approve fewer tools in the first quarter. It may also give the tools that remain a far better chance of becoming usable workflows rather than permanent experiments.

The shopping list is the easiest part. The budget begins where it ends.