Is It Safe to Give AI Access to Your Data?

It is usually safe to give AI access to your data through a business or API account, and considerably less safe through a free consumer chat account. That single distinction explains most of the difference in risk, and it is the one people skip. The same company can treat the same sentence completely differently depending on which door you walked through.

This is a walkthrough of what the major providers actually say in their own documentation, checked on 2 August 2026, and the five questions worth asking about any AI tool before you paste anything into it.

The consumer and business split

Every large provider runs two regimes. The consumer product is free or cheap, and the terms reflect that. The API and business tiers cost money, and the terms are meaningfully stronger.

Two concrete examples, both from the vendors' own docs rather than a roundup.

OpenAI's API. Data sent to the OpenAI API has not been used to train or improve its models by default since 1 March 2023, unless you explicitly opt in. Abuse-monitoring logs are kept for up to thirty days unless longer retention is legally required. Approved customers can enable Zero Data Retention, which excludes their content from those abuse logs entirely, per OpenAI's data controls documentation.

Anthropic's consumer Claude. Anthropic changed this in August 2025: consumer chat data is now used to improve Claude by default, and you have to turn the setting off if you do not want that. If training is enabled, de-identified data can sit in training pipelines for up to five years; turning it off keeps the standard thirty-day retention. Deleted conversations come out of backend systems within thirty days, and incognito chats never participate in training regardless of the setting, according to Anthropic's privacy documentation.

Worth flagging: this was opt-in when Claude first launched, so older summaries describing it that way are describing a policy Anthropic retired in August 2025. Check the Model Improvement toggle in your own account rather than trusting either an old guide or this one, since account-level settings can also override the account default.

The pattern generalises. Paid business tiers buy you shorter retention, exclusion from training, an audit trail, and usually a data processing agreement. Free consumer tiers buy you none of that reliably.

The five questions

Whatever the tool, these five answers determine your actual exposure. All five should be findable in public documentation. If any of them is not, that is itself an answer.

1. Is my input used to train the model?

The one everyone asks. Default answers vary by tier, and "we do not train on your data" sometimes means "not by default" and sometimes means "not contractually, ever". The difference matters if you handle client work.

2. How long is it retained, and who can read it?

Retention is the question that actually bites, because it governs what is exposed if the provider is breached. Note that "we do not train on it" and "we store it for thirty days" are both true simultaneously at most providers. Anthropic's commercial products, for instance, retain data indefinitely by default unless a custom retention period is configured, with a thirty-day minimum on Enterprise plans.

3. Do humans ever see it?

Most providers reserve the right to have staff review flagged content for abuse investigations. This is reasonable and also means "nobody sees it" is rarely literally true.

4. Where does it physically sit?

Relevant for GDPR, for public-sector clients, and for anyone with a data residency clause in a customer contract. Regional processing is usually available on business tiers and rarely on consumer ones.

5. What happens on deletion?

Deleting a conversation in a UI and deleting it from backups are different operations with different timelines. Ask for the second one.

Where the real risk sits

Focusing on training data misses three larger exposures.

Your own team's habits. The most common leak is not a provider misusing data, it is somebody pasting a client contract or a production credential into a free chat account with a personal login and no company oversight. This is a policy problem, not a vendor problem, and it is fixed by giving people a sanctioned tool that is good enough that they stop using the unsanctioned one. A small law firm handling client contracts and confidential filings is a good example of where this shows up in practice; see what that looks like specifically for a small law firm for the concrete list of dos and don'ts.

Agents with live access. Read-only access to a document is one risk profile. An agent with write access to your database, your repository, or your email is another entirely, because the failure mode is no longer disclosure but action. Anthropic's disclosure that its models gained unauthorized access to three organisations during security testing is a useful illustration: the models were doing what capable agents do, in an environment where the boundaries were misunderstood. Scope agent permissions to the smallest set that does the job, and prefer a tool that asks before destructive operations. This is one of the things worth checking when comparing AI coding tools, since they differ a lot in what they can reach.

The third parties behind the tool. Plenty of AI products are a thin layer over somebody else's model. Your data may transit two companies while only one appears in the interface. The subprocessor list, usually linked from the privacy policy, tells you who is actually in the chain.

A workable policy for a small team

You do not need a compliance department. You need four rules people can remember.

1. One sanctioned account per tool, on a paid business tier. The cost is trivial next to the exposure, and it gets you the stronger terms automatically.

2. A short, explicit list of what never goes in. Customer personal data, credentials and API keys, unreleased financials, anything under an NDA that names confidentiality of the form. Keep it to one screen or nobody will read it.

3. Least privilege for anything with access. If a tool only needs to read, do not give it write. If it only needs one folder, do not give it the drive. Revoke integrations you stopped using, because they keep their access quietly.

4. Prefer retrieval over upload for reference material. If the goal is to make a model aware of your documents, a retrieval setup keeps the documents in your storage and sends only the relevant chunk per request. How retrieval-augmented generation works covers the mechanics, and the practical upshot is that you have moved from handing over a library to handing over a page at a time.

What regulation now requires

If you operate in or sell into the EU, the AI Act's transparency obligations became enforceable on 2 August 2026, and they cover disclosure when people interact with an AI system and marking of AI-generated content. That is separate from data protection, which is still GDPR's job. Both apply. The EU AI Act transparency rules covers what changed, and the high-risk deadline post covers what moved.

The practical overlap is documentation. Knowing which providers you use, what they retain, and where it sits is the same evidence base for both regimes, so build it once.

Data access is one risk surface. A separate one worth understanding is prompt injection, where hidden content redirects what a connected AI tool does, regardless of how carefully the data-access permissions were set.

Frequently asked questions

Can I stop AI companies from training on my data?

On business and API tiers, exclusion from training is generally the default and often contractual. On consumer tiers, it is a setting you should check in your own account rather than assume, because defaults differ by provider and have changed over time.

Is it safe to paste client work into ChatGPT or Claude?

Not into a free personal account, unless your client agreement explicitly permits it. On a paid business tier with training disabled and a data processing agreement in place, it is a normal vendor relationship, and many agencies operate this way. The deciding factor is your contract with the client, not the AI provider's terms.

Does deleting a chat actually delete it?

It removes it from your view immediately and from backend systems on a stated timeline, commonly around thirty days. It does not necessarily remove copies retained for abuse investigation or legal hold. Check the provider's retention page for the specific numbers.

Is a self-hosted or open-weights model safer?

For data exposure, yes, because nothing leaves your infrastructure. You take on the security of that infrastructure instead, which is a real cost and a real risk if nobody on the team owns it. It is the right answer for genuinely sensitive workloads and overkill for most.

What is the single highest-risk thing people do?

Pasting credentials, API keys, or connection strings into a chat window. Treat anything you paste into any tool as though it has been logged somewhere, because in most configurations it has been. Recognising the scam patterns around AI is worth a read alongside this, since credential theft is where the two topics meet.

Vetting a tool before you connect it is only the first half of the problem. See what to do if an AI tool leaks your data for the incident response checklist for when it goes wrong anyway.

Related: why AI refuses safe questions