Singapore's AI governance guidance is now a family of frameworks rather than one universal checklist. The 2020 Model AI Governance Framework addresses organisations deploying traditional AI at scale; the 2024 framework covers generative AI ecosystem risks; and the Model AI Governance Framework for Agentic AI, updated to version 1.5 in May 2026, addresses systems that can plan and act through tools. These frameworks provide practical guidance and do not replace applicable law. A Singapore organisation should classify the system first, then document ownership, risk boundaries, data use, testing, human checkpoints, monitoring and user communication, while separately checking the PDPA, sector rules and other binding obligations.

Choose the framework by what the AI system can do

Start with the deployed system, not the product label. A conventional prediction or decision-support model may fit the 2020 Model AI Governance Framework. A system that generates text, images, code or other content raises the ecosystem and model risks addressed by the 2024 generative AI framework. A system that can plan across several steps, call tools or change an external environment also needs the agentic AI framework's controls.

One product can fall into more than one column. For example, a customer-support assistant may generate answers, retrieve personal data and open service tickets. Record each capability, the decisions or actions it can influence, the people and systems affected, and the framework sections used. This capability map becomes the index for the rest of the evidence pack.

  • Traditional AI: predictions, classifications or recommendations used in decisions.
  • Generative AI: production or transformation of content using a generative model.
  • Agentic AI: multi-step planning and action through tools, data or connected systems.
  • Hybrid system: apply the relevant controls together rather than selecting one label.

Separate voluntary governance guidance from binding obligations

Singapore's 2020 Model AI Governance Framework describes itself as a voluntary, practical framework. Using it can help an organisation structure responsible deployment, but following the framework does not by itself establish compliance with the PDPA, a sector rule, a contract or a duty owed in another jurisdiction. Keep the governance assessment and the legal-obligations register connected but distinct.

If the system handles personal data, map the processing against the PDPA obligations that actually apply, including purpose and notification, consent or another permitted basis, accuracy, protection, retention, overseas transfer, access and correction, breach notification and accountability. Check sector-specific requirements and overseas laws where the system, users, data or effects cross those boundaries.

  • Framework status and version recorded for each control decision.
  • Applicable-law and sector-rule assessment owned separately.
  • Contracts and customer commitments mapped to the same system facts.
  • Qualified advice obtained where the binding position depends on the facts.

Assign accountable owners before testing the model

The 2020 framework begins with internal governance structures and clear roles. Name a business owner for the use case, a technical owner for the model and integrations, and owners for data protection, security, procurement and user impact where relevant. Define who approves launch, who can pause the system and who receives incidents or complaints.

Accountability should reach third-party components. Keep the vendor, model version, hosting route, enabled tools, data flows, contractual restrictions and known limitations beside the approval record. A generic AI policy is not enough if nobody can reconstruct which system and configuration the organisation assessed.

  • Use-case owner and documented intended outcome.
  • Model, vendor, version and deployment configuration.
  • Decision rights for launch, material change, suspension and retirement.
  • Escalation contacts for privacy, security, safety and affected users.

Bound agent powers and place human checkpoints at real risks

IMDA's agentic AI framework groups practical measures around assessing and bounding risk, meaningful human accountability, lifecycle controls and end-user responsibility. Translate those themes into the actual permissions of the agent. List every tool, data source and external action; limit access to what the use case needs; and identify actions that require approval before execution.

A human-in-the-loop label is not a control unless the person has enough information, time and authority to intervene. Put checkpoints before high-impact or hard-to-reverse actions such as making a payment, changing a customer record, sending an external communication or exposing sensitive data. Record what the reviewer sees and what happens after rejection or uncertainty.

  • Allowed tasks, prohibited tasks and transaction limits.
  • Tool and data permissions tied to the least access needed.
  • Human approval points before significant external effects.
  • Stop, revoke and incident-containment procedures tested in practice.

Test claims that matter and retain the evidence

The evidence plan should follow the risks identified for the use case. Test the properties that matter to the deployment, such as accuracy for a defined task, repeatability, robustness, security, bias or differential impact, inappropriate content, privacy leakage and the reliability of tool use. State the dataset, environment, threshold, reviewer and result rather than recording only that testing occurred.

AI Verify can support standardised technical tests and process checks, but a tool output is one input to governance. It does not decide whether the organisation's use case is lawful, safe or acceptable. Retain failures, exceptions and remediation alongside the passing results, and rerun the relevant tests when the model, prompt, data, tools, permissions or operating context materially changes.

  • Risk-to-test matrix with a reason for every material test.
  • Versioned test data, configuration, thresholds and results.
  • Known limitations, accepted residual risk and approving owner.
  • Change triggers that require reassessment or retesting.

Make monitoring and user communication operational

Governance continues after launch. Monitor outcomes that can reveal drift, misuse, unexpected tool behaviour, security events or harm to users. Define who reviews alerts, how incidents are classified and when the system must be restricted or stopped. Preserve enough logs and version information to investigate without collecting personal data merely because it may be useful later.

Tell users when AI materially shapes their interaction or outcome, what the system is intended to do, important limitations and how they can seek help or challenge a result. For agentic systems, explain consequential actions and the user's responsibilities at the point of control. Revisit the assessment when IMDA updates a framework or when the product's capability, market, data or impact changes.

  • Defined monitoring signals, thresholds and review cadence.
  • Incident path with evidence preservation and decision authority.
  • Plain-language notice, limitation and feedback or appeal route.
  • Scheduled and event-driven review of the governance record.

Sources and discussion

Related resources

Prepare the next step

Use JurisLane's data and AI compliance readiness assessment to organise the system map, data flows, risk decisions, vendor evidence, testing record and launch questions. JurisLane can help prepare a review pack and identify issues for qualified advice; it does not certify an AI system or replace a regulator's decision.

Explore JurisLane services

Editorial note: This guide supports issue preparation and qualified review. Applicable requirements depend on the facts, entities, markets and current law.