If you ask a coding agent to fix an authentication bug, very little appears to happen from where you sit. You write a sentence, wait a few seconds and get an answer back.
The request the model receives can look very different.
Before inference, the agent may read the authentication implementation and several related files, inspect an error log, pull package information and include relevant parts of the earlier conversation. Alongside all of that can travel a system prompt, instructions added by your organisation and results returned by tools the agent has already used.
By the time the model runs, the sentence you wrote may be the least interesting part of the request.
None of this is particular to coding agents. A support assistant does the same thing: it combines a question with the customer's history and internal documentation. A knowledge system retrieves fragments of company documents. An agent queries an internal API and uses the result as context for its next decision.
All of this is useful. In fact it is largely the point, and it is why LLMs give us such good results.
Useful AI needs context. It may have it close at hand, in your own documents, or it may have to go out and find it.
So what happens to that context once the model has gathered everything and needs to think? Where does it go?
Picture your coding agent running on your laptop. The repository is there. The logs it inspected are there. The company controls that environment.
Then the agent gathers everything it considers relevant and sends an inference request to an external model.
Somewhere between those two systems something important has changed. Information governed by your infrastructure is now being processed inside infrastructure governed, at least in part, by someone else.
That line, which we are almost never aware of, matters.
It is the trust boundary.
The trust boundary you do not see
Trust boundaries are not new. Companies cross them constantly when they push code to GitHub, put customer information into Salesforce, deploy infrastructure on AWS or charge through Stripe. Modern software is built on delegation, and using infrastructure operated by another company is not in itself a security failure.
What matters is understanding what you have delegated, and under which conditions.
AI makes that harder to see because the boundary usually sits hidden behind an application.
When someone uploads a file directly to an external service, the movement of information is obvious. When an agent autonomously reads twelve files, selects fragments from four of them, combines them with tool results and sends the resulting context to a model, it is far less so. And it does it so easily and with so little friction that sometimes you never stop to think about it.
The interface can stay entirely inside your product while the full context crosses several infrastructure boundaries behind it.
This distinction matters because the visible prompt is not necessarily the data boundary.
The real boundary surrounds the entire inference context.
Follow the context like a trail of breadcrumbs
A useful way to understand an AI system is therefore to stop looking at the chat box and follow the context.
Where does it start?
What can the application retrieve?
What does it select?
What gets assembled before inference?
What crosses into another environment?
And what stays there afterwards?
Think about an internal support agent. The employee might ask:
Why can this customer not renew their subscription?
To answer, the system might retrieve the customer's account data, their billing status, previous support conversations and internal documentation before calling a model.
The user only sends one sentence.
The inference request contains a small representation of the company around that sentence.
This is increasingly how AI applications work. Context is gathered dynamically from the systems around them, which means a company's AI data surface is no longer limited to the information employees consciously decide to share.
It is determined, in part, by architecture.
What happens on the other side: no training, Zero Data Retention and private inference
Understanding what crosses the boundary is only half the problem. What happens once it has crossed?
Your prompt, with all its context, reaches the model. The model answers. And now, what happens to all that data that has been sent into someone else's infrastructure?
This is where several guarantees that often get treated as interchangeable have to be separated.
- Data is not used to train models. That answers an important question about training, but it does not tell you whether a request is retained temporarily, whether the content enters operational systems, or under what circumstances staff can access it. [1]
- Zero Data Retention is a different thing. It changes what persists after processing, depending on the specific product and configuration. There is usually still some minimal logging for safety, but it is the guarantee that most reduces what is left of your request on the other side. [2]
- Private inference. Dedicated or customer-controlled inference changes another part of the architecture: where processing happens, who operates the infrastructure and which controls remain under the customer's authority. Together with Zero Data Retention, it is the combination that keeps your information inside a perimeter you choose. It is the architecture the Helmcode platform is designed around.
No training, Zero Data Retention and customer-controlled inference describe different parts of the trust boundary.
That is why labels like "enterprise AI" or "private AI" are less useful than understanding the architecture behind them. The right guarantee depends on the workload.
Start with the workload
Teams naturally start by asking which model performs best. For an experiment, that is usually enough.
But once an AI system starts working with company information, there is a question worth answering before looking at the leaderboard:
What will this system be able to see, and how far are we willing to let that information travel?
A public content assistant and an agent with access to unreleased source code should not necessarily inherit the same infrastructure decision just because both need an LLM.
Define the acceptable boundary first. Then, inside that boundary, pick the best model for the job.
Capability, latency and cost still matter. They simply operate inside constraints the company has chosen deliberately.
As agents reach more tools, repositories, databases and internal systems, this distinction will matter more. The question companies are asking right now is how much of my information reaches the model when I call it.
That question is no longer answered by reading the prompt. It is answered by looking at the architecture.
Read more: AI Sovereignty: who controls your company's intelligence? covers the other half of this conversation. Where your intelligence runs, what exactly you are delegating, and how to keep the ability to decide differently when it matters.
Notes
References [1] and [2] in the text correspond to these sources, consulted on 17 September 2026.
[1] 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 detection logs are generated for all API use and retained for up to 30 days, unless the law requires longer: Your data, OpenAI API .
[2] 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: those that store jobs, files or container state fall outside the agreement for that specific data: API and data retention .
