Company data, for this purpose, is any input your organisation would not publish: internal documents, client material covered by an NDA, personal data about staff or customers, unreleased financial figures, credentials, and source code.
Yes, you can put some of it into ChatGPT. Already-published material is fine in any account. Internal material is fine only where your organisation holds a written commitment that inputs are not used for training. Client and personal data needs that commitment plus a data processing agreement, and a free consumer account gives you neither.
That is a three-line answer rather than a per-tool one, and it is deliberate. Vendor terms change every few months. Data classes do not. What follows is how to get those three lines somewhere a busy person will apply them under deadline, plus the distinction that catches most organisations out: a vendor promising not to train on your data is not the same as a vendor promising not to keep it.
This is written for whoever has to answer the question rather than implement it, usually a COO, an ops lead or a head of people. One thing has to exist first: a list of which AI accounts your organisation pays for, and at which tier. That list is always longer than expected, and the surprises are the personal subscriptions going through expenses.
Step 1: Sort the data into three classes, not ten
Three classes is the most a non-specialist will hold in their head under pressure, so use three: public, internal, and client or personal.
Public is anything already outside your organisation. Your website copy, published accounts, a press release, a job advert, market data you bought a licence for and may reproduce.
Internal is your own material, not yours to publish, but nobody else's property. Board papers, pricing models, a strategy deck, internal comms, your own process documentation.
Client or personal is material where somebody else has rights or a legal interest. Client deliverables and anything under an NDA, CVs and candidate notes, employee records, customer contact details, health or payroll data, and credentials of any kind.
If you already run the standard four-tier scheme of Public, Internal, Confidential and Restricted, keep it for everything else and collapse Confidential and Restricted together for this one decision. Collapsing them is the point. Somebody with a deadline makes a binary judgement, not a four-way one, and a scheme demanding the four-way judgement gets skipped rather than followed. The wording for a data classification clause is a separate job, and it belongs in the policy document rather than in somebody's head.
Step 2: Give each class one rule that survives a deadline
Each class gets exactly one rule, short enough to recall without looking it up.
Class | The rule | Where it can go |
|---|---|---|
Public | Goes anywhere. | Any account, including free and personal ones. |
Internal | Only where we hold a written no-training commitment. | A business or enterprise agreement the organisation signed. Not a personal subscription. |
Client or personal | Only with that commitment, a data processing agreement, and nothing in the client contract forbidding it. Unsure means no. | Named, approved accounts only. |
The ten-second version, for anyone who will not read the table: if you would hesitate before emailing it to a supplier, it is not public. If somebody else's name or somebody else's business is in it, treat it as client or personal.
Notice that none of the three rules names a tool. That is what makes them last. A rule saying "Copilot is approved, ChatGPT is not" is wrong within a quarter and ignored well before that, because the person applying it can see it makes no sense when both sit on the same enterprise agreement.
Step 3: Check what your account tier actually promises
The promise changes with the tier, and on consumer plans it is usually a setting rather than a term of business. The three vendors most UK organisations are actually running document this themselves, and their own pages are the only place worth checking, because the terms move.
Claude. Anthropic's privacy documentation, updated on 16 March 2026, says that on the consumer plans - Free, Pro and Max - it will use your chats to improve its models if you choose to allow it in your privacy settings, if a conversation is flagged for safety review, or if you opt in another way. There is a detail in that page worth reading twice: content pulled in through a connector such as Google Drive is excluded from training, but the same content is included "if it's directly copied into your conversation". The paste is treated differently from the connection, which is the opposite of what most people assume.
Microsoft Copilot. Microsoft's own documentation states plainly that prompts, responses, and data accessed through Microsoft Graph are not used to train foundation LLMs. That is a commercial commitment rather than a user setting, which is the strongest position of the three. One caveat on the same page matters if you operate in the EU: models provided by Anthropic as a subprocessor inside Copilot are currently excluded from the EU Data Boundary, so an admin switching those models on changes a residency assumption somebody else may have already documented.
OpenAI. Separate the API from the app, because they are different products with different terms and conflating them is how wrong answers get given confidently. For the API, OpenAI's documentation states that as of 1 March 2023 data sent to the OpenAI API is not used to train or improve its models unless you explicitly opt in. For ChatGPT Business and Enterprise, check OpenAI's enterprise privacy page on the day you need the answer rather than trusting a summary, including this one.
Step 4: Tell a contractual commitment apart from a settings toggle
A toggle can be switched back by whoever owns the account, and a contract cannot. On a personal Claude Pro or ChatGPT Plus subscription, the person controlling the training setting is the employee. Nobody in your organisation is notified if it changes, no admin can see its state, and there is no record to show a client. The protection is real while it lasts and you have no way of knowing whether it lasted.
There is a second gap, and it is the one that catches organisations who think they have finished. "Not used for training" is not the same as "not retained." OpenAI's API documentation is explicit that abuse monitoring logs are generated for all API usage by default and retained for up to 30 days, and that excluding customer content from those logs requires approval for Zero Data Retention or Modified Abuse Monitoring, which are "subject to prior approval by OpenAI and acceptance of additional requirements". Those controls exist and they work. They are not a checkbox in a settings menu.
So a supplier can hold your prompt for a month while honouring a no-training agreement in full. Both statements are true at once. If you have told a client "our data is not used for AI training", you have said something accurate and narrower than what they were asking.
Where personal data is involved, retention is not only a commercial question. The ICO's guidance on AI and data protection is the UK reference point, and it currently carries a notice that it is under review because of changes made by the Data (Use and Access) Act. Anyone telling you the UK position is settled has not read the front page of the guidance.
Step 5: Decide who approves a new tool, and how fast
One named person approves new tools, and they answer within a stated number of working days. Five is defensible. Fifteen is not, and the reason is behavioural rather than administrative.
An approval route slower than a personal credit card produces personal credit cards. Somebody who needed an answer on Tuesday and gets one a month later has already solved the problem on a free account, and the data now sits somewhere you hold no contract at all. Response speed protects you more than strictness does.
Building and maintaining the register of approved tools is a separate exercise with its own failure modes, as are risk classification and review cycles, which the guide to developing an AI policy covers properly.
How long does this take to put in place?
Two weeks of elapsed time and roughly a day of actual work, if nobody makes it a project. The elapsed time is mostly waiting for sign-off.
Classing your data: an afternoon if a classification scheme already exists, two or three sessions if it does not.
Auditing the accounts: a morning with your finance system and whoever administers your licences. Longer where departments buy their own, which is most places.
Writing the three rules and getting them approved: a week, almost all of it waiting.
Telling people, in a way that survives: ongoing, and the part that decides whether any of it works.
The cost is not in the writing. It is in the upgrades. Moving a team off personal subscriptions onto business seats is a real per-seat budget line, and the honest framing for a finance conversation is that you are buying a contractual commitment and an admin console, not better model output. Check current pricing with the vendor rather than a comparison article, for the same reason the terms need checking on the day.
What do you tell a client who asks?
Tell them three things in this order: the class you treat their data as, the tier of account it goes into, and the commitment you hold in writing. Anything shorter sounds evasive and anything longer sounds rehearsed.
The usable version reads something like: "We treat your material as client-confidential. It only goes into tools covered by our business agreements, which exclude our inputs from model training, and we hold a data processing agreement with each vendor. It never goes into free or personal accounts."
If you cannot say that truthfully today, the answer is not a softer version of it. It is "not yet, and here is the date we will be able to". Whoever is asking has usually been asked the same question by somebody above them, and a date is more use to them than reassurance.
Worth being clear about internally: the NDA you signed binds your organisation. The AI vendor never signed it and owes nothing under it. When client material goes into a tool, you are the party who made the promise, which is why the account tier is your problem rather than the vendor's. Some client contracts now carry explicit AI clauses, so read the contract before answering rather than after.
What usually goes wrong
Five failure modes, in rough order of how often they turn up.
The rule names tools instead of data. Accurate the week it was written, misleading a quarter later, and people stop trusting the rest of the document with it.
Nobody checked the tier. The organisation believes it is on ChatGPT Business. Four people are on personal Plus accounts they expense, because they had them before the business agreement existed and nobody asked.
The compliant path is the slow path. Covered above, and the most predictable of the five.
The rule was published but never taught. Circulating a document is not the same as changing what somebody does at four in the afternoon, and this is where most policies die. Making a rule stick across a workforce looks a lot like rolling out AI training across a hundred-person team: one owner, a few teams at a time, something taken off the workload rather than added to it.
Embedded AI was missed entirely. Features already inside software you pay for, switched on by a vendor update, where nobody made a decision at all. They never reach an approved tools list because nobody bought them.
The short version
Three classes. One rule each. One person who can say yes inside a week. A written note of which accounts qualify, checked against the vendor's own page rather than a summary. None of that needs a committee and none of it takes a quarter.
ivee builds this layer with UK organisations, and the part clients underestimate is the last one: getting people to follow a rule they did not write. If that is where you are stuck, our AI strategy and governance work is where to start.
