Sovereign AI in the Cloud: Where Data, Models, Logs, and Embedding Databases Should Reside

Sovereign AI is not just about choosing a cloud region for the primary database. In AI systems, sensitive information appears across multiple layers: model prompts, responses, embedding databases, RAG indexes, fine-tuning datasets, logs, telemetry, files, backups, and support requests.

That is why the entire data path must be reviewed: where data is stored, where it is processed, where it is transferred during a request, who has support access, how long derivative copies are retained, and whether they are used for training, diagnostics, or service improvement.

The practical principle is as follows:

• Source documents, personal data, trade secrets, embedding databases, and unsanitized logs must remain in a controlled region;
  
• Only minimal, sanitized, anonymized, or tokenized context should be sent to an external AI API;
  
• Fine-tuning datasets, checkpoints, adapters, and weights resulting from training on internal data must be treated as sensitive assets;
  
• Logs of requests, model responses, errors, and traces must not become a shadow repository of sensitive data;
  
• Deleting the source document must be tied to the deletion of chunks, embeddings, indexes, logs, and backups where applicable.

The key question is not “where the primary database resides,” but rather whether the company controls the entire data path—from the document to the query, embedding, model response, log, backup, and support access.

Why the right region alone is not enough

A company may store documents and customer data in the required cloud region, configure access controls and encryption, pass an audit—and still accidentally move sensitive information out of the controlled zone.

This does not require moving the primary database. It is enough to send contract fragments to an external AI API, keep an embedding database in global storage, or write prompts, model responses, and errors to SaaS monitoring without sanitization. On paper, the source data may remain in the correct region, but copies and derived layers are already governed by different rules.

In AI systems, risk is not limited to the database. Data appears in prompt contexts, model responses, vector indexes, fine-tuning datasets, logs, telemetry, files, backups, and support requests.

That is why sovereign AI is not only a legal issue, but also a cloud architecture issue: where data, models, logs, and embedding databases are stored; which components remain in the controlled region; what can be transferred outside it; and under what conditions.

Next, we will examine the core principle of this architecture: the first step is to control not an individual database, but the full data path within the AI environment.

The data path matters more than the selected region

Choosing a cloud region does not automatically make the entire AI environment sovereign. Data residency answers the question of where data is stored and processed. Sovereignty is broader: it includes contractual terms, technical restrictions, support access, retention periods, deletion of derived copies, and rules for transferring data to external services.

The main mistake is treating residency as full sovereignty. The primary database may be located in an EU region, but a contract fragment may be sent to an external AI API, an embedding database may reside in a global service, and the request body may be stored in SaaS monitoring. Formally, the database has not been moved, but some of the data has already left the controlled path.

That is why you need to review not just a single resource, but the entire data path:

• Where the data is stored;
• Where it is processed;
• Where it is transferred during a request, diagnostics, and integration;
• Who has administrative or support access;
• How long copies, logs, and intermediate results are retained;
• Whether the data is used for training, diagnostics, or service improvement.

If even one layer is not controlled, the region of the primary database does not eliminate the risk. Therefore, the next step is to classify data by sensitivity and determine which derived AI layers also require protection.

Sensitive, de-identified, and derived data

In an AI system, sensitive data is not limited to the original documents. Risk may persist in a short fragment of a prompt, a model response, an embedding database, an error log, or a dataset used for quality evaluation.

Sensitive data includes personal data, trade secrets, contracts, customer correspondence, medical and financial information, internal documents, and original support requests. Sensitivity is determined not by format, but by content and context: a contract PDF, a row from a CRM system, and an excerpt from a ticket may require the same level of control.

De-identified data can be processed more freely, but it cannot automatically be considered safe. If a name is removed from the text, but a case number, a rare medical phrase, a property address, or a unique combination of attributes remains, re-identification is still possible.

Tokenized data provides more control. In this case, actual values are replaced with tokens, and restoration is possible only within a controlled zone. For example, an external AI service receives CLIENT_123, rather than the client’s name, policy number, or account number.

In an AI architecture, it is important to account not only for the source data but also for derived layers:

• Requests to the model and model responses;
• Embeddings and embedding databases;
• RAG indexes;
• Fine-tuning and evaluation datasets;
• Model artifacts, adapters, and checkpoints;
• Logs, telemetry, and support data;
• Backups of all these layers.

Derived data does not automatically become safe. A model response may repeat a name, order number, or diagnosis. An API log may store both the prompt and the response. Embeddings also cannot be treated as de-identified by default: they preserve semantic proximity to the source documents and can reveal context through search.

AI Component Placement Model

After classifying the data, the architecture should be mapped to control zones. This helps identify which components remain within the managed cloud perimeter and which may interact with external services only after sanitization, masking, or tokenization.

The core principle is simple: a document may be stored in the required region, but a fragment of it may be sent in a request to a model, an embedding database, a log, an error trace, or a support ticket. Placement rules must therefore cover not only the source database, but also all derived layers of the AI system.

This model is needed to avoid confusing “the data is stored in the region” with “the entire AI perimeter is controlled.” If the embedding database, logs, or support tickets are governed by different rules, the sovereignty of the primary database does not eliminate the risk.

EU Cloud Infrastructure You Control

Run production workloads on dedicated resources across EU data centres. Transparent pricing, no hidden costs. Full control over compute, storage, and networking.

Explore Infrastructure

Predictable Virtual Machines for Production

Dedicated vCPUs, consistent performance, no noisy neighbours. Deploy and scale VMs in minutes. Full root access, fixed pricing.

View VM Plans

Up to €22,000 to Migrate Your Workloads

Cut OPEX when migrating to EU infrastructure. Get migration support, cost assessment, and infrastructure credits with no upfront commitment.

Apply for Bonus

Kubernetes with Full Control

Deploy production-ready clusters with control over node configuration, storage, and networking. Predictable costs and direct access to infrastructure.

Deploy Cluster

Once this map is in place, you can move on to the practical question: where exactly the key layers of the AI system—data, models, logs, and embedding databases—should be stored.

Where to Store Data, Models, Logs, and Embedding Databases

Data: Raw, Sanitized, and Derived

Raw sensitive data must be stored in a controlled region and processed in an environment where access rights, encryption, backups, and retention periods are managed. This applies not only to the primary database, but also to file storage, queues, temporary directories, caches, and analytics exports.

Anonymized and tokenized data can be used more broadly, but only if the sanitization process is documented and verifiable. Simply removing a name is not enough: re-identification can also be performed using indirect data or a combination of such data; for example, a company and job title can identify a person fairly accurately.

A practical rule: sensitive data remains inside the controlled region, and only the minimum context without direct identifiers or unnecessary details is sent outside it. If a model can answer without the full document, the full document must not leave the controlled environment.

Models: base models, fine-tuning, and artifacts

A model does not always have to be stored in the same place as the data. If a company uses a base model from an external provider and sends it only de-identified fragments, the main risk is not related to the model weights, but to the requests, logs, files, and the provider’s processing terms.

Fine-tuning on internal data is a different scenario. Datasets, checkpoints, adapters, weights after training, and quality evaluation results should be treated as sensitive assets. They may not explicitly contain the original document, but they can reflect internal wording, classifications, customer scenarios, or business logic.

For this reason, the training environment and the model execution environment should be documented separately: where the training datasets are stored, where training is run, where artifacts are saved, and who is allowed to download them.

Logs: diagnostics must not become a shadow database

Logs are typically needed for investigations, quality monitoring, and security, but in AI systems they can easily become a copy of sensitive data. Logs that store user prompts, model responses, API request bodies, identifiers, document fragments, errors, traces, and support ticket data are particularly risky.

Logs must be stored in a region that meets the requirements applicable to the source data, or sanitized before being sent to centralized monitoring. Like other data, they require masking, limited retention periods, viewing permissions, export controls, and a clear deletion procedure.

A common mistake is to configure the primary AI system in the required region while sending raw logs to an external observability service. In this case, the logs themselves become the channel through which data leaves the controlled environment.

Embedding Databases and RAG: A Derived Data Store, Not a Cache

An embedding database stores vector representations of documents and chunks. In a RAG architecture, it is used to find relevant internal sources, which are then added to the context of the request sent to the model. It is therefore not a technical cache, but a derived data store tied to the source documents.

If an embedding database is built from sensitive data, it must be stored in a controlled region and protected with access controls, encryption, and auditing, while deletion must be synchronized with the source documents. If a document is deleted or its retention period expires, the corresponding chunks and vectors must be deleted or reindexed.

Embeddings should not be considered anonymized by default. Even without the original text, an index can reveal the semantic structure of documents, internal topics, and relationships between customers, events, or contracts. A separate risk arises when RAG returns an overly large document chunk to an external AI API: the embedding database remains in the region, but the retrieved text is still sent outside it.

After the core components have been placed, the next step is to review regional requirements more broadly: not only for databases and models, but also for logs, backups, monitoring, support, and subcontractors.

Requirements for storage and processing regions

The region matters not only for the primary database: in an AI architecture, data and derived artifacts appear in files, embedding databases, fine-tuning datasets, model artifacts, logs, backups, monitoring systems, and support requests.

A minimum regional review should answer several questions:

• Primary data — repositories for documents, files, databases, and working sets;
  
• Model execution — inference region, request routing, and response processing;
  
• Embedding layer — the place where embedding databases, RAG indexes, and related metadata are created and stored;
  
• Fine-tuning — training environment, datasets, checkpoints, adapters, and evaluation results;
  
• Observability — logs, metrics, traces, security events, and monitoring services;
  
• Backups — primary, emergency, and archival copies of data and derived artifacts;
  
• Support — tickets, attachments, emergency exports, and manual engineer access;
  
• Administrative access — countries, roles, and conditions under which the provider or contractor may take actions;
  
• Subprocessors — third-party services involved in processing, storage, or support.

For sovereign AI, sensitive data, embedding databases, fine-tuning datasets, model artifacts, raw logs, and backups must remain in a single controlled region or in a pre-approved set of regions. If part of the processing is moved to another jurisdiction, this must be visible not only in the contract, but also in the architecture diagram, service settings, and access rules.

The wording “the resource is created in region X” is too weak. It is better to define the requirement more broadly: data, derived artifacts, logs, backups, and support access are restricted to region X or to an approved set of regions. Only this addresses sovereignty at the architectural level rather than merely at the declarative level.

After regions, the most contentious element of the AI architecture remains: the external AI API. It can be used, but only if it is clear what data is sent outside, where it is processed, and what happens to it after the model returns a response.

Risks of External AI APIs and Checks Before Use

An external AI API can be an acceptable part of the architecture if it receives only minimized and sanitized context. However, it must not be treated as a routine compute call. A model request may contain a document excerpt, conversation history, a user identifier, an internal instruction, or a search result from a RAG system.

Before connecting an external API, you should review the key risk areas:

This table is not intended for a formal vendor assessment, but for deciding which data can be sent externally at all. If the provider does not give clear answers about regions, retention, logs, training, manual access, and deletion, the external API must not receive sensitive data.

In that case, there are three safer, more controlled options: run the model in your own managed environment, use the external API only with tokenized context, or deploy a gateway that sanitizes requests and blocks the transfer of prohibited data categories.

The main check is simple: an external AI API must not become a bypass channel through which documents, identifiers, embeddings, logs, or RAG results leave the controlled zone.

Conclusion

An AI system’s sovereignty is determined not only by the region of the primary database, but by control over the entire data path: from the document and the request sent to the model to the embedding database, response, log, backup, and support access.

Sensitive data and derived layers from which meaning, identifiers, or business context can be reconstructed must remain in a controlled region and be processed in a managed environment. Only minimal, sanitized, de-identified, or tokenized context should be sent to an external AI API.

The practical criterion is simple: if a company knows where its data, models, logs, and embeddings are stored, who has access to them, how they are deleted, and what is sent to external services, the AI environment can be considered managed. If not, the selected region remains a declaration rather than a sovereign architecture.

FAQ

Does the model need to be stored in the same region as the data?

Not always. If the model contains no traces of internal data and receives only de-identified context, it can be hosted separately, provided the contractual and technical requirements are met. However, fine-tuning datasets, checkpoints, and model artifacts created after training on internal data should be treated as sensitive assets.

Can documents be sent to an external AI API?

Sending full documents that contain personal data, trade secrets, medical, financial, or contractual information is risky. A safer approach is to extract only the minimum necessary excerpt, remove identifiers, apply tokenization, and verify where the API processes and stores requests.

Why is an embedding database considered sensitive?

An embedding is not the same as the original text, but it preserves the document’s semantic structure. Restricted context can be exposed through search, matching, or access control errors. Therefore, a vector database should be protected as a derived sensitive store, not as a technical cache.

Which logs pose a risk to data residency?

Logs are risky when they store model requests, model responses, API request bodies, user identifiers, document fragments, error traces, and support ticket data. These logs require sanitization, masking, limited retention periods, and binding to the appropriate region.

Is the condition that “data is not used for training” sufficient?

No. You also need to check the retention period, processing region, file storage, vector stores, abuse monitoring, manual access, subprocessors, exceptions to regional guarantees, and the data deletion procedure.

Who is responsible for AI sovereignty in the cloud?

Responsibility is shared. The provider is responsible for its infrastructure and the stated service terms. The customer is responsible for data classification, request routing, access controls, encryption, DLP tools, logs, region selection, and the policy for transferring data to external services.

Bibliography

1. NIST — AI Risk Management Framework

2. Cloud Security Alliance — Data Security within AI Environments

3. OWASP — Top 10 for LLM Applications 2025

4. Microsoft Learn — Data, privacy, and security for Azure OpenAI Service