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 searching for the AI nobody registered. You can start in a spreadsheet today. This guide walks the practical build, the fields that earn their place, how to find the systems no one logged and how to keep the record true once it exists.

Why the register comes first

Almost every other piece of AI governance reads from the register. A risk assessment needs to know which system it is assessing and who owns it. A policy needs to know which systems it applies to. An incident response needs to know what the affected system does and who to call. A regulator, auditor or customer who asks what AI you use expects one answer, not a different list from each team.

The frameworks say the same thing. The NIST AI Risk Management Framework asks for mechanisms to inventory AI systems under GOVERN 1.6. ISO/IEC 42001 begins with defining the scope of the AI management system, which means knowing which AI systems it covers. Laws that regulate particular uses of AI, from the EU AI Act’s high-risk categories to Australia’s Privacy Act rules on automated decisions, can only be applied once you know which systems you run.

The register earns its place by being the living record everything else stays true against, every time a system is added or changed. A list built once for a deadline and filed away goes stale the moment the next system ships.

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. Think of a tool that ranks job applicants, a model that triages claims, a feature that routes complaints or sets a price, or an assistant staff use to draft customer replies. Include the tools your teams brought in themselves, because your accountability 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 governed. 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 record holds the same fields, so you can read across it and filter it. 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 data that feed it, in plain terms, and whether personal information is among them.
• Decides or supports decisions about people. Whether the system makes the decision itself, supports a person who makes it or does neither. Many legal duties turn on this field, 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.
• Status. Proposed, in development, testing, live or retired. A register that only shows live systems misses the one going to production next month.

Keep the records 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 you, or a tool, run assessments and checks across the register later without 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 system affects people 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, such as a chatbot, a screening tool or 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.

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. Asking only gets you what people remember, so where you can, check the traces the systems leave as well. How to find shadow AI in your organisation covers where those traces sit and how to read them.

Step 4: 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 before 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 every assessment, policy and disclosure built on it goes wrong with it.

Three habits keep it true. Save a new version of each record when something material changes, such as a new model, a new data source or a wider use, so you can say what the system looked like on a given date. Give every record a named owner who is prompted when the record needs attention. And re-run the search from Step 3 on a schedule, because shadow AI keeps arriving.

What the register feeds

Once the register exists, you can work out which systems need more. Systems that affect people need a risk or impact assessment, systems that carry risk need controls and guardrails, and some need a disclosure because the law requires one.

In Australia, that last step has a date. From 10 December 2026, APP 1.7 to 1.9 require the privacy policy to set out the kinds of decisions computer programs make, or substantially and directly help make, where those decisions could significantly affect individuals. The classification of which registered systems fall in scope, and how to reconcile them against the policy, is set out on the Privacy Act automated decision-making page.

How Aicura fits

Aicura is an AI governance platform, and the register is its free starting point rather than the whole of the work. Discovery connects to sources such as device management tools, code repositories, an IT asset register and cloud asset inventories, and reports the AI already in use. A person decides whether each item is added, linked to a system already listed or ignored. A library of known products fills in common systems so they are not typed from scratch, and a downloadable helper document lets a team gather the details before entering them. Each record keeps a new version when it changes, owners are named over time, and from Essentials registering a system starts its risk assessment.

Aicura holds the record and prompts the work. It does not decide which of your systems are in scope of a law or certify that the register is complete. Those calls stay with you.

---

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: NIST AI Risk Management Framework (AI RMF 1.0), GOVERN 1.6