Trust

Most “EU AI” claims survive until the security review. That is when the questionnaire arrives: where does data rest, who can query the training pool, what does your audit log cover. Opero is built for that review — hosted in EU member states, no training pool exists, every retrieval and every action is logged, and access controls filter before the model sees a single document.

EU hosting

Opero runs on EU infrastructure, under GDPR jurisdiction. Your corpus is stored, indexed and retrieved inside the EU, and traffic between your systems and Opero stays within the EU network perimeter. The one place that can reach beyond it is the model call itself: inference runs on EU endpoints by default, and it stays on them wherever your data-processing agreement requires it. Where a DPA places no such restriction, a request may be served by a provider endpoint outside the EU. Every provider that can appear in that path is named in the subprocessor list below, and Models and routing sets out how the choice is made. If your regulator requires data to remain in a single country — a common requirement for German Mittelstand and Danish financial customers — you can pin your deployment to one region at contract time. The pinning is enforced at the infrastructure layer, not by policy alone. Sovereign and on-prem deployment options are also available for customers operating under stricter mandates: a private installation typically goes live in 4–6 weeks from contract.

Data residency, retention, isolation

Every customer runs in a dedicated tenant. Your corpus, your conversation history and your metadata are not pooled with other customers’ data at any layer of the stack. Retention periods are configurable per contract — set the window your compliance team requires and data is purged on schedule. We do not train models on customer data. Opero grounds an LLM against your documents at retrieval time: when a technician asks a question, the system retrieves the relevant chunks from your corpus and passes them to the model as context. Nothing from your corpus enters a training pipeline. There is no training pool from which fragments of one customer’s service manual could surface in another customer’s answer.

Audit log

Every retrieval, every cited source, every outbound action — PO draft, ticket update, work-order note — is logged with the calling user, timestamp and model version. The log is append-only and scoped to your tenant. When a procurement auditor asks what your system did on a specific date six weeks ago, the answer is in the log: which user triggered the query, which documents were retrieved, what version of the model responded, and what action — if any — was written back to your ERP. The log is replayable. You can reconstruct the exact retrieval that generated a given answer, which makes the log usable in formal audits, not informal retrospectives.

Permissions and ACLs

Access controls are role-based and per-document. A field technician’s retrieval is scoped to the documents their role is permitted to read. A sales engineer’s retrieval is scoped differently. The filter runs before the model sees any candidate documents — not after generation. Post-generation filtering is how leaks happen: the model has already read the restricted document and may paraphrase it even if the output is then suppressed. Opero’s retrieval layer enforces the permission set at query time, so the model is never given material the calling user is not cleared to see.

Models and routing

You choose which models run. Opero routes across the frontier providers — Anthropic Claude, OpenAI GPT and Google Gemini — and the set enabled for your tenant is set at contract time, not left to a default. If your security review rules out a provider, it is switched off for your tenant and the router never reaches for it. Model choice is a configuration, not an architectural commitment: when a provider ships a better model, you move to it without rebuilding the knowledge base underneath.

Routing is per task, not per company. A retrieval question, a document extraction and a drafted reply do not need the same model, and the router picks on capability and cost rather than sending everything to the largest option. Every answer records which model version produced it, so the audit log above can replay a specific response against the model that actually generated it.

Inference runs on EU endpoints by default. Whether it can ever leave them is settled by your data-processing agreement rather than by us: where the DPA requires EU-only processing, routing is held to EU endpoints and a request will queue or fail over within the EU rather than cross the boundary. Where the DPA does not require it, the router may use a provider endpoint outside the EU. Ask for this to be written into the DPA if it matters to you — most regulated customers do, and it costs nothing to set.

No model provider trains on your data. That is contractual with each provider, and it is also structural: Opero passes retrieved chunks as context at query time, so your corpus is never submitted as training material. Model inference is a named category in the subprocessor list below — if a provider is in the path for your tenant, it is on that list, and you can review it before signing.

Integrations and access

Opero connects to the systems you already run — ERP, CRM, document stores, service desks, chat and mail — and reads them in place. It does not require a migration, and it does not become the system of record. Where a connector does not exist yet we build it; the typical timeline is two to four weeks. The current surface is listed on the Integrations page.

The part that matters for a security review is what happens to permissions. A connector inherits the access rules of the system it connects to rather than flattening them. If a technician cannot open a document in SharePoint, Opero will not retrieve it for them, and the filter runs before retrieval for connected sources exactly as it does for uploaded ones. Connecting a new source does not widen anyone’s access; it only makes the access they already had searchable.

Outbound actions are held to a tighter standard than reads. Anything that writes back — a purchase order, a ticket update, a sent reply — is scoped to what the calling user is permitted to do in the target system, and the actions that carry commercial weight require an explicit confirmation rather than firing on the model’s judgement alone. Each one lands in the audit log with the user, the timestamp and the model version attached.

Subprocessors and certifications

Current certifications: GDPR-aligned by design, with documented data-processing agreements available on request. SOC 2 Type II audit is in progress. The subprocessors list — covering infrastructure, model inference and support tooling — is maintained at #subprocessors and will move to a dedicated page as the list stabilises. If you need the current list for a security review, contact us and we will send it directly.

Where to look next

• Knowledge Agent — the system this trust posture protects.
• Building a knowledge agent your technicians actually trust — the long-form on operational trust.
• How EU-hosted AI changes procurement conversations — the procurement framing.