The UK government's £600m-plus AI package, published on 24 October 2026, brings security, domestic capability and adoption into the same investment programme. For boards, it raises a practical question: how much control does the organisation retain as AI becomes embedded in its operations? The government's announcement provides the policy context.
Days earlier, the Council for Science and Technology warned that Britain could become a "high-value AI customer" without deliberate investment in domestic capability, according to Reuters' reporting on the advisers' recommendations.
There is a useful parallel for businesses. An organisation can buy sophisticated AI services while gradually losing the ability to understand, challenge or replace the systems supporting its decisions. That dependency may remain invisible while services perform well. It becomes expensive when a supplier changes its terms, a model behaves differently, or an operational incident forces the business to work without it.
The board's task is to establish where those dependencies matter, what evidence supports continued adoption, and who remains accountable when automated work goes wrong.
What the package funds
The government's funding breakdown includes:
- £165m for a National AI Biosecurity Initiative.
- An additional £120m for the AI Security Institute.
- £60m for a National Cyber Shield and £70m for a National Exposure and Real-Time Vulnerability Centre.
- An additional £60m each for the Sovereign AI Fund and its R&D Procurement Scheme.
- £18m for a chip design academy, £15m for an AI Challenge Prize, £23m for economic research and £30m for local AI partnerships.
The announcement also covers cyber and AI skills development in Manchester. Up to £200m in private model credits for biosecurity is separate from public funding.
Reuters' coverage of the package describes its emphasis on defending against health and security threats.
The earlier AI Opportunities Action Plan: One Year On, published in January, had already connected adoption with investment in computing infrastructure, skills and assurance.
For an individual business, the implication is a planning priority: assess the resilience of AI adoption alongside its expected productivity gains. Public investment provides context; operational confidence still requires evidence from the organisation's own systems.
Make sovereignty a question of operational control
"AI sovereignty" is too broad to serve as a procurement requirement on its own. Boards need to translate it into decisions about particular services.
A company using AI to help draft internal presentations can tolerate different dependencies from a company using an AI agent to change customer accounts or coordinate field operations. The required controls should follow the consequences of failure.
For each important use case, directors should ask:
- Which business activity depends on this system, and how long could it operate without it?
- Where does sensitive information travel, including through supporting services?
- Which suppliers can change access, pricing or functionality?
- Can the organisation evaluate the system independently?
- Who can restrict or stop it, and what happens next?
These questions turn an abstract ambition into an assessment that engineering, procurement and operations can act on.
Domestic ownership can be relevant to that assessment. It does not, by itself, establish service continuity or technical independence. A UK supplier might rely on an overseas model provider. A self-hosted model might depend on specialist hardware and a small engineering team. Each arrangement needs its own examination.
The objective is to choose dependencies consciously and retain enough capability to manage them.
Follow critical data through the whole service
A board paper stating that "our data is hosted in the UK" leaves several operational questions unanswered.
Consider a hypothetical assistant that searches internal documents and drafts responses for customer service staff. Its data flow might include document ingestion, a search index, model inference, conversation history, monitoring and support access. The primary document store is only one part of that service.
The board should commission a map that follows information through the complete workflow. It should distinguish original records from derived information, including embeddings, extracted text and generated summaries. Logs and diagnostic records deserve attention because they may contain copies of information submitted during normal use.
For each component, establish the processing location, retention arrangements, access permissions and relevant supplier commitments. Record uncertainty explicitly. An undocumented assumption about a subcontractor is a gap to resolve before extending the system's access.
This work belongs within the organisation's broader data engineering and architecture. Adding AI to fragmented information flows makes ownership and access harder to understand unless those foundations are addressed.
Directors do not need a diagram of every API call. They need an intelligible account of which information crosses organisational boundaries and the evidence supporting that account.
A useful board question is: Can we trace a sensitive record from its source through retrieval, inference, logging and deletion, and identify who controls each stage?
If the answer is incomplete, the immediate response may be to narrow the data available to the system while the gaps are investigated.
Identify dependencies below the supplier contract
A list of contracted vendors can understate concentration risk.
Two AI applications bought from different companies may use the same underlying model service. They may also share a cloud platform, identity provider or integration partner. Switching between the applications would offer little protection against a failure in that shared dependency.
The board should ask management to map dependencies around critical business activities. Start with the process the business needs to keep running, then identify the services required to deliver it.
For a customer operations workflow, that could include identity, document retrieval, model access and the system where approved changes are recorded. The assessment should show which failures would stop work and which would merely reduce convenience.
Supplier reviews should then cover practical operating questions:
- What notice is provided before a model or API is retired?
- Can the business constrain changes or test them before production use?
- What access is available during an investigation?
- Which records and configuration can be exported?
- What would replacement require in engineering time and staff training?
Contractual rights are useful when the organisation can exercise them. An export clause provides limited continuity if nobody has tested the export or can rebuild the service from it.
This is a reasonable place to use cloud consultancy to examine architecture and commercial commitments together. The resulting recommendation might accept a concentrated dependency because its benefits justify the exposure. That decision should include a recovery plan, a budget and an owner.
Test the deployed workflow
On 12 October, Reuters reported that the AI Security Institute had access to the latest advanced models for safety evaluation. That work provides national context for model assessment.
A board still needs evidence about the system its organisation has actually deployed. Local documents, permissions, prompts and connected tools determine how a model is used and what it can affect.
Take a hypothetical assistant that drafts maintenance recommendations from equipment records. Its evaluation should include incomplete histories, contradictory instructions, unfamiliar terminology and records containing misleading content. If the assistant can create work orders, testing must also examine whether it acts within the correct permissions and handles failed or repeated requests safely.
The test programme should reflect the business's failure modes. Useful areas include:
- Whether outputs are sufficiently accurate for the intended task.
- Whether users receive information they are authorised to see.
- Whether untrusted content can redirect the workflow.
- Whether connected actions remain within approved limits.
- Whether the service behaves acceptably during timeouts, outages and recovery.
A broad accuracy percentage can hide an unacceptable failure in a sensitive category. Management should report results by consequence: a formatting error and an unauthorised account change need different treatment.
Testing should also follow material changes. Replacing a model, altering retrieval rules or granting a new tool permission may change behaviour even when the user interface looks identical.
For directors, the strongest assurance is a clear release decision: which scenarios were tested, what failed, who accepted the remaining exposure, and what would trigger a pause.
Give AI agents narrowly defined authority
An assistant that proposes an action and an agent that performs it create different operational exposures.
Suppose an AI tool helps security staff investigate suspicious activity. With read access, it can assemble evidence for an analyst. With broader privileges, it might disable accounts or change network rules. Those actions can affect the availability of the business itself.
Boards should require explicit authority limits for consequential automation. The relevant questions are concrete: which resources can the system change, how many changes can it make, and which actions require approval?
A sensible deployment might begin with observation and recommendations. Limited execution could follow once the organisation has evidence that the system performs acceptably within a defined scope. Expansion should depend on demonstrated behaviour and recovery capability.
The technical boundaries should include permissions enforced outside the model. Instructions in a prompt cannot substitute for access controls, transaction limits or approval mechanisms.
Stopping the agent also needs an operational design. Someone must know how to suspend its credentials, identify actions already taken and decide which changes require reversal. That capability should be tested under realistic conditions.
These controls fit within an established cybersecurity programme, with AI-specific failure scenarios added to incident response and recovery exercises.
Preserve accountability as adoption accelerates
Faster experimentation can leave ownership scattered across departments. IT may own the platform, security may review access, and a business team may rely on the output. When the service makes a consequential mistake, each group can have a different understanding of its responsibilities.
Before scaling an important use case, assign a business owner with responsibility for its purpose, acceptable failure rate and operational consequences. The technology owner should be responsible for implementation and service operation. Security, data and assurance specialists should have defined roles in reviewing the evidence.
The business owner needs authority as well as a name in a register. They must be able to fund controls, change the workflow or suspend use when performance becomes unacceptable.
Human review requires the same specificity. A reviewer needs enough context, time and expertise to challenge an output. An approval button offers weak protection if staff cannot inspect the evidence or are measured solely on speed.
Boards should ask management to demonstrate the review process using difficult cases. Can the reviewer identify the problem? Can they reject the proposed action? Does the system preserve enough evidence to explain what happened?
Skills investment should support those tasks. Procurement teams need to understand model dependencies and retirement terms. Operations staff need to rehearse degraded service. Engineers need experience evaluating permissions and unintended actions. Executives need sufficient understanding to question assurance claims.
Course completion figures reveal little about whether the organisation can perform these responsibilities.
Fund recovery and supplier exit deliberately
Replacing an AI provider can involve more than changing an endpoint. The application may depend on particular tool formats, prompts, retrieval behaviour or output structures. A replacement can connect successfully while performing poorly on the work that matters.
Boards should therefore distinguish contractual exit from operational exit. The first concerns rights and obligations. The second concerns whether the business can keep functioning.
For critical services, commission a proportionate replacement exercise. Export the necessary records and configuration, run representative tasks through an alternative, and measure the differences. Include the engineering effort, evaluation work and staff retraining in the cost.
The alternative may be a simpler service. During an outage, a search interface with source documents could be sufficient to keep a team working without generated answers. In another process, staff might return to a controlled manual queue.
Those fallbacks need capacity estimates. A manual process that handled yesterday's pilot may be overwhelmed after automation has expanded demand.
There is also a continuing cost to retaining options. Multiple suppliers add procurement and assurance work. Running models internally creates operational responsibilities. Boards should fund the recovery capability that matches the business impact, with explicit acceptance where maintaining an alternative would be disproportionate.
A practical agenda for the next 90 days
Boards can make progress without waiting for a comprehensive AI strategy refresh.
Establish the critical uses
During the first month, identify where AI already supports important business activity, including capabilities embedded in existing software. Prioritise by operational consequence and data sensitivity.
For each priority use case, name the accountable owner and record the underlying suppliers, processing locations and available fallback. Unknowns should appear as actions with deadlines.
Exercise one consequential failure
In the second month, choose a realistic scenario for a critical workflow. It could be a provider outage, an unsuitable model update or an agent making an unauthorised change.
Run the exercise far enough to establish who detects the problem, who can stop the service and how work continues. Measure the recovery time and any backlog created. Record where the planned response depends on knowledge or access held by one person.
Make the funding decisions
By the third month, bring the evidence back to the board. Seek decisions on specific gaps: access controls, evaluation capability, supplier terms, fallback capacity or operational staffing.
Report expected business value alongside the cost of operating safely. Productivity gains should account for review, rework and exception handling. A workflow that saves time in routine cases may still create expensive failures at the edges.
The board should leave that review with named owners, funded actions and a date for the next exercise.
The most useful next step is to select one important AI-enabled process and require management to demonstrate how it handles sensitive data, exercises authority and recovers from supplier failure. That demonstration will reveal where the organisation has control and where its next investment is needed.
