Your AI Risk Register Has Four Bullets. FINOS Has 46.

A few weeks ago I wrote about SR 26-2, the new model risk guidance, which carved generative AI out of scope in a single footnote and deferred the real work to a future rulemaking. Read that footnote to the end, though, and it still says anything not covered needs governance under the organization's general risk practices. It just doesn't say how.

That gap is easy to fill badly. What usually goes into a risk register is about four bullets — the model might be biased, it might leak data, it might be wrong, nobody can explain the decision. All true, and all too vague to hand to a delivery team who are two sprints from shipping something.

The FINOS AI Governance Framework is the most usable attempt I've seen at filling that gap, and it's free. FINOS is the Fintech Open Source Foundation, a nonprofit where financial firms collaborate on shared code and standards rather than each rebuilding the same thing privately. Their framework, called AIR, is a catalogue of 46 AI risks with matching controls. Version 2.0 shipped on November 12, 2025, growing from 30 in the first release.

Every risk and control gets an ID

That sounds like filing-cabinet work, but I think the IDs are most of the value.

Risks fall into three groups. First, operational (AIR-OP-*), meaning the system works badly on its own — hallucination and inaccurate outputs is OP-004, non-deterministic behaviour is OP-006, data quality and drift is OP-019. Second, security (AIR-SEC-*), meaning someone attacks it — information leaked to a vector store is SEC-002, prompt injection is SEC-010. Third, regulatory (AIR-RC-*), meaning you break a rule — information leaked to a hosted model, where your data ends up sitting at a vendor, is RC-001.

Controls are numbered the same way, split by whether they stop a problem or catch one. Preventative controls are AIR-PREV-*, like encryption of AI data at rest (PREV-014) or filtering data pulled from external knowledge bases (PREV-002). Detective controls are AIR-DET-*, like system observability (DET-004).

For example, a design document can then say the retriever handles AIR-SEC-010 using AIR-PREV-002, instead of a paragraph of prose that nobody can audit six months later. Engineering, risk, and audit all end up pointing at the same object. And because every entry is cross-referenced to seven external standards — the EU AI Act, NIST AI RMF, the OWASP LLM Top 10, and ISO 42001 among them — the regulatory mapping arrives already done, rather than living in a spreadsheet somebody maintains by hand.

The newer entries are about AI that takes action

Nearly everything version 2.0 added covers agents. An agent, for anyone outside this world, is an AI that doesn't just answer a question but takes steps on its own — it searches, calls APIs, writes files, and remembers things between sessions.

The new entries include agent action authorization bypass (SEC-024), tool chain manipulation (SEC-025), MCP server supply chain compromise (SEC-026), agent state persistence poisoning (SEC-027), and agent-mediated credential discovery (SEC-029). MCP is the Model Context Protocol, the standard way to plug tools into an AI, which also makes it a new place for someone to slip a malicious tool into the stack.

Read together, those five describe a single flow: poisoned document -> agent writes the hidden instruction into its own memory -> acts on it three sessions later -> using a credential it discovered by enumerating its own environment. Older model risk frameworks have no language for any of that, largely because they assumed a model produces a number. Agents produce actions, so the question shifts from whether the answer was correct to whether the action was authorized, and on what evidence.

The eight-step assessment

AIR also includes an assessment, labelled A through H — define the use case and context, identify the data involved, evaluate the model and technology, assess output and decision impact, map the regulations, work through security, identify controls, then decide and document.

None of that is a new idea. What makes it usable is that each step terminates in specific AIR IDs, so step G produces a real risk-to-control matrix with the gaps visible, rather than a status colour someone negotiated in a meeting.

How I'd use it

I wouldn't try to replace an existing governance standard with AIR, since that's a long political exercise with a low chance of success. I'd map the existing control library to AIR IDs once, then ask every new AI use case to declare its AIR risk set in the design document.

What that buys you is shared vocabulary between engineering and second line, a regulatory crosswalk you didn't have to build, and coverage of the agent risks that most internal frameworks, written before anyone deployed an agent, don't yet contain. SR 26-2 handed the generative AI problem back to us and said govern it anyway. AIR is a catalogue rather than a program, but a catalogue is exactly what those four vague bullets have been standing in for.