Every request to a language model is a small act of trust. You put a customer’s question, a contract clause, a network log or a draft article into a text field, and you send it away to be read by a machine you do not operate. The machine reads it, produces an answer, and somewhere a record of the exchange exists for a while.
Most discussions about inference are about the machine: which model, how capable, how fast. We think the more consequential question is the one nobody puts on a benchmark chart: where did the request go, and whose law applied while it was there?
Infrastructure has an address
Databases, message queues and object stores taught the industry this lesson a decade ago. Enterprises in Europe learned to ask where the disk was, who held the keys, and which government could compel access. Procurement built questionnaires around it. Regulators wrote it into guidance. Data residency became a checkbox, then a requirement, then a market.
Inference is infrastructure in exactly the same sense. A model server is a process on a machine in a building on a network. It receives data, keeps some of it in memory, sometimes logs it, and sends data back. Every one of those steps happens in a place, under an operator, subject to a jurisdiction.
What changed is that the most capable models arrived as remote APIs operated by a handful of companies, almost all of them under US law. For a while the capability gap made the question feel academic. If the only good model is over there, the question of where “there” is answers itself.
The gap closed
That is no longer where we are. Open-weight models from several labs now sit close enough to the frontier that, for most enterprise workloads, the remaining gap is not the deciding factor. You can download the weights, read the license, and run the model on hardware you choose.
Once that is true, the jurisdiction of your inference becomes a decision rather than a constraint. And decisions get reviewed. A bank’s data-protection officer, a telco’s security team, a ministry’s procurement office: all of them will, sooner or later, ask where the prompts go. The honest answers today are usually one of three:
- To a US provider’s API, under a contract that promises a lot and changes the jurisdiction of nothing.
- To a European reseller or cloud, whose model calls end up on a US provider anyway.
- To servers you operate yourself, if you have the GPUs, the people and the appetite.
We built Zarx because we think there should be a fourth answer, and because we were already living it.
Why paperwork is not the same as a data path
The standard mitigation for cross-border processing is legal: transfer impact assessments, standard contractual clauses, supplementary measures. This is serious work done by serious people, and it is fragile by construction. The legal basis for routine EU to US transfers has been invalidated twice by the Court of Justice of the EU, in 2015 and in 2020. Each time, thousands of organisations had to re-paper what they were already doing.
A data path is different. If the request never leaves servers operated by a Spanish company in Spain, there is no transfer to assess. The question “which foreign law can reach this data” has a short answer. Your DPO still does their job; they just do it on facts instead of on promises.
This is what we mean when we say inference has a jurisdiction. Not that law is the only thing that matters, but that it is a property of the infrastructure, decided by where the infrastructure is and who runs it, and that you should be able to choose it deliberately.
What Zarx does about it
Zarx is an OpenAI-compatible inference API for open-weight frontier models, served from GPUs that NPAW owns and operates in Spain. The servers are ours. The network they sit in is an IPv4 allocation registered to NPAW in the RIPE database. The models are open weights we run with vLLM and SGLang, so there is no remote model API behind the service. For inference, no US provider is a sub-processor because none is in the path.
We do not claim this is a certification, and we do not claim it makes anyone compliant. It is a design. Zarx is designed to help you meet GDPR data-residency requirements and to make the conversation with your regulator shorter. The sovereignty page draws the data path and lists what leaves your systems and what never leaves ours, with a source for each statement.
What we are asking of you
We are opening Zarx to a small number of design partners: teams in banks, telcos, public administrations and media in Europe who run, or want to run, language models in production and need prompts and outputs to stay under EU law. If that is you, tell us what you run inference on today. We will answer with the data path, the models we can serve, and the people who run them.