AI Sovereignty & the EU AI Act

Sovereignty over an AI system (in German: AI-Souveränität) is not a feature you switch on. It is a set of concrete operational questions: where does inference run, where does state live, who holds the credentials, what can the agent reach, and who decides when a human must intervene. Contenox is built so that every one of those answers belongs to the operator — and each answer is a file, a flag, or a grant you can read, version, and revoke.

That matters most where contenox is typically embedded: tool-heavy orchestration, request-processing and analytics chains, scripts and pipelines — the places where an agent’s effects reach real systems and the operator has to account for them.

What sovereignty means operationally

You pick the hosting. Run inference fully locally via Ollama or vLLM — no prompt or response leaves your network — or register a cloud backend against your own account, pinned to a region you choose. Providers are configuration, not architecture: the same chain runs against either.
State stays on your machine. Sessions, configuration, run logs, and captured execution state live in a local SQLite database (~/.contenox/local.db by default). There is no hosted contenox service and no account; telemetry is opt-in and off by default.
Secrets resolve from your environment at request time. Backends reference credentials by environment-variable name (--api-key-env); the value is read when a request is made and never lands in a config file on disk.
Agents see what you grant, not what you have. Every agent-reachable shell gets a scrubbed, least-privilege environment. Chains expose tools through a per-invocation allowlist. Sessions run only inside workspace roots you granted. And for foreign agent code, contenox carries a kernel-enforced, fail-closed sandbox — see the threat model for why that wall is structural rather than cooperative, and the sandbox guide for exactly what it does and does not confine.

Mapping to the EU AI Act’s oversight themes

The EU AI Act (Regulation (EU) 2024/1689) asks, among other things, that high-risk AI systems be designed for effective human oversight — its Article 14 language includes the ability of the natural persons overseeing a system to understand it, to intervene in its operation, and to interrupt it — alongside obligations around transparency, record-keeping (Article 12), and risk management. These are the questions an operator asks anyway before leaving an agent alone with real work; the Act happens to ask the same ones. Contenox does not interpret the Act for you. What it gives you are operator-authored mechanisms that map naturally onto those themes:

Oversight theme	Contenox mechanism
Human oversight — a person can intervene in or interrupt the system’s operation	HITL policies as human-in-the-loop checkpoints: authored allow/approve/deny rules evaluated before any tool call executes, failing closed to approval when nothing matches. The durable approvals inbox checkpoints an unanswered ask instead of timing out — the question waits for a human, and answering it from any terminal resumes the run exactly once. Attention bounds state who may answer an escalated question: a human by default, an agent only if the envelope says so, and only a bounded number of times.
Traceability and record-keeping	The audit trail is local and readable: `contenox state` inspects the captured execution state of past runs — per-task steps, handlers, transitions, and timings per request. `--trace` emits structured operation telemetry on stderr. Durable asks record who answered — and whether it was a person or an agent. Chains and policies are plain versioned files, so the configuration that produced a run is diffable.
Risk controls	Authored deny rules and condition operators (path globs, host matching, command blacklists, substitution detection) in the policy file. An LLM moderation gate as an ordinary chain step, on a model you choose. Compute bounds capping a mission’s total spend. Per-invocation tool allowlists and scoped workflow credentials. `contenox vet` validates chains and envelopes before anything runs them, and warns on fields that read stronger than they are enforced.
Data governance	Local SQLite state, environment scrubbing, secrets resolved from env at request time, region-pinned backends (below), and workspace roots bounding where sessions may operate.

Note: This is not legal advice, and using contenox does not make a deployment compliant with the EU AI Act. Whether the Act’s obligations apply to your system, and whether a given configuration satisfies them, depends on what you build and deploy — that assessment is yours and your counsel’s. What contenox provides are the operational controls such an assessment can point at: authored, versioned, and inspectable rather than implicit.

Compute and attention bounds

An envelope — the same HITL policy file that gates tool calls — can also carry a compute block that puts a ceiling on a mission’s total spend, and an attention block that says who may answer the unit’s questions:

{
  "default_action": "approve",
  "rules": [],
  "compute": {
    "maxTurns": 40,
    "maxToolCalls": 200,
    "maxTokens": 2000000,
    "modelAllowlist": ["qwen3:8b"],
    "backendAllowlist": ["ollama"],
    "onExhausted": "finish_stuck"
  },
  "attention": { "allowAgentAnswers": false }
}

Every compute bound is a ceiling and opt-in: absent or zero means unbounded, and bounds only ever restrict — they never grant.
maxTurns is enforced host-side. maxToolCalls is validated but not yet enforced by the shipped hosts. maxTokens is best-effort, enforced when the unit reports usage.
modelAllowlist and backendAllowlist are enforced at the point where a model is resolved, covering chat, prompt, streaming, and embedding calls. A unit cannot switch itself to a model or backend you did not name — which is how you pin an unattended mission to local inference only.
Exhaustion is never silent: a mission that crosses a bound finishes as stuck rather than running on. (onExhausted: "pause_ask" is not implemented and is rejected at validation — an envelope that sets it fails to load and fails contenox vet; use finish_stuck.)
The attention block is documented in the HITL guide: by default only a human may answer a unit’s escalated question; an envelope can hand a bounded number of routine questions to the firing agent, and the durable record always shows who answered.

Unknown fields in a compute block fail the policy load rather than silently running the mission unbounded.

Sovereign deployment options

Fully local: Ollama. Ollama runs models on your own machine — no API key, no data leaving your network. Combined with local SQLite state and env-resolved secrets, nothing about the deployment depends on an external party. This is the strongest sovereignty posture contenox supports, and the default path in the Quickstart. It is also what makes contenox a self-hosted Copilot alternative: your rules, your models, your machine — instead of an assistant whose behavior and telemetry belong to the vendor.

Self-hosted serving: vLLM. For serving open models on your own GPUs at higher throughput, contenox has a native vllm backend type and also speaks to vLLM through its OpenAI-compatible endpoint. vLLM is an open-source project with substantial backing from Red Hat, which ships a hardened, commercially supported distribution as Red Hat AI Inference Server — the route to take if you want a vendor on the hook behind your self-hosted inference.

EU-region cloud. When you use hosted models, you can still pin where requests are processed, on your own account and keys:

AWS Bedrock — EU regions: a bedrock-runtime.eu-central-1.amazonaws.com (Frankfurt) or other EU-region URL, with eu.-prefixed inference profiles.
Vertex AI — EU regions and data residency: regional endpoints such as europe-west4 (Netherlands) or europe-west3 (Frankfurt) keep ML processing in the pinned region; the global endpoint does not.
OpenAI — EU data residency: eligible API projects created with Europe as their region, served via eu.api.openai.com.

A region-pinned cloud backend is a weaker posture than local inference — the provider’s terms and infrastructure are still in the loop — but the account, the region, the keys, and the decision remain yours, and swapping to a local backend later is a configuration change, not a rewrite.

Human + AI collaboration

Sovereignty is not only about where computation happens — it is about who decides. Contenox treats Human + AI collaboration as an authored artifact: the HITL policy you wrote decides which actions run unattended, which pause for a person, and which are denied outright. Because asks are durable, that collaboration survives process boundaries — a question a unit cannot decide alone waits in the approvals inbox for a human answer instead of timing out into a default. The division of labor between you and the agent is a file you can read, review, and change — not a vendor’s default you discovered after the fact. That is what “trustworthy AI” means mechanically here: written rules instead of hidden prompts, budgets instead of hope, traces instead of guesswork.

Next steps

HITL policies — the policy format, condition operators, presets, and attention bounds.
Why contenox confines agents — the threat model behind structural confinement.
Least-privilege shell environment — scrub-and-inject for every agent-reachable shell.
The pause is yours to define — writing and activating your own approval policy.
The nested permission bomb — scoped workflow credentials instead of inherited human access.