On this page
An AI governance policy is the written record of what you allow AI to do in your business, what you never allow, and what a client can expect. For a one-person business it is one page, not a framework, and it takes about an hour to write. Six sections cover it: which tools you use, what data may never go into them, where a human has to check the output, what you disclose to clients, who is accountable, and when you review it. You need one for three practical reasons: client questionnaires increasingly ask for it, the EU AI Act's transparency duties apply regardless of headcount, and writing it once stops you making the call badly under time pressure. The template below is the whole policy, ready to fill in.
Search this topic and you get governance committees, RBAC matrices, model risk tiers and approval workflows. All of it written for companies with a board and an audit function.
None of that survives contact with a business of one, where the governance committee is you, the approval workflow is you deciding, and the audit trail is whatever you can remember. But the underlying question is still real, and it arrives in a specific form: a client asks whether you use AI on their work, and you need an answer you have already thought about.
Writing It: Six Steps, About an Hour
Work through these in order. Each one produces a section of the finished document, and the template further down is the same six sections laid out ready to fill in.
- List the tools you actually use. Open your billing and your browser history rather than working from memory. Most people find two or three they had forgotten, and an unlisted tool is the one that causes the problem later. If you have never totalled them up, what the subscriptions actually cost is usually the fastest way to find the ones you forgot.
- Decide your red lines on data. The single most important line in the policy. Name the categories that never go into an AI tool: client personal data, anything under NDA, credentials, unreleased financials. Be specific enough that a tired version of you at 11pm can apply it.
- Decide where a human must check. Not everything needs review. Name the outputs where you always check before it leaves: anything a client sees, anything with a number in it, anything legal or medical, anything published under your name.
- Decide what you tell clients. Pick one of three positions and write it down: disclose everything, disclose on request, or disclose when AI materially shapes the deliverable. Any of the three is defensible. Having no position is not.
- Name who is accountable. In a business of one this is a formality that takes ten seconds and matters anyway, because it is the line that says the output is yours regardless of which tool produced it.
- Set a review date. Every six months, or whenever you add a tool. AI tooling changes faster than any other part of your stack and a policy written last year is describing a business you no longer run.
That is the whole process. The reason it takes an hour rather than a week is that you are not designing controls for other people to follow. You are writing down decisions you are already making implicitly, so that they stop being improvised.
Aziz's take: Step two is the one to do properly and the rest can be rough. Everything else in the policy is a preference you can revise, but pasting a client's customer list into a chatbot is not a thing you can take back afterwards. I would rather someone wrote a bad policy with a sharp data line than a beautiful one that left it vague.
The AI Policy Template
This is the entire policy. Fill in every highlighted value, delete the rows that do not apply, and it is finished. It fits on one page on purpose, because a policy nobody rereads is a policy nobody follows.
How to use this
Fill in
- Every highlighted value. Delete any row that does not apply to you.
- Section 02 is the one to labour over. Name real categories, not "sensitive data".
- Pick one disclosure position in section 04 and delete the other two.
Check before you file it
- Every tool you pay for appears in section 01, including the free tiers.
- Section 02 is specific enough to apply at 11pm without re-deciding.
- The review date in 06 is in your calendar, not only in the document.
What goes wrong
- Copying an enterprise policy, which commits you to controls you will never run.
- Writing "no client data" while pasting client emails in daily. An untrue policy is worse than none.
- Never revisiting it, so it describes a toolset you stopped using months ago.
Why a One-Person Business Needs One at All
Three reasons, none of them theoretical.
Clients are starting to ask. AI questions are appearing in the same procurement questionnaires that ask for insurance certificates and a data processing agreement. Having a one-page answer ready is the difference between a smooth reply and a week of improvising while the contract waits.
The transparency rules do not have a headcount threshold. The EU AI Act applies obligations based on what the system does and the role you play, not on how many people you employ. Most solo work sits in the minimal-risk band where the duties are limited, but the transparency expectations around AI-generated content are the part most likely to touch ordinary freelance work. Writing down your disclosure position is the cheapest way to be on the right side of that.
It stops you deciding badly under pressure. The moment you need a data rule is the moment a deadline is close and pasting the whole client file into a chatbot would save forty minutes. A decision made in advance, in writing, is a different decision from one made at that moment. This is the natural companion to automating parts of your business with AI: the automation decides what the tools do, and the policy decides what they are allowed to touch.
The Four Pillars, Translated
Enterprise frameworks are usually built on four principles. They are sound, and they are also written for organisations with departments. Here is what each one actually means when the organisation is one person.
| Principle | What it means at enterprise scale | What it means for you |
|---|---|---|
| Transparency | Documented model cards, explainability reporting | Section 04. You have a disclosure position and you can state it in one sentence. |
| Accountability | Named owners, escalation paths, audit committees | Section 05. The output is yours. The tool is not a party you can blame. |
| Fairness | Bias testing across protected characteristics | Section 03. You read the output before it goes out, especially anything describing people. |
| Security | RBAC, data classification, DLP tooling | Section 02. A list of what never gets pasted in. |
The principles do not shrink. The machinery does. Every one of them reduces to a line you can write and actually follow, which is the only version that changes behaviour.
Five Mistakes That Make the Policy Useless
Copying an enterprise template. You commit to quarterly bias audits and a model inventory you will never maintain. A policy you do not follow is worse than none, because now there is a document showing you knew and did not.
Writing a data rule you break weekly. "No client data in AI tools" sounds strong and is untrue for most people, who paste client emails in to draft replies. Write the rule you will keep, then tighten it when the tooling allows.
Confusing this with a vendor agreement. Your AI policy is your internal rules. A data processing agreement is a contract with the vendor about what they may do with data you send them. You need both, they cover different risks, and neither substitutes for the other.
Leaving disclosure undecided. The worst position is the unexamined one, where you have not decided and answer differently depending on who asks. Any of the three positions in section 04 is defensible, and consistency is what makes it credible.
Never reviewing it. Tools change every few months. A policy naming a tool you abandoned in spring tells a client you wrote it once for show. The review date exists because this is the most common way these documents quietly die.
Aziz's take: The disclosure question is the one people avoid because they assume clients will react badly. In my experience the opposite happens. Saying plainly which parts of the process use AI and which are checked by hand reads as confidence, and it turns an awkward question into a short answer. What clients react badly to is discovering it themselves.
The Ten-Point Check Before You File It
- Every AI tool you pay for appears in section 01, including free tiers.
- Section 02 names real data categories, not the phrase "sensitive information".
- You could apply the section 02 rule at 11pm without re-deciding.
- Section 03 covers anything with a number in it.
- Exactly one disclosure position is left in section 04.
- That position matches what you would actually say if asked today.
- Accountability names a person, not a role.
- Nothing in the policy commits you to a control you will not run.
- The review date is in your calendar, not only in the document.
- You could hand this to a client unedited.
Point ten is the real test. If there is anything in it you would want to soften before a client read it, that thing is the part worth rewriting now, because a policy you would not show is not doing the job you wrote it for.