- Every significant automated or computer-assisted decision listed in one register with an owner
- Privacy policy disclosures generated from the register, not written from memory
- Decision events captured from legacy systems without rewriting them
- Customer service able to explain a decision and route a review
- New decision logic blocked from release until registered
Anonymised composite. Client names, identifying details and confidential figures are withheld; public facts are cited in the references.
The situation
An Australian energy retailer served households and small businesses across several states. Software touched many decisions that matter to customers: credit checks at sign-up, security deposits, payment plan offers, hardship flags, collections steps and, at the end of the line, disconnection warnings. The logic lived in a billing platform from the 2000s, a CRM, a collections tool, a credit bureau integration and a newer machine learning model that predicted who might struggle to pay.
Why now. From 10 December 2026, APP entities must include information in their privacy policy when they have arranged for a computer program to make, or do something substantially and directly related to making, decisions that significantly affect individuals' rights or interests1. The OAIC published its final guidance on 30 September 20264. Commentary on that guidance reads it broadly: it reaches rules engines and decision-support tools, not only AI, and human review does not automatically take a decision out of scope23. The retailer's privacy policy said nothing about any of this, and nobody could list where it applied.
What had to be true
- A complete list of significant decisions that software makes or substantially informs.
- Disclosures that match reality, generated from that list and kept current.
- Evidence for each decision: which system, which logic version, which data.
- Explanations on request that customer service can give in plain language.
- No new hidden decisions: changes to decision logic registered before release.
Architecture
The data flow, end to end
- DecideA system makes or informs a decision about a customer
- EmitA decision event is captured with decision type, logic version and inputs used
- LinkThe event is matched to its register entry and the customer record
- DiscloseThe privacy policy describes each registered decision type in plain language
- ExplainCustomer service retrieves the event and gives the reasons
- ReviewA customer can ask for a person to look again; the outcome is recorded
The hard part: finding decisions in twenty-year-old systems
Nobody had a list. Decision logic sat in billing configuration tables, stored procedures, collections scripts and a model in a notebook pipeline. Interviews found the obvious decisions; data found the rest. The team traced customer journeys that ended in a significant outcome, such as a deposit request or a disconnection warning, back through the systems that produced them, and recorded every step where software chose or ranked something.
Capturing evidence without rewriting the billing platform was the second problem. The OpenTelemetry Collector can read existing log files and query databases through receivers, then forward everything in one format, which is how the OpenTelemetry community recommends bringing older systems into modern observability5. The team used it to turn existing logs and table changes into structured decision events, with no change to the legacy code.
The scope calls were made with counsel. Following the guidance's broad reading, the team treated borderline cases as in scope, including the payment difficulty model, even though a person made the final hardship decision23. The hardship model was also a reason for care: it informed help for vulnerable customers, so its explanations were written with the hardship team. See explainable credit decisions in Brazil for the reason-code pattern.
You cannot disclose what you have not found. The privacy policy paragraph is the last step; the inventory is the work.
How it ran
- Scope rules
- Policy wording
- Review process
- Journey tracing
- Decision events and register
- Release gate
- Hardship input
- Explanation scripts
- Workbench and reviews
- Journey tracing
- Interviews
- Draft register
- Significance tests
- Borderline calls
- Owners named
- Collector on legacy systems
- Decision events
- Workbench view
- Policy generated from register
- Release gate
- Quarterly review
Key decisions and trade-offs
| Decision | Alternative | Why |
|---|---|---|
| Treat borderline cases as in scope | Narrow reading to limit disclosure | Matches the guidance and avoids later corrections |
| Generate disclosures from the register | Write the policy section by hand | Policy stays true as systems change |
| Capture events from logs and databases | Modify legacy code | Faster, lower risk before the deadline |
| Release gate on decision logic | Periodic audits only | New decisions cannot appear unnoticed |
| Write explanations with hardship staff | Engineering-written reasons | Clear and appropriate for vulnerable customers |
What I'd do again, and differently
Again: trace from outcomes backwards. It found decisions no interview would have surfaced, such as a deposit rule hidden in a billing configuration table. Differently: start the release gate first. Two new rules went live during the inventory and had to be found again. Related: policy layers for AI assistants, ISO 42001 and the NIST AI RMF, AI provider resilience under CPS 230 and the Australia page.
If you need to be ready for 10 December in Australia, see my fractional CTO work, or analyse your challenge and bring the result to a call.
- 1
- 2
- 3Transparency in automated decision-making: What the OAIC guidance means for your businessCorrs Chambers Westgarth · 2026
- 4
- 5Demystifying OpenTelemetry: Why You Shouldn't Fear Observability in Traditional EnvironmentsOpenTelemetry blog · 13 Jan 2026