What Your AI Acceptable Use Policy Should Actually Say

Most Australian businesses now have staff using AI tools at work. A smaller number have written a policy about it. Of those policies, most fall into one of two failure modes.

The first is the two-line ban: "staff must not use AI tools with company data". It is easy to write, it is universally ignored, and it makes the situation worse, because usage moves out of sight. We covered why in our post on shadow AI risk. A ban that is not enforced is not a control, it is a liability, because it establishes that the business knew about the risk and did nothing effective.

The second is the twelve-page document that reads like it was written by someone insuring against a lawsuit rather than trying to change anyone's behaviour. Staff sign it during onboarding and never look at it again.

A policy that works is short, specific, and answers the questions people actually have when they are sitting in front of a chatbot with a task to finish. This is what it should contain.

Section one: which tools are approved

Start here, because it is the question staff ask most and the one a vague policy fails to answer.

List the specific tools your business has approved, by name. Not "enterprise AI tools" but "Microsoft 365 Copilot" or "ChatGPT Team, on the business account". Name them.

For each approved tool, state what tier or account it must be used through. This distinction is the single most important technical point in the whole policy, and most staff do not know it. A consumer account and a business account for the same product can have completely different data handling. Business and enterprise tiers typically contract not to train on your inputs; free consumer tiers frequently reserve the right to. Same interface, same logo, very different risk.

State what happens if someone wants to use a tool that is not on the list. Give a real route: who to ask, and roughly how long an answer takes. If the answer is "no new tools, ever", staff will use them anyway and not tell you. A request process that gives an answer within a week is what keeps usage visible.

Section two: what data may go in, and what may not

This is the core of the policy. Be concrete. Categories, not principles.

Write down the categories of information that must never be entered into any AI tool, regardless of tier. For most Australian businesses that list includes:

• Personal information about clients, staff, or third parties, including names in combination with any other detail
• Health information, which carries heightened obligations under the Privacy Act
• Credentials, API keys, and access tokens
• Client information covered by a confidentiality agreement
• Unreleased financial results, and anything price-sensitive
• Legal advice and anything covered by privilege
• Source code, if your contracts restrict its disclosure

Then write down what is fine, because a policy that only lists prohibitions reads as a ban. Drafting a generic email, summarising a public document, rewriting your own already-public marketing copy, explaining a concept, and generating code for a non-sensitive internal script are all ordinary low-risk uses. Saying so explicitly is what makes the prohibitions credible.

Include the practical middle case, because it is the one that comes up daily: staff often want to use a real document as an example. The rule that works is to remove identifying details first. "Summarise this contract" becomes a problem; "summarise this contract with the party names, dates, and amounts replaced" usually does not. Give an example in the policy itself so people can see what you mean.

Section three: verification and accountability

The single most consequential sentence in an AI policy is the one that establishes who is responsible for the output.

The person who uses the AI output is accountable for it. Not the tool, not the vendor, not the person who approved the tool. If an AI drafts a client email with a wrong figure and a staff member sends it, that is the staff member's error in exactly the way it would be if they had typed it themselves.

State this plainly, then set the verification expectations that follow from it:

Anything factual must be checked against a source. AI tools produce confident, fluent, wrong answers, particularly for figures, dates, citations, legal or regulatory requirements, and anything about your specific business. Treat AI output as a draft from a capable new hire who has never seen your business and occasionally invents things.

Anything going to a client, a regulator, or into a contract gets human review before it leaves. No exceptions, and it should be a named human, not "the team".

Anything technical gets tested. Generated code, scripts, and formulas are reviewed and run in a safe environment before touching anything real.

Section four: disclosure

Decide your position and write it down, because staff will otherwise each decide for themselves.

There are three questions to answer. Does a client need to be told when AI was used in work delivered to them? Does an internal document need to be marked as AI-assisted? Does AI-generated material used publicly, such as marketing images or copy, need labelling?

There is no single correct answer, and it varies by industry. Some professional services contracts now require disclosure explicitly, so check your client agreements before you decide. What matters is that the position is decided centrally and applied consistently, rather than left to each staff member's judgement in the moment.

Section five: the human decisions AI does not make

Name the decisions that require a human, always, regardless of how good the AI output looks.

Typically: hiring, firing, and performance management; credit and pricing decisions about specific customers; anything that determines whether a person receives a service or benefit; safety-critical judgements; and final legal or financial sign-off.

This section matters more than it looks. The Privacy Act and general anti-discrimination law create real exposure around automated decision-making about individuals, and the direction of Australian regulation is toward more scrutiny, not less. A policy that has already drawn this line is in a far better position than one written after a complaint.

Section six: what to do when something goes wrong

Somebody will paste something they should not have. The question is whether you find out.

Make the reporting path explicit and make it blameless for genuine mistakes. State who to tell, and state that reporting promptly is the expected behaviour rather than a disciplinary event. If the only realistic outcome of admitting a mistake is punishment, you will not hear about mistakes, and you will lose the ability to respond to the ones that matter.

Then state what the business will do: assess what was disclosed, determine whether it triggers a notification obligation, and act accordingly. Under the Notifiable Data Breaches scheme, some disclosures of personal information require notification to the OAIC and to affected individuals. Knowing quickly is what makes that manageable.

What to leave out

A few things belong somewhere other than this policy.

Detailed tool instructions. How to log in to Copilot is documentation, not policy. Keep the policy about decisions and rules; put the how-to elsewhere and link to it.

Technology predictions. Anything that begins "as AI develops" will date the document and give people a reason to dismiss it as out of touch. Write for the tools you have now, and set a review date.

Aspirational language about innovation. It is not that the sentiment is wrong, it is that it dilutes a document whose value depends on being short enough to read.

Length and maintenance

Two pages. If it runs longer, the operational detail has crept in and should be moved.

Set a review date and honour it. Every six months is right for now, because the tooling and the licensing terms genuinely change that fast. The review should specifically re-check the approved tools list and the data handling terms of each, since vendors change those without announcement.

Getting it in place

The policy is the easy part. The work that makes it effective is knowing what your staff are actually using today, and making sure the approved tools are genuinely available so the compliant path is also the convenient one.

Our free IT health check includes an AI usage review: which tools are in use across your tenant, which accounts they are running under, and whether your licensing already covers a safer alternative. We also provide a policy template you can adapt. No obligation.

Learn more about our AI strategy services