How to Write an AI Acceptable Use Policy

An AI acceptable use policy tells your staff which AI tools they may use, what data they may put into them, who checks the output before it reaches a client, and what happens when something goes wrong. For an Australian SME it should be three or four pages and readable in five minutes. Anything longer gets skimmed, and a policy nobody has read protects nobody.

Key facts

• The policy is the staff-facing part of your AI governance. It sits alongside an AI register and technical controls, and on its own it is documentation rather than protection.
• Approved tools should be named. "Use AI responsibly" is not a rule anyone can follow or breach.
• The prohibited data list is the heart of it: client personal information, health records, identity documents, payroll, credentials, anything under an NDA, and anything you would not email to a stranger.
• Accountability for output stays with the person who sends it. A policy that implies the tool is responsible fails the first time a client reads something wrong.
• Disclosure rules matter where clients, candidates or patients are involved, and some professional bodies and client contracts already require it.
• A ban is not a policy. Blanket bans push usage onto personal devices and personal accounts, where you have no visibility at all.

What goes in the policy?

1. Purpose and scope. Two sentences. Who it applies to, including contractors, and what counts as an AI tool, including AI features inside software you already use.
2. Approved tools. Named, with the account type. "Microsoft 365 Copilot on your work account" is a rule. "A reputable AI assistant" is not.
3. What you may not put in. The specific list for your business. Name the systems the data lives in so people recognise it.
4. Checking the output. Who reviews AI-assisted work before it goes to a client, and the standing rule that the sender owns what they send, including facts, figures, citations and code.
5. Disclosure. When you tell a client, a candidate or a third party that AI was involved, and in what form.
6. Getting a new tool approved. Who to ask and how long it takes. If there is no path to yes, people stop asking and start using it anyway.
7. What happens if the rules are broken. Proportionate, and linked to the existing disciplinary framework rather than inventing a new one.
8. Owner and review date. A name and a date.

What should the prohibited list actually say?

Generic wording fails here. "Do not enter confidential information" means nothing to someone holding a spreadsheet they consider routine. Name it: client bank details, tax file numbers, Medicare numbers, identity documents, health information, payroll data, passwords and keys, anything covered by an NDA, unreleased financials, and the client database.

Then add the test that covers the rest: if you would not be comfortable with the client seeing this in a stranger's hands, it does not go in. People apply that test correctly far more often than they apply a definition.

How do you make it stick?

Three things, and none of them is a longer document.

Put a control behind it. Tenant policy on which AI services are reachable, data loss prevention rules on what can be uploaded or pasted, and logging. The policy states the expectation, the control enforces it, and only the pair is a managed risk.

Tell people why. A short all-staff message explaining the risk, what is approved, and who to ask for something new, converts the policy from a restriction into a service. Staff adopt AI for sound reasons, usually time pressure, and a policy that ignores that gets routed around.

Give it to new starters. It belongs in the induction pack beside the acceptable use and privacy policies, not in a folder nobody opens.

One honest caveat: policies written to restrict rather than to enable tend to lose. If the approved list is one tool nobody likes and the approval path takes six weeks, you will have the same shadow AI problem you started with, plus a document saying it is not allowed.

Frequently asked questions

Can we use a free AI policy template?

As a starting structure, yes. The parts that matter cannot be templated: the named tools, the prohibited data specific to your business, and the approval path. Most templates online are also drafted against US regulation and reference laws that do not apply here, so strip that out rather than leaving it in to look thorough.

Should we ban AI entirely?

We would advise against it. A ban does not stop usage, it moves it to personal phones and personal accounts, which removes every control you have and every record you would need after an incident. Approving a small number of tools and controlling them gives a far better outcome.

Does the policy need to cover AI features in software we already use?

Yes, and this is the gap most policies have. AI summarisation, drafting and meeting transcription keep arriving inside existing products, often enabled by default. Scope the policy to AI functionality rather than to a list of standalone websites.

Who should sign off the policy?

A director or the business owner. It covers staff conduct and client data, so it needs business authority behind it, not just IT sign-off.

How often should it be reviewed?

Annually at minimum, plus whenever you approve a new tool, change what data you allow, or something goes wrong. The approved tool list usually needs attention more often than the rest of the document, which is a good argument for keeping that list as an appendix you can update on its own.

If you want the policy drafted against the tools your staff are actually using rather than a generic list, that starts with finding out what those are, which we can do in a few days.

About the author

Brett Muscio is the Director of 4iT Support Pty Ltd, a managed services provider based in Castle Hill, NSW. He works with SME clients across Sydney, Melbourne, and Brisbane on AI governance, security awareness, Privacy Act obligations and Microsoft 365 security, with on-site support across the Sydney metro area and remote delivery nationally. Connect on LinkedIn.