Writing an AI Usage Policy for Your Australian Business

No Australian law names an "AI usage policy" as a mandatory document, and there is no standalone AI Act. But that framing misses the point. The Privacy Act 1988, the Australian Consumer Law and sector rules such as APRA CPS 234 impose obligations that staff AI use can breach, and several require you to take reasonable steps to protect information. A written policy, training and acknowledgment are the ordinary evidence that you took those steps. Without one, you are relying on individual judgement to meet obligations that sit with the organisation. Some organisations face a harder requirement: government panels, insurers and enterprise customers increasingly make an AI policy a contractual or tender precondition, which makes it mandatory in practice long before it is mandatory in legislation.

Draw the line at data, not at task. Prohibiting "using ChatGPT for client work" fails because staff cannot tell where the boundary sits, so they guess. Prohibiting "entering personal information, client-confidential material, credentials or unreleased financials into any tool not on the approved register" is a rule someone can apply mid-sentence. Under that framing, generally allowable uses include drafting internal content from non-sensitive material, rewriting text the employee already wrote, brainstorming, and explaining a public standard. Generally prohibited uses include anything involving client records, health information, employee data, credentials, or material covered by a confidentiality clause. The uncomfortable truth is that the prohibited list is exactly what staff most want AI for, which is why a sanctioned private alternative does more for compliance than a longer prohibition list ever will.

Entering personal information into a third-party AI tool is a use and, in most configurations, a disclosure of that information, which brings it within the Australian Privacy Principles. Several become immediately relevant. APP 6 limits use and disclosure to the primary purpose it was collected for, and "we fed it to a chatbot to summarise" is rarely that purpose. APP 8 governs cross-border disclosure and generally leaves you accountable for what an overseas recipient does with the data. APP 11 requires reasonable steps to protect personal information from misuse and unauthorised disclosure. APP 1 requires your privacy policy to accurately describe how you handle information, so an undisclosed AI workflow can make your published policy wrong. The OAIC has published guidance on using commercially available AI products, and its consistent theme is that AI creates no exception to any of this.

Review formally every twelve months at minimum, and additionally on defined triggers rather than only on the calendar. The calendar review is the floor. The triggers matter more, because this area moves faster than an annual cycle: a material change in Australian privacy or AI regulation, the introduction of a new AI capability into software your organisation already licences, a new client contract with AI terms, a near-miss or actual incident, or a request to add a tool to the approved register. The trigger that catches most organisations out is the second one. Vendors ship AI features into existing products, so a tool your policy approved last year on the basis of how it then behaved can quietly acquire a generative feature that changes where your data goes, without you making any procurement decision at all.

Treat the contract as the controlling rule for that engagement, and make the restriction visible to the people doing the work, because a clause that lives only in a signed PDF in the legal folder will not change what a delivery team does on a Thursday afternoon. Practically, this means three things. Check for AI clauses at contract review rather than discovering them at delivery, since terms range from full prohibition to consent, disclosure or approved-tool requirements. Maintain a register of clients and matters with AI restrictions, and flag those matters in whatever system the team actually works in. Define an escalation path for conflicts: a blanket client prohibition may rest on assumptions about public chatbots that a sovereign, non-training deployment does not share, and that is a conversation to have rather than a rule to quietly work around.

It changes the policy from a trust exercise into a control. When the only AI available is a public chatbot, every rule about data handling depends on an employee remembering it under deadline pressure, and enforcement is limited to detection after the fact. When you provide a private LLM on infrastructure you control, the sensitive-data question largely resolves at the architecture layer: prompts stay inside your environment, are not used to train an external provider's model, and can be logged for the audit trail your obligations may require. The policy gets shorter and more permissive, because the long list of prohibited inputs mostly collapses into "use the sanctioned tool". Shadow AI then drops for the honest reason rather than the compliance one: staff use unsanctioned tools when the sanctioned option is worse, and stop when it is better.