Singapore's Generative AI Transparency Guidelines: What They Ask You to Disclose

The problem of disclosure is that it sounds like evidence until a payment is challenged. A notice can tell a customer that an AI system is involved. It does not, by itself, show who permitted the agent to release funds, delete a record, or change a credit limit. The Singapore material should be read narrowly: IMDA’s public page is titled “Singapore Launches New Model AI Governance Framework for Agentic AI” and carries no publication date.

The IMDA generative AI transparency guidelines search result

A compliance team searching for IMDA material on generative AI transparency is usually looking for a practical answer. What must be disclosed. To whom. In what form. Before or after the AI system acts.

The IMDA page that is available for this point says less than that. It does not, on its face, give a checklist for a customer notice or a template for a disclosure screen. It is a public IMDA page about a “New Model AI Governance Framework for Agentic AI”, and its quoted language sits at the level of regulatory clarity and consumer choice.

Regulations IMDA has put in place a number of guidelines, acts, and codes of practices to bring clarity to the industry as well as provide more informed choices for consumers.

— IMDA

That wording matters because it keeps the obligation in its lane. It supports the idea that IMDA uses guidelines, acts and codes of practice to give clarity to industry and to support consumer choice. It does not support a broader claim that every agent action must be accompanied by a particular evidence artefact.

That limit is not pedantry. It is the difference between a disclosure regime and an evidentiary regime. A disclosure tells a person something before, during, or after an interaction. Evidence has to survive the dispute that comes later.

Imagine a customer service agent changes a customer’s credit limit. The interface may have told the customer that AI was involved. The organisation may have a policy that describes when credit limits can change. Neither fact proves that this agent, acting at that time, had authority to apply that new limit to that customer.

The disclosure may still be the right thing to give. It may be required by another document. It may reduce surprise. But if the dispute is about authorisation, the evidence has to point to the authority behind the act, not only to the fact that the act occurred.

That is where much AI governance writing becomes too soft. It says “transparency” and then treats that word as if it solves notice, control, accountability and audit at once. It does not. A customer can be fully informed that AI is in the loop and still be left unable to test whether the organisation’s own permission rules were followed.

AI governance Singapore, without treating disclosure as proof

The phrase “AI governance Singapore” pulls together several different problems. Some are about public communication. Some are about internal control. Some are about later examination by a regulator, auditor, court, board committee, or customer.

The IMDA wording supports a consumer-choice framing. It says guidelines, acts and codes of practice are used to bring clarity to industry and provide more informed choices for consumers. That is a serious governance function. It is also not the same as producing a defensible record of authority.

A governance owner should separate three files. The first file is the public-facing explanation. The second is the operating policy. The third is the record that shows what happened when the policy met the live action.

The third file is the one that breaks under pressure. System logs often show that an agent called a tool, that a workflow completed, or that a record changed. Those facts are useful. They are not enough if the question is who allowed the act and under which rule.

A payment release makes the gap plain. The finance system can show the payment left. The agent platform can show the request. The customer notice can show that AI assistance was disclosed. None of those, standing alone, shows that the payment satisfied the organisation’s authority model at the moment it was released.

That is why an evidence plan cannot start with the output. It has to start with the permission. If the permission was not captured when the decision was made, a later reconstruction will always look like a story assembled after the fact.

This is also why adjacent Singapore analysis on this site treats financial-services agent guidance as an evidence problem, not only as a policy-writing problem. See the financial-services evidence note for that narrower lane, and the broader collection.

The objection is fair. A transparency guideline is not meant to be an audit system. It may be aimed at disclosure, not retention. It may be addressed to consumer understanding, not examiner reconstruction. That is exactly the point: do not buy a notice mechanism and tell yourself you bought evidence.

Model AI governance Singapore and the missing runtime record

The IMDA page named above is about a model governance framework for agentic AI. A model governance framework can shape expectations about how organisations design and manage AI systems. It does not automatically answer the runtime question: did this particular agent have authority for this particular action?

Model governance is often strongest before deployment. It asks whether the system should exist, whether risks have been assessed, whether oversight is in place, and whether responsibilities have been assigned. Those are sensible questions. They are also upstream of the moment when an agent touches money, customer records, or infrastructure.

Crelis describes its own product category differently. It says it is concerned with runtime authorization for AI agents, and its public site says every agent action passes through Crelis before touching systems.

Every agent action passes through Crelis before touching your systems.

— Crelis.ai

That sentence is a vendor claim, not a regulatory requirement. It should not be laundered into a requirement claim. The value of the claim is narrower. It says where Crelis places the control: before the act reaches the system that matters.

That placement matters because after-the-fact monitoring is a different control. A monitor can detect that the record was deleted. It may even alert quickly. But it still begins with the deletion already attempted or completed. Runtime permission asks whether the deletion should be allowed to happen at all.

Crelis also describes GREENLIGHT as allowing existing systems to keep working while every action is checked and recorded. That is again a Crelis claim, and it should be read as one. It does not prove adoption by any regulator. It does not prove certification. It does not prove performance in your environment.

It does point to the operational distinction that a compliance officer should care about. The evidence problem is not solved by knowing that a model was governed before release. It is solved, if it is solved at all, by capturing the authority decision at the time the agent tries to act.

For teams still proving controls before enforcement, Shadow Mode: How to Prove AI Governance Works Before You Let It Block Anything is the more cautious starting point. For regulated retention questions, Your Logs Keep Two Weeks. Singapore Law Says Five Years. deals with the separate problem of how long evidence must remain useful.

What this means if you have to produce evidence

If you have to answer an examiner, do not lead with the model card, the transparency notice, or the prompt transcript. Start with the contested act. The act is the thing that changed the world.

For a payment, the act is release. For a customer record, the act is change or deletion. For a credit account, the act is the new limit applied to that person. Everything else is surrounding material unless it proves why that act was allowed.

The evidence package needs to show the permission trail. That means the agent identity, the requested action, the relevant policy, the decision made, any human approval, and the final outcome. If one of those elements is missing, be honest about the gap before somebody else finds it.

Do not pretend that disclosure fills that gap. A disclosure can explain that AI was used. It cannot prove that the organisation’s approval rule fired, that the required human was asked, or that a block was bypassed only under a permitted exception.

This is where tool-level authorisation can be useful but insufficient. Crelis says MCP can authorise an individual tool call and pause mid-call for a human decision, but cannot record which policy permitted the action or keep that record after the call returns.

MCP can authorize an individual tool call and can pause mid-call for a human decision; what it cannot do is record which policy permitted the action, or keep that record after the call returns.

— Crelis Knowledge Base

Again, read that as Crelis’s position on the limit, not as an independent standard’s finding. The point is still useful because it names the missing artefact. A tool call record can show access. The examiner’s harder question is why access was permitted.

One trap is to over-record the wrong thing. A full transcript may be large, sensitive, and still inconclusive. It may show that the agent reasoned about a refund. It may not show that the refund authority existed under the organisation’s policy.

Another trap is to record only the outcome. “Approved” is not a permission record. It is a conclusion. If the policy, actor, target, and basis are absent, the word approved has to be trusted rather than tested.

The same weakness appears when teams rely on dashboard history. A dashboard is built for operators who already trust the system. An examiner is often asking whether that trust is justified. The evidence has to travel outside the tool that produced it.

Tamper-evident evidence is the practical dividing line. The claim is not that alteration is impossible. The claim is that later alteration would show, which is the property needed when a record is produced to someone who was not present when the decision was made.

Practical steps for compliance and risk teams

1. Name the act. Write down the concrete actions an agent may take: release a payment, amend a customer record, cancel an order, change a credit limit, or send an instruction to another system. Do not start with broad risk labels.
2. Separate disclosure from authority. Keep the customer notice in one file and the permission rule in another. The notice may satisfy a transparency need, but it should not be treated as evidence that the act was authorised.
3. Capture the decision before the system changes. The useful record is made when the agent requests the sensitive act, not after the downstream system has already accepted it. Crelis describes GREENLIGHT as a route where agent requests for sensitive actions are routed through Crelis and only policy-allowed actions are carried out.
4. Record the basis, not only the result. “Allowed” is too thin if nobody can later see the policy basis. The record should let a reviewer understand why this agent could do this act to this target at this time.
5. Keep human approval specific. A human approval should attach to the action being approved. A general message saying “looks fine” is weak evidence when the challenged act is a specific deletion or payment.
6. Test in observation mode before blocking production work. A team can compare intended policy with real agent behaviour before enforcement changes the workflow. The approach in Shadow Mode: How to Prove AI Governance Works Before You Let It Block Anything is useful when risk owners need evidence before they accept interruption.
7. Plan for retention separately. A short operational log is not an evidence archive. The practical question is how long the organisation needs to keep a contested action explainable, and that may outlast the engineering team’s default log window.
8. Do not overstate the control. If the system only records outcomes, say that. If it records permissions but not policy basis, say that. A clean limitation is safer than a governance claim that collapses under examination.

Crelis’s position is narrow. Transparency helps people understand when AI is involved, but runtime authorization and tamper-evident evidence answer a different question: who allowed this agent to do this act, and can the organisation still prove it later. GREENLIGHT is described at GREENLIGHT, and teams that want to examine the permission step can use the product demonstration.

Crelis is patent-pending. It holds no SOC 2, ISO 27001 or ISO 42001 certification, and claims none.

Related reading

• Singapore financial-services agentic AI evidence — the Singapore financial-services evidence question.
• Verifiable AI Compliance: Singapore Financial Services — the adjacent financial-services control argument.
• Your Logs Keep Two Weeks. Singapore Law Says Five Years. — the retention problem after the action is disputed.