AIRG and Project MindForge training, step by step

What the AIRG covers. The MAS AI Risk Management Guidelines were finalised in October 2026 and come into force in October 2027. They cover traditional machine learning, generative AI and agents, across the AI lifecycle, and they are risk-based and proportionate, so the depth of control depends on how material the use is. MindForge is the industry's toolkit of practices, based on and aligned to the AIRG, and organised into pillars and considerations. This page pairs the AIRG expectation with the MindForge practice for each consideration the second and third line should focus on.

Your role. You do not build the AI. The second and third line provide independent oversight, effective challenge and reviews. Read each topic as a reviewer: how do you tell whether the first line has done this, and done it properly.

Related on this site: the AIRG explained, the final AIRG, AI risk management from first principles, AI risk management in Singapore, the complete guide, and the MindForge toolkit.

In an ebook: AI Risk Management from First Principles.

What the AIRG expects. Governance documents that set out the firm's approach to AI: a consistent, enterprise-wide way to identify AI, assess risk materiality, maintain an inventory, clear ownership, and the policies that underpin the oversight and lifecycle controls. The point is one approach applied the same way across the firm, not any single document.

What MindForge does. It builds the approach in layers: a short set of the firm's own AI principles; a working definition of AI so the approach applies consistently, including to AI embedded in purchased software; an identification framework wired into the software development lifecycle, existing risk reviews and third-party onboarding, with a named authority for borderline cases; and all of it written into a dedicated AI policy or folded into existing policies such as the model risk policy, then reviewed on a set schedule.

What good looks like, and what to ask for. One approach, applied the same way across the firm, with clear ownership. Ask how the approach is enforced where the business actually runs AI day to day, not just what the policy says.

Related on this site: governance documents, in full, the AIRG explained, and why AI governance frameworks fail.

In an ebook: Scaling AI Governance.

What the AIRG expects. Existing risk frameworks and functions identify, assess and manage the risks AI brings, with clear roles, indicators and escalation. The AIRG does not mandate a particular structure. What it requires is accountability and no gaps, with material AI risk reflected in the risk appetite.

The structure is the firm's choice. MindForge sets out three approaches, which can be combined: update each existing risk category for AI (distributed), expand model or technology risk to hold AI risk (concentrated), or add a dedicated AI risk category (AI-specific). Whatever the firm picks, what matters is a consistent spine across the firm, clear accountability, and no gaps between risk types or parts of the business. The board approves the approach; it does not have to favour one structure over another.

What MindForge adds. Existing controls such as access management and incident management still apply and are strengthened where they fall short. The firm sets a small number of AI key risk indicators with named owners, such as the share of use cases missing from the inventory, production systems running without approval, drift and data-quality measures, and total exposure. AI incidents are logged by severity, with attention to how long they take to resolve, and escalation runs against thresholds set by the risk appetite.

What good looks like, and what to ask for. AI risk visible in the risk appetite, controls strengthened rather than duplicated, and a short list of key risk indicators with named owners. Ask whether there are gaps between the chosen structure and any part of the firm, and for an example of a threshold being breached and what happened next.

Related on this site: the organisation-wide risk framework, in full, three lines of defence for AI, building an AI risk function, and AI risk management for risk and compliance.

In an ebook: Scaling AI Governance.

Start from the AIRG, which is strict here. The AIRG holds third-party AI to the same standard as AI built in-house: identified, rated for materiality, inventoried and controlled, with onboarding and deployment controls, and compensatory testing to cover what the vendor will not disclose. Buying the AI does not move the accountability to the vendor.

What an AI Card covers. An AI Card is a model or system card: a short, structured disclosure from the vendor. It usually sets out what the system is and what it is meant to be used for; the data it was built on; how it performs and where it is weak; the known risks and failure modes; the testing, guardrails and safety measures already in place; and version information, so you know what has changed. How much you ask for scales with how material your use is.

It is an extension, not a new thing. Model cards and data cards (datasheets) have been used in AI for years to describe what a model does and what data it was built on. An AI Card is that same idea, brought into vendor assessment. And MindForge treats this as strengthening what a firm already does, not a new function: you already run procurement, vendor assessment and third-party risk management, and an AI Card has the same purpose as a due-diligence questionnaire, applied to the AI-specific points.

What MindForge adds. Review the disclosure against your expectations. Where information is withheld, decide on the basis of indemnities, credible external attestation, or your own testing, rather than rejecting the vendor outright. Run compensatory testing on your own data and metrics, more where disclosure is thin or the use is material, with fairness testing part of onboarding. Watch for AI added to an existing product through vendor updates, and contract for change notification, liability, data retention and audit rights.

What good looks like, and what to ask for. Third party AI in the same inventory and on the same risk materiality scale as internal AI, disclosure requested in proportion to materiality, your own testing where it matters, and contracts carrying the AI-specific terms. Ask for a case where a vendor withheld information and how the firm decided.

Related on this site: third-party AI risk, in full, third-party onboarding, governing third-party AI, and supervising third-party AI.

In an ebook: AI Risk Management for Risk and Compliance.

What the AIRG expects. Rate each AI use on its materiality, at least across impact, complexity and reliance, applied consistently, with the depth of controls following the rating. Material systems get an independent review before deployment. The rating is how proportionality works in practice.

What MindForge does. It sets enterprise-wide tiers, commonly low, medium and high, on criteria that fit the firm: impact (financial, reputational, regulatory, effect on customers, use of personal data), complexity or novelty, and how far the AI replaces human judgement. It assesses inherent risk early, from the basic features of the use case, then residual risk after controls are in place, tested in conditions close to real use, repeating until the residual risk is acceptable. Controls scale with the tier, from sample-based review for a minor use to review of every output for a material one. A review before deployment is carried out by someone not involved in building it, and its depth and independence increase with materiality.

What good looks like, and what to challenge. Tiers applied the same way across the firm, based on what a system does rather than who sees it. An inherent assessment early and a residual assessment before go-live. Controls whose intensity matches the tier. Challenge the rating first, especially a high-impact use such as credit decisioning that has been rated low.

Related on this site: use-case risk and materiality, in full, supervising inventory and materiality, inventory and materiality for the second line, and inventory and materiality compared.

In an ebook: AI Risk Management for Risk and Compliance.

What the AIRG expects. An accurate, up-to-date inventory of AI use cases, so risk can be aggregated across the firm and controls applied consistently. It is a required outcome: the firm must be able to show it knows where its AI is. The AIRG does not prescribe the tool.

What MindForge does. It treats the inventory as a record of core attributes, and is flexible about the tool: extend an existing asset inventory, link several registers, or build a dedicated system. It sets six minimum attributes per use case: purpose and scope; type of AI; data used; risks and mitigations, including the materiality rating; status and governance, including the owner, lifecycle status and approvals; and third-party information, including vendor disclosures such as AI Cards. Every use case is recorded, including low-risk ones, so the firm-wide picture is complete. Three roles keep it current: the use-case owner maintains their entries, an AI-specific reviewer checks accuracy, and an inventory owner, usually a control function, is accountable for the inventory overall. Reviews after deployment also check the inventory, flagging where a live system no longer matches its record.

What good looks like, and what to ask for. One firm-wide view of the AI in use, the six attributes recorded before deployment, the three roles named and filled, and an owner for the schema. Ask how the firm finds AI that no one registered.

Related on this site: the AI inventory, in full, supervising inventory and materiality, and inventory and materiality for the second line.

In an ebook: AI Risk Management for Risk and Compliance.

The shift. Most AI risk management was built for narrow, predictive models. Generative AI adds open-ended outputs, new failure modes such as made-up answers and manipulation through the input, and heavy reliance on third-party models. Agentic AI adds systems that take actions and chain steps with less human involvement at each step. Capability and risk rise together.

What it means for your seat. The controls do not change in principle, but they stretch. Materiality has to account for autonomy and reach. Testing has to cover behaviour, not just accuracy. Monitoring has to run against systems that change after deployment. The second and third line need enough understanding of these systems to ask the right questions.

Related on this site: governing agentic AI, agentic AI risks, agentic AI risk management, and the five S's of AI.

In an ebook: Agentic and Generative AI for Finance.

Rate it on what it can affect. The materiality rating still applies, but for generative AI the impact and the reliance are often higher than they look: the output goes to a customer, a colleague acts on it, and the content is open-ended rather than a single number. Rate the use on what it can affect, not on how simple it is to use.

Ground it in your own documents. A language model has no memory between requests. For one request it works only from what it is given: the instructions, the question, and any documents fetched for it. So the strongest control is to make it answer from approved sources you supply, and to show which part of the source it used. For a question about a fee or a loan covenant, the system should pull the relevant document and answer from it, rather than from whatever it picked up in training.

Limit it, and keep records. Give the system access only to what the task needs. Keep a record of what was asked, what was retrieved, and what was produced, so a wrong answer can be investigated later.

Test it on your own work, and keep testing. Build a set of test cases from real work: representative customer questions and documents, and the hard ones, incomplete requests, out-of-date or conflicting sources, and cases where the system should ask for help rather than answer. For each case, write down what a good answer must contain, for example the clauses a covenant summary must mention, or the correct fee and its source. Judge answers against that, run the tests again after any change, and keep the worst cases. A public benchmark can help shortlist a model, but the decision to go live needs evidence from your own tasks.

How you tell it is working. A control you cannot measure is only a hope. Useful measures: whether an answer is actually supported by the source it points to, how often the system produces something unsafe or answers when it should have declined, and how often a person had to correct it. For a material use, there should be evidence that outputs are reviewed and that failures are found and fixed.

Related on this site: guardrails and metrics, making AI safe in practice, and use-case risk and materiality.

In an ebook: Agentic and Generative AI for Finance.

Challenge, not build. The second line does not run the model. Its job is to ask for evidence and to judge whether a control is real or only described. You do not have to invent a framework; the AIRG already is one. The questions below follow a use case across its life.

Identification and inventory. Is every use case recorded, including low-risk ones and anything bought from a vendor? How is AI that no one registered found?

Materiality. How was this rated, and why? Does a high-impact use rated low hold up when you probe it?

Before go-live. What was tested, against what, and by whom? Was the reviewer independent of the build? Did testing cover adversarial cases and fairness, and did it reflect real conditions rather than a clean dataset?

After go-live. What does the monitoring show, including drift? What thresholds exist, and what happens when one is breached?

Third-party. What was disclosed, what was tested on your own data, and what do the contract terms cover?

Data. Where did the data come from, what is sensitive, and how are training and operational data kept separate?

Incidents and escalation. How are AI incidents logged, and when do they reach the board?

Proportionality is your throttle. You cannot validate a whole portfolio in full. Put the weight where materiality is highest, and cover the rest with lighter checks.

Related on this site: where AI risk hides from the second line, challenge, not build, questions to ask your first line, testing and review, assessing controls before deployment, monitoring after go-live, and three lines of defence for AI.

In an ebook: AI Risk Management for Risk and Compliance.

This is the delta, not data governance in general. Your firm already governs data, and for some purposes, regulatory reporting above all, that governance is more exacting than anything AI requires. The point here is only what AI adds, on top of what you already do. It sits on your existing data governance; it does not replace it.

The key thing is representativeness. For AI that is trained, the data it learns from has to represent the conditions it will meet in use. A model trained on data that does not match live conditions fails quietly when conditions differ, and no one notices until it matters. For AI that is grounded, meaning it answers from documents you supply rather than from training, the documents it draws on have to be the right ones, complete and current, because the answer is only as good as what it is given. Representativeness, of the training data and of the grounding sources, is the thing to get right.

The other AI-specific additions. Provenance and rights for the data used. Protection of sensitive and personal data, including what leaves the firm when it is sent to a third-party model or placed in a prompt. Separating training data from live input, and preventing leakage between them. Retention and deletion for data held by or sent to AI. And the data used to test the system, which has to be representative too.

What to ask for. Whether the training or grounding data represents real conditions, and how that was checked. Where each dataset came from and on what basis it is used. What stops sensitive data leaving the firm through a model or a prompt.

Related on this site: data management, and data ethics.

In an ebook: AI Risk Management for Risk and Compliance.

What is different. An agent plans and acts across steps, calls tools, and can change things, not just produce text. Two things to pin down first: how much autonomy it has, and the path it can take, meaning the sequence of actions available to it. The risk is the path, not a single output, so control has to happen while it runs, not only before it ships.

Govern it in order of reliability. The most reliable control is to make an action impossible, not to ask the model not to do it. First, remove what must never happen: access it should not have, actions it should not be able to take. Next, fixed rules on the actions, not on the model's judgment: hard limits, approval required before high-impact actions, and a kill switch that someone owns and has tested. Then a second model as a check on behaviour, remembering that the checker is itself a system to govern. Last, your own testing: test the path, not just the answer; repeat it, because an agent is not deterministic; and probe through everything it reads, since instructions can arrive hidden in the content it retrieves.

Failure modes to watch. The wrong action, an action that breaks something, someone steering it through its inputs, and long chains where small errors compound.

Oversight, KRIs and proportionality. Human oversight scaled to impact. Key risk indicators for agent behaviour, such as actions outside scope, failed tool calls and escalations. Logging detailed enough to reconstruct the path. And not every agent needs the full treatment: match the effort to what it can affect, and keep governing it, because it keeps changing.

Related on this site: governing agentic AI, runtime governance for agentic AI, agentic AI risk management, and AI oversight and accountability.

In an ebook: AI Risk Management for Agents.

Most of it does not change. New models and new techniques arrive constantly, but the things that actually control AI risk are stable. Accountability stays with the firm, not the vendor or the tool. Risk and effort follow materiality, so the weight goes where the harm would be greatest. You keep a comprehensive inventory of what you have. You challenge and independently review before go-live, and you watch after. None of that depends on which model is in fashion.

So map the new to what's stable. When a new capability appears, agentic AI is the current example, the question is not what entirely new rules are needed, but where it sits in what you already do: how material is it, what can it affect, what independent check applies, what do you monitor. A firm that governs to durable fundamentals absorbs new technology; a firm that writes a fresh framework for each wave falls behind.

The AIRG was finalised in October 2026 and comes into force in October 2027, phased, so there is time to build on the fundamentals rather than scramble.

Related on this site: the final AIRG, the transition timeline, AI risk management for boards, AI risk management for risk and compliance, and the AIRG compared with the EU AI Act, NIST and ISO 42001.

In ebooks: AI Risk Management for Directors and AI Risk Management for Risk and Compliance.