Data and AI Strategy

The bank’s AI strategy had started with an ideas campaign. Sixty use cases came in from the business units, a committee ranked them, and fourteen pilots were funded. Eighteen months later none was in production. The pattern in the fourteen was the same: each pilot team had spent its first four months finding data, negotiating access, and cleaning what it got, usually as a one-off extract; each then built something that worked on that extract; and each then discovered that there was no way to receive the same data continuously, that the people whose work the pilot was meant to change had never been asked, or that nobody had said what result would justify taking it further. The document-classification pilot was the clearest case. It classified incoming correspondence with an accuracy everyone admired, on a sample pulled once from the mail system by hand, and the mail system had no supported route for repeatable delivery. It was extended twice, because ending it would have meant admitting that the thing it needed had never been funded.

The bank is fictional. Its problem illustrates a strategy that funds demonstrations without assigning responsibility for what comes after them. A data and AI strategy connects business decisions to usable data, suitable analytical capabilities, and evidence for the next investment. Shared foundations need owners and resources, but central funding is one option: domains can share costs, or a first consumer can fund something designed for later reuse. A bounded experiment and the minimum foundation it needs can advance together.

What a data and AI strategy decides

Forty-Seven Initiatives and No Strategy describes a strategy kernel: a diagnosis, a guiding policy, and coherent action. For data and AI, the diagnosis starts with decisions that better information might improve, as in Predicting the Wrong Thing Well. The UK National Data Strategy groups its national priorities around foundations, skills, availability, and responsible use. Those categories are useful prompts for an organization, not a requirement to finish every capability before testing an idea.

The UK government Data Maturity Assessment organizes evidence across ten topics and six themes rather than reducing an organization to one score. The bank should use data and AI maturity to investigate the specific capabilities its candidates depend on. A missing mail interface suggests a delivery gap; it does not establish low sharing culture, high systems maturity, or a particular skills score. Those judgments require evidence within the assessed scope.

Fund the foundations the next step needs

Assign owners and resources to the trust, sharing, access, and permission needed for the proposed activity. A lawful offline sample may support feasibility work while repeatable delivery is investigated. Live processing requires a supported supply path and controls appropriate to that use. In the maturity framework, Making data available is an assessment row under Topic 1, Engaging with others; a technical interface gap alone does not establish its cultural rating.

Foundation capability	Question it answers for a use case	What happens without it	Evidence it exists
Findability	Can the team find and understand the relevant data?	Repeated discovery and misunderstood definitions	A data catalog combining harvested technical metadata with maintained ownership, business meaning, and use restrictions
Trust	Is quality adequate for the decision and measured at the relevant boundary?	A model can faithfully learn from misleading inputs	A data contract, measured quality, and reconciliation where needed; see Passing Tests, Wrong Numbers
Access	Can authorized users obtain an appropriate version in time?	A feasible idea may have no workable access route	classification, decision rights, and measured request-to-access time; compare controlled grants, APIs, and versioned extracts. See Four Hours on the Dashboard
Continuity	What supply does this stage need?	A successful offline evaluation may not transfer to live operation	For recurring operation, supported data products with delivery and recovery commitments; for offline work, a suitable reproducible snapshot and an explicit integration experiment
Permission	Is this purpose and processing permitted?	Technical access can exceed permitted use	AI governance and an inventory recording purpose, applicable legal basis or use rights, restrictions, and consent scope where consent is relied on

Who Decides What explains why these responsibilities need decision rights as well as documentation. The UK AI Playbook allows support structures to mature with early projects; the controls necessary for safe, permitted work still have to exist at the relevant stage. In this bank, a central budget funds a reusable mail connection while the classifier team tests a bounded sample. That funding arrangement is a choice for this dependency, not a universal rule.

Use-case value against data readiness

For each use case, state a value hypothesis, examine feasibility, and define readiness for the proposed next step. A discovery study, offline evaluation, limited live trial, and broad rollout require different evidence. The table sorts candidates for investigation. It does not authorize investment: mandatory obligations and safety gates, total costs, uncertainty, operating capacity, learning value, and competing uses of resources still matter.

Estimated value	Data suitable for the proposed step	Data not yet suitable for the proposed step
High	Investigate a bounded next step; verify controls, capacity, costs, and alternatives before approval	Price the gap and test whether closing it is worthwhile; a data-access or integration experiment may itself be the next step
Low	Compare low-cost learning, mandatory obligations, and opportunity cost; readiness alone is not a reason to proceed	Usually defer discretionary work unless obligations or learning justify it; record conditions for reconsideration

The bank initially classifies four of its sixty candidates as high estimated value with data suitable for their proposed test, nineteen as high value with unresolved data gaps, and thirty-seven as lower estimated value. These are provisional groups. A classifier can use a lawful snapshot to test classification feasibility while another experiment tests repeatable delivery. If outcomes are not already recorded, specify how labels or future outcomes will be collected and evaluated; do not automatically rule out a model. A rules-based alternative may still be better. Risk review also separates a prohibited purpose from a restricted implementation: human-supported processing may be permissible where autonomous action is not. The UK AI Playbook offers public-sector guidance, not an identical legal ban for every organization. Evaluate jurisdiction, purpose, affected people, and permitted actions as described in The Invoice Gave the Instructions.

Which capabilities, in what order

The required capabilities follow the questions and operating risks. What Kind of Question Is It? distinguishes analytical tasks; even descriptive work needs appropriate skills, definitions, and controls. Model-based work may need versioning and promotion, as in Nobody Could Rebuild Version 14, and ongoing ownership, as in The Model Nobody Owned. Language-model services may benefit from the shared controls in Every Team Had Its Own Key. Estimate evaluation effort explicitly: the specialist judgments, datasets, and repeated tests described in The Judge Preferred Longer Answers can be substantial. Secure the minimum capabilities needed for the next safe test and budget their development alongside it.

Put these responsibilities on a business capability map. An architecture principle can require common access rules, discoverability, and evaluation records without demanding one catalog implementation or one evaluation harness for every domain. Tools may differ while meeting shared contracts and controls. Give active capabilities an operating owner and resources; when their consumers disappear or replacements take over, plan a safe retirement rather than assuming permanent operation.

Build, buy, or configure

technology selection begins with requirements and viable alternatives. Purchase, configuration, integration, and custom development can be combined. Compare expected benefit, fit, risks, operating capacity, total cost of ownership, and exit cost; TCO supplies the cost side, not the whole decision. In this fictional bank, the team compares an existing connector, scheduled controlled exports, a vendor extension, and a custom adapter. It selects the adapter only after finding that the connector lacks required audit fields, exports miss the target delivery interval, and the vendor extension cannot meet the agreed timetable. Those are case assumptions to verify through a small integration test, not proof that no market product could work.

Specify how the work will use the result

Map the existing decisions, handoffs, and responsibilities before deciding what must change. A classifier may reduce routing effort within the existing approval process; another use case may need a substantial redesign. Estimate the necessary integration, training, and operating costs for that scope and preserve required controls. human oversight needs authority, time, and evidence to work. An ignored prediction can still consume review time and money even if the decision stays the same. Measure the resulting service outcomes as in Twenty-Three of Twenty-Five Shipped, rather than treating either deployment or a large redesign as proof of value.

When a pilot scales, and when it stops

Write the decision the pilot will inform, its scope, evidence plan, budget, and review date before starting. The UK Service Manual describes alpha as a short period of testing ideas and assumptions with minimal prototypes; its typical duration is not a universal deadline for every experiment. Ending alpha can lead to beta, another justified test, or stopping. Approval for a limited next phase is not approval for unrestricted production.

Choose important assumptions by comparing potential harm or loss if wrong, uncertainty, dependencies, test cost, and information value. There may be several, and model performance can be one of them. A riskiest assumption is a priority for investigation, not necessarily the single least certain belief or something outside the model. Define exit criteria around the decision those tests can support. For the bank, both delivery feasibility and error costs need evidence; failure of one design can justify stopping that attempt while leaving another design open.

Exit	Condition, set before the pilot starts	What it commits the organization to	Document classifier
Advance within an approved scope	Evidence meets the next stage’s value, safety, operational, and permission requirements	Approve resources and controls for that scope, with rollout and rollback criteria	A regional trial requires representative documents, risk-specific error checks, review audits, capacity and recovery tests; handling time and override rate are supporting signals
Stop or pause the current attempt	Negative evidence, prohibitive constraints, or learning value too low for further cost	Record the reason and any conditions for reconsideration	A delivery design proves unaffordable, or the owner cannot justify changing the process; this need not permanently discard the use case
Run a justified further test	A specific decision-relevant gap remains and another bounded test is worth its cost	Specify method, budget, owner, and review date; retain the hypothesis when a larger sample is the appropriate test	Collect more representative labels, observe delayed outcomes, or test an alternative delivery design

A missing measurement is an evidence gap, not evidence of failure and not an automatic claim on another round of funding. A small or imprecise observed change may reflect inadequate sample size, delayed outcomes, or a measurement defect. Examine those explanations and the value of further learning before deciding. readiness concerns the defined next step; stopping the current attempt, pausing it, and abandoning the underlying need are different decisions.

Judging a data and AI strategy

Report cohorts and clocks as carefully as outcomes. For production conversion, define whether the denominator is unique use cases or pilot rounds, the approval window, and follow-up duration; report stopped, pending, and not-yet-mature cases. For on-time exit decisions, use rounds whose agreed review dates have arrived, and report overdue decisions separately from rounds not yet due. Pair these measures with spending, useful learning, service outcomes, and control failures. More production conversions or changed decisions alone do not establish greater value.

What a reviewer should ask

1. Which business decisions would change with data or models the organization lacks, and what is each worth against current practice?
2. What evidence supports each relevant maturity assessment, within which topic, theme, and organizational scope?
3. For each foundation capability, who owns it, who funds it, and what is its measured latency from request to delivery?
4. What supports the estimated value and stage-specific readiness, and how do obligations, costs, capacity, risk, and alternatives affect approval?
5. Which use cases were declined, and for which of the stated reasons?
6. Which shared capabilities are funded, in what order, and who operates each?
7. Which purchased, configured, and custom components were compared, against what requirements, benefits, risks, operating capacity, total costs, and exit costs?
8. For each use case, what changes in the work, who now decides what, and is that funded?
9. Which assumptions were prioritized, what evidence will resolve the next decision, and when is a further test worth its cost?

The bank chooses central funding for shared discovery, access, delivery, and evaluation responsibilities, developing the minimum needed alongside selected experiments. It investigates the four initially ready candidates and prices the gaps in the nineteen others before approving work. The classifier tests a lawful sample and a supported delivery route separately. A regional trial then checks representative document types, harmful errors, reviewer performance, permissions, processing load, and recovery. Only one process has authority to route each letter; the other produces shadow results. Expansion requires documented approval for the wider population and explicit transition and rollback criteria, not just faster handling or an expected override rate. For illustration, the bank compares two approval cohorts of fourteen and nine unique use cases, each followed for eighteen months; repeat rounds count under their original use case. The first has zero in production and fourteen still pending, while the second has five in production, two stopped, and two pending. The 0/14 and 5/9 figures describe those cohorts, not a causal estimate of the strategy’s effect. The board also reviews costs, useful stops, overdue decisions, measured service outcomes, and control performance.

References:

• UK Government Digital Service, Artificial Intelligence Playbook for the UK Government, 2025 (Open Government Licence v3.0).
• UK Government Digital Service, Data Maturity Assessment for Government: Framework, 2026 edition (Open Government Licence v3.0).
• GOV.UK Service Manual, How the alpha phase works (Open Government Licence v3.0).
• GOV.UK Service Manual, How the beta phase works (Open Government Licence v3.0).
• UK Department for Digital, Culture, Media and Sport, National Data Strategy, 2020 (Open Government Licence v3.0).