Most small teams are already using AI assistants. The tools arrived one person at a time, nobody wrote anything down, and the rules are whatever each person privately assumes. That is the situation an AI policy is for, and it does not need to be a legal document. One page, written by someone who understands the work, beats twelve pages copied from a multinational and read by nobody.
This is a structure you can copy, section by section, with what to put in each and the mistakes that make policies useless.
Start with three questions
Before drafting anything, answer these with whoever runs the business.
What information must never leave our systems? For most small firms the honest list is short: client data covered by an agreement, personal data of staff and customers, credentials and keys, unreleased financials, and anything a client has explicitly restricted.
What work may be produced with AI assistance, and what may not? Drafting an internal summary and drafting a legal undertaking are not the same decision.
Who is accountable when the output is wrong? There is only one workable answer, and putting it in writing is most of the value of the policy.
The structure to copy
1. Purpose and scope
Two sentences. Say what the policy is for and who it covers, and make sure it explicitly includes contractors, freelancers and interns, because they are usually the people using the most tools and reading the fewest documents.
2. Approved tools
Name them. A policy that says "approved AI tools" without a list is not a policy. Write the actual list, the account type each person should use, and the rule that anything not on the list is not approved until it is added.
The account type matters more than people realise. Consumer and business tiers of the same product can differ in whether your content may be used to improve the provider's models, in retention, and in administrative control. Check the current terms for the tier you are on, record what you found and the date you checked, and set the data controls deliberately rather than accepting defaults.
Include a line on how somebody requests a new tool, and make it easy. A hard request process produces shadow usage, which is the thing you were trying to prevent.
3. What may be pasted in, and what may not
Three lists, in plain language, using examples from your own work rather than abstract categories.
- Never: client personal data, staff personal data, passwords and API keys, anything under a specific client restriction, unreleased financial or contractual detail, and material a client supplied under an NDA.
- Ask first: whole client documents, internal strategy, unpublished creative work, and anything you would not want quoted back to you in a meeting.
- Fine: published material, your own drafts, general questions, code and text you own with the sensitive parts removed.
Add the practical habit that makes this workable: anonymise before you paste. Replace names, account numbers and identifiers with placeholders. The assistant does not need to know it is Kandy Hardware Limited to improve the paragraph.
If you operate in Sri Lanka, note that the Personal Data Protection Act No. 9 of 2022 is being implemented in phases, and that clients in the UK or the European Union may impose obligations on you through their contracts regardless of where you sit. Take advice on your own position rather than assuming; a policy is not a substitute for that.
4. Permitted and prohibited uses
Be concrete on both sides. Permitted might include drafting and rewriting, summarising documents you are entitled to hold, brainstorming, code assistance, translation drafts and research starting points. Prohibited should name the things that could actually hurt you: final legal, medical, tax or financial advice issued without a qualified human; decisions about hiring, discipline or dismissal; generated images of people or products in client deliverables; altering photographs used as evidence or as a factual record; and submitting AI output to a client as original work where the contract requires otherwise.
5. Human accountability
One rule, stated flatly: the person who sends it owns it. Every deliverable has a named human who has read it, checked it and stands behind it. Then add what checking means in your trade, because it differs: numbers and dates verified against the source, quotations and citations opened and confirmed to exist, code reviewed and run, legal or regulatory statements confirmed by someone qualified, and generated imagery checked against the rules in section four.
6. Disclosure
Decide what you tell clients and when, then be consistent. A workable default for a small studio: AI assistance in drafting and internal work needs no disclosure; generated or substantially AI-altered assets delivered to a client are disclosed in the handover note; and any client whose contract restricts AI use is treated by that contract, not by this policy.
Write down the sentence people should use, so nobody has to invent it under pressure.
7. Records
For work that matters, keep the prompt and the source material with the job file. If you produce images with tools that attach provenance information such as Content Credentials, keep that intact rather than stripping it. This costs nothing at the time and answers questions that arrive months later.
8. Client and contract exceptions
Keep a short register: client, restriction, date checked. Some clients prohibit AI use in deliverables, some require disclosure, some require that no data leaves a named jurisdiction. The register is where a designer checks in thirty seconds before starting.
9. Owner, review date and amnesty
Name one person who owns the policy and answers questions. Set a review date, quarterly at first, because the tools change faster than the document. And include an amnesty line: if you think you have pasted something you should not have, say so immediately and you will not be in trouble for reporting it. Policies without amnesty produce silence, and silence is how a small incident becomes a large one.
How to roll it out without ceremony
Draft it in an afternoon. Circulate it for a week and take comments, because the people doing the work will find the clause that does not survive Tuesday. Hold one thirty-minute session, using two real examples from your own jobs rather than hypotheticals. Put the document where the work happens, not in a folder nobody opens. Then review it on the date you set, even if nothing has changed.
Four ways these policies fail
It only says "use AI responsibly". Nobody has ever changed a behaviour because of that sentence. Every clause should be something a person could be observed doing or not doing.
It bans everything. A total ban in a team that already uses these tools does not stop the usage; it moves it to personal accounts on personal devices, where you have no visibility at all. Permit, name and control instead.
It was copied from an enterprise. Large-company policies assume roles you do not have: a data protection officer, a procurement process, a security team. Copying them produces obligations nobody can meet, and a policy that cannot be met is ignored entirely.
Nobody owns it. An unowned policy is out of date within a quarter and everybody knows it.
Our AI governance and responsible use course walks a team through writing this document for their own business, with the data classification exercise and the client register done in the session, so you leave with a draft rather than a reading list.
