Your AI Data Stays Local. Who Controls Everything Else?

Your organisation has bought local GPUs. Documents stay in a domestic data centre. The assistant answers questions without sending them to a public model API. That is a useful foundation. It still leaves a question: if your AI runs in your country, who controls its administration, telemetry, updates, model access, and continued operation?

Two announcements make this timely. On 30 September 2026, Eclipse launched the Sovereign AI Foundation, a vendor-neutral forum for understanding AI dependencies, assessing open source options, and developing practical guidance. Its announcement distinguishes that work from software development, which remains with Eclipse-governed projects. Read Eclipse's announcement.

On 29 September, NetApp announced Keystone Sovereign for qualified European customers, describing regional controls covering support, administrative access, and relevant data, logs, backups, and telemetry. The release identifies initial pilots for Germany and France; it does not establish universal availability or certify a customer's entire AI stack. Read NetApp's announcement.

My takeaway: sovereignty needs an operating model that people can inspect. These announcements are useful prompts for that review; the evidence must come from the system you actually run.

Use the AI Sovereignty Evidence Checklist alongside this article: download the printable PDF or download the editable CSV worksheet. Each area includes evidence to request, a verification method, and space for gaps and owners.

What operational sovereignty means in practice

Here, operational sovereignty means the organisation can govern who operates its AI, what crosses its boundary, how it changes, and how it continues or moves elsewhere. Data residency addresses one part of that control.

Define the boundary first: the country or region, permitted operators, approved external services, and required period of independent operation. A European service boundary and a single-country boundary are different requirements. External dependencies may be acceptable when their purpose, permissions, failure behaviour, and replacement options are understood.

Follow one private RAG assistant

Consider an illustrative assistant for internal maintenance manuals. Retrieval-augmented generation, or RAG, retrieves relevant document passages and supplies them to a model to help answer a question.

The proposed local path is: documents, parsing, embeddings, a vector database, retrieval, and generation on local GPUs. Authentication, authorisation, and audit records surround that path. Backups protect it; administrators maintain it.

Now add the dependencies that a simple architecture picture can omit: a hosted identity provider, a remote document parser, diagnostic uploads, container registries, model download credentials, licence checks, and a cloud fallback when the local model is busy. These are possibilities to investigate, not claims about either announcement. A local inference server alone cannot establish where the whole workflow runs.

Eight areas to verify

1. Data location

Where are documents, prompts, embeddings, and backups? Include extracted text, temporary files, conversation history, replicas, and support bundles. An embedding is derived data that belongs in the inventory.

How would you verify this? Reconcile a data-flow map with storage and replication settings. Trace a synthetic document through ingestion, retrieval, logging, and backup. Record the locations and retention rules for every copy you find.

2. Inference

Where does processing happen, including fallback requests? Check parsing, embedding, reranking, and generation separately. A local language model may still receive passages selected by a hosted service.

How would you verify this? Inspect endpoint configuration and outbound connections during representative requests. In a test environment, make the local model unavailable and observe whether the request stops, queues, or moves to another endpoint.

3. Administrative access

Who can access the system, and who approves it? Include supplier support, subcontractors, service accounts, infrastructure administrators, and emergency access. Permissions to change routing or export a database matter alongside access to the chat screen.

How would you verify this? Review privileged roles and a recent access record against its approval. Test a time-limited support session and confirm access expires and remains auditable.

4. Logs and telemetry

What leaves the environment? Prompts, retrieved passages, filenames, user identifiers, traces, and crash dumps may appear in diagnostic systems. Include what happens when support asks for a bundle.

How would you verify this? Inspect logging settings and sample payloads, then monitor outbound traffic during normal use, errors, and support collection. Encrypted traffic reveals destinations, not its full contents; combine network evidence with application-level inspection.

5. Encryption keys

Who controls the keys, and who can revoke them? Identify who grants decrypt access, who can change key policy, and what the application retains after decryption.

How would you verify this? Inspect key policies and audit records. Revoke a test key in an isolated environment and attempt fresh decrypt operations. Record cache behaviour and recovery steps. Revocation does not recall plaintext already copied or loaded into memory.

6. Software and model updates

Who approves changes, and can versions be retained? Cover model weights, tokenizers, runtimes, drivers, prompts, and retrieval settings. Record model access conditions and the rights needed to retain and use an approved version.

How would you verify this? Match deployed versions and hashes to an approved release manifest. Rebuild from retained artifacts with external registries blocked, then demonstrate rollback. Assign responsibility for security fixes so version retention does not become indefinite neglect.

7. Continuity

What works if external services become unavailable? A running process may survive an outage while a restart, new login, licence renewal, or restore fails.

How would you verify this? Run a controlled disconnection exercise covering login, ingestion, inference, restart, and restoration from backup. Include token or licence expiry where relevant. Record the tested duration, lost functions, recovery time, and staffing needed; a short test cannot prove indefinite independence.

8. Exit and portability

Can the organisation export its data and replace components? Include documents, permissions, metadata, configurations, evaluation cases, and audit records. A vector export may still require re-embedding when the embedding model changes.

How would you verify this? Import a representative export into an alternative component. Recheck retrieval quality, citations, and access restrictions. Measure migration time, unavailable features, and any supplier assistance required.

Turn answers into accountable decisions

Give each checklist entry an evidence reference, capture date, system version, observed result, gap, named owner, and next action. Mark untested claims as unverified. Record accepted dependencies with an approver and review date; keep them visible when conditions change.

Start with one complete user journey and one failure exercise. Review the findings with the application owner, platform team, security team, and procurement. That produces something useful for a buyer and actionable for an architect: a record of which controls have been demonstrated, which remain assumptions, and who will close each gap.

Download the AI Sovereignty Evidence Checklist (PDF) · Edit the worksheet in your spreadsheet application (CSV)