Key takeaways
✓An AI acceptable use policy should tell employees what to do, not just what to avoid. A list of prohibitions without practical guidance gets ignored.
✓The most common gaps are data classification (what information can go into an AI tool) and human review requirements (when a person must check the output before it is acted on).
✓Length is not quality. A one-page policy that staff actually read outperforms a 20-page document that sits in a shared drive.
✓Policy and training are not the same thing. Publishing a document does not change behaviour; people need to understand the reasoning behind the rules.
✓Australian organisations should ensure their policy addresses Privacy Act obligations and the data residency of any AI tools in use.
What should an AI acceptable use policy actually cover?
A good AI acceptable use policy covers six things: which tools are approved, what data can go into them, how outputs must be handled, where human oversight is required, who is accountable, and what happens when something goes wrong. Each one earns its place because each one maps to a real failure mode.
Approved and prohibited tools
Start with a clear list of which AI tools staff may use for work purposes, and which are off-limits until reviewed. This is not about being restrictive for its own sake. Without it, you end up with shadow AI: staff using personal ChatGPT accounts, free-tier tools with no data agreements, or consumer apps that train on uploaded content. A short approved list, with a process for requesting additions, closes that gap.
Prohibited use cases belong here too. Common ones include using AI to make or formally recommend employment decisions without human review, generating content that impersonates a real person, and using consumer tools to process personal information covered by the Privacy Act.
Data classification rules
This is the section most policies skip, and it's the one that matters most. Not all data carries the same risk when it enters an AI tool. The policy needs to tell staff, plainly, which data classifications can be used with which tools.
A workable approach is to tie your existing data classification tiers to specific tool categories. For example: publicly available information may be used with any approved tool; internal business data with approved enterprise tools only; personal information or commercially sensitive data only with tools that have a signed data processing agreement in place. If your organisation doesn't yet have a classification system, this is a good forcing function to build one.
The Privacy Act implications for AI tools are worth spelling out explicitly in this section. Staff generally don't think of pasting a client's name and address into a prompt as a potential data breach. The policy should make that connection visible.
Output review and accuracy standards
AI tools produce confident-sounding text that is sometimes wrong. The policy needs to state clearly that outputs are not authoritative, that staff are responsible for reviewing and verifying anything before it is used, and that specific output types (legal documents, financial calculations, medical information, external communications) require a defined level of human review before they go anywhere.
This section also covers attribution. If AI was used to draft a document, does that need to be disclosed internally? To a client? The answer will differ by context, but the policy should set a default.
The human-in-the-loop requirement
AI outputs are the starting point, not the final word. Any policy that doesn't state this clearly leaves staff uncertain about where their responsibility ends. It doesn't.
Accountability and roles
Someone needs to own this policy, and staff need to know who to call when they're unsure. Name the role responsible for maintaining the approved tool list (usually IT or the CIO's office), the person who handles escalations (a legal or compliance contact), and the team or manager who signs off on new use cases.
This section is also where you define what "responsible use" looks like for managers specifically. If a team member uses an unapproved tool and something goes wrong, the question of whether the manager knew, or should have known, will come up. Making that expectation explicit protects everyone.
Incident reporting
What should a staff member do if they suspect an AI tool has exposed data, produced a harmful output, or been used in a way that breaches this policy? Without a clear answer, the default is usually to say nothing.
Keep this section short and practical. Name the reporting channel, give a rough timeframe (report within 24 hours for potential data exposure, for example), and confirm that good-faith reports will not result in blame for the person raising them. The four AI risks every board should be asking about includes undetected misuse as a governance gap, and a reporting mechanism is the simplest way to surface it early.
What can you leave out?
Plenty. The most common failure mode in AI acceptable use policies is not a gap, it is a policy that runs to twelve pages and gets ignored by everyone except the person who wrote it.
A few things that look essential but rarely are:
A glossary of AI tools. The temptation to list every approved tool by name is understandable, but a named list is out of date before it is printed. By the time your policy reaches staff, the tool landscape has shifted. Define what counts as a "generative AI tool" by function (any tool that generates text, code, images or audio using a large language model) and maintain a separate, living approved-tools register that HR or IT can update without triggering a policy review.
Deep technical explanations. Your staff do not need to understand transformer architecture to follow a policy. If a section requires a diagram to make sense, it belongs in a training module, not a governance document. Keep the policy focused on what people must do and avoid, not on how the technology works.
Exhaustive scenario lists. Some teams try to cover every conceivable use case, writing emails, summarising contracts, generating code, creating images, and so on, with separate rules for each. This is an editing project, not a governance document. Use a small number of clear principles that staff can apply to any situation, including ones you have not anticipated.
Disciplinary detail. Your AI policy does not need to restate your existing code of conduct or employment contract provisions. A single line confirming that breaches are subject to the organisation's standard disciplinary process is enough. Repeating procedural detail creates inconsistency risk if either document is updated.
The right length is probably shorter than you think
A policy that fits on two pages and gets read is more protective than a forty-page framework that sits on the intranet. If staff cannot recall the key rules without looking them up, the policy is not doing its job.
One area worth leaving out entirely: predictions about future AI regulation. The Australian regulatory environment is moving quickly, and baking specific legislative references into a staff-facing policy means you will be rewriting it every few months. Keep regulatory compliance language in your legal and risk registers where it can be updated cleanly, and point staff to those documents if they need detail. The Privacy Act and AI changes are a good example of provisions that affect your compliance obligations but do not need to live in a frontline policy document.
How to structure the policy: a working template
The structure below gives you eight sections in the order a reader will naturally look for them. Each heading is followed by a short guidance note explaining what belongs there and what to avoid. Copy the headings, adapt the guidance to your context, and delete anything that doesn't apply to your organisation.
1. Purpose
State in plain English why the policy exists and what problem it solves. One short paragraph is enough. Avoid aspirational language about innovation or transformation; a purpose statement is not a vision statement. Something like: "This policy sets out how [Organisation] expects staff to use AI tools at work, and what approval is needed before using a new tool."
2. Scope
Name who the policy applies to: employees, contractors, secondees, volunteers. Name what it covers: AI tools accessed on company devices, company networks, or for company purposes, including free personal accounts used for work tasks. This last point matters. If a team member pastes a client brief into a free ChatGPT account from home, that is in scope. If your scope clause doesn't say so, you have a gap.
The gap most scopes miss
Free consumer AI accounts used for work tasks on personal devices are where most data leakage through AI tools happens. Name them explicitly in your scope clause.
3. Approved and unapproved tools
List the tools your organisation has assessed and approved, and the conditions attached to each. A simple table works well here.
Tool | Approved for | Conditions | Status |
|---|---|---|---|
Microsoft Copilot (M365) | General productivity tasks | Use within M365 tenant only | Approved |
ChatGPT Enterprise | Drafting, summarisation | No client data, no PII | Approved with conditions |
Free ChatGPT / Claude.ai | Personal exploration only | Not for work tasks or company data | Not approved for work use |
Any other tool | Requires IT and legal sign-off before use | Requires approval |
Add a catch-all row for tools not on the list, and make clear who approves exceptions. If you don't have that row, shadow AI fills the gap quietly.
4. Prohibited uses
This section should be specific, not a list of abstract principles. Concrete prohibitions are harder to misinterpret. Consider including:
Inputting personal information (names, contact details, health information, financial records) into unapproved tools
Generating content that will be presented as human-authored without disclosure, where disclosure is required by law or client agreement
Using AI to make, or to present as final, decisions about individuals in employment, credit, or similar high-stakes contexts without human review
Attempting to circumvent content filters or use AI tools for purposes that would breach other company policies (harassment, discrimination, fraud)
For HR and recruitment teams, this section needs to be especially careful. AI tools applied to candidate screening or performance assessment carry bias and compliance risks that warrant their own handling. The AI in HR and recruitment article covers those scenarios in detail.
5. Data handling rules
Spell out what categories of data may not be input into AI tools. At minimum:
Personal information as defined under the Privacy Act 1988
Client confidential information
Commercially sensitive internal data (pricing, strategy, M&A activity)
Information subject to legal professional privilege
Reference your existing data classification scheme if you have one. If you don't, this section is a prompt to create one, because AI tools make the absence of data classification expensive. The Privacy Act and AI obligations your organisation already holds apply fully here.
6. Human review and accountability
State that AI outputs require human review before they are acted on, shared externally, or used in a decision. Name which types of output carry higher risk and need a named reviewer: legal documents, financial calculations, medical summaries, HR decisions. Vague language like "users should review outputs" creates the impression of accountability without establishing it. Name the role, not just the requirement.
7. Reporting and breach response
Tell staff what to do if they suspect they've inadvertently shared data they shouldn't have, or if they discover a colleague using an unapproved tool. The reporting path should be short and blame-light. If staff fear punishment for honest mistakes, they won't report them. Connect this to your existing incident response process rather than creating a parallel one.
8. Review schedule and ownership
Name the team or role that owns the policy (usually a combination of IT, legal, and HR) and commit to a review date. Given how quickly AI tools and Australian regulatory obligations are moving, a twelve-month review cycle is likely too long. Six months is more realistic through 2025 and 2026. State how staff will be notified of material changes, and whether continued use of AI tools after a policy update constitutes acceptance.
How do you make the policy stick?
Publishing a policy and changing behaviour are two different things. Most AI acceptable use policies fail not because they are badly written, but because they are distributed once, acknowledged with a click, and never mentioned again. Six months later, staff are pasting customer data into free AI tools and no one has read page three.
A few things actually move the needle.
Get a real acknowledgement, not just a checkbox. A digital signature on a form proves nothing about comprehension. For roles with elevated AI access or higher-stakes decisions (finance, HR, legal, customer data), a short 15-minute conversation with a manager or team lead about what the policy means for their specific work is worth more than a tick box.
Embed it in onboarding. New starters encounter the policy at the same time they encounter every other piece of institutional knowledge, which means it rarely lands. Build a 20-minute AI onboarding module that walks through the policy with concrete examples: what counts as confidential information, which tools are approved, what to do if something goes wrong. That is easier to deliver consistently than a bespoke conversation.
The training gap is where risk lives
Most organisations have a policy. Far fewer have trained their people to apply it in real situations. The distance between those two things is where data leaks and compliance failures happen.
Train for judgment, not just rules. A policy tells people what they cannot do. Training develops the judgment to recognise a grey area and make a sensible call. For example, knowing that customer names are confidential is not the same as knowing whether it is acceptable to describe a complaint scenario to an AI without naming the individual. That distinction requires practice, not a PDF. This is especially relevant in HR and recruitment contexts, where the edge cases come thick and fast.
If you have shadow AI already circulating in your organisation, training is the moment to surface it constructively rather than punitively. People are more willing to disclose what they are actually using when the frame is "help us understand the risks" rather than "this is prohibited".
Set a review cadence. AI tools and Australian regulatory expectations are both moving fast. A policy written in mid-2024 may already be out of step with what the Privacy Act amendments now require or what your organisation has actually deployed. Build a six-monthly review into the policy itself, naming the owner (usually a combination of legal, HR, and IT). If no one owns the review date, it will not happen.
Use incidents as teaching moments. When something goes wrong, whether that is a data exposure, a bias complaint, or an employee using an unapproved tool, treat it as a live case study. Update the policy if a gap has been exposed. Debrief the relevant team. The four AI risks every board should be asking about all have a training dimension, and real incidents are the most credible way to make that dimension visible.
The honest truth is that a policy without training is a liability document, not a governance tool. It demonstrates that you wrote something down. Training is what demonstrates that people understood it.
Frequently asked questions
Does our AI acceptable use policy need to be a separate document, or can we fold it into our existing IT or data policies?
Either approach works, but a standalone document is easier to update and easier to reference in disciplinary proceedings. AI tools and the risks around them are changing quickly enough that you will likely revise this policy every six to twelve months. If it lives inside a larger IT policy, every minor revision requires you to reissue the whole document.
How specific should the policy be about which AI tools are allowed?
Name the tools your organisation has approved, and state clearly that any tool not on that list requires explicit approval before use. A vague "use AI responsibly" clause is not enforceable. That said, a named-tools list goes stale fast, so pair it with a lightweight approval process for adding new tools rather than leaving staff to interpret ambiguity. The shadow AI problem is almost always worse in organisations where the approved list is either empty or unenforceable.
What should the policy say about AI-generated content that gets published externally?
At minimum, require human review before any AI-generated content goes out under the organisation's name. Some industries will need to go further: financial advice, legal documents, and medical information all carry professional liability that an AI tool cannot absorb. For regulated sectors, it is worth getting legal advice on disclosure obligations before the policy is finalised.
How do we handle employees who were already using unapproved tools before the policy existed?
Treat the policy launch as a clean line. Publish it, train staff on it, and give a short grace period for teams to identify any tools they have been using that are not on the approved list. The goal at that point is visibility, not punishment. After the grace period, the standard disciplinary process applies. The Privacy Act implications of past unapproved use are worth reviewing with your legal team, particularly if personal data was involved.
How often should the policy be reviewed?
Review it at least annually, and also whenever a significant new tool is deployed organisation-wide, whenever a material AI-related incident occurs, or whenever relevant legislation changes. Australian AI regulation is still developing, and a policy written in 2024 may not reflect the obligations that apply in 2026. Build a named policy owner into the document from the start so that reviews actually happen.
Ready to turn your policy into practice?
A policy document on its own doesn't change behaviour. What changes behaviour is people understanding why the rules exist, what happens when they don't follow them, and how to make good judgements in the situations the policy doesn't explicitly cover.
That's the gap training fills. If your team has a policy but hasn't had a conversation about it, the policy is doing less work than you think.
Better People runs practical AI governance workshops for HR, legal, and operations teams across Australia. We cover acceptable use, data handling, verification protocols, and the judgement calls that sit between the lines of any written policy. Sessions can be delivered onsite or remotely, and they're built around your tools and your context, not a generic slide deck.
Want help turning your AI policy into something your team actually understands?
We'll talk through where your policy stands, what your team needs to know, and what a practical training session would look like for your organisation.
