Those dates are the first thing worth understanding, because they are not one date.
Oversight and the risk management framework take effect on 7 October 2027. That covers board and senior management accountability, and the machinery underneath it: identifying where AI is used, maintaining an inventory of it, and assessing the risk materiality of each use. Lifecycle controls and capability follow by 7 October 2028. That covers data management, human oversight, testing, monitoring, change management, third-party AI, and whether your people and infrastructure are up to the job.
The sequencing tells you what MAS expects first. Before any question about model testing or fallback plans, you are expected to know what AI your firm uses and how much each use matters. The first year is an inventory year.
The scope question most firms get wrong
A common reading is that the guidelines catch everyone equally, so every firm faces the full weight of them. That is not what the text says, and firms that act on it will waste a year.
MAS applies a graduated approach and the relief in it is real. Under paragraph 2.3, a firm may run on basic AI governance policies alone if poor performance or unavailability of the AI services or tools it uses is unlikely to have a material adverse impact on the firm, its customers or other stakeholders. Paragraph 2.4 gives six examples: drafting or proofreading emails to customers, summarising documents or meeting notes for internal reference, initial review or analysis of documents internally, generating formulas or charts for internal reference, AI image generation for marketing or internal materials, and chatbots that help staff locate internal policies. A footnote attaches a condition to all six. Humans should be reviewing and checking the outputs before using them.
What that buys is more than a lighter touch. Paragraph 2.2 applies Sections 3 to 6 unless 2.3 applies, so a qualifying firm is not running a reduced version of the full regime, it is running a different and much shorter one. Paragraph 2.5 sets out what it owes instead: a named member of senior management accountable for AI oversight, a permitted and prohibited use policy covering matters such as putting confidential or client information into public AI tools, an approved list of AI tools with a process for approving new ones, staff education, regular compliance checks, and a periodic and trigger-based review of whether it still qualifies. An approved tool list, not a full AI inventory.
Two things follow, and both cut against reading 2.3 as a comfortable exit. The gateway is assessed on the AI services and tools the firm uses taken together, not use by use, so a single material use takes the whole firm into Sections 3 to 6. And the qualifying judgment is not permanent. Paragraph 2.5 requires you to keep re-testing it, and AI arriving inside software you already own is precisely the sort of trigger that breaks it. The light track is a position you have to keep earning, not a category you fall into.
Materiality attaches to the use, not the tool
For firms on the full track, risk materiality is assessed per use case, based on the nature of the business and the risks arising from the systems and models used. Paragraph 4.12 sets three dimensions as a minimum: Impact, Complexity and Reliance. Paragraph 4.11 asks for both the inherent rating before controls and the residual rating after them, and requires the residual rating to sit within the firm's risk appetite before deployment.
The practical consequence: the same model can carry different ratings in different places. A language model summarising internal meeting notes and the same model drafting client-facing suitability commentary are two use cases with two materiality ratings and two sets of controls. Register the tool and you have recorded nothing useful. Register the use, with an owner, a purpose, an approved scope and a rating, and you have something a supervisor can follow.
This is also why the inventory is a list of uses rather than a list of software. Paragraph 4.7 expects entries to carry a purpose and description, an approved scope of use, model type, data used, dependencies, lifecycle status, an assigned risk materiality rating, model review status, named owners and links to documentation. "We use Copilot" answers none of those. Paragraph 4.3 adds something firms routinely miss: you are expected to designate a control function responsible for AI identification, and that function should be the final arbiter on whether a given use constitutes AI use at all. Someone has to own that call and be able to defend it.
Where the hard work actually sits: AI you did not buy as AI
The largest change between the draft and the final text is third-party AI, and it is the part most firms are least ready for.
Identification should minimally cover AI in services provided by material third-party service providers. MAS makes a point of including software that was never sold to you as AI but has AI features inside it. Your vendors are shipping AI into products you already own, on their release schedule, without asking you.
Paragraph 4.4 closes the obvious escape route. Where practical constraints prevent you identifying all AI use, whether through inadequate disclosure of AI embedded in third-party services or through shadow AI, you are expected to identify the risks arising from those constraints, put mitigating measures in place, and keep residual risk from unidentified AI within your risk appetite. Not knowing is a risk to be managed, not a reason to be excused.
What follows from that is specific:
- You retain primary accountability for third-party AI, including its effect on your customers and on your own regulatory compliance. You cannot push it to the vendor.
- Your contracts should give you visibility, appropriate to risk, over AI being introduced and over later changes to it.
- You should review third-party AI by testing it against your own use cases with your own data, and keep the documentation of that testing.
- Where vendor transparency is limited, MAS points to certifications or external assessments carried out by independent and competent parties, adding in parentheses that it does not mean self-attestations.
- If residual risk on a use case sits outside your appetite, you are expected to consider limiting the service, suspending it, or replacing the provider.
Where complete identification is not practical, and for most firms it will not be, MAS points to permitted-use policies, technical controls over public AI tools and monitoring for unauthorised use. That is the right home for staff using consumer AI tools in a browser. It is a control, not an inventory entry, and it needs to exist.
Why a global framework does not answer the question
Firms inside international groups often expect to satisfy this with the group's existing AI framework. MAS permits that, as long as the group framework actually meets these expectations.
That proviso carries the weight, and paragraph 3.6 sharpens it. Local senior management remains accountable for ensuring group frameworks adequately address Singapore-specific considerations and regulatory requirements, should have adequate visibility into and input on matters affecting Singapore operations, and should be able to demonstrate to MAS how they discharge their oversight responsibilities even when relying on group frameworks. The NIST AI Risk Management Framework and the EU AI Act were built for different purposes against different definitions. Mapping neatly to neither is not a failure of your framework, it is a fact about jurisdictional divergence. What a Singapore supervisor asks is whether the licensed entity here can show it governs its own AI use, assessed its own materiality, and holds its own evidence.
What examination will actually look like
Nothing in the guidelines requires a platform. A firm with a handful of AI uses can meet this with a spreadsheet, discipline, and someone senior who owns it.
What it does require is a record that holds up. In practice, supervisory examination tends to distinguish between a record built as decisions were made and one assembled after the request arrived. The first is dated, attributable, and shows uses being added and ratings changing as circumstances did. The second is internally consistent in a way real operations rarely are, and it tends to invite the next question rather than close it.
That distinction is the reason the 2027 date matters more than it appears to. You cannot reconstruct a year of governance in the month before an inspection. You can only have been keeping it.
Where to start
If you do nothing else before October 2027, work through these in order.
Settle the gateway question first. Does every AI service and tool your firm uses clear the paragraph 2.3 bar? Answer it honestly, write down the reasoning, and diarise the review. If the answer is no anywhere, you are on the full track and the next two steps are not optional.
Find the AI. All of it, including what arrived inside software you already owned and what your staff use without being asked. Expect this to take longer than you think and to surface things nobody knew about.
Write it down as uses rather than tools, and rate each one. Purpose, owner, approved scope, the systems behind it, and a materiality rating with the reasoning attached. The rating is a finding you have to be able to defend, not an assumption you get to make.
The firms that will find 2028 straightforward are the ones that spend 2027 on the inventory. The ones that treat the first deadline as the easy one will arrive at the second without the foundation the controls are supposed to sit on.
Governance Row builds AI governance software around the MAS guidelines for financial institutions in Singapore. If you are working out what the AIRG means for your firm, we are happy to talk it through.