Australia's Voluntary AI Safety Standard, Plainly
The Privacy Act and AI Automation: What an Australian Business Actually Has To Do
Ivan Bolonikhin
Founder, 2pizza.team
Founder, 2pizza.team
Not legal advice. This is how we design systems for Australian clients, written by engineers. Anything with real regulatory weight should go past your own adviser before it goes live. What follows is the practical shape of the obligations, not a compliance opinion.
Most Australian businesses meet the Privacy Act for the first time as a document exercise: someone writes a privacy policy, it goes on the website, everyone moves on. Then an automation project touches customer records and the questions get real, usually in the middle of a build when they are most expensive to answer.
Does it even apply to you
The Privacy Act 1988 applies to Australian Government agencies and to private sector organisations above an annual turnover threshold, with a set of carve-ins that catch smaller businesses anyway. Health service providers are the big one - they are covered regardless of turnover, because health information is treated as sensitive information with a higher bar. Businesses trading in personal information, and contractors delivering Australian Government contracts, are also caught.
If you are a small business that has assumed it is exempt, check the carve-ins rather than the turnover number. We have had this conversation with clients who were confidently outside the threshold and firmly inside a carve-in. Note too that the reform direction has been to narrow the small business exemption over time, so building as though it applies is the safer engineering choice even where it currently does not.
The principles that actually bite on an automation project
There are thirteen Australian Privacy Principles. On a typical automation build, five of them do most of the work and the rest follow if you get those right.
- Collection and notification - you collect only what you reasonably need for the function, and people know you are collecting it. In practice this kills the habit of syncing an entire table between systems because it was easier than selecting columns.
- Use and disclosure - information collected for one purpose does not quietly become training data, a marketing list, or an input to a different system, without consent or another lawful basis.
- Cross-border disclosure - sending personal information overseas makes you accountable for what happens to it. This is the one that catches AI projects, because the model provider is usually offshore.
- Security - reasonable steps to protect information, and to destroy or de-identify it when it is no longer needed. Retention is an obligation, not a storage preference.
- Access and correction - a person can ask what you hold and have it corrected. If your data is scattered across six systems with no map, answering that request is a project rather than a task.
The cross-border question, which is the one about AI
The moment your automation sends customer text to a model API, you are disclosing personal information to an overseas recipient, and you carry accountability for it. That does not make it prohibited. It makes it something you have to do deliberately.
- Strip what you do not need before the call. Most prompts do not require a full name, an address, or an account number to do their job. Redaction before the API boundary is the single highest-value control in an AI build.
- Check the provider's data handling and retention terms, and whether inputs are used for training. Enterprise tiers from the major providers contractually exclude training on your inputs. Consumer tiers historically have not.
- Prefer a region that reduces the exposure where the provider offers one. Several offer Australian or at least regional processing.
- Say so in the privacy policy. Vague wording about 'third party service providers' is doing a lot of work that a regulator may not accept.
- Consider whether the task needs a general model at all. A gradient boosting model trained on your own tabular data, running on your own infrastructure, discloses nothing to anyone.
Automated decisions are the part people miss
The reform direction in Australian privacy law has been towards transparency about automated decision-making that significantly affects individuals. The practical consequence for an engineering team is that if a system decides something material about a person - credit, eligibility, pricing, prioritisation, who gets contacted - you need to be able to say that it does, and broadly how.
This is a strong argument for the model choice we already push for other reasons. A gradient boosting model returns the features that drove each decision, so explaining it is a reporting exercise. A language model asked to produce a score returns a number with no traceable derivation, and explaining that to a regulator or an affected customer is not a reporting exercise, it is an admission.
If you are building anything that makes consequential automated decisions about people, verify the current commencement dates and the exact wording with your adviser rather than with a blog post. The direction of travel is settled; the detail and the timing are the part that changes.
Notifiable data breaches, and why it changes the build
Australia has a mandatory notifiable data breach scheme. An eligible breach - one likely to result in serious harm - has to be assessed and notified to the regulator and to affected individuals. The engineering consequence is that you need to be able to answer, quickly and with evidence, what was exposed and whose information it was.
That answer comes from logging you built earlier or it does not come at all. A system with no audit trail turns a contained incident into an unbounded one, because you cannot demonstrate the bound. This is why we log data access rather than only data changes, and why we resist the shortcut of a service account that reads everything.
What this looks like as engineering decisions
None of the above is a document. It is a set of choices that are cheap at the start of a build and expensive to retrofit.
- Select columns rather than syncing tables. Every field you move is a field you are accountable for.
- Redact before the API boundary, not after. Once it has left, it has left.
- Role-based access, with no shared service account that can read everything.
- Audit log reads as well as writes, with enough detail to answer a breach assessment.
- Set retention at build time, with an actual deletion job. Data kept forever because nobody decided is the default failure.
- Document the data flow as a diagram. If nobody can draw where personal information goes, nobody can answer an access request either.
One industry-specific warning
If you are in regulated health services, advertising rules under the National Law sit on top of privacy obligations and are considerably stricter than most industries face - testimonials in advertising regulated health services are prohibited outright. We learned that shape of constraint building for an Australian medical client, where every piece of generated content had to pass a compliance gate before publication. If AI is generating any customer-facing copy in a regulated field, the gate has to be a hard block in the pipeline, not a review step someone can skip when they are busy.
We build with these constraints designed in for Australian clients as a default, because retrofitting them is where projects blow their budget. If you want a second opinion on a build you already have, the audit at /audit is free and we will tell you what we would change. Ivan / 2pizza.team
Want us to look at your setup?
Free 30-min audit. We tell you what to automate first and what it would cost.