In the TV series Severance, employees split their memories between work and the outside world. When they enter the office, their “work self” wakes up with only work memories. When they leave, that version switches off, and their outside self has no memory of what happened at work.
Strange as it sounds, that is a useful way to think about many AI sessions.
A common customer fear is that AI works like one giant shared brain. You send it your supplier list, pricing model, sales forecast, or customer contract, and later another customer — or worse, a competitor — somehow gets a piece of that information back.
That fear is understandable. Business data is not casual information, and it should be protected accordingly. But the fear is often aimed at the wrong mechanism.
The AI Only Sees What It Is Given for That Session
People often talk about “the AI” as if it is one being.
That is a natural way to speak. We ask it questions and it answers. It appears to have a personality, and even remembers tidbits from earlier conversations. So it is easy to imagine that somewhere, there is one giant AI mind collecting everything from everyone.
But that is not how AI memory usually works.
A large language model (LLM) is the engine behind tools like ChatGPT. It does not begin each session knowing every company that has ever used it. Instead, it answers based on the information provided to it for that specific session. That information may include your question, previous messages in the same chat, uploaded documents, system instructions, records retrieved from a database, or outputs from connected tools.
If your supplier contract was introduced in that session, the model can read it and reason over it. If not, the model does not magically know it.
This is the important distinction: the LLM generates the answer, but the surrounding system decides what information is handed to it. So the risk is not usually that the model is secretly carrying your company’s files into another company’s chat. The risk is whether the system hands it the wrong information in the first place.
Memory Is Not Magic. It Is Something We Build.
Some AI systems do have memory, but that memory is usually built deliberately. It is storage and retrieval, not accidental magic.
The system may store useful things like chat history, user preferences, or documents in a knowledge base. It may retrieve data from a CRM, ticketing system, or shared drive. But none of this happens by itself.
Take a simple example. A customer asks, “What is the status of this order?” The system checks the order database, retrieves the relevant record, and passes it into the model. The model then explains the answer in plain language.
The model is not remembering all of this. The system is fetching the relevant information and handing it to the model for that moment.
So the real question is not, “Does the AI remember our data?” The better question is, “What does the system store, retrieve, and show to the AI later?”
The Leak Happens When the System Pulls the Wrong Data
This doesn’t mean that data leakage isn’t real. It just means the leak risk sits in a more specific place, and that it can be managed with good design.
The real danger is not usually that the LLM casually remembers one customer and tells another. The real danger is that the system around the model retrieves the wrong information, stores sensitive information carelessly, or gives the AI broader access than it needs.
Imagine a company uses an AI sales assistant with customer-specific price lists. Customer A has negotiated special rates, while Customer B has different terms. The leak does not happen because the model “remembers” Customer A’s pricing like a person remembering gossip. It happens if the system wrongly retrieves Customer A’s price list and shows it to the AI during Customer B’s session.
That is not AI becoming conscious. It is bad filing, bad access control, or bad retrieval. These are real risks, but they are not mystical risks. They are system design risks.
Ask What Gets Sent, Stored, and Retrieved
A serious AI implementation needs clear boundaries around data. The guiding principle is simple, and it is one IT teams have practiced for decades: give the model the least necessary context. If the AI only needs an invoice total, do not send the full contract. If the user is from Department A, do not let the system retrieve Department B’s documents unless there is a reason.
This is not glamorous stuff that gets shown in demos, but it is what determines whether an AI system is safe enough for real operations.
Vague reassurance is cheap: anyone can say, “Your data is safe with us.” Data flow is harder to fake. A serious vendor should be able to explain plainly what goes in, where it goes, what gets stored, what gets retrieved, and who can access it.
The Point Is Control, Not Blind Trust
Customers are right to be careful with company data. Pricing, payroll, contracts, customer lists, supplier terms, financial records, and internal policies should not be casually pasted into any tool just because it has an AI label.
But the right response is not to treat AI as one mysterious shared brain. The right response is to ask how the system is designed.
A serious AI vendor should be able to explain what data is sent to the model, what is stored, what is retrieved later, who can access it, and how customer data is kept separate. If the answer is vague, that is the warning sign.
Each session may wake up fresh, like the “work self” in Severance. But someone still decides what information that session is given. In business AI, trust does not come from the model sounding intelligent. It comes from the system being designed with clear boundaries.