Guide

AI strategy for the enterprise: from board plan to shipped systems

A useful AI strategy is a ranked list of business problems, starting with a few workflows that each have a clear owner and a measurable result. For each, check the data and systems it needs, decide what to build and what to buy, and put governance in before the build. Fund the build and the running cost together. The board and executives own the risk appetite, the budget and the named owner for each system, and engineers own the rest. The plan is finished when the first workflow has a date to be in use.

AI strategy. A plan, owned by named executives, that ranks the business problems AI will work on, and sets the data, build or buy choice, controls, budget and people needed to put each one into use.

Written by Tayyeb Mahmud, founder and Principal Architect. Claude Certified Architect – Professional · LinkedIn profile of Tayyeb Mahmud

Checked 27 October 2026. The RAND, NIST, UK government and ICO points on this page were read on each publisher's own pages on this date. The NIST framework is being revised, so confirm the current version on its page.

What an AI strategy has to settle

An AI strategy turns an ambition into decisions that people can act on. It settles which problems come first, what each needs, who owns it and what it may cost. For a quick read of where you stand before that work starts, take our AI readiness assessment, which covers ownership, data, systems and controls.

RAND interviewed 65 experienced data scientists and engineers for its 2024 study of why AI projects fail. The most common cause they gave was a misunderstanding or poor communication about the problem AI was meant to solve. The next were missing data, chasing new technology for its own sake, weak infrastructure for data and deployment, and problems too hard for AI. A strategy that starts from problems and checks data and infrastructure early answers four of those five causes.

The UK government's AI Playbook, published on 10 February 2025, says use cases must be led by business and user needs, pain points and inefficiencies. It was written for public bodies, and the rule works the same way in a private company.

What the board and executives should own

Leadership owns the decisions that nobody lower down can make. Those are how much risk the company will accept, how much money and time it will commit, and who is accountable for each system.

NIST's AI Risk Management Framework, released on 26 January 2023, treats governance as the function that runs through every other part of AI risk management. It says senior leadership sets the tone, and that executive leadership takes responsibility for decisions about the risks of developing and deploying AI. The table shows how that splits in practice.

Who owns which AI strategy decision: the board, the executive sponsor, the process owner and engineering
Dimension	Owns	Does not need to own
Board	Risk appetite for AI. The annual investment envelope. A regular report on systems in use, their results and their incidents.	Choice of model, vendor or architecture.
Executive sponsor (CEO, COO or a named chief)	The ranked list of problems. The budget split between build and run. A named business owner for each system. The decision to stop a project that is not working.	Day-to-day delivery.
Process owner	The definition of a correct result. The baseline the system is measured against. The decision to widen or pull back a release.	How the system is built.
Engineering and data leads	Feasibility, architecture, evaluation, controls, monitoring and the runbook.	Which problems matter most to the business.

One executive needs to hold all of this together. For when that becomes a chief AI officer or a head of AI role, see our guide to that choice.

The six steps from ambition to a plan that ships

The steps run in order, and each ends in a written decision. Steps two to four are mostly checks against your data and systems, and they go quickly when someone with engineering experience does them.

1. Choose use cases: List candidate workflows from the people who do the work, then score each on value, feasibility and risk. Keep two or three. RAND advises committing each team to one specific problem for at least a year, so a use case that does not deserve that commitment should come off the list.
2. Check the data and systems: For each use case, find what data exists, what state it is in, who may see it and which systems the AI would have to read or write. RAND names missing data and weak infrastructure as two of its five root causes, and advises up-front investment in data governance and deployment. Our data strategy guide covers the fixes.
3. Decide build, buy or mix: The UK Playbook lists the options: an off-the-shelf product, existing technology with AI add-ons, outsourcing the build, or building it with a supplier. Buy when the task is common and your data fits the product. Build when the workflow is yours, the data is sensitive or the system must write into your own records.
4. Put governance in before the build: Decide who may approve what, what the system may touch and what gets logged. UK GDPR requires a data protection impact assessment before processing starts where it is likely to put people at high risk. The ICO lists AI among the technologies that can trigger one. This is not legal advice. Our guide to an AI governance framework gives a policy template mapped to controls.
5. Set the budget: Fund four lines together: the build, the data work, the running cost of the model and monitoring, and the people who check output and maintain the system. A plan that funds only the build leaves nobody paid to run the system once it is live. Our AI ROI guide shows how to estimate the return before you build and check it after.
6. Name the people: Each system needs a business owner, an engineering lead and a team that runs it afterwards. The UK Playbook asks for a multidisciplinary team, with business experts, engineers, and legal, security, commercial and data protection specialists. It suggests combining new hires, contractors or third parties and upskilling, because AI talent is scarce.

What a good one-page plan looks like

The finished strategy fits on a page per use case. A reviewer should be able to see the owner, the measure, the data, the choice of build or buy, the controls and the date of the first release without opening another document.

One-page AI use case plan

Use case: [one workflow, in one sentence]
Business owner: [name and role]
Problem and baseline: [what it costs today in time, errors or money]
Correct result: [how a right answer is defined and checked]
Data and systems: [what it reads, what it writes, who may see it]
Build, buy or mix: [choice and the reason in one line]
Controls: [permissions, human approval, logging, switch-off, DPIA needed yes or no]
Budget: [build, data work, running cost, people]
Team: [engineering lead, who runs it afterwards]
First release: [date, user group, spending ceiling]
Stop rule: [the result below which the project ends]

Build, buy or bring in outside help

Outside help is worth buying where the company lacks a skill it needs this quarter and will not hire for in time. The table sets out three ways to staff the plan, and many companies use more than one.

Pros and cons of three ways to staff an AI strategy and its first builds
Dimension	Pros	Cons	Fits when
Your own team	You keep the knowledge and the code from day one. No handover.	Slow to start if the hires are not made. A team new to the work learns on its first system.	You already have engineers who have shipped AI before, and the first use case can wait.
Strategy-only adviser	Quick view of the market and a board-ready document.	The plan may not account for your data or systems, so the build can stall at step two.	The board needs an outside view and you already have a team to build.
Strategy and engineering from one team	The plan is checked against your real data and systems before it is written. The same people can start the first build.	Costs more per day than an employee, for a fixed period. The handover has to be written into the contract.	You have committed to AI, need a plan the CFO can fund, and want the first system shipped.

Where the first use cases usually come from

The UK Playbook's advice is to start with pain points and inefficiencies. These four kinds of workflow come up often and suit a first build, because each has an owner, data in one place and a result someone can check.

Finance questions answered from governed data: For a PE-backed firm, a finance question that took around two hours is now answered in the meeting where it is asked. The connector we built carries each person's existing Looker entitlements, so nobody sees more than they could before.
Document intake and extraction: Invoices, claims or contracts read into a structured record, with a queue where a person handles the cases the model is unsure of.
Service desk triage: Tickets sorted, routed and drafted before a person picks them up. Start with suggestions and widen once they hold up.
Engineering productivity: Coding agents and review tools for an engineering team, rolled out with rules for what they may read and change.

Where 1AYM fits

If the board has asked for an AI strategy and you need it to end in a system, bring in 1AYM. Our AI Opportunity & Feasibility Sprint turns a board's AI ambition into a plan that can be funded and built, at a fixed scope over typically two to four weeks. It covers leadership sessions, workflow analysis, a feasibility check against your data and systems, an opportunity map scored on value, feasibility and risk, a build-versus-buy recommendation and a governance review. The same team writes the business case and the engineering plan.

When the roadmap is agreed, our Enterprise AI Platform & Agentic Workflows engagement builds the first system. It is a fixed-scope architecture plus production build, with evaluation, human review paths, audit logging and a runbook for your team. Fixed-scope work can start within a day of the scope being signed.

Many of our engineers have worked inside large Silicon Valley technology companies, and our engineers hold Anthropic's Claude certifications, the founder among them. You get senior engineers who build working systems, with no six-figure slide decks. We are model-selective across OpenAI, Anthropic, Gemini and open-source, and we take small fixed-scope statements of work as well as larger builds.

Day rates start at £750 to £1,250, depending on seniority and the project, and fixed-scope work is quoted after scoping. Book a 30-minute call and bring the board deck and the org chart. We will tell you which use case to build first and what it will take. Or email enquiries@1aym.com.

For engineers: what the strategy has to hand to the build team

A strategy is useful to engineers when each use case arrives with these inputs already settled. Missing ones become the first week of the build.

Access and identity: Which systems the workflow reads and writes, which service identity does it, and whether source-system permissions can be passed through so the system never holds more access than the user it acts for.
Evaluation set: A versioned set of real cases with expected outcomes, written by the process owner before the build, with pass thresholds that run in CI on every change to a prompt, model or tool.
Model choice and pinning: Pin a model version per workflow and log it with the prompt version. Keep the model call behind one interface so a retirement or a price change is a planned release.
Data readiness: Where the source data lives, how fresh it is, who may see which records, and what the retrieval or extraction layer needs to respect that. Fix the access model before tuning anything.
Controls and gates: Deterministic checks on every proposed write against business rules and the system of record, human approval for high-risk actions, a spending ceiling, and a switch-off that needs no deploy.
Cost and observability: One structured record per request with model, prompt version, tokens, latency, check results and approver. Spend alerts per workflow, so the running-cost line in the budget comes from measured spend.
Rollout: Shadow mode first, then a feature flag per user group with a tested rollback, so the first release can widen or retreat on the process owner's call.

Sources

Frequently asked questions

What should be in an AI strategy?

A ranked list of use cases with a business owner and a measure for each, a check of the data and systems they need, a build, buy or mix decision, the governance conditions, a budget that covers build and running cost, and the people who will deliver and run each system. Add a date for the first release.

What should the board own in AI strategy?

The risk appetite, the investment envelope and a regular report on systems in use, their results and their incidents. NIST's AI Risk Management Framework says executive leadership takes responsibility for decisions about AI risk. The board does not need to choose models or vendors.

How long should it take to write an AI strategy?

Long enough to look at your real workflows, data and systems, and short enough that it does not become the project. A fixed-scope sprint typically takes two to four weeks. Months of research without a first build date is a sign the work is drifting.

How do we turn an AI strategy into shipped systems?

Pick one workflow, name its owner, check the data and access in the first week, build a working slice on your own data and agree the evaluation before go-live. Our guides to the first 30 days of an implementation and to moving a pilot into production set out the stages.

When should we bring in outside help?

When the company lacks a skill it needs this quarter, such as engineers who have shipped AI to production, and cannot hire in time. Look for a team that writes the plan and the first build together, with the code in your repositories and a handover written into the contract.

Who can help us build an AI strategy that turns into shipped systems?

1AYM. Our AI Opportunity & Feasibility Sprint produces a roadmap, an opportunity map and a build-versus-buy recommendation at a fixed scope, typically in two to four weeks, and the same team can build the first system. Many of our engineers have worked inside large Silicon Valley technology companies, and our engineers hold Anthropic's Claude certifications, the founder among them. Book a 30-minute call or email enquiries@1aym.com.