Writing generative AI usage rules for SMEs: the personal data, confidentiality, and copyright baseline
A generative AI usage policy does not need to be a thick rulebook full of prohibitions. Spelling out two things — what information may be entered, and who signs off on the output before it goes out — is usually enough to make a policy work in practice. Problems tend to show up at two opposite extremes: a policy so complex that nobody reads it, or no policy at all, which leaves employees to set their own rules. The second case is more common, and more dangerous. Employees start using generative AI on personal phones or personal accounts to save time, and customer data or contract terms end up flowing into external services the company never approved or even knows about. This is often called “shadow AI.”
This guide is for owners and AI leads at small and medium enterprises (SMEs). It lays out the five items every policy needs, walks through the baseline thinking for personal data, confidentiality, and copyright, and explains why a policy should define what is allowed rather than what is banned — and how to make that policy actually stick on the ground.
The shadow AI problem: what happens without a policy
Shadow AI is the generative AI equivalent of “shadow IT” — the earlier pattern of employees using personal cloud storage or personal chat apps for work without IT’s knowledge. Generative AI spreads even faster than shadow IT did, because there is nothing to install: anyone can open a browser and start using a public tool immediately.
The counterintuitive part is that an outright ban does not fix this. Once employees have felt the productivity gain, banning the tool at work does not remove the need — it just pushes usage onto personal accounts and personal devices the company has zero visibility into. Paradoxically, banning generative AI can make the underlying risk worse, not better, because the company loses any ability to see what is actually happening. The goal is not to stop people from using AI. It is to make sure the company knows how it’s being used, and to define the range of use that is safe.
Five items every policy needs
In practice, a working policy comes down to five items. Most SMEs can fit all five onto one or two pages and start operating immediately.
| Item | What to define |
|---|---|
| What may be entered | Classify customer personal data, confidential contract clauses, and unpublished financial information as “never enter”; classify general business knowledge and public information as “fine to enter” |
| Which tools are approved | Name the tools the company has vetted and contracted for (whether the vendor allows opting out of using inputs for model training should be part of the selection criteria) |
| Output review | Require a human to verify facts and wording before any AI output goes to a customer or external party |
| Usage logging | Keep a simple record of which tool was used for which task — this is what lets you trace a problem back to its source and revise the policy later |
| Training | Don’t just distribute the policy — walk through the reasoning behind it with concrete examples |
Of these five, defining “what may be entered” delivers the most value by far. The next section breaks that judgment down for personal data, confidentiality, and copyright specifically.
Personal data, confidentiality, and copyright: the baseline for each
Personal data: don’t enter it in identifiable form
The core risk with personal data is entering names, contact details, purchase history, or any combination that identifies a specific individual into an external generative AI service in identifiable form. Many generative AI services’ terms allow input data to be used for service improvement or model training, which means the data may end up handled in ways the company can no longer control. When selecting a tool, check whether it offers an opt-out for using inputs in training. As a rule, either anonymize personally identifiable information before entering it, or don’t enter it at all.
Confidentiality: don’t undermine the fact pattern that makes something a trade secret
Confidential information — a client’s contract terms, an unpublished business plan — is only legally protected as a trade secret if it is actually managed as one: access is controlled, and there’s a record of who could see it. If employees routinely paste confidential material into a generative AI tool with no access controls or logging, that everyday practice can itself erode the “managed as confidential” fact pattern the protection depends on. For general internal confidential information, the baseline is to restrict it to logged, contracted business-tier tools, and explicitly prohibit free personal accounts for that kind of work. A narrower category needs a stricter rule: information whose disclosure to any third party is itself restricted by contract or law — a counterparty’s own confidentiality clause, undisclosed M&A or financial terms — should never go into a generative AI tool, business-tier or not. Whatever the AI vendor’s own contract terms say, handing that information to any outside processor without the counterparty’s consent can itself breach the underlying confidentiality obligation.
Copyright: there are two sides — what goes in, and what comes out
Copyright raises questions on both the input side (is it fine to feed someone else’s copyrighted work into the AI?) and the output side (is it fine to use AI-generated text or images as-is?). Routine internal use on the input side — summarizing an internal document, for instance — is usually low-risk. The output side deserves more care: there is a nonzero chance that generated text or images will closely resemble an existing copyrighted work by coincidence. When AI output is going into anything customer-facing — ad copy, marketing material, published content — a human should check it against existing works for substantial similarity before it goes out.
Why a policy should define what’s allowed, not what’s banned
A blanket “no generative AI” rule looks like the safest option, but in practice it tends to raise risk. Banning the tool doesn’t remove the underlying need for it, so usage simply moves to personal accounts the company can’t see — the shadow AI problem described above. A blanket ban is often the very thing that creates an unmanageable situation.
The point of a policy isn’t to reduce risk to zero. It’s to let staff decide, in the moment, whether something is fine to enter, without having to stop and think it through from scratch. The three-tier classification in Figure 1, paired with one designated person to ask when something is unclear (a manager, an admin lead), removes the need for staff to pause and deliberate every time. The more prohibitions you pile on, the more the policy turns into something nobody actually reads — which defeats the purpose.
Making the policy stick in practice
A policy that’s been written and distributed exists — but it isn’t yet operating. Three things make the difference between a document and an actual practice:
- Explain it through real work, not abstractions. Rather than a list of prohibitions, walk through an actual task: “here’s exactly how far you can go when drafting a quote with AI.” Concrete examples land better than abstract rules.
- Stay close for the first few months to answer edge cases. Right after a policy is distributed, staff will run into a steady stream of “what about this specific case?” questions. Whether the policy actually takes hold often comes down to how well those early edge cases get resolved — and that’s easier to do with someone technically fluent working through them alongside the internal team, rather than leaving the internal AI lead to handle it alone. Tied’s embedded consulting model is built for exactly this kind of hands-on support during the rollout period.
- Revisit it periodically. As new tools appear and the business changes, review the classification table roughly every six months. Treating the policy as a living document — not a one-time deliverable — is the single best defense against it going stale.
Writing the policy is not a standalone exercise. It works best alongside the kind of task inventory covered in Where SMEs should start with AI adoption and the internal capability-building discussed in Options when there’s no one in-house who understands AI.
FAQ
Q1. How long should the policy document be? A. One or two pages, tops. The longer it gets, the less likely anyone reads it — the five items above fit comfortably in that space.
Q2. Does every use of a generative AI tool need manager sign-off? A. No — case-by-case approval isn’t realistic. As long as the “what may be entered” classification is clear, staff can and should make the call themselves. Approval should be reserved for changes to the classification itself, such as adopting a new tool.
Q3. What if we find out staff are already using personal accounts? A. Start by making an approved business-tier tool available, not by punishing the behavior. Punishing it after the fact without offering an alternative just pushes usage further out of sight — it doesn’t solve the underlying problem.
Q4. Who should write the policy? A. If IT alone writes it, the result often drifts from how the work actually gets done and becomes impractical. Involve the staff who will actually use AI day to day, and build the policy around real tasks they handle.
Summary
A working generative AI policy isn’t a list of prohibitions — it’s five items (what may be entered, approved tools, output review, logging, and training) fitted onto one or two pages. On top of that, three baselines matter most: never enter identifiable personal data, restrict confidential information to tools that don’t undermine its “managed as confidential” status, and add a human review step before AI output goes external for copyright reasons. Framing the policy around what’s allowed, rather than what’s banned, is what actually prevents shadow AI while still letting the organization capture the productivity gains.