There is a gap in most Malaysian AI deployments between what the legal team believes is happening and what is actually happening.
The legal team understands the company processes personal data under PDPA and has controls for it. What they often do not know is that the support team pastes customer messages — names, NRIC numbers, account details, sometimes medical information — into an AI tool dozens of times a day, and that those prompts may be transiting to a server in another country and sitting in a log nobody has classified.
The Personal Data Protection (Amendment) Act 2024 makes that gap materially more expensive.
What actually changed
The Amendment Act was gazetted in October 2024 and came into force in three stages — 1 January, 1 April and 1 June 2025. The changes most relevant to AI:
Mandatory Data Protection Officer
Appointment of a designated DPO became mandatory as part of the June 2025 phase. If your organisation processes personal data and you have not appointed one, that is a live gap independent of anything AI-related.
Mandatory breach notification
Data controllers must notify the Personal Data Protection Commissioner as soon as practicable where there is reason to believe a personal data breach has occurred.
The AI-specific implication is uncomfortable and worth stating plainly: a successful prompt-injection attack that causes an AI system to disclose one customer's data to another is a personal data breach. The novelty of the mechanism is irrelevant. "The model was tricked" is not a category the statute recognises. See prompt injection defence.
Stricter cross-border transfer
The Amendment Act revised the mechanisms for cross-border transfers, and guidance introduced Transfer Impact Assessments as an expectation on data controllers.
This is the provision that most directly touches AI. If you send prompts containing personal data to a model hosted outside Malaysia — which describes the majority of deployments using OpenAI, Anthropic or Google — you are conducting a cross-border transfer of personal data, and you should be able to show the assessment behind it.
The three questions to answer per system
Rather than a general compliance programme, the practical approach is to answer three questions for each AI system you run.
1. Does personal data enter this system? Including via documents in a RAG corpus, tool call arguments, and pasted content — not only structured fields. The answer is yes far more often than teams expect.
2. Where does it go? Which provider, which region, which sub-processors, and what is retained. "The vendor is compliant" is not an answer; you need to know the actual data path.
3. What is the lawful basis, and can you evidence it? Consent, contractual necessity or another basis — documented, not assumed.
Systems where all three are answered are defensible. Systems where any is unanswered are the exposure.
The logging problem nobody budgets for
The most common way a compliant organisation becomes non-compliant without a change request: someone enables full prompt-and-completion capture in an observability tool for debugging.
That single toggle creates a second copy of your most sensitive data, in a system with looser access controls than the database you were careful about, usually with no retention policy and often hosted offshore. It is a genuine and frequently overlooked exposure — we cover the specifics in what to log and what never to log.
The workable position: metadata tracing everywhere, content capture only behind PII redaction, and retention configured in the tool rather than written in a policy nobody enforces.
Deletion rights and AI systems
An awkward area worth raising early rather than discovering later.
If a data subject exercises deletion rights, you must be able to honour it — including in your AI stack. That means traces containing their data, vector-store embeddings derived from their documents, and cached responses. If your observability platform has no deletion path, do not put personal data in it. If your RAG index cannot remove a document and its derived embeddings, that is a design problem to fix before it is tested.
Model weights themselves are a harder question, which is a strong practical argument against fine-tuning on personal data unless you have thought it through carefully.
Sector overlays
PDPA is the floor, not the ceiling. Financial institutions carry BNM RMiT expectations on technology risk and third-party arrangements, which apply to AI systems and their observability stacks like any other technology. Healthcare has its own constraints on patient information on top of PDPA. Both push toward keeping prompt content inside infrastructure you control — which is a large part of why onshore model options are strategically interesting to regulated sectors independent of raw capability.
And the forthcoming AI Governance Bill will layer on top of all of this rather than replacing it.
A proportionate starting programme
- Confirm a DPO is appointed. This is already mandatory.
- Inventory AI systems and answer the three questions for each.
- Complete Transfer Impact Assessments for any system sending personal data offshore.
- Turn off unredacted content capture in observability tooling until redaction is deployed and tested against real Malaysian formats.
- Set and configure retention by tier.
- Write the AI incident procedure — including that a prompt-injection disclosure is a notifiable breach.
- Verify you can actually honour a deletion request across the AI stack.
None of this is exotic. The recurring failure is simply that AI tooling gets adopted by teams under delivery pressure, and the governance conversation happens after the data is already flowing.
Our AI Security programme covers PDPA-aligned AI deployment, redaction pipelines and incident readiness for Malaysian organisations — HRD Corp SBL-KHAS claimable.
