The first sign that an AI strategy will fail is often visible before a model is selected. The steering group can name several tools and dozens of ideas, but nobody can name the operational decision that should improve, the person who owns it or the evidence that would justify changing the process.
An AI strategy is a set of choices about work. It says where AI may create value, which uses are outside appetite, what must be proved, how risks will be controlled and who will operate the result. A technology catalogue, training programme or model policy can support those choices; none is a substitute for them.
Begin with work that an owner can change
“Use generative AI in customer service” is a theme. “Classify and route one defined category of customer request, while preserving a human escalation path” is a candidate use case. The second statement exposes a trigger, an output, an exception and a process owner. It can be observed before and after a change.
This work-first approach is consistent with the Government Digital Service: Artificial Intelligence Playbook for the UK Government, which advises teams to define the goal and user need before deciding whether AI is the right tool. The principle travels well beyond government: a clear need makes it possible to compare AI with rules, search, conventional automation or a process change.
A credible first use case has five properties:
- A named workflow: the trigger, inputs, decisions, outputs and exceptions can be mapped.
- An accountable owner: one person has authority to change the process and accept the operational result.
- An observable baseline: current quality, delay, handling, rework or risk can be assessed without inventing precision.
- A bounded release: the first test can be isolated from a wider transformation programme.
- A reversible decision: the organisation can scale, revise or stop without becoming dependent on an unproved system.
Ideas without an owner should normally leave the active portfolio. Ideas without a baseline may remain in discovery, but they are not ready for an investment case. Strategy becomes stronger when it removes work as well as adding it.
Make six choices explicit
1. Value
State the outcome in operational language. The aim may be to shorten a cycle, improve the consistency of a review, increase service capacity or make an information-heavy task easier to complete. Separate the outcome from the mechanism. “Deploy an assistant” describes a mechanism; “help an adviser find the current approved policy and its source during a call” describes useful work.
Value also needs a counterfactual. Compare the proposed AI route with improving the source data, simplifying the policy, changing a queue or adding deterministic automation. If a less uncertain intervention can achieve the outcome, it may be the better strategic choice.
2. Intended use and boundaries
Classify the intended use, not the brand of model. The same foundation model could support low-consequence drafting or influence a decision with material effects on a person. Market, sector, data and degree of automation change the control requirements. The European Commission: AI Act overview explains the EU’s use-based risk structure, including transparency and high-risk obligations. UK organisations serving European users still need to establish whether a proposed role falls within that framework.
Write the prohibited and deferred uses beside the chosen ones. Examples might include no autonomous customer eligibility decisions, no production use of unapproved personal data and no external action without confirmation. Boundaries turn a broad ambition into an investable programme.
3. Evidence
Define how the organisation will know that the system is useful and controlled before building it. A polished demonstration is not evidence. Tests should reflect normal cases, difficult cases, missing information, unsafe requests and the points at which a person must intervene.
The NIST: AI Risk Management Framework treats risk management as activity across design, development, use and evaluation. Its core functions—Govern, Map, Measure and Manage—are described in more detail by the NIST AI Resource Center: AI RMF Core. For strategy, the practical implication is simple: measurement is part of the design, not a test added after procurement.
Agree decision thresholds in advance. These may include task quality, supported-answer rate, exception volume, human review effort, security findings and operating cost. Avoid compressing unlike measures into a single score that hides a serious failure.
4. Control
Controls should follow consequence. A drafting aid with mandatory review needs a different control set from a system that ranks cases or initiates actions. Consider lawful use of data, access, transparency, fairness, security, record keeping, human authority and incident response.
The Information Commissioner’s Office: accountability and governance implications of AI makes senior management accountability explicit and treats a data protection impact assessment as a live way to identify and control risks where personal data is involved. A DPIA is not the whole governance model, but it can expose unclear purposes, controller relationships and residual risks early enough to change the plan.
5. Architecture and sourcing
Decide what should be bought, configured, integrated or built only after the intended use is clear. Many use cases need an existing model inside a controlled workflow, with identity, retrieval, business rules, validation, logging and escalation around it. Model capability is one component of that service.
Architecture choices should follow data sensitivity, latency, auditability, portability, expected volume and internal capability. Procurement should capture evaluation rights, data handling, model-change notification, service continuity and exit. A favourable pilot price is not a strategy if the organisation cannot later test, operate or replace the service.
6. Operating ownership
Name responsibility across the lifecycle: process owner, technical owner, data steward, risk and compliance input, evaluation owner, incident lead, user-training owner and vendor owner. The roles can sit within existing governance, but the decisions cannot be ownerless.
ISO: ISO/IEC 42001 AI management systems provides a management-system frame for establishing, implementing, maintaining and continually improving how an organisation handles AI. Certification is not required to borrow the useful discipline: defined responsibilities, documented objectives, controlled change and review over time.
Manage a portfolio, not an ideas list
Rank candidate work across value, feasibility, exposure and organisational readiness. Do not pretend that these dimensions are perfectly measurable. A short evidence note is more useful than a decimal score: what problem is observed, what data is available, what could go wrong, who owns the workflow and what must be learned next?
A balanced portfolio usually contains different learning goals. One item may test whether the data supports the use; another whether users can supervise the output; another whether integration economics are credible. Fund the next uncertainty, not an assumed production build.
Dependencies should be visible. If several ideas rely on the same identity, knowledge or evaluation capability, invest in that shared foundation deliberately. If an idea requires a company-wide data programme before any evidence can be gathered, reduce the scope or place it behind more tractable work.
Use decision gates that can stop work
- Frame: confirm the workflow, owner, affected people, baseline, constraints and plausible alternatives.
- Assess: establish data permission and quality, applicable obligations, architecture options, control needs and the key uncertainty.
- Prove: test a bounded prototype against representative cases and agreed measures, with important actions disabled or supervised.
- Pilot: observe the system with real users and realistic operating conditions; measure exceptions, workarounds and control burden.
- Scale, revise or stop: make a documented decision and fund ownership, monitoring and recovery alongside the technical service.
The right answer is to stop when the use has no accountable owner, the necessary data cannot be used lawfully, material harm cannot be reduced, performance cannot be evaluated, or the control burden removes the expected value. Stopping is a strategy outcome, not a failed delivery ritual.
What the board should be able to see
A board-ready AI strategy does not need to be long. It needs a small prioritised portfolio, explicit boundaries, an account of applicable risk, investment ranges, architecture principles, accountable owners and decision gates. It should distinguish confirmed facts from assumptions and identify the evidence expected from the next period.
It should also describe the operating consequences. Which teams will review outputs? Which policy or control changes? Who accepts incidents? What capability must remain in-house? A strategy survives contact with operations when the people who run the work can explain what changes on Monday morning, and control functions can see how the organisation will know whether it remains acceptable.
No framework can make a weak use case valuable or remove uncertainty from an emerging technology. The purpose of strategy is to make the uncertainty governable, place small informed bets and preserve the ability to change direction.
Further reading: NIST: AI Risk Management Framework; Information Commissioner’s Office: guidance on AI and data protection; European Commission: AI Act overview; ISO: ISO/IEC 42001 AI management systems.
