Once an AI agent is connected to your enquiries, CRM or document store, your data no longer lives in one place. The customer record sits in the CRM, the text of their message goes to a model, a copy of the conversation stays in the logs, and the reply lands in WhatsApp or Telegram. Ask a supplier where the data is kept and the answer is usually "in the cloud". This article shows how to break an automation down into specific storage points, what to ask about regions and retention, how to build an access map, and what you can verify yourself before go-live.
If you are working with personal data from Uzbekistan, the legal side is covered in our article on Uzbekistan's personal data law and AI automation. This piece is about the technical side: what physically sits where.
"In the cloud" is not an answer
The cloud is someone else's servers, in a specific country, run by a specific company, with specific people who can get in. For every point your data passes through, you need three facts:
- Where: the provider and the region where data is stored and where it is processed. These are not always the same — data may rest in one region while a model processes the request in another.
- How long: the retention period, and what happens afterwards — deletion, archiving or anonymisation.
- Who: which accounts have access, with what permissions, and who grants and revokes them.
If a supplier cannot answer these for each point, nobody has drawn the data map yet. That is rarely bad faith; usually it simply has not been done. It should be done before launch.
The five places your data ends up
Take a typical setup: an agent that answers enquiries in a messenger and logs them in the CRM. Here is the map for that illustrative case. Replace the entries with your own systems.
| Point | What is stored | Physical location | Retention | Who has access |
|---|---|---|---|---|
| Source system: CRM, spreadsheet, ERP | Customer records, deals, history | CRM vendor's cloud or your own server | Until you delete it | Your staff plus the agent's service account |
| Integration server (orchestrator) | Intermediate data, queues, credentials | A cloud server in a chosen region | Whatever is configured — often indefinite by default | Whoever administers the server |
| Language model (API) | Request and response text | The model provider's data centres | Per the provider's terms, usually limited | The provider, under its own rules |
| Logs and knowledge base | Conversation copies, document fragments, vector index | Alongside the integration server or a separate database | Often indefinite unless configured | Developers, sometimes the whole supplier team |
| Channel: WhatsApp, Telegram, email | The conversation with the customer | The messaging platform's servers | Per the platform's rules | Bot admins, staff in the chat |
The most overlooked row is logs. The model provider discards the request after its retention window, the CRM is protected by roles, yet the server logs hold six months of full conversations with phone numbers, readable by anyone who logs in to debug.
Regions: what to choose and what to check
For the integration server and databases, the region is chosen explicitly when the resource is created. Major cloud providers offer UK, EU, US, Middle East and Asian regions, so for a UK or Gulf business there is usually a local option.
Models are harder, because the provider decides which data centre handles a request. Some providers offer region selection to business customers. OpenAI, for example, lets eligible API customers enable European data residency, but only when creating a new project — an existing project cannot be switched. Terms change, so check the provider's current documentation at the point of signing rather than a blog summary, including this one.
Three things you can check yourself:
- In the cloud console: which region the server and database are in. It is shown on the resource page.
- In the model account: whose name it is registered in, what region the project uses, which retention settings are on.
- In the contract: whether every sub-processor is named, with its country.
Retention: where data stays longer than you think
API model providers do not, by default, train on business customers' data, and they keep requests for a limited period for abuse monitoring. OpenAI's default is up to 30 days, with zero data retention available subject to approval (OpenAI documentation). Other providers have their own terms; take them from the source and write them into your map.
More often the problem is your own plumbing:
- Debug logs switched on during development and never switched off.
- Conversation history kept for context — the agent needs recent messages, not three years of them.
- Uploaded documents left in storage after newer versions replaced them.
- Backups that keep a deleted record alive for months.
The fix: give every row of the map a retention period and automate deletion. For instance, full transcripts for 90 days, after which only the summary stays in the CRM; logs with names and phone numbers masked before they are written. These numbers are placeholders — set your own.
The access map
| Account | System | Permissions | Granted and revoked by |
|---|---|---|---|
| Agent service account | CRM | Create leads, change stage; no delete, no bulk export | Your CRM admin |
| Model API key | Model provider | Model calls only, a separate project per process | Account owner — ideally you |
| Supplier engineer | Integration server | Named account with multi-factor authentication | You; revoked when work ends |
Three principles worth putting in writing. Accounts belong to you: the cloud server, the model account and the bot are registered to your company, and the supplier is given access. Least privilege: an agent that records enquiries does not need to export the customer base. Named accounts, no shared passwords, so the audit trail shows who did what and one person's access can be removed cleanly.
How we handle this on our own projects — DPAs, UK and EU transfer safeguards, access controls and human approval — is set out on our security and data page.
A pre-launch plan
- Trace one enquiry end to end: which systems the text and fields pass through.
- Fill in the data map: point, contents, region, retention, access.
- Strip what the model does not need. Answering "do you deliver on Saturdays?" requires no date of birth.
- Set retention and automatic deletion for logs, history and documents.
- Register accounts to your company and give the supplier named access.
- Write sub-processors, regions, retention and post-contract deletion into the agreement.
- A month after launch, check that deletion runs and logs contain no phone numbers.
These points make good questions for a first supplier meeting; see how to choose an AI automation vendor and the rest of the implementation section.
FAQ
Can we keep all data inside the UK or EU?
For servers and databases, yes — choose that region. For the model, it depends on the provider and your plan; some offer regional processing for business accounts. Where that is not available, send the model de-identified text only.
Does the model learn from our conversations?
Through the API, major providers do not train on business customers' data by default. That does not cover staff pasting customer data into a free consumer chatbot — that is a matter for your internal policy.
What happens to our data if we stop working with the supplier?
Agree it upfront: the deadline for deleting copies, what is handed over to you, and how deletion is confirmed. If the accounts were yours from the start, most of the question answers itself.
Can you help us map our own process?
Yes. We draw the data and access map at the start of every AI agent project. Get in touch and we will look at which data the agent genuinely needs and which can stay where it is.