A One-Page AI Policy for a Small Team

Your team is already using AI. Some of them are pasting things into tools you haven't evaluated, and nobody has said what's allowed because nobody has written it down.

A one-page policy costs an hour and prevents the specific failures that are hardest to undo — a client contract pasted into a consumer tool, a fabricated figure in a proposal, work sent to a client that reads as automated.

Write permissions, not prohibitions

The most important design decision.

A policy that bans everything gets ignored, and worse, it drives usage underground — people keep using it and stop telling you, which removes your only visibility.

Say what's encouraged, then what's restricted, then who to ask. That gets followed.

The four things it must cover

1. Data — what can go in

The one with real consequences. Be specific rather than principled:

Fine: public information, our own published content, anonymised examples, drafts with no client details, internal process documents.

Not without asking: anything identifying a client, contracts, financial records, employee information, anything under an NDA.

Never: passwords, API keys, or access credentials of any kind.

If you handle regulated data — health, financial, legal — the requirements are specific to your sector and jurisdiction, and that section should be written with whoever advises you on compliance rather than improvised.

2. Verification — what must be checked

Anything with a specific figure, date, citation or legal reference must be verified against a real source before it goes anywhere. AI output is a draft, not a finding.

Anything going to a client or published is read in full by a person before it goes.

That second line does most of the work. It doesn't ban anything; it puts a human between the output and the outside world.

3. Disclosure — what gets said

This varies by business and by client, and it's worth deciding deliberately:

We don't disclose routine use for drafting and research, in the same way we don't disclose using a spellchecker.

We do disclose where a client has asked, where a contract requires it, and for any substantial deliverable that is materially AI-generated rather than AI-assisted.

If in doubt, disclose. Being asked afterwards is worse than saying so upfront.

Some clients have their own policies requiring disclosure. Worth asking at the start of an engagement rather than discovering later.

4. Accountability — who owns the output

One sentence, and it prevents a whole category of argument:

Whoever sends it, owns it. "The AI wrote it" is not an explanation we offer to clients or accept internally.

The one-page version

AI USE — [BUSINESS NAME]                    Last reviewed: ______

WHAT WE ENCOURAGE
  Drafting, summarising, reformatting, first passes, brainstorming,
  categorising at volume, explaining unfamiliar topics as a starting point.

DATA
  Fine:            public info, our own content, anonymised examples,
                   internal process documents
  Ask first:       client-identifiable data, contracts, financials,
                   employee information, anything under NDA
  Never:           passwords, keys, credentials

VERIFICATION
  Any specific figure, date, citation or legal reference must be verified
  against a real source. AI output is a draft, not a finding.
  Anything client-facing or published is read in full by a person first.

DISCLOSURE
  Routine drafting: no disclosure needed.
  Disclose when: the client asks, a contract requires it, or a substantial
  deliverable is materially AI-generated.
  If in doubt, disclose.

ACCOUNTABILITY
  Whoever sends it, owns it.

APPROVED TOOLS
  [list] — anything else, ask first.

WHEN IT'S UNCLEAR
  Ask [named person]. Asking is always fine.

Name someone to ask

Every policy has edges. If there's nowhere to go when a situation isn't covered, people guess — and they guess in whichever direction is more convenient.

Name a person. In a small business that's usually you. Say explicitly that asking is fine and won't be treated as a problem, because the alternative is people not asking.

Choose the tools, don't leave it open

Listing approved tools does two things: it stops confidential material going into whatever someone found on a forum, and it means you've actually checked the data handling for the tools in use.

Keep the list short and add to it deliberately. "Anything else, ask first" is the line that makes it workable.

Review it every six months

This area changes faster than most things you'll write a policy about — tools change their terms, capabilities shift, and your own usage grows.

Six months is the right cadence, and it should be a real review: what are people actually doing, what has the policy failed to cover, what tools have appeared.

Put it in the quarterly planning cycle so it doesn't quietly become a document nobody has read since it was written.

The mistakes

1. No policy at all. People are using it anyway, without guidance.
2. A policy that bans everything. Ignored, and it hides usage from you.
3. Principles instead of specifics. "Be careful with data" tells nobody what to do.
4. No named person to ask. People guess conveniently.
5. No approved tool list. Confidential material into unvetted products.
6. Writing it once. Out of date within a year.

What to do next

Copy the one-page version above, fill in the tool list and the named person, and send it to your team this week. It doesn't need to be perfect — it needs to exist before the situation it would have prevented.

Then put a six-month review in the calendar.