AI Governance 14 July 2026

AI Compliance in Singapore: The 2026 Reference

AI compliance in Singapore rests on voluntary frameworks and sector guidance, not on a binding AI statute. An enterprise deploying AI here complies with the Personal Data Protection Act wherever personal data is involved, follows IMDA's model frameworks as best practice, and — if it is a financial institution — tracks what MAS publishes for the sector. Nothing in that stack licenses an AI system, and no authority signs off on a deployment. That surprises teams arriving from jurisdictions built around statutes and conformity assessments. It should not be mistaken for softness: the data protection law is enforced, and the voluntary documents are unusually precise about what good governance looks like. This page maps the instruments that actually exist, what each one asks of an enterprise, and the records you would need if someone asked you to prove your answers.

AI compliance Singapore

Complying with AI rules in Singapore means, concretely: meeting the PDPA wherever personal data touches an AI system, using IMDA's voluntary model frameworks as the reference for governance design, testing against AI Verify if you choose to, and — for financial institutions — reading what MAS puts out for the sector. The PDPC has published advisory guidelines on how the Act applies when organisations use personal data to develop and deploy AI systems, most recently for generative AI. Those guidelines are the closest thing the general economy has to AI-specific regulatory text.

What is absent matters as much as what exists. There is no AI licensing regime, no registration duty, and no dedicated AI regulator to notify. The binding edge of the stack is data protection and sectoral law, not an AI act. What Singapore offers instead is unusually specific guidance on how to govern — which is its own kind of pressure, because when the guidance is this concrete, "there were no rules to follow" stops working as an account of a failure.

Singapore AI regulation 2026

Singapore's 2026 landscape is defined by a small set of documents, none of them a statute. In January 2026, IMDA launched the Model AI Governance Framework for Agentic AI, extending its earlier model frameworks to systems that act rather than merely generate. In July, the PDPC published its Advisory Guidelines on Use of Personal Data in Generative AI. The financial sector, meanwhile, received an industry white paper on safeguards for AI agents and continued to wait on a set of proposed supervisory guidelines, both covered below.

The white paper deserves precision, because it is widely misread. On 3 July 2026, MAS published <a href="/blog/mas-safr-what-singapore-s-agentic-ai-guidance-actually-requires-you-to-evidence">SAFR</a> — an industry paper on safeguards for AI agents in finance, developed together with financial institutions and FinTechs. The paper is explicit that it is not regulatory guidance and does not set supervisory expectations. Treat it as a signal of where scrutiny is heading and a shared vocabulary for the sector, not as a rulebook. We examine what that means for financial services in our guide to verifiable AI compliance in the SAFR era.

The proposed guidelines are the item to watch. MAS consulted on formal guidelines for AI risk management in the financial sector: the consultation paper appeared in November 2025, and comments closed at the end of January 2026. As of this writing, the final guidelines have not been issued; the consultation proposed a twelve-month transition after issuance. None of this is new terrain for the regulator — the FEAT principles on fairness, ethics, accountability and transparency in AI date back to November 2018. Everything we write about MAS guidelines tracks this thread.

The contrast with Brussels is useful for multinationals. The EU AI Act is binding law: its general application date, including the Article 50 transparency obligations, arrived in August 2026, while obligations for most high-risk systems were deferred to December 2027 by the Digital Omnibus amendments. Singapore has chosen not to legislate an equivalent. The practical consequence is that a governance programme built to evidence standards — one that assumes a sceptical reader will one day open the file — transfers well between both regimes.

IMDA model AI governance framework agentic AI

IMDA's Model AI Governance Framework for Agentic AI is the document to start with if your systems act on a user's behalf. It gives organisations a structured overview of the risks of agentic AI and the emerging best practices for managing them, and it is aimed squarely at deployers — organisations building agents in-house and organisations buying third-party agentic solutions alike. It is voluntary guidance, not regulation. Its authority comes from being the reference point everyone else in the room has read.

The framework organises its recommendations in four areas across the agentic lifecycle: assess and bound the risks upfront; make humans meaningfully accountable; implement technical controls and processes; and enable end-user responsibility. The first area asks you to decide, before deployment, which use cases suit agents at all and how to limit an agent's autonomy, tools and data access by design. The middle two areas are where enterprise deployments succeed or fail, because they concern what happens while agents are running.

On accountability, the language is unusually concrete. From IMDA's own factsheet:

Design effective human oversight to guard against automation bias e.g. trigger human approvals at significant checkpoints, and regularly audit the effectiveness of such human approvals

Read as an engineering brief, the four areas reduce to two questions: what is this agent permitted to change, and who answers for it when it does. A deployment that can show a considered answer to both — with the approval points named, exercised and audited, as the framework recommends — is ahead of most of the market. A deployment that cannot is relying on nobody ever asking.

AI Verify Singapore requirements

AI Verify imposes no requirements, and that is the first thing to understand about it. It is an AI governance testing framework and software toolkit, maintained by the AI Verify Foundation — a global open-source community that convenes AI owners, solution providers, users and policymakers around trustworthy AI. Adopting it is a choice, not an obligation. What it offers is a structured way to test claims about an AI system and to show the results to counterparties — customers, boards, procurement teams — which is the transaction most enterprises actually need from it.

The assurance layer around it is growing. The AI Tester Accreditation Programme — AI TAP — accredits testing service firms that can technically assess AI systems for safety, reliability and governance risks, and the Foundation expects the programme to be available in 3Q 2026. Accreditation matters for buyers of testing services because it answers the question that has dogged AI assurance from the start: who checks the checkers. If your governance story leans on third-party testing, the existence of an accreditation route for those testers strengthens it.

PDPC AI compliance checks

The binding law in this stack is the PDPA, and the PDPC administers it — so this is where compliance stops being optional. The commission has twice set out how it reads the Act in AI contexts. The Advisory Guidelines on use of Personal Data in AI Recommendation and Decision Systems, published on 1 March 2024, address when organisations can use personal data to develop and deploy systems that embed machine learning models. The Advisory Guidelines on Use of Personal Data in Generative AI followed on 20 July 2026. Between them they cover the data-protection questions an AI deployment raises at each stage: the basis for using personal data in development, the safeguards around it, and the accountability arrangements behind both.

What does a compliance check mean in practice? Under the PDPA it means being able to show those same three things on request — basis, safeguards, accountability — with records rather than recollections. One caution on sourcing: a statistic about PDPC checks across several dozen organisations circulates in vendor content, and we could not trace it to any primary source, so it does not appear here. If a number is going to drive a board decision, insist on the regulator's own page. That discipline is a fair test of any compliance content you read, this page included.

What this means if you have to produce evidence

Strip these instruments to their common demand and one requirement is left standing: when an AI system acts, you should be able to show what it did, under whose authority, and with what oversight. IMDA's framework says make humans meaningfully accountable; the PDPC's guidelines assume you can show how personal data was handled; the financial-sector documents assume decision records exist to inspect. None of these documents will build that record for you, and none of them specifies the mechanism. That part is yours.

Five moves are checkable this quarter, without buying anything. Inventory the systems that act, not just the models you host. For each one, write down what it may change without a person and what needs sign-off — that boundary is the framework's central question. Capture decisions as records at the moment they happen: the request, the outcome, the named approver where one was involved. Store those records so that later alteration would be visible — tamper-evident is the property to ask for, and unlike trust, it can be tested. Finally, set retention deliberately: the default in most logging stacks is measured in weeks, while accountability questions arrive months or years later. We keep a worked version of this exercise in our accountability framework for financial services.

None of this effort is wasted if Singapore's posture hardens into supervisory expectations or, eventually, law. The record you keep voluntarily is the record you would produce under compulsion; building it early is cheaper than reconstructing it late. Our writing on AI governance keeps returning to this point, because reconstructing agent behaviour from ordinary logs after a dispute rarely survives contact with a sceptical reader.

Where Crelis fits, stated once. Crelis is an independent runtime authorization and evidence layer for AI agents: before an agent executes an action, it decides whether the action proceeds, needs a human approval, escalates, or is blocked — and it writes a tamper-evident record of each decision as it is made. It runs in shadow mode first with design partners, observing and recording before it is trusted to gate anything, and the approach is patent-pending. How we look after the records themselves is set out plainly on our security page.