AI usage policy
What should an AI usage policy actually control?
A useful AI policy is a record of decisions the organisation has made: which services are approved, what information may go into them, who reviews what comes out, and who says yes to the next tool. A template can suggest those decisions. It cannot make them for you.
That is why most downloadable AI policies change nothing. They arrive with the decisions left blank, and the blanks are the entire point.
General information about Australian obligations, not legal advice.
Do we need an AI usage policy?
If staff are using AI for work, yes, and you probably need it more than you need most of your other policies. Australian guidance treats an AI policy as a whole-of-organisation practice: the National AI Centre's first essential practice is to assign a senior leader as AI governance owner and create an AI policy setting out how the organisation will use AI responsibly.
No Australian law requires a specific AI policy document. What the law requires is that you handle personal information properly, that you take reasonable steps to protect it, and that you do not mislead people. A policy is the ordinary way an organisation makes those things happen consistently across people who are not thinking about privacy law while they work.
The corollary is that a policy nobody has read is worth roughly nothing to any of those obligations, which is why the second half of this page is about what happens after it is written.
The decisions a policy needs to embody
Grouped by what they actually govern. In a smaller business several of these are one sentence each, and that is fine. What matters is that a real decision sits behind the sentence.
Which services, on whose account
- The approved list, by name and by tier where it matters.
- Whether personal subscriptions may be used for work at all.
- Services that are specifically not approved, and why.
- AI features inside software you already licence.
- Who approves a new tool, and what they assess first.
- How the list gets updated between policy reviews.
What may go in, and what may not
- Personal information about customers, patients or staff.
- Sensitive information, including health and biometric.
- Client or matter material held in confidence.
- Commercially sensitive and unreleased information.
- Intellectual property, source code and proprietary material.
- Credentials, API keys and access tokens.
- What de-identification is expected to look like in practice.
What must be checked before it is used
- Which outputs require human verification, and by whom.
- Uses that are not permitted without explicit approval.
- Decisions affecting a person's rights, employment or care.
- Who is accountable for output once it is sent or published.
- When AI involvement should be disclosed to a client or customer.
- What to do when output is found to be wrong.
Who does what
- The named AI governance owner.
- Who assesses providers and records the decision.
- What managers are responsible for in their teams.
- What every staff member is responsible for.
- Training expected before a tool is used for real work.
Access and departures
- How AI accounts are provisioned and paid for.
- Multi-factor authentication on every AI account.
- Connected integrations and what they may reach.
- What happens to accounts, chat history and connections when someone leaves.
- Periodic review of who still has access.
When something goes wrong or has to differ
- How to report an AI-related incident, and to whom.
- What counts as an incident, including data put somewhere it should not have been.
- How an exception is requested, approved and time-limited.
- How this connects to your data breach assessment process.
- The review cadence for the policy and the approved list.
The three that decide whether the rest is useful
Which services are approved. What information may go into them. Who approves the next one. A policy that answers those three specifically is more use than a twenty-page document that covers everything at the level of "staff should exercise appropriate care". Vagueness in an AI policy is not caution. It leaves each staff member to make a decision the organisation was supposed to make.
One policy, or rules split across two?
There is a real design choice here, and getting it wrong is why some AI policies are ignored. Oversight material and day-to-day rules have different audiences and different lifespans.
Oversight: the AI governance layer
- Who owns AI governance and what that involves.
- How a provider is assessed before approval.
- How risks are screened and recorded.
- How incidents are investigated.
- The review cycle.
Read by owners, directors and managers. Changes when the business changes.
Behaviour: what staff actually need
- These tools are approved. This one is not.
- Do not put these categories of information in.
- Check this before you send or publish it.
- Tell this person if something goes wrong.
- Ask before you sign up to anything new.
Read by everyone. Often better placed in an acceptable use policy staff already acknowledge, so it is not competing for attention with a governance document.
Either structure works. What does not work is putting the staff-facing rules inside a governance document that only management ever opens, then treating the existence of the document as though the rules had been communicated.
A policy in a folder is not the end of the control
Writing the document is the first of eight steps and the only one AI can do for you. The other seven are what turn a policy into something the organisation can point to.
-
Approve it
Someone with authority adopts the policy on a date. Without that, it is a draft that happens to be finished, and there is no answer to the question of who decided this.
-
Assign the ownership in it
The named AI governance owner should know they own it. So should whoever assesses providers and whoever receives incident reports. Names in a document that the named people have not seen are not accountability.
-
Communicate it
Issue it to the people it binds, in a way that reaches contractors and part-timers, not just the staff on the main email list.
-
Train on it
The rules that matter most are counter-intuitive: that a personal account is still work use, that a summary can contain personal information, that a confident answer can be fabricated. People need those explained, not just published.
-
Record acknowledgement
A dated list of who has read and accepted it. This is the single record that most often does not exist, and the one most often asked for.
-
Make the approved list real
Publish it somewhere people will look, and make sure the tools on it are the tools people actually have access to. A list that omits what everyone uses trains people to ignore the policy.
-
Monitor and handle exceptions
Someone will use something unapproved. Whether that surfaces or hides depends on how the first case is handled. Australian guidance is explicit that people need to feel safe disclosing their AI use, and that unapproved use is often a signal of unmet need or time pressure rather than defiance.
-
Review it, and record that you did
Set a cadence and hold to it, plus a trigger for material change: a new tool, an incident, a change to a provider's terms. The review record is what turns a policy from a document with a date on it into a maintained control.
Each of those leaves a different record
Approval, assignment, issue, training completion, acknowledgement, the approved list itself, exception decisions and review dates. Together they are the evidence that the policy was a control rather than a file. Separately, each of them is a thing an organisation can either produce on request or cannot. What to keep, in detail.
What if staff are already using AI we never approved?
Assume they are, and find out before you write the policy rather than after. The National AI Centre's guidance describes unapproved use as often a signal of unmet need, time pressure or curiosity, and says people need to feel safe disclosing it. A policy written without knowing what is actually in use will either prohibit something the business depends on or omit the thing creating the exposure.
A short, non-punitive survey is usually enough: which AI tools are you using for work, on which account, and for what. The answers are frequently longer than management expects, and the useful ones are rarely the headline products. Transcription tools, browser extensions, AI features inside a CRM, a design tool with generative features, an assistant somebody enabled on a trial that never ended.
There is a security dimension to the same exercise. Until you have that list you cannot know what information has left the organisation, which makes an assessment after an incident considerably harder. The security side of unapproved AI use.
A policy that exists and does not work
A twelve-person law firm
The firm adopted an AI policy last year. It prohibits entering confidential client information into AI tools. It is well written and covers the right ground. Staff use three different generative AI accounts between them, two of them personal.
What the firm has
- A written AI policy with sensible rules
- A partner who read it carefully
- An answer for the professional indemnity renewal
- A genuine intention to do this properly
What is missing
- No approved tool list, so "approved tools only" means nothing
- No acknowledgement record from any staff member
- No training, so nobody was told a summary can carry client detail
- No provider assessment for any of the three accounts
- No review since adoption, and no owner for one
The prohibition is the part everyone quotes and the part that does the least work. What would change behaviour is a named approved account that staff can actually use, a list of what may go into it, and one training session explaining why a case summary is client information. None of that is in the document, because the document was the whole project.
How this works in Cleverer
The Policy Builder includes an AI Governance Policy. It is built around the decisions above rather than around a template, which means it asks the questions and then writes the document that follows from the answers.
The questions that set the content
Who the policy owner and AI risk owner are, whether AI tools are in use and how, which tools are approved, whether personal or sensitive data is entered, whether output is reviewed before use, and the review frequency.
What the honest answer produces
Where the answer is that staff use AI independently and it is not formally managed, or that data entry is not monitored, the generated policy states that as a disclosed position with the remediation required, rather than writing it up as a working control.
The eight steps, tracked
Adoption with an approver and a date, an audience, acknowledgement records, an assigned review owner and a review date that appears in the review calendar when it falls due.
What it does not do
It does not detect which AI tools your staff are using, block anything, or connect to your systems. The approved-tool list is what your organisation decides it is. Cleverer holds the decision, the ownership, the acknowledgement and the review cycle around it, and puts the AI providers into the same supplier register as everyone else you disclose information to.
The policy is one part of the position
The Readiness Check looks at policies, responsibilities, training, registers and evidence together, which is usually where the actual gap turns out to be.
Questions about AI usage policies
Is an AI usage policy legally required in Australia?
No Australian law requires a specific AI policy document. Australian government guidance recommends one as the first essential practice of AI governance, and where the Privacy Act applies, a policy is a normal way of taking the reasonable steps APP 11 asks for. The absence of a legal mandate is not much of an argument against having one.
Does using Microsoft Copilot remove the need for an AI policy?
No. A business-tier product with assessed terms removes some of the risk around what the provider does with your data. It does not decide which staff may use it, what information they may put in, which outputs need checking, or what happens when someone uses something else instead. Those are organisational decisions and they are what the policy exists to record.
Can we just download an AI policy template?
A template is a reasonable starting structure and the National AI Centre publishes one. What it cannot supply is the approved tool list, the information categories that matter in your business, the named owner, or the verification rules for your work. A template adopted without filling those in produces a document that reads well and governs nothing.
Should the policy ban AI outright?
Rarely, and it usually does not work. A blanket ban moves the usage onto personal accounts and out of sight, which is worse than the position you started from, because you lose the visibility as well as the control. Australian guidance takes the same view: give people a safe, approved way to do the thing they are going to do anyway.
Do staff need training before using generative AI at work?
Training is the difference between a rule existing and a rule being followed. The specific things people get wrong are not obvious: that a personal subscription used for a work task is still work use, that a case or file summary contains personal information, that a confident answer can be entirely fabricated, and that an uploaded document exposes far more than a typed question. None of that is intuitive, and a policy on an intranet does not teach it.
How often should an AI usage policy be reviewed?
At least annually, plus whenever something material changes: a new tool goes into use, a provider changes its terms or data handling, an incident occurs, or the business starts using AI in a decision that affects people. The approved tool list usually needs updating more often than the policy body, so it is worth allowing the list to be changed by the owner between full reviews.
