AI Sovereignty: Who Controls Your Company's Intelligence?

For the first few years of generative AI, the security conversation inside companies was relatively easy to understand. An employee opened ChatGPT in a browser, copied a piece of text into it and asked a question. Security teams responded with policies about what could and could not be pasted into a chatbot, while some companies went further and blocked these tools entirely.

That conversation already feels outdated. It no longer matches how these systems work.

AI is no longer a destination where employees occasionally send information. It is becoming part of the infrastructure through which information moves.

A coding agent can read a repository, inspect dependencies, search documentation, modify files and execute commands. An internal assistant can retrieve information from thousands of company documents before answering a question. Meeting tools process customer conversations automatically. Agents are being connected to databases, CRMs, support systems and internal APIs, and the amount of context we give them keeps growing because they become considerably more useful when they understand more about the company they are working for.

The result is a subtle but important change in the security question. It used to be whether you should paste a particular piece of information into ChatGPT.

Increasingly, the question is where your company information goes when AI uses it.

Every useful AI system needs context. A coding agent without access to your codebase is considerably less useful. A customer support agent without access to previous conversations and product documentation cannot answer much. An internal research assistant becomes valuable precisely when it can search information that is not available on the public Internet.

The better these systems become, the more of our companies we connect to them. And the more of our information they reach.

This is why some of the most interesting AI conversations happening inside large companies are beginning to move away from model quality as the only criterion. For the last few years, the dominant question has been which model is best. Companies compared benchmarks, context windows, prices and reasoning capabilities, switching providers whenever a new model offered a meaningful improvement.

Once models become infrastructure, the criteria change.

Companies now have to understand not only what a model can do, but where inference happens, what information is sent with each request, how long that information can be retained, who can access it, what gets logged and what happens if the company eventually wants to move the workload somewhere else.

Recent decisions by some of the companies adopting AI most aggressively suggest that this conversation is already changing. Palantir has reportedly asked Anthropic for an irrevocable zero-data-retention commitment. NVIDIA has restricted the use of Claude for more sensitive work, while Booz Allen has limited its use for proprietary cybersecurity tasks. [1]

These decisions are interesting precisely because none of them amount to a rejection of external AI. They are decisions about where particular workloads are allowed to run and under which conditions.

At the same time, providers themselves are responding to the same pressure. Enterprise AI products increasingly offer different retention, data-processing and deployment configurations, including zero-data-retention options for eligible customers. But not for everyone. [2] [3]

The direction of travel is therefore more interesting than any individual controversy. Companies are becoming more demanding about the boundary around inference, while model providers are building new ways to narrow it.

That requires some precision. If you read this in the terms and conditions of your AI provider, you have to understand that they describe different guarantees:

"Not used for training", "zero data retention" and "private inference".

A provider may commit not to use customer data for training while retaining requests temporarily for security or abuse monitoring. A zero-data-retention configuration can remove or substantially reduce that persistence without changing where inference physically happens. Private inference changes another part of the architecture again.

Treating all of these concepts as interchangeable is one of the reasons enterprise AI security conversations become confusing.

Consumer ChatGPT is not ChatGPT Enterprise; an enterprise API deployment is not equivalent to a consumer chatbot. Model training, abuse monitoring, operational logging, human access and data retention are related, but distinct questions.

Collapsing them into a single conversation about "privacy" produces dramatic headlines, but does little to help a company make better infrastructure decisions.

None of this is new. Companies already trust external infrastructure with extremely sensitive information. Source code lives on cloud platforms. Customer information sits inside CRMs. Financial data passes through payment processors. Entire businesses run on infrastructure owned by AWS, Microsoft or Google.

Modern companies are built on carefully managed dependencies, not on the absence of them.

AI is no different.

What is different is the amount and variety of information that can converge in a single AI workflow.

A coding agent may see source code, architecture decisions, environment information, error logs and internal documentation during the same session. Give it access to more tools and the boundary expands again: it may query an issue tracker, inspect a database schema or interact with a deployment system.

More importantly, it reaches enough information that, misused, it could build a profile of your company, collect the intelligence that matters most and use it without your consent.

This does not make these systems unsafe. It makes their architecture important.

There is a significant difference between deciding that an external provider is trustworthy enough for a particular workload and building your AI infrastructure so that every workload must trust that provider.

That distinction is where the conversation about AI sovereignty becomes useful.

The problem isn't OpenAI or Anthropic. It's the trust boundary.

It would be easy to turn this conversation into an argument against OpenAI, Anthropic or any other commercial AI provider.

It would also be the wrong conclusion.

The cloud did not make companies less serious about security. It forced them to become more precise about what they were delegating. AI requires the same maturity.

When information moves from a system governed by your controls into one governed, at least partially, by another party, it crosses a trust boundary. That does not make the transaction unsafe. It means that some guarantees now depend on somebody else.

The important question has never been whether trust exists, because modern infrastructure makes that unavoidable. It is what exactly you are trusting someone else to do, under which technical and contractual guarantees, and whether those guarantees are appropriate for the workload.

With AI, that can become surprisingly difficult to answer.

Whether prompts are used for training is one question. How long prompts and outputs are retained is another. Whether operational or security logs exist is another. [4] Whether humans can access information under specific circumstances introduces another layer, as do the location of inference and the subprocessors participating in the service.

An enterprise agreement can change many of these conditions. Zero-data-retention configurations can change them further. Dedicated deployments and private infrastructure can reduce or move the boundary again.

This is why asking whether "OpenAI stores my data" or "Anthropic can see my code" is usually too imprecise to be useful for an infrastructure decision. The answer depends on the product, configuration, contract and workload. [5]

There is another question that receives much less attention:

What happens if you want to change any of this later?

Imagine a company building an internal coding platform around a commercial model. The arrangement is perfectly reasonable. The provider has the best model for the task, the API is easy to integrate and the security team is comfortable with the guarantees.

Over time, the platform becomes more useful. More developers adopt it. The agent receives access to more repositories and documentation. Teams build workflows around provider-specific features. Prompts, tools, observability and application logic gradually accumulate around the original API.

Nothing has gone wrong. In fact, the project has been successful.

But the trust decision made at the beginning has quietly become an architectural dependency.

Perhaps a year later a particularly sensitive repository needs to remain inside the company's infrastructure. A customer contract may introduce new data residency requirements. The provider may change its pricing or terms. Another model may simply become better.

The company can still migrate, but the relevant question is how much of its AI stack has to move with it.

This is where AI sovereignty becomes more than a privacy discussion.

Security asks whether a system is sufficiently protected for a particular use. Sovereignty asks a related but broader question:

Who retains the ability to make the next decision?

A company may consciously decide that sending a workload to an external model is acceptable. That can be a perfectly sovereign decision if it understands the boundary and retains meaningful alternatives.

The problem appears when an architectural choice gradually removes those alternatives.

This is also why the most sovereign option is not automatically the most secure. Running an open model on poorly maintained infrastructure does not become secure because the weights are under your control. A mature enterprise API with strong access controls, auditing and contractual guarantees may be considerably safer for many workloads.

Sovereignty should not be used as a shortcut around ordinary security engineering.

What it changes is who controls the architecture.

What AI sovereignty actually means

Sovereignty is an uncomfortable word in technology because it can mean almost anything. It is frequently associated with geography, regulation or the idea that infrastructure should remain within national borders. In AI, it is also beginning to be used as shorthand for self-hosting.

Both interpretations capture part of the problem, but neither is particularly useful on its own.

A company does not become sovereign simply because it owns GPUs, just as it does not lose sovereignty every time it calls an external API.

What matters is whether the company understands and controls the path between its data and the intelligence operating on it, and whether it retains the ability to change that path when necessary.

That control can be understood across four parts of the stack: data, models, compute and operations.

Data

Data is the most obvious layer, but even here the boundary is broader than it initially appears.

AI systems consume much more than the prompt visible in a chat interface. Retrieved documents, source code, conversation history, tool results, system instructions and information assembled dynamically from internal systems may all become part of a request.

Some of that information may exist only in memory during inference. Some may be written to application or provider logs. Conversation history may live somewhere else entirely, while embeddings sit in a vector database and traces are sent to an observability platform.

An architecture casually described as "private AI" can therefore still create copies of company information across several systems.

A sovereign architecture makes those decisions explicit.

The objective is not zero retention everywhere. There are legitimate reasons to retain information for auditing, debugging, security or product functionality.

The objective is intentional retention.

Models

The second layer is the model itself.

The best model for a workload today may not be the best six months from now. A smaller model may become good enough to run privately. An open model may offer comparable quality with different economics. A new proprietary model may create enough additional value to justify using it. Regulation or customer requirements may make an existing deployment inappropriate for a subset of workloads.

Model sovereignty does not require using open models exclusively.

It requires treating models as components that can be replaced rather than permanent dependencies.

Compute

Compute introduces another decision.

There is a broad spectrum between sending every request to a public API and buying a rack of GPUs. Inference can run through hosted APIs, dedicated infrastructure, a company's own cloud account, sovereign cloud environments or hardware physically controlled by the company.

The important capability is not necessarily owning the compute.

It is being able to decide where a workload runs.

Operations

Finally, operations determine what the AI system is actually capable of doing.

An agent may read a repository but not modify it, query customer information through a restricted interface or execute code only inside an isolated sandbox. Identity, permissions, tool access, isolation, observability and auditability therefore become part of the sovereignty boundary as well.

This becomes increasingly important as companies move from chat interfaces towards agents.

An AI system that can only generate text has a very different risk surface from one that can read company systems, execute tools and take actions. The question is no longer only what information reaches the model, but what authority comes back with the answer.

Put these layers together and sovereignty starts to look less like a deployment choice and more like an architectural property.

There is also an important distinction between contractual guarantees and architectural guarantees.

A provider can contractually guarantee that customer data will not be retained, with that promise backed by contracts, certifications and audits. Those guarantees matter.

But systems can also be designed so that certain guarantees follow from how the infrastructure works. If context exists only in memory for the lifetime of inference, there is less customer information available to retain afterwards. If the inference layer does not create prompt logs, there is no historical prompt database whose retention period needs to be managed.

The strongest systems combine both approaches.

Technical design reduces the amount of trust that has to be placed in a provider, while contracts, audits and certifications verify the controls that cannot be independently observed.

Neither eliminates the need for the other.

This gives companies a more useful way to evaluate sovereignty: where does the workload's data exist, what persists after inference, which model processes it, where does that model run, what can it access, and can any of those answers be changed later?

The answer does not need to be the same for every workload.

In fact, it probably shouldn't be.

Not every workload needs the same level of control

Companies do not protect every piece of information in the same way today.

A public press release and an acquisition plan may both be documents, but they do not belong under the same security policy. An employee directory, customer database and production credentials carry different risks and are surrounded by different controls.

AI workloads should be treated in much the same way.

Consider an employee asking a model to improve the wording of a public job description. The information is already public, the consequence of exposure is negligible and adding dedicated infrastructure would provide very little additional value.

Now consider the same employee analysing compensation data across the company, or a developer giving a coding agent access to a proprietary repository.

The interface looks almost identical in both cases: a prompt goes in and an answer comes back. The infrastructure decision underneath it should not be.

Before deciding how a workload should run, a company can evaluate a relatively small number of characteristics: the sensitivity and business value of the information involved, the systems the model can access, the actions it is allowed to perform and the consequences if something goes wrong.

These categories are deliberately not absolute.

The same workload can require very different controls depending on the organisation. A customer support assistant for an ecommerce store and one handling defence contracts may perform conceptually similar tasks while operating under completely different constraints.

Regulation, geography, contractual obligations and the value of the underlying information can move the same workload considerably up or down the table.

The important shift is to stop selecting AI infrastructure at company level and start selecting it at workload level.

A company does not necessarily need an OpenAI strategy, an Anthropic strategy or even an open-model strategy.

It needs to understand what it wants AI to do and define the acceptable boundary for each workload.

For some, a hosted frontier model will be the obvious answer. Others may require stronger guarantees around retention. As sensitivity increases, dedicated or privately operated inference may become justified.

The objective is to find the minimum sufficient level of control for each workload.

That matters economically as much as it does from a security perspective.

Maximum sovereignty has a cost. GPUs have to be provisioned, infrastructure operated, models served and capacity planned. Doing all of that to summarise public research would be difficult to justify. Doing it to process the intellectual property on which the value of the company depends may be considerably easier.

The same reasoning applies in the opposite direction.

Convenience also creates dependencies. Building every AI workflow around a single external provider can reduce complexity today while reducing optionality tomorrow.

A good sovereignty strategy therefore does not try to minimise external dependencies at all costs. It makes those dependencies proportional to the workload.

This becomes especially important for companies whose most valuable information is not necessarily regulated.

Proprietary source code, unreleased research, manufacturing processes, product architecture or the accumulated knowledge contained in thousands of internal documents may not fit neatly inside a compliance category, but they can represent a substantial part of the company's value.

The relevant question is not only whether an AI provider complies with a regulation.

It is whether the architecture surrounding a critical workload reflects the value of the information passing through it.

Sometimes the answer will be a standard hosted API. Sometimes it will require ZDR or dedicated infrastructure. Sometimes the workload should not leave an environment controlled by the company.

A mature AI stack should be capable of supporting all of them.

From model selection to inference routing

Most AI applications today begin with a model choice.

A team decides to build with GPT, Claude, Gemini or an open model, integrates the corresponding API and develops the application around it. For an experiment or a small internal tool, that is usually the fastest and most sensible way to start.

The problem appears when that application becomes infrastructure.

Once multiple teams, agents and internal tools depend on the same integration, the original model choice begins to determine much more than model quality. It influences where inference happens, which data policies apply, how costs behave, which capabilities developers can use and how difficult it will be to move a workload somewhere else.

A different architecture separates two decisions that are often made together:

What does the application need to do, and where should the intelligence required to do it come from?

An internal search tool does not inherently need to know which provider answers every query. It needs a model capable of understanding its context, producing a sufficiently good answer and satisfying the policies attached to that workload.

The same is true for a coding agent. Repositories, permissions, tools and tasks belong to the application. Whether the reasoning behind those tasks happens on a frontier commercial model, a dedicated endpoint or an open model running inside the company's infrastructure can be a separate decision.

Once those concerns are separated, the AI stack begins to look different.

Applications and agents sit at the top. Below them sits a control layer responsible for applying identity, permissions and workload policies and determining which inference destinations are acceptable.

The inference layer below that no longer needs to be a single provider. It can contain commercial APIs, endpoints operating under zero-data-retention guarantees, dedicated deployments and open models running on private or self-hosted infrastructure.

The important architectural change is that the application is no longer permanently coupled to one of them.

Inference becomes a resource that can be governed rather than a provider that applications are built around.

A request containing public information may be allowed to use any approved provider. A coding agent operating on a sensitive repository may only be permitted to use endpoints satisfying particular retention requirements. A workload containing particularly valuable intellectual property may be restricted to models running inside controlled infrastructure.

Within those boundaries, the system can still optimise for quality, latency and cost.

This creates an important hierarchy:

Security and data policies define where a workload can run. Performance and economics then help decide where it should run.

A company might therefore have access to ten models without every application being allowed to use all ten. The available inference pool for a marketing assistant could be broad, while an agent connected to production infrastructure might operate inside a much smaller set of approved deployments.

This is considerably more flexible than trying to find one model capable of satisfying every requirement in the organisation.

It also reflects how AI is likely to evolve.

There is little reason to assume that a single model provider will remain the best choice across coding, reasoning, document processing, multimodal tasks, agents and high-volume inference. Model capabilities are moving too quickly, and the economics vary too widely between workloads.

A model that is unnecessarily expensive for millions of simple classifications may still be worth using for a difficult reasoning task. A smaller open model may perform perfectly well for an internal workflow that does not require frontier intelligence.

The infrastructure should be capable of expressing those differences.

Over time, routing can incorporate more than sensitivity: cost ceilings, latency requirements, geographic restrictions, availability and measured performance on company-specific tasks can all influence where inference happens.

There is, however, an important limitation to this idea.

Models are not perfectly interchangeable.

Different models support different context sizes, tool formats, reasoning modes, structured outputs and multimodal capabilities. They respond differently to the same prompt, and applications built around provider-specific features can achieve better performance precisely because they take advantage of those differences.

A sovereign architecture cannot pretend those differences do not exist: they set how easily a piece can be swapped out. What is in your hands is making coupling a deliberate choice rather than an accident, without flattening every model down to a lowest common denominator.

A team should be able to use a provider-specific capability when its benefit justifies the portability it gives up in return, while keeping the infrastructure underneath capable of supporting alternatives.

This also applies to fallback behaviour.

A sensitive workload routed to a controlled inference environment should not silently fall back to an unrestricted public endpoint simply because the preferred model becomes unavailable. Routing is only sovereign if every permitted route respects the policy attached to the workload.

Observability deserves the same attention. A company can design an inference path with excellent privacy guarantees and then accidentally reproduce every prompt inside its own telemetry stack. The control layer itself therefore has to respect the data policies it is responsible for enforcing.

Done properly, this architecture reconciles two objectives that are often presented as opposites: using the best available AI and maintaining control over how that AI is deployed.

A company can use frontier commercial models where their capabilities matter, cheaper models where scale matters and privately deployed models where control matters, without requiring any one of those decisions to define the entire AI stack.

AI infrastructure is likely to become heterogeneous.

And open models provide another place to route.

Open models change the sovereignty equation

Open models do not solve the sovereignty problem by themselves.

A company can send sensitive information to an open model running on somebody else's infrastructure, retain every prompt indefinitely and surround the deployment with weak access controls. The availability of the weights does not make any of those decisions safer.

What open-weight models change is something more fundamental:

They separate the model from the company that created it.

With a closed model, access to the model and dependence on its provider are closely connected. Enterprise contracts and deployment arrangements can substantially alter the conditions, but the model itself remains tied to infrastructure made available by its developer or authorised partners.

Open weights break that relationship.

They create a separation between three roles that are often treated as one: who creates the model, who operates inference and who controls the compute.

They do not have to be the same organisation.

A model can be developed by one organisation, served by another and run on infrastructure controlled by a third. Subject to its licence and technical requirements, the same weights can be served through a specialised inference provider, dedicated GPUs, a company's cloud environment or hardware operated internally.

The intelligence can remain broadly the same while the trust boundary around it changes.

This is the structural contribution open models make to AI sovereignty. They create another degree of freedom in the architecture.

It is also why the enterprise discussion around open models should not be reduced to whether they beat the best proprietary model on a leaderboard.

For some workloads they will; for others they will not. Frontier commercial models can still justify their use when the additional capability produces enough business value.

The more interesting question is whether every workload actually requires frontier capability.

Many do not.

Extraction, classification, document processing, retrieval, summarisation, translation and a growing range of agentic tasks can often be performed by models that are easier to operate under controlled conditions.

As open models improve, the set of workloads for which companies have a credible alternative to external frontier inference expands.

This does not remove proprietary models from the stack.

It changes when depending on them is necessary.

The same capability can also move through different infrastructure environments as its requirements change.

Imagine a company has evaluated an open model for document analysis and knows that it performs well enough for the task. During development, the team may consume that model through a hosted inference API because there is little reason to operate GPUs while the product is still being tested.

As usage grows, economics may justify moving the same workload to dedicated capacity. A particularly sensitive customer may require inference in a specific region. Another deployment may need to run inside the customer's own cloud, while a regulated environment could require the model and its surrounding data pipeline to operate without external network access.

Those are significant infrastructure changes, but they do not necessarily require changing the underlying model or rebuilding the application around completely different intelligence.

The model becomes portable in a way that closed models generally cannot be.

Portability, however, should not be confused with perfect reproducibility.

Running the same weights through two inference providers does not guarantee an identical service. Providers can differ in quantisation, serving configuration, context limits, throughput, latency, reliability and supported features.

Even when the model name is identical, the operational characteristics surrounding it may not be.

Open weights therefore do not magically eliminate infrastructure dependencies.

They make those dependencies more granular.

Self-hosting also deserves a more realistic treatment than it usually receives.

Running inference yourself transfers control, but it transfers responsibility with it. GPUs need to be provisioned and utilised efficiently. Serving infrastructure needs to scale. Models need to be updated. Reliability, monitoring, security and capacity planning become your problem rather than the provider's.

For many companies, taking on all of that operational burden would make little sense.

There is an important middle ground between a public model API and building an internal GPU platform. Open models can run on infrastructure operated by specialised providers while still allowing different guarantees around isolation, retention and deployment location. They can run on dedicated capacity without the customer having to employ a team of inference engineers, and they can move again if requirements change.

This is why ownership of the weights and ownership of the hardware should not be treated as the same thing.

The strategic advantage is that a company can decide how much of the inference stack it wants to operate and how much it wants to delegate, without every company having to become an AI lab.

That distinction changes the nature of vendor risk.

With a proprietary model, replacing the provider usually means replacing the model as well. With an open model, changing who serves it can leave more of the stack intact. The company may still depend on external compute, networking or infrastructure, but those dependencies can be separated and evaluated individually rather than bundled into a single model provider.

This does not eliminate vendor lock-in. Infrastructure rarely does.

It makes lock-in more granular.

And that is an important property of a sovereign system. Sovereignty does not require eliminating every external dependency; it requires preventing those dependencies from becoming irreversible decisions.

If applications are separated from inference, open models provide destinations at the end of that route that the company can ultimately control. A workload can begin on shared infrastructure, move to dedicated capacity as it grows and eventually run entirely inside the company's environment if its sensitivity demands it.

The model does not have to determine the trust boundary.

The company does.

That is why open models matter even to organisations that continue using GPT, Claude or Gemini every day.

Their value is that they make proprietary models optional.

Sovereignty is optionality

There is a tendency to discuss technological sovereignty in terms of ownership: who owns the infrastructure, where the servers are located, who developed the model or whether the software is open.

Those questions matter, but ownership is not quite the same thing as control.

A company can own infrastructure and still depend heavily on a particular vendor, model or software stack. It can also rely extensively on external infrastructure while maintaining considerable control over how its systems are deployed and where its data is allowed to move.

A more useful measure of sovereignty is therefore the freedom to decide: optionality. Having options.

Can the company change its mind?

Can it move a workload from one provider to another? Can it decide that information which was acceptable to process externally yesterday should remain inside a controlled environment tomorrow? Can it adopt a better model without rebuilding the application around it? Can it bring inference closer to its data if regulation, economics or customer requirements change?

If the answer is yes, the organisation retains meaningful control over its AI infrastructure even when much of that infrastructure is operated by other companies.

If the answer is no, the current provider may be perfectly safe and reliable and the problem may sit somewhere else: a technical decision has become difficult to reverse. We usually think of technical debt as code, but this is technical debt too, and of the worst kind.

This distinction is particularly important because nobody knows what the model market will look like in a few years.

The current generation of AI infrastructure is being built while model capabilities, prices and architectures are changing extraordinarily quickly. Models that required enormous amounts of compute are becoming smaller and more efficient. Open models are closing gaps that looked substantial only months earlier. New hardware changes inference economics, while regulation and customer requirements change where certain workloads can operate.

Building permanent dependencies during that period is a considerable bet on a future that is difficult to predict.

A sovereign architecture does not try to predict it.

It preserves the ability to respond to it.

That may mean continuing to use frontier proprietary models extensively because they provide the best capabilities available. It may mean running high-volume workloads on cheaper open models. It may mean moving particularly sensitive inference onto dedicated infrastructure, or keeping a handful of critical workloads completely isolated.

Those choices can coexist because sovereignty lives one level above them. It is the ability to keep making the choice.

This also explains why sovereignty should not be treated purely as a security project.

Security teams will naturally care about retention, access controls, data residency and auditability. Infrastructure teams will care about reliability and deployment. Finance teams will care about inference costs. Product teams will care about model quality and latency. Legal teams will care about contracts, regulation and data processing.

A good AI architecture has to accommodate all of them.

The most sovereign deployment is of little value if the model cannot perform the task. The cheapest deployment is not attractive if it exposes information the company considers critical. The best model on a benchmark may be irrelevant if using it creates a dependency the organisation cannot accept.

Sovereignty provides a framework for negotiating those trade-offs rather than pretending one of them should always win.

A practical AI Sovereignty Test

There is a simple way for companies to begin evaluating where they stand today.

Choose one AI workload that already matters to the organisation, preferably something connected to internal data, and follow a single request from the moment the user makes it until the response returns.

Then try to answer seven questions.

1. Do you know exactly what information leaves your environment?

Not only the user's prompt, but retrieved documents, conversation history, system prompts, tool outputs, source code and any other context assembled before inference.

2. Do you know what persists after the request finishes?

This includes application logs, provider logs, prompts, outputs, traces, cached data and conversation history. The answer does not have to be "nothing". It should simply be deliberate.

3. Can you decide where that workload runs?

Could the same application use a hosted API, a zero-retention endpoint, dedicated infrastructure or a model running inside your own environment if the sensitivity of the workload changed?

4. Can you change the model without rebuilding the application?

Some adaptation will almost always be necessary, particularly when applications rely on model-specific capabilities. The question is whether changing models is an engineering task or an architectural migration.

5. Can you control what the model is allowed to access and do?

For agentic systems, the inference endpoint is only part of the security boundary. Tool permissions, data access, execution environments and identity matter just as much.

6. Can you verify the guarantees you depend on?

Some guarantees can come from architecture. Others require contracts, audits or certifications. A company should know which is which rather than relying on assumptions about how a service probably works.

7. If your requirements changed tomorrow, could your architecture change with them?

This is ultimately the question that connects all the others.

A company that cannot answer every question today does not necessarily have an AI security problem. Most organisations are still building this infrastructure, and many workloads simply do not justify the highest levels of control.

But the answers reveal where trust has been delegated and where technical choices are becoming dependencies.

That is useful information to have before those dependencies become difficult to reverse.

How we think about this at Helmcode: our idea of sovereignty

These principles have influenced how we are building Helmcode.

We want companies to be able to use open models without having to become inference infrastructure companies themselves. That means providing the convenience of an API while preserving some of the properties that make privately operated inference attractive in the first place.

One of those decisions is how customer data is handled.

Inference in Helmcode is designed around a zero-logs architecture. Customer prompts and context are processed in memory for the duration of the GPU session rather than accumulated as a historical customer dataset. Customer prompts are not used to train future models, and the inference layer is designed to avoid creating a historical collection of prompt content behind the API.

Our goal is to make zero logs a property of the architecture rather than simply a retention policy.

There is an important difference between promising to delete customer data later and designing a system so that there is as little customer data as possible to retain in the first place.

Architecture, however, does not remove the need for trust.

Customers still have to trust us to operate the infrastructure we describe, which is why technical guarantees should be accompanied by independent verification rather than treated as a substitute for it. We are working through that process, including external certification around how we manage data and infrastructure.

Nor do we believe every workload needs to run through Helmcode.

There will be workloads for which a proprietary frontier model is the right choice, workloads where an open model provides better economics, and workloads whose sensitivity justifies infrastructure controlled entirely by the company using it.

The architecture we believe in is one where those decisions do not have to be permanent.

AI is becoming too deeply embedded in companies for inference to remain an implementation detail. Models increasingly sit between employees and documents, developers and code, agents and internal systems.

As that happens, the question of where intelligence runs becomes part of the architecture of the company itself.

The objective of AI sovereignty is to know where your intelligence runs, understand what you are delegating and retain the ability to choose differently when it matters. It is not a retreat from external infrastructure, and it does not mean keeping every token inside your own building.

The goal is not to eliminate trust from AI infrastructure. That would be impossible. It is to understand where that trust exists, reduce it where the workload requires it, and preserve the ability to change the architecture when the answer changes.

The companies that achieve that will still depend on AI providers.

They just won't have to depend on any one of them. They will be able to choose.

Notes

Calls [1] to [5] in the text refer to these sources, all consulted on 15 September 2026.

[1] Palantir pressed Anthropic for irrevocable zero-data-retention guarantees before making its models available through Palantir's software; NVIDIA limits the use of Anthropic's models to less sensitive tasks and relies on its own Nemotron models for internal work; Booz Allen barred employees from using Anthropic's commercial model for proprietary cybersecurity work. Reuters, 14 September 2026, on an exclusive by The Information: Palantir, Nvidia curb AI model use over data fears .

[2] OpenAI states that data sent to its API is not used to train or improve its models unless the customer explicitly opts in to share it, and that abuse monitoring logs are generated for all API usage and retained for up to 30 days unless longer retention is required by law. Zero data retention excludes customer content from those logs and is subject to prior approval by OpenAI: Your data, OpenAI API .

[3] Anthropic offers zero data retention for the Claude API and states that conversation content is not retained by default, but coverage is defined feature by feature: features that store jobs, files or container state fall outside it, and using one is, in Anthropic's own words, a choice to step outside your ZDR arrangement for that specific data: API and data retention .

[4] Zero data retention does not mean nothing is logged. OpenAI documents that abuse monitoring logs may contain metadata derived from customer content, such as classifier outputs, and that system data is processed separately. Anthropic documents that if metrics logging is enabled in Claude Code, productivity data is exempted from zero data retention and may be retained. The useful question is what is not retained, rather than whether the ZDR label appears in the contract.

[5] The conditions depend on the model and the product, not only on the provider. Anthropic designates Claude Fable 5, Fable 5.1, Mythos 5 and Mythos 5.1 as Covered Models: they require 30-day retention to support safety work on every platform where they are offered, and they are not available under zero data retention unless expressly authorised, a policy in effect since 9 June 2026. The Claude Teams and Claude Enterprise interfaces are not ZDR-eligible either. This is why you cannot simply write that Anthropic retains your data: Data retention practices for Covered Models .