Staff pasting company data into ChatGPT

Why it happens

When you find staff pasting company data into ChatGPT, assume first that they are trying to do their job faster. They may be turning rough notes into a proposal, summarising a long document, translating supplier material or asking for help with a spreadsheet. Public tools are easy to reach, often better than the software they have been given, and they respond without a procurement form.

That does not make the behaviour safe. It does explain why a blanket ban is rarely effective. If the sanctioned route is slow, unclear or absent, work moves into personal accounts, copied text and browser tabs. The organisation then loses the opportunity to shape how AI is used. Start by understanding the job people are trying to complete, as you would in an AI readiness assessment.

There is a management lesson here. When a team repeatedly reaches for the same public service, it may be showing you an unmet need for better search, clearer templates, more accessible knowledge or simpler software. Solve that need where you can. Security controls work better when they support the work rather than simply obstruct it.

Do not confuse risk with disaster

The exposure is real: information may leave company-controlled systems, be retained by a supplier, be accessible under account settings you have not reviewed, or be used in ways your client contract does not allow. A prompt can also contain more context than the sender realises. A copied email thread may include personal data, pricing, attachments, names and internal comments.

The exposure is not proof that every pasted sentence has been published on the internet or seen by a stranger. Product terms and settings differ by plan, account and feature, and they change. At the time of writing, OpenAI says personal ChatGPT workspaces may share content for model improvement unless the user opts out, while ChatGPT Business, Enterprise and API data are not used for training by default. That distinction does not settle every privacy, retention or contract question.

The same pattern appears elsewhere. Microsoft says Microsoft 365 Copilot prompts, responses and permitted organisational data are not used to train foundation models; it still follows existing permissions, so an over-shared folder can remain a risk. Google says Gemini in Google Workspace is not used to train generative models outside the customer domain without permission, while administrators control features and retention. Check the exact service, plan, contract and settings before approval. Your AI policy should reflect those facts, not a generic claim that one brand is “safe”.

Name the data that stays out

Set one uncompromising boundary: staff must not put the following material into an unapproved consumer AI tool, even to “just tidy it up”. Where an approved business tool is used, the policy should still set its own rules and approval checks.

• Passwords, one-time codes, API keys, private certificates or access details.
• Special category personal data, health information, criminal-offence data or safeguarding records.
• Identifiable customer, employee or supplier information where the use has not been assessed.
• Legally privileged advice, live disputes, investigation material or confidential board papers.
• Unpublished bids, pricing, acquisition plans, product designs, source code or client secrets.
• Material controlled by a customer contract, security classification or export restriction.

Do not ask staff to make fine legal distinctions under time pressure. Give examples drawn from their work: a care provider should recognise a support plan; a wholesaler should recognise a customer price file; an accountancy practice should recognise a tax return working paper. Clear examples are more useful than a definition of “confidential” on its own.

Offer a sanctioned route

The practical alternative is not “wait for the perfect enterprise programme”. It is a named, approved tool or controlled trial for a small set of common jobs, with a short data rule and a real person who can answer questions. Start with tasks that use public, fictionalised or low-sensitivity content: agenda drafting, grammar checking, idea generation, training materials, plain-language rewriting and internal document templates.

Where the work needs company context, configure the route deliberately. Use managed accounts, least-privilege access, a reviewed knowledge source and a way to report a questionable answer. A proper AI implementation can connect the right systems and controls; it should not simply make a public chatbot available to everyone.

A sanctioned route must be easier than the unsafe workaround. If it takes a week to get an answer, people will keep using the browser tab.

Make the approval process visible in the tools people already use. A short request form can ask for the task, proposed data, users, expected output and any systems to be connected. Give a quick answer for simple, low-risk requests and a clear explanation when the answer is no or not yet. Publishing a small catalogue of approved examples helps teams see what is possible without guessing at the boundary.

Find out without a witch-hunt

Begin with a short, non-disciplinary discovery exercise. Ask teams which tools they use, which tasks they use them for, what they paste in, what value they get and what stops them using approved systems. Make clear that the purpose is to make work safer and more useful, not to punish people for raising their hand. Anonymous responses can help where trust is low.

Combine that with proportionate technical evidence already available to the organisation, such as approved software records, security alerts or web access reporting, subject to your employment, privacy and monitoring obligations. Do not promise secrecy you cannot keep. Look for patterns: teams repeating the same task, documents being copied because they are hard to find, or staff using personal accounts because managed access is absent.

The result should be a use-case register, not a list of names. Categorise each use by value, data sensitivity and whether there is a safe alternative. This is the foundation for practical AI education and a credible approval process.

Keep the conversation focused on the information and route, not a moral judgement about the tool. A person who reports that they used a personal account has given you a chance to assess the material, explain the safe alternative and improve the process. If the only lesson is that reporting creates trouble, future problems will be quieter and harder to manage.

Use the first month well

The first month is about gaining control without stopping useful work. Do not begin by buying several licences in response to anxiety. Build enough understanding to make a limited, defensible choice.

1. Week one: publish an interim rule for unapproved tools, especially the data that must not be entered, and give staff a contact for questions.
2. Week one and two: run a short discovery exercise across functions and list the real tasks, tools, accounts and data involved.
3. Week two: review existing managed licences, contracts, permissions, security settings, data loss prevention controls and any available audit records.
4. Week three: choose two or three low-risk, useful tasks for a sanctioned pilot and define the human check for each.
5. Week four: issue a short AI policy, train the pilot users, record questions and decide what needs technical work before wider access.

A good result after thirty days is not full compliance theatre. It is a truthful picture of current behaviour, safer immediate boundaries and a route that lets people get work done without improvising with company information. The issue of staff pasting company data into ChatGPT is best managed through clarity, controls and a credible alternative.