From 10 December 2026, Australian Privacy Principle (APP) 1.7 requires an APP entity to disclose, in its privacy policy, when a computer program uses a person’s personal information to make, or substantially and directly help make, a decision that could significantly affect that person’s rights or interests. APP 1.8 lists what the policy must say. APP 1.9 confirms that refusals, failures to decide, and beneficial as well as adverse outcomes all count.
This article explains the published instruments and guidance. It is not legal advice. Readers should seek advice from their own legal advisers about how APPs 1.7–1.9 apply to their organisation.
A shortlist the privacy policy cannot prove
In late October 2026, the people-and-culture lead at a mid-market Australian insurer asked her privacy officer a short question. A claims manager had connected an assistant to the human-resources information system three months earlier. The assistant now drafts shortlists from candidate profiles. The privacy officer was rewriting the APP privacy policy for 10 December and needed to know which personal information the assistant actually used.
The HR system log showed an integration user. It did not show which assistant ran, which candidate fields were read, or which shortlists were produced from which records. The policy paragraph would have been a guess. That is the gap this article names as the provable disclosure: a privacy-policy statement that can be backed by a record of which caller used which personal information, and that can be updated when the callers change.
What do APPs 1.7–1.9 require from 10 December 2026?
They require a privacy-policy disclosure, not a new right to object, and not an individual explanation of each decision.
The provisions were inserted into APP 1 by Part 15 of Schedule 1 to the Privacy and Other Legislation Amendment Act 2024 (No. 128, 2024). That Part commences on 10 December 2026. The object of APP 1 remains that APP entities manage personal information in an “open and transparent way”.
APP 1.7 applies when three conditions are all met:
- the entity has arranged for a computer program to make a decision, or to do a thing that is substantially and directly related to making a decision
- the decision could reasonably be expected to significantly affect the rights or interests of an individual
- personal information about that individual is used in the operation of the computer program to make the decision or do that thing
If those conditions are met, APP 1.8 requires the APP privacy policy to include:
- the kinds of personal information used in the operation of such computer programs
- the kinds of such decisions made solely by the operation of such computer programs
- 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 fills in the edges. Making a decision includes refusing or failing to make one. A decision may affect rights or interests whether the effect is adverse or beneficial. Statutory examples include granting or refusing a benefit under an Act, affecting rights under a contract, and affecting access to a significant service or support.
The amendment applies to decisions made after 10 December 2026 even if the arrangement or the personal information predates that day.
Allens, writing after the OAIC’s 30 September 2026 guidance, put the legal character in one sentence: “This is a transparency measure only.” It does not create a right to contest the decision or a duty to notify each affected individual.
Which organisations are covered by the Privacy Act change?
APPs 1.7–1.9 apply to APP entities: Australian Government agencies and organisations covered by the Privacy Act 1988.
Private-sector and not-for-profit organisations with annual turnover above $3 million are generally covered. Small businesses at or below that threshold are usually not, unless an exception applies: health service providers that hold health information, businesses that trade in personal information, Commonwealth contracted service providers, credit reporting bodies, certain Anti-Money Laundering and Counter-Terrorism Financing (AML/CTF) reporting entities, Consumer Data Right accredited entities, related bodies, or those that have opted in. Johnson Winter Slattery notes the obligation applies to every APP entity, including agencies. State and territory authorities are generally outside the Act unless a specific arrangement brings them in.
Coverage is a legal question. The rest of this article assumes the reader is, or advises, an APP entity.
Does APP 1.7 apply to rule-based tools, not just AI?
Yes. The trigger is a computer program, not an artificial intelligence system.
The OAIC’s APP 1.7–1.9 fact sheet lists what a computer program includes: “pre-programmed rule-based processes”, artificial intelligence and machine learning, ordinary software and apps, and generative AI including chatbots. Johnson Winter Slattery summarises the same point: “Even a spreadsheet formula used to rank individuals may be caught.”
The OAIC’s worked example is a health provider that scores clients in a spreadsheet and uses the ranking to decide who to contact. Staff still make the call. The ranking is still in scope because it determines who receives a significant service.
Human review does not automatically take a tool out of scope. The OAIC treats a program as substantially related when its output is a key factor in the human’s decision, and directly related when it has a direct connection to that decision. Machine-learning or generative-AI outputs used in significant decisions generally stay in scope unless there is extensive human oversight and control.
“Arranged for” is wider than a formal procurement. It includes in-house software, purchased products, configured off-the-shelf tools, and reliance on advisory outputs. JWS adds that permitting employees to use an AI chat tool to draft performance assessments that then decide promotions can be an arrangement.
How do AI agents calling CRM, HR and finance APIs create ADM exposure?
They create it when the agent’s output is a key factor in a significant decision and the agent used personal information about the affected individual to produce that output.
The OAIC’s in-scope examples already sit on those systems: recruitment software that sorts candidates, programs that approve or reject credit, programs that assess insurance eligibility, and reports that rank employee performance. The computer program is often no longer a single vendor workflow. It is an assistant, a desktop agent, or a Model Context Protocol (MCP) client that calls the same APIs an employee would call.
Someone in claims, finance or people-and-culture connects an assistant to Salesforce, Workday or Xero. A manager asks it who to shortlist, who to offer a payment plan, or whose claim to escalate, and accepts the recommendation. Personal information was used. The decision can significantly affect the individual. APP 1.7’s three limbs can all be present.
Vendor documentation describes what the CRM can return. It does not describe what this assistant did return, or whether a second unofficial agent is now calling the same API with a wider token. An inventory of “AI tools we bought” is not an inventory of ADM. The decision sits at the call.
How can you evidence which automated system used which personal information?
You evidence it with a record at the hop where the personal information actually moves: the outbound API call.
Mapping programs and updating the policy produces a disclosure. It does not produce proof. The HR log in the opening scenario named an integration user. It could not name the assistant or the fields. A vendor exhibit lists categories the product may process, not what a particular agent was allowed to read this week.
The provable disclosure is a privacy-policy statement tied to that call-level record. For each in-scope decision type, the organisation should be able to show:
| What APP 1.8 asks | What a call-level record can show |
|---|---|
| Kinds of personal information used | Which endpoints and fields each caller was allowed to read, and which were redacted before the caller received them |
| Decisions made solely by a computer program | Which callers are permitted to write or to trigger an outcome without a human step |
| Decisions a program substantially and directly helped | Which callers may read or recommend, under which credential, against which target |
“The CRM integration used personal information” is not the same as “the shortlisting assistant used name and work history, and was blocked from health fields.” When a caller is added or its scope changes, that record is what keeps the policy current. It does not replace legal review. It gives counsel facts they can disclose with.
What practical steps should privacy and IT leaders take before 10 December?
Inventory the agents and integrations, map the personal information each one can touch, enforce that map, keep the evidence, and redact what the agent does not need.
The OAIC and the law-firm notes already recommend an ADM audit, vendor follow-up, and a policy update. The list below adds the outbound-call steps those pages leave out.
- Inventory callers, not only products. List assistants, desktop agents, MCP clients, scripts and integration users that call CRM, HR or finance APIs, including unofficial tools staff have been permitted to use.
- Map decisions to those callers. Record the decision types each one can influence: shortlisting, credit variation, claim triage, performance ranking, access to a significant service.
- Map the personal information each caller can see. Start from the API the caller hits. Note sensitive classes such as health or biometric data.
- Decide scope per caller. Write the limit as a rule on the call, not as a paragraph in a prompt.
- Redact what the decision does not need. If the API returns a full contact record, remove fields before they reach the model. See how to redact personal information from API responses.
- Keep evidence of each call. Record which caller, which target, which path and method, and whether the call was allowed or blocked.
- Refresh the policy when callers change. A new agent or a wider token is a policy event. Managed-service teams packaging this as a repeatable assessment should treat the inventory as a living register.
Commercial-in-confidence information about the program itself is excluded from APP 1.7. Embarrassment is not a commercial-in-confidence reason.
Where RequestRocket fits
RequestRocket is complementary to the identity, legal and privacy-policy work APP 1 already assumes. Identity tells you who the caller is. Counsel decides what the policy must say. RequestRocket sits on outbound calls to APIs the organisation does not host.
It holds the real API credential so the agent never sees it. Rules decide which endpoints, methods and request shapes a given caller may use. Filters can remove fields or rows from the response before they reach a model. Every call leaves an audit record: which caller, which target, what was allowed or blocked. That is the evidence layer of the provable disclosure. It does not write the privacy policy.
The same path is what outbound API governance describes as the control gap between identity and access management (IAM), inbound gateways and secrets managers.
FAQ
Does APP 1.7 create a right to object to automated decisions?
No. Allens describes it as a transparency measure only. It requires specified information in the APP privacy policy. It does not give a right to contest the decision. Other laws may still provide review rights.
Does a human reviewer take an AI agent out of scope?
Usually not. The OAIC treats a program as in scope when its output is a key factor with a direct connection to the decision, including advisory output. Generative-AI outputs used in significant decisions stay in scope unless there is extensive human oversight and control.
Do APP 1.7–1.9 apply only to systems built after 10 December 2026?
No. The amendment applies to decisions made after commencement, even if the arrangement for the program, or the use or collection of the personal information, happened earlier. Existing agents and integrations are in the first inventory.
What if a vendor will not say how its product uses personal information?
The disclosure duty typically sits with the APP entity that uses the personal information to make or help make the decision, not with the vendor. The OAIC expects vendors to give high-level information so the entity can write the policy. JWS recommends writing that duty into vendor contracts.
Is updating the privacy policy enough on its own?
The legal obligation in APP 1.7–1.8 is to include the specified information in the policy. A policy that names kinds of personal information the organisation cannot evidence will not stay accurate as agents change. The provable disclosure is the policy plus the call-level record that supports it.
Do we have to name every AI product in the policy?
The OAIC allows grouping of decision categories and types of personal information, so long as the detail is meaningful to a reasonable person. Sensitive classes such as health information or biometric templates should be clear. The right grouping still depends on a complete inventory of callers.
Book a walkthrough of RequestRocket
Sources
- OAIC, Chapter 1: APP 1 – Open and transparent management of personal information (updated 30 September 2026)
- OAIC, APP 1.7–1.9 Transparency Obligation Fact Sheet (September 2026)
- OAIC, Automated Decision-Making Transparency Obligation Issues Paper
- Privacy and Other Legislation Amendment Act 2024 (Cth) No. 128
- OAIC, Small business
- OAIC, Chapter B: Key concepts
- Allens, Mandatory automated decision-making disclosure requirements are coming (2 October 2026)
- Johnson Winter Slattery, ADM disclosure obligations: key takeaways from the OAIC’s guidance (22 October 2026)