Preparing for Australia's Automated Decision-Making Transparency Requirements

From 10 December 2026, an APP entity may need to disclose in its APP Privacy Policy where a computer program participates in a consequential decision involving personal information.[1][3]

The disclosure is the visible part.

The harder work is operational: knowing which decisions are affected, what mechanisms contributed to them, what information they used, where authority sat, and where human judgement actually occurred.

New transparency requirements under Australian Privacy Principle 1 commence on that date. They apply where an APP entity has arranged for a computer program to make, or do something substantially and directly related to making, a decision that could reasonably be expected to significantly affect a person's rights or interests, and personal information about that person is used in the program's operation.[1][3]

Where that test is met, APP 1.8 requires the entity's privacy policy to include the kinds of personal information used, the kinds of decisions made solely by computer programs, and the kinds of decisions for which computer programs do something substantially and directly related to making the decision.[3][5]

That is a privacy policy change. It is also the visible edge of a much less visible problem. For many organisations, answering it will require more than identifying their declared AI systems.

The statutory question is not really about AI at all.

What actually changes on 10 December 2026

On 30 September 2026, the Office of the Australian Information Commissioner published new resources to help organisations prepare for APP 1.7 to 1.9, including a fact sheet and a compliance flowchart.[2][3][4] The obligation itself was introduced through the Privacy and Other Legislation Amendment Act 2024.[1]

The scope test has three parts. An APP entity is caught where:

• it has arranged for a computer program to make, or do something substantially and directly related to making, a decision;
• that decision could reasonably be expected to significantly affect an individual's rights or interests; and
• personal information about that individual is used in the operation of the program for that purpose.[3]

Three aspects of that test are particularly important.

Computer program is not a synonym for AI

The obligation is technology-neutral. The Explanatory Memorandum to the amending Act, quoted in the OAIC's consultation material, states that "computer program" in APP 1.7(a) is intended to take its ordinary meaning and encompass a broad range of matters, including pre-programmed rule-based processes and artificial intelligence and machine learning processes.[6] The OAIC's fact sheet confirms the same breadth, adding commonly used software, apps and word-processing tools, and generative AI including chatbots.[3]

But breadth does not mean every use of software is captured. The program still has to make the decision, or do something substantially and directly related to making it.

The Explanatory Memorandum gives a useful illustration. A pre-programmed spreadsheet formula used to score and triage people may be substantially and directly related to the resulting decision. A spreadsheet used only to calculate a person's age from their date of birth, or to add numbers to arrive at a sum, has a direct connection to the decision without being a sufficiently substantial contribution to it.[6]

That distinction matters. A readiness exercise limited to "our AI systems" could miss deterministic calculations, rules engines, scoring mechanisms or decision functionality embedded inside third-party software, each of which the regulator's own guidance treats as potentially in scope.

The relevant question is not:

Is this AI?

It is:

What does this computer program actually contribute to the decision?

Human review does not automatically take the decision out of scope

APP 1.7 does not apply only to decisions made entirely by software. It also covers a program doing something substantially and directly related to a decision ultimately made by a person. "Substantially" means the program is a key factor in facilitating the human's decision; "directly" means it has a direct connection with making it.[3][6]

A final human approval does not, by itself, tell us how the decision was actually formed. A person clicking approve tells us a person was involved. It does not tell us whether that person had access to the relevant evidence, could meaningfully challenge the computer-generated recommendation, could reach a different conclusion, held the institutional authority to decide, or where the substantive judgement in the decision actually occurred.

Those are broader governance questions, not additional requirements imposed by APP 1.7 itself. But they matter when an organisation tries to understand how its consequential decisions are really being made.

Arranged for can reach beyond software built in-house

An organisation does not need to own or operate the software itself to be in scope. The words "arranged for" recognise that a computer program may be operated by one entity while another entity is responsible for arranging for it to make or assist a decision.[6] During and after procurement, the OAIC expects an entity to monitor third-party use of the program, and to identify, assess and oversee how a third-party product or service uses it to make or assist decisions.[6]

Procurement does not remove the underlying transparency question. If a third-party product participates materially in a consequential decision involving personal information, the organisation that arranged for its use needs to understand what role it plays.

The obligation is nevertheless a transparency obligation. It does not require an organisation to publish its complete operating architecture or expose every internal algorithm. Nor does it itself create a general right to human review, explanation or contestation of a computer-assisted decision. It requires specified information about relevant uses of computer programs to appear in an APP Privacy Policy.

Why the privacy policy sentence is the easy part

Writing a sentence that explains how computer programs use personal information in particular categories of consequential decisions may take only a few lines.

Establishing that sentence confidently is harder. An organisation may first need to work out which consequential decisions are relevant, which computer programs materially participate in each one, what kinds of personal information they use, whether a program makes a decision itself or substantially and directly assists someone else to make it, and how that participation fits within the institution's wider decision-making environment.

APP 1.8 does not require an organisation to maintain a detailed reconstruction of every individual decision, and it does not prescribe any particular architecture for answering these questions.[3][5] But there is a practical difference between writing a disclosure from a software inventory and writing one from an understanding of how consequential work actually happens. That is where the operational problem begins.

What follows is a five-step approach to that operational problem, and where DataMPowered's own architecture, ifCEM, could plausibly help with each step. This is DataMPowered's own interpretation of the operational challenge. It is not OAIC guidance or legal advice, and it does not claim that ifCEM, or any other product, makes an organisation compliant. Whether a particular decision falls within APP 1.7, and what an APP Privacy Policy must say about it, remain matters for the organisation and its advisers.

Step 1: Find consequential decisions

Start with decisions and their consequences for people, not with a catalogue of AI products.

APP 1.9 makes clear that "making a decision" includes refusing or failing to make one, and that a decision may affect a person's rights or interests beneficially or adversely.[1][5] The OAIC's own non-exhaustive examples span decisions to grant a government benefit or housing assistance, decisions affecting contractual rights such as an insurance policy, and decisions affecting access to a significant service or support such as healthcare, credit, education, employment or immigration processing.[3][5]

The common thread is not a technology. It is the consequential decision. Operationally, that means examining real institutional work, including existing processes, systems, policies, people, rules and decision points, rather than starting from a list of software labelled "AI."

How ifCEM could help

ifCEM starts with a real situation and the language a person uses to describe it, rather than requiring them to already know the correct system, form or mechanism. Work moves from expression and situation, through interpretation of intent, to discovery of relevant institutional capability and establishment of what is authoritative, applicable and permitted.[7] A capability that is discovered or proposed does not become institutional fact merely because it was surfaced; establishment, authority and the binding of a capability to a particular mechanism remain separate concerns.[7]

Tracing a real piece of work through that sequence, rather than through an inventory of software, is one way to help surface where computer programs, deterministic mechanisms, existing systems, institutional rules, people and models actually contribute to a decision.

This should not be read as an automated scan of an organisation. ifCEM does not currently enumerate every consequential decision, or every computer program, across an institution. It is available today for guided evaluation of one real use case and bounded organisational pilots.

Step 2: Separate the mechanisms involved

Once a consequential decision is found, resist collapsing everything that contributes to it into "the system."

One outcome might involve a deterministic calculation, an existing application, an institutional rule, a third-party service, a predictive model, a language model, and a person exercising judgement, sometimes in sequence and sometimes combined inside one platform. APP 1.8 itself depends on this kind of separation, because it distinguishes decisions made solely by a computer program from decisions a program merely assisted substantially and directly.[3][5]

How ifCEM could help

ifCEM is deliberately model-optional, and a Worker is not the work itself. A Worker is the bounded mechanism through which an institutional capability is engaged: it may use deterministic logic, an approved tool chain, an existing application or service, or a selected language model.[7] The Supervisor governs the conditions under which that engagement may proceed, and GovernedWork persists what was actually engaged for a given piece of work.[7]

Institutional capability, Worker, the tool or model a Worker uses, and GovernedWork are different things, and keeping them distinct is useful here. The institution's capability to check eligibility, approve a payment or assess a claim should not disappear because the Worker, model or service fulfilling it changes.[7]

Nor is ifCEM organised around a predefined set of workflows that a person must already know how to navigate. Existing workflows can themselves remain useful institutional capabilities or mechanisms that a Worker engages. ifCEM's organising model is governed work around a real situation, not a workflow a user must already be able to name.

Step 3: Establish authority and accountability

Capability does not confer authority. A computer program may be technically able to calculate an entitlement, recommend an outcome or initiate an action without thereby having the institutional authority to do so. A person may likewise be capable of performing a task without holding the delegation required to make a particular consequential decision.

Those distinctions matter more as AI makes institutional capability easier to reach through ordinary language.

How ifCEM could help

The Sovereign Operational Capability Architecture keeps institutional meaning, capability, rules, authority, evidence and judgement institution-owned.[7] ifCEM provides governed access to, and work around, that institutional capability. It does not become the authoritative home of the institution itself.[7]

Judgement Governance™ addresses a related problem: a person's presence in a decision is not the same as authorised or meaningful judgement. The governing question is how consequential human judgement is prepared, supported, exercised, evidenced and made reviewable.[8] Within ifCEM, Supervisor governance and GovernedWork are intended to keep authority boundaries explicit for the work they govern.[7]

ifCEM does not invent an organisation's authority structure. Delegations, decision rights and accountability remain institutional facts the organisation itself must establish.

Step 4: Make consequential work reconstructable

APP 1.8 does not require a detailed provenance record for every individual decision. DataMPowered's own view is that reconstructability still becomes valuable once an organisation needs to understand, maintain and defend its higher-level description of consequential decision-making over time.

For an important outcome, useful questions include what situation gave rise to the work, what authoritative information and institutional requirements applied, what capabilities were engaged, which computer programs or other mechanisms materially contributed, what authority applied, where human judgement was required, what happened, and who remained accountable for the outcome.

How ifCEM could help

This is the purpose behind Judgement Passport™. A Judgement Passport is not intended to be a generic AI audit log, a transcript archive or a model explainability report. Its object is the eligible governed outcome and the material institutional evidence needed to make that outcome reconstructable and accountable: the situation and context, the authoritative evidence relied on, the applicable requirements, the authority or delegation exercised, the institutional capabilities and material system or model contributions involved, relevant human judgement, and the accountability owner.[9]

That evidence can be genuinely useful when an organisation needs to understand how a computer program participated in one consequential matter. But a Judgement Passport is not an APP 1.8 disclosure, and APP 1.8 does not require a Judgement Passport or an equivalent per-decision record.

Current product maturity should be stated precisely. Judgement Passport foundations, internal issuance, persistence, association, projection and read capability, exist for eligible governed outcomes. Customer-facing presentation and broader access continue to mature, and a Passport is not issued for every piece of work.[9] Nor can a Passport retroactively reconstruct work that never passed through the governed architecture.

Step 5: Turn operational understanding into transparent disclosure

Once an organisation understands which consequential decisions are relevant, what kinds of personal information are used, and how computer programs participate, the privacy policy requirement becomes much clearer. APP 1.8 asks for three categories of information: the kinds of personal information used by the relevant computer programs, the kinds of decisions made solely by those programs, and the kinds of decisions for which those programs do something substantially and directly related to making the decision.[3][5]

The law does not require the privacy policy to reproduce the institution's entire operating model. But the organisation still needs a defensible basis for what it says.

How ifCEM could help

ifCEM's governed-work model is designed to keep context, capability, mechanisms, authority, evidence and accountability connected to the work in which they participate, for the work it governs.[7] That can make the relevant institutional and mechanism boundaries easier to examine than if they have to be reconstructed later from disconnected systems and records.

It does not mean ifCEM automatically produces an APP-compliant privacy policy. It does not determine whether a particular decision significantly affects an individual's rights or interests. It does not inventory every computer program across an organisation. And it does not certify Privacy Act compliance. Those remain organisational and legal responsibilities.

What the OAIC requires, and what this is

The legal requirement is specific. From 10 December 2026, an APP entity that meets the APP 1.7 conditions must include the information specified in APP 1.8 in its APP Privacy Policy, with APP 1.9 defining relevant aspects of a decision and its effects.[1][3][5]

The law does not require ifCEM. It does not require the Sovereign Operational Capability Architecture. It does not require Judgement Governance. It does not require Judgement Passport.

Those are DataMPowered's own architectural responses to a broader institutional question: how does an organisation continue to understand, govern and account for consequential work as computer programs, AI, existing systems and people increasingly participate together?

The five-step approach above is one way of thinking about that question. ifCEM is currently available for guided evaluation and bounded organisational pilots, not as a certified compliance product and not as a guarantee of Privacy Act compliance. An organisation could reach the same operational understanding through many different combinations of governance, technology and process.

But the larger challenge remains. A privacy policy can only describe an organisation's use of computer programs accurately if the institution first understands how the relevant consequential work is actually being performed.

December creates the transparency deadline. The deeper question is whether the institution understands what it is being asked to disclose.

References

[1] Privacy and Other Legislation Amendment Act 2024 (Cth), Schedule 1, Part 15, inserting APP 1.7, 1.8 and 1.9 into Schedule 1 to the Privacy Act 1988 (Cth). https://www.legislation.gov.au/C2024A00128/latest/text

[2] Office of the Australian Information Commissioner, "New resources on transparency for use of AI and automated decision-making," media release, published 30 September 2026. https://www.oaic.gov.au/news/media-centre/new-resources-on-transparency-for-use-of-ai-and-automated-decision-making

[3] Office of the Australian Information Commissioner, APP 1.7–1.9 Transparency Obligation (fact sheet), 30 September 2026. https://www.oaic.gov.au/__data/assets/pdf_file/0021/269013/APP-1.7-1.9-Transparency-Obligation-Fact-Sheet.PDF

[4] Office of the Australian Information Commissioner, APP 1.7–1.9 Transparency Obligation (compliance flowchart), 30 September 2026. https://www.oaic.gov.au/__data/assets/pdf_file/0019/269011/OAIC-APP-1.7-1.9-Transparency-Obligation-Flowchart.PDF

[5] Office of the Australian Information Commissioner, "Chapter 1: APP 1 Open and transparent management of personal information," APP Guidelines, updated 3 October 2025, section "New obligations about automated decisions from December 2026." https://www.oaic.gov.au/privacy/australian-privacy-principles/australian-privacy-principles-guidelines/chapter-1-app-1-open-and-transparent-management-of-personal-information

[6] Office of the Australian Information Commissioner, Automated Decision-Making Transparency Obligation (APP 1) Issues Paper, May 2026, quoting the Explanatory Memorandum to the Privacy and Other Legislation Amendment Bill 2024 (Cth), paragraphs 335 to 337. https://www.oaic.gov.au/__data/assets/pdf_file/0027/263925/ADM-Issues-Paper.pdf

[7] DataMPowered, ifCEM and the Sovereign Operational Capability Architecture.

[8] DataMPowered, Judgement Governance.

[9] DataMPowered, Judgement Passport.

Platform-maturity statements in this article (guided evaluation and bounded organisational pilots, foundations implemented for eligible governed outcomes, not available for every piece of work, no compliance certification) reflect the canonical capability classifications in DataMPowered's internal ifCEM product-maturity record as at publication, and are not independently assigned.

---

Dakshan Pothuhera
Founder, DataMPowered®