AI Acceptable Use Policy: A One-Page Starter

An AI acceptable use policy should help someone decide what they may upload, which account to use and when to ask for help. A short staff-facing page can make those decisions easier to find, provided the underlying approvals and controls exist.

This is a starter template. Adapt it to your organization and have someone qualified review provisions with legal, contractual or employment consequences.

How long should an AI acceptable use policy be?

My preference is a short page that links to the detail. Test it with a realistic task: can a new joiner identify the allowed data, tool, review step and escalation route? Page length alone does not establish effectiveness or compliance.

Use your existing data-classification terms and incident process so the AI policy does not create conflicting rules.

Copy this AI acceptable use policy and edit it

Everything in square brackets is yours to fill in.

AI acceptable use, [Company] Owner: [responsible role and current contact]. Last reviewed: [date]. Questions, exceptions and incidents: [channel].

1. Approved tools and uses. Use only the tools, account types, purposes and data categories listed at [approved-use register]. Approval of a product does not authorize every feature or use. Request additions or exceptions at [link]; [role] will respond within [timeframe].

2. Permitted data. Upload only material permitted for that tool and purpose under [data policy]. Do not paste credentials or API keys. Personal, regulated or confidential information requires the specific approval recorded in [register], including any required agreement. Use placeholders or less data where possible.

3. Review outputs and actions. A responsible person must check external material, production changes and decision-support output before use, following [review standard]. Verify important facts and sources. Agents must follow [permission and approval rules] before taking actions. Human review does not remove the company’s responsibilities.

4. Ask and report promptly. Ask at [channel] before an uncovered use. Report accidental disclosure, unexpected agent actions or suspected compromise immediately through [incident process]. Preserve relevant details and follow containment instructions; do not delete evidence without checking.

Fill every bracket before adopting this template. Confirm the approved-use register and response process actually exist. What to check before uploading company data explains the data and account decisions in more detail.

Name an owner and a request path for your AI policy

NIST AI RMF calls for documented responsibilities and clear communication about AI risk. It is a voluntary framework and does not require an individual’s name in the policy. Use a responsible role and a maintained contact register, or a named person where that is clearer for a small team. A department can own the process if authority and escalation are explicit.

Publish a request route with a response target and reasons for decisions. It gives staff a way to resolve uncovered cases and gives the owner evidence about unmet needs. Personal-account activity may be outside central monitoring; that does not mean it leaves no records anywhere. Shadow AI at work covers that visibility problem, while agent security policy covers software acting on delegated authority.

When a request arrives, the questions to ask are narrow: what data would go into it, is there an agreement covering that data, and what can it reach. Vendor terms differ in ways that matter here, and they differ product by product inside a single vendor. OpenAI says it can execute a Data Processing Addendum for ChatGPT Business, ChatGPT Enterprise and the API, and states that business data is not used to train its models by default. HIPAA arrangements have a different scope. OpenAI’s current guidance describes BAA enrollment for eligible API organizations, sales-managed ChatGPT Enterprise/Edu arrangements and a separate flow for eligible ChatGPT for Clinicians users; it excludes ChatGPT Business. A BAA alone does not make a workflow compliant. Check the covered service, configuration and executed agreement before handling protected health information.

Publishing an AI use policy is not the same as it working

Choose a review window suited to the visibility and risk of your organization. A short initial review can identify gaps, but it is not a compliance audit.

Pick a window and compare the document to reality. Which tools are people using, which of those are on your approved list, and what has been requested. A month with no requests is not evidence of compliance, and it is not evidence of a broken process either. Possible explanations include: there was no demand, or no one knows the path exists, or no one expects a yes. Where the tools in use do not match the list, my own first suspicion is the list rather than the people, because approved lists go stale without anyone noticing and the work does not wait for them.

Training belongs in the same review cycle. NIST AI RMF calls for personnel and partners to receive training suited to their AI-risk duties and policies. For a small team, discussing realistic examples together is a useful start. Add role-specific training and check understanding where the work demands it.

If you want the framework scaffolding behind all of this, ISO/IEC 42001 is the international standard for AI management systems and is a reasonable outline to borrow from. Certification against it is voluntary, and for a team writing its first page, the outline is the useful part rather than the badge.

I do not have one of these, which is an awkward admission to make underneath a template. No employer sets rules for me and there is no one to hand a document to. What I have instead is a handful of habits I described while preparing these posts: I try to minimize retained chats, numbers get rounded or swapped before anything is pasted, and I instruct agents to ask before changing a file. Each of those arrived on its own, after something specific made me think about it. Assembling this page is the first time I have seen them sitting next to each other, and what struck me is that I could not have handed them to anyone in that state. This post’s argument turns out to point at me too.

Should you ban AI tools instead of writing a policy?

A restriction can be appropriate for a particular task or data type. Define its scope, enforce it where feasible, and provide an escalation path. Offer an approved alternative when one meets the requirements; some work may need to proceed without AI.

Do not assume a ban eliminates demand or inevitably drives everyone to personal accounts. Check usage and requests, explain the reason for the restriction, and revisit it as the tools and requirements change.

FAQ

Do we have to disclose when something was written with AI?

That depends on the audience and any commitments you have made, so decide it deliberately rather than by default. For example, your policy could distinguish external publication from internal drafting, subject to the requirements that apply. Where a client contract, a publisher, an academic body or a regulator has its own disclosure requirement, that requirement wins and your policy should point at it rather than restate it.

Can we just use an AI tool to write the AI policy?

Yes, for a first draft. The limitation is that the hard parts of this document are not the wording, they are the decisions: which tools you will approve in practice, what your real data categories are, and who owns it. A fluent draft can still omit the decisions your team needs. Use it to draft, then replace every generic clause with a specific one.

Does GDPR change what has to be in the policy?

Where GDPR applies, identify a lawful basis and the parties’ actual roles before processing personal data. Processing on a controller’s behalf needs the Article 28 arrangement, commonly a data-processing contract. A vendor may instead act as a controller for some processing, so a DPA is not a universal checkbox or a complete compliance assessment. Have the responsible privacy reviewer assess the use and reflect the approved scope in the policy.

Is one page really enough?

One page can be a useful staff-facing summary. It is sufficient only if people can find the detail, approvals and controls their work requires. Keep supporting rules separately where needed and test the summary against real tasks; neither brevity nor length guarantees that a policy works.

Sources

This page is a starting point, not legal advice. NIST AI RMF and ISO/IEC 42001 are voluntary frameworks rather than regulation. Vendor terms cited are OpenAI’s published terms for its own business products checked on October 8, 2026 and are used as an example of what to check, not as an industry norm. The template and implementation suggestions are editorial guidance, not evidence that a particular policy meets every obligation.

Written by Grace

I test AI tools and agents in my own workflow, and write down what I find, including the settings that surprised me. About Grace and how posts are verified