A Four-Layer Method for Assessing AI Sovereignty

The debate around sovereign AI often moves too quickly from a strategic concern to a technological answer. A government identifies dependency on foreign AI providers, then immediately asks whether it should train a national model, build domestic compute infrastructure or require local hosting.

Those may be valid interventions. But they are not a methodology.

Before choosing a solution, policymakers need to answer a more basic set of questions: What value are we trying to protect? Which parts of the AI value chain are required to create that value? Who controls those parts today? How concentrated is the dependency? What happens if access is interrupted? And how much control is actually necessary for this specific use case?

In reviewing the available approaches, I did not find a widely accepted methodology that integrates that full sequence. The literature offers strong frameworks for classifying AI systems, mapping markets and value chains, describing dimensions of control, testing strategic dependencies and managing risk. Each illuminates part of the problem. None, on its own, provides a complete path from a defined use case to a proportionate national response.

The method proposed here is a synthesis of those contributions. It is organised as four core layers, with additional sources supporting the questions, evidence and implementation inside them. The governing question is: for a defined AI use case, where are the material gaps between current and required control across the value chain, and what is the least intensive intervention that closes them?

How the sources were selected

I used four criteria. First, institutional authority: the source comes from a government, intergovernmental body or recognised standards institution. Second, methodological contribution: it provides a usable taxonomy, assessment logic, set of dimensions or decision process, rather than only a statement of policy ambition. Third, national relevance: its concepts can inform public policy, public procurement or nationally significant AI capabilities. Fourth, complementarity: it contributes something materially different to the decision sequence, even where concepts overlap.

Not every source was created as an AI sovereignty framework. That is precisely why synthesis is required. OECD classification establishes the context of the use case. OECD value-chain research maps the system and its dependencies. Sovereignty, cloud and resilience sources help define what control means. The JRC tests when reliance becomes strategically significant. NIST, Canada's assessment approach and ISO guidance help translate the analysis into governance, evidence and repeatable practice.

A source belongs in the core when it changes the structure or outcome of the assessment. A supporting source adds depth to a core layer or helps operationalise it. This distinction does not imply that the supporting sources are less rigorous or less important. It describes the role they play in the combined method.

Layer 0: Classify the use case

The OECD Framework for the Classification of AI Systems comes first because sovereignty requirements cannot be assigned in the abstract. It describes the system through five dimensions: people and planet, economic context, data and input, AI model, and task and output.

This separates, for example, an internal drafting assistant from a system that affects eligibility for public services, clinical decisions or national security. The classification establishes who may be harmed, what public value is at stake and how consequential interruption or failure would be.

Output: a defined use case and its criticality. This is a core layer because changing the use-case classification can change the required sovereignty posture.

Layer 1: Map the AI value chain

OECD research on AI markets and infrastructure provides the structural map. Relevant points may include energy, data centres, networking, semiconductors and accelerators, cloud and compute, data, foundation models, adaptation and tooling, integration, applications, and distribution.

Compute, data and skills recur across the chain rather than appearing only once. Actors may also control several layers at the same time. This matters because apparent supplier diversity at the application layer can conceal a shared dependency on the same cloud, chips, base model or jurisdiction.

Output: the components and actors required to deliver the use case, including direct and indirect dependencies. The value-chain map does not decide what must be domestic.

Layer 2: Measure control as a six-dimensional profile

No reviewed source supplies an AI-specific set of control dimensions ready for direct use. This method therefore introduces a synthesis layer. It draws on sovereignty, cloud, resilience and AI governance sources, but the resulting six-dimensional profile is part of the proposed method rather than an official external framework.

• Legal and contractual control: applicable jurisdiction, enforceable rights, termination terms, access commitments and protection from unilateral change.
• Data control: access, location, use, reuse, deletion, confidentiality, provenance and the ability to move data.
• Model and technological control: access to weights or interfaces, auditability, modification, portability, interoperability and replacement.
• Infrastructure and operational control: who operates the service, where it runs, continuity, observability, recovery and the ability to keep it functioning.
• Supply-chain control and resilience: concentration, indirect dependencies, substitutability, exit paths, inventories and trusted alternatives.
• Human capital and local expertise: the people and institutional knowledge needed to evaluate, adapt, operate, secure and replace the capability.

These dimensions become the rows of two matrices. The columns are the relevant value-chain points from layer 1. The first matrix records current control. The second records the control required by the classified use case. Evidence and uncertainty should be attached to every material rating.

Layer 3: Set the required autonomy using the JRC logic

The JRC's Open Strategic Autonomy work asks whether an external dependency actually constrains freedom of action. Its analytical logic combines four considerations: own capacity, external reliance, concentration of that reliance, and risk associated with external partners.

This is not a ladder with four official JRC labels such as “full control” or “strategic vulnerability.” Those can be useful policy summaries, but they are synthesis outputs. The JRC contribution is the proportionality test: external reliance may be acceptable when it is diversified, substitutable and anchored in trusted relationships. The same reliance becomes strategically material when alternatives are scarce, migration is difficult or partner risk is high.

Concentration should be supported by evidence. The JRC source uses partner-share measures. Measures such as HHI may add sensitivity where supplier-level market-share data are available, but HHI is an optional extension, not part of the JRC framework and not a substitute for analysing technical common points of failure.

Output: a justified required-control profile. Comparing it with the current-control profile reveals the gaps that policy or procurement must address.

The gap is the finding, not a vote for a national model

If current control already meets the required profile, no sovereignty intervention may be needed. If a gap exists, the response should target that gap. Options include stronger contracts, portability and exit requirements, supplier or jurisdictional diversification, trusted international partnerships, shared infrastructure, incentives for domestic capability, long-term public procurement, public-private partnership or direct state capability.

The method separates three questions that are often mixed together:

• Capability acquisition: managed API, self-hostable model weights, partnership, dedicated development or base-model training.
• Deployment: who operates the capability, on whose infrastructure, in which jurisdiction and with what continuity guarantees.
• Adaptation: prompting, retrieval, fine-tuning, continued pre-training or training from scratch. These are implementation methods, not sovereignty postures by themselves.

A self-hostable model may run in a foreign cloud. A managed API may run on reserved capacity with contractual continuity commitments. A locally trained model may still depend on foreign accelerators, software, data or expertise. Labels alone therefore do not establish sovereignty.

What the four layers do not decide

The assessment ends with a control gap and a proportional intervention direction. It does not by itself specify model size, architecture, training corpus, compute budget, funding instrument, intellectual-property allocation or the organisation that should operate the capability.

Those belong to a second decision stage: translate the control gap into a capability design, choose an institutional and commercial model, and evaluate concrete supplier or consortium proposals. Public requests for information can answer those downstream questions. They should not be forced into the four-layer diagnosis.

Israel's own policy history suggests a wide intervention spectrum rather than one institutional template: regulated markets, licensing, the state as an anchor customer, concessions and public-private partnerships, special state rights, government companies and direct state capabilities. The appropriate form depends on the gap, the required technical depth, market structure and the state's ability to govern the arrangement over time.

How the supporting sources deepen the core

The EU Cloud Sovereignty Framework makes control more concrete through legal, data, operational, technological and supply-chain criteria. The UK CMA adds a market-resilience lens: supplier diversity, substitutability, barriers to entry, disruption scenarios and factors that amplify harm. These sources strengthen the control profile and the assessment of external reliance without becoming separate stages in the sequence.

NIST contributes a discipline for governing, mapping, measuring and managing the dependencies that remain after a policy posture has been chosen. Canada's Algorithmic Impact Assessment and ISO/IEC 42005 contribute a different kind of value: they show how questions, evidence, review points and proportional requirements can be turned into a repeatable assessment process.

The distinction is therefore functional. Core layers determine what the assessment must decide. Supporting sources improve how a layer is measured, evidenced or implemented.

A research synthesis to test, not a finished standard

This method should not be treated as a complete or validated standard. It is a research synthesis intended to make the decision process explicit, traceable and open to challenge. Important questions remain, including how evidence should be weighted, when a control gap becomes material and how qualitative judgement should interact with quantitative indicators.

A useful next step is to test the method across materially different cases: a resident-facing government service, healthcare, education, a software startup, industrial systems, defence and a national language or cultural capability. Multiple evaluators should assess the same cases independently. Their disagreements will reveal ambiguous definitions, missing evidence and assumptions that have not yet been justified.

Formal weights or thresholds should come only after that testing. Otherwise, the model may manufacture precision before the underlying concepts are stable.

Conclusion

The method begins with the use case, maps the value chain, compares current and required control across six dimensions, and uses open strategic autonomy to test whether the resulting posture is proportionate. Its central result is the evidence-backed gap between what exists and what the use case requires.

Only then should policymakers ask what to buy, build, host, regulate or organise. This order keeps a preferred technology or institutional form from becoming the answer before the problem has been defined.

Source rationale

Dates refer to the cited publication or current version. The note beside each source explains why it is included and whether it is a core layer, a supporting source or a tool-design reference.