Overview of the Proposed Malaysia’s AI Governance Bill

The AI Law Is Coming to Malaysia. Here’s What It Actually Means for Your Business

On 10 July 2026, the National AI Office (NAIO) quietly published something every Malaysian business owner should read but usually don’t, which is the Public Consultation Paper for the proposed AI Governance Bill.

I am actually glad that there’s some reporting about this, and some professional services domain experts also providing some overview on this. So far I haven’t really seen much AI / IT domain experts sharing about it yet, maybe they will wait for the final bill since this is just a draft.

I read all of it. The consultation paper, the summary deck, the questionnaire. Not because I enjoy reading government documents on a weekend (a bit), but because this Bill is about my passion and my work.

Years ago when AI started to be mass adopted by the public, and knowing what AI is capable of, and the impact (not because of Terminator movies). My concern was the AI governance & policies. I still remember when Elon Musk co-sign “The 2023 Moratorium Letter” with Future of Life Institute, and his rally for strict government oversight.

So this is my rough overview on what the Bill proposes, what it means for SMEs and business owners, what responsibilities and risks you need to take note of, some of my thoughts, and how you can have your say before the consultation closes on 31 July 2026.

Disclaimer:

This is a consultation paper, not the final law. Things will change. Nothing here is legal advice. But the direction is now clear, and direction is enough to act on.

Why Is Malaysia Doing This?

Right now, AI in Malaysia is governed by a patchwork. We have the AIGE (national AI ethics guidelines that are voluntary), the PDPA for personal data, sector rules from BNM or SC if you’re in finance, and a lot of grey space in between.

The government’s own paper says it plainly: the current landscape risks “differing standards and approaches” across sectors, and current approaches are reactive — the rules only bite after harm is done.

The Bill proposes to fix that with three moves:

  1. Central institutional oversight — one national authority, working with existing regulators.
  2. Principle-based rules — a stable set of principles in law, with the practical details filled in later through guidelines and codes (“adapt and learn,” in their words).
  3. A risk-based approach — heavier obligations for higher-risk AI, lighter touch for low-risk use, so innovation isn’t strangled.

Honestly? As a framework, this is sensible. I am not a lawyer or compliance officer, but this does seem to mirror what serious jurisdictions are doing.

As usual, the devil is in the details.

The Two Words That Will Matter Most: “Developer” and “Deployer”

The Bill regulates the people connected to an AI system based on their degree of control over it, mainly split into two roles:

A Deployer is the person or organisation that causes an AI system to operate in the real world — who decides whether, where, how and under what conditions it’s used.

Basically,  if your business uses AI like a chatbot answering customer WhatsApp messages, AI features inside your accounting software, an invoice-extraction tool, even AI you switched on inside Microsoft 365, you are a Deployer.

The Bill isn’t only for tech companies. It’s for businesses that are using an AI powered system or the accounting firm using AI to draft client letters.

A Developer is anyone who “materially shapes” what the AI system can do. And here’s the part most commentary has missed: the paper explicitly says this includes not just the party that trains the model, but also the party that adapts it for a specific use case, integrates it into a wider system, or modifies it after deployment.

When someone builds an App or a custom AI workflow for your business like connecting an AI model to your invoicing process, tuning it for your use case and so on. Under this definition, they may carry Developer-level duties.

So might your IT vendor. So might your own team. 
So might be your self, if you vibe coded an AI powered tool for your business.

I really do think the definition needs more refinement, but I’ll come back to why later. But the practical takeaway for owners is this:

Every AI system in your business now has a role question attached.
Who built it, who adapted it, who runs it.
And you should know the answer for each one.

And no, the “personal use” exemption doesn’t save you. That exemption covers individuals using AI for personal, family or household affairs. Your staff using ChatGPT for company work is business use.

It’s in scope.

Pillar 1: A Central AI Authority

The Bill proposes a Central AI Authority with three functions:

  • AI Safety — maintaining the risk framework, supervising assessments, supporting testing, running incident reporting.
  • Investigation and Enforcement — fact-finding when AI incidents occur, issuing directions and orders, imposing interim risk-control measures and administrative penalties.
  • AI Enablement — developing guidance, templates, training and practical support, and running AI sandboxes.

It will work through Sectoral Leads, like existing regulators (think BNM for banks, SC for capital markets) who translate the national framework into industry rules.

What this means for you: one more regulator that can affect your business but also this is good news. A body whose job includes producing free official guidance and templates to help you comply.

For SMEs, the Enablement function may end up being the most useful part of this whole Bill. Watch for it.

Pillar 2: Five Principles You’ll Be Expected to Follow

The Bill sets out five AI Governance Principles. Developers and Deployers must have “due regard” for them, meaning you actively apply them, proportionate to your system’s nature and impact.

  1. Human dignity and human agency. Important decisions can’t be placed entirely beyond human review. If AI affects people like hiring, credit, pricing, eligibility then a human must genuinely stay in the loop as a real reviewer and checkpoint.
  2. Transparency and explainability, proportionate to risk. You should be able to explain, at a level matching the stakes, what your AI does and its limits to your team, your customers, and if needed, a regulator. No hiding behind AI’s black box.
  3. Clear accountability through traceability and redress. Responsibility must sit with identifiable persons , which means you cannot blame the AI. And you must be able to suspend or withdraw an AI system when necessary. Basically, every AI system needs a named administrator that can shut it down forcefully.
  4. Safe and secure use. Anticipate risks before they happen; systems must withstand misuse and failure.
  5. Responsible data governance. The data feeding your AI must be lawful, properly sourced, and protected. If your AI touches personal data, this principle and the PDPA hold hands.

Notice something? They are quite common and are what a well-run business does anyway, but the Bill just makes “we never thought about it” an unacceptable answer.

The key word for SMEs is proportionate. A 12-person trading company is not expected to govern AI like a bank. But proportionate is not zero. There’s a standard now, and sure will be getting a lot of refinement further down the line.

Pillar 3: The Risk Framework

The Bill anchors risk on four categories of harm:

  • Death
  • Bodily injury
  • Unlawful deprivation of fundamental liberty
  • Contravention of any written law

Then it sorts AI systems into three tiers:

  • Unacceptable (AI deployed with intent to cause harm will be prohibited outright),
  • High Risk (no bad intent, but real risk of harm then these face structured obligations: risk assessment, documentation, internal controls, human oversight, monitoring), and
  • Low Risk (baseline due-regard only).

Most SME owners will read “death” and “bodily injury” and relax, since my invoice bot isn’t going to injure anyone lah. Fair. But look at the fourth category again: contravention of any written law.

That means:

An AI system that causes a breach of the PDPA is causing a defined “AI harm.”An AI hiring tool that discriminates in ways employment law prohibits -> “AI harm”.A chatbot that misleads customers in ways consumer law prohibits -> “AI harm”.

For the average Malaysian SME, this is where your real exposure lives. Not robots causing injuries, your everyday AI quietly stepping on laws that already exist.

The staff member pasting customer data into a free AI tool isn’t just sloppy practice anymore; under this framework, it’s the raw material of a report-able AI harm.

Pillar 4: Incident Reporting (Including Near Misses)

The Bill proposes a structured AI incident reporting system. An incident isn’t just a disaster, because it includes failures, weaknesses, misuse, unexpected effects, and notably, near misses. Meaning including the times something almost went wrong.

Reporting can come from Developers and Deployers — and from public complaints through the Authority’s channels.

Which means, your customers, or even if not your customer, will have a hotline to complain about your AI.

I actually like the near-miss reporting, with AI so fresh, it is crucial information. The near miss you record today is the incident you prevent next quarter. But it only works if businesses aren’t punished for honesty, which is a point I’m raising in my own consultation feedback.

What to do now, and it costs almost nothing: 

Start an AI incident log.

A simple record like date, what happened (including the almost-happened), what you did, what you changed. When reporting rules eventually arrive with thresholds and deadlines, the businesses with a maintained log will adapt in a week.

Pillar 5: The AI Sandbox — Genuinely Good News for SMEs

The Bill proposes an AI Sandbox: a supervised environment to test AI systems under real-world conditions with regulatory oversight. Which will be evaluating accuracy, fairness, robustness and safety, running limited pilots, even testing under relaxed regulatory settings.

Here’s the sentence that matters: the paper says this may be “particularly beneficial for small and medium-sized enterprises that may otherwise lack the resources to navigate complex regulatory requirements.”

The government put SMEs in the sandbox’s purpose statement. This is actually very good news, the Good. These resources shouldn’t be limited only to KL-centric, big-company affairs. A manufacturer in Bukit Mertajam or a services firm in Ipoh should be able to participate remotely, affordably. If done right, the sandbox becomes the cheapest assurance evidence an SME can get.

So What Should You Actually Do Now?

You don’t need to buy anything today. You just need to be aware and start things:

  1. Inventory All of your AI. Including AI features embedded in software you already pay for, and the “shadow AI” your staff use unofficially. You cannot govern what you haven’t listed. (In my AI assessments, companies typically find 3–5x more AI in use than the boss knew about.)
  2. Answer the role question per system. Who built it, who adapted or integrated it, who operates it? You’re the Deployer; know who your Developer is — and get it in writing when you engage vendors. (Which is why I always ask Vendor what AI provider and AI model they will be using)
  3. Write basic usage rules. Usually just one page which consists of what staff may and may not put into AI tools, which tools are approved, what setting to configure for better privacy..
  4. Put a human in the loop for people-and-money decisions. Anything touching hiring, credit, pricing, eligibility, or customer-facing output gets a named human checkpoint.
  5. Start the incident log. Including near misses. Just start an excel or spreadsheet today. Which Date, Time, Incident, Solution, Remark columns.
  6. Ask your AI vendors two questions: “Under the proposed Bill, are you the Developer for this system and will you put that in writing?” and “What are your data-ownership and exit terms?” Watch how they answer. The ones who go quiet are telling you something.

Notice none of these six requires the Bill to pass. They’re a good practice with or without a law. The law when finalized will just convert them from optional to expected.

Some of My Insights

What I genuinely like: 

The risk-based, proportionate approach; principles in law with details in adaptable guidelines; a central authority with an explicit enablement duty; near-miss thinking; and a sandbox with SMEs named in its purpose. This is a more thoughtful starting point than many countries managed. Is actually quite impressive.

What concerns me, and what I will submit my feedback on:

First, the Developer definition is too wide as drafted.

Capturing anyone who “adapts” or “integrates” AI could sweep in every IT vendor doing routine configuration and definitely will terrify the local integrator ecosystem Malaysia’s AI ambitions depend on.

I’ve proposed a materiality threshold (training, fine-tuning, or changing a system’s purpose or behaviour = Developer; routine deployment and configuration = supporting the Deployer) and a safe harbour for low-risk integration work.

I say this as someone the clause would definitely affect. I’m not asking to escape responsibility, but have a clear line to follow, so responsibility lands where control actually sits.

Second, “contravention of any written law” needs a materiality qualifier.

As drafted, any minor technical breach becomes an “AI harm,” potentially pushing routine SME systems into high-risk treatment. Anchor it to material harm to persons.

Third, SMEs need worked examples, not just principles.

“Due regard, proportionate to impact” is right in spirit but a 12-person firm needs to see what it looks like at their size. The Enablement function should publish plain-language guidance with SME scenarios, in every sense of the word plain. E-Invoice documentation actually is quite a good example of this, hope there will have similar User Guide, and Industry Specific Guide, and extensive FAQs later on.

Fourth, report once.

An SME shouldn’t have to file the same incident with the Central Authority, a Sectoral Lead, and the PDPA regulator separately. One report, then it is routed internally which makes more sense.

Whatever the final text says, the direction is set. Duty-holder roles, due-regard principles, harm-tiered risk, incident reporting. Businesses that prepare early will not panic later on.

Have Your Say — Before 31 July 2026, 5:00pm

Again, this is a public consultation. The government is literally asking what you think and if SME owners stay silent, the only voices shaping this law will be big tech, big banks, and big law firms. The people this Bill will land on hardest, week to week, are you and me.

Three ways to submit:

  • Google Form (the easy way): about 45 minutes, six focus areas, and you can answer only the sections you care about. Even feedback on just one area counts. Go to https://forms.gle/ZR7dbYBbMZmhBfxTA to feedback.
  • Written feedback by email to policy@ai.gov.my with the subject line: [FEEDBACK] AI Governance Bill – Public Consultation – YOUR COMPANY NAME – DATE
  • The Unified Public Consultation (UPC) portal at https://upc.mpc.gov.my/view-consultation/264, worth bookmarking generally, because this is where national consultations live.

Deadline: Friday, 31 July 2026, 5:00pm.

You don’t need to be a lawyer. Answer as a business owner: what AI you use, what would make compliance realistic for a company your size, what guidance you’d need. That ground truth is exactly what the drafters can’t get from consultants’ papers.

I am still compiling mine to submit, and hope more people will do the same before the due date.

Ryan Chuah
Ryan Chuah

Ryan Chuah is an experienced IT consultant specializing in SME digitalization. Drawing from his background in software development, internet industries, and professional firms, Ryan identified the gap between IT and business.

As the founder of Kiizen IT Consulting Sdn Bhd, he's committed in offering tailored, scalable, strategic, and supportive IT solutions for SMEs. With a deep understanding of both IT and business requirements, Ryan consistently delivers practical and innovative solutions in our ever-evolving technological landscape.

Articles: 51