When you call corti-s1, where does your request go? In an EU project, it runs on hardware we operate in Europe, passes hardware attestation before inference, and returns a response without us storing your prompts or completions. US projects use Azure-hosted OpenAI models under the same IDs, so check the region before you judge the name.
Follow the request
A sovereignty claim has to survive a trip through the infrastructure.
Start with where your request enters. Follow it to the machines doing the work. Check who operates them, how they isolate your workload, and what remains when the response comes back. Each stage should give your security team something it can check.
For an EU project, the path looks like this:
- Your app calls Corti’s EU endpoint through an OpenAI-compatible API.
- The request reaches hardware we operate in Europe, with no US cloud in the processing path.
- Hardware attestation verifies workload isolation before inference.
- The model generates a response.
- The response returns to your app. We never store, log, or train on prompts and completions.
You control the first step. Check your project’s region before sending traffic. The same model ID reaches different underlying models in EU and US projects, so a US evaluation won’t tell you how the EU model performs.
Ask what the evidence proves
“Your data stays in Europe” gives a reviewer a claim to investigate. They still need to know which part of the system enforces it.
Hardware attestation provides evidence about the environment running your workload. Ask what it checks and how your team can inspect the result. Processing location and retention need their own supporting evidence, too. Attestation shouldn’t become a catch-all answer to every security question.
The sovereign cloud overview explains Corti’s hosting approach. Your reviewers can find compliance documentation in the Corti Trust Center.
A download needs work
Published model weights give you something to run. Getting useful, reliable behavior out of them takes evaluation, tuning, and a serving stack.
We evaluate candidates on real workloads and public benchmarks, regardless of which lab released them. We tune inference for latency and throughput, work on coding and structured output, and test releases against defined evaluation suites before shipping them.
Then we operate the service. Hardware, cluster, serving software, and API all sit within the stack we run. The Corti Models documentation explains that work.
The original developer supplies the starting weights. Running those weights on our infrastructure doesn’t send your prompts back to that developer.
The name stays put
You shouldn’t need to follow every upstream release to keep your application running. corti-s1 gives you a stable model ID while we improve what sits behind it.
That convenience comes with a decision: do you want automatic updates, or control over when behavior changes? A stable name doesn’t mean identical outputs forever. If reproducibility matters, Corti supports version pinning by arrangement.
Before you build an evaluation around an ID, check its region and version. The model documentation is the place to start.
