Data residency and what’s captured

This page is for the security, privacy and compliance people who decide whether to roll out Flowstate Router and Flowstate Desktop.

In short

• By default, Flowstate records usage, cost, savings and routing decisions for every request. It doesn’t keep what people and AI tools said.
• Admins can turn on session transcripts for each AI service. Transcripts are off until they do.
• Everything is stored only in your workspace’s region, either the US or the EU. UK workspaces are processed and stored in the EU.
• Flowstate links AI accounts to your workspace only from sources it can verify. Router requests from accounts it can’t link are refused.

What’s recorded by default

For every request that passes through Flowstate, it records:

• Who sent it, and which tool, service and model were used.
• Tokens, cost and what Flowstate saved.
• What Flowstate decided to do with the request, such as keeping the model, moving it to a cheaper one or failing over.
• Timings and the IDs that tie requests to a session.

It doesn’t keep the prompts, the responses or any other conversation content. Flowstate reads a request in memory to route it and reads the response to count its tokens, but neither is stored.

Credentials are never kept. Sign-in tokens and API keys don’t appear in anything Flowstate stores.

Recording happens after the answer is sent, so it doesn’t slow the person’s tool down.

Session transcripts

A session transcript keeps the conversation itself, as well as the usage. Transcripts are off by default. An admin turns them on for each AI service.

Turn transcripts on for a service

1. In Flowstate Helm, go to Settings → Router and choose Whole company.
2. Under Session transcripts, turn on each service you want transcripts for.

The switch that applies is the service the tool connected to, not the company that made the model. For example, a Claude model used through Amazon Bedrock counts as Amazon Bedrock, and one used through OpenRouter counts as OpenRouter.

When to turn a service on

Turn on a service when you need its conversations and they don’t reach Flowstate another way.

Many organisations already bring conversations in through the AI provider’s own compliance API. See Capture AI prompts and responses. If that covers the service, you don’t need a transcript from Flowstate as well.

Compliance APIs don’t cover everything. For example, the Anthropic Compliance API covers people who sign in with Claude Enterprise. It doesn’t cover:

• Anthropic Console API keys.
• Claude used through Amazon Bedrock, Vertex AI or Microsoft Foundry.
• Claude Code sessions that run in the cloud.
• Organisations with zero data retention.

If you need those conversations, turn on the matching switch.

How transcripts are kept

• One transcript per session. A session is one conversation as the tool knows it: a Claude Code session, a Codex session or a claude.ai conversation. Subagents and side requests are kept in the same transcript, not as separate ones.
• In your region. Transcripts are stored in your workspace’s region, like everything else.
• Turned on part-way. If you turn on a service during a session, the transcript starts with the next request. That request carries the earlier conversation, so nothing is missing.
• Turned off part-way. If you turn a service off, Flowstate keeps what it already holds for that session and adds nothing more.

Where data is stored

Data goes to storage in your workspace’s region and nowhere else. If Flowstate can’t work out a person’s region, it doesn’t store the request.

How it feeds analysis

Flowstate Helm uses the usage records to show who uses AI, which tool and model they used and what it cost. See Review AI sessions.

Where Flowstate Helm analyses conversation content, for example to show what AI was used for, the content comes from session transcripts, where you’ve turned them on, or from a provider’s compliance API.

Who is recognised

Flowstate links an AI account to your workspace only from sources it can verify:

• Your AI provider integrations. The people your connected AI providers report as users in your organisation.
• Service-account API keys. Flowstate Helm sends the router a hash of each key, never the key itself.
• Flowstate Desktop sign-ins. When someone signed in to Flowstate Desktop uses their Claude, ChatGPT or Google sign-in, Flowstate links that account to them.

A work email address on its own is never used to link an account.

An account that another workspace already tracks is never taken over. Flowstate Helm shows “This account is already tracked by another workspace” instead, without naming the other workspace.

Router requests from accounts Flowstate can’t link to a workspace are refused with a 403. The router is never an open relay. Flowstate Desktop requests are different: the person has already signed in to Flowstate on that computer.

What AI providers see

Flowstate passes requests to the AI service. People keep using their own account, so the provider sees the request as that account’s request. Requests arrive from Flowstate’s network, not from your offices. If you limit a provider account to certain IP addresses, ask your Flowstate contact for the addresses to allow.

Before you approve

Settle these before a pilot:

1. Transcripts. Decide which services, if any, need session transcripts. Check what your providers’ compliance APIs already cover first.
2. Region. Your workspace region is right. UK workspaces are stored in the EU.
3. Notice. People know what Flowstate records about their AI use, and whether their conversations are kept. Agree the wording with HR and, where they apply, works councils or employee representatives.
4. Retention. Agree retention with your Flowstate contact. Flowstate doesn’t set a public period on this page.
5. Failover. You’ve decided whether to consent to failover to Flowstate-hosted models.

Related

• Flowstate Router
• How routing works
• Flowstate Desktop
• Capture AI prompts and responses
• Security at Flowstate