An AI policy people will actually follow

A blanket ban can be difficult to enforce, and a vague statement of principles may leave people unsure what to do. Neither outcome is inevitable; pair clear rules with access controls, practical guidance and a route for questions.

A usable policy is short, concrete, and answers four questions.

Which tools, and on which account

Name them. Not “approved AI tools” — the actual products, and critically, which account to use.

Data handling can differ by product, account, plan and configuration. Name the approved combination and explain how to obtain access instead of assuming the product name alone is enough.

Say how to get access, and say what to do about a tool that is not on the list — because there will be one next month, and “ask first” only works if people know who to ask.

What must never go in

The section people actually read, so make it specific to your organization.

Use categories people can recognize: specified customer records, legal matters, credentials, unreleased financials or patient information. Make the restrictions fit the organization’s actual obligations and approved uses.

Give an approved route for sensitive work, which may involve an authorized environment, suitable minimization or review by a named person. Redaction can miss identifying details, and self-hosted execution can still send content to external services; neither is an automatic permission to upload.

What has to be checked

Include verification rules alongside data and access rules. They address different risks, and none should be assumed to cover the others.

Three useful checks are: verify consequential claims against appropriate evidence, preserve source links for information people will act on, and put generated code through normal review. Check supplied material too when its accuracy or interpretation is uncertain; add requirements for the actual use case.

These habits make evidence easier to inspect, but they do not replace required approvals or prevent every false claim. State which uses need additional review before the output is acted on.

Who decides the edge cases

Name a person. Not a committee, not an inbox.

Expect edge cases and give people a clear escalation path, with a backup when the owner is unavailable. Do not require them to infer an exception from an ambiguous rule.

Set a practical response expectation and review whether it is met. A reachable owner helps people resolve uncertainty, alongside training and enforceable controls.

What to leave out

Principles without operational guidance. Keep values where they help interpret the policy, but connect them to concrete permitted and prohibited actions.

Explanations of how the technology works. Worth writing; belongs elsewhere. A policy is a decision document.

Aspirational statements with no operational meaning. Replace vague promises with clear requirements, owners and checks. Do not drop a mandatory rule because enforcement is incomplete: document the gap, assign an implementation or remediation plan, and follow the responsible approval process for any exception.

Write it for the moment it gets read

Make a short reference useful at the moment somebody chooses a tool, shares data or acts on output. Those are several decision points, not just the moment before pasting a prompt.

Aim for a skimmable staff-facing summary with links to the detailed policy and procedures. Do not omit necessary requirements solely to force the whole policy onto one page.

This also argues for putting it where the work happens — pinned in the relevant channel, linked from the tool’s access page — rather than in a document management system nobody opens.

Give it an owner and a review date

Everything in this area is moving. Tools change their retention policies, new surfaces appear, and something you banned in March may be fine now on a different plan.

A policy can become stale when tools, contracts, threats or work change. Assign an owner and make those changes triggers for review.

Use periodic review alongside event-triggered updates. The appropriate cadence and effort depend on the deployment; a quarterly twenty-minute check is not a universal guarantee.

A skeleton you can fill in

Use these six sections as a short reference, with links to fuller requirements when needed. Length should follow the decisions and obligations the policy must cover.

Approved tools and accounts — the products by name, which account to use, how to get access, and who to ask about anything not listed.

Never paste this — your categories, in your vocabulary, with the workaround beside each one.

Check before you rely on it — the three habits: specifics are claims, anything reaching a document carries a source, code goes through normal review.

Tell somebody if — the short list of situations worth flagging, and who to flag them to. Make this easy and blameless or it will never be used.

Who decides — a name, and how quickly they respond.

Owner and review date — both, on the page.

What changes as agents get more capable

One thing worth anticipating rather than retrofitting.

Most policies were written for a person typing into a chat window. Increasingly the relevant question is not what somebody pastes in, but what a tool is permitted to do on its own — act on a schedule, respond to a message in a channel, open and merge changes, call internal systems.

Coordinate the staff policy with technical access-control rules for unattended actions. Link the two so readers know both what data they may share and what authority tools may exercise; neither risk is always the smaller one.

The test that matters

Ask people to find the rule, apply it to a realistic example and identify who can resolve an exception. Correct answers are useful evidence of understanding, but do not prove that every deployment complies.

The objective is understandable, enforceable use with visible accountability. Check actual behavior and revise the policy when the evidence shows a gap.

Technical review, October 10, 2026. References: OpenAI: API data controls; Cursor: Self-Hosted Machines; NIST: AI Risk Management Framework.

Try this

Ask three colleagues to find and apply the policy to a realistic scenario, then locate the escalation path. Use difficulties to improve guidance and training; this small check does not establish compliance or explain every incident.