AI sovereignty: who can actually change the system?

A hospital is considering an AI application that prepares internal summaries of technical documents. In this fictional example, the supplier says that the servers are in Europe, the model weights are available and the customer controls its data. During the review, three questions remain unanswered: can a support engineer inspect an input, who can replace the model, and which organisation can change the access rules? Each answer could alter the hospital’s decision even if the servers stay in the same building.

For European hospital, pharmaceutical and medical technology leaders, I would therefore translate AI sovereignty into a set of demonstrable powers over a specific service. A useful statement names an actor, an action, the circumstances in which it is permitted and the evidence that the boundary works. Geography belongs in that statement. So do permissions, technical enforcement and the people able to operate them.

Start with the decision that ownership should protect

This reflection starts with Sonya Huang’s Sequoia talk Own Your Intelligence, published on 11 August 2026. She emphasises control over model weights while allowing different boundaries between internal capabilities and external services. This investor perspective on product development provides no clinical evaluation. [1]

For the fictional hospital, the immediate question is narrower: can the organisation keep confidential material within the agreed use and approve changes that affect an accepted workflow? A pharmaceutical research group might prioritise who can reuse unpublished experimental results. A medical technology manufacturer might prioritise who can change the model used to process technical complaints. These are proposed decision examples. The information and approvals required would depend on the actual activity.

Write the desired power as a sentence. For example: “Only the designated release owner can authorise a new model version for this workflow.” Then ask whether the contract, application configuration and underlying administration all support that sentence. An application-level approval button has limited value if another administrator can bypass it without a record.

Follow every relevant copy of the data

Use one artificial document to trace the proposed service. Identify where its contents enter, which components process them and where copies or derivatives appear. Include the search index, conversation history, diagnostic records, backups and any material selected for later model improvement. Establish what actually exists in this architecture; a generic diagram leaves that question open.

ANSSI’s SecNumCloud version 3.2, dated 8 March 2022, distinguishes customer-data location, technical data and administration. Section 19.2 permits documented support outside the EU, with access control and supervision from the EU. Its qualification requirements concern a defined cloud service; they establish no automatic approval of a hospital’s AI application. [2]

The practical implication I draw is to ask for the access boundary around each relevant copy. Who can see readable content? Who can grant that access? What must happen before an exception is allowed? A support request can matter as much as the main processing route if it includes a document excerpt. Record the permitted purpose and deletion arrangements for that route as well.

Encryption deserves equally concrete questions. Identify where keys are controlled and where the application needs readable information. A claim about encrypted storage leaves the processing step to be examined. Ask the technical team to explain which actors are excluded at each step and what evidence supports that exclusion. This avoids turning a product label into an assumed property of the whole system.

Separate model possession from release authority

Available model weights give the review a specific object: the numerical parameters used by the model. The organisation must still establish its permissions to use or modify that version, the software needed to run it, and who controls the surrounding application. Possessing a copy does not settle those separate questions.

The BSI’s 2021 AIC4 catalogue asks for information about learning frequency and significant model changes in its description of an AI service. These are useful disclosure categories from an older technical framework. They do not establish the suitability of a current language model or a legal requirement for this hospital. [3]

I would distinguish three proposed permissions in the review: using an approved model, adapting it with approved material, and releasing a changed version into the workflow. They can belong to different parties. A supplier may perform adaptation while the customer retains a release decision. Conversely, a locally operated model may change through an automated process that the professional owner has never examined.

Ask for the identifier of the version currently running, the person who approved it and the record of the last change. Include instructions, connected information sources and software components when they can change the result. For the fictional hospital, a new document repository could alter the summaries substantially even with identical model weights. The relevant boundary covers the complete accepted configuration.

Make administrative power visible

An ordinary user account reveals only one view of a system. The review also needs the people and organisations that can create privileged accounts, approve exceptional access, change connections or alter logging. Ask the supplier to identify these powers across its own organisation and the subcontractors involved in the service.

The BSI’s C3A version 1.0, published on 27 April 2026, treats external identity management, access logging and controlled administrative access as distinct criteria. It also addresses exchanges of data with third parties. The framework explicitly describes itself as non-binding and presupposes the C5 security criteria. It offers a basis for assessment, rather than a general sovereignty certificate. [4]

My proposed check is a supervised demonstration with artificial information and approved test accounts. Have the responsible team grant a narrowly scoped permission, show its record and revoke it. Examine whether revocation affects the intended route, including any existing session. Separately ask how exceptional supplier access becomes visible to the customer. A demonstration reveals behaviour under those conditions; it cannot prove that every hidden route has been excluded.

This exercise requires someone who understands the implementation and someone who can judge the permission’s business purpose. Procurement can obtain evidence, but a contract owner alone may be unable to interpret a technical exception. Record the unresolved question and the function responsible for resolving it.

Keep the evidence as precise as the claim

The European Commission’s implementation guidance, published on 1 June 2026, calls for examining technical layers and supplier chains. It also acknowledges the effort required to assess self-declarations. The framework arose from cloud procurement for EU entities. Its criteria are useful references; the proposed check here does not award one of its assurance levels. [5]

For each important power, keep four short entries: the stated arrangement, supporting evidence, any remaining gap and the person accountable for the decision. Distinguish a contractual commitment from an observed configuration and from an independent assessment. Each answers a different question. Check which service, version and period an assessment actually covers before applying it to the application in front of you.

The Commission also proposed a separate Cloud and AI Development Act in June 2026. As reviewed on 14 September 2026, its official policy page identifies it as a legislative proposal. Its proposed assurance levels must be kept distinct from the earlier procurement framework and from requirements already applicable to a particular organisation. [6]

The fictional hospital could then limit its first use to approved technical documents until the support-access question is resolved, while separately requiring control over model releases. That would be an explicit boundary around this application. The useful outcome is a decision people can explain: which powers the organisation retains, which it delegates, and what evidence makes that delegation acceptable.