The AI inventory and materiality rating

If you own one thing in the second line, own these two: whether the firm knows where its AI is, which is the AI inventory, and whether each use has been rated honestly, which is the materiality rating. I wrote the AIRG and led the thematic review of how banks actually manage AI model risk, and everything else you do hangs off these two. Risk and compliance teams tend to treat the inventory as the business's spreadsheet and the rating as the business's call. Both are yours.

The business keeps the AI inventory and sets the materiality ratings. We review them. Is that not the right split?

It is the split that gets second lines into trouble. So the question is: if the first line both decides what counts as AI and how risky each use is, who is left to challenge the answer that suits it?

The AIRG is deliberate here. It puts a control function in charge of identification and materiality firm-wide, so neither is quietly set by whoever benefits from the answer. In most firms that control function is you. A control only reaches the AI that is on the inventory, and every downstream control is dialled by the rating, so if you do not own these two, you are challenging lifecycle controls without knowing whether they sit on the systems that need them.

Own the net, not just the list

Before an inventory there is identification - how the firm decides what counts as AI in the first place. This is where you set the rule, not the business. Write a clear, firm-wide definition of what counts, and make yourself the arbiter of the borderline cases, because if each unit draws the line where it suits them, the firm-wide picture fragments and your aggregate numbers become fiction.

Then build the net, not just the list. AI arrives in a firm without knocking: a feature switched on inside a tool already licensed, a vendor model embedded in a product nobody logged, a model that grew out of a spreadsheet, a team using a public chatbot on personal accounts because the sanctioned route was slow. This is the shadow AI, and it is where the quiet failures come from. So wire identification into the places AI actually enters: procurement sign-off, vendor onboarding, change management, and a periodic attestation from each business line. Do not ask the first line only what is on the list. Ask how it would surface what is not, and build the controls that catch it before it is live.

Own the one inventory, and hold it to a standard

The AIRG wants a single, accurate, up-to-date inventory, because one firm-wide inventory is what lets risk be aggregated and controls applied consistently. Several inventories that do not reconcile are no inventory at all. This is the asset the whole second line runs on, so hold it to a standard.

Make it complete, which you test by reconciling it against the registers you already keep - the model inventory, the vendor register, the IT asset list - and chasing what appears in one and not the AI inventory. Make the metadata real: each entry carrying the materiality rating, the business and technical owner, the use case and its authorised boundaries, data sources and sensitivity, dependencies, validation status. An inventory of names is useless. Make it linked, so a given system connects to the data feeding it and the processes depending on it, because that is what turns "what does this change touch, and what has to be re-validated" into an afternoon's work instead of a dig. And keep it current, with triggers tied to the pace of deployment, plus a decommissioning log, because an inventory that only ever grows is not maintained, it is accreting.

A control only reaches the AI you wrote down.

Be the arbiter of the rating

Now the most consequential number in the whole programme, and the one you must not let the first line set alone. The materiality rating decides how hard every downstream control has to work, so it is both the thing you most need to be sound and the cheapest place for the business to make risk quietly disappear.

The AIRG wants a methodology that rates each use at minimum across Impact, Complexity, and Reliance - the harm if it fails, how novel and opaque the thing is, how much the firm leans on it with how little human oversight and how little reversibility. Own that methodology. Make sure it rates on what a system does, not on the easy proxy of who sees it, because audience is not materiality: a system no customer sees can decide which claims get paid, and a customer-facing tool can be a harmless chatbot. Give it scoring rubrics with worked examples so a "high" means the same thing in every unit, and name the triggers that force a re-rate - a change of use, a performance drop, an incident - because a rating set two years ago may have quietly gone stale.

Then do the one thing that separates a real second line from a rubber stamp. Do not spend your scrutiny on the high-rated systems; they are already getting the heavy controls. Sample the low-rated ones and pull the thread. Why is this low? What would move it up a tier? Who in the business signed it, and did they benefit from it staying low? Step back and read the distribution across the estate: if almost everything sits in the lower tiers, far more than a firm of your size and business should produce, that shape is the finding, and you are the one who has to raise it. Being the arbiter means you have, at least sometimes, overruled a unit's self-rating. If you never have, you are not arbitrating. You are recording.

Why this chapter is the one that matters

Get these two right and the rest of your job gets easier, because a programme that genuinely knows where its AI is and has rated it honestly gives you a map you can trust, and proportionality finally works: you can go deep where the map says the risk is. Get them wrong and everything else is effort spent in the wrong places. The inventory and the rating are not the administrative preliminaries to the real second-line work. They are the real work, and almost everything that will later embarrass you hides in the gap between the two.

Work with me

I train risk and compliance teams on turning AI risk management into a working system. See the courses and workshops, read more on AI risk management, or get in touch.