Why a self-hosted vector database changes the EU sovereignty question
If your organization embeds contracts, customer records or internal documents, treat the vectors as derived data from those source documents, because they carry information about the text they were made from. Self-hosting keeps those vectors, their payloads and their snapshots under your own control, so the question shifts from where a US-hosted service stores them to whether your own deployment, its operators and its backups stay inside the boundaries you have set. Whether the vectors are personal data is a question you must assess for each collection, not something to assume. Ask what the source text contains, whether a person can be identified from the chunk and its metadata, and whether the payload fields include names, identifiers or case references.
On platforms, the three common choices are Qdrant, Milvus and PostgreSQL with pgvector. Qdrant and Milvus are dedicated vector engines that can run on your own Kubernetes clusters or servers, and Milvus offers a single-machine Standalone mode as well as a distributed cluster. pgvector adds vector search to a PostgreSQL database you may already operate, with the backup, high availability and access controls you already have. The right choice depends on collection size, filtering needs and whether your team can run a distributed cluster or patch and back up a stateful service around the clock. Confirm those capacity questions before you choose, because the sovereignty position is the same on all three once they run inside your boundary.
The sovereignty argument also depends on the embedding model. If the model that produces the vectors is a hosted API outside the EEA, the source text leaves your infrastructure before the vector database is involved, so the transfer analysis must cover that step as well. Document the full path: source system, chunking, embedding model location, vector store location, backups and any support access from outside the EEA. The EDPB Guidelines 05/2021 treat remote access from a third country, even only viewing data on a screen, as a transfer, so vendor support access belongs in that map.
Which EU rules set the requirements for vector storage
This table maps each EU rule that touches embeddings to what it means for where the vector store is hosted, who can administer it, who holds the keys and how long logs are kept. Read it as a set of build requirements to confirm with your legal and privacy team, not as a legal opinion, since whether a given embedding is personal data depends on your content and your assessment.
| Rule | What it asks for | What it means for the vector store build |
|---|---|---|
| GDPR Article 44 and Chapter V | Every transfer of personal data to a third country, including onward transfers, must meet Chapter V conditions. Infringements of Articles 44 to 49 can carry fines of up to EUR 20 million or 4% of worldwide annual turnover (Article 83(5)(c)). | Treat embeddings derived from personal data as in scope until your assessment says otherwise. Keep the collection, its replicas and its backups in the EEA and map every onward path. |
| EDPB Guidelines 05/2021 | Remote access from a third country, even only displaying data on a screen for support, and storage in a cloud outside the EEA are transfers. | Restrict administrator and vendor support access from outside the EEA, including screen sharing. Confirm where the vendor's support staff sit and whether they can see payloads. |
| Schrems II (Case C-311/18) | The CJEU invalidated the Privacy Shield while holding that standard contractual clauses remained valid, so transfers still need a transfer tool and a case-by-case assessment. | Standard contractual clauses do not settle the question alone. Document the destination's access powers and whether technical measures can protect data in the clear. |
| Data Privacy Framework status | Adequacy under Implementing Decision (EU) 2023/1795 covers only US organizations on the Data Privacy Framework List. An appeal against the General Court's September 2025 judgment is pending as Case C-703/25 P. | Do not assume a US vendor is covered. Check the vendor's listing and the appeal outcome before relying on it, and keep an EU-only hosting option ready. |
| 18 U.S.C. 2713 (CLOUD Act) | US providers must preserve or disclose data in their possession, custody or control, wherever that data is located. | An EU region of a US-controlled service can still be reachable by US process. Ask who controls the keys and whether the operator can be compelled to hand over data. |
| GDPR Article 48 | A third-country court or authority order requiring disclosure is recognized only if based on an international agreement in force with the EU or a Member State. | Include in the vendor review how requests are handled. Require the contract to commit to challenging or notifying requests where the law allows. |
| Data Act Article 32 and switching rights (Regulation (EU) 2023/2854) | Providers must take measures to prevent third-country governmental access to non-personal data held in the Union where it conflicts with EU or national law. Customers may switch to another provider or on-premises infrastructure, with switching charges banned from 12 January 2027. | Keep vectors exportable in a documented format and plan a restore to on-premises infrastructure. Confirm your vendor's exit terms in writing. |
| AI Act Articles 12 and 19 (logging) | High-risk AI systems must technically allow automatic event logging over their lifetime (Article 12(1)), and providers must keep logs for at least six months unless other law provides otherwise (Article 19(1)). | Enable query and access audit logs on the vector store and retain them in EU storage for at least the period your classification requires. Confirm whether your system is high-risk before setting the period. |
Do embeddings count as personal data under the GDPR?
Treat an embedding derived from a personal data record as potentially personal data until a documented assessment shows otherwise. A vector is a numerical representation of text, and it can still relate to an identifiable person when it was produced from a record about that person, when it sits next to identifiers, or when someone holding other data could link it back. The GDPR defines personal data broadly, so the practical default for a controller is to keep the vector, its payload and every copy of them inside the same protections as the source document. Whether a particular vector falls outside the regulation is a legal question. Your counsel or data protection officer must make that call and record the reasoning, and this page does not reach a legal conclusion on your data.
The most direct exposure is usually not the vector itself but the chunk text and metadata stored alongside it. In a typical RAG setup, the payload holds the original passage so the assistant can cite it, plus fields such as a customer identifier, a case number, a file path or an author name. A query that returns a point gives the caller that text in clear form, so the assessment should start with the payload schema, not the embedding math. Ask your team to list every payload field in each collection, mark which ones name or describe a person, and decide whether those fields should be stored at all, minimized, or kept in a separate store with stricter access. Confirm the exact field names and how your chosen engine, whether Qdrant, Milvus or pgvector, persists them, because the answer determines where personal data lands in backups and snapshots.
Which hosting pattern keeps vectors under EU control
Running the vector database in the organization's own data centers in the EU puts the storage, the keys and the administrators under the organization's direct control. Data stays on hardware the organization owns or leases in the EU, and no third party's cloud control plane sits between the cluster and the people who run it. The remaining exposure is usually the vendors and contractors who support the stack, because any remote session that displays data from a third country can count as a transfer under EDPB Guidelines 05/2021.
- Key custody: The organization can hold encryption keys in its own key management system, on EU hardware it operates.
- Admin access: Administrators are the organization's own staff, so access reviews and logging follow its existing identity controls.
- Support access: Any vendor screen-sharing or remote login from outside the EEA must be assessed as a transfer before it is allowed.
- Backups: Snapshots and off-site copies must also be placed in the EU, since storage outside the EEA is itself a transfer.
- Staffing: The organization must staff storage, upgrades and on-call operations for the cluster.
Confirm which support staff, vendors and tooling can reach the cluster, and from which countries, before signing any support contract.
Deploying the vector database into the organization's own account with an EU cloud provider keeps the data in an EU region while the infrastructure is rented. The organization still runs the software and holds the admin rights, but the cloud provider runs the underlying facilities and its own management plane. The key questions are whether the provider is subject to third-country law with extraterritorial effect, and whether its support staff can reach the data from outside the EU. EDPB Recommendations 01/2020 are direct on the point that technical measures cannot fix access to data in the clear where a foreign authority's powers exceed what is necessary and proportionate.
- Key custody: Customer-managed keys can be held in the organization's account, but confirm whether the provider's key service and its staff can access key material.
- Admin access: The organization administers the database, while the provider administers the hypervisor, network and managed services underneath.
- Support access: Confirm whether provider support engineers can view customer data, from which locations, and under which legal process.
- Legal exposure: Ask whether the provider's parent company is subject to the US CLOUD Act, since 18 U.S.C. 2713 applies regardless of where data is located.
- Region pinning: Confirm that backups, logs and monitoring telemetry stay in EU regions.
Request the provider's written statement on government access requests and support locations before choosing a region.
Qdrant Hybrid Cloud runs managed Qdrant clusters on the customer's own infrastructure, and Qdrant Private Cloud is a dedicated, fully isolated enterprise deployment. Both are priced through Qdrant sales, so the commercial terms are negotiated rather than listed. The data plane sits in the infrastructure the customer chooses, which can be an EU data center or an EU cloud account. The reader must still confirm where any vendor control plane, telemetry and support access sit, because a managed component can send metadata or diagnostics back to the vendor.
- Key custody: Confirm whether keys and secrets are held in the customer's infrastructure and whether the vendor ever receives them.
- Admin access: Confirm which cluster operations the vendor performs and which the customer keeps, including upgrades.
- Control plane location: Ask where the management components run and whether they process vector payloads or only cluster metadata.
- Support access: Ask whether vendor engineers can open sessions into the cluster and from which countries.
- Commercials: Pricing is set through sales, so request the written scope of included support and upgrades.
Get the data flow for any telemetry and support channel in writing, and check it against the organization's transfer assessment.
A managed vector service hosted in the United States stores vectors and runs queries on infrastructure owned and operated by a US provider. The Qdrant Cloud tiers and the Zilliz Cloud Serverless and Dedicated options are examples of managed offerings, and their hosting regions and staff locations must be confirmed for each plan. Storing data in a cloud outside the EEA is a transfer under EDPB Guidelines 05/2021, so Chapter V safeguards apply, and the Data Privacy Framework only covers organizations on the DPF List. The appeal in Case C-703/25 P is pending, so the position is open. Even within an EU region, the provider's US parent may be subject to US legal process.
- Key custody: Some plans offer customer-managed keys, but the provider still operates the service and its key handling.
- Admin access: The provider's staff operate the platform, and the customer controls only accounts and collections.
- Support access: Any support session that displays data from outside the EEA is a transfer, and the vendor's support locations must be confirmed.
- Legal exposure: Assess GDPR Article 48 and the CLOUD Act together, since the provider may receive orders it cannot refuse.
- Service terms: Uptime commitments differ by plan, so check the contract rather than the marketing page.
Ask the provider for its region, support location and government access policy in writing before any personal data is loaded.
Zilliz Cloud offers bring-your-own-cloud options for managed Milvus, which place the data plane in the customer's cloud account while the vendor operates the service. This is a hybrid pattern and it is not the same as self-hosting Milvus. The data may sit in an EU account, but the reader must confirm where the control plane, metadata and support access sit, since these can determine whether vendor staff outside the EU can reach the data. The Milvus project itself is Apache-2.0 licensed, so the open-source option remains available if the managed model does not meet the requirement.
- Key custody: Confirm whether the customer's keys are used for the data plane and whether the vendor can access the key material.
- Admin access: Identify which administrative actions the vendor performs in the customer's account.
- Control plane location: Ask where the control plane runs and whether it processes vector payloads or only metadata.
- Support access: Ask whether vendor engineers can open sessions into the customer's account and from which countries.
- Exit path: Confirm how the data can be exported to a self-hosted Milvus deployment, given the Data Act switching rights.
Request a written data flow diagram from the vendor that marks every point where personal data could leave the EU.
Which open-source vector engines fit an EU sovereignty brief
Three self-hosted options cover most EU sovereignty briefs: a dedicated Qdrant or Milvus deployment, or pgvector inside PostgreSQL you already run. The fourth card covers the checks that decide between them, which sit with your legal, security and platform teams as much as with the engine.
Qdrant on your own infrastructure
Qdrant is licensed under Apache-2.0 and the open-source engine is free to self-host, so the vectors stay on servers or cloud accounts you control. The default deployment has no authentication and listens on all interfaces, so API keys, TLS and per-collection JWT permissions must be configured before any data is loaded. JSON audit logging of authenticated API operations is available in recent releases. Check that your storage is block-level with a POSIX-compatible file system, because Qdrant cannot run on NFS or S3-style object storage.
Milvus with its own dependencies
Milvus is Apache-2.0 licensed and offers Standalone and Distributed deployment modes, with two active release lines. A distributed cluster depends on etcd for metadata, object storage such as MinIO, S3 or Azure Blob, and a write-ahead log such as Woodpecker, Kafka or Pulsar, so each dependency needs its own hosting, backup and access review. Milvus implements authentication, TLS and role-based access control. Confirm which release line your team will standardize on and how that line receives security fixes.
pgvector inside existing PostgreSQL
For teams already running PostgreSQL, pgvector adds vector search to a database that already has backup, replication and access controls under your own operations. This keeps the number of systems holding derived personal data small, which simplifies data mapping for sovereignty reviews. Confirm the vector dimension limits and index types supported by your PostgreSQL and pgvector versions, and test filtered queries at your expected collection size. Plan to move to a dedicated engine if scale or query rate outgrows the shared database.
Hosting and licence terms to confirm
Your legal and data protection teams should confirm where each engine runs, who operates it, and whether any vendor-managed option, such as a hybrid or cloud service, sends data or support access outside the EEA. Licence terms, including any commercial or enterprise components, should be reviewed before the architecture is fixed. Your security team should own authentication, key management and audit log retention. DeployOpen can prepare the deployment and evidence, but the sovereignty determination and the choice of hosting rest with your organization.
Documenting the embedding model's data flows
The embedding model is a processing step in its own right, and it is often the first place personal data leaves the EU. If chunks of documents are sent to a US-hosted embedding API, the text is transferred before any vector reaches your database, so a self-hosted vector store does not by itself keep the data in the EU. Map every step from source document to stored vector, and record where each step runs. Under the transfer rules in Chapter V of the GDPR, remote access from a third country and storage outside the EEA both count as transfers, as the EDPB Guidelines 05/2021 explain, so the embedding call needs the same scrutiny as the database.
Recommend running an open-weight embedding model on EU infrastructure, served by the same stack you use for LLMs, such as vLLM or Ollama. This keeps the embedding endpoint inside the same network boundary, access controls and logging as the rest of the pipeline. The record of processing for the embedding step should contain the model name and exact version, the host location and operator of the serving infrastructure, whether inputs or outputs are logged by any provider and for how long, the retention period for the inputs, outputs and any cached embeddings, and who can access those logs. Confirm each of these with your provider in writing if you use a hosted model, and treat an unanswered question as a reason not to use that provider for regulated content.
If the assistant or search tool is a high-risk AI system under the EU AI Act, Article 12(1) requires the system to technically allow automatic recording of events over its lifetime, and Article 19(1) requires providers to keep those logs for at least six months unless other law provides otherwise. Decide early whether your use case falls into a high-risk category, since that determines whether the embedding and query logs must be retained and for how long. Keep those logs in the same EU-controlled storage as the vectors, and confirm the retention period with your legal team, because it may conflict with the deletion duties that apply to personal data under the GDPR.
How a sovereign vector store rollout runs in phases
The sequence separates the legal question of whether vectors are personal data from the technical build, so each phase produces a record the controller can defend. Every phase closes with a named output that the next phase depends on.
Scope data categories and map transfers
The organization lists which sources feed the embedding pipeline, such as document repositories, ticketing exports or customer correspondence, and which data subjects and business records they contain. For each source it records where data is stored, who administers the systems, and whether any vendor, support engineer or cloud account outside the EEA can view or store it, including remote screen access. The output is a data inventory and a transfer map that shows every location and access path, reviewed by the data protection officer before any hosting decision is made.
Assess vector status with counsel
Client counsel or the DPO decides whether embeddings derived from personal data are personal data under the organization's GDPR analysis, and whether the vector store falls under the same controls as its source records. The assessment should also document the lawful basis for embedding, retention rules for derived data, and how erasure requests reach vectors. The output is a signed memo that sets the control baseline for every later phase, so the engineering team builds to a stated requirement rather than an assumption.
Decide hosting and build the environment
The team chooses an EU or in-country hosting location it controls, and an engine such as Qdrant, Milvus or PostgreSQL with pgvector, based on the scale and filtering needs set in the requirements. The build uses block-level SSD or NVMe storage, TLS for REST and gRPC, API keys or role-based access, and no public listener, because Qdrant instances are open on all interfaces by default. Confirm with the vendor which features your chosen edition includes. The output is a hardened environment with a documented network boundary and a configuration review that shows no unauthenticated endpoint is reachable.
Build the embedding pipeline on EU infrastructure
The embedding model runs inside the same boundary as the vector store, either as a self-hosted model or through a provider contract that the legal assessment has cleared, and the pipeline stores chunks, source identifiers and access labels together with each vector. Logs and intermediate files, including those written by orchestration tools, are placed in the same jurisdiction. The output is a documented data flow diagram for the embedding model, with each hop labelled by location, operator and retention period, which becomes part of the evidence pack.
Test migration and deletion
The team migrates a representative sample first, then the full corpus, and checks that point counts, payloads and access labels match the source records. It then runs deletion tests: remove a source record, confirm its vectors and payloads disappear from live collections, and trace whether copies remain in snapshots or backups. Restores are tested on a version-matched instance. The output is a test report with recorded deletion evidence and a documented backup retention rule that explains how erased data leaves backups.
Enable audit logging and assemble the evidence pack
The team turns on authenticated API audit logging, sets log retention and access rules for the logs themselves, and connects them to the organization's monitoring. If the vector store supports a high-risk AI use case, retention must also satisfy the event-log duties in Articles 12 and 19 of the EU AI Act, which the legal team should confirm for the specific system. The output is an evidence pack listing the transfer map, memo, configuration baseline, data flow diagram, deletion test results and log samples, which the controller can hand to an auditor or supervisory authority on request.
Cut over and review switching terms
The team cuts over application traffic in a planned window, keeps the previous retrieval path available until the new one passes acceptance checks, and records who approved the switch. After cutover, the contract owner reviews the provider or hosting terms against the Data Act, including the customer right to switch to another provider or to on-premises infrastructure, the notice period and transition period in Articles 25 and 29, and the ban on switching charges from 12 January 2027 under Article 50. The output is an accepted cutover record and an exit plan that names the data export method and the target environment.
Evidence a regulator or auditor will ask for
This table lists the records a data protection authority, auditor or internal assessor is likely to request for embeddings under EU control, and the component that produces each one. Read it as a preparation checklist: most items are produced by the vector store, the embedding pipeline or the hosting team, and each needs an owner and a retention rule before an assessment starts. Evidence is prepared for your assessors, and independent auditors or authorities decide whether it is sufficient.
| Evidence item | What it shows | Component that produces it |
|---|---|---|
| Transfer map | Every location where embeddings, source chunks and snapshots are stored, processed or accessed, including support access from outside the EEA | Architecture record maintained by the platform team and the DPO |
| Record of processing for embeddings | Purpose, data categories, lawful basis and retention for vectors derived from personal data | Data protection team, informed by the embedding pipeline design |
| Hosting location and admin access list | Regions, data centers and named administrators with access to nodes, object storage and backups | Infrastructure provider console and identity provider exports |
| Encryption and key custody records | Encryption at rest and in transit, who holds keys, and where key material is stored | Key management system logs and TLS configuration of the vector store |
| Qdrant audit logs or Milvus RBAC exports | Which identities performed which API operations and which roles or collection permissions were granted | Qdrant JSON audit logging or Milvus role-based access control configuration |
| Backup and restore test records | Proof that backups are encrypted, located in the EU and restore correctly with version-matched snapshots | Backup tooling reports and signed restore test runbooks |
| Deletion evidence for erasure requests | Source records, vectors, payloads, snapshots and backups affected by each erasure request, and when deletion completed | Erasure ticketing workflow combined with vector store deletion logs |
| Embedding model data-flow record | Whether the embedding model runs in the EU, which inputs leave the boundary, and whether any vendor API receives text | Embedding service configuration and network egress rules |
| AI Act log retention settings | Configured retention period for automatically generated logs against the minimum period in Article 19(1) | Logging platform retention policy and AI gateway or application logs |
What do buyers ask before a sovereign vector database project?
Are vector embeddings personal data under the GDPR?
Assess it for each dataset rather than assuming either answer. An embedding is derived from source content, and if the source text, metadata or payload can identify a person, or if the vector can be linked back to a person by the organization or a reasonable third party, the GDPR is likely to apply. Business documents can also contain personal data inside them, such as names in contracts or emails. Ask your data protection officer to classify each collection, document the reasoning, and decide which safeguards follow from that classification. The GDPR text on EUR-Lex is the starting point for that assessment.
What drives the cost of a sovereign vector database project?
Cost follows the written scope, which is agreed before work starts. The main components are the design and hosting review, the deployment and hardening of the database, integration with your embedding pipeline, backup and restore testing, documentation and evidence, and handover. Recurring costs include the infrastructure you run, support or retainers, upgrades, and the staff who operate the system. Qdrant Cloud and Qdrant Hybrid Cloud pricing is set by Qdrant sales, not published as a list, so request those quotes separately. DeployOpen does not publish prices. Ask for a quote that separates one-time work from recurring support.
How long does a sovereign vector database project take?
The timeline depends on the scope, the number of collections, the data sources, and how quickly your teams provide access and decisions. A single collection on existing infrastructure is a different project from a multi-region cluster with legal review and integration into several document systems. DeployOpen does not state a fixed duration here. Ask for a timeline as part of the written scope, with the dependencies you own listed separately, such as access approvals, network changes and sign-off on the data map.
What does the client need to provide for the engagement?
Three inputs matter most. First, a data map that lists each source system, the types of content embedded, the personal data they contain, and where vectors and payloads will be stored. Second, legal input from your privacy, legal and compliance teams on transfers, retention and erasure. Third, infrastructure access, including the cloud accounts, data centers or air-gapped networks where the database will run, along with identity, network and storage approvals. Missing any of these usually extends the scope rather than shortening the build.
Can our own team run a self-hosted vector database after handover?
Yes, if you have the capacity to run it. A self-hosted vector database needs someone to handle upgrades, backups, restore testing, monitoring, capacity planning and access reviews. Qdrant, for example, documents that self-deployed instances are not secure by default and need authentication and TLS configured, and its distributed mode recommends at least three nodes for production clusters. Confirm that your team can own those tasks, that the runbooks are written, and that restore tests are scheduled. DeployOpen can plan, implement, document and support the platform, with ongoing support available as a retainer.
Does the EU-US Data Privacy Framework matter if the vector service vendor is US-based?
It can matter, but it is not a complete answer. The Data Privacy Framework adequacy decision, Commission Implementing Decision (EU) 2023/1795, covers transfers to US organizations that are on the Data Privacy Framework List, and an appeal against the General Court's judgment upholding it is pending. Even with a valid basis, a US provider can be subject to US law such as the CLOUD Act, and the EDPB has said that some government access powers cannot be addressed by technical measures alone. Hosting the vector store in your own EU infrastructure removes the vendor from the transfer path, which is why many buyers choose that route.
Is hosting vectors in an EU region of a US cloud enough for sovereignty?
Usually not on its own. Hosting in an EU region does not settle whether a US-headquartered provider can be compelled to disclose data it controls, and remote access from outside the EEA can itself be a transfer under EDPB Guidelines 05/2021. Assess who operates the service, who can access the data, and under which law. Ask the provider for its government access policy and contractual commitments, and confirm them against your own risk assessment. Self-hosting inside your own accounts or data centers gives you the most direct control over these questions.
Questions to put to an implementation partner
Start with the access path, because it decides whether data leaves the EU even when the vectors never do. Ask the partner where remote support sessions originate, which countries their engineers work from, and whether any support activity displays vector payloads or source text on a screen. The EDPB Guidelines 05/2021 treat remote access from a third country, even only displaying data for support or administration, as a transfer, so the answer belongs in the legal assessment. Ask how the partner handles keys and admin credentials: where the Qdrant API keys or Milvus root credentials are generated and stored, who holds them, whether they are rotated after each engagement, and whether any vendor-side key or telemetry channel can reach the cluster. Note that a self-deployed Qdrant instance has no authentication by default, so ask the partner to show the configured admin and read-only keys, TLS settings and JWT-based per-collection permissions on your environment, not on a demo.
Next, ask where the embedding pipeline runs. The vectors are only as sovereign as the model call that produced them, so ask whether the embedding model is self-hosted in the EU or called through a US-hosted API, and which logs, prompts and cached inputs that call retains. Ask how deletion reaches snapshots and backups: how a point and its payload are removed from live collections, which snapshots and backup sets still contain it, and how the partner documents the time until those copies expire or are rewritten. Ask for the evidence package in writing: the data flow map, the transfer or no-transfer analysis, the hosting location of every backup target, and the named person who signs off the legal assessment. DeployOpen prepares evidence, but the controller and its counsel own the conclusion, so confirm that sign-off sits with your organization. Finally, ask how switching and exit are handled. The Data Act gives customers a right to switch to another provider or to on-premises infrastructure with a maximum two-month notice period and a 30-day transition, so ask for a tested export path using Qdrant snapshots or a Milvus export, and for proof that a restore works on infrastructure inside the EU.
Close with restore testing, since a sovereignty claim is weak if the backup copy sits outside the boundary or cannot be restored. Ask whether the partner has restored a snapshot into a clean EU environment, which version they restored into, and how they confirmed that the restored collection matched the source counts and search results. Ask who may run restores, whether restore access is logged, and whether test restores use real personal data or a masked copy. A partner that cannot answer these questions with specifics should not be trusted with the data-sovereignty scope.
How the Data Act supports moving away from a provider
This sequence turns the Data Act's switching rights and provider obligations into a contract clause and a tested export path, so the organization can leave a vector service or move the data to its own infrastructure without depending on the provider's cooperation. It produces evidence that the exit is possible before it is needed.
Confirm which services fall under the Data Act
Legal and procurement teams check whether the vector service, its managed tiers and any bundled hosting count as a data processing service under Regulation (EU) 2023/2854. Ask the provider in writing which contract, data processing service and region the vectors sit in, and whether any part is delivered from outside the Union. The output is a short written position recording the service category, the hosting location and the open questions for the provider.
Map the vector data you would need to move
The engineering lead lists every artifact that must survive an exit: vector points, payloads, collection and index configuration, the embedding model name and version, the chunking rules and the source record identifiers. Without these, a restored collection cannot be queried or traced back to source documents. The output is an inventory signed off by the data owner, stored alongside the contract file.
Write the switching terms into the contract
Legal drafts exit clauses that cover the customer's right to switch to another provider or to on-premises infrastructure, the notice period, the transition period and the export format. Confirm in writing that switching charges are removed from 12 January 2027, as the Data Act requires, and that the provider must support export in a documented, machine-readable form. The output is a signed clause set that names the exit steps and the responsible contacts on both sides.
Document the provider's third-country access exposure
The security and compliance team asks the provider how it resists third-country governmental access to non-personal data held in the Union, which is the obligation in Article 32 of the Data Act. Request the provider's legal and technical measures, its policy for handling foreign authority requests and any sub-processors outside the EU. The output is a written exposure assessment that the DPO and CISO review before signing.
Build an export path to your own infrastructure
The platform team sets up a self-hosted target, such as Qdrant or Milvus on the organization's own infrastructure, and configures the same collection schemas, dimensions and distance settings. Confirm the storage requirements of the target engine, including block storage rather than network file systems for Qdrant. The output is a running target environment that accepts the exported data and is ready for a restore test.
Test the export and restore on a copy
Engineers export a representative collection, load it into the self-hosted target and run the same queries against both systems. They compare point counts, payload fields, filter results and top-k ordering, and confirm that source identifiers still resolve to the original documents. The output is a dated test report with any mismatches recorded and fixed before the test is closed.
Schedule repeat tests and keep the evidence
The platform owner repeats the export and restore test on a fixed schedule and after each provider or engine upgrade, and stores the results with the contract file. Each run should show the same record counts and query behaviour as before. The output is a test log that the compliance team can present when the organization asks how it would leave the provider.
Contract terms that close the transfer gap
Standard contractual clauses under Commission Implementing Decision (EU) 2021/914 are one transfer tool, and they are the one most vector database vendors offer by default. They are not a complete answer. The standard contractual clauses decision lets a controller send data to a third country under contract, but the Court of Justice's Schrems II judgment (Case C-311/18) required the controller to assess whether the law of the destination country lets authorities reach the data in a way that undermines those clauses. Ask the vendor for its written transfer impact analysis and for the list of sub-processors that can touch embeddings, logs and backups, including support staff who may view data on screen from outside the EEA.
The harder problem is compelled access. EDPB Recommendations 01/2020 state that where a cloud provider must access data in the clear and the destination's public authority powers go beyond what is necessary and proportionate, the EDPB cannot envision an effective technical supplementary measure. A contract cannot override a court order, so the contract must limit the damage: notice to the controller where legally permitted, challenge of overbroad requests, and data minimization. Before choosing a US-controlled provider, assess exposure under 18 U.S.C. 2713, which reaches data in the provider's possession, custody or control wherever it is stored, and under GDPR Article 48, which recognizes foreign disclosure orders only where an international agreement is in force. Document that analysis as part of the controller's transfer file.
The architectural answer is to make the provider unable to read the data. Prefer deployments where the vector store runs in the organization's own cloud account or data center, and where encryption keys are generated and held in a key management system the organization controls, so the provider never holds plaintext keys. Confirm with any vendor whether embeddings are encrypted at rest with customer-held keys, whether the vendor's support model requires access to the cluster, and who operates the keys during an incident. Ask for these answers in writing and keep them in the contract schedule, because a contract that describes controls the vendor cannot actually enforce will not satisfy an assessor.
How DeployOpen scopes and builds a sovereign vector store
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own cloud accounts, data centers or air-gapped networks. For EU data sovereignty, that means fixing the data flows, hosting location, access paths and evidence in a written scope before any vector store is deployed.
How we scope
- Map which personal and business documents feed the embedding pipeline and where each vector is stored.
- Record every transfer path, including remote administration and support access from outside the EEA.
- Agree the written scope, deliverables and timeline with you before any work starts, as engagements are fixed-scope.
How we build
- Deploy the chosen engine such as Qdrant, Milvus or pgvector in your EU infrastructure with authentication and TLS enabled from the start.
- Configure per-collection permissions, block-level storage and replication sized to your own quorum and recovery rules.
- Document the embedding model's data flows, including where model calls run and which logs and payloads are retained.
How we hand over
- Deliver architecture diagrams, data flow records, access matrices and configuration baselines for your own review.
- Test backup and restore, deletion of vectors when source records change, and audit log output before handover.
- Provide runbooks for operators, upgrade procedures and a list of evidence to give your auditors or data protection officer.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer when your team wants us to keep operating the store.
- Re-test access controls and restore procedures after each upgrade or change to the embedding pipeline.
- Ask your legal counsel to confirm transfer assessments, since DeployOpen prepares controls and evidence but does not issue audit reports or legal opinions.
