Commercial APIs
Permitted workloads, allowlisted per policy.
Deployment & Sovereignty
Governed AI that runs where your obligations say it must.
Katara was built in the EU, for teams whose regulators, customers, and legal counsel care where data lives, which laws reach it, and which models touch it. Choose the boundary. The governance layer is the same everywhere.
The boundary is a deployment tier, not a policy exception.
Katara keeps the same access control, retrieval permissions, model traffic policy, tool registry, and audit trail in every tier. The only variable is who owns the metal and where the workload is allowed to live.
01 // Why deployment is a governance question
Access control means nothing if the infrastructure underneath it answers to someone else.
For most software, hosting is an ops detail. For AI over regulated data, it's a legal surface: GDPR transfer rules, sector data-residency requirements, and non-EU legal reach over foreign-owned cloud providers all turn “where does this run?” into a question your DPO has to answer in writing. Most AI infrastructure vendors are US companies on US hyperscalers, and their answer is a standard contractual clause. Ours is a deployment tier.
02 // Three deployment tiers
The same governance layer, three places to run it.
| US | EU Data Residency | EU Sovereign | |
|---|---|---|---|
| Multi-tenant, Katara-managed | ✓ Available | ✓ Available | → Q3 |
| Single-tenant, Katara-managed | ✓ Available | ✓ Available | → Q3 |
| Single-tenant, client-managed (on-prem) | → Q4 | → Q4 | → Q4 |
✓ Available now · → Coming, quarter noted
Updated as of July 9, 2026
03 // The model layer
Sovereignty ends at the model, unless the model is yours too.
Data residency solves half the problem. If every request still exits to a US model API, your inference layer — prompts, retrieved context, outputs — crosses the boundary your deployment tier was chosen to protect. The Katara AI Gateway is provider-neutral by design: route to commercial APIs where policy allows, and to open-weight models (Mistral, Llama-class, or your own fine-tunes) running inside your boundary where it doesn't. Policy decides per workload; the audit trail records the choice either way.
Open-weight models
Models running inside your boundary when policy disallows external inference.
Your fine-tunes
Self-owned model endpoints with the same governance and audit treatment.
Policy and audit
The platform records the routing decision so you can explain why each class of workload goes where.
04 // What every tier includes
The governance layer doesn't thin out as the boundary tightens.
Chunk-level retrieval permissions · policy-checked model traffic · governed tool registry · tamper-evident audit log · exportable evidence for regulatory examination — identical across all three tiers. The only variable is who owns the metal.
05 // Honest FAQ
Questions teams ask before they make the boundary real.
Is an EU region of a US cloud provider “sovereign”?
No, and we won’t call it that. EU-region hosting on a US-owned provider gives you data residency; it does not remove non-EU legal reach over the provider. That distinction is exactly why the Sovereign EU tier exists. If a vendor uses “sovereign” to describe a hyperscaler region, ask them this question.
Which sovereign infrastructure providers do you use?
We’re finalizing the reference architecture with our early-access partners and will publish the provider and sub-processor list before general availability.
Can we bring our own models?
Yes — any OpenAI-compatible endpoint, including self-hosted open-weight models, can sit behind the Gateway with the same policy and audit treatment.
Where is Katara AI itself based?
Katara AI is built and operated from Barcelona, Spain.
Tell us your boundary. We'll meet you inside it.
Share your residency, sovereignty, or deployment constraints and the workflow you need to govern. We'll come back with the tier, the architecture, and the evidence trail it produces.