The question is not whether AI tools are useful. It is which copy of your business information ends up somewhere you no longer control. An employee pasting a contract into a free chat tool to "make it shorter" has made a copy of that contract on somebody else's infrastructure, under terms nobody at your company has read. That may be harmless. It may also breach a confidentiality clause you signed.
This guide covers the practical version of that decision: what to keep out, what is usually fine, and how to give people a workable alternative instead of a rule they will quietly ignore.
First, the Distinction That Actually Matters
"Public AI tool" here means any service used outside your own administered environment — typically a free or personal-tier product that an employee signs into with a personal account. The same brand often sells a business or enterprise tier that runs under your organization's tenant and contract, with different data-handling commitments and administrative controls.
Those tiers are not interchangeable, and the difference is contractual as much as technical. Before treating any tool as approved, confirm the exact tier and read the terms that apply to it. Product tiers and terms change, so check the provider's current documentation rather than relying on a summary — including this one.
Three Questions Before Anything Is Pasted
- Does the provider retain what is submitted, and for how long?
- Is submitted content used to train or improve the provider's models, and can that be disabled?
- Who else could obtain access — provider staff, subprocessors, or anyone through a legal process?
If those three answers are unknown, the tool is not ready for company information, regardless of how good the output is.
Categories to Keep Out
These are the categories that most often create real exposure for a small business:
- Regulated personal data — health information, payment card numbers, Social Security or other government identifiers, driver's licence details, bank and financial account numbers
- Credentials and secrets — passwords, API keys, connection strings, recovery codes, certificates, and anything that grants access to a system
- Network and system detail — internal addressing, firewall rules, server inventories, backup configuration, and diagrams that describe how to reach your infrastructure
- Customer information under contract — anything covered by a confidentiality agreement, a data processing clause, or a customer's own security requirements
- Unreleased business information — pricing strategy, bids in progress, acquisition or financing discussions, board material, and anything embargoed
- Personnel and payroll records — reviews, disciplinary matters, medical accommodations, compensation, and candidate information
- Matters under legal hold or active dispute — anything your counsel is handling, including your own notes about it
- Third-party material you do not own — licensed content, vendor documentation marked confidential, and another company's source material
A workable rule of thumb for staff: if you would not forward it to someone outside the company without checking first, do not paste it into a tool outside the company without checking first.
Why "I Took the Names Out" Is Not Enough
Removing obvious identifiers is better than nothing, and it is not a control you should rely on. Identifying detail hides in places people do not think to edit: account numbers inside a quoted email thread, a file name, a date combined with a location, a case reference, an unusual job title in a small town. Reconstructing who a record refers to from what is left over is often straightforward for anyone with context.
Attachments carry more than their visible text as well. Spreadsheets keep hidden columns, filtered rows, and revision history; documents keep tracked changes and comments; exported PDFs keep metadata. If a file is being uploaded rather than a paragraph being typed, assume everything in that file has been shared.
What Is Usually Fine
A policy that forbids everything gets ignored. These uses rarely raise the same concerns, provided no customer or employee identifiers are attached:
- Rewriting or shortening marketing copy you have already published
- General questions about a technology, a regulation, or a business concept
- Drafting a generic template, checklist, or outline you will fill in yourself
- Explaining an error message that contains no internal addressing or credentials
- Brainstorming structure for a document before any real content exists
Give People an Approved Path
Most policy failures here are not defiance; they are an employee with a deadline and no sanctioned option. The controls that hold up in practice are the ones paired with an alternative:
- Approve one business-tier tool that runs under your own tenant and agreement, and tell people it is the one to use
- Publish a short approved-tools list, and a named person to ask about anything not on it
- Configure the administrative controls the business tier offers, including retention and training options where available
- Train with examples from your actual work rather than abstract categories
- Revisit the list on a schedule — new tools appear inside products your staff already use
It is also worth checking what is already in use. Tools reach employees through browser extensions, phone apps, meeting recorders, and features switched on inside software you already own.
If It Has Already Happened
Assume at some point it will, and treat it as an incident to work rather than a disciplinary event to litigate:
- Record what was shared, when, by whom, and into which service and account tier
- If credentials or keys were involved, rotate them first and review access logs
- Check whether the account has a setting to delete history or opt out of model training, and use it
- Determine whether any contractual or regulatory notification obligation may apply — obligations vary by data type, contract, and jurisdiction, so involve your counsel and your insurer rather than deciding internally
- Fix the gap that made it the easiest option, then update the policy and the training
The Short Version
Decide the categories in advance, write them in plain language, approve a tool people can actually use, and make the review step part of the workflow rather than an afterthought. Our AI readiness checklist covers the surrounding work, and the Microsoft 365 permissions guide covers the access review that should come before you enable an assistant inside your own environment.