What a Workable Policy Has to Settle
A policy a small team will actually follow fits on one page and takes about 20 minutes to draft. It answers five questions: what data may never leave the building, which tools are approved, what must be checked by a person before it ships, what gets disclosed to clients, and who owns the accounts. Skip the philosophy and write the defaults.
Most small teams already use these tools. The policy is not deciding whether that happens, because it is happening in browser tabs nobody asked about.
The document exists to move that activity somewhere you can see it. A rule that is easy to follow beats a rule that is easy to defend in a meeting.
What Goes Wrong Without One
The failures are specific, and they repeat across teams of every size. Naming them is more persuasive than any paragraph about responsible innovation.
Someone pastes a client contract into a free consumer account to get a summary. The confidentiality clause in that contract did not contemplate a third party, and now you cannot honestly say it was not shared.
Someone ships a page of generated copy with a statistic in it that nobody verified. Our guide to fact-checking AI writing covers the mechanics, but the policy is what makes the check mandatory rather than optional.
A meeting assistant joins a sensitive call because it lives in someone’s calendar and defaults to joining everything. Our guide to whether you need consent before an AI notetaker joins covers the legal side. The practical side is an awkward conversation with a client.
Five people expense five overlapping subscriptions on personal cards. Nobody can cancel any of them, because nobody knows which account holds the work.
None of these needed bad intent. Each one was a reasonable person solving a Tuesday problem with the tool in front of them.
That is the argument for writing something down. A policy converts four judgement calls made under time pressure into four decisions made once, calmly, by people who could think about them.
The Five Decisions Every Policy Has to Make
- ● Data out, tools in, review, disclosure
- ● Name an owner for each
- ● Defaults beat philosophy
One: what data may never leave
This is the clause that matters most and the one teams write last. Start from a short forbidden list rather than a long permitted one, because people can remember a short list.
Client names, customer records, credentials, unreleased financials, and anything under a confidentiality clause is the usual core. Add whatever your industry treats as sensitive, and stop there.
Two: which tools are approved
Name two or three, not twenty. An approved list works because it removes the question, and a long list reintroduces it.
Say what happens when someone wants a new one, in a sentence. A named approver and a two-day answer keeps requests inside the process instead of routing around it.
Three: what a human has to check
Draw the line at exposure rather than at effort. Anything a customer or the public sees, anything containing a number, and anything stating a fact about a person needs a named person to check it before it ships.
Internal drafts and brainstorming do not need this treatment. Exempting them is what keeps the rule credible, because a review requirement on everything becomes a rubber stamp within a fortnight.
Say what the review actually involves, in one line. Asking someone to trace every number and name back to a source gives them a task they can finish. Asking them to confirm that the text reads accurately does not.
Four: what gets disclosed
Decide separately for clients, for the public, and for job candidates. These three cases have different expectations and different contractual baggage.
Many client contracts now include a clause about subcontractors and third-party processing. Read one of yours before writing this section, since your contract may already decide it for you.
Five: who owns the accounts
Accounts belong to the business, on a business email, paid on a business card. This single rule prevents the most common and most boring disaster, which is losing access to work when someone leaves.
Write down who renews and who reviews. An owner with a calendar reminder is the difference between a policy and a PDF.
The same line covers departures. When accounts sit on business email, removing someone takes minutes, and when they sit on personal logins it takes a favour.
A Clause-by-Clause Table You Can Copy
- ● Each clause needs a check
- ● Workable defaults included
- ● Adapt the wording to your work
Treat the middle column as a starting default rather than a recommendation for your situation. The right-hand column is what stops each clause from becoming decoration.
| Clause | A workable default | How you know it is being followed |
|---|---|---|
| Forbidden inputs | Client data, credentials, financials, anything under an NDA | Nobody can name an exception from last month |
| Approved tools | Two or three, with a named approver for additions | Expense reports show no personal-card subscriptions |
| Human review | Required for anything customer-facing or containing numbers | Reviewer names appear in the document history |
| Meeting recording | Assistant joins only when the organiser enables it per meeting | No assistant appears on a call nobody expected |
| Disclosure | Follow the client contract, default to telling them | A client question has a ready answer |
| Account ownership | Business email and business billing, no personal accounts | Offboarding removes access in one place |
| Review cadence | One 30-minute check each quarter, owner named | The tool list matches what people actually use |
The last row is the one most teams drop. A list written in spring describes a stack that no longer exists by autumn, because these products change faster than policies do.
Where Small Teams Get the Data Rule Wrong
The common mistake is writing the rule around tools instead of around data. Tools change monthly, and the sensitivity of a client contract does not.
The second mistake is assuming the paid tier settles the question. Business plans often state that inputs are not used to train models by default. The only way to know your plan is to read its own documentation, and checking whether a tool trains on your data walks through where to look.
The third is forgetting that retention and training are separate questions. A provider can decline to train on your text and still store it for a period, which matters for anything you are contractually obliged to keep private.
The fourth is writing a ban you cannot enforce. Prohibiting all use sends the same work to personal accounts, where there is no business agreement and no audit trail at all.
The Two Sentences to Put in a Client Email
Disclosure is the clause teams agonise over and then never write. The reason is that it feels like a confession, so it never reaches a form people can send.
Keep it factual and short. Say which part of the work uses these tools, and say who is accountable for the result.
A workable version reads like this. We use AI tools for drafting and research, we do not put your confidential material into them, and a person here reviews everything you receive before it reaches you.
Two sentences do more than a paragraph of reassurance. Clients want to know that you protect their material and that a named human stands behind the output.
Check the wording against your contracts before you standardise it. If an agreement restricts subcontractors or third-party processing, the contract sets the rule and your email simply reflects it.
What This Policy Does Not Cover
It is worth naming the gaps, because a one-page document invites the assumption that it handles everything. It is not a security programme, and it does not replace access controls, device management, or backups.
It is also not a data processing agreement. If a client or a regulator needs contractual assurances about where data is handled, that paperwork sits with the vendor and with your lawyer.
Finally, it does not settle ownership of what the tools produce. Rules on that vary by jurisdiction and by what a human contributed, so treat it as a separate question rather than one line in a policy.
Who Should Write Which Rule First
- ● Client work starts with data
- ● Regulated work starts with review
- ● Solo work starts with billing
The solo freelancer: Start with account ownership and disclosure. You have no compliance problem and a real client-perception problem, so the sentence you need is the one in your proposals.
The agency handling client data: Start with forbidden inputs, and read a signed contract before you write it. Your obligation is already defined somewhere, and the policy is just making it operational.
The team in a regulated field: Start with human review and records. In finance, health, and law the question is rarely whether someone used a tool, but whether a qualified person checked the output and whether you can show it.
The nonprofit or volunteer-heavy team: Start with the approved tool list. Rotating people and shared logins make account sprawl the fastest-moving risk you have.
The small product or engineering team: Start with the code and customer data clauses, then decide on disclosure. Source code, customer records, and support transcripts each need their own line, because they usually live in different tools.
Keeping the Policy Alive After Week One
Put the page where the work happens. A pinned message in your main channel outperforms a shared drive nobody opens.
Review it quarterly, with one person responsible. Thirty minutes to confirm the tool list, the approver, and the forbidden inputs is enough, and skipping two quarters is how a policy quietly expires.
Fold it into onboarding and offboarding. New people read it in their first week, and leaving people have their access removed from the same list, which only works if the accounts were business-owned in the first place.
Revisit the approved tools when your stack changes, not on a fixed schedule alone. If you are reconsidering the whole set, choosing one AI assistant for your stack is a useful companion to this exercise.
The One-Page Version
If you write nothing else, write these five lines. Approved tools are X and Y, and new ones go through this person.
Never paste client data, credentials, or financials. Anything a customer sees gets a named human check before it ships.
Accounts sit on business email and business billing. The person named at the bottom reviews this page every quarter.
That is a real policy. It is short enough to read, specific enough to follow, and honest about the fact that the tools are already in use.
The rule a team uses most is usually the one about what never goes into a prompt. How to redact personal data before pasting it into a chatbot gives the examples that section needs.
FAQ
How long should a small team AI policy be?
One page, and no longer. A small team reads a page and ignores a handbook, so the useful document names the approved tools, the data that may never be pasted, the work that needs human review before it ships, and the person to ask. Anything beyond that belongs in a separate note for whoever renews the subscriptions.
Should we just ban AI tools instead of writing a policy?
A blanket ban pushes the same activity onto personal accounts, where you have no visibility, no business terms, and no record. Naming two or three approved tools and one short list of forbidden inputs gets far better compliance than a rule nobody can follow while doing their job.
What data should never be pasted into an AI tool?
Client names, customer records, credentials, unreleased financials, health or legal details, and anything covered by a signed confidentiality clause. The practical test is whether you would email the same text to a stranger. If the answer is no, it does not belong in a chat box.
What work should always be reviewed by a human before it ships?
Anything a customer or the public will see, anything with a number in it, and anything that states a fact about a person. Internal drafts, brainstorming, and rough summaries do not need the same treatment, which is what keeps the review rule from becoming theatre.
Does the policy need a named owner?
Yes, in one line, because the cost of the alternative is high. Naming the person who approves new tools and reviews the list each quarter is the difference between a policy and a document. Without an owner, the list goes stale within a month of the first new release.
Sources
- NIST AI Risk Management Framework — checked 2026-09-27
- FTC: AI (and other) companies: quietly changing your terms of service could be unfair or deceptive — checked 2026-09-27
Some links may be affiliate links. We may earn a commission at no extra cost to you.
This article was written with AI assistance. It is researched and fact-checked, not based on personal hands-on testing unless explicitly stated.
Comments
Post a Comment