Somebody on your team has already pasted a customer email into a chatbot. That is the honest starting point for most small companies, and it is not a discipline problem. It is a sign that the work is hard and the tool is right there. The question is not whether people are using AI. It is whether you know what they are putting into it, and whether anyone is checking what comes out.
Training employees to use AI well, on a team of ten, is a different exercise than it is at a company of ten thousand. You do not have a legal department to write a twenty-page acceptable-use standard, and you would not follow it if you did. What you have is proximity. Everyone is close enough to be told the rules once, in person, and close enough to notice when someone ignores them.
Write one page, not a program
The most useful AI workplace policy for a small business fits on a single page and can be read in two minutes. Anything longer gets skimmed, filed and forgotten. I think of it the same way I think about governance when the board is four people and a lawyer — the point is not to imitate the paperwork of a bigger institution. The point is to write down the small number of things that actually prevent harm.
A page that works has four parts:
- The tools people are allowed to use, named specifically, and the accounts they must use them under.
- The categories of information that never get pasted into any of them.
- The rule for checking output before it leaves the building.
- The name of the person to ask when something falls between the lines.
That is the whole document. Notice what is missing: no philosophy about the future of work, no list of approved prompts, no attempt to anticipate every tool that will exist in six months. Those things date badly. The four items above will still be right next year, even if every product name in the first one has changed.
The confidential-information problem is a sorting problem
This is the part people get wrong, and they get it wrong in both directions. Some owners ban everything, which guarantees the tools get used anyway, just invisibly. Others wave it through and discover later that a client's unredacted contract went into a consumer chatbot account registered to somebody's personal email.
The workable answer is to make the sorting easy enough that a busy person does it correctly while distracted. I would not ask staff to reason from principles about data classification. I would give them a short list of things that never go in: anything that identifies a customer or an employee by name, anything covered by a signed confidentiality agreement, anything financial that has not been published, anything a lawyer sent you, and anything you would not be comfortable reading aloud at a table where a competitor was sitting.
Then teach the workaround, because a rule without a workaround is a rule people break. The workaround is redaction. Strip the names, swap the real numbers for round ones, describe the situation instead of pasting the document. Most of what people want from these tools — a clearer paragraph, a first draft, a second opinion on structure — survives redaction intact. The model does not need to know your client's name to tighten your prose.
There is also an account question that owners tend to skip. Where a tool is used matters as much as which tool. Business and enterprise tiers generally come with different data-handling commitments than the free consumer version of the same product, and those terms change. Read them yourself before you approve anything, and re-read them once a year. Also check your own client contracts, because some of them may restrict who your data can be shared with, and an AI vendor is a third party whether or not the contract anticipated one.
Teach verification as a habit, not a rule
Rules about accuracy do not survive contact with a deadline. Habits do. The habit I would build is simple and it has one owner: the person who sends it owns it. Not the tool, not the person who wrote the prompt, not the manager who approved the workflow. Whoever's name is on the outgoing email is accountable for every claim in it.
Applied honestly, that single sentence does most of the work a training program is supposed to do. It means somebody checks the numbers. It means somebody opens the cited source and confirms it exists. It means nobody sends a client a summary of a contract clause they have not personally read in the contract.
What I would teach alongside it is a sense of where these tools fail, because the failures are not random. Models are most confident exactly where a new user is least able to catch them — specific figures, dates, citations, names of regulations, the precise wording of an obligation. They are fluent about things they have no way of knowing. A team that internalises this stops treating plausible output as verified output, and that shift matters more than any prompt technique.
The other thing worth teaching is that fluency is not judgment. The draft will read well. It will read well when it is wrong, and it will read well when it is subtly off-tone for the relationship you have with that particular customer. Someone still has to decide whether it is the right thing to send.
Train on live work, in short sessions
Most AI training for staff fails because it is a demo. Somebody presents impressive examples using somebody else's data, everyone nods, and nothing changes on Monday. The alternative costs less and works better: take forty-five minutes, pick a task your team actually does every week, and do it together with the tool open.
Run it in pairs. Show the failures, not just the wins — a bad output that someone caught teaches more than a good one that impressed. And keep a shared file of examples that worked, written by the people who used them, not by you. It will be scrappy. It will also be the single most-used training asset you have, because it is written in your company's vocabulary about your company's work.
Do this monthly, in twenty minutes bolted onto a meeting that already exists. I have the same view of this that I have about the continuity drills we run every hurricane season — short and repeated beats thorough and annual, because the only version anyone remembers under pressure is the one they have practised recently.
Be careful about what goes out under your name
The output that worries me most is not the internal memo. It is anything published — website copy, listing descriptions, review responses, proposals, the answers you give in writing to a customer who is deciding whether to trust you. I run BrandAmplifi, which works in online reputation and search visibility, so I spend a lot of time looking at what companies have put on the public record about themselves, and generic AI-written copy is easy to spot and quietly corrosive.
It is corrosive in two ways. It flattens the specific detail that made you credible, and it introduces claims nobody checked into the place where they are hardest to retract. If you want a practical frame for the public side of this, I wrote separately about being found by AI as a local operator. For the policy, one line is enough: published material gets a named human reviewer, every time, no exceptions for volume.
Give an amnesty, then start the clock
Before the policy takes effect, say plainly that anything anyone has already pasted into a chatbot is forgiven and forgotten. You want to know what is out there, and nobody tells you if the answer costs them their standing. In a company of ten, one awkward conversation in a staff meeting gets you a more accurate picture than any audit would.
Then make one person the first call. Not a committee and not a policy owner with a title — just the colleague who is most curious about this and who other people already ask. Give them permission to approve small things without escalating, and to bring the genuinely hard ones to you.
What you are really managing
None of this is about the tools, which will look different in a year. It is about whether your people can tell the difference between output and work, and whether they feel safe saying that something the machine produced is not good enough to send. That judgment is the asset. If you are early in adoption, the sequencing I described in the first ninety days without a data team pairs naturally with this — get the habits in before the volume arrives.
A small team has one real advantage here, and it is worth using deliberately. We can change how we work in a conversation rather than a rollout. What we cannot do is outsource the judgment, and we should stop pretending that a longer policy would.