An AI policy people can actually use

An employee has a customer document open in one window and an AI tool in another. They aren’t thinking about a governance framework. They want an answer to a much smaller question: can we use this tool, with this information, for the piece of work in front of us?

When the answer is buried in twenty pages, people will guess. Some will paste the document into a personal account, while more cautious colleagues may avoid a harmless use because they don’t know whom to ask. A small business can put the operating answer on one page, provided we are honest about what that page can and can’t do.

This is a starting point, not legal advice or a substitute for a risk review. Privacy, employment, health, financial, and other rules vary by jurisdiction and sector, so the final policy still needs review from whoever is responsible for legal, privacy, and security in the business.

Three answers people can remember

The first answer is use. It covers low-risk work in an approved business account with public or non-sensitive company information, perhaps brainstorming, changing the tone of text, or drafting an internal note that a person will check. This area should be broad enough that an employee doesn’t need permission every time they try something harmless.

The second is review first. The customer document belongs here if it contains confidential or personal information, as does customer-facing output, a new integration, an automated action, a decision about a person, or advice in a regulated setting. Review might come from a manager, data owner, IT lead, security adviser, or lawyer, depending on why the use is sensitive. What matters is that the route is quick and somebody can give a real answer.

Then there is do not use. That includes putting work data into an unapproved tool, placing passwords or secret keys in prompts, letting AI make covert decisions about customers or employees, publishing unchecked professional advice, impersonating somebody, or bypassing an existing security, privacy, or intellectual-property rule.

These aren’t three equally sized risk buckets. They are the answers an employee needs while the two windows are still open.

Copy this one-page policy starter

The following page is deliberately plain. Replace every bracketed item, remove examples that don’t fit, and add stricter controls where contracts, law, or the 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, while the employee using it remains responsible for the result.

Approved tools

Use only [approved tools and account types] for company work. Never 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. Never 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. Never 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” is more specific than a product name

Writing “employees may use ChatGPT” still leaves our employee guessing, because a free account, a managed workspace, and an API can come with different contracts, retention settings, controls, and ways of handling data (even features inside one product may behave differently). We’d therefore keep a tiny register beside the page with the exact product and plan, its owner, the kinds of data and work it allows, anything it connects to, the terms we’ve checked, and a review date.

It’s dull work, but dull is useful here (and it won’t take long to keep current).

The data rule needs familiar objects too. “Sensitive information” is vague, so a clinic might name intake forms and appointment notes, a wholesaler might name customer prices and supplier terms, and a software team might name secrets, production data, private code, and client material covered by a contract. Personal information stays personal after it enters a prompt. The UK Information Commissioner’s Office has AI and data-protection guidance, and Singapore’s PDPC discusses human involvement, operations, and communication, although we’d still need to check which duties matter where the business works.

Moreover, approval doesn’t mean sending every available field. If a draft needs the product and complaint reason, it probably doesn’t need a name, email, and full account history (less data is usually easier to protect).

The same plainness helps with review. “Check the output” will often mean a quick look at fluent text, and it won’t give the reviewer much to do, while “compare every number and promise with the source” gives them a job they can actually perform. Code can go through the usual tests and review (nothing special is needed there), while a customer reply can be checked for account facts, policy, promises, and tone. Furthermore, a high-stakes translation may need somebody qualified in the language and subject. A new workflow may require review of every case, while a stable and low-consequence one may later use sampling (after the complete workflow has been tested, obviously).

Decisions that materially affect a person need a harder boundary. Hiring, dismissal, pay, credit, access, health, and legal rights can’t be reduced to somebody clicking approve after an AI answer. We’d give any use there a real review of its purpose, data, legal basis where required, people affected, errors and bias, testing, what a human can see and challenge, any appeal route, monitoring, and ownership. NIST’s Generative AI Profile likewise connects controls with the organisation’s goals, risks, resources, and legal duties. Consequently, the first page can point to this process, but it can’t replace it.

Nevertheless, the page can’t secure a connected agent (no matter how firmly it is worded).

Once AI can read company data, browse a document, send a message, or change a record, a bad instruction hidden on a webpage can matter (as can an innocent action taken in the wrong place). OWASP includes prompt injection, data disclosure, and excessive agency among its current risks for LLM applications. Therefore, connected systems need narrow permissions, separate read and write actions, approved destinations, ordinary-code validation, logs, limits, tested failure behaviour, and human gates around strong actions. Choosing where AI belongs helps keep those controls in parts of the system that can enforce them.

Finally, we’ll need one person to own the page (perhaps an operations director, technology lead, or founder). They’ll keep the register current, handle incidents, and give “review first” requests a quick route, because an inbox that nobody answers is just a quiet ban. A request can be brief. It’ll say what work changes, which people and data are involved, what tool is proposed, what could go wrong (and whether it can be undone), and who checks the result after launch.

That’s enough to begin the conversation (and we can ask for more if the risk warrants it).

Tomorrow’s tool will have a new name and another good demonstration. However, the employee with two windows open will still need the same three answers, and they’ll need a real person when the answer isn’t obvious. If the first page does that, it is already doing useful work (and it gives the wider rollout a shared method too). We won’t have answered every future question, but we won’t have left each employee to invent the rule alone.