Enterprise AI Strategy: Five Decisions, in the Right Order

An enterprise AI strategy decides whether a company’s AI earns its keep. Deloitte’s 2026 State of AI in the Enterprise survey found one in five companies has mature governance for AI that acts on its own. That gap is a sequencing problem: a stalled pilot can run on a capable model and still go nowhere.

The order is the strategy

Each of the five decisions is worth little unless the ones before it were made first. Order is the thing that gets dropped when a pilot is scoped against a deadline instead of against a problem.

1. Define the business problem before the tool

A team that starts from “we should use AI for X” can end with a demo and nothing on the bottom line. The problem needs a baseline up front: cost per ticket, minutes per claim, conversion on one flow. Without it, nothing can later prove the pilot did anything.

Track spend the same way: as cost per query or per completed task, not as one lump AI budget line. A support bot and a tool that writes code can cost very different amounts per job done, even on the same underlying model. If spend concentrates in a few expensive interactions, one budget line hides that until the invoice arrives.

2. Assess data and technical readiness

The second decision is whether the data supports the use case — checked before the build starts. That means an honest look at the exact system the model needs to reach: how complete its data is, how current, and who may see it. A model pointed at old, duplicated, partly blacked-out support tickets still answers fluently and confidently. It’s wrong, at the same speed as a model pointed at clean data.

3. Choose an operating model

The third decision is organisational: how centralised AI ownership should be. Full centralisation gives consistency and one point of accountability, at the cost of speed, as business units queue. Federation, where each business unit runs its own work, moves fast, at the cost of duplicated infrastructure, inconsistent governance and no shared learning between teams. Hub-and-spoke sits between the two: a central hub owns shared infrastructure and governance standards, while the business units, the spokes, run their own use cases against those standards. It aims for consistency and closeness to the problem at once, risking a new queue at the hub.

4. Build governance before scale, not after an incident

Governance often gets added only after something goes wrong, and it’s cheaper to build it before scale than to reconstruct an audit trail after a regulator or a customer asks. Three frameworks are worth building against rather than inventing your own: a risk-management framework, a certifiable standard and a binding law.

The first is the framework from the National Institute of Standards and Technology (NIST). It’s voluntary, written for organisations of any size in any sector, and built on four functions: govern, map, measure and manage. The second comes from the International Organization for Standardization (ISO) and International Electrotechnical Commission (IEC): their joint standard, ISO/IEC 42001, sets out policies and processes for how AI gets built and run. The third is the EU AI Act, the one binding, risk-tiered rule here — a narrow set of uses banned outright, and obligations for the ones judged high-risk. It has been amended since it was passed, so check the current dates before you plan compliance around them.

For engineersThe EU AI Act's high-risk deadlines have moved since the law was passed; these are the current ones.

As of 26 September 2026: prohibited-practice rules and the general obligations for general-purpose AI models are already in force, from February and August 2025. Most of the Act’s remaining rules, including enforcement and transparency duties, have applied since 2 August 2026. A later amendment, the Digital Omnibus on AI, pushed the high-risk rules back: standalone high-risk systems under Annex III now have until 2 December 2027, and high-risk AI embedded in already-regulated products until 2 August 2028. Source: the European Commission’s AI Act timeline page.

5. Instrument for monitoring from day one

The fifth decision is the easiest to cut under deadline pressure: monitoring, built in before launch. Drift detection tracks whether live inputs, or the model’s own answers, have moved away from what was tested. An evaluation harness is a fixed set of test cases that checks whether a model update made answers worse, run on a schedule rather than only at launch. Red-teaming means deliberately trying to break a system’s safeguards on an ongoing basis. And guardrails — filters, limits and escalation paths outside the model itself — turn one bad answer into a contained event before it reaches a customer.

For engineersDeloitte's governance finding comes from a large, multi-country survey of senior leaders, not from our own measurement.

Deloitte surveyed 3,235 senior leaders — board and C-suite members, plus president, vice president and director-level executives, split evenly between IT and line-of-business roles — across 24 countries, in August and September 2025. Its own words: “only one in five companies has a mature model for governance of autonomous AI agents.” The full report puts it at 21%.

A running programme can still go back for the step it skipped

The decision in front of you is which step, if any, your programme skipped, and whether to go back for it now, while it’s cheap, or after a regulator asks.

Updated 26 Sep 2026: figures we couldn’t source were removed, and claims that went beyond their sources were fixed.