Governance is the ability to prove what your agents did, not a policy document
Every organisation can write an AI policy. Far fewer can answer a regulator's question — what did this agent do last Tuesday, under which authority, using which version of which rule, and who approved it. This practice builds the inventory, the classification, the controls and the evidence that make that answerable, aligned to ISO 42001, ISO/IEC 23894, NIST AI RMF and the EU AI Act.
Inventory first
You cannot govern what is not registered. Most estates start with an unknown number of agents and a known number of licences.
Classify by two axes
Impact of the outcome, and autonomy of the agent. Both must be high before the heaviest controls apply.
Controls that are exercised
A control that exists but has never been run is a document. We test every control and keep the result.
Two jurisdictions, two postures
Hong Kong and Singapore differ in what they expect of you. One control framework can serve both, if it is built to be read by either.
Four frameworks, and what each one actually asks you to have
These frameworks are complementary, not competing. Organisations that try to satisfy all four separately end up with four sets of documents. Organisations that map each one onto a single management system end up with one system and four views of it.
| Framework | Nature | What it requires you to have in place | The evidence an assessor looks for |
|---|---|---|---|
| ISO 42001 | Certifiable management system standard for AI | An AI management system: scope, policy, roles, risk assessment, data governance, system impact assessment, lifecycle controls, monitoring, incident management and improvement, with documented information | Approved policies with named owners, risk register with treatment decisions, impact assessments, internal audit records, management review minutes, and evidence that controls are executed rather than described |
| ISO/IEC 23894 | Guidance on AI risk management | A risk management approach that identifies, analyses, evaluates and treats AI risk across the lifecycle, with criteria for what counts as acceptable residual risk | Risk taxonomy tied to business processes, treatment plans with owners and due dates, and a stated risk appetite that somebody has actually approved |
| NIST AI RMF | Voluntary framework: Govern, Map, Measure, Manage | Governance structures, context establishment, a measurement programme with documented metrics, and a management and monitoring process for AI systems in operation | Governance profile per system, documented metrics with trend data, and a monitoring process that shows what happens when a metric breaches its threshold |
| EU AI Act | Regulatory, risk-based, with escalating obligations | Risk classification of systems, technical documentation, logging, transparency to deployers and affected persons, human oversight, accuracy and robustness, and post-market monitoring for higher-risk uses | The technical file per system, the conformity assessment record, the registration where required, and proof that post-market monitoring is running and producing corrective action |
| ISO 27001 and information security controls | Certifiable information security management system | Access control, key management, logging, secure development, supplier management and incident response, extended to cover agents as a new class of identity and a new class of privileged automation | Agent identity records, credential rotation evidence, log retention and review records, and supplier assessments covering the platforms your agents run on |
How we sequence this. We build one management system with ISO 42001's structure, because it is the most complete of the five and the one an assessor can certify. The others are mapped onto it: NIST AI RMF's four functions become the operating rhythm of the committee, ISO/IEC 23894's risk treatment becomes the risk register's discipline, and the EU AI Act's technical documentation becomes a template in the system rather than a separate project.
Governance in numbers
Each asks for something different, and they are not substitutes
Data sensitivity and decision materiality
Inventory, classification, evidence — everything else is an extension
A control nobody exercises is not a control
Four frameworks, and what each one actually asks you to have
These stack rather than compete. The operational record that satisfies your sector regulator is usually most of what the others need — which is why designing it once, properly, is worth the effort.
| Framework | What it fundamentally asks of you | The evidence it produces |
|---|---|---|
| ISO/IEC 42001 | An AI management system: policy, objectives, roles, risk treatment and a documented improvement loop | Management system records, internal audit reports, improvement logs |
| ISO/IEC 27001 | Information security management extended to cover agent-held data and agent authority | Scope statement, risk register, Statement of Applicability |
| EU AI Act | A risk classification for each system, and the transparency, record-keeping and human-oversight duties that follow from it | Technical documentation, risk assessment, logs, human oversight records |
| Sector regulation | Whatever your own regulator already requires of you, in your own jurisdiction | Supervisory records, decision logs, approval trails |
Two axes, applied together
A single risk score hides the decision. We classify every agent on two independent dimensions — the impact of the outcome if it is wrong, and the autonomy of the agent in producing it — because the same automation has a very different risk profile in a low-impact internal workflow and in a customer-facing or regulated one.
| Impact axis | What it assesses | Indicative criteria |
|---|---|---|
| Low | Internal effort recovered; errors are cheap and reversible | No external party affected, no obligation, no financial consequence, trivially reversible |
| Moderate | Operational or financial consequence that is contained and correctable | Internal customer impact, limited financial exposure, recoverable errors, reputational effect contained to one stakeholder group |
| High | Consequence reaching a customer, a counterparty, a regulator or the balance sheet | Contractual or regulatory obligation, material financial exposure, decisions affecting individual rights, errors that cannot be fully reversed |
| Critical | Consequence involving safety, fundamental rights or regulated financial decisions | Individual credit or eligibility decisions, safety-adjacent activity, statutory reporting, or any use where a wrong output cannot be undone for the affected person |
| Autonomy axis | What it assesses | Indicative criteria |
|---|---|---|
| Assisted | The agent produces content; a person decides and acts | No autonomous action, no write access to systems of record |
| Supervised | The agent acts within a narrow envelope, and every consequential action is approved | Approval required per action or per batch, human executes or releases the action |
| Delegated | The agent acts within a defined envelope and reports afterwards | Post-hoc review, sampled at a rate set by risk, with reversal capability |
| Autonomous | The agent acts and only escalates what its own rules flag | Continuous monitoring, a mandated kill switch, and periodic re-authorisation |
Because the axes do not move together
A high-impact decision made by a supervised agent carries much lower operational risk than the same decision delegated. Collapsing this into one score either over-controls trivial agents or under-controls consequential ones.
Classification follows the use
The same agent, used for a different decision, can sit in a different class. Any change of use triggers a reclassification — otherwise the classification becomes a label attached to the technology rather than to the activity.
Regulatory categories follow from impact
Where the EU AI Act applies, the regulatory category is derived from the intended purpose and the impact axis, then documented in the technical file. We do not classify the other way round.
Two axes, applied together
Most governance frameworks are applied as a single blanket requirement, which reliably over-governs the bottom-right quadrant and under-governs the top-left.
Full governance, full evidence
Both high. Private processing, full human approval, complete decision log, human oversight record. This is where banks and health systems actually operate.
Governance-heavy, data-light
Material decisions on non-sensitive data. Full approval trails and evaluation, but the data controls can be proportionate.
Data-heavy, decision-light
Sensitive data, low materiality. The controls focus on the data: residency, minimisation, encryption, egress. Less approval machinery needed.
Proportionate by design
Neither is high. Sample review and standard logging is genuinely enough here, and over-governing this quadrant is how budgets get wasted.
Inventory, classification, evidence. Everything else is an extension.
A great deal of enterprise AI governance effort is spent on policy language. The three artefacts that actually change your risk position are unglamorous, and they are the ones that make the difference when something is questioned.
Asset inventory
Every agent, the model and tools it uses, the systems it reads and writes, the business process it supports, the owning department, the named owner, its authority tier and its data classification. Reconciled against what is actually running — licences, service accounts, API keys and traffic — because the difference between the registered estate and the live estate is where the risk lives.
Classification
Each entry scored on the impact and autonomy axes, mapped to a control set, with a named reviewer and a review date. Classification decisions are recorded with the reasoning, so a later challenge can be answered from the record rather than from memory.
Evidence
For each agent: the mandate and its expiry, the evaluation results that justified its tier, the approval record, the full execution log, the exception and escalation record, the review findings and the changes made since. Assembled automatically where the platform allows it, and demonstrably retrievable within a defined period.
The test we apply. In an audit rehearsal, we pick an agent at random and ask the team to produce everything about it. If that takes more than a day, the estate is not under control — regardless of how good the policy is.
What each entry has to carry
| Field group | Contents |
|---|---|
| Identity | Agent identifier, version, service identity, business process supported, department, named owner and named supervisor |
| Composition | Model or models used, tools and plugins exposed, knowledge sources with their versions, external agents it depends on |
| Reach | Systems read, systems written, data classification of what it touches, geographic or residency constraints |
| Authority | Authority tier, threshold parameters, permitted action set, escalation conditions, mandate expiry date |
| Assurance | Evaluation set identifier, last regression result, approval record, open findings, last review date |
| Operations | Log location and retention period, incident history, kill-switch owner, dependency and supplier references |
What a challenger will ask about any agent
Not a team, not a role, and not "the system". A named individual, acting within a mandate granted by the steering committee, on a date, with the evidence that justified the tier at that point.
The evaluation set, the regression result and the threshold that were in force. Authority without an evidential basis is a preference, and a preference does not survive a challenge.
The execution log, the escalations, the exceptions and the review findings, retrievable for a specific period. This is the question that separates a governed estate from a documented one, and it is the one most organisations cannot answer quickly.
Inventory, classification, evidence. Everything else is an extension.
Three steps. Organisations that skip to policies and procedures have usually skipped all three, and their evidence pack is a reconstruction exercise rather than a record.
Inventory
Every AI system in use, including the ones nobody declared — the shadow tools your people adopted themselves. This is where most organisations discover surprises.
Classification
Each system classified on the two axes: data sensitivity and decision materiality. Classification determines which controls apply, so it must be arguable rather than assigned.
Evidence
For each control, a record that it operated, over a period, consistently. Produced continuously by the system rather than assembled when someone asks.
Controls that are exercised, not controls that are described
The difference between a governance programme that works and one that does not is almost entirely a question of testing. We design controls so they can be run on a schedule, and we keep the results, including the ones that failed.
Data and content safety
Prompt injection: untrusted content treated as instruction, with content separated from instruction by structure rather than by prompting. Privilege escalation: a tool call attempted outside the mandate, blocked at the tool boundary and logged as an attempted violation. Data exfiltration: outbound content checked against classification rules, with a DLP layer over both the agent's answers and its tool arguments.
Keys, sandbox and execution
KMS-managed secrets held outside the agent's context and rotated on a schedule, scoped to a single capability. Sandboxed execution for generated code, with a restricted file system, no ambient network reach and resource limits. Network egress controls declaring which destinations an agent may reach at all.
Logging and audit trail
Complete execution trace — inputs, retrieved sources with scores and provenance, tool calls with arguments and results, definition version, output, and the escalation decision. Immutable storage with a defined retention period, and per-request identifiers that let a user-facing question be traced to a specific execution and a specific rule version.
Human oversight in practice
Named supervisor per agent, with the authority to suspend. Escalation quality measured, not just escalation volume. Rehearsed kill switch exercised on a schedule and recorded. Fatigue control on review sampling, because a reviewer who approves everything is not a control.
Control testing, honestly
A control that is never exercised is an assumption. We test each control in the environment it will actually run in, on a cycle, and record the result — including the failures. The output is a small, unglamorous set of artefacts: what was tested, by whom, when, what happened, and what changed as a result.
This is also what makes the difference between an ISO 42001 management system and a policy manual. An assessor tests whether controls are executed. If your evidence shows a control that failed twice and was not remediated, you have a finding. If it shows a control that was exercised, failed, was remediated and re-tested, you have a working system — and the record says so plainly.
What an assessor asks first
| Question | What good evidence looks like |
|---|---|
| Show me the list of AI systems in use | A live inventory reconciled against licences, service accounts and live traffic, with a dated difference report |
| Who is accountable for this system | A named individual, not a team, with the mandate record and the review date |
| What happens if it goes wrong | A tested containment path, a named kill-switch holder, and a rehearsed notification route |
| Show me what it did last week | A retrievable trace for a specific execution, with sources, tool calls, rule version and escalation decision |
| How do you know it is still acceptable | A dated regression result against a defined threshold, plus live quality monitoring with a breach procedure |
| What are you doing about the open findings | A register with owners, due dates and evidence of closure — including the ones not yet closed |
Controls that are exercised, not controls that are described
This distinction is the whole discipline. A described control is an intention; an exercised control is a fact with a record and a date on it.
| Control that is described | Control that is exercised | How you tell the difference |
|---|---|---|
| "Access to the agent platform is role-based" | Role assignments are reviewed monthly, exceptions are logged, and the last three review records exist | Ask for the last review record and who signed it |
| "Sensitive data is not sent to external models" | An egress rule blocks it, an alert fires on attempt, and last quarter had two blocked attempts that were investigated | Ask how many attempts were blocked and what happened |
| "Humans approve material decisions" | The decision log shows the named approver for every material action, and the sampling review found two that should not have been approved | Ask what the sampling review found last quarter |
| "Agents are evaluated before release" | The regression suite runs on every change and the results are archived with the version | Ask to see a version and its evaluation record together |
The platform is a supplier, and it carries your risk
We are an authorised delivery partner for the platforms we deploy, and we hold ourselves to the same standard we would apply to any supplier: named controls, documented responsibilities, a contractual basis for access and audit, and a plan for the day the dependency changes.
Most enterprise AI risk assessments stop at the internal estate and treat the platform as a given. That is where the largest concentrations of unmanaged risk sit — shared infrastructure, shared model access, shared data paths, and a set of terms of use that nobody in the business has read against its own obligations.
- Access and audit rights — what the supplier may access, under what conditions, and whether you can evidence it.
- Sub-processor and location disclosure — where data is processed, who else processes it, and whether that is disclosed in a form you can reconcile with your own obligations.
- Retention and deletion — what is retained, for how long, on what basis, and how deletion is demonstrated rather than asserted.
- Change notification — how you learn about a material change in the platform before it affects your controls.
- Exit and portability — whether your evaluation sets, traces, logs and knowledge can be exported in a usable form. If they cannot, the dependency is stronger than your governance allows for.
Three tiers of dependency
| Tier | What it covers | What we verify |
|---|---|---|
| Platform | The agent runtime, model access, orchestration and evaluation services the estate runs on | Certification maintained, contractual responsibilities, change notification, data handling, exit plan |
| Model and data | Embedding, vector store, retrieval services, and any third-party data enrichment | Data location, retention, deletion, and whether the service may be used for the classification of data you hold |
| Enterprise systems | Internal applications and data stores the agents read and write through integrations | Who owns the integration, what it does when a schema changes, and whether the agent's write path is covered by the same change control as the application |
Portability is a governance control. The ability to export your evaluation sets, logs and business knowledge, and to re-point them at another runtime, is what keeps a supplier relationship a commercial relationship rather than a structural dependency.
The platform is a supplier, and it carries your risk
The platform is your supplier, and it carries your risk. The obligations do not transfer when you buy a capability — they transfer only to the extent a contract assigns them. Ask every supplier the same four questions: what will you not do, what do you log, who can see the logs, and what happens to the logs when we leave. A supplier that cannot answer those four has not been assessed, and their certificate does not assess them for you.
Hong Kong and Singapore ask different questions of the same evidence
Our group headquarters is in Singapore; our enterprise learning business is headquartered in Hong Kong SAR. Both jurisdictions are in scope for most of our clients, and the practical difference shows up in what an assessor or a regulator wants to see.
| Dimension | Hong Kong SAR | Singapore |
|---|---|---|
| Primary posture | Prudential and sectoral expectations, with a strong emphasis on documented, demonstrable controls and management accountability | Risk-based expectations with a comparable emphasis on governance, inventory and accountability across the enterprise |
| What clients ask us for | Audit-ready evidence packs, management system documentation, and evidence tied to named accountable individuals | Inventory, classification and control frameworks that stand up to internal audit and to group-level reporting across markets |
| Common failure | Controls documented by the group but not evidenced locally — the local business cannot show the activity actually happened in its own environment | Group-level frameworks with no local inventory, so the local estate is invisible to the group risk function |
| How we handle it | One control library, executed and evidenced per entity, with local retention of the evidence rather than a central file that the local regulator cannot inspect | One estate inventory across entities, with a single classification method and local accountability that reconciles into group reporting |
| Cross-border data | Data flowing between Hong Kong SAR and other group locations is a specific and live issue, and the transfer basis needs to be stated and evidenced rather than assumed | Regional hosting commitments and cross-border transfers need to be reflected in the data classification of each agent, not only in the infrastructure diagram |
The practical recommendation. Build one control library and one classification method across all entities, and execute the evidence locally. A single global document set with no local execution is the configuration that fails in both jurisdictions, for different reasons and in the same audit.
Hong Kong SAR and Singapore ask different questions of the same evidence
This is not a compliance-versus-ethics divide. It is a difference in emphasis, and an organisation operating across both will be asked to answer both sets of questions from one operational record.
- Supervisory expectation is strong on records and traceability
- Model risk and explainability get real examiner attention
- The expectation of documented human oversight in AI-assisted decisions
- Cross-border data handling is a live supervisory topic
- Evidence is expected to be retrievable on request, in a defined period
- Model governance frameworks are explicit and testable
- MAS-style expectations on model development and validation discipline
- Fairness and explainability carry equal weight with robustness
- FEAT principles are the reference point for responsible AI
- Expectations are outcome-oriented: prove the control worked
Who decides, who advises, who is independent
Governance fails through two predictable errors. The first is a committee with no decision rights, which discusses and recommends and changes nothing. The second is a committee where the team building the agents also decides whether the agents are acceptable, which approves everything and evidences nothing.
Our design separates the three, and enforces the separation in the role design rather than in a policy sentence.
AI steering committee — decides
Chairs the estate: what may be built, at what tier, with what capital, and whether a mandate is re-authorised. Meets on a fixed cycle with a decision log. Chaired by a business executive.
Central AI enablement team — enables
Owns the shared platform capability and publishes the paved road. Advises the committee and builds nothing that requires the committee's own approval.
Risk, audit and legal — advise independently
Set the control framework, review classifications, and hold the right to refuse a deployment. They do not report to the team that builds agents, because that independence is what makes a refusal credible.
Agent owner and supervisor — operate
Named individuals inside the business who own an agent day to day, hold the escalation destination and can suspend a live agent unilaterally.
What each meeting decides
| Cadence | Forum | Decisions taken |
|---|---|---|
| Weekly | Exception review with the agent owner | Threshold adjustments, case handling, additions to the regression set from confirmed failures |
| Monthly | Estate operating review | Scorecard review, control test results, new inventory entries, incident trends, cost attribution |
| Quarterly | Steering committee | Re-authorisation of every mandate, classification changes, capital allocation to the next units |
| Quarterly | Control rehearsal | Kill-switch exercise, containment path test, retrieval of random agent evidence, incident notification drill |
| Annual | Management review and internal audit | Management system effectiveness, risk appetite confirmation, the annual assurance report |
A governance regime that has no rehearsal in it is a governance regime that has never been tested. The quarterly rehearsal is the cheapest control we know and the one most often omitted.
Who decides, who advises, who is independent
Independence matters: whoever operates a control should not be the one testing it. Most weak AI governance arrangements fail on this single point rather than on the quality of the controls themselves.
| Task | R | A | C | I |
|---|---|---|---|---|
| Maintain the AI inventory | Governance team | Chief risk or compliance officer | Technology, business owners | Board |
| Classify each system | Business owner | Governance team | Risk, legal | Technology |
| Design the control set | Governance + risk | Chief risk officer | Technology, business | Audit |
| Operate the controls | Technology + business owners | Technology lead | Governance | Risk |
| Sample and test effectiveness | Internal audit | Audit committee | Governance | Board |
| Report to the regulator | Compliance | Chief compliance officer | Legal, risk | Board |
| Approve a new AI system for use | Business owner | Governance committee | Risk, technology, legal | All |
What we do not do
This is the practice most likely to overreach, because the word "compliance" invites a promise we cannot keep. We are precise about the line.
- We do not provide legal advice or make legal judgements. Whether a given use of AI is lawful in a given jurisdiction, how a regulatory filing should be made, and what your obligations are under a specific regime are questions for your counsel. We build the management system, the controls and the evidence that let your counsel answer them with facts.
- We do not issue certification. Certification is issued by accredited certification bodies against the standard, not by a consulting firm. We prepare you for that audit and support the management system afterwards. We will not sell you a certificate, and we will say so if a certificate is what you actually want.
- We do not sign off on a regulatory conformity assessment as your responsible party. That responsibility sits with the deploying organisation and its named accountable individuals. Our role is to make the technical file, the log and the evidence complete and retrievable so that your assessment can be completed by you.
- We do not build governance for agents that do not exist. A control framework designed around a hypothetical estate is a document. We start from the live estate, which means the inventory comes first and the policy follows what is actually running.
Governance is the last mile, not the first
Authority and operating model
Where the authority tiers and the decision rights that governance oversees are defined.
Runtime and observability
Where the audit trail, the log retention and the tool-boundary controls are produced.
Capability and evidence
Where the competence records and the digital-employee evidence pack are assembled.
Definitions and accountability
Where the ownership of a definition — and therefore of a control — is decided.
What we do not do
We do not provide legal advice and we are not a certification body. We will not tell you a control is compliant because a framework lists it. And we will not design a governance system so heavy that the business routes around it — which is the most common way well-intentioned AI governance fails in practice.
What this page answers
Every topic below is covered in the sections above, and each links to the page that goes deeper on it.
Ask us the question you cannot currently answer
A 45-minute working session with a governance lead. Tell us one question about your estate that you would struggle to answer today — what an agent did, who authorised it, or which rule applied. We will tell you what evidence it would take, and how long it would take to produce.