An AI policy people can actually use

A useful small-business AI policy can fit on one page. It should name the tools people may use, the information they may put into them, the outputs a person must check, the decisions AI must not make, the route for reporting mistakes, and the owner who keeps the rules current. Everything else can sit behind that page.

The document has one job: let an employee answer a practical question at the moment of work. “Can I use this tool for this information and this outcome?”

This article provides a starting point, not legal advice. Privacy, employment, health, financial and other sector rules differ by jurisdiction. Have the final policy reviewed by the people responsible for legal, privacy and security in your business.

Begin with three operating zones

Most staff do not need a taxonomy of AI risks. They need boundaries they can remember.

Use

Low-risk work in an approved business account, using public or non-sensitive company information. Examples may include brainstorming, changing the tone of text, summarizing material already cleared for that tool, or drafting an internal document that a person will review.

Review first

Work involving confidential data, personal information, customer-facing output, automated actions, new integrations, decisions about people, or advice in a regulated context. The review may involve a manager, the data owner, IT, security, legal counsel, or a combination appropriate to the risk.

Do not use

Unapproved tools for work data; passwords, secret keys or authentication codes in prompts; covert decisions about employees or customers; unreviewed professional advice; impersonation or deception; and attempts to bypass the company’s security, privacy or intellectual-property rules.

These zones are deliberately unequal. “Use” should be broad enough that employees do not need permission for harmless work. “Review first” should create a fast route to a responsible decision, not a place where ideas disappear.

Copy this one-page policy starter

Replace every bracketed item. Remove examples that do not fit your business. Add stricter controls where your law, contracts or sector require them.

[Company] employee AI use policy

Purpose

We use AI to improve work while protecting customers, colleagues and company information. AI can assist with work; the employee using it remains responsible for the result.

Approved tools

Use only [approved tools and account types] for company work. Do not connect a new AI service to company systems or install an AI browser extension without [owner] approval. The current list is kept at [location].

Information

Public and [approved internal] information may be used in approved tools. Do not enter personal, confidential, client, financial, health, legal, security or credential information unless the specific tool and use case have written approval from [owner]. Minimize the information provided.

Review and responsibility

Check AI output against the original evidence before using it. Verify facts, calculations, citations and code. A named person must approve external communication, material business decisions and changes to company records or systems.

High-impact uses

AI must not make final decisions about hiring, dismissal, pay, credit, eligibility, health, legal rights, safety or other significant outcomes. Any AI assistance in these areas requires prior review by [owner and relevant adviser] and meaningful human decision-making.

Customers and disclosure

Follow [company rule] when AI materially creates customer-facing content or interacts directly with a customer. Do not present invented people, testimonials, evidence or AI output as verified fact.

Incidents and questions

Stop and report accidental data entry, harmful or incorrect output, unexpected tool actions, or a suspected security issue to [channel/person] promptly. Good-faith questions and reports are encouraged.

Owner and review date

[Role] owns this policy, the approved-tool register and use-case reviews. Last reviewed: [date]. Next review: [date or trigger].

“Approved” must refer to a tool and an account type

Writing “employees may use ChatGPT” is incomplete. A free consumer account, a managed business workspace and an API deployment can have different contracts, administrator controls, retention settings and data handling. Features within the same product can also send data to different services.

Keep a small register beside the policy:

This is dull administrative work. It is also what lets a policy survive the arrival of the next popular tool.

Data rules need examples from your business

“Do not share sensitive information” leaves each employee to define sensitive. Name the objects they recognize.

For a clinic, that may include intake forms, diagnoses, appointment notes and identifiers. For a wholesaler, it may include customer pricing, supplier terms and unpublished sales data. For a software team, it includes secrets, production data, private repositories and client code governed by contract.

Personal information remains personal information when pasted into a prompt. The UK Information Commissioner’s Office provides AI and data-protection guidance and a risk toolkit for organizations using information in AI systems. Singapore’s PDPC similarly frames AI governance around internal structures, human involvement, operations and stakeholder communication. The applicable obligation depends on where and how your business operates.

Data minimization is useful even after a tool is approved. If a drafting task needs the product type and complaint reason, it may not need the customer’s name, email and full account history. Remove what the task does not require.

Human review should name the thing being checked

“All AI output must be reviewed” sounds safe and quickly becomes ceremonial. People glance at a fluent answer and click approve.

Define review around the failure:

• A summary is checked against the source for missing commitments and changed numbers.
• Extracted fields are checked when confidence is low or required evidence conflicts.
• Code is tested, reviewed and scanned under the same rules as human-written code.
• A customer reply is checked for account facts, policy, promises and tone.
• A translation is reviewed by a qualified person when an error has legal, safety or reputational consequences.

Review can change as evidence accumulates. A new workflow may require every output to be approved. A stable, low-consequence workflow may later use sampling and exception review. The accountable person remains clear either way.

That change should follow evidence from evaluating the complete AI workflow, not confidence created by a few good-looking outputs.

Put decisions about people behind a harder boundary

AI can help structure evidence or remove administrative work without becoming the decision maker. This separation is particularly important in hiring, performance, access, credit, health and other outcomes that materially affect a person.

At minimum, require a use-case review that covers:

• purpose and lawful basis where personal information is involved;
• data sources and people affected;
• error, bias and accessibility risks;
• what the human decision maker sees and can challenge;
• testing on the relevant population and edge cases;
• explanation and appeal routes where applicable; and
• ongoing monitoring and an owner.

NIST’s Generative AI Profile takes the same risk-based approach. It asks organizations to align controls with their goals, risk tolerance, resources and legal requirements across governance, mapping, measurement and management.

A one-page employee policy is the front door to this process. It is not the process itself.

Connected AI needs engineering controls, not better wording

The risk changes when an AI system can read company data, browse untrusted material, send messages or modify records. A malicious instruction can be hidden in a webpage or document. A model can expose information it was allowed to retrieve. An agent can take the wrong action with perfectly good intentions.

OWASP’s current LLM application risks include prompt injection, sensitive information disclosure and excessive agency. An employee policy can tell people not to paste secrets. It cannot secure a customer-facing agent.

Connected systems need technical safeguards such as scoped permissions, separation of read and write actions, destination allowlists, approval gates, validation in ordinary code, logs, limits, and tested failure behavior. The stronger the action, the less the system should rely on a prompt to police itself.

Those controls depend on the architecture. Choosing where AI belongs in each step makes it easier to keep calculations, permissions, and final actions in deterministic code.

Give the policy an owner and a fast exception path

Nobody reads a policy whose tool list is six months out of date. Name one role that can update the approved register, coordinate reviews and close the loop after an incident. The role does not have to be a full-time AI officer. In a small business it may be an operations director, technology lead or founder, supported by advisers when the use is consequential.

Also name the path for a new idea. A useful request can be short:

1. What work will change?
2. Which people and information are involved?
3. What tool or connection is proposed?
4. What can go wrong, and can it be undone?
5. Who checks the result and owns it after launch?

This turns governance into a way to make a decision. A blanket ban can push experimentation into personal accounts. With no policy, careful employees have to guess while careless ones remain unconstrained.

The same principle applies to adoption: a rollout needs a shared method, not merely tool access.

When a new tool appears tomorrow, an employee should know what is allowed, what needs review and which person can give a useful answer. If the first page of the policy does that, it is doing real work.