Your Sovereign AI Plan Needs a Second Operator

Your AI may be hosted in the UK and still depend entirely on one person. Test whether the operating knowledge belongs to the business.

UK hosting does not remove dependence on one person

Your AI service runs in a UK data centre. The contract names a UK company. Your files stay in an approved location. Those are useful facts, but they do not answer a basic operational question: who can run the service when its original builder is unavailable? If the answer is one employee, one contractor or an unnamed person at the supplier, the organisation still has a significant dependency. The location of the hardware has not transferred the knowledge needed to use it safely.

The Council for Science and Technology advice published on 19 October 2026 makes a useful distinction. It describes AI sovereignty in terms of agency across the AI value chain, not simply ownership of a machine. Its four recommendations include investing in people, skills, organisations, data and practical experience. That is national policy advice, not a requirement for every small business to build a domestic model. However, the underlying question translates well: does your organisation retain enough capability to make and carry out its own decisions?

For a small firm, that capability might mean understanding which documents feed an assistant, who approves changes, how access is granted and how a bad release is withdrawn. None of those tasks requires every employee to become a machine-learning engineer. They do require more than a friendly assurance that the technical person has everything covered. A system can be technically accessible while being practically unusable without its creator.

The proposed second-operator test is deliberately modest. Choose one important, bounded workflow and ask another authorised person to perform routine operational tasks from the documented instructions. Keep the original builder available as a safety observer, not a live instructor. Record every point at which undocumented knowledge becomes necessary. You are testing whether capability belongs to the business, not whether someone is clever enough to improvise.

A UK postcode does not tell you who can operate the system.

Separate business ownership from technical access

Start by naming the decisions that must remain with the business. A service owner decides what the workflow is allowed to do, what a satisfactory result looks like and when it should stop being used. A technical operator maintains the approved configuration and checks that the service is functioning. A reviewer checks outputs where judgement or accountability remains human. One person may hold several roles in a small firm, but the responsibilities should still be explicit.

Then map those responsibilities to actual access. Can the service owner see which version is live without needing unrestricted infrastructure permissions? Can the second operator inspect a failed run without reading every customer's documents? Can a reviewer reject an output without changing the underlying model? Shared passwords are not evidence of shared capability. They hide responsibility and make it harder to remove access cleanly when someone leaves.

This is not an imaginary concern about interchangeable software. In its 16 October 2026 business-software announcement, the Competition and Markets Authority described Microsoft's products as serving over a million UK businesses and public sector organisations, with around 20 million monthly users. Those figures refer to the wider business-software ecosystem, not AI users alone. The same announcement identified identity and access management across clouds as an area for further work. Even large platforms do not make ownership and permissions disappear.

What this means in practice is a short responsibility sheet for each important AI workflow. Name the business owner, primary operator, second operator and supplier escalation route. List the decisions each can make and the evidence they must record. For example, an operator might refresh an approved document collection but need the owner's approval to add a new source containing personal data. Make authority visible before asking someone else to take over. Otherwise, the handover can accidentally become a widening of access rather than a transfer of competence.

A second operator needs their own authorised access, not somebody else's password.

Run a routine-change drill, not a dramatic outage exercise

An outage plan asks how work continues when a service fails. A second-operator drill asks whether someone else can perform ordinary maintenance while the service is healthy. Keep those questions separate. A team may have an excellent manual fallback and still be unable to update its own assistant without its original developer. Conversely, a team may know how to administer the tool but have no realistic way to work without it.

Use a safe test environment with representative, non-sensitive records. Ask the second operator to identify the current approved configuration, find the source of one answer, inspect an unsuccessful run and make a small authorised change. A useful example is replacing a test opening-hours document, checking that the assistant uses it, then restoring the previous configuration. This is an illustration, not a claim that every platform exposes identical controls. Adapt the exercise to the service you actually use.

Write the acceptance conditions before starting. The person must be able to explain what changed, show the approval, demonstrate that unrelated permissions stayed intact and identify the relevant supplier contact. Do not reward speed at the expense of judgement. Stopping because the instructions do not cover a risky step is a good result: it exposes a gap without teaching people to guess. Record the gap and fix the instructions before repeating that part of the exercise.

For an illustrative customer-enquiry assistant, the drill could use ten fictional questions covering opening hours, cancellation terms and an unsupported request. Ten is a manageable starting sample chosen for the exercise, not a statistical guarantee of safety. The business owner should choose cases that reveal consequential mistakes. The purpose is to prove a repeatable operating procedure, not to certify a model with a tiny benchmark. If the builder has to explain where the settings are, how documents are selected or which failures matter, add those missing steps to the runbook.

Test ordinary maintenance without live coaching from the original builder.

Buy a service without outsourcing all your judgement

The strongest counterargument is sensible: a small business pays a managed supplier precisely because it does not want to operate servers or become an AI engineering department. That is a good reason to buy expertise. It is not a good reason to accept complete dependence on an individual whose availability and authority are unclear. The right boundary is retained business judgement plus a support arrangement that can survive personnel changes.

For a managed service, your second operator may only need to manage approved users, recognise an unsafe answer, pause a workflow and assemble a useful support request. The supplier can retain responsibility for patching, infrastructure and model deployment. Ask the supplier who covers the primary engineer's absence and how another engineer would understand your configuration. Evidence might include a maintained service record, a documented escalation path and an observed support handover. Do not demand unrestricted access to the supplier's internal systems as a substitute for those outcomes.

The CMA cloud-services decision page, updated on 16 October 2026, says AWS and Microsoft have taken steps to support UK customer choice while further action remains possible. Its accompanying announcement describes changes involving data transfer fees, interoperability requests and tools to automate switching. Those developments can reduce particular barriers, but they do not promise that your AI workflow, permissions and operating knowledge will transfer automatically. Infrastructure choice and organisational competence are different parts of the same dependency problem.

Be precise about regulation too. The CMA's Microsoft strategic market status proposal was provisional and subject to consultation in the October announcement. It was not a final ruling or proof of wrongdoing. The CST sovereignty letter is advice. Neither document imposes a universal two-person staffing rule on UK firms. The second-operator test here is an operational recommendation. Existing contractual, privacy and sector-specific obligations still need to be assessed for your own use case, with appropriate professional advice where necessary.

Managed support should reduce technical work, not remove business responsibility.

Make retained capability a small, recurring business control

Turn the first drill into a short capability record, not a sprawling transformation programme. Keep the workflow name, business owner, approved scope, primary and second operator, location of the current runbook and date of the last observed exercise together. Include the tasks each person can actually perform and the tasks that remain supplier responsibilities. A training certificate can support this record, but it cannot replace a demonstration using your approved process.

Budget for the exercise honestly. Count the second operator's time, the builder's observation time and the effort needed to repair unclear instructions. Compare that with the business effect of waiting for one unavailable person before a routine change can be made. Use your own figures rather than a generic claim that resilience pays for itself. Some low-risk tools will justify only a basic owner and support contact. An assistant connected to important customer work deserves a stronger level of retained capability.

What this means in practice is to attach the record to events you already manage. Recheck it after a major supplier change, a new document source, a permissions redesign or the departure of someone with operational knowledge. A calendar review can catch quiet drift between those events. Choose a frequency that matches how often the workflow changes; there is no magic monthly or quarterly interval that proves control. The useful evidence is that the named person can still follow the current instructions.

The CST advice also asks proposed national AI pilots to answer six questions, including what system must be built around the model and how success will be measured. For a business, those are helpful prompts rather than a new compliance checklist. Your answer should include people who understand the workflow, not just a preferred hosting location. Keep the successful parts simple, fix the missing knowledge and repeat only the tasks whose evidence has gone stale. Sovereign AI becomes more credible when the business can demonstrate informed control on an ordinary working day.

Retained capability is demonstrated through work, not declared in a hosting contract.