Notes

Writing an AI Policy for a Small Australian Business

Does a small business need an AI policy?

Yes, and sooner than most owners think, because the policy is not what starts AI use in your business. It is what catches up with it. Your staff are already pasting things into chat tools. The only open question is whether anyone has told them what should never go in.

An AI policy for small business does not need to look like the policy of a listed company. One page is enough. What matters is that it is specific, that it names a person, and that it exists before the incident rather than after it.

What actually goes wrong without one?

Three things, and none of them are dramatic. They are quiet and they compound.

Customer data ends up in a tool nobody vetted, because it was the fastest way to summarise a spreadsheet on a Thursday afternoon. Work goes out the door with an error in it that nobody checked, because the output was fluent and fluency reads like accuracy. And two people in the same team build two incompatible ways of doing the same task, neither written down, both now load bearing.

None of those are staff failures. They are the predictable result of capable people being handed a powerful tool with no instructions.

What should an AI policy actually say?

Six clauses cover almost every small business. Write them in plain language, on one page, in words your team would use.

Which Australian rules actually apply?

The Privacy Act and the Australian Privacy Principles apply to how you handle personal information regardless of the technology, and that is the obligation most small businesses trip over first.

If you are putting customer personal information into a third party tool, you are disclosing it to that third party, and the ordinary rules about disclosure, consent and offshore transfer apply. The Australian Privacy Principles are the reference. Alongside that, the Australian Government's AI Ethics Principles set out the voluntary expectations around fairness, transparency, contestability and human oversight that most sensible policies end up restating in plainer words.

Nothing here is legal advice. If your business handles health records, financial advice, or personal information at scale, get a lawyer to read your page. It is a short document and it will be a short conversation.

Should the policy ban anything outright?

Yes, and a short prohibition list is more useful than a long permission list.

Ban unapproved tools for work data. Ban putting customer identifiers into anything without a written agreement covering it. Ban letting a machine send external communications unreviewed until you have specifically decided a lane is safe to run unattended. Those three cover most of the real exposure.

What a policy should not do is ban AI generally. That policy has never once been complied with. It simply moves the usage onto personal devices where you cannot see it, which is materially worse than the situation you were trying to fix.

How does a policy connect to actual builds?

The policy is the boundary that any machine you build has to sit inside, which makes it a design document as much as a governance one.

When we scope work we put approval gates in by default, so a machine drafts and a person sends until you have decided otherwise. That is not caution for its own sake. It is the same principle as the policy: the business stays accountable for what goes out under its name. Our method sets out how that gets agreed in writing before anything is built, and what to automate first covers picking a lane where an unattended machine is genuinely safe.

Start with one page

Write the six clauses. Name the tools. Name the owner. Put a review date on it. Send it to the team and tell them it is a floor, not a ceiling, and that they should say when it gets in their way.

If you would rather talk it through against what you are actually planning to build, get in touch or have a look at how we work. We would rather you had the boundary drawn before the machine is running than after.

Keep reading