Enterprise

Enterprise AI on your terms

One agreement covers 700+ models, you choose where Opper runs,
from our European platform to your own cloud or datacentre.

See pricing

Trusted by 50k+ developers and companies serving 10M+ users

The challenge

AI is business-critical before governance catches up

One agent works most of the time, and nobody can say why it got the rest wrong, what it was sent, or what it cost. Multiply that by every team that wants to build with AI.

Quality nobody can measure

The people who see the bad outputs are product owners and domain experts, and the only way they can act on them is a ticket to a team that owns the codebase, so weeks pass between spotting an error and fixing it.

Control nobody can prove

When legal asks which model handled a case, where it ran, and what was sent to it, the answer has to be assembled by hand from application logs, and the project sits in review until somebody does.

Teams either blocked or unguarded

Every team wants to build with AI, and without shared infrastructure the choice is to slow them down with process or let them move without guardrails, which is why AI adoption stalls at the second team.

Spend nobody can attribute

Model spend arrives as one invoice with no breakdown by team, product, or use case, so finance cannot forecast it and nobody can tell an expensive experiment from a business-critical workload.

The Opper Way

What Enterprise gives you

Everything in the control plane, wrapped in the deployment, contracts, and commercial terms a large organisation actually runs on.

Deploy Opper where your data has to live

Most customers run on the shared European platform in AWS Stockholm and never think about it again. When a workload cannot sit on shared infrastructure, the same Opper runs as a dedicated instance on its own address, inside your own cloud account, or in your own datacentre, and your teams build against the same API either way.

Dedicated instances on a region and domain you choose
Your own cloud account or your own datacentre

European platformDefault

AWS Stockholm, eu-north-1

Dedicated instanceIsolated

yourcompany.on.opper.ai

Your cloudYour account

Your AWS, Azure, GCP, or sovereign cloud

Your datacentreOn-premise

Your hardware, your network

The same API surface on every option

One agreement that already covers your next model

Adopting a model provider directly means another vendor review, another DPA, and another line on the sub-processor list your customers have to be notified about. Routing through Opper turns all of that into one agreement, so a team can move to a better model the week it ships instead of the quarter after.

One DPA covers 700+ models
No amendment when a team adopts a new model

See security and compliance

What your legal team receives:

Data Processing AgreementPublished

Sub-processor listPublished

Platform security overviewPublished

Standard Contractual ClausesOn request

Zero retention termsOn request

One agreement, whichever models your teams pick

Commercial terms built around your volume

Enterprise agreements replace the self-serve checkout with what procurement needs, so you get an annual commitment with volume pricing, invoicing against a purchase order, and no per-seat charges as adoption spreads. Token rates stay at provider rates with nothing added on top, and bringing your own provider keys keeps existing cloud commitments in play.

Annual commitments, volume pricing, and invoicing
Your own provider keys and existing commitments

See how pricing works

Token ratesProvider rates, no markup

Platform feeNegotiated on volume

CommitmentAnnual, with volume pricing

BillingInvoice against a PO

SeatsNot charged

Your provider keysSupported, per agreement

Current self-serve rates are on the pricing page

Give every team AI without becoming the bottleneck

Central teams usually pick between slowing everyone down with review and letting teams ship without guardrails. Opper gives each team its own project with a model allowlist, a budget cap, and its own keys, so the guardrails are set once centrally and teams move at their own pace inside them.

Model allowlists and budget caps per team
One place to see what every team is spending

Explore the control plane

claims-automation€4,000 / mo

EU routes only · 68% of budget used

developer-tools€9,500 / mo

All frontier models · 41% of budget used

support-copilot€1,200 / mo

ZDR routes only · 87% of budget used

Guardrails set centrally, teams ship at their own pace inside them

Commitments you can hold us to

Enterprise plans come with an SLA, dedicated rate limits, and a shared Slack channel with the Opper team. Routing across the providers in your fallback chain means one provider having a bad day does not become your outage, and measured availability is published per route rather than described.

SLA, dedicated rate limits, and a shared Slack channel
Automatic failover across your fallback chain

See live provider uptime

UptimeContractual SLA

Rate limitsDedicated limits

SupportShared Slack channel

EscalationDirect escalation path

Provider outageAutomatic fallback

Measured availability is published per route on the status page

Data handling

Two retention questions, two answers

Whether prompts and completions are stored is really two separate questions, one about Opper and one about the model provider, and they are answered in different places.

What Opper stores

By default, metadata only: model, tokens, latency, and cost. Prompt and completion content is not retained.
Full tracing is something you turn on with the Control Plane, with retention configurable per project.
Enterprise agreements can specify zero retention.
Opper never trains on your data.

What the model provider stores

This varies by route, so retention is published per model and provider rather than described in general terms.
Retention periods vary, from none at all to a fixed abuse-monitoring window, and none of the listed providers train on it by default.
Zero data retention routes keep nothing once the response is served, on by default for some routes and arranged under an Enterprise agreement for others.

Enforced once, not per project

Checking retention model by model does not survive contact with a dozen teams. A ZDR-only allowlist restricts every project to routes that retain nothing, so the rule is set centrally and holds across the organisation, and a team cannot opt out of it by picking a different model.

Deployment

Four ways to run Opper

The same gateway, the same control plane, and the same model catalogue, placed wherever your data and your auditors need it to be.

European platform

Default

Where it runs: AWS Stockholm, eu-north-1
Infrastructure: Opper's EU account

EU residency with nothing to run or patch, the default for most customers.

Dedicated instance

Where it runs: A region you choose, on its own address such as yourcompany.on.opper.ai
Infrastructure: Opper's account

Isolation from other tenants, your own domain, and a region picked for your data.

Your cloud

Where it runs: Your AWS, Azure, GCP, or sovereign cloud account
Infrastructure: Your cloud account

The infrastructure has to sit inside your own contracts, controls, and cloud commitments.

Your datacentre

Where it runs: Your own hardware, on your own network
Infrastructure: Your network

Workloads that cannot depend on infrastructure outside your perimeter.

Option	Where it runs	Infrastructure	Why you would pick it
European platformDefault	AWS Stockholm, eu-north-1	Opper's EU account	EU residency with nothing to run or patch, the default for most customers.
Dedicated instance	A region you choose, on its own address such as yourcompany.on.opper.ai	Opper's account	Isolation from other tenants, your own domain, and a region picked for your data.
Your cloud	Your AWS, Azure, GCP, or sovereign cloud account	Your cloud account	The infrastructure has to sit inside your own contracts, controls, and cloud commitments.
Your datacentre	Your own hardware, on your own network	Your network	Workloads that cannot depend on infrastructure outside your perimeter.

Assurance

What your reviewers will ask

The questions that hold an AI project in review, and where the answer comes from when every call goes through one gateway.

The question	Where the answer comes from
Where personal data is processed	The platform runs in AWS Stockholm, region and retention are published for every model and route, and routing can be restricted to European routes centrally rather than trusted to each team.
Transfers outside the EEA	Route selection decides it, European routes are served from European infrastructure, and Standard Contractual Clauses are available on request alongside the DPA.
Which model produced an output	Every call is recorded with the model that served it, the cost, the latency, and the policies that applied, and sessions group those calls into the conversations users actually had.
Operational resilience	Requests fail over across the providers in your fallback chain, budgets and rate limits are enforced per team, and measured availability is published per route on the status page.
Dependency on outside services	A dedicated instance takes shared tenancy out of the request path, and own-cloud or on-premise deployments go further, keeping operational data inside infrastructure you control.
Vendor security review	The security overview, the DPA, and the sub-processor list are published, and Enterprise agreements can add tailored terms including zero retention.

Stakeholders

What each part of the business gets

An AI platform has to be signed off by more people than it is built by, so here is where each of them should start.

Role	What they need	Start here
CTO and Head of Engineering	One architecture every team builds against, adopted by changing a base URL rather than rewriting applications.	The control plane
CISO	PII masked before it reaches a model, guardrails enforced in the infrastructure, and an audit trail that does not depend on application code.	Security and compliance
CFO	Provider token rates with no markup, a platform fee negotiated on volume, spend attributed per team, and invoicing against a purchase order.	How pricing works
Legal and DPO	One agreement covering every model, residency documented per route, and a DPA that does not need amending when a team adopts a new model.	Read the DPA
Product and AI leads	Quality measured on every generation and improved through steering, so fixing an output does not start with a dev ticket.	How steering works

FAQ

Enterprise FAQ

What does Enterprise add on top of the Control Plane?

Enterprise keeps everything in the Control Plane and adds the things a large organisation needs around it: SSO and SAML, audit logging, zero-retention terms negotiated per route, dedicated rate limits, custom hosting regions and self-hosted deployments, an SLA, a shared Slack channel, and commercial terms with invoicing instead of a card.

Can Opper run in our own cloud or our own datacentre?

Yes. Opper runs as a dedicated instance in a region you choose, inside your own AWS, Azure, GCP, or sovereign cloud account, or in your own datacentre. Your teams use the same API and the same model catalogue whichever option you pick, so the deployment decision does not change any application code.

How is Enterprise priced?

Enterprise replaces the self-serve platform fee with terms negotiated for your volume, on an annual commitment, invoiced against a purchase order. Token rates stay at provider rates with no markup, and there are no per-seat charges as adoption spreads across teams. Current self-serve rates are published on the pricing page.

Do we keep our own provider relationships and keys?

Yes. Opper supports bringing your own provider keys, so you keep the contracts you have already signed and any committed spend you have with Azure, AWS, or a model provider keeps being drawn down while the traffic still flows through Opper for routing, governance, and observability.

What does Opper itself store?

By default only metadata such as model, tokens, latency, and cost, with prompt and completion content not retained. Full tracing is something you turn on rather than something you turn off, retention is configurable per project, and Enterprise agreements can specify zero retention. Opper never trains on your data, and the detail is in the security and compliance overview.

What does the model provider retain, and can zero retention be enforced across the whole organisation?

That depends on the route, which is why retention is published per model and provider in the directory. Retention periods vary by provider, from none at all to a fixed abuse-monitoring window, and none train on it by default. Zero data retention routes keep nothing once the response is served, on by default for some routes and arranged under an Enterprise agreement for others. Rather than checking this model by model, a ZDR-only allowlist restricts every project to routes that retain nothing, so the rule is set once centrally and holds for every team.

Which documents do you provide for a vendor security review?

The Data Processing Agreement, the sub-processor list, and the platform security overview are published on opper.ai and can go into a review without waiting on us. Standard Contractual Clauses are available on request, and Enterprise agreements can add tailored terms including zero retention.

Do you support SSO, audit logging, and role-based access?

Yes. Enterprise plans include SSO and SAML so access follows your identity provider, and audit logging records user actions for compliance. Access, model allowlists, and budgets are scoped per project, so each team gets what it needs without seeing everyone else's traffic.

What happens when a model provider has an outage?

Requests fail over to the next route in your fallback list automatically, and you are only billed for the successful response. Because routing is central, moving a workload onto a different provider is a rule change rather than a redeploy, and the public status page publishes measured availability per route.