APP 1.7 starts on 10 December 2026. Here is the engineering evidence an automated-decision disclosure needs

I work at Permit, and this is based on a post our CEO wrote for our blog, so read it with that in mind. It's also not legal advice. Privacy counsel decides the wording and the scope.

From 10 December 2026, APP 1.7 under Australia's Privacy Act changes what some privacy policies have to say. It applies when an APP entity arranges for a computer program to make a decision, or to do something substantially and directly related to making one, where the decision could significantly affect a person's rights or interests and personal information about that person is used in the program. In that case the privacy policy has to describe the kinds of personal information used and the kinds of decisions involved, split into decisions the program makes on its own and decisions it substantially assists.

A few details from APP 1.9 and the OAIC that engineers tend to miss:

• Refusing or failing to make a decision counts as making one.
• It applies whether the outcome is good or bad for the person.
• It isn't limited to AI. Rules engines, scoring systems, workflow automation and agents can all be in scope.
• It covers decisions made from 10 December 2026, no matter when the system was built or the data was collected.

Why this lands on engineering

Legal writes the policy, but they can only describe what you can show them. If nobody knows which services and agents read which personal data on a decision path, "the kinds of personal information used" ends up as a guess.

The post's homework list, shortened:

1. Inventory every program, workflow and agent that makes, refuses, routes or substantially assists a significant decision. Include rules engines and fraud workflows along with models. Record the owner, whether it decides alone or assists, what personal information it uses, and how it's enforced and logged today.
2. Map kinds of personal information to concrete resources and actions, like transactions.read or service_access.refuse. "The risk service can read customer data" is too vague to disclose against.
3. Put enforcement points in two places: before anything reads personal information, and before a system approves, refuses, routes or escalates.
4. Write policy at that level. Can this workflow use data for triage but not for a refusal? Can this model recommend a review but not decide?
5. Keep authorization data in sync. When an agent gets a new tool or a workflow adds a data source, slow permission updates mean your evidence describes an older system.
6. Keep decision logs with identity, resource, action, policy, tenant, time and result, so the policy statement rests on production facts instead of interviews.

There's also a section on APRA's April 2026 letter on AI, which raises related themes (IAM for agents and other non-human actors, privileged access to tools and models, AI inventories). That's parallel pressure for APRA-regulated entities. APP 1.7 itself isn't an APRA requirement.

The full post has a 90/60/30-day countdown to 10 December and covers where Permit fits: 10 December 2026: APP 1.7 and the authorization evidence behind automated decisions