Your documents stay in the EU
Content lives in a database in the EU, isolated per organisation. What leaves is the question and the retrieved passages — to models we hold contracts with. The exact breakdown is in the Data residency section; we don't hide it.
Content in an EU database
Documents, indexes and backups sit in MongoDB Atlas in Frankfurt, isolated per organisation by a condition on every query. They aren't public and aren't indexed by the internet.
No public AI
We never use public consumer AI. Zero retention and no training on your data is being confirmed contractually with both providers — Anthropic (generation) and Voyage via Atlas (embedding and reranking).
AI is only a helper
The language model answers strictly from retrieved passages of your content (RAG) and attaches a source citation.
Cloud today, on-prem in preparation
Today we run cloud with the database in the EU. A fully on-prem mode, where data never leaves your perimeter, is designed and the adapters are written — it has not been deployed yet. The full data-flow breakdown is in the Data residency section.
Where your text actually goes
Not where the data rests, but where it gets processed. That distinction decides whether you pass procurement — and most vendors leave it out.
1 · Data at rest in the EU
Database, indexes and backups sit in the EU. Calling AI models abroad is permissible under a processing agreement and standard contractual clauses.
ordinary commercial deployment
2 · Nothing leaves the EU
The models run in the EU too — including the questions your people type. Not a GDPR requirement, but it does appear in tender conditions.
public sector, larger companies
3 · Nothing leaves the perimeter
The whole system runs on your infrastructure. Without outbound connectivity, if required.
classified material, closed networks
Level 1 is legally sound — GDPR does not forbid transfers outside the EU, it conditions them. But when a tender says “data must not leave the EU”, that is an organisational requirement no contract can satisfy. A vendor who can only offer level 1 gets excluded on form, not on merit.
Modes we can deploy
The mode is a property of your organisation, not of our edition. Same application, different configuration — and a disallowed combination simply refuses to start. The mode running today is eu-data; the other three are written in code and the first deployment comes with the hardware.
| Mode | What it means | Embedding | Rerank | Generation |
|---|---|---|---|---|
| eu-data | Data in the EU, processing may be outside | MongoDB Atlas | MongoDB Atlas | Claude API |
| eu-full | No text leaves the EU | own service | own service | own model |
| on-prem | Everything on your infrastructure | own service | own service | own model |
| air-gap | Closed network, no outbound connectivity | own service | own service | own model |
The second question: does it run for us alone?
The mode above says which country processes your text. It does not say whether that processing happens on a machine reserved for you, or on a service that is serving other customers at the same moment. These are two independent questions and the system checks both.
| Level | What it means | When it makes sense |
|---|---|---|
| T1Shared | Shared infrastructure. Your documents are separated by access rules, but the model processing them also serves others. | standard commercial deployment, small and mid-sized companies |
| T2Dedicated | Embedding, reranking and generation run on instances that serve no one else. Your text never passes through a shared process. | banks, large enterprises, sensitive internal policies |
| T3Disconnected | Dedicated, plus no outbound connectivity. Requires air-gap mode — otherwise the disconnection exists only on paper. | classified material, closed networks |
Levels combine with modes; they are not steps on a single scale. A shared service can run entirely inside the EU (T1 + eu-full), and a dedicated instance can sit anywhere (T2 + global). And one thing most vendors will not say out loud: a dedicated cloud account is not dedicated hardware. That is why Claude via AWS Bedrock does not pass at level T2 even though it runs in Frankfurt — the model there serves everyone else too.
Where processing happens — including what we are still verifying
Every row is backed by the vendor's own public documentation, not by an estimate. Components processing outside the EU are not used in the eu-full, on-prem and air-gap modes — a profile with such a combination refuses to start.
| Component | Provider | Processing location | Basis |
|---|---|---|---|
| Database, indexes, backups | MongoDB Atlas | EU (Frankfurt) | region chosen when creating the cluster |
| Hybrid search | mongot in cluster | EU (Frankfurt) | computed inside the cluster |
| Reranking | $rerank (Voyage) | outside the EU (US) | stated in Atlas project settings |
| Embedding | Atlas Automated Embedding | outside the EU (US) | MongoDB subprocessor list: Google LLC, United States |
| Answer generation | Anthropic Claude (direct API) | outside the EU (US) | processed in US infrastructure |
| Answer generation | Claude via AWS Bedrock (EU regions) | EU (Frankfurt, Ireland, Paris) | region chosen at deployment |
| Legislation catalogue (Slov-Lex) | MongoDB Atlas — one copy for all organisations | EU (Frankfurt) | official works without companyCode; what an organisation subscribed to is its own record |
| Live source (MCP connector) | a server the organisation connects (e.g. Sportnet) | depends on the server operator | optional; the question goes out, not documents; in eu-full, on-prem and air-gap only a server on your infrastructure |
| Embedding, rerank, generation | own services (on-prem) | your infrastructure | runs at your site |
Why we spell this out in such detail. Because someone in procurement will ask. Most vendors state “data in the EU” and stay silent about where the model runs — yet that is exactly where the question and the retrieved passages go. Every row above is backed by the vendor's own documentation, and if the situation changes, so does this table. And here is the open point we don't hide: written zero-retention confirmations are still being finalised with Anthropic (generation) and with Voyage (embedding and reranking via Atlas), where the exact processing region is not yet confirmed either.
This page is a technical description of data flows, not a legal assessment. For a specific deployment we recommend review by a data protection specialist.
User management and sign-in
Users sign in via your existing SSO and see exactly what they're entitled to — with no manual account creation.
SSO and single sign-on
Sign in with an e-mail link or via SSO — Microsoft Entra ID and Google Workspace. One canonical session across the whole system; further OIDC providers can be added.
Automatic account provisioning
A person is created on first SSO sign-in if they belong to a domain the organisation has allow-listed. People can also be bulk-imported from a list and invited by e-mail. Roles are assigned in the app; syncing roles and groups from a CRM is in preparation.
Multi-tenant access
Each organisation is its own space on its own domain. Public content is visible to every signed-in person; internal only to people of that organisation. A multi-level hierarchy and per-document sharing with another organisation are in preparation.
Security at query level
An access right is a mandatory filter derived from the server-side session (default-deny). It is applied before the language model — it cannot be bypassed by a prompt. Audit on every change.
Supported identity providers
What the data protection officer controls, and what we have checked
Data residency says where text is processed. This says what is stored about people, who decides it and how we checked that it holds.
Personal data protection in the product
- Every regulation has a person responsible and a legal basis from a code list. A regulation can have several bases; legal obligation takes precedence.
- The data protection officer (DPO) has a dedicated page: a report of legal bases with search and export, retention periods and the organisation's contact.
- A signed-in person files an objection directly on the privacy page. The DPO is notified and decides; the decision stays on record.
- The privacy page is assembled per organisation: the country of its seat determines the authority and laws, and the list of processors matches what the organisation actually uses.
- The AI usage overview does not store the question text — it may contain personal data. Purpose, person and time are enough to control costs.
- A closed helpdesk ticket is deleted 24 months after closing, and a person from the help window after 24 months without a question; the organisation can change the period alongside the other retention periods. The privacy page describes the helpdesk only when the organisation uses it.
- Every MCP connector call leaves a trail — connector, tool, who triggered it, duration and result — without the question text. The question goes to the connector's server, not the library's documents.
- Courier (internal messages) has a thread deletion period the organisation sets alongside the other retention periods; an admin cannot read other people's messages, the assistant does not search them, and the audit records who, to whom, when and the subject — not the text.
- The helpdesk history analysis runs without storing message text: it keeps a monthly summary, time to reply and topics; the origin of a proposal is deleted when it is decided.
- Consent to connecting an AI assistant over MCP is an evidence record with the exact wording in the language the person saw; it is revoked in the account sheet, and the people admin sees everyone's connected apps.
Code security review (September 2026)
Before the first production release we went through the application code, dependencies and configuration. Every point below was verified directly in the code.
Organisation in every query
The organisation code is in the condition of every read and write, not in a check above it. A search without an organisation is rejected.
Everything protected except exceptions
The route list is “everything except public”, so a new page is protected automatically. An unknown domain gets a 404.
The server sets the evidence
The wording, statement and language of an acknowledgement are set by the server, not the browser. Acknowledgements are never deleted; a revocation is a new entry.
Secrets encrypted
Organisations' sign-in secrets and the AI key are stored encrypted (AES-256-GCM). There are none in the repository.
Security headers
The portal cannot be embedded in someone else's frame — a spoofed click on “I confirm” would be especially bad for a regulation.
File type from content
An uploaded file's type is determined from its content, not from what the browser claims. Exports are protected against formula injection.
This is our own review, not an independent audit or certification. An independent penetration test is a step that will come with further customers.
Ready to get your content at your fingertips?
We'll show you Contineo on your own sources.
Get in touchoffice@contineo.app