The MAS AIRG AI Inventory: The 11 Fields It Must Contain

MAS's proposed Guidelines expect every financial institution to keep an accurate, up-to-date inventory of its AI use cases, systems and models (paragraph 3.4). Paragraph 3.5 lists the key attributes each entry should capture, including purpose and description, approved scope of use, model type, data used, dependencies, lifecycle status, risk materiality rating, validation status, key roles, and links to documentation. This guide expands that illustrative list into eleven practical fields.

A list of tools in a spreadsheet is not an inventory in the Guidelines' sense. Paragraphs 3.4 and 3.5 of the proposed text describe a maintained record capturing key attributes for every AI use case, system or model. The paper frames its attribute list as illustrative, but capturing them is the expectation, and the list is specific. Here is what that means in practice, field by field.

The eleven fields, one by one

1. Name and description

Each AI use is identified and described in plain terms: what the system is and what it does. This sounds trivial until a firm tries it and discovers that nobody can say precisely how many AI tools are in use, because staff copilots, vendor-embedded models and analytics engines were never counted as AI. The Guidelines' definition covers systems that generate predictions, recommendations, decisions or other outputs, including third-party tools.

2. Purpose and use case

Not just what the AI is, but what it is used for and in which business process. One model can serve several uses, and each use carries its own risk. The inventory records them separately, because materiality is assessed per use, not per tool.

3. A named owner

Every entry has an accountable person. Not a team, not a function, a name. This is the field that turns a list into governance, and it is the one MAS has been most consistent about across the AIRG, the MindForge Handbook and its earlier information papers.

4. Approved scope of use

Where and how the AI is permitted to operate: which jurisdictions, which customer segments, which decisions. The scope field is what makes drift visible. When a tool approved for internal research starts feeding customer communications, the inventory is where that boundary was written down.

5. Model type

What kind of AI it is: a rule-based system, a supervised classifier, a large language model, an agent built on one. Model type is a listed attribute in the paper's own text, and it does real work: complexity and the controls that follow differ sharply between a transparent scorecard and a black-box vendor model, and a reader of the inventory should not have to guess which they are looking at.

6. Risk materiality rating

Each use is scored on the Guidelines' three dimensions of impact, complexity and reliance, assessed both inherent (before controls) and residual (after controls), and the rating is recorded with its rationale. This is the field that drives everything downstream: which controls apply, how much independence a review needs, how intensively the use is monitored. For the method behind that score, see how to assess an AI use case's risk.

7. Data used

What data the AI consumes, where it comes from, and whether personal data is involved. The Guidelines put real weight on data fitness, lineage and protection, and the inventory is where those obligations attach to specific systems.

8. Third-party dependencies

Whether the AI is built in-house, procured, or embedded in a vendor product, and which providers are involved. The proposed text is explicit that third-party AI carries the same governance obligations as internal builds. A firm cannot avoid the risk by purchasing the tool.

9. Lifecycle status

Whether the use is in development, pilot, deployed, or retired. Governance obligations differ at each stage, and decommissioning is itself a controlled event under the Guidelines, not a quiet switch-off.

10. Review and validation history

When the use was last assessed, reviewed or validated, by whom, and what changed. An inventory that cannot show its own maintenance is a snapshot, and a supervisor reading a snapshot will ask the obvious question: is this current?

11. Linkage to controls and evidence

The connective tissue. Each inventory entry points to the controls applied to it and the evidence behind them. This is what transforms the inventory from a register into the spine of an inspection-ready record.

Two things are worth saying plainly. First, proportionality does not mean exemption. Firms whose AI use is assistive face a lighter set of expectations, but the Guidelines' own annex still expects basic policies, an approved-tools list and clear ownership even at that level. The inventory scales down; it does not disappear. Second, the inventory is a living document. The proposed text expects it to be kept current, reviewed, and supported by a repeatable identification process, which is exactly why a spreadsheet built once for a deadline fails the test that matters: not "do you have a list" but "show me it is current."

The transition period proposed after finalisation is twelve months. An inventory started then will look like what it is. One started now becomes a track record, and a track record is the one thing that cannot be assembled retroactively.

That is the problem Governance Row is built for: a live AI inventory with every field above, materiality assessment on MAS's own dimensions, 68 controls mapped paragraph by paragraph to the AIRG, MindForge, Veritas, SAFR and TRM, and an inspection pack generated in one step. The AIRG is one layer of the full Singapore AI governance stack. For the full picture of the Guidelines themselves, see our complete guide to the MAS AI Risk Management Guidelines.