“We need sovereign AI” may seem like an easy requirement, until someone has to implement it.
Does it mean source code cannot leave the European Union? Or that models must run on infrastructure your organization fully controls? Or that developers cannot use providers that retain prompts or retain data in some way? Or that your engineering workflow must keep working if a model vendor changes its pricing, licensing, or availability?
Those requirements overlap, but they are not interchangeable. They can lead to very different architectures.
In What Do We Mean When We Say Sovereign AI?, we explored why the same label can describe data, infrastructure, model, or jurisdictional sovereignty. This post takes the next step: turning those distinctions into decisions an engineering team can act on.
We will start with the architecture questions, then walk through how to apply them using Kilo’s EU AI Coding Rollout Planner.
The goal is not to find a product with “sovereign” on the label. It is to understand what you need to control, how to establish that control, and what still needs verification.
Follow the Data
Consider a developer using an AI coding agent inside their editor.
The editor runs on their laptop. The repository is checked out locally. The agent reads relevant files, assembles a request, and sends it to a remote model.
Is that local AI?
The agent is local, but the model inference is not.
Now move the agent into a cloud environment in the EU. It checks out the repository, edits files, and runs tests there. But if it calls a model endpoint outside the EU, it may be European agent hosting, but not European inference.
An AI coding workflow has several parts to examine:
This is why choosing an EU model endpoint is a useful decision, but not the end of the review.
For each workflow, trace what data leaves each environment, where it goes, who can access it, and what terms govern it. Include automated code reviews and background agents, not just the assistant that individual developers see in their editor.
Separate the Requirements
Privacy, geography, and control are often bundled together in vendor language. Your requirements should separate them.
Data Use
Can a provider use submitted code or prompts to train models?
That is different from whether it stores requests. A provider may prohibit training while retaining data for another purpose.
This isn’t a hypothetical concern. The Information reported in September 2026 that Palantir, Nvidia, and Booz Allen have started demanding new data guarantees or restricting use of Anthropic’s and OpenAI’s most advanced models, over fears the labs could learn from their IP. Anthropic and OpenAI both say they don’t use customer inputs and outputs to train by default; the dispute is over what “by default” excludes, and how long models flagged as cyber-capable have their data retained regardless of that setting. That’s the exact distinction this section is asking you to pin down before you sign anything.
Retention
Are prompts or responses retained? For how long? Are there exceptions for debugging, security, or abuse monitoring?
Distinguish request content from operational metadata. “No prompt retention” should not be interpreted as “no records of any kind.”
Processing Location
Must inference happen in the EU, the EEA, a particular country, or a specific environment?
Be exact. “Europe” is not a precise substitute for an approved list of territories. Also establish whether the requirement covers only inference or extends to execution, storage, logs, and other services.
Operational Control
Who operates the infrastructure, controls access, manages encryption keys, and approves changes?
A service can run in an EU data center without being operated by an EU-controlled organization. An endpoint can be customer-controlled without being physically located in the EU.
These distinctions do not make one arrangement universally right or wrong. They determine whether it fits your requirement.
For example:
For the sensitive product team, submitted code and prompts must be processed through approved EU endpoints, must not be used for provider training, and must follow our agreed retention policy.
That is something an architecture and procurement team can evaluate. “Use private European AI” leaves too much unresolved.
EU hosting also does not, by itself, establish GDPR compliance. GDPR obligations extend beyond location, and qualifying international transfers can be lawful. The European Data Protection Board’s guidance explains those transfer conditions.
Preserve Your Choices
Sovereignty is not only about where today’s request goes. It is also about which decisions you can make tomorrow.
If a model becomes unavailable, can you replace it without replacing your coding tools? If a provider changes its terms, can you move to another approved endpoint? If a workload becomes more sensitive, can you change its deployment without redesigning every team’s workflow?
This isn’t speculative. An independent expert strategy report on transformative AI notes that ENISA, the EU’s own cybersecurity agency, had to negotiate for early access to Anthropic’s most capable model and still hasn’t received newer versions, before a separate US export control directive suspended the model for all customers outside the US entirely. If the EU’s own security agency can’t count on continuous access, no individual engineering org should assume it either.
These are practical forms of independence.
Open-weight models can expand your hosting options, subject to their licenses and operational requirements. Model-agnostic tooling can make changing providers easier. Neither removes the need to evaluate quality, compatibility, capacity, and cost.
An alternative route is more useful when you have tested it.
Choose representative tasks from your own repositories. Compare whether an alternative model can complete them reliably, how much intervention it needs, and what it costs to operate. A model appearing in a supported-provider list is a starting point, not proof that it is an adequate replacement.
This is the engineering version of the argument in Europe Needs An AI Strategy: preserve choices at the layers you can control.
It’s also a sharper version of the argument I made in How to Differentiate When Everyone Can Download the Same Model: the model itself is increasingly a commodity, so the durable asset is your own context, evaluations, and judgment, not the model you currently run on. Losing a provider shouldn’t mean losing what you’ve built.
Know What BYOK Means
Bring Your Own Key is useful, but doesn’t answer all questions by default.
BYOK lets you use credentials associated with your provider account. That can help you reuse an existing commercial agreement, billing arrangement, or approved endpoint.
It does not automatically mean:
Inference stays in the EU.
Requests bypass every intermediary.
Your organization operates the model infrastructure.
The provider retains no data.
A developer’s credentials are available to a hosted agent.
A developer configuring a personal key for an IDE pilot is one operating model. An organization supplying shared access for their developers, for automated code reviews, and background agents is another.
Document both the credential owner and the request path. Then validate the endpoint and terms behind that access.
Make Policy Enforceable
Not every workload needs the same restrictions.
A team working with sensitive customer systems may require a tightly constrained set of EU providers. Another team working on less sensitive internal tooling may be allowed a broader approved catalog.
Different policies within an organization can preserve useful flexibility. But they need clear boundaries and ownership.
There is also a difference between a default and a restriction.
A default says, “Start with this model.” A restriction says, “You cannot use an unapproved model through this managed workflow.”
When a requirement uses the word must, identify what enforces it. That could involve product controls, identity management, network restrictions, endpoint configuration, or a combination. Review fallback behavior and connected tools as well as the primary request path.
The same applies to local deployments. A local model is not evidence of an air-gapped system. Tool calls, package downloads, telemetry, updates, and other outbound connections still need examination.
The result should be a documented operating policy, not just a list of the preferred settings.
Apply It With Kilo
Many of these decisions are the basis of Kilo’s EU AI Coding Rollout Planner.
The planner asks eight questions and maps your answers to possible Kilo capabilities, a likely plan, and items to confirm. It is a requirements-planning tool, not a compliance assessment or a cost calculator.
To show how to use it, consider a hypothetical European engineering organization introducing AI coding to a sensitive product team. It wants interactive assistance in developers’ editors (VS Code and JetBrains) and asynchronous coding tasks, with approved EU inference and centralized policy management.
Here is how that team could work through the planner.
1. Select Priorities
Choose Security and privacy, EU data compliance, and Governance and auditability.
These selections describe the reasons for the rollout. The later questions turn them into more specific requirements.
Before continuing, write down what success means outside the tool: useful developer adoption, acceptable task quality and cost, and evidence that the approved workflow respects the defined boundaries.
2. Set the Scope
Choose Team rollout.
This describes the intended scope, but it does not mean enabling every developer immediately. Start with a bounded cohort and representative repositories.
The pilot should test the operating model as well as the coding experience: access provisioning, approved routes, support, reporting, and exception handling.
3. Choose the Surfaces
Select IDE extensions and Cloud Agents.
This creates two execution paths to examine. Interactive IDE work happens in the developer environment. Cloud Agents need a separately approved environment for asynchronous tasks.
Add Code Reviews or integrations when you are ready to validate their paths too, rather than assuming approval of one surface automatically covers the others.
4. Define Inference Policy
Select Inference must stay in the EU.
For this example, also select the controls to block providers that train on submitted data and retain prompts.
Those are separate requirements. The next step is to verify that the actual providers and endpoints satisfy each one, including any relevant exceptions and contractual conditions.
If your policy additionally requires customer control of the infrastructure, record that explicitly. The planner simplifies its inference-boundary choices; real requirements can combine geography and control.
5. Choose Model Access
Select Shared organization BYOK if the organization intends to use supported shared provider credentials.
Kilo also offers managed Gateway access, developer-configured BYOK, Enterprise Shared Private Gateway, and compatible local or self-hosted model connections.
The right choice depends on existing provider agreements, the selected endpoints, and which workflows need access. A developer’s personal configuration should not be assumed to supply credentials to Cloud Agents.
EU-hosted open-weight inference through providers such as Inceptron is one option to investigate. Confirm current model availability, endpoint territory, and terms for the chosen route.
6. Choose Execution Compute
Select Developer machines for IDE work and Kilo-hosted EU compute for the asynchronous agents.
Kilo-hosted EU compute is an Enterprise option that needs contractual scoping.
This is separate from the EU inference decision. Both paths need validation.
Kilo also lists customer-provided compute as an option for Cloud Agents and Code Reviews. That introduces its own questions about location, connectivity, isolation, capacity, updates, and operational responsibility.
7. Identify Policy Groups
Choose Different teams need separate policies if this sensitive product group needs stricter rules than other parts of the organization.
Kilo Enterprise offers sub-organization controls for differing budgets and policies.
The planner records the need for segmentation; it does not configure each team’s policy. Produce a separate assignment showing which teams and workloads belong under which rules.
8. Choose Governance
Select Centrally enforced organization policy.
For this example, approved providers and models should be controlled centrally rather than left as recommendations each developer can change.
Review the identity, access, audit, and exception requirements alongside those controls. Establish who can approve a new provider or change an existing policy.
Review the Result
For the example above, the planner recommends Enterprise as the likely fit and maps the requirements to relevant Kilo capabilities.
That result is a starting point for implementation, not a statement that the deployment is already sovereign or compliant.
Use it to review:
Which models and endpoints meet the inference requirements.
Whether provider data-use and retention terms match the policy.
Which execution environments and product data paths are covered by the EU arrangement.
How access restrictions and separate policies will be enforced.
Who owns validation, ongoing operations, and exceptions.
The planner displays a short set of confirmation items. Treat those as prompts for discussion, not an exhaustive security or procurement checklist.
Then run the bounded pilot. Test useful coding work and the boundaries around it. Confirm that unapproved routes are blocked where required, that reporting provides the evidence you need, and that an approved alternative model is workable.
Expand only after those checks support the decision.
Start With Boundaries
There is no single deployment that every European engineering team should call sovereign.
Some workloads need regional inference. Others need customer-controlled infrastructure. Some require a local environment with tightly restricted connectivity. Many organizations will operate more than one arrangement.
What matters is being able to explain the choices: what data goes where, who controls the system, which dependencies remain, and what prevents an unapproved path.
Cost control is worth naming separately, because it’s often the reason organizations start asking these ownership questions in the first place. GitHub Copilot moved to usage-based billing on June 1, 2026, replacing flat premium-request limits with token-metered AI Credits. Base subscription prices didn’t move, but agentic-workflow costs jumping 10x to 50x for heavy users once the meter went live, with model multipliers rising alongside it, Claude Opus 4.7’s multiplier for annual subscribers reportedly went from 7.5x to 27x. Developer forums registered backlash, and coverage of the change described teams actively evaluating flatter, more predictable alternatives.
Kilo’s pricing works differently: you pay providers directly, per token, at the rate they publish, with no markup or model multiplier layered on top. And with a Kilo Pass you add extra credits to your balance every month. That’s the same argument as the one about owning your context and evaluations instead of renting them: the moment a vendor changes its terms, cost included, ownership is what you fall back on. A pricing shock like Copilot’s is just one of the reasons that more organizations choose setups they control instead of ones they rent.
Kilo provides options for model access, execution, and governance. The work is to select and validate the combination that matches your requirements.
Use the EU AI Coding Rollout Planner to turn those requirements into a practical starting plan, then validate the proposed setup before rollout. Our team is happy to talk through scoping your AI coding rollout.
This article provides technical planning guidance, not legal or compliance advice. Product availability, provider behavior, regional coverage, and service commitments depend on the specific configuration and applicable agreements.
Splitting 'we need sovereign AI' into concrete requirements is the step most teams skip. The question that tends to settle the debate is the last one: does the workflow keep running if a vendor changes pricing, licensing or availability? Residency is easy to buy; continuity has to be designed.