Your privacy policy has to describe a system that cannot describe itself

The part nobody is writing about

There is no shortage of coverage of the automated decision-making transparency obligation. Law firms have written it up carefully, and our own summary of what the rule actually says is worth reading before this one.

What none of them cover is the engineering. They tell you that your privacy policy must describe the kinds of personal information used in automated decisions and the kinds of decisions being made. They do not tell you how to find out, in a business that already runs a dozen automated processes, which of them qualify. That is not a legal question. It is a question about software you already own, and in most cases the software cannot answer it.

A privacy policy is a description of a system. Most systems were never built to be described.

Where the decisions actually are

The phrase "automated decision-making" makes people picture a model. So they check whether they run a model, find they do not, and stop. That is the first place this goes wrong, because the rule is not about the technique. It is about whether a computer program decides something, and whether that decision significantly affects a person.

In an ordinary Australian business of 20 to 200 staff, the candidates are rarely where anyone looks first.

Only the last of those is AI in the sense people mean. The other five predate the current wave entirely, and most were written by somebody who has since left. They are still automated decisions.

Why the system cannot answer

Ask a typical operational system what it decided about a given person last March and you will usually get the outcome. The record says the application was declined, the request was routed to tier two, the account was flagged. What is almost never recorded is the part the disclosure obligation is actually about: which inputs were considered, which rule applied, and whether a person could have changed the result.

This is not negligence. Application logs are built for debugging and for recovery, so they record what happened in order that it can be replayed. A decision record is a different artefact with a different purpose, and very few systems have one, because until now nothing required it.

The practical consequence is that the inventory step everyone recommends is harder than it sounds. You cannot inventory what the system does not record, so for a good number of processes the honest first move is to read the code rather than query the database.

The four things worth instrumenting

If a process turns out to be in scope, four things make it describable. They are in order because the order is real: you cannot classify a decision you have not found, and you cannot disclose one you cannot describe.

1. A decision record, separate from the activity log. One row per decision, written at the moment it is made. It needs the classes of personal information that fed the decision, not the values. "Employment history, address, age band" is what a privacy policy discloses; the actual address belongs in the system of record, not duplicated into a log that will be retained for years.

   Recording classes rather than values also stops the instrumentation becoming its own privacy problem, which is the usual failure mode of a naive audit trail.

2. The version of the rule that decided. Rules change. A decision made in March under one threshold and one made in September under another are different decisions, and a policy describing only the current logic misdescribes everything before it. A version identifier costs almost nothing at write time and is close to unrecoverable afterwards.
3. The human checkpoint, and whether it was used. This is the one most often missed, and it decides whether a process is in scope at all. A decision does not stop being automated because a person clicked approve. What matters is whether that person had the information and the standing to decide differently.

   So record both: that a checkpoint existed, and whether the outcome was ever changed at it. A checkpoint that has never once altered a result is evidence about the process, and it is better to know that before somebody else works it out.

4. Retention that outlives the decision. Someone affected by a decision may ask about it well after the operational data has been archived or purged on its own schedule. Decision records need a retention period set deliberately against the obligation rather than inherited from whatever the surrounding table does.

The rubber stamp problem

Partial automation is where most of the genuinely difficult calls sit. A system scores an application, a person reviews the score, the person approves. Is that automated?

The test is not whether a human was present. It is whether the human input was capable of changing the outcome. A reviewer processing 200 items an hour, seeing only a score and a recommendation, with no view of the inputs and no practical ability to disagree, is not a decision-maker. They are a step in the automation.

What it looks like when it is built in

The cheapest version of all of this is the one where the instrumentation is part of the system from the start, because retrofitting a decision record into a process that has run for four years means reconstructing intent from code.

It is the reason the AI agents we build are specified with an audit trail, a defined human approval path, a scoped role and bounded system access before anything is deployed. An agent whose actions are not recorded cannot be described later, and an agent without a defined approval path cannot answer the question in point three. The same reasoning puts an immutable audit log capturing every action into the workflow systems, where the decisions are rules rather than models.

It also shows up in work that had nothing to do with this deadline. In a SharePoint access governance build for a Perth resources business, every access request carries a duration and an expiry calculated when the request is made rather than left to a reviewer's calendar. That was designed for a security review, not a privacy one. It happens to produce exactly the kind of record this obligation now asks for, which is usually how governance works: the systems that can answer a new question are the ones already answering an older one.

What is worth doing in the time left

There is enough time before commencement for the inventory and the policy wording. There is not enough to re-engineer six processes, so the sequencing matters.

• List the candidate surfaces first, not the systems. Ask what decisions get made about people, then find which software makes each one. Starting from the application list misses the rules buried inside workflows.
• Mark the significant ones honestly. "Significantly affect" is the term doing most of the work in the test and it is not yet settled. Employment, finance, access to a service and anything with a legal consequence are the safe assumptions.
• Check each one for a decision record before assuming it has one. This is the step that determines whether the rest is a writing exercise or an engineering one.
• Write the policy against what the systems can actually evidence today. A privacy policy describing a level of traceability you do not have is a worse position than a plainer one that is true.
• Give it an owner past December. Rules change and new automations ship. A disclosure accurate on the tenth and stale by February is the predictable failure.

The obligation is a transparency one, not a consent one. Nothing here requires stopping an automated process, and nothing requires asking permission to run it. It requires being able to say what it does, which is a much lower bar legally and a much higher one technically.

Common questions