Back to Insights
AI SovereigntyResearch Review · July 2026 · 12 min read

Seven Frameworks You Need to Assess AI Sovereignty

A country cannot decide how much control it needs over AI by asking only whether it should build a national model. It first needs a method for understanding the use case, the value chain, the dependencies, the consequences of failure and the alternatives available.

The discussion 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 large language 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?

I reviewed seven established frameworks and assessment approaches from the OECD, the European Commission, the European Commission's Joint Research Centre, the United Kingdom, Canada and NIST. None was designed to provide a complete assessment of AI sovereignty. Together, however, they provide the building blocks for one.

The proposed assessment sequence

The synthesis produces an eight-stage process. The rest of the article explains which framework contributes to each stage and where its limits remain.

  1. 1Classify the use caseIdentify who uses it, who is affected and what task it performs.
  2. 2Define the valueSpecify the public, economic, social or security outcome to protect.
  3. 3Map the value chainIdentify the data, compute, model, software, infrastructure and skills required.
  4. 4Assess current controlDetermine what can be operated, modified, audited, transferred or replaced.
  5. 5Map dependenciesIdentify suppliers, jurisdictions, concentration, indirect dependencies and alternatives.
  6. 6Assess criticalityExamine the consequences of failure, interruption, price changes or loss of access.
  7. 7Define required controlSet a justified target for each relevant layer and control dimension.
  8. 8Choose the interventionDecide whether to accept, monitor, diversify, regulate, partner, incentivise or build.

1. OECD AI value chain: What does the system depend on?

The OECD's work on AI markets and infrastructure is the most useful starting point for interpreting the term "AI value chain." It maps the upstream and downstream activities required to turn technical inputs into products, services and economic value.

Upstream layers include semiconductor design and production, accelerators, data centres, energy, networking, cloud services, training data, skills and foundation model development. Downstream layers include model adaptation, specialised models, development platforms, integration, applications and adoption across sectors.

The OECD also identifies compute, data and skills as recurring inputs across the chain. These inputs matter because limited access, market concentration and vertical integration can turn them into bottlenecks.

This framework answers the first question: Which layers and inputs are required to create value from a particular AI use case?

It does not tell a government which layers it must own or control. It maps the terrain, but it does not define the required sovereignty posture.

2. OECD classification framework: What kind of AI use case are we assessing?

A public education assistant, a benefits eligibility system, a software startup and an industrial robot should not be assessed under the same control requirements. The OECD Framework for the Classification of AI Systems helps explain why.

It characterises an AI system across five dimensions:

  • People and planet: who uses the system, who is affected and what rights or interests may be involved.
  • Economic context: the sector, business or public function, scale of deployment and whether the system supports a critical activity.
  • Data and input: data sources, structure, sensitivity and quality.
  • AI model: the model type, how capabilities were acquired and whether the model is general or specialised.
  • Task and output: what the system does, its level of autonomy and how its output affects the physical or digital environment.

This framework answers the second question: What is the context of the AI system, and why might that context justify a different level of control?

It prevents a national strategy from imposing the same requirements on every AI deployment. However, it does not assess sovereignty or external dependency.

3. EU Cloud Sovereignty Framework: What does control actually mean?

"Control" and "sovereignty" are often used as if they were binary properties. The European Commission's Cloud Sovereignty Framework provides a more operational approach.

The framework uses 48 criteria grouped into eight sovereignty objectives: strategic; legal and jurisdictional; data and AI; operational; supply chain; technological; security and compliance; and environmental sustainability. It assigns Sovereignty Effectiveness Assurance Levels from SEAL 0 to SEAL 4.

The important methodological insight is not the specific cloud procurement score. It is the idea that sovereignty can be expressed as a multi-dimensional profile with different assurance levels.

A service may require strong control over data and operations, while accepting some foreign technological dependency. Another may require protection from foreign legal authority, local operational continuity and a credible exit path.

This framework answers the third question: Across which dimensions should control be assessed, and how can different levels of assurance be represented?

Its criteria cannot simply be copied into an AI model strategy. They were designed for cloud procurement. They need to be adapted to training data, model weights, code, evaluation tools, model adaptation, inference infrastructure, portability and access to technical expertise.

4. JRC Open Strategic Autonomy: When does external dependency become strategic?

A country can depend on foreign technology without losing meaningful autonomy. The critical question is whether it retains credible options.

The Joint Research Centre's work on open strategic autonomy examines external reliance, the concentration of that reliance and the risk associated with the external source. For AI, this suggests assessing supplier concentration, geographic concentration, geopolitical and legal exposure, substitutability, domestic capability and trusted partnerships.

Dependency on a foreign component may be manageable if multiple independent suppliers exist, migration is practical and the relevant states are trusted partners. The same dependency becomes more serious when every apparent alternative relies on the same chips, cloud platform, model provider or jurisdiction.

This framework answers the fourth question: Is the dependency diversified and manageable, or concentrated in a way that limits national freedom of action?

It also provides an important correction to simplistic sovereign AI narratives. Sovereignty does not require autarky. Partnerships, alliances, interoperability and diversification can all strengthen strategic autonomy.

5. UK Market Resilience Framework: What happens if the supply is disrupted?

Dependency matters only in relation to the harm that disruption could cause. The UK Competition and Markets Authority's Market Resilience Framework offers a useful way to analyse that harm.

The framework distinguishes between sources of fragility, such as low supplier diversity and financial weakness, and factors that amplify harm, including the criticality of the product or service, barriers to entry and the presence of vulnerable consumers.

Applied to AI, it prompts practical scenarios: What happens if an API becomes unavailable for an hour, a week or a year? Can the organisation return to a manual process? How many people are affected? Are rights, safety or essential services involved? How long would it take to introduce an alternative? What happens if prices increase sharply?

This framework answers the fifth question: How severe would disruption be, and which characteristics could turn it into a national problem?

The framework also warns against false precision. Criticality and harm cannot always be reduced to a quantitative score. Qualitative judgement remains necessary.

6. Canada's Algorithmic Impact Assessment: How consequential is the use case?

Canada's Algorithmic Impact Assessment is a structured questionnaire used to determine the impact level of an automated decision system. It considers system design, algorithm, decision type, impact, data and mitigation measures, and produces an impact level from one to four.

The Canadian tool is not a sovereignty assessment. Its contribution is procedural: assess the consequences of the use case first, then apply requirements proportionate to the impact.

This is particularly relevant when comparing AI used for drafting internal documents with AI that influences access to public services, medical care, education or administrative decisions.

This framework answers the sixth question: How consequential is the system, and what level of scrutiny should follow from that impact?

7. NIST AI RMF: How should accepted dependencies be managed?

Even when a dependency is considered acceptable, it still needs to be managed. The NIST AI Risk Management Framework organises that work around four functions: Govern, Map, Measure and Manage.

The NIST Generative AI Profile is especially relevant to the AI value chain. It recommends documenting over-reliance on third-party data and systems, identifying fallbacks, recording incidents involving external AI components, defining ownership and preparing incident response, fallback and recovery plans.

This framework answers the seventh question: Once dependencies and risks are known, how should they be governed, monitored and handled over time?

NIST turns dependency mapping into operational responsibility. It does not determine which capabilities must be national, but it helps ensure that accepted dependencies do not remain invisible and unmanaged.

No single framework is enough

The seven frameworks and assessment approaches address different parts of the problem. The OECD maps the value chain and classifies the use case. The European framework breaks sovereignty into measurable dimensions. JRC tests whether external reliance is strategically dangerous. The UK and Canadian approaches assess criticality and impact. NIST helps manage the risks that remain.

Used separately, each leaves important questions unanswered. Used together, they provide the building blocks for the sequence introduced above. The value of the synthesis is not a single score, but a defensible path from context and dependency to proportionate intervention.

The assessment should begin with an arena and be completed at the use-case level

A country should not begin with the abstract question, "Do we need a sovereign model?" At the national level, analysis may begin with an arena such as education, healthcare, industrial robotics, defence or resident-facing public services. But the required level of control should not be assigned to the arena as a whole.

It should be determined for a defined use case within that arena: an AI assistant helping residents access government services, clinical decision support, an AI coding service used by domestic startups, autonomous industrial inspection, intelligence analysis for defence or a national-language foundation model supporting public and cultural services.

Each use case depends on a different value chain and has a different failure profile. Each may therefore justify a different level of control.

A commercial API may be entirely appropriate for a startup testing a product. The same dependency may be unacceptable for a classified defence system and insufficiently resilient for a public service that enables citizens to exercise rights.

Control should be measured as a profile, not a single score

A single "sovereignty score" can conceal more than it reveals. A system may have strong control over data, weak model portability, acceptable legal exposure and no credible operational fallback.

The more useful output is a profile that compares current and required control across dimensions such as:

  • Legal and jurisdictional control.
  • Data control.
  • Technological control.
  • Operational control.
  • Supply chain resilience.
  • Security and auditability.
  • Portability and substitutability.
  • Continuity and recovery.
  • Skills and institutional knowledge.

The policy-relevant finding is not the overall score. It is the gap between the current and required level of control in each layer.

Dependency does not automatically justify national development

Once a gap is identified, governments still need a proportional response. The intervention ladder may include accepting the dependency, monitoring it, introducing procurement requirements, improving portability, diversifying suppliers and countries, establishing international partnerships, incentivising domestic research and industry, creating shared infrastructure or developing a national capability.

Building domestically is one option, not the default conclusion.

A rigorous methodology should be capable of concluding that no intervention is required. If every assessment produces a recommendation for more national infrastructure, the method is not discovering the answer. It is merely formalising a prior preference.

From literature review to a usable assessment

The next step is not to produce another long policy report. It is to convert these methodologies into a short, testable assessment tool.

A useful first version should be tested across materially different arenas: a resident-facing government service, education, healthcare, a software startup, industrial robotics, defence and a national cultural or language asset.

Multiple evaluators should assess the same cases independently. Their differences will reveal ambiguous definitions, unsupported assumptions and questions that require better evidence.

Only after this pilot should the framework introduce formal weights or thresholds. Otherwise, the scoring system may manufacture precision before the underlying concepts are stable.

Conclusion

The central question in AI sovereignty is not whether a country controls every component. It is whether it has enough control, choice and resilience to protect the value that matters in a specific context.

Answering that question requires more than one framework. It requires a sequence: classify the use case, map the value chain, examine control and dependencies, test the consequences of failure, define the required level of control and choose a proportional intervention.

That sequence provides a stronger foundation for national AI strategy than starting with a preferred technology and working backwards.

Open research repository

The Hebrew research notes, source mapping and initial integrated framework are available in a public GitHub repository. The repository is a personal research project and does not represent an official government position.

Explore the research repository

Primary sources

I write in a personal capacity. The views expressed here are my own and do not represent any employer, government body or organisation.