Write an AI Use Policy Employees Can Actually Follow

Constructed scenario: an employee needs to summarize a public competitor announcement by Friday. The company’s AI policy says “no AI without approval,” but the approval queue takes weeks. The work still has a deadline. Some people may use a personal account, copy a file to an unapproved tool, or stop reporting the work at all. That is an operating risk—not a measured claim about how often employees break rules. Design an approved route that can meet a real deadline.

Write the first page for a person doing a job

A useful policy begins with the approved workspace, which data can be used there, which actions the tool may take, and whom to ask when the task falls outside those limits. Put the rules in ordinary examples: public marketing material may be summarized in the approved workspace; an unredacted customer contract, payroll file, credential, or private health record needs a separately approved route. Do not rely on “use good judgment” to carry all of this.

The NIST Cybersecurity Framework 2.0 small-business guide encourages a risk approach fitted to the organization’s priorities and resources. The 2025 OWASP community guidance on sensitive information disclosure explains why a prompt instruction alone cannot guarantee that private information stays private. These are frameworks, not proof that this four-lane policy produces a particular result. Translate them into the exact workspace and data route your people use.

Four proposed lanes are clearer than one blanket rule

This is our practical policy pattern, not a universal classification standard. Your data owner must move an item to a stricter lane when a contract, law, customer promise, or business risk requires it. Source code and financial records, for example, may be barred altogether in one organization and approved in a controlled workspace in another.

• Allowed now: public information and approved internal-low-risk material in the company’s named workspace, with a person checking consequential claims before publication.
• Ask first: customer records, client-owned work, nonpublic financials, internal code, or a new connector—a link that lets the AI tool read or act in another application. Name a data owner and give a target response time.
• Human approval before action: customer messages, price promises, record changes, purchases, deletions, and access changes. Show the approver the exact recipient or record and effect.
• Do not enter: passwords, private keys, payment credentials, and information barred by a client agreement or law unless a specifically approved process handles it.

Give the policy an exception route that works

A one-page request should ask: what job are you doing, what data is needed, which system will connect, what action could occur, and who owns the result? The data owner is the person accountable for how that information may be used—often a department leader, not necessarily the IT administrator. A business owner and the right data or security reviewer can approve a limited pilot, suggest a safer input, or explain the stop. Record the decision and review date. A vague “contact security” mailbox with no response target is not a route; it is a delay.

For the Friday competitor brief in the opening example, a completed request could read: “Summarize the public October product announcement using our approved workspace; no internal files or customer records; draft only; marketing lead checks every claim before distribution.” That belongs in the allowed-now lane. If the employee later wants to connect private competitor research, it becomes a new request—not a silent extension of the old approval.

The operations or security lead should own the policy text, update it when tools or terms change, and review exceptions monthly at first. Privacy or legal review matters when a law or client agreement governs the information; requirements differ by industry and place. Interview a few employees after launch. Ask them to perform a real task with the approved tool. Watch where they wait, what file format fails, or which source they cannot reach. If the sanctioned option cannot do the work, fix the option or provide a narrower safe alternative. Keep hard stops for high-impact actions and sensitive data; remove friction that protects nothing.

Measure behavior, not acknowledgments

Set a baseline in week one: how many people use the approved workspace, how long requests take, and why exceptions are needed. For a first pilot, the policy owner might set a two-business-day response target for ordinary requests and review misses each Friday. That is a suggested service target, not an industry benchmark. Also track unsafe workarounds reported and incidents without punishing the reporter. After two weeks, make the policy standing only if the team can finish its low-risk task inside the approved route, requests meet the chosen response target, and the data owner can see what was used. Otherwise revise the route and extend the pilot. This page gives you a workable first policy. Our free ten-part AI security course teaches the surrounding identity, testing, scoring, and repair work.