APP 1.7–1.9 from 10 December 2026: what the OAIC's new guidance actually requires

The obligation is not hypothetical and it is not narrow. From 10 December 2026, APP entities must carry specific information about computer program decision-making in their privacy policy. On 30 September 2026 the OAIC republished Chapter 1 of the APP Guidelines as version 2.0, adding a dedicated run of paragraphs on this obligation and publishing a fact sheet, a supplementary fact sheet for government agencies, and a compliance flowchart.

This is not legal advice. It is a reading of published guidance, written to help you plan. The OAIC's own position is that several of these tests turn on facts specific to your systems and your people — reliance and override in practice, whether an outcome differs materially for a vulnerable cohort, and what your contracts actually say. Have your privacy officer or counsel confirm the classification for each program before you publish a disclosure. Where our reading and theirs differ, theirs governs.

This matters more than a routine guidance update, for two reasons. First, the new guidance spells out several tests that most published compliance commentary has either glossed over or got wrong — most consequentially, that human-in-the-loop decisions are frequently in scope, not out of it. Second, it converts the question from "should we disclose something" into "can we evidence it", which is where the actual work sits.

APP 1.7, 1.8 and 1.9 are three different things

The single most common drafting error we see in draft policies is treating these sub-sections as one undifferentiated obligation. They do different work.

APP 1.7 is the threshold test. All three conditions must be met:

• (a) the entity has arranged for a computer program to make, or to do a thing substantially and directly related to making, a decision;
• (b) the decision could reasonably be expected to significantly affect an individual's rights or interests; and
• (c) personal information about that individual is used in the operation of the program.

If any one fails, APP 1.8 does not bite. Note that (b) asks about what you could reasonably expect, judged before the fact — not about how serious the outcome turned out to be.

APP 1.8 is the disclosure list. Once the threshold is met, the privacy policy must include:

• (a) the kinds of personal information used in the operation of such computer programs;
• (b) the kinds of such decisions made solely by the operation of such computer programs; and
• (c) the kinds of such decisions for which a thing that is substantially and directly related to making the decision is done by the operation of such computer programs.

APP 1.9 is definitional. It establishes that making a decision includes refusing or failing to make one, that doing a thing includes refusing or failing to do it, and that a decision may affect rights or interests whether they are adversely or beneficially affected. So "we decided not to renew your policy" is a decision, and a favourable automated outcome is still a decision.

"Meaningful information about the logic" is a different obligation

If your draft policy says APP 1.8 or 1.9 requires you to publish the "meaningful information about the logic utilized" for each decision, that is a misattribution. That phrase belongs to the APP 6 collection-notice obligation, which requires you to advise an individual at the point of collection of the name of the computer program, its purpose, and the meaningful information about the logic utilized. APP 1.7–1.9 is a separate requirement about disclosing categories in the privacy policy. They are two obligations, often triggered together, and conflating them produces a policy that satisfies neither cleanly.

Human-in-the-loop is usually in scope, not out

Published commentary has often suggested that a human decision-maker takes a decision outside the reach of APP 1.7. The OAIC's guidance says otherwise in terms: a decision may be within scope even where a computer program output does not replace the entire decision-making process, or is subject to human review.

The test is whether the program does a thing substantially and directly related to making the decision. "Substantially" means real or of substance, not insubstantial or nominal. "Directly" means directly connected to making the decision. Whether the output is advisory or determinative is one factor, not the test.

The OAIC's worked examples make the boundary concrete:

• Scholarship ranking — the program produces a recommendation, the panel makes the final call and can disregard the ranking. In scope, because the panel actually considers the ranking.
• Loan officer following a risk score — the officer relies heavily on the score and almost always follows it. In scope, with reliance as the deciding factor.
• Marketplace auto-suspension with available override — staff can overturn the algorithm but rarely do because it is considered highly accurate. In scope; nominal override availability does not save it.

The factors the OAIC tells you to weigh are: the degree of reliance on the output, the ability and likelihood of human override, whether the output is advisory or determinative, the transparency and explainability available to the decision-maker, and how deeply the program is integrated into the workflow.

If your organisation has a documented, monitored override rate and a genuine review step, that is evidence you can point to. If the override button is decorative, it is not a defence.

"Arranged for" does not stop at your own systems

This is where vendor procurement matters. Computer program takes its ordinary meaning and is read broadly — pre-programmed rule-based processes, AI and machine-learning models, and generative AI tools including chatbots all fall within it.

Under APP 1.7(a), "arranged for" covers the case where a program is operated by one entity but a different entity is responsible for arranging for it to make the decision. The OAIC's non-exhaustive list includes:

• procuring an AI system to screen and rank job applications;
• permitting or directing employees to use an AI chat tool to draft performance assessments that determine promotion decisions;
• contracting a third-party software company to approve or decline refunds automatically; and
• operating a case management system that automatically escalates certain complaint types.

So the obligation stays with you, the APP entity, not the vendor — and a contract does not move it. The OAIC expects entities to identify, assess and keep oversight of third-party programs both during and after procurement, and to ensure contractual arrangements are clear about which party retains ultimate decision-making capability or judgement. That is a procurement-diligence obligation, not just a privacy-policy drafting one.

What counts as significantly affecting rights or interests

"Significantly" means more than trivial, with the potential to considerably influence the individual's circumstances. It is not limited to adverse outcomes — a beneficial effect is still in scope (APP 1.9(c)).

Rights and interests the OAIC treats as generally in scope include access to:

• essential banking and credit services
• healthcare, emergency and aged care (including in-home services)
• housing, and essential food and nutrition
• employment opportunities
• educational services
• essential utilities and telecommunications
• financial assistance, and physical assistance or support

Two points are worth internalising. First, the individual's circumstances change the analysis. The same suspension decision can be trivial for one customer and significant for a customer relying on the service to reach medical appointments or maintain employment. Children, people from low socio-economic backgrounds, Indigenous Australians and people with a disability are specifically called out. If a program produces an output that is materially different for a vulnerable cohort than for the general population, the decision should be taken to significantly affect rights or interests.

Second, the scope extends beyond statutory benefits and contractual rights to things like personalised pricing that limits access to significant goods or services, and to targeted advertising that produces differential outcomes.

How much detail is enough

The OAIC is explicit that this is a proportionality exercise, not a disclosure dumping ground. Information should be articulated in plain language, structured so an individual can ask for more, sufficiently specific to be meaningful without overwhelming, grouped logically, and framed so the information and the decision can be challenged or contested.

Two practical allowances work in your favour:

• Grouping is expressly permitted. You may group categories of decisions and types of personal information rather than separating out each program. The OAIC's own example describes an entity using a range of fraud-prevention technologies processing identity, geolocation, biometric and IP data to permit, flag or deny account access — described as a range, not program by program. But keep the grouping meaningful to a reasonable person, and articulate clearly where more sensitive information (health information, biometric templates) feeds a decision.
• Commercial-in-confidence information is excluded. The obligation does not require disclosure of genuinely commercially sensitive information or trade secrets. The OAIC warns this is a narrow exclusion — a benefit from using a program is not commercial-in-confidence unless releasing it would harm your commercial interests, and the mere commercial value of a system is not enough.

A layered policy — a condensed summary up front, linking to the full detail — is explicitly endorsed and fits both this obligation and the broader APP 1.3 duty to have a clearly expressed policy that is easy to navigate.

The part that is not drafting

A privacy policy is a set of statements about categories. What an auditor or regulator tests is whether you can produce the underlying evidence for a specific decision when asked. That is where most organisations are exposed, because a policy written in October 2026 describes programs whose historical decision records cannot be produced.

That is the whole argument for a tamper-evident log, and it is the argument we make throughout this site. Each decision is:

1. Signed with your organisation's own key — you hold the root of trust, not a third party.
2. Sealed in a hash chain — each content hash bound to the one before it, so any after-the-fact edit is detectable.
3. Optionally time-stamped by an independent RFC 3161 authority — proving when the decision was signed, outside your control.
4. Retained under a policy that supports verifiable erasure — content removed while the chain anchor is preserved for integrity.

Together these let you answer, for a named decision: what personal information was used, which model version and system produced it, whether a human was involved and who, what the outcome was, and whether the record has since been altered. Verified offline against your published key, with no account and no trust in the vendor.

Note the last point carefully in a procurement conversation. Where evidence lives only inside a vendor's platform, you do not own the audit trail — the same administrators who can alter production logs can alter the evidence. See Vendor-neutral assurance for the sovereignty test we use.

A rollout that fits the deadline

Ten weeks is enough, but only if the inventory starts now.

1. Inventory the programs, not the projects. List every system that makes, or substantially and directly supports, a decision about a person: rules engines, scoring models, triage tools, and the generative AI tools staff are already using informally. Informal usage is the usual blind spot.
2. Assess each against the three APP 1.7 conditions, and where it passes, against the three APP 1.8 limbs. Record the reliance and override facts while you can still interview the people who know them.
3. Check the vulnerability angle — whether outcomes differ materially for a cohort. If they do, the decision is in scope regardless of how it looked in aggregate.
4. Reconcile third-party arrangements. Confirm in writing, per vendor, who retains ultimate decision-making capability, and put a change-of-use notification obligation in the contract.
5. Draft the disclosure as groups, following the grouping allowance, with a layered summary. Flag anything you are excluding as commercial-in-confidence and be able to justify each exclusion.
6. Prove you can evidence it. Pick ten decisions that already happened and produce the record for each. If you cannot do that today, no policy wording will hold.
7. Rehearse the six APP 1.2 practices: risk identification across the information lifecycle, security controls and audit trails, a Privacy Impact Assessment for new projects, breach and complaint procedures, governance ownership, and staff training on how the APPs apply to what you actually do.

A useful discipline here is a Privacy Impact Assessment for each in-scope program. The OAIC names it in its APP 1.2 examples, and the documentation it produces is usually most of what you need for the disclosure anyway.

If you are evaluating tooling rather than building, the questions to put to a vendor before the deadline are collected in Twelve questions to ask an AI decision vendor before 10 December 2026. If you already know you are buying, the broader map is What solutions exist for creating evidence trails of AI decisions.

Where Decision Keep fits

Decision Keep is the evidence layer, not the decision maker. It records decisions your organisation has already made and gives you evidence that cannot be quietly rewritten — which is what lets the statements in your privacy policy be true by the time an auditor asks.

The disclosure your privacy policy makes is a claim about categories. The receipt behind it is what makes the claim verifiable. For the broader control framework mapping, see Audit-ready AI: how GRC teams prove every automated decision; for how the records support subject access requests and privacy-policy drafting under GDPR Art. 22, see What legal and compliance teams need to know about AI decision records.

If you want the board-facing version of the same evidence, the 1-page board AI evidence checklist is the shortest form of the argument.