Malaysia's AI Governance Bill and Incident Reporting
The failures that will matter most under Malaysia's new approach to artificial intelligence are the ones that make no noise. No alarm sounds. No screen turns red. A system does exactly what it was built to do, and somewhere a person is worse off for it: a loan declined on grounds no one can quite explain, a shortlist that keeps thinning out the same kind of candidate, a triage tool that quietly sends one group of patients to the back of the queue. Nothing was hacked. Nothing broke. And under the framework the government is now proposing, that ordinary, uneventful morning may be the moment a reporting duty begins.
On 10 July 2026 the National AI Office (NAIO) released the proposed AI Governance Bill for public consultation, open until the end of the month. The more useful question for anyone who builds or uses these systems is narrower: does this apply to me, and would I know when I had crossed one of its lines?
How the Bill decides who is in scope
The instinct, on hearing that a new AI law is coming, is to ask whether it covers your industry. The consultation paper answers in a different register. It does not publish a list of regulated sectors or a register of covered companies. It fixes instead on the AI system as the thing being regulated, then asks what any given organisation does with it.
Two questions settle the matter. Is the system connected to Malaysia? The proposed scope reaches AI systems 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. And what is your relationship to that system? A Developer, in the paper's words, is any person or organisation that materially shapes what a system can do and what limits are built into it. A Deployer causes the system to operate in the real world, deciding whether, where and how its capability is used. Responsibility follows the degree of control a party holds, across the system's life from inception to retirement, along the eight lifecycle stages the paper draws from ISO/IEC 5338:2023.
The consequence is broad, by design. Any person or organisation can fall within scope, public sector or private, large or small, whether it trained the model or merely switched it on. Being designated critical infrastructure is neither a trigger nor a shield. The only carve-outs proposed are two domains of deployment: personal or household use, and systems used solely for national defence or security. Whether further exemptions should follow, by sector, domain or use case, is a question the NAIO is putting to industry rather than answering for it. For most organisations that touch AI, the safe assumption is that they are inside the tent.
The trigger is harm, not a breach
Most organisations carry a settled model of an incident: a breach, an outage, a ransomware note, stolen credentials, the kind of event that trips a monitor and starts a call tree. Malaysia's existing rules reinforce it. An organisation that suffers a cyber security incident affecting critical infrastructure must notify the authorities under the Cyber Security Act 2024, and data protection rules carry their own breach-notification duties. Each begins with something going wrong to a system.
The AI Governance Bill begins somewhere else. A reportable AI incident, in the consultation paper's terms, is an event, failure, weakness, misuse or unexpected effect from an AI system that causes or may cause harm. Harm is anchored to four categories: death, bodily injury, unlawful deprivation of fundamental liberty under the Federal Constitution, and contravention of any written law. The duty reaches near misses too, which the paper treats as early warning rather than as luck.
A harm-based duty asks what a system did to people while it was working exactly as designed.
Set the two side by side and the shift is plain. One regime asks whether a system was attacked. The other asks what a system did to people while it was working exactly as designed. Malaysia is not alone in moving the line: the European Union's AI Act frames its own incident-reporting duty around serious outcomes, among them death, serious harm to health, disruption of critical infrastructure, and breaches of fundamental rights. In Kuala Lumpur as in Brussels, the direction of travel is towards consequences.
Why the usual instincts look in the wrong place
Return to that quiet morning. The loan model, the hiring filter, the triage tool: none announces itself. No credential was stolen, so no security alert fires. The system is not malfunctioning in any way a monitoring dashboard would recognise. It is functioning, and the harm is in the function. An organisation can hold clean audits, pass its penetration tests and run a mature incident process, and still never see the events this Bill most wants surfaced, because they were never security events to begin with.
This is why it is a mistake to picture the problem as one for the security team alone. Many organisations that develop or deploy AI have no such team, and those that do have built it to watch for intruders, not for outcomes. The exposure does not scale with the sophistication of your monitoring. It scales with how much of your consequential decision-making you have handed to systems whose ordinary output can hurt someone.
The report you can already half-write
There is a reassuring side to this. On what a report should contain, the paper asks for material any competent organisation can assemble: the nature of the incident, the foreseeable harm, the containment steps taken, the root cause where it can be established, and the remediation. Anyone who has written up a serious operational failure will recognise the shape of it, and the investigative discipline carries over intact.
What does not carry over is the beginning. A conventional incident report starts the moment something is detected. A harm-based duty has no detector waiting to fire, so the organisation must build the trigger itself: a deliberate way to notice, classify and escalate outcomes that no technical system will raise on its own. In practice that is a human judgment, made by the people closest to what a model does in the world, model owners, risk, legal and the affected business line, feeding whatever incident process already exists. It also means recording near misses, which most organisations discard today.
Who carries the duty, and how far it reaches
Because the Bill assigns responsibility by control, buying a system does not push the obligation back onto whoever sold it. A firm that licenses a model and puts it to work is a Deployer, answerable for how that capability is used whatever assurances came with the contract. The reach crosses borders: a model running on servers abroad is within scope if a Deployer established in Malaysia is the one using it.
One proposed principle deserves particular attention from anyone inclined to treat automation as cover. Responsibility, the paper states, must remain attributable to identifiable people and cannot be displaced onto the AI system itself. "The system decided" will not answer for a harm. For a board, that resolves into something concrete and worth arranging before any incident forces the question: for every consequential AI system in use, a named human owner, and a decision trail someone can actually follow.
The exercise worth running now
The consultation stays open until 31 July 2026, and there is more to take from it than a chance to comment. Run an exercise that pays off whatever the final law says: hold your organisation's working definition of an incident against the four categories of harm. For each, ask a plain question: what would this look like where we operate, who would notice it, and would anything we currently run actually catch it? Wherever the honest answer is that nothing would, you have found the capability this Bill will expect you to have.
Then follow the reporting line to its end. If an AI system your organisation deploys caused harm next week, decide now whom you would tell, under which law, and how quickly. The organisations that cannot yet answer that cleanly are exactly the ones whose views the consultation needs, and that gap is the most useful thing they can put in a submission.
Sources
National AI Office (NAIO), Public Consultation Paper of the Proposed Artificial Intelligence (AI) Governance Bill, 10 July 2026. https://ai.gov.my/governance/
European Union, Regulation (EU) 2024/1689 (EU AI Act), Article 73: Reporting of Serious Incidents. https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-73
National Cyber Security Agency of Malaysia (NACSA), Cyber Security Act 2024 (Act 854), Section 23: Duty to Give Notification on Cyber Security Incident. https://www.nacsa.gov.my/legal.php
ISO/IEC 5338:2023, Information technology, Artificial intelligence, AI system life cycle processes. https://www.iso.org/standard/81118.html
Disclaimer
This article is provided for general information and educational purposes only and does not constitute legal, regulatory or compliance advice. The Malaysia AI Governance Bill discussed here is a draft released for public consultation and does not represent the final law; its provisions, definitions and obligations may be amended, added to or removed before enactment, and the Government is not bound by the contents of the consultation documents. References to the Cyber Security Act 2024, the EU AI Act and ISO/IEC 5338:2023 are included for context and comparison and do not establish how any obligation will apply in practice. Organisations should verify any obligation against the primary source documents and seek qualified professional advice before acting. AKATI Sekurity accepts no liability for decisions taken in reliance on this article.
AI Governance
Frequently Asked Questions
-
The Malaysia AI Governance Bill is a proposed national law, released by the National AI Office for public consultation on 10 July 2026, that would create a single framework for governing artificial intelligence across sectors. It sets out baseline governance principles, a risk-based tiering of AI systems, an incident-reporting mechanism and a regulatory sandbox, overseen by a Central AI Authority working alongside existing sectoral regulators. It remains at consultation stage and is not yet in force.
-
The proposed Bill applies to any person or organisation that develops or deploys an AI system connected to Malaysia, rather than to a fixed list of sectors or entity types. A system is in scope if it is 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 it is hosted. The only proposed exemptions cover personal or household use and systems used solely for national defence or security.
-
A reportable AI incident is an event, failure, misuse or unexpected effect from an AI system that causes or may cause harm, with harm defined as death, bodily injury, unlawful deprivation of fundamental liberty, or contravention of any written law. The duty also extends to near misses. Because the trigger is the consequence of the system's behaviour, an incident can be reportable even when no security breach or system outage has taken place.
-
A Developer is the party that materially shapes what an AI system can do, how it functions and what limits are built into it, while a Deployer is the party that decides whether, where and how that system is used in the real world. Accountability follows the degree of control each party holds. Many organisations that buy or integrate AI act as Deployers, and licensing a model from a vendor does not transfer a Deployer's obligations back to the Developer.
-
Public consultation on the Bill closes on 31 July 2026, with submissions made through the National AI Office's consultation channels. The timing of enactment is not fixed, since reaching the consultation and Cabinet stages is not the same as becoming law, and the Government has indicated the Bill would then be tabled in Parliament. Organisations should treat the current text as a draft that may still change.
