Part 3 of four. Each briefing in this series takes one of the four sovereignty questions from our full guide, Making Sense of Sovereign AI, and makes it usable on its own.
Question 3: How Is Your Data in Transit Handled?
What this actually means
“Data in transit” is any data that is moving – between systems, services, environments, regions, or providers.
That sounds technical, but the business reality is simple:
Even if you store data in the right place and encrypt it properly, you can still lose sovereignty through the pipes – the hidden flows that move information for convenience, monitoring, and integration.
In AI systems, “data in transit” isn’t just customer records moving from A to B. It includes:
- Prompts sent to a model (the question, instruction, or request)
- Context retrieved to ground the answer (documents, database snippets, embeddings)
- Model outputs (which can include sensitive information if the prompt contains it)
- Logs and telemetry (often the biggest blind spot)
- Human feedback loops (review queues, labeling tools, support tickets)
In other words: the data you worry about is rarely confined to a single “core system.” AI creates many auxiliary data flows and those are where sovereignty often erodes quietly.
Why leaders should care
From a compliance perspective, cross-border movement and third-party sharing can trigger obligations you didn’t plan for – especially when logs contain personal data, regulated data, or operationally sensitive information.
From a choice perspective, many organizations decide to limit movement even when it is technically legal because every additional flow is an additional dependency, vendor exposure, and potential breach of trust.
From a cost perspective, “in transit” sovereignty is expensive because it often means giving up best-in-class global tools. The most convenient observability platforms, analytics services, and AI add-ons are frequently global by design. Replacing them with local alternatives—or building capabilities yourself—adds friction and cost.
The executive mistake is to treat “data movement” as a technical detail. It is not. It’s a governance and trust issue.
A more vivid, end-to-end example
The Sovereign Chatbot That Isn’t
Imagine a public-sector agency launching an AI assistant to help citizens with tax questions.
1. The sovereign core
The agency does many things right:
- The chatbot application runs in a national or EU sovereign environment
- The model is hosted within the same jurisdiction
- The citizen-facing database remains local
- Security teams sign off on residency
Leadership communicates confidently:
“Your data stays here.”
2. The operational reality kicks in
After launch, the agency wants to answer entirely reasonable questions:
- Are users getting correct answers?
- Where do they drop off?
- Which topics create frustration?
- Are we accidentally exposing sensitive information in responses?
To get these insights quickly, the project team plugs in a popular global analytics and monitoring tool. It’s fast, cheap, and the dashboards are great.
Here is what happens next – often without anyone intending it:
- Full conversation transcripts are streamed into the analytics platform
- Logs include metadata such as time, channel, and sometimes identifiers
- Prompts and responses now exist outside the sovereign boundary
- Support engineers and vendor staff may have access to debug issues
Technically, the “main system” is sovereign.
Practically, the most sensitive part – citizen conversation – now travels elsewhere.
This is the sovereignty gap that catches leadership teams off guard: the side systems become the real system.
3. Fixing it requires real trade-offs
Once the issue is identified, the agency has options but each has consequences:
- Data minimization: log only what’s necessary (errors, aggregate stats), not full transcripts
- Benefit: reduces exposure significantly
- Trade-off: less diagnostic power and slower debugging
- Anonymization and redaction: strip identifiers before any data leaves the environment
- Benefit: improves compliance posture
- Trade-off: adds engineering complexity and still requires careful validation
- Local observability: use a tool that runs inside the same jurisdiction as the chatbot
- Benefit: aligns reality with the public promise
- Trade-off: dashboards may be less polished; costs may be higher
- Keep transcripts inside: store full conversations locally and only export aggregate analytics
- Benefit: strongest control
- Trade-off: slower insights; more internal operational burden
This is the leadership decision point: sovereignty in transit is not a yes/no stance – it’s a set of explicit choices about what you measure, where you measure it, and what you are willing to expose to get speed.
The practical insight for leaders
The takeaway is simple and uncomfortable:
- Sovereignty is often lost through convenience
- The biggest risks often sit in logs, telemetry, analytics, and “temporary” integrations
- If your organization promises “data stays here,” you must include every supporting service in that promise – not just the model host
For business leaders, the right question is not:
“Is the chatbot hosted in the right region?”
But:
“Where do prompts, outputs, logs, and feedback travel—and who can see them?”
Once you ask that question, sovereignty stops being abstract. It becomes a concrete operating model decision—about tooling, vendors, and what data you allow to flow where.
And as with the other questions: you rarely need maximum sovereignty everywhere.
But you do need intentional sovereignty where trust and risk are highest.
Next in the series: Question 4 — who can be forced to access your data?