My last post introduced a free AI acceptable-use policy for small and mid-size companies. That post was for business owners. This one is for the people who must make a policy work: IT leads, security and compliance people, and consultants who advise clients.
Before I wrote a single line, I studied about a dozen public AI policies. They came from security bodies, financial-sector groups, state governments, universities, and law firms. The weak ones failed in the same ways:
- They banned AI, and staff moved to personal accounts.
- They named specific tools, and the names went stale within a year. One well-known framework from 2023 still lists Google Bard.
- They said “verify the output” but never said how.
- They covered chatbots only. They missed notetakers, browser extensions, AI inside other software, and agents.
- They had no route for exceptions, so people made their own.
I designed our template around these failures. Below are the nine decisions that matter most, the alternatives that I rejected, and the frameworks behind each one. I quote the template directly, so you can judge the wording yourself.
Decision 1: An approved list with fast requests, not a ban
The alternative I rejected: “No AI unless approved”, with a slow review.
A slow ban feels safe on paper. In practice, it moves AI use to phones and personal accounts, where you have no contract, no logs, and no visibility. That is “shadow AI”, and it is the main risk that comes without an attacker.
So the policy allows approved tools and promises a fast decision on new requests:
From the template, section 4:
4. We decide on requests within 5 business days. Low-risk requests can be faster.
6. A new AI feature inside software that we already use counts as a new tool. Do not turn it on until we approve it.
Item 6 matters more every month. AI features now appear inside email, CRM, and design tools with a simple update. NIST’s Generative AI Profile asks organizations to decide explicitly how to treat AI that sits inside other software (action GV-1.6-002). Our answer is simple: it counts as a new tool.
Frameworks: NIST AI 600-1 GV-1.4-002 (transparent acceptable-use policies) and GV-6.1-007 (approved provider lists).
Decision 2: The policy names no tools
The alternative I rejected: a list of allowed and banned tools inside the policy.
Tool names change faster than policies. If the policy names tools, you must re-approve the whole policy every time you add one. So the policy points to a separate, living list: the AI Tool Register. The register is Template 2 in this series.
This also helps with audits. An auditor wants to see a stable policy and a current inventory. NIST AI RMF GOVERN 1.6 asks for exactly that: mechanisms to inventory AI systems.
Decision 3: Three data tiers, not four
The alternative I rejected: the classic four tiers (public, internal, confidential, restricted).
Four tiers work in large companies with trained staff. In a 40-person company, people mix up “confidential” and “restricted” all the time. A rule that people cannot remember is a rule that people do not follow.
So the template uses three tiers and two tie-breakers:
From the template, section 5:
– If you do not know the tier, treat the data as Restricted.
– Remove names and other identifying details if the task does not need them.
– Give the AI tool only the part of a document that the task needs.
The table in the same section also says that passwords, API keys, and other secrets go into no AI tool, ever. No exception process can change that rule.
The last two bullets are the plain-language form of data minimization. In the healthcare version, the same idea appears with its legal name: the HIPAA “minimum necessary” standard (45 CFR 164.502(b)).
Decision 4: The scope covers everything that is AI, not only chatbots
The alternative I rejected: “This policy covers generative AI tools such as ChatGPT.”
That sentence leaves out the riskiest tools. Our scope lists six types: chat assistants, AI inside other software, meeting notetakers, browser extensions and AI browsers, code assistants, and agents.
Notetakers deserve a special mention. Lawsuits about AI notetakers and recording consent are already moving through US courts. Many US states require the consent of all parties to record a conversation. So the template has a clear rule: no recording or transcription without the consent of all participants.
Browser extensions are the quiet risk. They can read everything on the screen, including data that never goes into a chatbot.
Decision 5: “Open every source”, not “verify the output”
The alternative I rejected: a general duty to “verify AI output”.
“Verify” has no standard. Everyone thinks they verified. So the template turns it into actions that you can check:
From the template, section 7:
4. Open and read every source or citation that an AI tool gives you. Do not use a source that you cannot find.
6. Get a second person to review AI-assisted work before it goes to [customers, regulators, or the public]. Do the same before you use it for legal or financial decisions.
The reason is a real failure. In 2025, a large consulting firm partially refunded a government client after people found fabricated references in a report. A “verify the output” clause would not have stopped it. “Open every source” would have.
Frameworks: NIST AI RMF MAP 3.5 asks you to define, assess, and document your processes for human oversight. Section 7 is that process, written for staff.
Decision 6: A separate section for agents, mapped to the 2026 OWASP list
The alternative I rejected: treating agents like any other AI tool.
Chatbots produce text. Agents take actions. The risk changes from “wrong answer” to “wrong action”. The OWASP Top 10 for LLM Applications 2026 reflects this: Excessive Agency (LLM03) moved up to third place, from sixth in the 2025 list.
From the template, section 9:
2. Give each AI agent the minimum access that it needs. Use read-only access when possible.
3. A person must approve each agent action that is difficult to reverse. Examples: sending external messages, making payments, deleting data, changing live systems, and changing access rights.
4. Each AI agent has a named owner who monitors it and can stop it immediately.
7. AI tools can follow hidden instructions in websites, emails, and documents (“prompt injection”). Do not let an AI tool act on content from outside the company without a person checking the result.
Item 7 addresses LLM01:2026, Prompt Injection, which is still the number one risk on the list. Item 4 gives you a named person with a switch-off. NIST calls this a mechanism to “supersede, disengage, or deactivate” a system (MANAGE 2.4). The Generative AI Profile adds that you should agree the switch-off criteria in advance (MG-2.4-004).
Decision 7: In a multi-state company, apply the strictest rule everywhere
The alternative I rejected: different rules for each location.
The healthcare example is a fictional clinic group with clinics in Texas and California. The two states have different rules:
| Topic | California | Texas |
|---|---|---|
| Recording a conversation | Consent of all parties (Penal Code §632) | Consent of one party |
| AI-written clinical messages | A disclaimer and contact instructions, unless a licensed provider reviewed the message (Health and Safety Code §1339.75, from AB 3030) | Tell patients that AI is used in their care, by the date of service (HB 149, the Texas Responsible AI Governance Act, from January 1, 2026) |
| AI used for diagnosis | — | The practitioner reviews all AI-generated records and tells the patient (SB 1188) |
Staff move between clinics. Patients call any clinic. Two rule sets would cause mistakes. So the example uses one standard, set at the stricter level:
From the healthcare version, section 7:
5. In our California clinics, get consent from every person in the room, for example a parent or an interpreter. California law requires the consent of all parties to a confidential conversation.
6. In our Texas clinics, follow the same steps. Riverbend uses one standard in all clinics.
The same thinking decided the clinical messages. Instead of adding the California disclaimer to some messages, the example says that a clinician reviews every AI-drafted clinical message. Automated messages may not contain clinical information at all. One simple rule meets both states.
Decision 8: For AI software companies, separate the policy from the engineering standard
The alternative I rejected: one long document with every engineering control in it.
An AI software company has two kinds of AI risk: staff who use AI tools, and a product that is AI. If you put every engineering step into the policy, it becomes too long for sales and support staff, and too short for engineers.
So the B2B example splits it. The policy sets the rules. A separate Secure Development Standard explains how engineers meet them. The policy also defines customer data broadly, because many teams forget parts of it:
From the B2B AI SaaS version, section 2.3:
Customer data: all data that a customer or its users put into the Ardent platform, including documents, prompts, outputs, embeddings, logs, and files.
Embeddings are the number form of documents that AI uses for search. They are customer data too. So are logs. The product section then turns customer promises into rules, for example tenant isolation, which addresses OWASP LLM09:2026 (Vector and Embedding Weaknesses). It also covers hidden instructions:
From the B2B AI SaaS version, section 7:
10. Hidden instructions. System prompts and other hidden context must not contain secrets or another customer’s data. Assume that a user can make the AI reveal them.
That rule addresses LLM08:2026, Hidden Context Exposure. The example ends with an appendix that maps nine common customer security questions to the section that answers them and the evidence to attach. For a startup that sells to enterprises, that table can shorten every security review.
Decision 9: For consulting firms, the client decides
The alternative I rejected: one firm-wide AI rule for all clients.
A consulting firm works with confidential information that belongs to its clients. Clients have different views about AI. Some welcome it. Some forbid it in their contracts. So the consulting example gives the decision to the client:
From the consulting firm version, section 6:
1. Before work starts, the engagement lead sends the client AI-use notice to the client.
2. The client chooses: agree, agree with limits, or do not agree. The engagement lead stores the signed notice in the engagement folder.
4. If the client does not agree, do the work without AI tools on its data. You can still use AI on public information.
The example adds two rules that I rarely see in other policies. First, one separate workspace for each client in each AI tool, so two clients’ data never mix in one chat. Second, honest billing: do not bill a client for the time you spend learning a new AI tool. That rule follows the reasoning of the American Bar Association’s Formal Opinion 512 on generative AI for lawyers, which fits consultants just as well.
The consulting example also includes a ready-to-use client AI-use notice in English and Spanish.
Three small lines that do a lot of work
Some of the most useful text in the template is only one sentence long.
Good-faith reporting. The template says: “We do not punish good-faith reports of mistakes.” You learn about a data leak only if people feel safe to report it.
Employee rights. The template protects the right of employees to discuss the terms and conditions of their employment. In the US, discipline and monitoring rules that seem to limit that right can cause legal problems. Employment lawyers add this line routinely.
Review triggers. The policy has a yearly review, but also reviews after a serious incident, a new law, or a change in a main vendor’s terms. Vendors change their data terms more often than most companies review their policies.
About the framework appendix
Each version ends with a table that maps its sections to five frameworks:
- NIST AI RMF 1.0
- NIST AI 600-1, the Generative AI Profile
- ISO/IEC 42001
- the EU AI Act
- the OWASP Top 10 for LLM Applications 2026
Three notes on how I built it:
- I checked every NIST reference against the original NIST documents. A wrong reference number in front of an auditor costs more trust than no reference.
- I used the 2026 OWASP list, not the 2025 one. The 2026 edition changed the order. Many articles still quote the old numbers.
- Alignment is not compliance. The table helps when an auditor or a customer asks how your policy maps to a framework. It does not prove that you meet a law.
For companies with staff or customers in the EU, the training section also supports Article 4 of the EU AI Act on AI literacy. The 2026 Digital Omnibus amendments softened that article to a duty to take measures to support AI literacy. It is still a duty.
How to adapt it
- Start with the industry version that is closest to you, even if your industry is different. The decisions transfer.
- Keep the three-tier data rule unless you already run a four-tier scheme that your staff know well.
- Fill the register before you publish the policy. A policy that points to an empty register teaches people to ignore it.
- Test the one-page guide on a new employee. If they cannot explain the data rule after five minutes, simplify it.
Get the templates
All four versions are free on GitHub under CC BY 4.0, in Markdown and Word: github.com/nosistech/governance-templates.
Next in this series is Template 2: the AI tool inventory and risk register. It turns “approved tools” into a scored list, with one row per use, not per vendor.
If you want help to adapt these templates to your organization, contact NosisTech.
This post is general information, not legal advice. The legal references are current as of October 2026, and laws about AI change often. Ask your legal counsel before you adopt any policy.