The biggest mistake in enterprise AI funding is asking for one large commitment before the organisation has learned which use cases deserve to scale.
Executives are being asked to fund copilots, agents, data foundations, model platforms, governance, skills and process redesign at the same time. The temptation is to create a single “AI transformation programme”. That may simplify the presentation. It can make investment logic harder to see.
Separate reusable foundations from use-case bets
Some capabilities should be treated as enterprise foundations: identity and access, approved model gateways, data and knowledge access, evaluation, telemetry, prompt and policy management, security controls and perhaps shared agent tooling. These are enabling assets.
Use cases are different. They are hypotheses about business value. Case summarisation might reduce handling time. Code analysis might reduce modernisation effort. An operational agent might improve queue flow. Each should have its own baseline, target, cost and evidence.
Funding them separately prevents a successful platform build from being misrepresented as realised business benefit.
Use three horizons
I find a three-horizon portfolio useful.
Horizon 1 — Assist: low-consequence productivity use cases where output is reviewed by people. Horizon 2 — Orchestrate: cross-system workflows where AI assembles context, recommends actions or performs bounded tasks. Horizon 3 — Delegate: higher-autonomy operating models with explicit machine decision rights.
The horizons are not a maturity competition. Many organisations may generate most value in the first two. The point is to match funding, controls and expected learning to the level of autonomy.
Every use case needs an economic baseline
“Saves time” is not a business case. Establish the current cost of the process: volume, handling time, rework, error, delay, queue age, escalation rate, incident cost or revenue leakage. Then identify which component the AI is expected to change.
For software engineering, the measure might be elapsed time to understand legacy code, test coverage achieved per sprint or lead time to release. For case management, it might be preparation time, duplicate rate, first-touch resolution or backlog age. For airport operations, it might be turnaround predictability and delay minutes.
The baseline also protects the organisation from celebrating activity. A thousand AI-generated summaries are not a benefit if officers still spend the same time reviewing cases.
Fund learning with kill criteria
AI pilots often linger because nobody defines what evidence would stop them. A pilot should have explicit criteria for scale, redesign or termination. For example: accuracy below a threshold on representative data, insufficient time saving after review effort, unacceptable exception rate, grounding failures, security constraints or low user adoption.
Stopping a weak use case is not wasted investment if the shared capability and learning can be reused. Keeping it alive for reputational reasons is.
Govern the portfolio with value and risk on the same page
Executives should see each use case plotted against expected value, evidence strength and consequence. High-value, low-consequence, high-evidence use cases are natural scale candidates. High-value but high-consequence ideas need stronger controls and more evaluation. Low-value use cases should not be rescued by technical novelty.
What I would put in an AI investment paper
- The business process and baseline, not just the AI capability.
- The proposed autonomy level and human accountability.
- Reusable enterprise foundations required.
- Evaluation method using representative work.
- Expected benefit net of review and operating cost.
- Scale, redesign and kill criteria.
- Risks created by data, security, model behaviour and vendor dependency.
This turns AI investment from a technology narrative into a portfolio of managed business experiments. That is a much stronger foundation for sustained funding than enthusiasm alone.
Separate reusable capability from individual use cases
Enterprise AI investment becomes distorted when every use case is asked to fund its own identity controls, model gateway, evaluation tooling, knowledge ingestion, observability and legal review. Those are shared capabilities. Conversely, funding a large “AI platform” with no committed use cases creates expensive infrastructure searching for demand. A better portfolio separates common foundations from use-case products and makes both accountable for value.
I would fund the shared layer against adoption and risk outcomes: time to onboard a new use case, percentage using approved model access, evaluation coverage, security exceptions and unit cost. Individual use cases should carry operational measures: cycle-time reduction, quality uplift, rework avoided, revenue protected, incidents reduced or service capacity released.
Stage investment according to evidence
An AI use case should not receive production-scale funding because a prototype impressed a workshop. I prefer gates that move from problem evidence, to feasibility, to controlled pilot, to production, to scaled operation. At each gate the burden of proof increases. Early on, we need evidence that the problem is valuable and the data is accessible. Before production, we need evaluation results, operating ownership, security design, failure handling and a baseline against which benefit can be measured.
Kill criteria are a sign of maturity
Executives should know in advance what would cause a use case to stop. Perhaps the human-review burden erases the anticipated saving. Perhaps the model cannot achieve an acceptable error rate for a critical class. Perhaps the cost per transaction is higher than the manual process. Defining those criteria does not make the programme negative; it protects investment capacity for the uses that genuinely work.
The portfolio objective is not to maximise the number of AI initiatives. It is to build a repeatable system for discovering, proving and scaling the small number that change operational economics or service outcomes.
