AI data security: where business content really goes

What AI data security actually means#

AI data security means knowing three things: what content the system may read, where that content gets processed, and whether anyone may keep it afterwards. Every other question on this topic is a version of one of those three.

This decision already gets made several times a year. Books handed to an external accountant are read in full. They work under a contract, and they do not repeat those figures to their other clients. Choosing who processes content for an AI assistant is the same kind of decision rather than a new category of risk.

Two problems that get treated as one

Business content and customers' personal data raise different questions, and merging them is why the topic feels harder than it is.

• Business content. Price lists, procedures, contract terms and internal instructions. The risk here is commercial, and it comes down to who else could read the prices.
• Customer personal data. Names, phone numbers, order histories, and in some sectors health details. The risk here is legal, and data protection law governs what may be done with it.

The first problem is settled by a contract and by control over who has access. The second needs the short list of paperwork covered further down, most of which already exists, prepared for other systems.

Where the leak usually comes from

In our experience the most common data leak in a small company has nothing to do with an assistant. An employee pastes a customer email into a free public chatbot to draft a faster reply, and nobody records that it happened.

That habit is already established in most companies before any AI project starts. It is unmonitored, undocumented, and far more exposed than a tool bought under contract. A sanctioned tool tends to suppress it, because people improvise less when something approved is available.

Where content goes when a customer asks something#

Content goes to a model provider, is read to produce that answer, and does not become part of the model. Under a business agreement it is not used to train models other people use, and it is not exposed to that provider's other customers.

That is the accurate version, and it is worth understanding the mechanics rather than taking any vendor's word for it. Four steps happen between a question and an answer.

1. 1A customer asks a question. The question reaches the assistant, not the model behind it.
2. 2The system searches the approved content. It pulls out the few passages that look relevant to the question.
3. 3Those passages and the question go to the model provider. This is the step people worry about, and the one worth asking about.
4. 4The answer comes back and is shown. Under a business agreement the passages are not added to any model, and the provider keeps them only for the window the contract sets.

Most business agreements now exclude training on customer content. That holds because the contract says so, not because of anything in the technology, and terms differ between providers. Ask for the exclusion in writing, and check that it appears in the contract actually being signed.

Training, retention and logs are three different things

Three separate questions get bundled under the word "storage", and separating them makes the vendor conversation much shorter.

• Training. Whether the text is used to improve a model that other people use. Business agreements normally exclude this, so read the clause rather than trusting the summary.
• Retention. How long the provider holds the text after answering. Expect a defined window measured in days, and longer if something is flagged or a legal hold applies.
• Conversation logs. What the assistant itself keeps so its answers can be reviewed. This part belongs to the business, and it is where personal data actually accumulates.

Zero retention exists as an option, but it is requested and confirmed in writing. It is not a default and should not be assumed.

The third item gets overlooked, and it is the one entirely within the client's control. The logs in the first week show what the system really does. The guide on accurate AI answers explains what to look for.

What the rules actually require#

The rules do not ban AI, and most of the paperwork is the same as for any other supplier. Two things are specific to AI, and one of them applies from August 2026.

The controller is the business

The business decides why the data is processed and broadly how, which makes it the controller. The vendor is the processor, acting on written instructions. It also carries its own duties for security and for reporting when something goes wrong.

That structure is ordinary. An accountant, a payroll bureau and an email provider stand in the same relationship to a business. None of them requires a change to how it operates, and neither does this.

What is needed on paper

• A data processing agreement with the vendor, naming every subprocessor, with a transfer safeguard if any of them sits outside the EU.
• A line in the privacy notice telling customers that an automated assistant handles enquiries.
• An entry in the record of processing activities, alongside the entries for other systems.
• A route to erase one customer's conversation history when they ask for it.
• An impact assessment, where the processing is large scale, covers sensitive data, or is otherwise high risk.

Most of that copies what already exists for the CRM. Where there is no privacy notice at all, that gap exists with or without an assistant, and it is worth closing either way.

Telling people they are talking to a machine

Since 2 August 2026, the EU AI Act requires that people be told when they are interacting with an AI system. The duty applies unless that is already obvious, and it covers businesses of every size.

In practice this is a label on the chat window and an opening line from the assistant. It is the cheapest obligation on this page to meet, and the easiest to forget.

Five questions to put to any AI vendor#

Ask these before signing, and ask for the answers in writing. A vendor who cannot answer all five in a single email is not ready to handle customer information.

1. 1Which subprocessors handle our content, and in which countries? Names and locations, not a reference to the cloud.
2. 2Is our content used to train any model, and does the contract say so? A verbal assurance here is worth very little.
3. 3How long is our text kept after an answer is produced? Ask for a number in days. A description of good practice is not an answer.
4. 4How do we delete one customer's history, and how do we export everything if we leave? Ask for the actual steps.
5. 5Can we see the processing agreement before signing? A refusal settles the decision.

One more question belongs in the same email, and it is the one vendors answer least precisely. Ask who on their side can read the conversations, and whether every such access is logged. Support access is normal, and support access that leaves no record is not.

Notice that none of these five questions is about AI. They are the questions for any supplier holding customer records, which is the point of asking them.

What stays with the business#

A contract covers the vendor. It does not cover what happens inside the office, and that is where most incidents start, in our experience.

• Access to the conversation history. Grant it to the people who need it, and remove it as soon as someone leaves.
• Staff pasting into public tools. Write the rule down, since this is the leak nobody records.
• Personal data in old documents. Check the old quotes and case notes, because they get indexed along with everything else.
• The limits of the assistant itself. Decide what it may never discuss, such as another customer's order.

In our experience, the last one is the item most often missed. A system connected to every order can answer a question about somebody else's order unless that boundary is set. Nothing in the technology sets that limit on its own.

Give the system less to protect

The cheapest security measure is not putting personal data into the system at all. An assistant answering questions about opening hours, services and prices has no need for a customer list.

Names, contact details and case histories come out of the indexed content. Deciding which sources belong in scope is covered step by step in the guide on preparing your content for an AI assistant.

Deciding those limits, writing them into the configuration and testing them before customers arrive is work we do for our clients. We also handle the processing agreement and the subprocessor list, and we run the assistant on an external model provider with processing in the EU. In more sensitive settings, such as an AI assistant in healthcare, we agree the boundaries in writing with the client before go-live.