Part of Sovereign AI for Education Systems: A Practical Guide for Ministries. This post applies the same control question to any organisation choosing an AI vendor.
Twice this year I have sat with the strategy team of a Big Four firm and heard the question their clients keep asking: which AI model should we standardise on? GPT, Claude or Gemini? A US model or a Chinese one? Closed or open-weight?
I hear the same question from ministries, assessment bodies and publishers across Africa and the Gulf. Model choice matters. Different models bring different capabilities, costs, risks and constraints. But it is the wrong first decision.
The assets that compound over time are the memory you accumulate and the methods you build around the model. Those should remain yours. The model should be replaceable. This post sets out why, what the three layers are, what it looks like in my own work, and a three-question test you can run on any AI deployment this week.
What you are really buying when you “adopt AI”
When an organisation, or an individual, adopts AI, it is usually acquiring three different things at once. Most products bundle them so tightly that the boundaries disappear. That is convenient at the start. It also makes it hard to see where the lasting value sits, and what you would lose if you left.
1. The memory layer
This holds the records, documents, decisions, correspondence and history of how you or your organisation works. It also includes the structure around those records: relationships, provenance, metadata and version history.
Everyone agrees they should control their data. Many assume they already do because a product offers a CSV export. But a pile of rows is not a working memory. If the relationships, history and structure disappear on export, much of the useful context disappears with them.
2. The method layer
This is the layer that gets the least attention, and it is where your working methods become explicit and executable. It includes the schemas that structure information, the workflows that move it, the prompts and rules that guide the model, the permissions and review gates that constrain it, and the evaluations that tell you whether it is working. It also includes the routing logic that decides which task goes to a model and which needs a person.
When a team spends six months getting an AI assistant to handle intake properly, the value is not only in the model or the records. It sits in the method the team has worked out: what to collect, how to classify it, which exceptions matter, when to escalate and how to check the result. That method is often the least portable part of an AI deployment. It is also the part I care most about, because it is where professional judgement lives. I write about capturing it in Expertise Encoding.
3. The intelligence layer
This is the model itself, the part everyone argues about: which lab, which benchmark, which release. It is also the layer that changes fastest. A model that leads this quarter may be overtaken next quarter, and prices move just as quickly.
What ownership means in practice
For me, ownership is practical, not legal. Can I inspect it, change it, version it, export it intact and move it without asking a vendor for permission? You can own the method while renting the infrastructure it runs on. Control matters at the points where your judgement and institutional memory build up.
Build inside a vendor’s walls and your workflows may be written in its configuration language. Your automations may live in its runtime. Your prompts, review steps and accumulated judgement may exist only inside its interface. You may be able to export the records, but not take the method with you in a form another system can run.
This is no longer only an architecture preference. The European Union’s Data Act, which has applied since 12 September 2025, includes rules to help customers switch between providers of data processing services and to improve interoperability. Portability has become a policy question.
Renting more of the stack can still be the right call. Managed platforms provide support, security, integrations and reliability. Building your own method layer brings maintenance, versioning and key-person risks, and managed dependency can be worth paying for. The risk is letting that dependency deepen without noticing it, testing it or pricing the exit.
What this looks like on my desk
I have spent the past year running a small version of this architecture across my own work, in a system I call NiallOS. My working memory sits in a structured database on infrastructure I control. It holds projects, documents, extracted evidence, decisions, commitments, contacts and journal entries. Around it sits a set of scripts, plain-text instructions and scheduled routines. A morning brief is ready before my working day starts. Meeting context is prepared before I ask. New research in my field is scanned each week. At the end of a working session, the relevant updates are written back into the system.
No single part is the breakthrough. The value comes from every routine sharing the same memory and the same methods.
Since I built it, I have changed the underlying models several times. I have used US frontier models, Chinese open-weight models routed through an aggregator, and different models for different roles depending on cost and capability. Changing the provider connection took minutes. No records had to move. The core workflows did not have to be rebuilt. The morning brief arrived the next day as usual, sometimes slightly smarter and sometimes slightly cheaper.
That does not mean a new model is automatically safe for every task. Models behave differently, and prompts, structured outputs, tool use and safety behaviour all need testing. The US National Institute of Standards and Technology’s AI Risk Management Framework treats evaluation as contextual and ongoing, which is the right expectation. A replaceable model still has to earn its place in a live workflow. What the architecture changes is the cost of that evaluation: I can test a different model against the same records and methods without rebuilding the system around it first.
Some models reach my system through an aggregator, a service that routes requests between providers. That is another dependency, but the records and methods still live elsewhere, and the route can be replaced.
This is the operational fact underneath the argument. The model provider can change. The memory and the method keep compounding. Compare a team whose prompts, automations and review steps live only inside one vendor’s assistant. For them, changing provider means more than choosing a new model. They have to reconstruct how the work was being done.
When control has to extend into the model
For many individuals and organisations the pattern is simple. Hold the memory and method somewhere you control, then call the model through an interface you can replace.
Some institutions need to move the control boundary further. I work with ministries, regulators and assessment bodies in the Gulf and across Africa. In some of these settings, law, data classification policy, contracts or institutional risk appetite require certain learner or citizen data to stay in-country or on premises. The intelligence has to come to the data, rather than the data going out to the intelligence.
That can mean running open-weight models on infrastructure the institution controls. This gives more operational control over the model layer, but it is not complete sovereignty. Licences, hardware, operators, security and update paths still matter. The sovereign AI guide for ministries covers those infrastructure choices in more detail.
The capability picture has also shifted. Stanford’s 2026 AI Index reported that in March 2026 the leading closed model was 3.3% ahead of the leading open-weight model on the Arena leaderboard. That does not make every open model suitable for every task, and running frontier-scale models locally still needs serious infrastructure and skills. It does mean open-weight models are now credible options for many workloads where local control matters.
The layers can be separated, but only by design. You have to draw the boundaries, write down the dependencies that remain and test whether switching actually works.
What this means for education systems
Education has a particular reason to care. A ministry’s curriculum, assessment frameworks, marking guidance and years of learner records are exactly the kind of memory that compounds. The way its officials moderate marks, review content or support teachers is exactly the kind of method that should not live only inside a vendor’s product. Procurement cycles are long, contracts outlast model generations, and the people who negotiated a deal have often moved on by the time it needs renewing.
So when an education organisation buys an AI service, I would want four things written into the agreement or the design:
- The right to export records together with their structure, relationships and history, in a documented format, at any time and at the end of the contract.
- Prompts, workflow definitions, rubrics and evaluation sets held in files or systems the organisation governs, not only in the vendor’s interface.
- A model interface that can be pointed at a different provider, or a locally hosted model, without rebuilding the service.
- A tested exit plan: what would be moved, retested and approved again, by whom, and how long it would take.
None of this stops a ministry from using commercial tools. It means the ministry chooses the dependency rather than discovering it later.
A three-question portability test
When the “which model?” conversation starts, in a boardroom, a team meeting or your own head, start with three questions instead.
- Where does our memory live? Could we take the records, relationships, history and structure with us tomorrow?
- Where is our method written down? Is it held in files and systems we govern, or only in a vendor’s configuration screens?
- If we changed model provider next month, what would we have to rebuild, retest and approve again?
If the answers are “inside their product”, “inside their product” and “almost everything”, you have made a deep platform commitment. That may still be the right commercial choice. But it should be explicit, bounded and revisited as the market changes.
You do not need to self-host everything to apply the principle. A one-person system can use a structured database, plain-text workflows and a thin routing layer. An institutional version will also need identity and access controls, audit logs, monitoring, evaluation, backups, disaster recovery and clear procurement terms. The scale changes. The ownership test does not.
Try the test on one live workflow. The parts that break will show you where the dependency sits.
Own the memory, own the method, rent the intelligence
Model capability will keep moving, and that is good news if you are set up to benefit from it. The method you develop and the memory you accumulate should still be there when it does.
If you are working through these choices for a ministry, an assessment body or an education organisation, see Work with me or get in touch. For the wider policy picture, start with Sovereign AI for Education Systems, and for how I capture working methods so AI can use them, see Expertise Encoding.
