Most staff in South Australian councils, not-for-profits and small businesses are already using generative AI at work, whether or not anyone approved it. They paste a tricky email into a free chatbot to soften the tone, ask an assistant to summarise a long report, or use the AI features that have quietly appeared inside the tools they already have. Banning it rarely works and pushes the use out of sight. A short, clear acceptable use policy does better: it tells people which tools they can use, what information must never go into them, and who is responsible for the result. This guide covers what to put in a generative AI acceptable use policy, a one-page outline you can adapt, how to roll it out, and what differs for councils, agencies and small businesses. It is general guidance, not legal advice.
For the wider legal picture, including the Privacy Act automated decision rules from 10 December 2026, see our AI laws tracker for SA organisations.
Why a short policy beats a long one
An acceptable use policy is the staff-facing layer of AI governance. It is not your whole framework: the AI inventory, risk tiers and approvals sit behind it, and the Voluntary AI Safety Standard and the Guidance for AI Adoption describe the organisational practices. What staff need is something they can read in five minutes and remember when they are about to paste a document into a chat window. Two pages is plenty. If a rule needs a paragraph of explanation, put the explanation in training and keep the rule in the policy.
What to include
- Purpose and scope. Say the policy covers any tool that generates text, images, audio, code or summaries, including AI features built into email, office suites, CRMs, meeting tools and browsers, and that it applies to staff, contractors and volunteers using work information on any device.
- Approved tools and accounts. Name the tools staff may use and require work accounts, not personal free accounts. Business plans usually give you admin control, audit logs and contract terms about how your data is used. List the settings you rely on, such as chat history and training opt-outs, and say how staff request a new tool.
- Information rules. The most important section. A simple traffic-light rule, shown in the table below, is easier to follow than a long list of prohibitions.
- Checking outputs. Staff stay responsible for anything they send, publish or act on. AI output must be checked for accuracy, tone and fairness before use, and facts, figures, references and legal or policy statements must be verified against the source, because models can produce confident, plausible errors.
- Decisions about people. AI must not be the deciding factor in decisions about a person, such as hiring, discipline, eligibility, enforcement, fees or service levels, without approval through your governance process and a human who reviews and owns the decision.
- Transparency. Say when staff should tell people AI was used, for example in public-facing content, correspondence that relies substantially on AI drafting, or chatbots that customers talk to. Never present AI output as a person’s own professional opinion if no one has reviewed it.
- Records, privacy and confidentiality. Prompts and outputs can be records. Set out how they are kept, and remind staff that the Privacy Act and client confidentiality obligations apply in a chat window exactly as they do in email.
- Intellectual property. Do not paste in third-party material you are not licensed to share, and check the terms of the tool before using generated images, code or text in published or commercial work.
- Connecting and building. Plugins, browser extensions, connectors to your files or email, AI agents that act on systems, and anything built on an AI API need approval first, because they can reach far more information than a single chat.
- Reporting problems. Give one clear place to report a mistake, such as personal information pasted into the wrong tool or an AI answer that surfaced a document someone should not see, and make it safe to report. Treat serious cases through your incident response plan.
- Training and acknowledgement. Staff complete short training before using approved tools and acknowledge the policy.
- Ownership and review. Name the owner and review the policy every six to twelve months, because tools, contract terms and guidance change quickly.
A traffic-light rule for information
| Category | Examples | Rule |
|---|---|---|
| Green | Public information, published policies, your own general drafting, generic questions with no names or identifying details | Fine in any approved tool |
| Amber | Internal documents, non-public business information, de-identified data, draft reports | Only in approved tools with a work account and business data protections switched on |
| Red | Personal or health information, customer or ratepayer records, staff matters, legal advice, passwords and keys, security details, information classified under your scheme, commercial-in-confidence tender material | Never in public or personal AI tools; only in tools specifically approved for that information, if at all |
The Office of the Australian Information Commissioner’s guidance on privacy and commercially available AI products recommends, as a matter of best practice, not entering personal information, and particularly sensitive information, into publicly available generative AI tools. The red row reflects that. SA public sector organisations should map these rows to the classification levels they already use under the SA ISMF rather than inventing new labels.
A one-page outline you can adapt
- Why we have this policy (two sentences on benefits and risks)
- What it covers (tools, people, devices)
- Tools you can use (named list, work accounts only, how to request another)
- What you can put in (the traffic-light table)
- Your responsibilities (check outputs, no decisions about people without review, say when AI was used)
- Things that need approval first (plugins, connectors, agents, new tools, public chatbots)
- If something goes wrong (who to tell, and that reporting quickly is expected and safe)
- Owner, training and review date
How to roll it out
- Approve tools before you publish the policy. A policy that bans free tools without offering a work alternative will be ignored. If you use Microsoft 365, the work-account Copilot Chat experience is often the quickest approved option; see our Microsoft 365 Copilot readiness guide before you switch on anything that searches your files.
- Ask what people already use. A short anonymous survey finds the tools in use and the tasks people value, which tells you what to approve first.
- Train with real examples. Forty-five minutes on good prompting, checking outputs and the traffic-light rule, using your own documents and scenarios, does more than a long policy. Our guide to AI skills for staff covers the content.
- Back the policy with settings. Use admin controls to require work sign-in, switch off features you have not approved, and apply data loss prevention to the red category where your licences allow.
- Review after three months. Look at the questions and incident reports you received, update the approved list, and tighten or relax rules based on what actually happened.
What differs for councils, agencies and small businesses
- Councils should agree with their records manager how AI prompts and outputs are treated under the State Records Act 1997 and the Freedom of Information Act 1991, and consider elected members separately from staff. Public-facing chatbots and AI-drafted correspondence to ratepayers deserve an explicit transparency rule. Our guide to AI for South Australian councils covers the wider picture.
- SA Government agencies should align the policy with the SA ISMF, their information classification requirements and any current whole-of-government guidance on generative AI. Federal agencies work to the Policy for the responsible use of AI in government.
- Small businesses and not-for-profits can keep it very short. The two rules that prevent most harm are work accounts only, and no personal, client or confidential information in tools that are not approved for it. Organisations below the Privacy Act small business threshold should still check whether an exception brings them into coverage, as many health and service providers are.
Common mistakes
- Copying a large organisation’s twelve-page policy that no one reads.
- Banning AI outright, which moves use onto personal phones where you have no visibility.
- Forgetting AI features built into existing software, which are often switched on by default in updates.
- Writing the policy once and never reviewing it as tools and contract terms change.
- Treating the policy as the whole of AI governance, with no inventory, risk tiering or approval path for higher-risk uses.
- Leaving out when staff must tell people that AI was used. See our guide to chatbot disclosure and AI content labelling.
This article reflects common practice and guidance as at late 2026. Privacy law, government AI policy and vendor terms change, so confirm current requirements with the OAIC, your agency or council guidance and your advisers before you finalise a policy.
Talk to an Adelaide team
A policy covers how staff use AI tools. When you build or connect your own chatbot or agent, the risks move into the design itself; see threat modelling for apps and AI agents for a practical way to review them.
If you want a policy your staff will actually follow, talk to us about an AI acceptable use policy and staff session or call 0402 401 584. We can draft a short policy around the tools you already use, run a practical training session with your team, and set up the inventory and approval path behind it. Read more about our AI governance and assurance and training and team consultations services.