A claims model flags a policyholder for review. The head of claims asks who approved it, what it was tested on and whether anyone can explain why this customer was selected. Technology has a release record, risk has a policy, and the claims team has a queue to clear. Nobody can put the full answer together quickly.
That’s the practical test of an AI governance framework. Not whether the organisation has agreed on principles, but whether people can explain a decision, locate the evidence and correct the outcome when something goes wrong.
What an AI Governance Framework Really Is
An AI governance framework is the set of roles, policies and checks that determines how AI is approved, used, monitored and corrected inside an organisation. Think of it as the operating arrangements around the model, not another document sitting beside it.
For the insurer, those arrangements should connect the claims process to a named owner, approved data, validation results and an escalation route. When a customer challenges a decision, staff shouldn’t have to organise a detective hunt across technology, compliance and the business.
From a working model to a defensible decision
Once AI influences credit, claims, customer service or staff decisions, technical performance isn’t enough. Leaders also need to justify the purpose, explain the safeguards and show who can intervene.
Singapore’s Model AI Governance Framework was first published in January 2019, with a dedicated generative-AI framework proposed in January 2024. It provides voluntary guidance that firms must translate into internal standards, while the ASEAN Guide on AI Governance and Ethics, endorsed in February 2024, offers a shared regional baseline.
Start with existing governance rather than creating a parallel organisation. For teams connecting AI oversight to established data and technology responsibilities, PlotStudio AI’s overview of DMBOK, COBIT and ISO governance models provides useful context.
A framework is working when the person handling the customer’s question knows where to find the answer.
Clear up two misconceptions early. A policy PDF isn’t a framework, because it cannot approve a release, stop a system or resolve an appeal. Governance also needn’t obstruct experimentation: approved tools, clear boundaries and proportionate checks let teams experiment without negotiating every decision from scratch.
For broader organisational context, Ekipa’s practical articles on AI adoption and transformation explore the leadership and delivery work surrounding the technology.
Roles, Policies and Controls Explained
Policies are the rulebook. Controls are the checks that prove people follow it. Roles identify the people who answer when a check fails, or a model decision is challenged.
Take a rule prohibiting personal customer information in unapproved AI tools. A staff briefing explains the rule, an access restriction helps enforce it, and a named manager handles exceptions. Without that connection, the organisation has an expectation but no dependable way to apply it.
Core components of an AI governance framework
| Component | What it covers | Typical artefacts | Usual owner |
|---|---|---|---|
| Roles and accountability | Who approves, builds, monitors and answers for each AI system | RACI chart, named model owners | Board and executive sponsor |
| Policies and standards | Rules on acceptable use, data, vendors and human oversight | AI use policy, data standard, vendor clause | Risk, legal and compliance |
| Controls | Checks applied at each lifecycle stage | Intake checklist, validation tests, release gate | Model owner with risk partner |
| Risk classification | Sorts use cases into tiers carrying different rules | Tiering criteria, risk register | AI governance committee |
| Monitoring and incident response | Watches live systems and handles failures | Drift dashboard, incident playbook | Operations and technology |
| Evidence and documentation | Records what was decided, by whom and why | Approval logs, change history, model cards | Model owner and internal audit |
| Training and awareness | Makes the rules usable by people doing the work | Role-based training, team briefings | HR, L&D and team leaders |
The ownership column needs a distinction. Model owners produce and maintain operational evidence; internal audit independently assesses whether that evidence supports the organisation’s claims. Asking audit to build the records it later examines weakens that separation.
The same principle applies to monitoring. A dashboard isn’t a complete control unless someone receives the alert, understands the threshold and has authority to act.
Check for missing connections
Singapore’s first-edition Model AI Governance Framework organises guidance across four domains: internal governance, decision-making models, operations management and customer relationship management. Use those domains to challenge the completeness of your arrangements.
Strong committee oversight doesn’t compensate for a missing customer explanation process. Equally, a well-written disclosure won’t help if the business cannot identify which system influenced the outcome.
For financial workflows, distinguish judgement from execution. AI might interpret a document, but payment permissions, approval limits and transaction execution should remain tightly controlled. Loopfour’s explanation of why deterministic finance workflows hold up is useful context for deciding where predictable rules should constrain autonomous behaviour.
This table is a starting map, not a fixed organisational template. A bank handling lending decisions will place more weight on validation and customer consequences than a team using AI to draft internal workshop notes. Match the effort to the possible harm, while keeping ownership and evidence clear throughout.
Who Owns What From Board to Delivery Team
A committee can approve a use case, but it cannot own every operational decision. When the inventory names “the AI committee” as the system owner, staff still won’t know whom to call when a customer complains.
Separate oversight from delivery. The board sets risk appetite and reviews material exposure; an executive sponsor secures resources and resolves conflicts; the business model owner remains answerable for the system’s purpose and outcomes.
Who decides, signs off and escalates
| Role | Decides | Signs off | Escalates to |
|---|---|---|---|
| Board | Risk appetite and material AI exposure | Framework approval | Not applicable |
| Executive sponsor, such as CEO, CRO or COO | Priorities and resourcing | Framework and high-risk use cases | Board |
| AI governance committee | Risk tier and go or no-go for higher-risk use | Use-case approvals and policy changes | Executive sponsor |
| Business model owner | Purpose, data use and business outcomes | Release and change requests | AI governance committee |
| Technology and data lead | Architecture, data sources and monitoring setup | Technical readiness and incident fixes | Model owner |
| Risk and compliance | Challenges on controls and exceptions | Exceptions and regulatory reporting | AI governance committee |
| Internal audit | Scope of reviews | Assurance opinion | Audit committee |
| Managers and frontline staff | Day-to-day use within permitted rules | Nothing formal; flag issues | Model owner or risk |
Treat these as proposed decision rights to formalise through your own delegations. A committee’s use-case approval and an executive’s approval of material exposure are different decisions, not duplicate signatures.
The MAS FEAT Principles state that AI-driven decision-making should be approved by an appropriate internal authority and that firms remain accountable for internally developed and externally sourced models. Outsourcing the technology therefore doesn’t outsource responsibility for its use.
Make ownership visible in everyday work
Hypothetical example: a mid-sized insurer assigns its claims triage model to a business owner in the claims director’s team. A technology data lead manages technical operation, risk provides committee challenge, and the claims director sponsors the use case.
If referrals rise unexpectedly, the business owner assesses customer impact while the data lead investigates system behaviour. The incident playbook specifies who can suspend automated routing and move cases into a manual queue.
There’s a useful organisational parallel in the dairy company’s agile transformation supported by Ekipa. Its strategic framework, called the ‘9 Grids’, assigned each Management Team member a specific Grid, supported by Grid Leads and cross-functional teams. The relevant lesson is explicit ownership backed by delivery capacity, not copying the same structure into AI governance.
Supplier contracts need comparable clarity around change notification, evidence access, incident support and exit arrangements. Frontline managers also need a permitted-use guide and an escalation contact, rather than a committee charter.
Ownership check: Every AI inventory entry should name a person who can answer for the business outcome, not just a department.
Building Policies and Controls Teams Will Actually Use
Policies written only for audit tend to leave delivery teams guessing. “Use AI responsibly” doesn’t tell a product manager whether customer records can enter a service assistant or who approves a change to its instructions.
Keep the governing policy short, then attach operational standards where detail is necessary. Staff should be able to find the relevant rule without reading a document intended for model validators.
A policy outline you can adapt
-
Purpose and scope: State which teams, systems and supplier services the policy covers.
-
Definitions: Explain AI, automated decisions and human oversight in working language.
-
Roles and decision rights: Identify approval, suspension and escalation authority.
-
Permitted uses: Describe approved activities and their boundaries.
-
Prohibited uses: Make disallowed tools, data handling and decisions explicit.
-
Data rules: Specify how personal and sensitive information may be accessed, processed and retained.
-
Approval routes by risk tier: Identify the evidence required before approval.
-
Monitoring and incident reporting: Define alerts, response responsibilities and reporting channels.
-
Exceptions process: Require a rationale, compensating controls, an owner and an expiry.
-
Review date and owner: Assign responsibility for keeping the policy current.
Write rules that teams can test. “Only approved data fields may enter the assistant” is actionable when the approved fields are listed, and the application rejects everything else.
Controls by risk tier
These are suggested starting points, not regulatory classifications or mandated review periods. Adjust them for your sector, materiality and the consequences of failure.
| Risk tier | Example use | Minimum controls | Approval | Suggested review |
|---|---|---|---|---|
| High | Credit decisions, claims triage or eligibility affecting individuals | Human review, subgroup testing, explainability note, full documentation | Governance committee or board | Quarterly |
| Medium | Customer service assistant with escalation, internal forecasting on customer data | Pre-release testing, monitoring, data lineage record | Head of function, reported to committee | Every six months |
| Low | Internal drafting or summarising with no personal data | Usage rules, logging, staff training | Team lead, documented | Annually |
| Prohibited | Uses the firm has ruled out, such as unapproved public tools with client data | Blocked at access level, staff briefed | Not approved | Checked at each audit |
The trade-off is capacity. Human review adds little protection if reviewers receive an unexplained score and face pressure to approve it quickly. Give them relevant evidence, authority to override and a manageable workload.
The MAS FEAT guidance on validation calls for regular reviews of data and models for accuracy and relevance, and checks that deployed behaviour matches intended behaviour. Build that into a recurring process: validate before release, monitor production outcomes, investigate drift and record remediation.
For generative-AI inputs, teams can explore AI prompt moderation from Veevoo, Inc. when considering controls against inappropriate or sensitive submissions. Such controls supplement access restrictions and data rules; they don’t replace them.
Translate each control into a backlog acceptance criterion. For example: the release cannot proceed until the owner approves subgroup test results and the fallback queue has been exercised. Delivery teams can then plan the work instead of discovering governance requirements at the release gate.
Proving AI Decisions Can Be Reconstructed
A customer disputes an AI-assisted decision: a declined claim, a flagged transaction, a credit limit changed without explanation. Risk is asked to show what happened. A policy binder cannot answer that question; only records can. The organisation needs to establish which inputs the system received, which model version produced the output, which steps it took and who approved the result.
TechCoffeeHouse’s report on surveyed Singapore businesses states that 94% were using or piloting multi-step AI systems, yet only 29% could produce an audit trail showing how AI-driven decisions were made; only 70% had explicitly assigned responsibility for AI outcomes, while technical model complexity (66%), platform integration (50%) and tracking third-party AI tools (49%) were identified as major scaling priorities.
Evidence to keep for each AI decision
| Evidence item | What it proves | Common gap |
|---|---|---|
| Prompts and inputs | What the system was asked and with what data | Inputs overwritten or not logged |
| Model and version | Which model produced the output | No version tag tied to the release |
| Data lineage | Where the data came from and how it was transformed | Third-party data with no source record |
| Tool calls and steps | What an agentic system did between input and output | Only the final answer is stored |
| Human approvals and overrides | Who accepted or changed the outcome | Approvals kept in email or chat |
| Exceptions and waivers | Where normal rules were set aside and why | No expiry or review date |
| Post-deployment changes | What changed after launch and who approved it | Changes made without a change record |
A model card describes a model and its limitations at a point in time. An agentic workflow needs an additional execution trail because the outcome may depend on retrieved documents, tool responses, routing decisions and intermediate actions.
Say an assistant reads a claim, retrieves policy wording and recommends further investigation. Retaining only its final recommendation leaves the reviewer unable to establish whether it retrieved the correct policy or acted on an outdated document.
Test the trail in practice
Use a shared decision identifier to connect application events, model calls, source records and human actions. Restrict access to those records and set retention rules that balance audit needs with privacy obligations. Logging everything indefinitely adds exposure without improving governance.
Reconstruction means establishing the inputs, system state, actions and approvals that supported the original outcome. Reproducing identical wording is rarely the point, and with probabilistic systems it may not even be possible.
Practical rule: Evidence should be retrievable by the person investigating the decision, not only by the engineer who built the system.
Ekipa’s AI governance frameworks help teams connect governance conversations to this kind of operational evidence.
I would run a quarterly reconstruction exercise: select a material decision and give the team an agreed retrieval deadline. Record missing evidence, assign remediation and retest. When the trail breaks, fix instrumentation and ownership before polishing the policy.
How to Roll Out the Framework Step by Step
Roll out small, finished pieces rather than announcing a large policy launch. A completed inventory entry with an accountable owner is more useful than a thorough framework nobody has applied.
Start with existing risk, procurement and delivery processes. Add AI-specific checks where necessary instead of sending teams through an entirely separate approval system.
Give each step an owner and an output
-
Name an accountable executive and a working group: I recommend three to five people from business, risk and technology, with protected time rather than informal participation. The executive sponsor owns this step; its output is a mandate with decision rights and available capacity.
-
Inventory actual AI use: Include supplier features, embedded assistants and staff using public chatbots with work information, because an application register alone won’t reveal all usage. Business heads own discovery, supported by procurement and technology; the output is a consolidated register.
Use these fields for every entry: use-case name, business owner, purpose, people affected, data types, vendor or internal build, level of automation, risk tier and last review date. Add evidence locations and dependencies where they help investigation.
-
Classify each use case: Ask who could be affected, whether actions are automated, how sensitive the information is and how readily an outcome can be reversed. The governance working group owns the criteria; the output is an agreed tier and rationale for each entry.
-
Write the minimum policy set: Turn actual inventory findings into clear boundaries, approval routes and exception rules, rather than drafting for imagined use cases. Risk and legal own the policy, with delivery-team input; the output is an approved policy supported by usable checklists.
-
Pilot the arrangements: I would choose two or three live uses with different risks and follow them through approval, monitoring and evidence retrieval. Model owners run the pilot; the output is completed evidence packs and a prioritised list of process fixes.
-
Brief people by role: Reviewers need override scenarios, managers need escalation guidance and staff need examples of acceptable data handling. HR, L&D and functional leaders own this step; its output is demonstrated understanding, not merely attendance.
-
Exercise incident response and reconstruction: Simulate a failure and rebuild a real decision to expose gaps between departments. Operations coordinates the drill with model owners; the output is an action log covering containment, customer handling and missing evidence.
-
Establish leadership review: Set a quarterly review of material exposure, overdue actions, exceptions and incidents, with results reported to the board. The executive sponsor owns the report and ensures decisions become assigned work.
Avoid an administrative launch
-
Policy before discovery: Don’t approve rules before understanding the systems people already use.
-
An untested process: Don’t skip the pilot because the documents look complete.
-
Email-only training: Don’t mistake distribution for the ability to handle a difficult situation.
Adoption requires managers to change routines, not just acknowledge a policy. Ekipa’s guidance on organisational change management provides useful context for building those changes into everyday work.
Frequently Asked Questions
Is an AI governance framework legally required in Singapore?
Singapore’s Model AI Governance Framework is voluntary guidance, not a standalone legal mandate. Financial institutions should account for MAS’s FEAT expectations and assess the regulatory obligations applying to their activities. Voluntary guidance doesn’t remove existing responsibilities around customer treatment, data handling or oversight.
Do smaller firms need every component?
They need the essential functions, but not a separate committee or document for each. Start with a complete inventory, a named accountable owner, a short policy and an activity log. Add independent challenge and stronger controls as the consequences of AI use increase.
How is this different from an AI ethics statement?
An ethics statement describes what the organisation values. A framework identifies who checks a use case, what evidence they retain, who can stop it and how affected people can challenge an outcome. The difference becomes visible when someone must act.
How often should the framework be reviewed?
As a starting recommendation, review high-risk uses quarterly, medium-risk uses every six months and low-risk uses annually. Review the overall framework at least annually, and reopen relevant assessments when the purpose, data, automation or supplier changes materially. A scheduled review shouldn’t delay action on a known problem.
Start With One Use Case and a Named Owner
Choose an AI use case that is live or close to launch, preferably one affecting customers or a regulated decision. Name its business owner this week and give that person two weeks to complete the inventory entry, agree the risk tier and assemble the evidence needed to investigate an outcome.
Then test a decision. The exercise will reveal whether the business can reach the right records, whether technology retains them and whether reviewers have authority to correct mistakes. Those findings give leadership a practical investment agenda.
Ekipa’s AI Strategy & Advisory provides ground-level execution planning, leadership alignment and governance frameworks for executive teams turning strategic plans into 90-day cycles. Its Agile Roadmap Planning Session reviews the operating model and identifies delivery bottlenecks with transformation leads.
Support can help, but the starting decision remains yours. A named owner and one real use case will teach you more about governance than another month of drafting.
Ekipa helps leadership teams connect AI governance to execution planning, team capability and delivery. If your next challenge is turning approval rules into working backlogs and evidence your teams can retrieve, visit Ekipa to explore a practical starting point.