How to build an AI system register

You build an AI system register by listing every system that uses AI or automation to make or support a decision, capturing the same fields for each one, then flagging the systems whose decisions significantly affect a person. Those flagged systems are what your privacy policy has to disclose from 10 December 2026. You can start in a spreadsheet today. This guide walks the practical build, the fields that earn their place, how to find the AI nobody registered, how to classify automated decisions and how to keep the record true once it exists. It is a job a lean compliance team can run themselves, the do-it-yourself version of work a consultant would otherwise bill by the hour.

Why you are building this now

The trigger is the deadline. From 10 December 2026, Australian Privacy Principle 1.7 to 1.9 require organisations to set out in the privacy policy the automated decisions that significantly affect people. You cannot write that disclosure from memory, because the systems that make those decisions are spread across teams and some of them sit inside tools a team adopted without telling anyone. The register is how you find them and write them down before you draft the policy.

The deadline gets you to the register, but it is not what the register is for. A privacy policy written once goes stale the moment the next automated-decision system ships, and the register that was filed away with it goes stale too. The register earns its place by being the living record your disclosure stays true against, every time a system is added or changed. You build it for December, and you keep it for the systems that come after.

Step 1: List every system that makes or supports a decision

Start broad and walk your operations, listing every system that uses AI or automation to make or support a decision, not only the systems that sound like AI. Credit scoring and fraud flagging are the obvious ones. The quieter ones matter as much, a tool that ranks job applicants, a model that triages claims, a feature that routes complaints or sets a price. Include the tools your teams brought in themselves, because the obligation does not stop at software you built.

It is easier to record a system now and decide later that it falls out of scope than to miss one that should have been disclosed. Cast wide on this pass and narrow on the next.

Step 2: Capture the same fields for each system

A register is only useful if every entry holds the same fields, so you can read across it and reconcile it against the policy. Capture these for each system.

• System. What it is called and a plain line on what it does.
• Purpose. The decision or task it exists to perform.
• Owner. The person or team accountable for it inside your organisation, not the vendor.
• Data used. The kinds of personal information that feed it, in plain terms.
• Decides or supports decisions about people. Whether the system makes the decision itself, supports a person who makes it or does neither. This is the field the December obligation turns on, so record it carefully.
• Vendor. Who supplies it, or in-house if you built it. Embedded features are easy to miss here, so name the parent product as well as the feature.
• Lifecycle status. In use, in trial, being retired or proposed. A register that only shows live systems misses the one going to production next month.

Keep the entries plain. The register is a working record, not a report, and the value is in it being complete and current rather than polished. Capturing the same fields each time is also what lets a tool reconcile it against the policy later without you re-reading every line.

Step 3: Find the AI nobody registered

The systems you already know about are the easy half. The risk sits in shadow AI, the systems no one logged centrally, because a decision that significantly affects a person counts toward your disclosure whether or not anyone wrote it down. Four places are worth a deliberate search.

• Embedded vendor features. AI that arrived inside a product you bought for something else. A CRM that scores leads, an HR platform that ranks candidates, a payments tool that flags transactions. The feature was switched on without a separate purchase, so it never reached a register.
• Spreadsheet models. A scoring or eligibility model someone built in a spreadsheet and now relies on. It is automation that affects people even though it never looked like software.
• Point solutions. A single-team tool bought to solve one problem, a chatbot, a screening tool, a pricing engine, sitting outside any central inventory.
• Recent procurements. Read the last year or two of purchases and renewals against your draft register. Anything that touches decisions about customers, staff or applicants is worth a second look.

The way to surface shadow AI is to ask the teams, not the systems. Ask each team what tools they use to decide or sort anything about a person, and treat embedded features as in scope until you have ruled them out. The AI inventory scenario linked below walks a full version of this search.

Step 4: Classify which systems significantly affect people

Not every system on the register reaches the disclosure obligation. The test that matters is whether the system makes an automated decision that significantly affects a person. Work through the flagged column from Step 2 and apply two questions to each one.

First, is the decision substantially automated. A decision the system makes on its own, with no person reviewing it before it takes effect, is automated. A decision a person genuinely reviews and can overturn is supported rather than made, and the degree of that involvement is what you recorded in Step 2.

Second, does the decision significantly affect the person. A decision that changes whether someone gets a loan, a job, an insurance payout or access to a service generally clears that bar. A decision that sorts an internal queue with no effect on a person generally does not. Where a system sits between the two, note your reasoning beside it rather than leaving the call unrecorded.

This classification is also where an impact-assessment habit helps. CSIRO’s responsible AI work, including the AI6 transparency and impact-assessment practice, frames the question as understanding who a system affects and how before you rely on it. Recording that reasoning in the register gives you something concrete to hand an adviser if you take advice, and something to revisit when the system changes.

Step 5: Reconcile the register against your privacy policy

Read the systems you classified as significantly affecting people against your current privacy policy. For each one, check whether the policy says the decision is made, what kind of personal information feeds it and what it is used for. Note every automated decision that is not yet set out. That list is the distance between what your organisation does and what it has disclosed, and closing it is the point of the build.

This is the step that does not stay done, because every reconciliation is true only for the systems you have today.

Step 6: Keep the register current as systems change

Tie the register to your change process. Set the point where a new or altered system is added to the register the moment it goes live, the same way a new supplier reaches your contracts list or a new asset reaches your asset register. A register that is only built once becomes wrong as soon as the next system ships, and the privacy policy built on it goes wrong with it.

This is the durable point. The 10 December 2026 obligation is the start, not the finish. Every new or changed automated-decision system has to make it onto the register and into the disclosure, or the two drift apart and the policy you worked hard to get right goes stale. That is why the register belongs in something built to hold it over time rather than a spreadsheet that ages between reviews.

Aicura is built for that sustaining work. It ships a prefill catalogue so common systems are not typed from scratch, and a Helper PDF you can use to collect entries offline before they reach the register. Aicura is your AI Register, so it scans your privacy policy against the ADM rules and surfaces which automated-decision systems are not disclosed, keeping the register versioned and reconciled against the policy as systems are added and changed. The work is generated, not analyst-built, which is what lets the reconciliation run again each time something changes rather than waiting for the next review. It is the standing version of the consultant’s one-off inventory, kept current instead of filed away.

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 a worked version of the search in Step 3 and the close calls in Step 4. When you are ready to put your own systems and dates against the obligation, the primary source below is where it is set out.

The classification practice in this guide draws on CSIRO’s responsible AI work, including the AI6 transparency and impact-assessment pattern.

---

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 what the privacy policy has to set out from 10 December 2026.
• The 10 December 2026 deadline — What commences on 10 December 2026 and what the privacy policy the register feeds has to say from that date.

Related scenarios

• Build and maintain your AI inventory — A worked walk through finding the systems an organisation runs and deciding which ones reach the register.

---

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, and the OAIC's APP guidelines