Governance

Most AI deployments in 2025 have governance policies. Very few have governance. The distinction is operational: a policy describes what should not happen; governance is the architecture that prevents it and records what did. The audit trail is the proof. If you cannot reconstruct what your agent knew, what it decided, and why, for any action it took in the last twelve months, you have logs. You do not have governance.

That gap has regulatory consequences for the first time this year. The EU AI Act’s high-risk obligations were deferred on 16 June 2026, when the European Parliament gave final approval to the digital omnibus amendments. Standalone high-risk systems under Annex III now apply from 2 December 2027, and high-risk AI embedded in products covered by Annex I product-safety law from 2 August 2028. Most of the Article 50 transparency obligations were left where they were, and applied from 2 August 2026.¹ Singapore launched the world’s first governance framework specifically for autonomous AI agents at Davos on 22 January 2026.² The window for treating AI governance as a voluntary posture has closed for organisations operating at any meaningful scale in either jurisdiction.

The regulatory moment

The EU AI Act entered into force on 1 August 2024. Its obligations roll out in phases. The prohibitions on unacceptable-risk AI practices took effect in February 2025. General-purpose AI model obligations followed in August 2025. The high-risk system rules under Annex III, covering AI used in employment, access to essential services, biometrics, and a range of other categories, were due on 2 August 2026, but the June 2026 omnibus amendments moved them to 2 December 2027.¹

For high-risk non-compliance, penalties reach up to EUR 15 million or 3% of global annual turnover, whichever is higher.¹ The jurisdictional reach is not limited to EU-based companies. Any provider or deployer whose AI system produces outputs used within the EU falls within scope, which matters for Singapore-based operators with European customer bases.

Singapore’s approach is different by design. The IMDA Model AI Governance Framework for Agentic AI, launched on 22 January 2026 at the World Economic Forum in Davos, is voluntary guidance rather than prescriptive regulation.² It is the first such framework published by a government, which is IMDA’s own claim for it. It does not offer a tidy definition of an agent, and says so plainly: “There is no consensus on what defines an AI agent, but there are certain common features”.² That reticence is the honest position. The systems this matters for are the ones running multi-step workflows against tools, APIs and other systems without a person approving each step.

The voluntary framing does not mean a governance-free environment. Existing Singapore legislation, the Computer Misuse Act, contract law, and the Personal Data Protection Act, already provides accountability mechanisms for AI-caused harms. The Monetary Authority of Singapore published an AI Risk Management consultation paper in November 2025, with final guidelines expected later in 2026; once finalised, those become supervisory expectations that MAS evaluates during inspections.³ The PDPA is worth reading carefully here, because it is easy to over-read. It contains no automated-decision-making regime: no statutory duty to tell someone a decision was automated, no right of access to the decision logic, and no right to human review or appeal. What applies are the ordinary obligations, Consent, Notification of purposes, and Accountability, to whatever personal data the system processes. The PDPC’s Advisory Guidelines on the Use of Personal Data in AI Recommendation and Decision Systems (1 March 2024) set out how the regulator reads those obligations for AI, and they say of themselves that they “are advisory in nature, are not legally binding on the Commission or on any other party, and do not constitute legal advice.”⁹

The NIST AI Risk Management Framework, published in January 2023 and extended with a Generative AI Profile in July 2024, remains the dominant international reference architecture, structured around four functions: Govern, Map, Measure, Manage. NIST issued a Request for Information on agent security that received 937 public comments; the Cloud Security Alliance has proposed a formal Agentic AI Profile extending the original RMF with categories for tool-use risk, runtime behavioural governance, and delegation chain accountability. As of June 2026, that profile is proposed rather than formally adopted.⁴

Singapore’s four dimensions for agentic AI

The IMDA Agentic AI MGF organises its guidance into four dimensions. For any team running AI-operated workflows, these four dimensions are a sound operational architecture regardless of the voluntary status of the framework itself.

The first dimension is risk assessment and boundary setting. Organisations must define explicit boundaries for what agents can access and do: least-privilege design applied at the tool and permission level. Risk assessment must occur before deployment, not after. An agent that can, in principle, access any data source or call any external API has a larger blast radius than one whose tool permissions are scoped tightly to the tasks it performs. The framework requires systematic risk assessment; the operational implication is that every tool permission granted to an agent is a risk decision, not a configuration detail.

The second dimension is human accountability. The framework requires clear allocation of responsibility across the AI lifecycle: developers, deployers, operators, and end users each bear defined accountability. More specifically, it requires “significant checkpoints in the agentic workflow that require human approval” for high-stakes or irreversible actions. Nominal oversight, a human technically in the loop who approves without genuine comprehension, does not satisfy this requirement. The framework goes further: organisations must demonstrate that oversight is effective.

The third dimension is technical controls throughout the lifecycle. Controls must be implemented at three stages: design phase (tool guardrails, access boundaries, safety limits); pre-deployment testing (execution accuracy, policy adherence, behaviour across diverse inputs); and post-deployment monitoring (progressive rollout, real-time monitoring, continuous evaluation). This is a lifecycle requirement, not a one-time deployment checklist.

The fourth dimension is end-user education and transparency. Users must receive clear notification of agent capabilities, data access policies, and their own responsibilities. Training for effective human-agent interaction is required. For B2B operators, this extends to client teams who interact with or receive outputs from AI-operated workflows.

Human-in-the-loop vs human-on-the-loop: the reversibility calculation

The distinction between human-in-the-loop and human-on-the-loop is not a philosophical preference. It is a reversibility-and-risk calculation applied to each specific action type in a workflow.

Human-in-the-loop (HITL) requires pre-execution human approval. The agent pauses and cannot proceed without the human decision. This applies when an action is irreversible, high-stakes, legally binding, or when confidence or risk thresholds require it. Human-on-the-loop (HOTL) allows autonomous execution with post-execution monitoring and intervention capability. The agent does not wait. This applies when actions are reversible, lower-stakes, high-volume, or when operational speed is a core requirement.⁵

A single multi-step workflow will typically require both. The agent drafting an internal research summary operates HOTL: the draft can be corrected if wrong, the action is reversible. The agent publishing to a client’s website, sending an outbound communication, or making a financial commitment operates HITL: the action cannot be cleanly undone, and a bad decision has real-world consequences.

An approval step where a human clicks “approve” without genuine comprehension is not oversight. It is approval theatre, and it is the primary failure mode of most human-in-the-loop implementations.

EU AI Act Article 14 and the NIST AI RMF both require “demonstrable” human oversight: trained, measurable, and provable. Automation complacency, the tendency of oversight humans to approve agent actions without critical review when approvals become routine, is the structural failure this requirement is designed to address.

The operational countermeasures are practical. Structured briefings before high-risk workflow runs replace silent button presses with a contextual handoff. Challenge-and-response checklists replace simple approve/deny prompts with surfaced risk factors, not just the proposed action. Post-action debriefs feed findings back into threshold calibration. These patterns come from the aviation Crew Resource Management model; they apply directly to agentic workflow oversight. Governance is a learning system, not a static gate.

On timeout: if the approval window expires without a human response, the system must fail safe to denied, not auto-approve. Approval silence is not consent.⁵

Audit trails: what the minimum standard actually requires

Singapore’s Agentic AI MGF recommends rather than mandates, but it is specific about what it recommends: “Ensure log immutability: Maintain complete audit trails by ensuring that problematic agent trajectories and failures cannot be deleted, preserving them for analysis and compliance purposes.”² The EU AI Act is where logging is actually compulsory: Article 12 requires that high-risk systems “technically allow for the automatic recording of events (logs) over the lifetime of the system”, with retention duties falling on providers under Article 19 and on deployers under Article 26(6).¹⁰ The practical standard emerging from both regulation and operational deployment is that audit trails must enable reconstruction of four questions: what did the agent know, what did it decide, how did it get there, and was it within policy?

An audit trail that captures only final outputs, “the agent sent this email”, is inadequate for accountability purposes. The minimum viable audit trail for an agentic workflow captures model version, prompt or prompt hash, tool calls and their results, retrieved context, final action payload, governance checkpoint outcome, and a timestamp with session and engagement identifiers. These are not redundant fields; each one answers a different accountability question.

The distinction between an audit trail and a general event log matters operationally. Debug traces capture everything for developers; audit trails capture what matters for accountability and reconstruction. Monitoring dashboards show current state; audit trails preserve historical record. Storing everything in a structured log and calling it an audit trail misses the organisational logic: the audit trail must be structured around accountability questions, not around the system’s internal architecture.

Governance checkpoint recording is the component most often missing. At each defined checkpoint, an approval gate, an escalation decision, a human review, the log should capture who reviewed, what was reviewed, the decision outcome, and the basis for the decision. This turns governance from a claim into a demonstrable fact that survives audit. Without it, you can show that a gate exists in the workflow diagram; you cannot show that it operated.

The four failure patterns

Governance failure in production AI systems follows four predictable patterns. Each is an architectural problem, not a policy problem.

The first is policy without enforcement. A governance policy is written, approved, and filed. The AI system continues operating without the policy being wired into any execution checkpoint. The gap between the policy document and the running system is invisible until an incident occurs. The countermeasure is enforcement at execution time, not at compliance review time. A policy engine that operates between the agent’s intent and the execution layer, applying rule sets before each action executes, is the operational pattern gaining adoption in 2025–2026.⁶

The second is shadow AI sprawl. When sanctioned AI tools are more restrictive or harder to use than unsanctioned alternatives, teams route around governance. The governance framework covers the sanctioned system; the work happens in the unmonitored one. The countermeasure is not restriction. It is making sanctioned tools more capable and more accessible than the alternatives, not less. Governance that creates friction without delivering value will be bypassed.

The third is agent sprawl without orchestration. Multiple agent deployments, different tools, different providers, different workflows, without a single control plane. Audit trails are fragmented across systems; escalation paths are inconsistent; there is no unified view of what AI is doing across the organisation. Governance requires a single envelope around all agent activity. Per-tool policies are not equivalent to organisational AI governance.

The fourth is weak data foundations. AI governance built on top of poor data governance is structurally unstable. Audit trails that reference data with no provenance, decisions based on models trained on undocumented data, personal data flowing through agent workflows without retention policies: these are governance failures at the foundation layer that no amount of escalation-threshold configuration can resolve. Data governance must precede AI control infrastructure, not follow it.⁶

What this means for AI-operated workflows run over months

An AI-operated workflow that runs alongside a team across months, handling brand operations, content production, customer communications, internal reporting, accumulates a governance surface area that grows with every action the system takes. Each action is a decision point. Each decision point either has a traceable record or it does not.

Good governance in this context has four operational properties. It is invisible when working correctly: governance that requires constant human attention to function is governance that will be bypassed when humans are busy. It is evidence-generating, not evidence-consuming: the audit trail is produced as a byproduct of normal operation, not assembled as a separate compliance exercise. It distinguishes risk levels and routes accordingly: treating all agent actions identically produces either paralysis or negligence. And it improves over time: threshold calibration, gate placement, and escalation criteria should be reviewed against actual workflow history on a regular cadence, monthly or quarterly, rather than set once at deployment and left to drift.

ISO/IEC 42001:2023, the first international standard specifying requirements for an AI management system, provides a certifiable baseline that covers a significant portion of the NIST AI RMF’s Govern and Map functions. Certification is not currently required by any regulation, but it provides a defensible posture under EU AI Act scrutiny and a credible signal in client relationships where the governance question will be asked.⁷

For Singapore-based operators, the current environment is best characterised as: legally accountable now, under voluntary guidance frameworks that will likely transition to binding requirements within one to three years as regulatory capacity builds. The IMDA Agentic AI MGF’s four dimensions, risk bounding, human accountability, technical controls, end-user transparency, are a sound operational architecture regardless of mandatory status. Building to them now is the lower-risk path.

The practical floor in Singapore is the PDPA as it actually stands: consent, notification of purposes, and accountability for the personal data an AI-operated workflow touches. Those are enforceable today. The AI-specific expectations, notification that a decision was automated, transparency about decision logic, a route to human review, come from the PDPC’s advisory guidelines and from the IMDA framework. Both are guidance, not law. Building to them is a good idea and increasingly what clients ask for. Being told they already bind you is not accurate, and a compliance plan built on that premise is built on sand.