AI is an everyday part of our working life. From your office software, your inbox, your CRM, your website. You chose some of this; others were features enabled by a supplier.
So here's the question: can you name every AI feature your organisation uses?
No? Don't worry, most people can't.
Simon Chapman, our AI Lead, asked this question at the start of our recent webinar on AI sovereignty. None of the 50 participants, from digital teams across multiple sectors, could name all the features their organisation uses.
This tells a clear story about AI sovereignty. Few organisations understand their AI ecosystem well, and for most, sovereignty is still just an aspiration.
But Simon went on to explain that this needn't be the case, and that digital teams can take a few simple steps to start taking back control.
Watch the webinar below...
Control, not total ownership
Sovereignty can sound like a call to own every layer of your technology, from the hardware up to training your own model.
That isn't realistic or necessary for most organisations.
A more useful idea is strategic independence. You can still buy services from the market. But you should understand them, know what they do with your data and have a credible way to move if you need to. If leaving a platform would take years, you have very little control. If you could switch in weeks, you have a lot more.
Your contract with suppliers matters, but it won't answer every question.
- Who can access your data?
- Where is it stored, and for how long?
- Is it used to train the supplier's models?
- Who ultimately controls the provider?
- And what happens if you suddenly lose access?
Those last two questions aren't hypothetical. Simon gave two recent examples of US sanctions cutting people off from their technology. After Addameer, a Palestinian human rights organisation, was sanctioned by the US, Microsoft terminated its cloud account, resulting in the loss of all data stored since 1 January 2025. The second was Karim Khan, chief prosecutor of the International Criminal Court, who was personally sanctioned and reportedly lost access to his Microsoft email.
The risks won't be the same for everyone, but the lesson is simple; understand what you depend on before it becomes hard to change.
Own your knowledge, rent the intelligence
An AI feature is more than the model that produces the answer. It has several parts:
- An interface people can use it through
- Prompts that tell the model what to do.
- Content or data that is added to each request so the answer is relevant.
- A system that manages all of the steps above
For many features, you can keep most of these parts under your control.
Take a resident asking for help with council tax. A well-designed service finds the relevant pages on the council's website, passes that content to a model with instructions on what it should do and returns a clear answer. The council may not control the model. But it can control the content, the process, the prompts and the checks around it.
That leads to a useful principle: own your knowledge and rent the intelligence. Treat the model as a service you can plug in and swap out, not the foundation your whole feature depends on. Your content, data, prompts, processes and evaluation should stay yours, not disappear inside a supplier's product.
Start with the systems you already have
You don't need to solve AI sovereignty in one go. Start by listing the AI features already running in your organisation. For each one, ask:
- Who provides it, and where does it run?
- What data leaves your organisation, where is it kept and is it used for training?
- What is the AI being asked to do?
- What could you take with you if you left, and what would stop working?
Then build that thinking into how you buy and build. Add exit criteria to business cases and procurement now, rather than trying to work them out once a supplier relationship has already become hard to change.
Make sure you can see and edit the prompts used in your own features and write evaluation questions for the services that matter most.
Perhaps most importantly, choose features that let you switch AI models.
In the webinar, Simon showed how this works in Drupal, the open source platform we like to build with. A summarising and tagging workflow switched to a different model and provider without changing anything else in the content process.
You might use a large managed model or a smaller open-weight model, one whose files are published so you can run it on your own infrastructure. You might use another provider entirely. Either way, the question stays the same: does it meet the quality you need, and can you change it when you need to?
Test the quality you need
Switching providers only helps if you can tell whether the new one is good enough. That's where evaluation comes in.
Work with the people who know the subject best to write a small set of realistic questions. Agree on what a good answer needs to include. Then run those questions against each model or provider you're considering. Run them more than once, because the same model can give different answers to the same question.
For a council tax assistant, that might mean checking whether answers consistently include the key facts from the relevant council pages. For a tool that summarises articles, it might mean checking that each summary covers the points you agreed in advance. The tests don't need to be complicated. They give you a fair, practical way to compare options.
Perfect control isn't the goal, and nobody expects you to have it all worked out by next week. Start with the question none of our webinar participants could answer: what AI are you already using? Once you know, you can ask where your data goes, how you'd judge a replacement and how easily you could switch. That's when sovereignty stops being an abstract idea and becomes a set of choices you're making on purpose.
Watch the full webinar above or on YouTube.
