The AI Policy Template That Fits on One Page

If your team is already using AI, I would start by giving them a clear way to use it for work, which tools are allowed, what data can go into them and who checks the result before it reaches a client.

You can put those everyday rules on one page, and for a small business that page is the AI policy people actually use. Your lawyer may need more behind it, but the person trying to finish a client report needs an answer they can find and follow while doing the job.

Through a franchise network's delivery data, I have seen a practical version of this, an internal AI tool covered by a defined data privacy agreement, a ban on putting work data into public tools, and a path for people to propose a new tool before using it.

That is the practice behind this AI policy template. The six rules below are my way of making the operating boundaries easy to remember, they spell POLICY, and they include a boundary for agents that can take actions rather than just write a response.

The one-page AI policy for a small business

P: Pick from the approved list. Use only the firm's approved tools and accounts for work, within their approved purposes and data limits. The firm checks their data agreements and settings before approval. Approved tools: [tools, account types and permitted uses]. List owner: [name].

O: Off-limits. Do not put client or third-party data into public AI tools, even when those tools are approved for other work. This includes prompts, uploaded files and sharing links. Approval of a tool does not override a client's restrictions or permit public sharing of their information.

L: Loop the firm in. Found a better tool? Propose it to [name or channel] before using it for work. It must be checked and approved first. Report a suspected data exposure or mistaken action to the same owner promptly so the firm can respond.

I: Irreversible actions need a person. Agents may act alone only within an approved workflow where their work can be checked, mistakes can be caught in time and the consequences can be undone safely. Anything irreversible or client-facing needs a person's approval before the action happens.

C: Client terms decide disclosure. Follow applicable law, professional duties and each client's terms on notice, consent and disclosure. Obtain required consent before using AI on the work. Answer client questions truthfully, and ask [name] when the requirement is unclear.

Y: You own what you ship. Before AI output reaches a client or a production system, a named person verifies it and is responsible for its use. Check facts, sources, client context and any commitments the work makes.

Never use AI to impersonate a person or let it independently sign, commit or bind the firm.

Policy owner: [name]. Effective date: [date]. Next review: [date]. Approved-tools list: [location].

This is an operator's starting template, not legal advice or a claim that one page meets every obligation. Have the person responsible for legal advice check it against your jurisdiction, industry, contracts and actual tools before adopting it.

You can use the companion, Where Client Data Is Allowed to Go, to write down your approved tools, data limits and request contact. Fill it in, have the relevant adviser check it, then walk your team through it alongside this policy. Download the editable Word version.

You will notice that the C rule doesn't just say to disclose AI whenever it is used, and it doesn't say to stay quiet unless someone asks. Different work can have different requirements, and your policy needs a way to find the requirement before the work starts.

The important part of keeping it short is that somebody can use it under pressure. Imagine a person about to paste a client file into a free chatbot because the approved process is too slow for the deadline.

If your policy says to consider whether the information is sensitive, that person has to make a data decision while also trying to finish the job. A stack trace may look like ordinary code and still contain information about a customer.

The approved-list rule gives them a simpler first decision. Is this the approved tool and account for this kind of work, and is this data allowed there?

That does not eliminate all judgment, because approval still has to cover the use and the data. But the firm makes the tool decision once with the proper information instead of asking each employee to improvise it every afternoon.

The list also has to offer a workable option. If you tell people they cannot use the tool that gets the job done and give them no alternative or proposal path, the deadline is still there when your policy announcement is over.

I would not call that a failure of the team's attitude. As the owner, you need to supply the approved route and make it possible to ask when that route doesn't cover the work.

The older survey figures explain why simply having a document is not enough. In McKinsey's 2023 global survey, 21 percent of respondents whose organizations had adopted AI said they had policies governing employees' use of generative AI.

A September 2023 Littler survey reported by SHRM found that 37 percent of 399 employers had AI policies. These are different samples and old snapshots, not a current count of how many service firms have rules.

And in UpGuard's shadow-AI study, 40 percent of employees recalled AI training, while 40 percent reported using unapproved tools daily. Those two percentages don't tell us that the same trained people were all in the daily-use group, or that training caused the behavior.

They give you a reason to look at what happens after the training. Can people name the approved tool, can they use it for the task they need, and do they know who to contact when they can't?

I like the way FRB Law describes the enforcement problem: “Employees quickly learn which rules are real and which are decorative.”

If the policy says a person must approve a client email but the agent has permission to send it without approval, the workflow is teaching a different rule from the page. Fixing the wording alone won't change that.

Sharing is another place where the tool name can distract you from the actual risk. An approved account with suitable protections can still expose information if someone makes the output public.

In 2025, ChatGPT's discoverable-sharing feature allowed shared conversations to appear in search results. On July 27, 2026, Axios reported that publicly shared Claude artifacts were appearing in Google results, including business plans and clinical-trial material.

Those reports concern shared content, they do not establish that private chats were all made public. The lesson for your policy is to treat the sharing link as a data decision too, because a person may think they are passing a document to one colleague when they are publishing something more widely.

The same care applies to inputs, and that is where people ask what you shouldn't share with ChatGPT. The Samsung reporting in 2023 described employees putting sensitive material into ChatGPT, including source code.

Whether a provider uses submitted material for training depends on the product, account, settings and agreement. I would not tell the team that every public chatbot trains on everything, or that a paid subscription by itself makes client data safe.

Have the firm check those conditions and the client's permission, then make the allowed use plain. The person producing a report should not have to interpret a vendor's data terms while the client is waiting.

Now look at the agent rule, because this is where a familiar instruction can stop working. With a chatbot, you ask for a draft and read it before deciding what to do with it.

An agent connected to email or billing may be able to take the next step itself. If it has already sent the reply or issued the invoice, reviewing the text afterward is too late to provide approval before the action.

So “review AI output before use” needs to be implemented as a real stop before the action, not left as a sentence that assumes the stop is already there. This is a gap to check in a policy, not a claim that every other policy template ignores agents.

An agent drafting a client reply and leaving it in an approval queue stays on the preparation side. Give the same agent permission to send that reply and it has crossed into client-facing work, so the I rule requires a person before it sends.

For internal actions that can run alone, check more than whether a button says undo. Can you detect the mistake in time, and does undoing it repair the consequence, or has another person already acted on the wrong information?

A wrong internal summary can become a bad client promise when someone quotes it in a proposal. That is why owning the output includes checking what the next person will do with it, not only where the file is stored.

The policy above deliberately sets a conservative client-send boundary. If you later want a tested workflow to send routine messages automatically, that needs an explicit policy decision and controls, not an employee quietly treating the word routine as permission.

Client contracts deserve the same attention. The Association of Corporate Counsel publishes sample AI guidelines for outside counsel, which is a concrete example of buyers putting expectations about AI into the instructions they give professional firms.

A sample is not a rule binding every firm. What binds your work depends on the client's actual terms, the agreement you accepted, applicable law and any professional duties that apply to you.

For US lawyers, the ABA's Formal Opinion 512, issued July 29, 2024, discusses competence, confidentiality, communication and reasonable fees when using generative AI. It is guidance on the ABA Model Rules, not a law that automatically governs every jurisdiction or every service business.

Consent and disclosure depend on the circumstances, including confidentiality risks, relevance to the representation and the client's instructions. Lawyers need to check the rules and opinions governing their own work, and a consulting or agency owner should not copy a legal-profession requirement as if it applied universally.

That is why the C rule names the sources of the obligation and gives the team someone to ask. Honest answers matter, but so does obtaining consent before use when consent is required, answering truthfully afterward doesn't repair having skipped it.

You can put this page in the employee handbook, with the current approved-tools list somewhere people can reach easily. Name the owner and set a review date, I would review it quarterly and whenever a tool, contract or workflow changes the rules people need to follow.

Then walk the team through actual examples from their work, a file upload, a shared link, an agent preparing a message and the point where a person approves it. Ask them to show you what they would do, rather than asking whether they have read the page.

Keep the proposal path open and validate new tools before approving them. That is part of the practice I have seen, people can suggest an option, but suggestion does not become permission to use it on client work.

This gives you a controlled starting point for AI use that was happening without company oversight. It won't redesign delivery, prove an AI return or make the firm AI-native, and it won't replace training, access controls or the fuller legal material your work may require.

Fill in the names, tools and dates, get the relevant legal review, and show the team where approval actually happens in the workflow. The page is ready to be useful when the work follows the same rules.