Data lineage has always been one of those things that data teams knew we should have, but was often deprioritised by the program roadmap. Because it’s not something that’s immediately visible, no one was ever fired for shipping without it.
Well, that’s going to change very soon on 10 December 2026.
What’s changed
The Privacy and Other Legislation Amendment Act 2024, which commences 10 December 2026, inserted the new APP 1.7, 1.8 and 1.9 into the Privacy Act.
What does this mean?
APP entities that use personal information (that could reasonably be expected to significantly affect an individual’s rights or interests) in automated decision-making must disclose the kinds of personal information used, and the kinds of decisions made, in their privacy policy.
Defing a computer program
Note that the definition of “computer program” isn’t limited to generative or agentic AI. It includes rule-based engines, scoring tools, and arguably a spreadsheet doing the same job.
And importantly, a human in the loop does not exempt you.
Decision making
APP 1.8 addresses decisions where the program does something substantially and directly related to making the decision itself decision.
This means that even if a model produces a recommendation that a then human signs off on…
…you’re still in scope.
The hidden assumption
The OAIC ran a consultation on its transparency guidance, which closed on 15 June 2026, and its formal guidance is expected around September 2026.
There’s a hidden assumption in it….
…To disclose the kinds of personal information used in an automated decision, you have to know what personal information the system actually used.
For a deterministic rules engine, that means you need a code review.
For a model trained on a corpus assembled over multiple years by different teams, with a retrieval layer that reads live from multiple document stores…
…that’s a lineage question.
And if you can’t answer it, then you can’t write the disclosure.
Personal information disclosure
APP 10 requires that personal information you use or disclose is accurate, up to date, complete and relevant.
Now… apply that statement to a probabilistic system.
What it ends up meaning is that if your model generates personal information that is wrong (for example infers an attribute incorrectly or fabricates a detail about an individual) then you have arguably used inaccurate personal information. And the OAIC’s position on generative outputs is that content which re-identifies individuals, or, creates new personal information, falls within its collection rules.
So… hallucination isn’t just a quality problem now.
It’s potentially a data quality breach.
Where this meets APRA
Last week I shared that APRA’s April letter and its impact on on enterprise AI’s ability to produce defensible evidence. And that provenance is what that evidence needs to sit on.
Now, remember that an APRA-facing assurance artifact has to assert that the system:
- Operates within a defined tolerance
- That the assessment was independent
- That the evidence is current rather than point-in-time
Every one of those claims is now being made about a system whose behaviour is determined by its inputs.
Meaning that an assurance statement made without provenance is essentially an assertion about a system that you can’t fully describe accurately, and such a statement won’t pass testing.
Three obligations in one capability, for the CFO
Data lineage for AI systems shouldn’t be addressed in three different projects but as one capability serving three separate regulatory demands:
- Privacy transparency under APP 1.7 to 1.9, live from December.
- Prudential assurance under CPS 220, CPS 230 and CPS 234, per APRA’s published expectations.
- And critical operations mapping under CPS 230, which requires you to identify the dependencies underpinning a critical operation – and grounding data is a dependency whether or not anyone has classified it as one.
This means you’ll need one build that rolls up three different business cases.
This evolves your lineage project from “data engineering hygiene that can be deprioritised” to “shared compliance infrastructure with a December deadline”.
Now your sponsorship shifts as a result.
What the artifact has to contain
Each AI system making decisions about people needs:
- The complete set of data sources, both training and retrieval, with the trust tier of each.
- The classification carried by each source, and the classification of any derived artifact – which, as I noted on Monday, is where classification tends to get lost.
- The identities with write access to each source.
- The date each source was last reviewed against the purpose it was collected for.
- And a record of which model version was trained on which dataset version, ideally with a cryptographic hash rather than a filename.
That ends up being six fields to produce across those five points.
All of which are difficult to reconstruct after the fact.
Your four month clock is ticking
If you’re starting from scatch then full lineage across the estate by December isn’t a realistic goal at this stage.
So what can you do?
Limit your scope to the systems the obligation actually impacts the most…
Automated decisions affecting individuals’ rights or interests.
In most Australian financial services organisations there’s a handful of areas that covers: credit decisioning, claims assessment, fraud and AML triage, hardship assessment, underwriting.
Firstly, get provenance right for those.
Secondly, document what you can’t yet cover, and included a remediation plan.
If a supervisor comes knocking, then showing a partial capability with a credible plan gives you more leeway. A supervisor that gets back an assertion that can’t be evidenced is unlikely to give you that.
Sources
- OAIC, Consultation on Guidance for Transparency in Automated Decision Making, 18 May 2026 — https://www.oaic.gov.au/engage-with-us/consultations/consultation-on-guidance-for-transparency-in-automated-decision-making
- OAIC, Guidance on privacy and developing and training generative AI models — https://www.oaic.gov.au/privacy/privacy-guidance-for-organisations-and-government-agencies/guidance-on-privacy-and-developing-and-training-generative-ai-models