writing

NC · article

AI Strategy for Boards in Malaysia: What Directors Should Ask, Own and Verify

A decision guide for directors, chairs and company secretaries of Malaysian listed and large private companies who must oversee AI without being technical: the questions to put to management, what belongs at board level, and where MCCG, AIGE and the Securities Commission's 2026 proposals actually stand.

by Nic Chin11 min readMalaysia / AI Governance

part of Hiring and Scoping AI Work · 9 articles

The short answer: a board’s AI strategy is not a technology plan. It is a decision about how much AI risk the company will accept, which uses of AI are material enough to be approved and monitored at board level, and what evidence management must produce to show those systems work. Most Malaysian boards already have the governance machinery for this under the Malaysian Code on Corporate Governance; what they usually lack is the right questions and the right evidence.

What Does AI Strategy for Boards in Malaysia Actually Mean?

There are two different jobs that both get called “AI strategy”. The first is management’s job: choosing where AI creates value, sequencing the work and building the capability. I cover that in the enterprise AI strategy guide. The second is the board’s job, and it is the subject of this article: oversight. The board does not choose the model or the vendor. It decides the limits within which management may use AI, approves the uses that could materially hurt the company if they failed, and holds someone accountable for each of them.

A board that spends its time reviewing a management strategy deck is doing management’s job a second time, and nobody is doing the board’s job at all.

What Do Malaysian Rules Currently Expect of Directors on AI?

Less than many directors assume, and more than many management teams acknowledge. “The regulator requires it” is said far more often than it is true.

The MCCG already covers AI risk, without naming it

The Malaysian Code on Corporate Governance (as at 28 April 2021) does not mention artificial intelligence. It does not need to. Practice 10.1 says the board should establish an effective risk management and internal control framework, and the guidance to it asks the board to determine the company’s level of risk tolerance and to discuss in its disclosure how key risk areas, including operations, regulatory compliance, reputation and cyber security, were evaluated. An AI system that drafts customer correspondence, scores credit or summarises regulatory filings sits squarely inside every one of those categories. The Code works on an “apply or explain an alternative” basis: boards are expected to explain how they apply it, and that explanation is what your governance disclosures are read against.

The Securities Commission has proposed explicit expectations

On 3 July 2026 the Securities Commission opened a consultation on proposals to strengthen the corporate governance ecosystem, running to 31 July 2026. One of its four proposals seeks feedback on expectations for board oversight of technology, including disclosures on the use and governance of technology and AI. That is a proposal, not a rule, and the final form is not yet known. But a board that can already describe its AI oversight will not be drafting it in a hurry.

The national AI guidelines are voluntary, and useful anyway

MOSTI’s National Guidelines on AI Governance & Ethics (AIGE), published in September 2024, state plainly that they are voluntary and that Malaysia has not enacted specific AI legislation. They set out seven principles (fairness; reliability, safety and control; privacy and security; inclusiveness; transparency; accountability; and the pursuit of human benefit and happiness) with separate guidance for end users, policy makers, and developers and technology providers. Most companies are end users and deployers, not developers. The part a board should borrow is the idea of “human-in-command”: the capability to oversee the overall activity of an AI system and decide when and how it is used. In board language, that means someone can switch it off, and everyone knows who.

Financial institutions have an extra signal

Bank Negara Malaysia issued its Discussion Paper on Artificial Intelligence in the Malaysian Financial Sector on 5 August 2025, with feedback closing on 17 October 2025. It is a discussion paper, not a policy document, but boards of banks, insurers and takaful operators should treat it as the direction of travel. The industry’s own directors seem to agree the gap is real: the FIDE FORUM and Accenture Malaysia report released in June 2026 found that while 71% of Malaysian banks had implemented at least one AI application, only 17% of the financial institutions surveyed had scaled strategic AI initiatives, and it named limited board-level AI literacy among the barriers.

What Questions Should a Board Ask Management About AI?

Directors do not need to understand how a language model works to oversee one. They need questions whose answers are hard to bluff. The table below is the set I would put to any management team presenting AI to a board. The middle column is what a credible answer sounds like; the right-hand column is the answer that should end the agenda item until management comes back with more.

Questions a board should ask management about AI, with what a good answer sounds like and what a red-flag answer sounds like
QuestionA good answer sounds likeRed-flag answer
Which AI systems are in use today, including ones inside vendor software?A register, with an owner and a risk rating per system“We are still at pilot stage” while staff use public tools daily
Which of these could cause material harm if wrong?A short list, with the harm named: customer, financial, regulatory“None, a human always checks”, with no evidence of how often
How do you know it works?A fixed test set, a pass threshold agreed before launch, and the latest resultA demo, a vendor benchmark, or user satisfaction scores
If a regulator asked why it produced a specific output, could we answer?Yes: inputs, sources and model version are logged and retained“The model is a black box”
Who can switch it off, and how fast?A named role, a documented procedure, a tested rollback time“IT would handle that”
What personal data does it touch, and where does that data go?A data flow per system, with PDPA handling and vendor terms checked“The vendor is compliant”, with no one having read the terms
What happens when the vendor changes the model underneath us?Re-testing against the same test set before the change goes liveSurprise at the question
What has gone wrong so far?A candid incident and near-miss log, with fixes“Nothing”. Every live AI system has failure cases

The question that separates prepared management teams from unprepared ones is the third. “How do you know it works?” has a precise answer in well-run AI programmes: an evaluation set of real cases, frozen before launch, with a threshold agreed in advance. I explain how that artefact is built in how to build an LLM evaluation set. A board does not need to read the test set. It needs to know one exists, who agreed the threshold, and what the latest score was.

What Belongs at Board Level, Management Level and Technical Level?

A board that tries to oversee everything about AI oversees nothing. The model below is the split I recommend. It maps onto the structure the MCCG already assumes: the board sets risk tolerance and seeks assurance, management runs the controls, and specialists produce the evidence.

Board AI oversight model: what belongs at board level, management level and technical level across six oversight areas
AreaBoardManagementTechnical
Risk appetiteSets it: where AI may decide, advise, or not be usedTranslates it into policyEnforces it in system design
Material use casesApproves the register and each material entryMaintains the register, proposes additionsDocuments each system’s scope and data
AccountabilityRequires one named executive owner per material systemOwner answers for outcomes, including the off switchOperates and can execute the rollback
MeasurementReceives results against pre-agreed thresholdsAgrees thresholds before launchBuilds and runs the evaluation
IncidentsSets escalation criteria; hears material incidentsTriage, customer and regulator responseAudit trail to reconstruct what happened
Third-party AIApproves reliance on critical AI suppliersContracts, data terms, exit plansRe-tests when a vendor changes the model

Two rows deserve emphasis. Third-party AI is the one boards most often miss, because the largest AI exposure in many Malaysian companies is not a system they built but a feature switched on inside software they already licensed, or a general assistant rolled out to staff. Accountability is the one that fails quietly. A system owned by a committee, or by “the AI team”, has no owner. The AIGE accountability principle says those deploying AI should take responsibility for its proper functioning; the board makes that real by attaching a name to it.

Why Do Boards Over-Trust Strategy Decks and Under-Ask for Evidence?

This is the practitioner point I most want directors to take away. In my experience, boards over-index on AI strategy documents and under-index on evidence that a deployed system actually works. A strategy deck is easy to review because it is written for the board. The evidence that a system works is written for engineers, so it rarely reaches the boardroom, and so it is rarely produced to a standard anyone would defend.

The difference between the two is concrete. On a pharmaceutical SaaS platform I hardened ahead of enterprise pilots, the work was not judged by a roadmap. It was judged against 24 acceptance criteria, all 24 of which had to pass with evidence. That evidence included an audit trail of more than a dozen critical actions, including every AI query, retained for 365 days in append-only logs; input and output guardrails with a configurable blocking or logging mode; and a Kubernetes rollback validated at under two minutes. Each of those maps directly onto a board question in the table above: can we reconstruct what it did, does it have limits, can we switch it off. None of it would have appeared in a strategy deck.

The same principle shapes how I build products. SystemAudit, my code-analysis platform, uses a two-layer design: a deterministic analysis runs first and produces hard findings with file and line references, and the language model is only allowed to interpret those findings, not contradict them. The reason is governance, not engineering taste. A report meant to be read by investors or a board has to rest on something that does not change when you ask twice.

When an AI programme disappoints, the cause is rarely the strategy; it is that nobody could show the system worked before it was relied upon (the architectural reasons are in why AI projects fail). For every material AI system, ask to see the evidence, not the plan.

How Should AI Risk Be Reported to the Board?

Good AI risk board reporting is short and repetitive by design: the same five items every quarter, so that change is visible.

  1. The material use case register, with a named owner and risk rating for each entry, and anything added or retired since the last report.
  2. Performance against threshold for each material system: the latest evaluation result against the figure agreed before launch.
  3. Incidents and near misses, including those caught by human reviewers, because a reviewer catching errors is evidence of a system producing them.
  4. Third-party changes: new AI features in licensed software, vendor model changes, and whether re-testing happened.
  5. Appetite breaches: any use outside the limits the board set, and what was done.

If the company has not yet decided which uses of AI are material, that is the first piece of work. A useful starting point is to map where generative AI is already being used or proposed, which is the ground covered in generative AI use cases in Malaysia, and then apply the board’s risk appetite to that list. The most common unrecorded use is staff tools such as ChatGPT and Copilot; what management should have in place for those is set out in rolling out ChatGPT Enterprise or Copilot under PDPA.

Frequently Asked Questions

Is there a law in Malaysia that requires boards to oversee AI?

Not a specific one yet. The National Guidelines on AI Governance and Ethics published by MOSTI in September 2024 state that they are voluntary and that Malaysia has not enacted specific AI legislation. What already applies is the general duty in the Malaysian Code on Corporate Governance for the board to establish an effective risk management and internal control framework, which covers AI once it touches operations. The Securities Commission opened a consultation on 3 July 2026 on expectations for board oversight of technology and AI, so explicit expectations may follow.

Does a board need a technical director to oversee AI?

No. A board needs directors who can ask for evidence and recognise when they have not received it, which is a governance skill rather than a technical one. Where the board lacks confidence in reading that evidence, an independent technical review of the material systems is usually a better investment than recruiting a technologist to the board, because it produces a finding the whole board can act on.

Which committee should own AI oversight?

Usually the committee that already owns risk: a Risk Management Committee where one exists, otherwise the Audit Committee. The MCCG already places risk management and internal control with the board and its committees, so AI fits the existing structure rather than needing a new one. The board as a whole should still set AI risk appetite and approve material use cases.

How often should AI be on the board agenda?

The material use case register and AI incidents should reach the responsible committee at least quarterly, alongside other operational risks, with a full board review of AI risk appetite once a year. Any AI incident with customer, regulatory or financial impact should be escalated between meetings on the same basis as any other serious incident.

Does the BNM discussion paper on AI apply to my company?

Bank Negara Malaysia issued its Discussion Paper on Artificial Intelligence in the Malaysian Financial Sector on 5 August 2025, with feedback closing on 17 October 2025. It is a discussion paper aimed at the financial sector, not a binding rule, and it matters most if you are a financial institution or a supplier to one. Boards outside the sector can still use it as a signal of where supervisory thinking is heading.

What should an AI report to the board contain?

Five things: the register of material AI use cases with a named owner for each, current performance against a pre-agreed evaluation threshold, incidents and near misses since the last report, changes to third-party AI suppliers or models, and any use case that breached risk appetite along with what was done about it. A report that contains adoption statistics but none of these is a progress update, not oversight.

Oversee the Evidence, Not the Enthusiasm

The regulatory direction is clear enough to act on without waiting for the final shape of the Securities Commission’s proposals. The boards that will be comfortable when those expectations land are the ones that already know which AI systems matter, who owns each one, how each is measured, and who can switch it off.

Where a board wants independent assurance that a material system does what management says, that is the work behind AI assurance. Where the gap is senior technical leadership to produce that evidence in the first place, a fractional AI CTO is often the right shape. You can read more about how I work with Malaysian companies, or book a consultation to talk through what your board should be seeing.

Ready to discuss your AI project?

Book a free 30-minute discovery call to explore how AI can transform your business. Or if you already have a codebase, get an instant architecture report at SystemAudit.dev No technical knowledge needed, results in 3 minutes.

About the Author

Nic Chin is an AI Architect and Fractional CTO who helps companies design and deploy production AI systems including RAG pipelines, multi-agent systems, and AI automation platforms. He has delivered enterprise AI solutions across the UK, US, and Europe, and provides AI consulting in Malaysia and Singapore.