Why EU data sovereignty changes the Copilot decision
An EU organization that must show where personal data is processed, stored and accessed can keep that answer under its own control by running Onyx with self-hosted models in an EU location it operates. In that setup, the document index, prompts, query history and logs stay in infrastructure your team owns, so the residency question moves from a vendor's regions to your own hosting choices. The rest of this page separates three things: what the constraint requires, what Microsoft 365 Copilot and the EU Data Boundary do and do not cover, and what you must confirm in your own environment before you decide.
Start with what the constraint requires. Under GDPR Article 44, every transfer of personal data to a third country, including onward transfers, must meet Chapter V conditions. The EDPB's Guidelines 05/2021 state that remote access from a third country counts as a transfer, even if the data is only displayed on a screen for support or administration, and so does storage in a cloud outside the EEA. Your review should therefore list every party that can view data from outside the EEA, including vendor support staff. The US CLOUD Act provision at 18 U.S.C. 2713 also reaches providers' data regardless of where it is located, so your assessment should cover who can be compelled to disclose it, not only where the bytes sit.
Then confirm the points the supplied facts do not settle. The scope of the EU Data Boundary for the Copilot services and models your tenant would use is not established here, so request Microsoft's written statement on what it covers, including any model providers excluded from it. Confirm where Copilot prompts, responses and audit records are stored and who can export them. If you run Onyx with vLLM, note that the vLLM security documentation says inter-node traffic is insecure by default and that --api-key alone is not enough, so isolate the nodes on a private network and place a reverse proxy in front of user-facing endpoints. These checks determine whether the self-hosted design meets your residency commitments.
What GDPR and the Data Act require for AI processing
Four requirements shape where an EU organization can run an assistant that reads its documents and prompts. Each one turns on where personal and non-personal data sit, who can reach them, and whether you can leave a provider. The cards below set out what each rule asks for and the evidence you should be able to produce.
Transfer conditions for third-country storage
Article 44 of the GDPR requires every transfer of personal data to a third country to meet Chapter V conditions, including onward transfers. Infringements of Articles 44 to 49 can draw fines of up to EUR 20 million or 4% of worldwide annual turnover, whichever is higher. Map every location where an assistant stores indexes, prompts, logs or backups, including vendor sub-processors. Ask each provider to state the region for each category of data, and keep that map with your records of processing.
Remote access and storage count as transfers
The EDPB's Guidelines 05/2021 treat remote access from a third country as a transfer, even when staff only view data on a screen for support. Storing data in a cloud outside the EEA is also a transfer. For an assistant, this covers vendor support engineers, follow-the-sun administration and backups replicated abroad. Ask your provider to confirm which teams can open the index, logs or prompt stores, from which countries, and whether any of that access is logged and reviewable.
Limits on third-country disclosure orders
Under Article 48 of the GDPR, a third-country court or authority order to disclose personal data is enforceable in the EU only when it rests on an international agreement, such as a mutual legal assistance treaty. This matters because the US CLOUD Act at 18 U.S.C. 2713 requires providers to preserve or disclose data in their possession, custody or control wherever it sits. Where a provider cannot offer a location you control, the EDPB Recommendations 01/2020 say no effective technical measure may exist if the authority's powers go beyond what is necessary. Document that assessment before you sign.
Data Act measures against governmental access
Article 32 of the Data Act requires data processing service providers to take technical, organisational and legal measures against third-country governmental access to non-personal data held in the Union, where that access would conflict with EU or national law. The Data Act has applied since 12 September 2025. Ask providers for their written measures, their policy for responding to government requests and whether they notify you of such requests. Keep these answers with your supplier file, because they show how you checked the rule.
Switching rights and exit evidence
Under Articles 25, 29 and 50 of the Data Act, customers may switch to another provider or to on-premises infrastructure, with a maximum two-month notice period and a 30-day transition. Switching charges are banned from 12 January 2027. Before you commit, confirm that you can export indexes, prompts, conversation logs and configuration in open formats, and that the assistant can run on your own infrastructure if you need to leave. Record a tested exit path, not only a contract clause, because the regulator will look for the second.
What the EU Data Boundary covers and where it stops
The EU Data Boundary is a Microsoft commitment about where certain customer data is stored and processed, and the supplied facts do not describe its current scope or exclusions in enough detail to rely on for a decision. Before you assume any Copilot-related data stays in the EU, ask Microsoft in writing which workloads, data categories and Copilot features the boundary covers today, which ones it excludes, and whether any processing still occurs outside the EU. Ask the same question about the Anthropic-hosted models that appear in some Microsoft 365 Copilot options. Confirm in your tenant settings and the Microsoft admin documentation whether those models are enabled, where they run, and whether they can be turned off for your users. Treat the answer as a documented fact for your tenant only after you have checked it yourself.
The legal question does not end at the data center location. Under 18 U.S.C. 2713, the CLOUD Act requires US electronic communication and remote computing service providers to preserve or disclose data in their possession, custody or control, whether that data sits inside or outside the United States. The EU-US Data Privacy Framework rests on Commission Implementing Decision (EU) 2023/1795, but that decision is under appeal as Case C-703/25 P, so an EU organization should not treat the framework as a permanent basis for transfers. Your legal and privacy teams should record which US-linked entities can reach the data and what your contracts say about government requests, and they should review that record again when the appeal is decided.
EDPB Recommendations 01/2020 are direct on the point that matters most. Where a provider needs access to 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. This is why a self-hosted assistant changes the analysis: if your indexes, prompts and logs live in an EU location you operate, and the models run there too, no provider holds the data in the clear for a foreign authority to request. Your next step is to write down, for each Copilot data flow you are considering keeping, who can access it in the clear and under which law. The answer shapes both the self-hosted design and the contract terms you still need from any remaining vendor.
Which open-source options keep processing in an EU location you run
This table compares Onyx Standard, Onyx Lite, Open WebUI, LibreChat and AnythingLLM on where indexes and logs live, identity and permission handling, Microsoft connectors and license terms. Read the check marks as confirmed in the supplied documentation, and treat unconfirmed items as questions for the vendor and your own pilot. The main takeaway is that EU control depends on where you deploy the stack, not on the interface you pick.
| Capability | Onyx Standard | Onyx Lite | Open WebUI, LibreChat, AnythingLLM |
|---|---|---|---|
| Where indexes, database and logs live | Index (Postgres, Vespa or OpenSearch), Redis and object storage run in your chosen location | No vector database or background workers, so less index data to place | Chat history and any RAG store sit in the database you configure; confirm the vector store location |
| Air-gappable deployment | Documented as air-gappable with Docker, Kubernetes, Helm or Terraform | Confirm air-gap support with Onyx before relying on it | Open WebUI documents fully offline use with Ollama; confirm for LibreChat and AnythingLLM |
| SSO and user provisioning | Google OAuth, OIDC or SAML, with SCIM provisioning | Confirm SSO and SCIM options for this lighter deployment | LibreChat supports OAuth2, LDAP and email; confirm SAML and SCIM for each tool |
| Permission sync from source apps | Syncs source permissions so answers draw only on documents the user can see | Confirm whether permission sync is available | Confirm; general document chat tools may not inherit source permissions |
| SharePoint, OneDrive and Teams connectors | Connectors for SharePoint, OneDrive, Outlook and Microsoft Teams are in the repository | Confirm connector availability in the lighter edition | Confirm; document ingestion is supported but Microsoft source connectors need checking |
| Model routing to self-hosted models | Works with Ollama, LiteLLM and vLLM, plus proprietary providers | Confirm the supported self-hosted providers | Open WebUI works with Ollama and OpenAI-compatible APIs; LibreChat and AnythingLLM support Ollama |
| License constraints | Community Edition is MIT; ee directories fall under the Onyx Enterprise License | Confirm which license terms apply to the lighter edition | Open WebUI License adds a branding clause; LibreChat and AnythingLLM are MIT |
How to deploy Onyx with self-hosted models in an EU location
This sequence produces an Onyx deployment whose index, database, model servers, logs and object storage sit in an EU location that your organization operates, with sign-in and source permissions enforced from the start.
Choose the EU hosting location and boundary
Your infrastructure or security team selects the EU cloud account, data center or private hardware that will hold every component, and documents which regions, subprocessors and administrative access paths fall inside the boundary. Confirm with each cloud or hosting provider where backups, snapshots, logs and support access are stored, because these can sit outside the region you chose. The step is done when the boundary diagram names every system that will hold indexed content, prompts or logs, and each one has a confirmed EU location.
Deploy Onyx Standard with the chosen tooling
Your platform engineers install Onyx Standard using Docker, Kubernetes with Helm, or Terraform, based on the orchestration your team already operates. Standard includes vector and keyword indexing, background sync workers, model inference servers, object storage and Redis, so review the deployment overview to size each service before you apply it. The step is done when all Onyx services report healthy and the web interface loads only from inside your network.
Run the database, index and cache inside the boundary
Platform engineers confirm that Postgres, the index engine (Vespa or OpenSearch, as documented for Onyx), Redis and the model servers run in the EU location with persistent volumes in the same region. Record which index engine you chose, because it determines backup and restore procedures. The step is done when a test document indexed through the platform is visible only in the EU storage volumes and nowhere else.
Serve models with vLLM or Ollama in the EU
Your ML platform team hosts the chosen open-weight model on GPUs inside the same boundary, using vLLM for OpenAI-compatible serving or Ollama for smaller deployments, and points Onyx at that endpoint. For vLLM, keep each multi-node run on an isolated network, because the vLLM security documentation states that inter-node communication is insecure by default with no authorization or encryption. Put the vLLM server behind a reverse proxy that allowlists only the endpoints users need, since the --api-key option does not cover every route (including /metrics and /health). The step is done when a prompt sent through Onyx is answered by the EU model and the proxy rejects requests to unlisted paths.
Connect sources with permission sync
Your administrators add connectors for the content repositories that must be searchable, such as SharePoint, OneDrive, Confluence or Google Drive, using service credentials scoped to read-only access. Confirm that permission sync is enabled for each connector, so answers draw only on documents the requesting user can already open in the source system. Test with two accounts that have different access rights. The step is done when each account returns only the documents it is entitled to see.
Configure SSO with OIDC or SAML and SCIM
Your identity team connects Onyx to the organization's identity provider through OIDC or SAML and enables SCIM user provisioning so accounts and group changes follow joiner and leaver events. Confirm that role-based access control in the Enterprise Edition is considered if you need it, since it is listed among premium features. The step is done when a deprovisioned test user loses access to the interface and to the connector data they could previously query.
Confirm log, audit and object storage locations
Your compliance and operations leads verify where query history, usage analytics, application logs, metrics and object storage objects are written, then confirm each location is inside the EU boundary. Review the vLLM metrics endpoint, which exposes Prometheus-format data, and decide whether the monitoring stack stays in the EU as well. Confirm retention periods with your data protection officer, since the platform does not set them for you. The step is done when a written data map lists every store, its location and its owner, and a sample log entry is traced to an EU volume.
Evidence to collect for a data protection review
A data protection review of a self-hosted assistant asks the same questions as any processing review: where data sits, who can reach it, how long it lasts and what the transfer position is. The cards below list the evidence that answers those questions, drawn from the platform layers that you operate. DeployOpen prepares this evidence, but auditors, supervisory authorities and certification bodies issue any assessment or certification.
Data flow and location records
Map every place a question, document chunk, embedding, log line or model prompt is stored or processed: the Onyx index, its Postgres database, Redis, object storage, the model server and any backup target. For each component, record the country and data centre, the operator and the account that controls it. Check that no component silently falls back to a hosted API endpoint, because a single outbound call to a non-EU model provider is a transfer that this record must show. Ask your implementation partner to include the diagram in the handover pack.
Records of processing and transfer assessments
Keep your Article 30 records of processing for the assistant, listing purposes, categories of data, recipients, retention and security measures. If any sub-processor or remote support path sits outside the EEA, document a transfer assessment under Chapter V, including remote access from a third country, which the EDPB treats as a transfer. Record the reasoning for any EU processor subject to third-country law, since EDPB Guidelines 05/2021 say compliance with a foreign authority request would itself be a transfer.
Configuration exports for SSO, permissions and retention
Export the Onyx SSO configuration (OIDC or SAML), SCIM provisioning settings and role assignments, and the connector permission sync settings for each source. Keep dated copies of retention and deletion settings for chats, indexed documents and logs. Reviewers will compare these exports with your identity provider and source systems to confirm that answers only draw on documents each user can already open. Store the exports in a version-controlled repository so changes after the review are visible.
vLLM metrics and access logs
Collect the request counts, token throughput and latency metrics that vLLM exposes at its metrics endpoint, along with reverse proxy access logs. The vLLM security documentation warns that --api-key does not protect every endpoint, including /metrics and /health, so the proxy allowlist is itself evidence. Export the allowlist configuration and show that only the endpoints meant for users are reachable from the Onyx network segment. Confirm the retention period for these logs in your own logging stack.
Onyx query history audit
Onyx lists query history auditing and usage analytics among its enterprise features. Use it to show which users asked which questions, when, and which sources were cited, which supports access reviews and incident investigations. Because query history can contain personal data, document who may read it, how long it is kept and how a user's entries are deleted on request. Confirm with the Onyx documentation for your edition that the feature and its export options are available to you before relying on it in the review.
Questions EU buyers ask before running Onyx themselves
What drives the total cost of running Onyx ourselves?
The total is driven by five components: GPU or accelerator capacity for inference, the infrastructure that hosts the index, database and background workers, implementation work, ongoing operations, and any Enterprise Edition features you need. Onyx Community Edition is MIT licensed, so the software itself has no license fee, but the Enterprise License applies to code in ee directories and covers features such as RBAC. GPU capacity and infrastructure recur every month, while implementation is largely one-time. Model choice moves the balance: a self-hosted model on your own GPUs shifts cost toward hardware, while a proprietary API shifts it toward usage fees. Ask any quote provider to price each component separately, state which Onyx edition is assumed, and list which model servers and index backend are included.
How much time and effort does a self-hosted Onyx rollout take?
Effort depends mainly on how many sources you connect, how many users need permission sync, and how much of the model stack you build yourself. Connecting SharePoint, OneDrive, Outlook, Teams and similar sources means configuring each connector, validating that synced permissions match the source application, and testing edge cases such as shared mailboxes and nested groups. Sizing and procuring GPUs, setting up Entra ID or another identity provider through OIDC or SAML, and hardening the network add further work. Because most DeployOpen engagements are fixed-scope, the schedule and deliverables are agreed in writing before work starts. Ask for a written phase plan with a timeline for each source and a named acceptance test for permissions.
What does our team need to provide for the work?
The work needs decisions and access from your side more than extra software. You will need an owner for the business case and acceptance criteria, identity administrators who can register the application and configure SSO and SCIM provisioning, and source-system owners who can grant read-only connector accounts. Your infrastructure team must provide a cloud account, data center capacity or an air-gapped network segment, plus DNS, certificates, backup targets and monitoring. Security and compliance staff should confirm where logs and indexes may reside and which data classes are excluded. Your team also needs to decide who answers user questions after go-live, because support is a separate line item.
Can our internal engineers run Onyx without outside help?
Some organizations can, provided they already operate Kubernetes or Docker stacks, PostgreSQL, Redis and GPU inference, and have engineers who can keep up with a project that publishes releases frequently. Onyx Lite offers a lighter chat and agents deployment without a vector database or background workers, which may suit a smaller pilot, while Onyx Standard adds Postgres, Vespa or OpenSearch, Redis and model servers. The harder parts are usually permission sync correctness, model serving security and patching cadence. vLLM's security documentation says node-to-node traffic is insecure by default and recommends a reverse proxy that allowlists only user-facing endpoints, so someone must own that configuration. Assess honestly which of these skills you already have before deciding.
Does Onyx Cloud or Microsoft 365 Copilot keep our data in the EU?
Onyx Cloud is a managed service, so where it stores your data depends on the provider's hosting terms, which you should confirm in writing before using it for EU personal data. Microsoft 365 Copilot is built on Microsoft cloud services, and the EU Data Boundary is Microsoft's commitment to store and process in-scope customer data inside the EU and EFTA; verify its current coverage and any exceptions, including model processing, with Microsoft. Under GDPR Article 44 and EDPB Guidelines 05/2021, remote access from a third country and storage outside the EEA are transfers, so both paths need a documented assessment. A self-hosted Onyx stack in an EU location you operate keeps indexes, prompts and logs under your control, but you must still check where any external model API processes requests.
What should we ask a quote provider in writing?
Ask for a written scope listing each source connector, the model servers and serving engine, the index backend and the edition of Onyx assumed. Request a cost breakdown separating one-time work (design, implementation, hardening, testing) from recurring items (GPU or cloud capacity, backups, upgrades, monitoring, support). Ask which features need the Enterprise License and how RBAC and SCIM are covered. Require a statement of where every component runs, where indexes, prompts and logs are stored, and whether any request leaves the EU. Ask how permission sync is tested, what acceptance criteria apply, how upgrades to Onyx and the vLLM serving layer are handled, and which controls DeployOpen prepares as evidence for an independent auditor. Confirm the exit path as well, including data export and the switching terms under the EU Data Act.
How DeployOpen deploys under EU data sovereignty
DeployOpen plans and implements self-hosted open-source platforms inside your own cloud accounts, data centers or networks, so indexes, prompts and logs stay in an EU location you operate. Engagements start with a written scope that names the sources, models, regions and evidence your organization needs.
How we scope
- Written scope names every source to connect, including SharePoint, OneDrive, Outlook and Teams, before work starts
- We map where indexes, prompts, logs and backups will sit, and which processing locations are inside the EU
- We record which model hosting option applies, self-hosted with Ollama or vLLM or a provider you choose, and why
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before any build begins
How we build
- We deploy Onyx with its document index, database and processing services inside your chosen EU environment
- We configure connectors and confirm that permission sync limits answers to documents each user can already see
- We set up SSO and provisioning through your identity provider and test role-based access before users onboard
- We test the model endpoints, restrict exposed API routes and document which logs and metrics are retained
How we hand over
- You receive architecture documentation covering data flows, storage locations, network boundaries and retention settings
- Runbooks cover updates, backups, restore tests and how to add or remove connectors without changing the data boundary
- We prepare the controls and evidence your compliance team or independent assessor will need, without issuing any audit or attestation
- Handover includes a review session with your security, legal and platform teams to confirm open questions
How we support
- Ongoing support, upgrades and continuous security testing are available as retainers after handover
- Retainers can cover patching of Onyx, model servers and Helm chart changes as new releases arrive
- Periodic reviews can recheck data residency settings, subprocessors and transfer assumptions as regulations change
- Confirm response expectations, change control and reporting formats with us in the written scope
