AI assistants make it remarkably easy to analyse a document, summarise a meeting or turn a rough idea into a polished first draft. That convenience can also make it easy to overlook a basic question: what happens to the information you share?
If someone uploads a client document, employee record, contract or commercially sensitive report, where is that information processed? Is it retained? Could it be used to improve the provider’s models? Does using a business account change the position?
The short answer is that the risk depends less on the name of the AI tool than on the particular product, account type, settings and contract being used.
A managed business workspace can provide significantly stronger protections than a personal account. However, no account type makes every upload appropriate. Organisations still need clear rules, sensible controls and people who understand what they should and should not share.
This article provides general information rather than legal advice. Provider information was checked on 21 August 2026, but features, terms and regional availability change frequently, so check the current service documentation and obtain specialist advice where necessary.
Start with the account type, not just the AI tool
When organisations compare ChatGPT, Claude, Microsoft Copilot or Google Gemini, they often focus on which tool gives the best answer. For privacy and security, the more important distinction is frequently between a personal account and a managed business service.
Personal and consumer accounts
Personal accounts are designed primarily for individual use. Depending on the provider, conversations may be eligible for use in improving models unless the user changes a setting or declines consent. Retention periods, administrative controls and contractual protections can also differ from those provided with commercial services.
For example, OpenAI allows consumer users to turn off the use of new conversations for model improvement through its data controls. Anthropic asks consumer users whether they want their data used for model improvement. Microsoft’s approach varies by product and account, with many signed-in consumer Copilot users able to opt out of model training.
This does not mean that personal AI accounts are inherently unsafe. They can be appropriate for low-risk experimentation using public, fictional or properly sanitised information. They should not automatically become the place where staff upload client records, personal data or confidential business material.
Business and enterprise services
Business services generally offer stronger commercial protections. These may include commitments not to train models on customer content by default, administrative controls, single sign-on, security features, audit capabilities, defined retention options and a data processing agreement.
The exact protections still vary by provider and subscription. A self-service business plan may not offer all the controls or regional choices available with a negotiated enterprise service.
For customer content processed solely to provide the service, the customer will commonly be the data controller and the provider its processor. That is not a universal rule. A provider may act as a controller for certain account, billing, security, abuse-prevention or service-administration data. The actual roles should be checked against the contract and data flows.
If you are still deciding which assistant is the best fit, our guide to ChatGPT, Claude and Copilot for business looks at the wider practical differences between the main tools.
What can happen to information you share?
Four separate questions are often bundled together when people ask whether an AI tool is private:
- Training: can the provider use prompts, files or responses to improve its models?
- Retention: how long are prompts, outputs, logs and deleted content kept?
- Access: in what circumstances could authorised personnel or subprocessors access the information?
- Location: where is the information stored and where is the model processing performed?
A strong answer to one of these questions does not automatically answer the others. A provider might promise not to train on business data but still retain limited safety logs. It might offer UK storage while processing model requests elsewhere. A service may also pass information to external integrations, search services or connected applications operating under their own terms.
Model training
Business offerings from the main providers typically state that customer prompts and outputs are not used to train their general models by default. This is an important protection, but it should be confirmed for the exact service being purchased rather than inferred from the provider’s brand name.
Consumer services operate differently. Their settings and privacy choices can change, and users may have different options depending on their age, country, account status or product. Organisations should therefore avoid basing a company-wide policy on the settings visible in one employee’s personal account.
Retention and human access
“Not used for training” does not necessarily mean “never retained”. Information may be held for normal service delivery, security monitoring, legal compliance, support or investigation of suspected misuse. Some providers offer shorter retention periods or zero-data-retention arrangements for eligible API and enterprise customers, but exceptions can apply to particular features or models.
Providers generally restrict human access to limited authorised circumstances. Even so, confidential or personal information should only be shared when the organisation is satisfied that the service, contract and internal controls are appropriate.
Storage, processing and data residency are different
Data residency is often discussed as though it were a single setting. In practice, at least three locations may matter:
- where prompts, files and responses are stored
- where model inference—the processing that generates the answer—takes place
- where supporting activities such as authentication, routing, monitoring and technical support occur
A service can therefore offer storage in one region without guaranteeing that every aspect of processing remains there.
Can AI processing remain in the UK or Europe?
UK and European options do exist, but availability varies by provider, plan, model and deployment.
OpenAI currently offers UK storage for eligible ChatGPT workspaces. However, its supported ChatGPT inference regions are Europe—the EEA and Switzerland—the United States and the United Arab Emirates. It does not currently offer UK-specific ChatGPT inference residency. OpenAI also makes clear that some non-GPU processing and external integrations may operate outside the selected region. See OpenAI’s current data and inference residency guidance.
Anthropic states that data from its commercial services is generally stored in the United States. However, it may process customer traffic in selected countries in Europe and other regions, and traffic-routing choices are available to some Developer Platform and usage-based Enterprise customers. It is therefore no longer accurate to describe all Claude inference as US-only. See Anthropic’s server and processing-location guidance.
Microsoft Azure, AWS and Google Cloud provide further regional deployment choices. Depending on the model and configuration, Azure can process requests in a selected region or within an EU DataZone. AWS Bedrock supports in-region and geographic processing options, while Google Vertex AI offers regional and EU endpoints for supported services.
UK-only processing may be possible for some cloud deployments using London regions. It should not be promised without checking the availability and behaviour of the particular model, deployment type, safety services and connected features.
The practical lesson is to ask separately:
- Where is our content stored?
- Where does model inference take place?
- Are prompts or outputs copied elsewhere for safety monitoring?
- What happens when web search, connectors or other integrations are enabled?
- Does the location commitment appear in the contract, or only in general product information?
Does international processing make AI use unlawful?
No. Processing personal data outside the UK is not automatically prohibited.
Where UK data protection law applies, the organisation needs an appropriate lawful basis for the processing. If the arrangement involves a restricted international transfer, the party responsible for initiating that transfer must also identify an appropriate transfer mechanism or safeguard.
Depending on the destination and circumstances, that might include UK adequacy regulations, the UK International Data Transfer Agreement or the UK Addendum to the EU Standard Contractual Clauses. A transfer risk assessment may also be needed.
The contract with the provider is only part of the picture. Organisations should also consider data minimisation, security, transparency, retention, individual rights and whether the proposed use is compatible with the reason the information was originally collected.
The Information Commissioner’s Office provides current guidance on international transfers under the UK GDPR.
What about private or self-hosted AI?
Organisations with particularly strict security, confidentiality or sovereignty requirements may consider running an open-weight AI model within their own infrastructure or private cloud environment.
This can provide greater control over where information is processed, who can access it and how long it is retained. Models from providers such as Mistral, Meta, IBM, Google and Microsoft can be available for private deployment, subject to their individual licences and technical requirements.
Greater control also means greater responsibility. The organisation must manage infrastructure, security, updates, monitoring, model quality, access controls and specialist support. A privately hosted model can still create privacy or security problems if it is poorly configured or given excessive access to internal data.
For many businesses, a properly configured enterprise service will offer a better balance of capability, control and operating cost. Private deployment becomes more attractive where the information is highly sensitive, regulation is strict, workloads are substantial or the organisation already has the technical capability to run it safely.
Is a business AI account suitable for confidential or personal data?
Potentially—but only with appropriate due diligence and controls.
| Type of information | Practical approach |
|---|---|
| Public or low-sensitivity information | Generally suitable for approved AI tools, subject to normal accuracy and usage checks. |
| Ordinary internal business information | Use an approved business workspace with appropriate contractual, security and administrative controls. |
| Personal data | Confirm the lawful basis, minimise what is shared, check the provider arrangement and consider whether a DPIA is required. |
| Special-category, regulated or highly confidential information | Do not upload by default. Carry out a formal review and consider a more tightly controlled or private environment. |
The appropriate answer depends on the purpose, sensitivity, people affected and consequences if the information were exposed or used incorrectly. Client contracts, professional duties and confidentiality obligations may impose restrictions beyond data protection law.
Before uploading information: a practical checklist
Before staff share documents or data with an AI assistant, ask:
- Are we using the organisation’s approved account? A managed business workspace is different from an employee’s personal subscription.
- Do we need to include this information? Remove names, identifiers and unnecessary detail wherever possible.
- Is the use lawful and fair? Confirm the purpose and lawful basis where personal data is involved.
- What do the current terms say? Check training, retention, access, subprocessors, deletion and regional processing for the exact plan.
- Do we have the right contractual protections? This may include a data processing agreement and appropriate international-transfer provisions.
- Could the output affect someone significantly? Decisions involving employees, customers, finance, health or access to services may require additional scrutiny and human oversight.
- Would we be comfortable explaining this use? If the organisation would struggle to explain the processing to a customer, employee or regulator, it probably needs further review.
Anonymisation can reduce risk, but simply removing a person’s name may not be enough. A combination of job title, location, circumstances and other details can still identify someone. Redaction should therefore be deliberate rather than cosmetic.
Common mistakes
Assuming a paid account is automatically a business account.
A personal subscription may offer more features without providing organisational administration or the commercial terms needed for workplace use.
Treating “not used for training” as the whole privacy answer.
Retention, regional processing, logging, integrations and human access still need to be understood.
Writing a policy without giving people an approved alternative.
If staff are told not to use public tools but are not given a practical, authorised service, unmanaged use is likely to continue.
Relying on anonymisation without checking whether someone remains identifiable.
Context can reveal identity even when obvious fields have been removed.
Focusing only on the provider.
Weak internal permissions, excessive access, poor data quality and untrained users can create as much risk as the AI platform itself.
Common questions
Can AI providers use our prompts to train their models?
It depends on the product, account and settings. Managed business and enterprise services generally state that customer content is not used to train their general models by default. Consumer services may use conversations for model improvement subject to their current settings and privacy choices.
Can we keep all of our AI data in the UK?
Sometimes, for particular cloud deployments and supported models. However, UK storage does not necessarily mean UK-only inference or UK-only supporting operations. Obtain a precise description of storage, inference, logging, support and integration data flows before relying on a residency claim.
Is it safe to upload confidential information?
Not by default. It may be appropriate within an approved business service after reviewing the sensitivity, purpose, contract, security controls and relevant legal or professional obligations. Highly sensitive information should receive a formal assessment before use.
Do we need a data protection impact assessment?
A DPIA is required where processing is likely to result in a high risk to individuals. It may be appropriate where AI uses sensitive information, evaluates or monitors people, operates at scale, combines datasets or contributes to significant decisions. The ICO provides guidance on when and how to complete a DPIA.
A practical way forward
The aim is not to prevent people from using AI. It is to make useful adoption easier while putting proportionate controls around the information involved.
Start by defining approved tools and account types. Give people straightforward guidance on what they may share, what they must not share and when they should ask for help. Review the provider’s current terms, understand the data flows and introduce stronger assessment for higher-risk use cases.
Technology is only part of the answer. Effective adoption also requires governance, training and clear ownership. Mavents can help through AI Governance & Risk, GenAI training for business teams and AI Strategy & Roadmapping.
The most useful rule is also the simplest: before sharing information with an AI tool, understand the account you are using, the data you are sharing and the controls that apply to both.