Malaysia has been governing AI through voluntary guidelines — the National Guidelines on AI Governance and Ethics, sectoral rules from Bank Negara, and general law. That is about to change.
On 10 July 2026, the National AI Office (NAIO), established in December 2024 under the Ministry of Digital, published a Public Consultation Paper setting out the proposed AI Governance Bill. Written feedback was invited until 31 July 2026, with a potential enactment target in the second half of 2026.
The shift is from voluntary to mandatory. Here is what is proposed, in plain language.
The scope is broader than most people assume
This is the first thing to understand, because a lot of organisations will assume it does not apply to them.
The proposed scope reaches AI systems that are placed on the market or put into service in Malaysia, designed, developed or used in Malaysia, or used by a Deployer established in Malaysia regardless of where the system is hosted.
That last limb is the significant one. Running a US-hosted SaaS AI tool from a Malaysian entity does not put you outside the Bill. If you are established here and you deploy the system, you are in scope wherever the servers sit.
The proposed three-tier risk framework
Obligations follow your role, not just the tier
The proposed framework allocates governance responsibilities according to the role a party plays and the level of control it exercises. A Developer building a model carries different duties from a Deployer putting it into service.
For most Malaysian businesses the relevant identity is Deployer — you did not train the model, you are using it in a real process affecting real people. Deployer obligations typically centre on how the system is used, what oversight exists, and what happens when it goes wrong, rather than on how the model was built.
The four mechanisms worth understanding
Baseline governance principles. A floor applying across tiers — transparency, accountability, human oversight in some form.
Risk-based tiering. The three tiers above, with obligations scaling to risk.
Incident reporting. A mechanism requiring notification when an AI system causes or risks causing harm. Practically, this means you need to be able to detect an incident and reconstruct what happened — which is an observability requirement dressed as a legal one. If you cannot answer "what did the system do and why" after the fact, you cannot report on it. See LLM observability.
Regulatory sandbox. A supervised environment for testing higher-risk systems. Genuinely useful for organisations doing novel work, and worth watching.
Oversight sits with a proposed Central AI Authority working alongside existing sectoral regulators — so Bank Negara does not stop mattering for financial institutions. Expect layered rather than replaced supervision.
What is not yet public
Being straight about the gaps matters more than filling them with speculation.
The consultation paper sets out architecture rather than final text. Penalty levels are not detailed in publicly available summaries. The precise contents of each tier — which specific uses count as unacceptable or high-risk — remain to be settled. Enactment timing is a target, not a commitment, and consultation feedback can move all of it.
Anyone telling you exactly what the compliance obligations will be is guessing. What is reasonably certain is the direction: risk-based tiering, role-based obligations, mandatory incident reporting, extraterritorial reach.
What to do now
None of this requires waiting for enactment. All of it is worth doing regardless.
- Inventory your AI systems. Most organisations cannot currently answer "which AI systems do we run, who owns each, and what can they affect?" You cannot classify by risk tier without this, and it is the longest-lead item.
- Provisionally classify by risk. Anything touching employment decisions, credit, healthcare, or vulnerable people should be assumed high-risk. Internal drafting assistants almost certainly are not.
- Identify your role per system. Developer or Deployer — and note it, because your obligations differ.
- Build incident detection now. You cannot report what you cannot see. Tracing, logging and alerting are prerequisites, and retrofitting them is far harder than starting with them.
- Document human oversight. For every consequential AI decision, who reviews it, on what basis, with what authority to override.
- Align with what you already have. If you are complying with PDPA obligations and, in financial services, BNM RMiT, a great deal of the groundwork overlaps. See our PDPA and AI guide.
The proportionate view
Two failure modes are worth naming. The first is treating this as an existential compliance event and freezing AI adoption — the Bill is explicitly designed to enable adoption within guardrails, not to prevent it. The second is assuming voluntary guidelines will simply continue and doing nothing, which leaves you retrofitting governance onto systems already in production.
The organisations that will find this straightforward are those that already know what they run, can explain what it did, and have a human accountable for each consequential decision. That is defensible engineering practice with or without a statute.
Our AI Security programme and AI Awareness programme cover AI governance, risk classification and incident readiness for Malaysian organisations — HRD Corp SBL-KHAS claimable.
