Most AI policies fail the same quiet way. Somebody writes fifteen pages, it goes into a shared drive, and nobody opens it again.
The document was not wrong. It was longer than anyone’s willingness to read it.
The short answer: a workable AI policy fits on one page and settles five things. Which tools are approved, what data never goes in, what to do instead, who reviews AI-assisted work, and when the policy gets looked at again.
That is enough to change behavior, which is the only thing a policy is for. The sample wording below is a starting point to react to rather than language to adopt as-is.
If you have worked through our AI Integration Checklist, this is the answer to question three. The checklist asks whether your policies are updated for AI. What follows is how to write the one that answers it.
Why Short Beats Comprehensive
A long policy tries to anticipate every situation. An employee hits one it did not anticipate, finds the document unhelpful, and stops consulting it.
A one-page policy accepts that it cannot cover everything. It settles the decisions that come up daily and routes the rest to a person.
There is a second reason. AI tools change on a quarterly cycle, and a long policy takes long enough to write that nobody wants to revise it. So it goes stale and stays published anyway.
Decision One: Name the Approved Tools
Pick two or three. Put them on business or enterprise tiers with agreements in place, and name them explicitly.
Employees may use [Tool A] and [Tool B] through the company account for work purposes. Personal AI accounts must not be used for company information.
The account matters more than the tool. Business tiers generally exclude your data from model training by contract, while free and personal accounts often do not. Our guide to what not to put into AI covers that distinction in detail.
Decision Two: List What Never Goes In
Name categories rather than examples. Examples invite people to decide whether their situation counts.
The following must never be entered into any AI tool: customer or member records, login credentials, health information, employee files, nonpublic financial information, and anything covered by a contract or a regulator.
Adjust the list for what your organization actually handles.
Decision Three: Say What To Do Instead
A prohibition with no alternative gets ignored, because the underlying task does not go away. Give people a route.
Remove identifying details such as names and account numbers before using an AI tool. If a task requires real customer, patient or otherwise regulated information, contact IT before proceeding.
This is the line that decides whether a policy works. Most unapproved AI use is people trying to do their jobs faster, not people being careless.
Decision Four: Name a Reviewer
AI output can be wrong in confident, well-formatted prose, which is harder to catch than an obvious error.
Any AI-assisted work going to customers, regulators, the board or anyone outside the organization must be reviewed and approved by [role] before it is sent.
Name the role rather than the person, so the policy survives someone changing jobs.
Decision Five: Set a Review Date
This policy will be reviewed on [date] and after any change to the approved tool list.
Put an actual date in the document. A policy with no review date becomes wrong without anyone noticing.
What Changes by Industry
The five decisions above work for any organization. Regulated ones have to settle more, and this is the part most policy templates skip. Treat what follows as a starting list of questions rather than a set of answers.
| If you are a | What your policy also has to settle |
|---|---|
| Bank or credit union | Whether AI tools are assessed as vendors under your information security program, who signs off before member data goes near one, and how that assessment is evidenced when an examiner asks. |
| Healthcare provider | Whether a Business Associate Agreement exists for any tool that could touch patient information, and what staff are told to do when one does not. |
| DOD contractor | Which environments are approved for controlled unclassified information, and where employees route that work rather than deciding for themselves. |
| Firm working under NDA | Whether your client agreements permit third-party processing at all, and who checks before work product goes into a tool. |
For banks and credit unions, this is where AI connects to the vendor risk process you already run. NCUA’s 2026 supervisory priorities name vendor management and protecting member data among examination focus areas, so an examiner asking about AI is really asking whether it went through the same process as every other vendor.
Healthcare organizations and DOD contractors have the harder version, because there is no de-identified form of protected health information or CUI that makes a consumer tool acceptable.
We have deliberately not published ready-made wording for any of these. Two institutions of the same size in the same sector can carry different obligations depending on their charter, their examiner, their contracts and what they already have in place. A clause copied from a web page can end up documenting an assessment that never happened, which is worse than having no policy at all. The only reliable way to get this right is to walk through your particular setup with someone who does it regularly.
Getting People To Actually Read It
Two things move adoption more than the wording does.
- Send the page itself. Attach the one-page document rather than a link to a policy portal. Ask for a written acknowledgment and keep it on file, because that record is what an examiner or an insurer asks for later.
- Lead with what is allowed. Tell people which tools they can use before telling them what they cannot do. A policy that opens with approvals reads as support. One that opens with prohibitions reads as suspicion, and people route around it.
Frequently Asked Questions
Does a small business really need an AI policy?
Yes, and one page is enough. If employees handle customer, financial or health information, the exposure exists regardless of headcount.
What should an AI acceptable use policy include?
At minimum: the approved tools and account tiers, the data categories that must never be entered, what employees should do instead, who reviews AI-assisted work before it leaves the organization, and a review date.
How often should we update our AI policy?
At least twice a year, and immediately after any change to your approved tool list. AI platforms change their data handling terms more often than most vendors do.
Start With What Is Already in Use
A policy written without knowing what your team already uses tends to describe a situation that does not exist. In every AIStack Challenge we have run, we have found at least one AI account in use that leadership did not know about. That is why we start with an inventory, then build the AI integration around what people are genuinely doing.
Writing the five decisions down is the easy part. Working out which tools your people already trust, which account tiers they are on, and what your regulator expects of you specifically is the part that takes judgment. Getting that quietly wrong is worse than having no policy, because a signed document creates a record you may not be able to stand behind.
The AIStack Challenge is a 20 to 30 minute call with someone who does this for a living. You leave with a written report covering what surfaced, where your data is going, and what to do next.
