Writing an internal AI use policy that fits on two pages

5 days ago
3 min read

Updated: 5 days ago

Introduction

In almost every business, staff are already using these tools. Some are using approved products for approved purposes; others are pasting client material into a free consumer account because it saves them twenty minutes. The absence of a policy has not prevented use; it has delegated every judgement to whoever is at the keyboard.

A policy fixes that cheaply. It does not need to be long or restrictive, and the good ones are two pages that enable rather than prohibit: here is what you may use, here is what must never go into these tools, here is what to check before anything leaves the business. Written that way it gets read and followed, which is the only measure that matters.

1. Writing an internal AI use policy should enable rather than prohibit

The tone determines compliance.

A policy that says no to everything is ignored and drives use onto personal accounts. One that says which tools are approved for which purposes gives people a route that does not require concealment.

2. List what may never be uploaded

The most important section.

Client confidential material, personal data, employee information, pricing and margin, anything covered by a confidentiality agreement, and credentials. Specific categories rather than a general instruction to use judgement.

3. Name the approved tools and accounts

Practical and often forgotten.

Which products, on which business accounts, for which purposes. Most inappropriate use is people solving a real problem without knowing what is already available and paid for.

4. Set the verification requirement

The quality clause.

What must be checked before output is used: figures, names, dates, references, and anything going to a customer. This is the part that prevents the errors, and it belongs in the policy rather than in training alone.

5. State where a human decision is required

The boundary.

Decisions about people, safety statements, regulated advice, contractual commitments and anything with legal effect. These should be listed explicitly rather than left to be inferred.

6. Cover disclosure to customers

Increasingly relevant.

Whether and when customers are told, and who decides. Some clients have their own policies restricting whether their material may be processed this way, and staff need to know that this question exists.

7. Say what happens when something goes wrong

The clause that makes reporting safe.

That errors should be reported immediately, to whom, and that reporting one is expected rather than penalised. Without this the policy reads as a list of ways to be in trouble.

8. Keep it to two pages and write it plainly

Length is the enemy of a read policy.

Two pages, in ordinary language, that a new employee can absorb in ten minutes. A twelve-page document adapted from a template will be acknowledged and not read, which achieves nothing.

9. Review it every six months

The field is moving.

New tools, changed vendor terms, new legal requirements and new uses within the business. A policy written once and left is out of date within a year and its authority decays with it.

The legal requirements that sit behind such a policy — data protection, confidentiality, employment, sector-specific regulation, and emerging rules on the use of these systems — vary by jurisdiction and are changing. Where your business is regulated or handles sensitive data, the policy should be reviewed by someone competent in that area.

Conclusion

Write two pages that enable a safe route, because people are already using these tools without one.

List explicitly what may never be uploaded, name the approved products and business accounts for each purpose, set out what must be verified before output is used, state where a human decision is required, cover whether and when customers are told, make clear that errors must be reported and that reporting is expected, keep it in plain language and short enough to be read, and review it every six months.