Is ChatGPT Safe for Company Data? The Answer Your Auditor Wants

Direct answer: The business and enterprise tiers of the major AI providers contractually exclude your inputs from model training and are defensible for most company data. The free consumer tiers are not, and neither is any of it for customer personal information unless you have checked your own contracts and privacy notice first. The bigger risk is that you have no policy and no idea who is using what.

The tier distinction matters more than the vendor

Paid business tiers generally offer data processing terms, no training on your inputs, retention controls and administrative visibility. Consumer tiers historically train on inputs by default. Same brand, materially different obligations, and staff cannot be expected to know which one they signed into.

What your own contracts say

This is where it usually breaks. Your customer agreements probably name your subprocessors and commit you to notifying changes. If an employee pastes customer data into a tool that is not on that list, you may have breached a contract regardless of how safe the tool is. Under PIPEDA and Quebec's Law 25 there are transfer and accountability obligations on top.

So the question is not really "is it safe". It is "is it a disclosed subprocessor, and does our privacy notice cover it".

What auditors and buyers now ask

Whether you have an acceptable use policy for AI. Which tools are approved. How you prevent customer data reaching unapproved ones. Whether staff have been told. Whether AI vendors go through the same vendor risk process as any other processor. A shrug is a finding, and it is showing up in enterprise questionnaires routinely now.

Shadow AI is the real exposure

The tool your policy covers is rarely the problem. It is the browser extension, the personal account, the AI feature quietly switched on inside a SaaS product you already use. Most companies underestimate their usage by a wide margin because they only count what they pay for.

A position that survives review

Approve a small number of business-tier tools. Write a short acceptable use policy saying what may and may not be pasted, with customer personal information as a clear no unless the tool is a disclosed subprocessor. Put AI vendors through vendor risk. Tell people, once, in plain language. Then check what is actually being used rather than assuming.

Our free AI acceptable use policy generator produces the policy, the shadow AI risk checker finds the usage you do not know about, and the Shadow AI Audit is the engagement version when the answer needs to hold up in front of a buyer.

The contract terms worth reading before you decide

"We do not train on your data" is the headline every provider leads with, and it is usually true on the paid business tiers. It is also the least interesting clause. The terms that determine whether you can defend the tool in front of a buyer or a regulator sit further down.

Retention. Most business tiers retain inputs and outputs for a period, commonly thirty days, for abuse monitoring, even where training is excluded. Some offer zero-retention arrangements on request or on specific API endpoints. If you are processing anything sensitive, find out which applies to you, because "not used for training" and "not stored" are different promises and only one of them answers a data subject access request.

Human review. Abuse-monitoring pipelines can involve staff reading flagged conversations. That is a legitimate control on the provider's side and a disclosure obligation on yours. If your privacy notice says personal information is only accessed by your own staff and your processors, and a provider's reviewers can see flagged content, the notice is inaccurate.

Processing location. Ask where inference runs and where logs are stored. For Quebec organisations this connects directly to the Law 25 assessment obligation for transfers outside the province, and for anyone with public-sector or financial-services customers it will be asked in the vendor review.

Sub-processor chains. AI providers use cloud infrastructure and sometimes model hosting from other companies. Your customer contract may commit you to disclosing sub-processors, and the obligation flows through the whole chain, not just to the name on the invoice.

Whether a data processing agreement is actually in place. Many organisations assume the business tier includes one automatically. Several providers require you to execute it separately, and an unsigned DPA is the first thing a thorough reviewer will ask to see.

The uses that carry real risk, ranked

Not all AI usage is equally exposed, and treating it as one undifferentiated risk leads to blanket bans that staff route around. In rough order of exposure:

Pasting customer personal information into an unapproved consumer account. This is the one that becomes a contractual breach and potentially a privacy incident. Support teams do it with ticket contents, sales teams do it with call notes, and recruiters do it with candidate CVs, which are personal information belonging to people who never became your customers and who have their own rights.

Uploading source code or infrastructure configuration. Configuration files carry credentials more often than anyone admits. A developer pasting a stack trace or a Terraform file into a chat window can disclose an API key without noticing. Secret scanning on your repositories does not see this because it never touched a repository.

Building AI features on top of customer data. Different problem entirely. Here the risk is not staff behaviour, it is your product architecture, and the questions become prompt injection, output handling, tenant isolation in retrieval, and what happens when a model returns another customer's data because a retrieval filter was applied after the search rather than inside it.

Using AI output without verification in a regulated context. Contract summaries, security assessments, and financial analysis produced by a model and passed on as fact create liability that has nothing to do with data protection.

General drafting and brainstorming with no confidential content. Low risk, and say so explicitly in your policy, because a policy that treats writing a blog outline the same as processing health records will be ignored on both counts.

How to find the usage you do not know about

Asking staff what tools they use produces an incomplete answer, not because people lie but because they do not count the browser extension, the meeting recorder somebody trialled, or the AI assistant their existing SaaS vendor enabled by default in a release note. Three checks find most of it in an afternoon.

Look at outbound DNS or proxy logs for requests to known AI provider domains, and look at the volume rather than just the presence. Steady daily traffic from a handful of machines tells you who has built the tool into their workflow. Then check your identity provider for OAuth grants and third-party application authorisations, because a surprising share of AI tools ask for calendar, mail, or drive scopes and are granted them by individuals without any procurement step. Finally, review your expense records for small recurring charges. Individual subscriptions on personal cards reimbursed through expenses are a reliable indicator, and they also mean the terms of service were accepted by an individual rather than by your company, which is a materially weaker legal position.

Do this before you write the policy. A policy written against imagined usage prohibits the wrong things and permits the tools people are already relying on to do their jobs.

The vendor risk assessment questions specific to AI

An AI provider goes through the same vendor process as any other processor, with a handful of additional questions that the standard questionnaire will not cover. Ask whether inputs are used for training or fine-tuning under your specific plan, and get it in writing rather than from a marketing page. Ask what the retention period is and whether a zero-retention option exists. Ask whether outputs are logged and for how long. Ask how deletion requests are handled and whether deletion propagates to derived artefacts. Ask whether the provider has a SOC 2 Type II report or an ISO 27001 certificate, and if they claim ISO 42001, ask for the scope statement rather than the badge. Ask what happens to your data if you stop paying.

For any tool that connects to your own systems through an integration or an agent, add one more: what permissions does it hold, and can they be narrowed. An AI assistant granted full mailbox access to summarise threads is a considerably larger exposure than one that receives pasted text, and it is frequently approved with less scrutiny because it feels like a productivity setting rather than a data transfer.

What good looks like a year in

The organisations that handle this well are not the ones with the strictest policy. They are the ones where the approved tools are good enough that nobody needs an alternative, where the rule about customer personal information is short enough that people remember it, and where somebody checks quarterly what is actually being used rather than assuming the policy is self-enforcing.

Practically, that means a named owner for AI usage, a list of approved tools that is genuinely maintained, a paragraph in the privacy notice that reflects reality, AI providers appearing on your sub-processor list where they process customer data, and a record of the acceptable use policy having been acknowledged. That set answers almost every question an enterprise buyer currently asks, and it is a modest amount of work compared with the cost of discovering the gap during a deal.

When you should not buy an AI security engagement

A fair share of companies asking us about this do not need an engagement, and it is worth being direct about which ones.

If you have fewer than thirty staff, no AI features in your product, and no customer personal information flowing anywhere near these tools, the whole problem is solved by buying business-tier licences for the two tools people actually use, writing a one-page acceptable use policy, and telling everyone once. Our free generator produces the policy and the checker will find the usage. That costs nothing and closes the realistic risk.

If your buyer has asked a single questionnaire question about AI governance, answer it honestly. Naming your approved tools, confirming the tier, and stating that AI vendors go through your standard vendor process is a complete answer. Commissioning an assessment to produce a better-sounding version of the same answer is spending money on presentation.

If your privacy notice is out of date and your sub-processor list has not been touched in a year, fix those first with your own counsel. That is a documentation task, and paying a security firm to do work a lawyer should review is an expensive route to the same place.

The case for an engagement is narrower. It is when you are shipping AI features that touch customer data and need someone to test the retrieval boundaries and prompt handling properly, when a large buyer has escalated past the questionnaire into a real assessment, or when you have discovered usage across dozens of tools and need it mapped and closed before a certification. Our security assessment work covers the first, and where the driver is a framework rather than a single deal, the compliance side is the better entry point. If you are not sure which describes you, tell us what triggered the question and we will say plainly if the answer is a free afternoon rather than an invoice.