Choose the model.
Keep the data.
Data sovereignty means your data is not bound to an engine. AI sovereignty means your organisation decides which model runs, where it runs, what it is allowed to see, and holds the evidence of every call. It is the same independence, one layer up, and it rests on the governed tables underneath: a model can only answer safely from data whose lineage and classification you hold.
Three choices that must stay yours
Choose the model
One interface in front of the providers, so the choice of model is yours and revisable: a cloud vendor today, an open-weight model in your own environment tomorrow, without rewriting the pipelines that call it.
Choose where it runs
Scheduled pipelines can run entirely on a local model on your own host, so nothing leaves your network. Interactive use can go to a cloud model, in the country or region you pick where the provider offers it. Nothing here is specific to one jurisdiction.
Choose what it may see, and keep the evidence
Prompts are checked before they go out and responses on the way back; every traced call lands in observability you host; a cost ceiling is enforced before the call, not after the invoice.
One interface, nine providers
Every provider below is behind the same interface in our code today, with the status stated plainly. “In use” means it runs in our own deployment; “wired” means implemented and routable, not exercised daily.
| Provider | Where inference runs | Status in our code |
|---|---|---|
| Google Gemini | Cloud API | In use — default for interactive work in our own deployment |
| Local models via Ollama | Your host | In use — default for every scheduled pipeline run; nothing leaves the network |
| AWS Bedrock | Your AWS account | Wired — with regional inference profiles where AWS offers them, so inference stays in the region you choose |
| OpenAI | Cloud API | Wired — used as the reviewing model in one of our paths |
| Anthropic | Cloud API | Wired |
| Azure OpenAI | Your Azure tenancy | Wired, including managed identity |
| Google Vertex AI | Your Google Cloud project | Wired |
| Open-weight models via Fireworks (DeepSeek, Qwen) | Cloud API | Wired |
| Alibaba Cloud Model Studio | Cloud API | Wired |
| Databricks model serving | — | Not built. On the roadmap. |
| Snowflake Cortex | — | Not built. On the roadmap. |
What the layer controls
Each row is a capability we verified in the code on the day this page was written, with its scope stated.
| Control | What it does | Status |
|---|---|---|
| Model choice is configuration, not code | Provider and model are read from a configuration table in your own database, then environment, then defaults. Changing the model is a row update, not a redeploy. | Built |
| Two policies: scheduled and interactive | Airflow tasks and interactive use are governed separately. In our deployment, scheduled work defaults to a small local model; interactive work to a cloud model. Either can be set to off: a kill switch that refuses every call. | Built |
| Local-only mode | A single setting routes every call to a model on your own host. That is the path for data that must not leave the network. | Built |
| Prompt and response guardrails | On the pipeline-generation path: personal-data patterns are removed from prompts before they leave, AWS Bedrock Guardrails are applied when configured, and responses are validated on return. | Built — on that path; not yet universal |
| Tracing you host | Calls are traced with OpenTelemetry into an observability stack you run, with model, tokens and latency per call. | Built — enabled per module, not yet platform-wide |
| Cost ceiling before the call | A daily budget is checked before a request is sent; when it is exhausted, the call is refused rather than billed. | Built — per deployment, not yet per tenant |
| Second-model review | Optionally, a second model reviews the first model’s output before it is used. | Built, off by default |
| Cloud adapters | One model interface implemented for AWS, Azure and Google Cloud, so a customer in one cloud can still point at a model in another. | Built |
| Gated by governance | Requests can be gated against a control catalogue before they reach a model, returning allow, allow with conditions, block or escalate, with citations. | Built; see below |
Gated by governance
Before a request reaches a model, it can be checked against a versioned catalogue of regulatory and industry controls. The gate returns one of four decisions and cites the control text it relied on, so a person can check the citation rather than trust the model.
Allow
The request is within policy for the data it touches.
Allow with conditions
Proceeds with a stated condition, for example a redaction or a disclaimer, recorded with the decision.
Block
Refused, with the control cited verbatim.
Escalate
Handed to a person, with the reasoning and the citations attached.
The gate is only as good as the data classification beneath it, which is why it sits on the governed tables from Data Sovereignty. Storing every decision as an audit row is on the roadmap; today the decision and its citations are returned with the response. The control catalogue and the gate in detail →
Built on governed data.
Prove first, claim after.
The data-sovereignty notes show a build with numbers. This layer will get the same treatment: a build on our own environment, measured, with what broke. Until then, this page lists capabilities, not results.
Provider names are trademarks of their respective owners: OpenAI, Anthropic, Google, Amazon Web Services, Microsoft, Alibaba Cloud, Fireworks AI, Databricks, Snowflake. DATAP.AI is not affiliated with, endorsed by or sponsored by any of them. Capabilities describe our own code as of September 2026 and may change. Regional inference, guardrails and identity features depend on what each provider offers in a given region.