The AI Verdict Isn’t the Decision. The Email It Triggers Is.
Compliant by Design — Essay 08
From 10 December 2026, an Australian privacy policy has to disclose the automated decisions behind it. APP 1.7, inserted by the Privacy and Other Legislation Amendment Act 2024, is the most concrete Australian AI obligation with a date on it. I write a series about building AI products under exactly this regime, and in July I noticed that neither of my products’ compliance registers had a line for it. The person who writes about other people’s gaps had the most dated one on his own books. So I ran the audit on myself. The conclusion was stranger than either “it applies” or “it doesn’t”: the law probably skips my AI feature, probably catches an email my AI triggers, and will catch everything the day my second product launches.
What the rule actually asks
APP 1.7 is a transparency obligation, not a conduct one. If you have arranged for a computer program to make a decision, or do something substantially and directly related to making one, and that decision could reasonably be expected to significantly affect a person’s rights or interests, and personal information is used along the way, then your privacy policy must say so: the kinds of personal information used, the kinds of decisions made solely by the program, and the kinds where the program does a related thing. No right to an explanation, no right to human review. Words in a policy.
Two scoping points matter for anyone building on AI APIs. “Computer program” is deliberately broad: a rule-based engine counts the same as a frontier model. And “arranged for” covers procured systems, so calling someone else’s AI API is arranging.
Whose decision is it?
VeriShield’s reason to exist is an AI verdict. Paste a suspicious message, get Safe, Caution or Danger with a summary. The stakes clear the “significant” bar comfortably: a wrong Safe on a real scam can cost a user over fifty their savings, and a wrong Danger on a real bank message can make them ignore it. If anything in my products is the automated decision this law has in mind, surely it is the product’s headline feature.
Then I read the regulator’s examples. The OAIC’s final guidance landed on 30 September, ten weeks before commencement, and its worked examples share a shape: an entity’s program deciding something about a person. Approvals, triage, eligibility. VeriShield’s verdict points the other way. It is advice to the person, so they can make their own decision about their own message. The statute never says whose decision it has to be, and the guidance never asks the question. I treated it as open and put it on the lawyer list, because I could argue either side before lunch.
The email is the decision
While the headline feature sat in the maybe column, something boring walked straight into scope. When a check returns Danger, a program decides, with no human involved, to email the user’s nominated family contacts, and the email carries what was checked and the result. Solely automated. Driven by personal information. Affecting a person under an arrangement they signed up to. Every element of the test, no interpretive stretch required. And on a family plan, one person’s check can trigger an email about another, which is precisely the vulnerable-user pattern the regulator says raises the stakes.
That inversion is the finding I did not expect. The component with artificial intelligence in its name is arguable. The plumbing around it is not. If you are running this analysis on your own product, inventory the programs that act on the model’s output before you agonise over the model.
The product with no AI
Miinfo, my second product, is pre-launch and has no AI anywhere: emergency health information behind a QR code, rule-based end to end. Rule-based programs are explicitly covered, so it gets the same inventory. Almost everything falls out as either executing the user’s own standing instruction or trivial. The borderline item is the rate limiter guarding the public emergency chart. Refusing a request is “refusing to do a thing”, and the regulator’s own example of a significant effect is a decision affecting access to healthcare services. Paramedics behind one hospital network can share an IP address. The product’s most defensible security control is also its most plausible automated decision, and it is a safety finding whether or not the law ever applies.
I logged a design gate next to it. Today the chart displays the user’s own entries. The day any feature computes a clinical signal from them, the analysis gets rerun before it ships.
The exemption attaches to the company, not the app
In August I wrote that the Privacy Act probably exempts me, because the company sits under the small-business threshold (Essay 04). That is still true, and it now has an expiry date I can name. The exemption is lost by an entity that provides a health service and holds health information, and that status attaches to the entity, not the product. Miinfo’s whole purpose is recording a person’s conditions, medications and allergies for use in an emergency. The day it holds its first real user’s health information, the company running it very likely stops being a small business operator. Both products run under the same Pty Ltd. So Miinfo’s launch day is the day VeriShield’s privacy obligations, APP 1.7 included, stop being voluntary. One product’s launch checklist turned out to be the other product’s compliance deadline.
Whether an emergency-information app “provides a health service” is on the lawyer list too. But “record the individual’s health” sits in the statutory words, and I am not building on the assumption that a court reads them out.
What I did with “probably not, yet”
I wrote the disclosure paragraph anyway. The OAIC’s fact sheet tells entities in doubt to take a cautious approach and disclose, and the paragraph costs one policy section: what the programs use, what happens with no human in the loop (the verdict, the daily-limit refusal, the family alert), and what a person can do about each. Writing it surfaced gaps of its own, which is the audit paying twice: you cannot describe your automated decisions accurately until you can see them clearly enough to describe.
The uncomfortable takeaway
“Does this law apply to my product?” turned out to be the wrong question twice. Wrong once because the decisions hide in the plumbing, not the model: audit the programs that act on outputs, not just the thing called AI. Wrong twice because the threshold attaches to the entity: your exemption can be repealed by your own roadmap. “The law doesn’t apply to me” is not a fact about you. It is a dated claim, and the next thing you ship can be the thing that falsifies it.
Compliant by Design is a fortnightly series on building AI products under Australian regulation — Privacy Act, APPs, NDB, health data — written from inside the work, not above it.