Picture a General Counsel who adopted an AI legal research tool twelve months ago. Faster outputs, broadly accurate, daily use across employment matters, contractual reviews, privacy questions. Nobody paused to ask whether the tool would satisfy a transparency obligation attaching to every APP entity in Australia as of December this year.
Now picture her last week, running a performance management query. An employee's HR records and correspondence, fed into the tool to assess the strength of a case before taking it to the board. The tool synthesises the personal information, returns an assessment, and she drafts her advice. A routine task. A capable tool. And, she is about to discover, a process with a specific, dated legal problem she hasn't mapped.
The OAIC's consultation on guidance for automated decision-making transparency closes this Monday, 15 June 2026. The guidance it produces will frame how APP 1.8 of the Privacy Act 1988 is read and enforced when the provision commences on 10 December. The GC has never heard of APP 1.8. Most in-house legal teams haven't.
The obligation sounds, at first read, as if it applies to fully automated systems: the algorithm that approves a loan, the model that flags a fraudulent transaction. The OAIC's consultation signals something broader. The guidance under development covers any decision-support tool where technology plays a material role in shaping decisions, well beyond purely automated outputs. Under that framing, the performance management query our GC just ran, an AI tool synthesising an employee's personal information to help form advice that influenced a board decision sits squarely within scope. The APP entity, meaning the organisation whose legal team used the tool, carries a disclosure obligation in relation to how personal information flowed through its decision-making process, regardless of whether a human reached the final conclusion.
When our GC works this out, the next thing she does is call her vendor. She has four questions.
Can the vendor tell her whether the tool sends query content and personal information to third-party models? She needs to know whether the employee records she fed in last week stayed within a closed environment or passed through an open API hosted somewhere offshore. The vendor's answer is slow and hedged. APP 8 governs cross-border disclosure of personal information; that question and the APP 1.8 question compound each other, and an organisation that hasn't mapped its AI tool's data routing cannot assess its exposure under either.
Can the vendor produce a traceable record of what sources the tool drew on and what processing it performed? The employee involved in the performance matter would have a reasonable expectation of knowing, if they asked, that their personal information had been processed in this way. For the GC to respond to such a request, or to satisfy a regulator, she needs a record. The vendor confirms the tool produces outputs. It does not produce a processing record.
Can the vendor specify what personal information the tool processed across a given matter? The vendor cannot answer this. It processes queries. It returns results. What it does not do is maintain an auditable account of what personal information passed through it, in what context, and to what effect. That is a structural problem, not a logging oversight.
What are the vendor's data retention practices. Does query content get retained, and for how long? This question lands in silence. Nobody asked it during procurement. Nobody asked it in the twelve months since.
Our GC has now correctly identified that she has a tool generating plausible, useful outputs from an opaque process, and that from 10 December that gap carries a specific legal obligation. The difficulty is structural. General-purpose AI tools - large language models adapted for legal work rather than built for it - were designed for fluency and breadth. Audit trails, closed data environments, and traceable processing records were not in scope when they were built. They are hard to retrofit. A tool cannot produce an auditable account of what it processed if the architecture was never designed to hold one.
We built Habeas differently, and the architecture matters here in a way worth being direct about. Habeas operates as a closed corpus: over 300,000 Australian cases and pieces of legislation, a legitimate and verifiable dataset, not a connection to open third-party models. Every output traces to the specific source document it drew on. The citations are traceable, not generated, which means the research record is something a practitioner can account for. A GC describing a General Counsel we work with put it plainly: "The Australian-law focus and the depth of nuance in the answers is a major differentiator. It materially changes my confidence and speed when forming legal views." That specificity is downstream of architecture. It is also what produces a record an APP entity can point to when asked to describe how its AI tools process personal information. A closed corpus with traceable citations can be accounted for. A tool that generates plausible text from an opaque process cannot, and from December that distinction has a legal dimension it did not have before.
We are not in the business of claiming a compliance shortcut, the obligation is new and the guidance isn't final. What we can say is that the architecture either supports an answer to the vendor questions our GC just asked, or it doesn't.
As for the consultation itself: the guidance the OAIC finalises will define the interpretive framework for APP 1.8 enforcement, the administrative standard compliance teams will work against for years. The decision-support framing is almost certainly here to stay; the policy rationale is too strong for the OAIC to confine the obligation to purely automated outputs. A boilerplate privacy policy sentence acknowledging that technology is sometimes used will not discharge it. Enforcement under the Privacy Act carries real consequences, and the OAIC has conducted investigations under considerably less specific obligations than this one.
The legal profession, in aggregate, has not mapped its AI tools against this question. Many firms adopted these tools on the strength of demos and accuracy benchmarks, without asking what personal information the tools touch or how the organisation would account for that processing if asked. Closing Monday, the consultation is the last practical opportunity to shape how that question is answered in guidance. The obligation itself arrives on a specific date whether or not anyone has shaped the guidance, or put four questions to their vendor, or noticed the problem at all.
The architecture is the argument. Habeas is at habeas.ai.
The legal research in this article was conducted and every citation verified using Habeas, the Australian legal AI research platform.
