EU-only processing | kanman documentation

Your code, stories and conversations reach a language model whenever kanman drafts a story, answers in a chat, reviews a change or works on a run. With EU-only processing switched on, kanman uses only model routes that process in the EU, and refuses every other route before a single request leaves. This is a property of your workspace that kanman enforces, not a promise in a document.

Switch it on

Open Workspace settings > Model access (/<workspace>/settings/models).
Find the card EU-only processing. It shows the route your workspace key uses and the region it processes in.
Turn on the switch.

Only owners and admins can change it; every member can see it. The setting is off by default, and kanman never turns it on or off by itself. Every change is recorded in the audit log.

You can switch it on when your workspace key is an EU route (see below) or when the workspace runs everything on its own runners. If the current route does not qualify, the card says why and what to set up first.

Which routes count as EU

Route	With EU-only processing
Amazon Bedrock in an EU region, in-region or with the EU inference profile	Allowed
Amazon Bedrock with the global inference profile, or in a region outside the EU	Refused
Google Vertex AI in a European region (on your own runners)	Allowed
Azure OpenAI, when Test connection confirmed that the resource is in an EU region	Allowed
Azure OpenAI whose region kanman could not confirm	Refused
Your company’s own AI gateway	Allowed: your gateway, your choice of region
Anthropic’s public API	Refused
OpenAI’s public API	Refused
kanman’s own model access (pay through kanman)	Refused

The public APIs and kanman’s own model access are refused because they do not guarantee that a request is processed in the EU. To use EU-only processing, give your teams your own key with an EU route, for example Amazon Bedrock in eu-central-1. See Using your own key.

What it covers

The switch covers every model call kanman makes for the workspace:

kanman’s own steps: drafting stories, answers in the conversation and the independent review;
the coding agent of every run, in kanman Cloud and on your own runners.

What happens when a route is refused

Nothing is sent. kanman checks the route before the call. A refused request never leaves, so no data reaches a provider outside the EU.
A run does not start. A run whose team would use a route outside the EU is not started: no machine starts and no runner takes it. The run says why and what to change: switch the team to your own key with an EU route in Team > Agent and models.
No fallback. kanman never switches to another provider or region on its own to get work done, with or without EU-only processing.

The region is recorded

Every model call and every run records the region its model ran in. The run page shows it under Cost & details as Model region (for example “eu-central-1, in the EU”), so you can show for each run where its model processed your data. Every change of the switch itself is in the audit log.

Runner-only workspaces

Workspaces that run everything on their runners with their own AI gateway already process where that gateway runs: kanman’s cloud never calls a model provider for them. EU-only processing adds the same check on the runners, so a runner whose model access points outside the EU refuses the work instead of sending it. Each runner reports where its model processes when it starts; a runner from before this feature reports nothing and is refused until you update it. A runner that uses Azure OpenAI counts as EU only when you set AZURE_OPENAI_REGION to the resource’s EU region (for example swedencentral). See Model access on self-hosted runners.