How to work out which of your systems make automated decisions

To work out which of your systems make automated decisions, you list every system that touches a decision about a person and test each one against two questions. Does a computer program produce or substantially help produce the decision, and could that decision reasonably be expected to significantly affect the individual. A system that meets both is in scope. This guide makes those two tests concrete, walks you through triaging your own system list and shows you where the grey areas sit.

The reason to do this carefully is that the most common reading of the rules is the wrong one. Many organisations decide they are out of scope because they do not think of themselves as using AI. The Privacy Act does not turn on whether you use AI. It turns on whether a computer program is involved in a decision, and that is a far wider net.

Why most organisations underestimate their scope

From 10 December 2026, Australian Privacy Principle 1.7 to 1.9 require organisations to set out in the privacy policy the automated decisions they make that significantly affect people. The obligation is written around the term “computer program”, not “artificial intelligence”. That choice is what trips people up.

A computer program, for this purpose, is any coded logic that produces an output. It covers a machine-learning model, and it equally covers a set of if-then rules, a scoring sheet, an eligibility calculator and a formula in a spreadsheet. If a person feeds in details at one end and a result comes out the other that was produced by the logic rather than by a person weighing it up, a computer program made or shaped that decision.

So the question to ask of your estate is not “where do we use AI”. It is “where does coded logic produce or substantially shape a decision about a person”. Once you frame it that way, systems you had not thought of as decision-makers come into view.

The two tests, made concrete

A system is in scope when it clears both tests below. Work through them in order, because the first one is where the breadth lives and the second is where the judgment lives.

Test one: is a computer program producing or substantially shaping the decision

This is the wide net. Read it as covering more than machine learning.

Each of these counts as a computer program producing or shaping a decision.

• A credit or risk score generated by a model.
• A rules engine that approves or declines an application against set criteria.
• An eligibility check that decides whether someone qualifies for a service, a concession or a hardship arrangement.
• A spreadsheet that takes a person’s inputs and returns a ranking, a price or a pass or fail.
• A third-party tool that shortlists, prices or flags people, including one a team adopted without central sign-off.

The phrase to hold on to is “substantially shapes”. A decision does not have to be fully automated to count. If a computer program produces the result that a person then signs off with little or no change, the program substantially shaped the decision and the system is still in the frame.

Test two: could the decision reasonably be expected to significantly affect the individual

This is the threshold that separates a decision that matters to a person from one that does not. The standard is whether the decision could reasonably be expected to significantly affect the individual, so you are judging the effect on the person, not the cleverness of the system.

These decisions generally clear the threshold.

• Whether someone is approved for a loan, an account or insurance, and on what terms.
• The price or premium a person is offered, where it changes what they can access.
• Whether a job applicant is shortlisted or screened out.
• Whether a person qualifies for a benefit, a concession, a hardship measure or a service.
• Whether a claim, an application or a complaint is accepted, declined or escalated.

These decisions generally do not.

• Routing an enquiry to the right internal queue, where the routing has no effect on the outcome for the person.
• Sorting or de-duplicating records for staff convenience.
• A spell-check, a formatting tool or an internal dashboard that informs staff but decides nothing about a person.

The test is “reasonably be expected”, which means you weigh the likely effect, not the worst case you can imagine. A decision with a real bearing on a person’s money, work, rights or access to a service sits inside the threshold. A decision that only changes how staff handle their own workload sits outside it.

A hands-on triage walkthrough

Here is the work, applied to a list you can build for your own organisation. A spreadsheet with a row per system is enough.

Step 1: Pull together the full list of systems that touch a decision

List every system, tool and process that produces or shapes a decision about a person. Walk each team rather than relying on a central software list, because the systems that matter are often the ones a team brought in to solve its own problem. Include spreadsheets and manual rules, not only named applications. Cast wide here. It is cheaper to record a system and set it aside than to miss one.

Step 2: Test each system against the breadth of “computer program”

For each row, ask whether a computer program produces the decision or substantially helps produce it. Mark the ones where coded logic, of any kind, is doing the deciding. This is where you catch the scoring sheet and the eligibility spreadsheet that a “do we use AI” question would have skipped straight past. Set aside, for now, any system where a person reaches the decision unaided and the tool only stores or displays information.

Step 3: Test each decision against the “significantly affect” threshold

For the systems that cleared step 2, ask whether the decision could reasonably be expected to significantly affect the individual. Use the two lists above as your reference points. Write the effect down in plain words next to each system, for example “decides loan approval” or “sets insurance premium” or “routes ticket, no effect on customer”. The effect you write is what justifies the call.

Step 4: Sort each system into flag, set aside or grey

Put each system into one of three piles.

• Flag. Clears both tests. A computer program produces or shapes the decision, and the decision significantly affects the individual. These are the systems your privacy policy has to address.
• Set aside. Clearly fails one test, with no computer program in the decision or no significant effect on a person. Keep these on the list with a one-line reason, so the next person to review knows why they were excluded.
• Grey. A genuine close call. Record it, note your reasoning and treat it as in scope until you have a basis to move it out.

Step 5: Move the flagged and grey systems into your register, and redo this as the estate changes

Record the flagged and grey systems in your AI Register, which is the standing record your privacy policy is reconciled against. Then treat this triage as something you repeat. Scope is not a fixed list. The next tool the business adopts might cross the threshold, and a system that was borderline today can become clearly in scope when its role grows. Tie a quick rerun of these tests to the moment a system goes live or changes materially.

The grey areas, and how to handle them

Most lists produce a handful of cases that do not sort cleanly. These are the common ones.

• A human signs off the output. The question is whether the person genuinely weighs the decision or mostly endorses what the program produced. If the program’s result is followed almost every time, treat the decision as substantially shaped by the program and flag it.
• A flag that triggers a manual review. A fraud or risk flag that only routes a case to a human for a full decision is closer to set aside, but if the flag itself restricts a person’s access while they wait, the effect on the person can pull it back in. Note both sides of it.
• A recommendation rather than a decision. A tool that ranks or recommends, where a person then decides, can still substantially shape the outcome if the ranking drives what happens. Judge it by influence on the result, not by what the tool is called.
• A low-stakes decision at scale. A single low-impact decision may not clear the threshold, but if the same automated decision affects access for a large group, look again at whether the effect is significant.

When you cannot resolve a grey case, leave it flagged and write down your reasoning. That note is what you reconsider at the next review, and it is the concrete thing to hand an adviser if you take advice on the close calls.

Where Aicura fits

Once you have sorted your systems, you need somewhere to record them and a way to keep the sorting current as the estate changes. That is the work Aicura is built around. Aicura is your AI Register, and it scans your privacy policy against the ADM rules and surfaces which automated-decision systems are not yet disclosed. The classification and the reconciliation are generated, not analyst-built, so they can run again each time a system is added or changed rather than waiting for the next manual review.

The deadline is the reason to triage your systems now. Keeping that triage true as the organisation grows is the work that continues after, and it is what a living register exists to handle.

Where to go next

Read the framework page on automated decision-making for how APP 1.7 to 1.9 define a decision that significantly affects a person, and the AI inventory scenario for how an organisation finds these systems spread across its teams and tools. When you have your list of in-scope systems, the companion guides take you the next two steps. Use How to build an AI system register to record what each system decides, and How to write an ADM transparency statement to set out the flagged decisions in your privacy policy.

---

Related frameworks

• Automated decision-making under the Privacy Act — How APP 1.7 to 1.9 define an automated decision that significantly affects a person, and why the scope is wider than AI.
• The 10 December 2026 deadline — What commences on 10 December 2026 and what your privacy policy has to say from that date.

Related scenarios

• Build and maintain your AI inventory — How an organisation finds the automated-decision systems spread across its teams and tools.

---

A note on this page

This guide explains what the rules require and how to do the work. It is general information, not legal advice. How the obligations apply turns on your own circumstances, so read the primary source and take your own advice before you rely on it.

Aicura does not certify, audit or issue a compliance verdict, and it does not produce a score. That decision belongs to your organisation and its people.

Primary source: Privacy Act 1988 (Cth), Australian Privacy Principle 1.7 to 1.9 and the OAIC's APP guidelines