Free tools · 6 minutes · Last reviewed 24 August 2026
AI policy generator: a tailored AI acceptable use policy in 8 questions
Answer eight questions about your company and this assembles an AI acceptable use policy from eleven clause blocks, tailored to your size, your industry, whether customer data touches the tools, and whether your AI tools draft or act. The finished policy appears as plain text on this page, ready to copy. No email, no download wall, no sign-up. Every clause and the reasoning behind it is printed below, so you can read the whole default policy without answering anything.
Written and last reviewed on 24 August 2026 by Ashutosh Upadhyay, founder of Cognio Labs. No lawyer has reviewed this and it is not legal advice. Have your own counsel review the policy before you adopt it. What this gives you is a first draft specific enough to be worth a lawyer's hour instead of a blank page.
Generate your policy
Eight questions: headcount, industry, whether customer data touches the tools, whether your tools draft or act, what is already in use, whether you need a DPA or a BAA, how much approval process people will tolerate, and what you owe clients. Answer for the company you have, not the one on the org chart.
8 questions · plain text on the page · no email · nothing leaves your browser
Why we built a generator and not another Word file
In August 2026 we checked the top ten results for five policy keywords — fifty positions in total — and every one was a static document behind a form. Not one was a tool. On three of those five queries, Google's own AI Overview ended by offering to draft the policy for you in the chat. That was true when we looked; search results move, so check it yourself if it matters to you. That gap is the whole argument. The thing people want is a policy that fits their company, and a fifteen-page template covering healthcare, finance, EU data and enterprise procurement is not that. It is a deletion exercise, and the deletion is the part nobody finishes.
So the output here is plain text on the page. No email, no file to open, no “check your inbox”. If you would rather have the file, the download button is there, but it is an extra rather than the point.
Why companies actually write an AI policy, in our experience
Not because of a framework. The one time a client came to us asking for an AI policy, it was because an employee had access to something they should not have had, and that access led to publishing something that was a problem. That is the shape of it: an access-control failure at the edge of a system, which then walked out the front door as something external.
Read that sequence again, because it tells you where a policy has to bite. Rules about what employees may type are the easy half. The hard half is that the information had already been made reachable, by a connection somebody set up and nobody revisited. Which is why the clause below is the one we care about, and the one almost every template on the internet leaves out.
We are not going to dress this up with a number, a client name or a dollar figure. We do not have one to give, and inventing one would be worse than saying so.
The clause people skip
There must be named stakeholders for each piece of information going out of the platform and coming in. That is it. Almost nobody writes it, because it is not a rule about behaviour — it is a table of names, and filling it in exposes how many connections currently belong to nobody.
A drive connected to a tool six months ago is still handing out whatever is in it, to whoever can reach the tool. The person who wired it up may have changed teams. The access list has drifted. Nothing in a normal acceptable use policy catches that, because the policy is written about people typing, and this is about a pipe left open. Section 7 of the generated policy is the table. If a row has no name in it, that category should not be connected yet.
The eight questions, and what each one changes
Nothing here is scored and nothing is sent anywhere. Each answer switches specific paragraphs on inside specific clauses.
- How many people will this policy cover?
Sets how heavy the document is allowed to be. Under 50 people, a policy with a committee in it will not be read, so the generator keeps one approver and one page of rules.
Options: Fewer than 20 · 20 to 50 · 50 to 200 · More than 200
- Are you in a regulated or contract-bound industry?
Adds the specific obligations that override everything else in the document: protected health information, privileged client material, or personal data of EU and UK individuals.
Options: No — general commercial work · Healthcare or health data · Financial services · Legal, accounting or another privileged profession · We handle EU or UK personal data
- Does customer or personal data touch the AI tools?
Decides whether the data clause is a short reminder or the longest section in the policy, and whether redaction becomes a rule rather than a suggestion.
Options: No — internal and public material only · Sometimes, by accident — support tickets, email threads · Yes, deliberately. It is the point.
- Are the tools drafting, or taking actions?
Switches the approval tiers on or off. Drafting-only companies get a short version; anything that writes to a system or sends something outward gets scoped credentials, logs and a per-action approval rule.
Options: Drafting only — a human sends everything · Mostly drafting, plus some automations that write to systems · They send email, update records, move files or money
- What is already in use?
Decides whether the policy opens with a survey step. If you do not know what people use, writing an approved list first produces a list that is wrong on day one.
Options: Honestly, we do not know · Free or personal accounts of the big chat tools · Paid business tiers with admin control · Business tiers plus tools connected to our own systems
- Do you need a DPA or a BAA before a tool can be approved?
Adds a hard gate to the approval clause. Where a contract is required, the tool is unapproved until the paperwork exists, regardless of how good the tool is.
Options: Not sure what those are · Yes — a DPA · Yes — a BAA · Both · No
- How much approval process will people actually tolerate?
Sets the weight of the request-a-tool clause and the review cadence. Process nobody follows is worse than no process, because it produces a document that is provably ignored.
Options: Almost none — one page, one approver, trust people · A request, a named approver, a written answer · Formal review, sign-off and a record
- Do you have to tell clients when AI touched their work?
Rewrites the disclosure clause, and adds a contract-review step before the policy goes live if you have not checked your own MSAs for subcontractor and confidentiality language.
Options: Yes — some contracts require it · No contract requires it, but we want to · No · We have not checked
The eleven clause blocks, in full, with the reasoning
This is the default policy as it stands before you answer anything — every clause, its base text, why it is written that way, and the conditions that add to it. Read it here, disagree with it here, and use the generator only if you want the tailored version.
1. Scope and definitions
Why this clause is written this way: Most policies break here by defining AI as a product category, which means the policy covers the chat tab and misses the summarise button your CRM shipped last quarter. Define it by behaviour instead. And put contractors in scope in the first sentence, because they are the people most likely to be working on a personal laptop with a personal account.
This policy applies to everyone doing work for [COMPANY] — employees, contractors, freelancers and interns — on any device, company-owned or personal. "AI tool" means any software that generates or summarises text, code, images, audio or recommendations using a general-purpose model. That includes standalone chat tools, coding assistants, meeting recorders, and AI features built into software you already pay for. "Approved tool" means a tool named on the list in Section 2. Everything else is unapproved, including the free tier of an approved tool used from a personal account. This policy sits underneath existing confidentiality, security and client agreements. Where those are stricter, they win.
What gets added, and when
- Under 50 people: At our size this policy is one page, one approver and one review a quarter. If it grows past two pages, we have written the wrong document.
- 50 people or more: Each department head is responsible for making sure their team has read this and for raising gaps that are specific to their work. Central policy, local ownership.
- Privileged profession: Client-confidential and privileged material is in scope by default. Assume every matter file is covered unless the client has agreed otherwise in writing.
- Healthcare: Protected health information is in scope by default, including material that is only identifiable in combination with something else in the same document.
- EU or UK personal data: Personal data of EU and UK individuals is in scope by default. "Personal data" here means what GDPR means by it, not what feels personal.
- Financial services: Client account information, positions, and anything that would be material non-public information are in scope by default, and are covered by the never-paste list in Section 3 without exception.
2. Approved tools, and how to get a new one on the list
Why this clause is written this way: The reason to keep an approved list is not control. It is that shadow AI is already happening in your company, and a ban just moves it onto phones where you cannot see it, cannot log it, and cannot revoke it when someone leaves. A short list plus a fast answer beats a long list plus a slow one. Sanctioning two good tools removes most of the reason to go around you.
The current approved list lives at [LINK]. For each tool it names: the tool, the tier, the account type (company SSO, never a personal login), the named owner, and the date it was last reviewed. Anyone can request a new tool. Send [APPROVER] four things: the tool, what you want it to do, what data would go into it, and whether it connects to any of our systems. You get an answer within [N] working days. A no comes with a reason and an alternative. Using an unapproved tool for company work is a policy breach, not a firing offence. Tell us and we will vet it. Hiding it is the part that causes harm.
What gets added, and when
- You do not know what is in use: Before this policy goes live, run one anonymous survey: which AI tools do you use for work, and what for. Do not collect names. You will find tools nobody told you about, and that list is the only honest starting point for an approved list. Writing the list first produces a list that is wrong on day one.
- Personal or free accounts in use: Personal and free-tier accounts are not approved for company work. Consumer tiers can use your inputs for training, and they give you no admin visibility, no audit log, and no way to cut off access when someone leaves. Move to business tiers before you enforce anything else in this policy.
- Tools connected to your systems: Any tool connected to one of our systems is reviewed on connection and again every [CADENCE]. The review checks what it can still reach, whether that is still the minimum it needs, and whether anyone who set it up has since left.
- Light approval appetite: Approval is one named person and a two-working-day answer. No form, no committee, no security questionnaire.
- Formal approval: Approval requires a written request, a security review, and a record kept against the tool showing its owner, its contract status, its renewal date and the date of its last review.
- DPA required: No tool is approved for any work involving personal data until a data processing agreement is signed. The tool can be trialled on synthetic or public material in the meantime.
- BAA required: No tool is approved for any work involving protected health information until a business associate agreement is signed. There is no trial exception for this one.
- Unsure about contracts: Before approving anything, find out whether you need a data processing agreement (you do, if personal data goes in) or a business associate agreement (you do, if health information goes in). Both are standard documents that vendors sign routinely. Not knowing is not a defence.
3. What must never be pasted into a model
Why this clause is written this way: Write this as concrete nouns, not as "confidential information". People do not classify documents in their heads at 4pm; they recognise things. OWASP lists sensitive information disclosure as one of the top risks in LLM applications precisely because the leak path is ordinary use, not an attack. The list below is the one people can actually apply.
Never paste into any AI tool, approved or not: - Credentials of any kind: passwords, API keys, tokens, private keys, connection strings, session cookies. - Anything under an NDA that names the counterparty. - Unreleased financials, cap table, or deal terms before announcement. - Personnel matters: performance reviews, disciplinary records, salary data, or health information about a named person. - Whole database exports, or any file you have not opened and read first. - Source code from a private repository, unless the tool is on the approved list and the repo owner has said yes. If you are unsure, the test is simple: would you be comfortable if this exact text appeared in a stranger's chat window? If not, redact it before you paste it.
What gets added, and when
- Customer data leaks in accidentally: Support tickets, forwarded email threads and screenshots are where customer data gets into tools without anyone deciding to put it there. Treat a pasted ticket as a pasted customer record, because that is what it is.
- Privileged profession: Privileged communications and matter files never go into an unapproved tool under any circumstances, including for a quick summary and including with names removed. Removing the names does not remove the privilege problem.
- Healthcare: Protected health information never goes into a tool without a signed business associate agreement, and then only the minimum needed for the task.
- Financial services: Material non-public information never goes into any AI tool, approved or not, at any tier, for any reason.
4. Customer and personal data
Why this clause is written this way: A model vendor that processes personal data on your instructions is a processor whether or not anyone in your company used that word. GDPR Article 28 puts the obligation on you to have a contract in place with them; Article 32 puts it on you to have appropriate security. The practical version of both is: minimum data, signed paperwork, and no AI tool becomes the place a record lives.
Customer and personal data may only be put into approved tools that have the required contract in place, and only the minimum needed for the task. Redact before you paste: names, email addresses, phone numbers, account numbers, addresses, and anything else that identifies a person on its own or in combination. [Name the redaction method you actually use here. If there is not one, that is the first thing to fix.] No AI tool becomes a system of record. If the output matters, it goes into the system that already holds that kind of record. If a customer asks what happens to their data in your AI tools, the honest answer must already exist in writing before they ask.
What gets added, and when
- No customer data: Today this section is a boundary, not a workflow. Keep it, because the first time someone pastes a support thread into a tool it will have stopped being true and nobody will announce it.
- Customer data is central: Because customer data is central to how the tools are used, this section carries the most weight in the document. Name the specific data categories, the specific tools cleared for each, and the specific person who owns that pairing. A general rule will not survive contact with a busy week.
- EU or UK personal data: Each vendor is a processor under GDPR Article 28: a written contract, processing only on documented instructions, and named sub-processors. Check where the data is processed and what the transfer mechanism is. Check the retention setting against your own retention policy — the vendor default is usually longer.
- Healthcare: Minimum necessary applies to prompts exactly as it applies to everything else. If the task can be done with the condition and not the patient, the prompt gets the condition and not the patient.
5. Human review before anything leaves the company
Why this clause is written this way: This is the second gate. Section 7 is the first. The one time a client asked us to write an AI policy, an employee had access to something they should not have had, and that access led to publishing something that was a problem. Access at the boundary, then publication. A review rule alone would not have caught it, which is why both clauses exist and why the ownership one matters more.
Nothing produced with an AI tool goes outside the company until a named human has read it end to end and can defend every factual claim in it. That includes: client deliverables, email to clients, marketing and social posts, code merged to production, anything containing a price or a legal commitment, and anything published under a person's name. The reviewer is accountable for the content as if they had written it. "The model said so" is not a defence, internally or to a client. Where the output contains a number, a citation, a quote, a name or a date, the reviewer checks it against the source. Those are the five things models get wrong most often and the five things a reader will check.
What gets added, and when
- Drafting only: Since everything is drafted and sent by a person today, this clause is the whole of your risk control. Keep it short and enforce it. Add Section 6 the day the first automation gets the ability to send something itself.
- Automations already act: Where an automation can send something outward without a person in the loop, this clause does not protect you. Section 6 does. Go and check which of your automations can currently reach an external recipient.
6. Agent actions and approval tiers
Why this clause is written this way: Drafting and acting are different risks and most policies treat them as one. Three tiers is the smallest split that works, and the line that matters is not how clever the automation is — it is whether the blast radius stops at your own systems. Scoped credentials are the control that does the actual work here. A token that can only do one thing can only cause one kind of problem.
Tier 1 — Draft only. The tool produces text, code or a suggestion, and a person sends it. No approval beyond being on the approved list. Tier 2 — Acts inside our systems. Writes to a record, moves a file, creates a ticket, schedules something. Requires a named owner, credentials scoped to exactly what it needs and nothing more, and a log of what it did. Tier 3 — Acts outside the company, or moves money. Sends email to an outside recipient, posts publicly, changes a customer-facing record, issues a refund or a payment. Requires either a human approval step per action, or a hard cap plus daily review. No new Tier 3 automation runs unattended in its first 30 days. Nothing gets a credential broader than its job because a broader one was easier to create. Every automation has an owner whose name is on it, and the owner is the person who turns it off.
What gets added, and when
- Drafting only today: You are Tier 1 across the board today. Keep the section anyway, so that the first person who wires something into a system reads a rule instead of inventing one.
- Tier 3 already live: You already have Tier 3 automations running. Before this policy goes live, list them, check each one's credentials against what it actually needs, and confirm each one has a name against it. In our experience that audit finds at least one credential broader than the job.
- Formal approval: Tier 2 and Tier 3 automations are recorded in a register with owner, scope, credentials, log location and review date.
7. Named owners for information going out of the platform and coming in
Why this clause is written this way: This is the clause people skip. Everyone writes rules about what employees may do, and almost nobody names a person for each piece of information going out of the platform and coming in. So nobody owns the in/out boundary, and nothing gets checked at it. NIST's AI Risk Management Framework puts GOVERN first and treats accountability structures as a named function; this clause is that idea cut down to a table a 30-person company can fill in on a Tuesday. Standing connections are the row people forget, because they were set up once and then nobody looked again.
Every category of information that enters an AI tool, and every category that leaves one, has a single named owner. Not a team. A person, by name, in a table. Write it with four columns: information category / direction (in or out) / named owner / what they check. At minimum, name an owner for each of these rows: - Client and customer records going in - Employee and HR information going in - Source code and internal systems documentation going in - Files, drives and knowledge bases connected to a tool for retrieval — standing, in, and the row most often left blank - Anything generated that will be published, sent externally, or shown to a client — out - Anything generated that will be written back into a system of record — out The owner's job is not to approve every item. It is to be the person who gets asked, and the person who reviews who has access to that category every [CADENCE]. If a row has no name in it, that category is unowned, and it should not be connected to anything yet.
What gets added, and when
- Tools connected to your systems: Start the table with the standing connections, not the chat tools. A knowledge base connected six months ago is still handing out whatever was in it, to whoever can reach the tool, and the access list has almost certainly drifted since.
- Under 50 people: At your size the same two or three names will fill most of the table, and that is fine. The value is not the spread of ownership, it is that the row is not blank.
- 50 people or more: Owners are named individuals, not roles, because a role does not answer email. Review the table whenever someone in it changes job or leaves, not only on the review cadence.
8. Disclosure to clients
Why this clause is written this way: Two questions, in this order. Does a contract require it? And would the client be annoyed to find out later? The second one is the one that costs you the relationship, and it does not appear in any contract. Check your own MSAs for subcontractor and confidentiality language before you write this clause — plenty of them already restrict sending client material to a third party, and a model vendor is a third party.
Before this policy goes live, someone reads our client agreements for the words AI, machine learning, subcontractor, processor and confidentiality, and writes down what they found. Where a contract requires disclosure, we disclose in writing before the work starts, not in the delivery email. Where no contract requires it, the default is: we answer honestly if asked, and we volunteer it where AI did substantive work rather than spelling and grammar. We never present model output as the work of a named person who did not review it.
What gets added, and when
- Contracts require disclosure: Keep a list of which clients require disclosure and in what form. Put the check into the project kickoff, not into the delivery step, because by delivery the tool has already been used.
- Voluntary disclosure: Say it plainly and once, in the statement of work: which parts of the work use AI tools, who reviews the output, and what we do not put into a model. Volunteering it early is cheaper than being asked about it late.
- Contracts not checked: This is the first thing to do, before anything else in this policy. It takes an afternoon with a search across your signed agreements, and it is the one item here that can already be a breach today.
- No disclosure obligation: No obligation today does not mean no obligation next quarter. Re-check at each review, and re-check any time a client sends a new master agreement.
9. Logging and retention
Why this clause is written this way: You cannot investigate what you did not log, and the retention default on a business chat tool is usually longer than your own document retention policy — which means the tool has quietly broken a policy you already had. Check the two against each other. It takes ten minutes and it is the single most common mismatch we find.
Company AI accounts are on business tiers with admin visibility. Personal accounts have none, which is the practical reason they are not approved. Chat and prompt retention is set to [N] days and is checked against our existing document retention policy. Where they disagree, the shorter one wins. Every automation that acts in our systems writes a log: what it did, when, under whose authority, and what data it touched. Logs are kept for [N] and are readable by [OWNER]. Do not switch logging off to reduce noise. Reduce the noise.
What gets added, and when
- EU or UK personal data: Retention has to be defensible against the storage limitation principle, which means a period you chose for a reason, not the vendor default you never looked at.
- Formal approval: Logs and the approved-tool register are reviewed together at each cycle, and the review itself is recorded with a date and a name.
- Automations act in systems: An automation that can act without a log is an automation you cannot investigate. If a tool cannot produce one, that is a reason to not approve it, not a detail to work around.
10. Incident reporting
Why this clause is written this way: The highest-value line in any AI policy is the one that makes reporting cheap. If reporting a bad paste feels like confessing, people stop reporting, and self-reports are your only early warning — nothing else in your stack will tell you that someone put a contract into a personal chat account. Write the no-penalty sentence and mean it, or do not bother writing the section.
If you think something confidential went into a tool it should not have, or an AI-generated error went out to a client, tell [NAMED PERSON] the same day. Directly. Not through a form. There is no penalty for promptly reporting your own mistake. The penalty exists for not reporting it. [NAMED PERSON] then works out what data was involved, checks whether the vendor's retention means it still exists, checks whether any disclosure or notification obligation is triggered, and writes down what changed so the same thing does not happen twice. Every incident gets one written paragraph, kept. Three paragraphs a year tell you more about your real risk than any framework will.
What gets added, and when
- EU or UK personal data: Where personal data is involved, GDPR Article 33 sets a 72-hour clock for notifying the supervisory authority from the point of becoming aware. Work out in advance who makes that call, because 72 hours is not enough time to also decide who decides.
- Healthcare: Where protected health information is involved, breach notification obligations may apply. Name the person who assesses that, and name their backup.
- Customer data in play: Include in the assessment whether the customer needs to be told. Deciding that in the moment, under pressure, is how companies end up choosing silence.
11. Review cadence, and the date at the top
Why this clause is written this way: A policy with no visible review date stops being read, and everyone can tell. Model behaviour, vendor data terms and your own tool list all change faster than annually, so an annual review means the document is wrong for most of the year. Put the next review date at the top of page one where it is the first thing anyone sees.
This policy is reviewed every [CADENCE] by [OWNER]. The next review date goes at the top of page one. Each review checks four things: the approved list against what people are actually using, the named-owner table against who still works here, every incident since the last review, and whether any vendor changed its data terms. Anyone can propose a change at any time. Send it to [OWNER]. Changes are announced, not silently republished. Version and date every revision. A policy nobody can date is a policy nobody can rely on.
What gets added, and when
- Light approval appetite: Quarterly for the first year, then twice a year once the tool list stops moving. Fifteen minutes with the list beats an annual rewrite nobody schedules.
- Formal approval: Reviews are minuted, and the minute names who attended and what changed.
- Tool list not yet under control: Re-run the anonymous usage survey at the first two reviews. The gap between the approved list and the survey is the only honest measure of whether this policy is working.
When a policy is premature, and when you need a lawyer instead of a generator
If nobody at your company uses AI tools for work yet, do not write this. You will produce a document about a situation you have not met, and it will be wrong by the time anyone reads it. Run the anonymous survey, wait a quarter, then write the policy against what you found. And if you are five people who can all see each other's screens, take two clauses — the never-paste list and the named owners for standing connections — and leave the other nine.
Go to a lawyer, not a generator, in four cases. When a client contract already restricts sending their material to third parties and you want to know whether a model vendor counts. When you are subject to a regulator who will ask to see this document and ask you to defend it line by line. When an incident has already happened and you need to know your notification obligations, not your policy. And when you operate across jurisdictions with different rules about personal data and automated decision-making, because a generic clause will be wrong in at least one of them.
Here is the honest limit of this tool. It cannot read your contracts, it does not know your regulator, and no lawyer has reviewed a word of it. It gets you from nothing to a draft that names the right things, which is a real saving on a lawyer's hour but is not a replacement for one.
One more limit worth saying out loud. A policy does not stop anything by itself. If your tools are on personal accounts with no admin visibility, no logs and no way to revoke access, you have written a document about a system you cannot see. Fix the accounts first. The policy is how you keep it fixed.
Who reviewed this, and how to check
Written and last reviewed on 24 August 2026 by Ashutosh Upadhyay, founder of Cognio Labs. We build and run AI agents for companies in the 20 to 50 person range, which is where the clause list above comes from — it is the set of things we end up writing down for clients, not a summary of other people's templates. The reasoning for every clause is on this page so you can argue with it rather than trust it. The external sources we leaned on are listed below, each one attached only to the specific point it actually supports.
What this page is not: legal review. Nobody with a practising certificate has looked at it. We say that here rather than burying it, because the alternative — implying a review that did not happen — is exactly what makes policy templates untrustworthy.
What to do after you have the policy
Fill in every square bracket. Name the approver, the incident contact, the retention period and the owners in the Section 7 table. Then send it round with one sentence about why it exists, and run the anonymous tool survey in the same week so your approved list starts from reality rather than from a guess.
If your tools already act rather than draft, the longer version of Section 6 is in our guide to AI agent security and governance, which covers scoped credentials and approval tiers in more depth than a policy document should. If you are not sure whether you are ready to build anything at all, the AI readiness assessment is twelve questions and takes four minutes. When you want the guardrails built rather than written down — approved tools, scoped access, logs, named owners — that is the programme we run. The rest of our free tools are in the resources library.
Frequently asked questions
Is this AI policy template really free, with no email required?
Yes. The generator runs entirely in your browser, no answer is transmitted anywhere, and the finished policy appears as plain text on the page that you can select and copy. There is no email gate, no sign-up and no download wall. The download button exists as a convenience, not as the way to see the result.
How is a generated AI policy different from downloading a template?
A template gives you every clause and leaves you to delete the ones that do not apply, which is the step most people never finish. This assembles eleven clause blocks from your answers to eight questions, so a drafting-only company of 15 people gets a shorter document than a healthcare company running automations that write to systems. The default text of every clause is also printed on this page, with the reasoning behind it, so you can read the whole thing before answering anything.
Has a lawyer reviewed this AI acceptable use policy template?
No. It was written and reviewed by Ashutosh Upadhyay, founder of Cognio Labs, and last reviewed on 24 August 2026. It is not legal advice and no lawyer has been involved. Have your own counsel review it before you adopt it, particularly the customer data, disclosure and incident clauses, and particularly if you are in a regulated industry. What this gives you is a first draft that is specific enough to be worth a lawyer's time instead of a blank page.
What is the one clause most AI policies get wrong?
Named owners for information going out of the platform and coming in. Almost every policy sets rules for what employees may do, and almost none names a person against each category of information crossing the boundary in either direction. Because nobody owns the boundary, nothing gets checked at it. The standing connections — a drive or a knowledge base wired into a tool six months ago — are the rows left blank most often.
Should we ban AI tools instead of writing a policy?
Banning moves the usage onto personal phones and personal accounts, where you have no admin visibility, no logs, and no way to revoke access when someone leaves. You do not remove the risk, you remove your view of it. Sanctioning two good tools on business tiers, with a named approver who answers in two days, removes most of the reason anyone goes around you.
When is writing an AI policy premature?
If nobody at your company is using AI tools for work yet, a policy is a document that will be out of date before it is read. Find out what is actually in use first, with one anonymous survey. And if you are a team of five where everyone can see everyone's screen, the two clauses that matter are the never-paste list and the named owners for standing connections. The other nine can wait.
How often should an AI acceptable use policy be reviewed?
Quarterly for the first year, then twice a year once your tool list stops moving. Vendor data terms and model capabilities change faster than annually, so an annual review leaves the document wrong for most of the year. Put the next review date at the top of page one, since a policy with no visible review date stops being read.
Does this cover AI agents that take actions, not just chat tools?
Yes, in Section 6. It splits work into three tiers: drafting only, acting inside your own systems, and acting outside the company or moving money. Tier 2 needs a named owner, credentials scoped to exactly the job, and a log. Tier 3 needs a human approval per action, or a hard cap plus daily review, and nothing new runs unattended in its first 30 days.
Sources
- NIST, AI Risk Management Framework (AI RMF 1.0) — GOVERN is the first of its four functions and it treats accountability structures as a named part of managing AI risk. Section 7 of this policy is that idea reduced to a table of names. NIST does not prescribe the table; we do.
- OWASP GenAI Security Project, LLM02:2025 Sensitive Information Disclosure — the basis for writing Section 3 as a list of concrete things rather than as “confidential information”. Sensitive data reaching a model through ordinary use is a named top-ten risk, not an edge case.
- GDPR Article 28 (Processor) — why a model vendor handling personal data on your instructions needs a written contract, and why Section 2 gates approval on it.
- GDPR Article 33 (Notification of a personal data breach) — the 72-hour clock referenced in the incident clause for companies handling EU or UK personal data.
- The trigger story and the named-owner clause come from our own client work at Cognio Labs, anonymised, with no numbers attached because we do not have any to attach. It is first-hand observation, not research.
Want the policy pressure-tested?
Thirty minutes, no pitch. Bring the generated draft and we will tell you which clause will not survive your actual setup — usually the one about who owns the standing connections. Including when the answer is that you should fix your accounts before you hire anyone.