Public consultation submission
AI and personal data protection in Malaysia: our submission on JPDP's AI Framework
On 22 October 2026 we filed a written submission with the Personal Data Protection Department (JPDP) on Public Consultation Paper No. 1/2026, the draft Artificial Intelligence (AI) and Personal Data Protection Framework: eleven recommendations on the Framework's legal effect, training AI on personal data already held, buying external AI, data subject rights and biometric data, together with four annexures. This page collects the full papers and tracks the Framework as it develops.
In brief
- The Framework is JPDP's guidance on how the Personal Data Protection Act 2010 applies when personal data is processed through AI. It will reach almost every Malaysian organisation using AI, not only those building it: anyone buying software with an AI feature, deploying a chatbot, or whose staff use AI tools at work.
- Our overall view is positive. The Framework stays close to Act 709, says correctly that using AI creates no separate legal basis, and handles offshore AI through section 129. Our recommendations are meant to help it work in practice.
- The question controllers ask most, whether they can train or fine-tune AI on personal data they already hold, is touched on in three places in the Framework. Each states a different test, and none is the Act's own. We ask JPDP to use the Act's "directly related" test and explain how it applies to training.
- The Framework is softer than the Commissioner's existing ADMP Guideline on DPIAs, DPO involvement and AI as the sole factor in decisions. We ask for the two to be aligned, and for a human-oversight standard.
- The word "biometric" does not appear in the Framework, although biometric data has been sensitive personal data since the 2024 amendments and AI tools now create it as a matter of routine.
- This is our third AI consultation submission this year, after the AI Governance Bill and the Copyright Act amendments. The same point runs through all three: most AI that matters runs on personal data, and new rules should connect to Act 709 rather than sit beside it.
The papers
These documents may be quoted with attribution to Edwin Lee & Partners. Journalists and researchers are welcome to contact us for comment.
What the Framework is, and its legal effect
JPDP published the draft Framework on 5 October 2026, for consultation until 23 October 2026. It is to be issued as a Guideline under section 48(g) of Act 709, and it covers the life of an AI system that processes personal data across ten Parts, from scope and definitions through development and testing, procurement of external AI and data subject rights, to fairness, security and record-keeping.
Our first point concerns its legal effect. Paragraph 1.7 says the Framework supplements the Act, and paragraph 1.8 describes it as high-level best practice. But the operative text is written almost entirely in mandatory terms ("hendaklah" in Bahasa Malaysia, "shall" in English), and the Framework does not say what happens to a controller that does not follow it. In our experience a guideline like that gets read two ways. Larger controllers treat every "shall" as binding and budget for it. Smaller controllers notice that it is a guideline and treat it as optional. Neither outcome is good for data subjects.
We recommend a short "status and effect" clause on a comply-or-explain basis: the Framework records the Commissioner's view of what the Principles require where personal data is processed through AI; compliance with it will be taken into account in assessing compliance with the Principles; and a controller that departs from a provision should be able to explain why in writing. That gives the Framework real weight while being honest about what a guideline is, and it gives smaller controllers a proper way to be proportionate without being non-compliant.
Two scope points go with this. The Framework requires measures to be "proportionate" in seven places without saying proportionate to what. We suggest a two-level reference point using a line JPDP has already drawn in the ADMP Guideline: an AI system that makes or materially supports decisions with legal or similarly significant effects on individuals attracts the Framework in full, and other AI systems attract a lighter core with a proportionate record. And we ask that systems running only on fixed, pre-defined rules be taken out of the definition of an AI system. On the current wording, even the deterministic DPIA questionnaire tool we built for our clients, which calls no model at any point, would be caught.
Training AI on personal data you already hold
Paragraph 5.1 of the Framework says, correctly, that using AI creates no separate legal basis for processing personal data. The question every controller then asks is whether it can use the personal data it already holds, collected to provide its services, to train, fine-tune or improve a model. The Framework touches on this in three places and states the test three different ways: processing "consistent with" the original purpose (paragraph 6.3), a purpose "not previously specified" (paragraph 7.4), and a purpose that "materially differs" (paragraph 8.3(d)). None of them is the test in Act 709, which asks whether the new purpose is directly related to the purpose for which the data was collected.
Where it is not, the controller needs to give notice under section 7 and, unless one of the grounds in section 6(2) applies, obtain consent. None of those grounds is a legitimate-interests or product-improvement ground. Sensitive personal data needs explicit consent under section 40. Public availability is not consent, and collecting personal data from another organisation's website may engage section 130. The research exemption will rarely fit commercial model development.
We ask JPDP to use the Act's own words in all three places, to set out the factors for deciding whether training is directly related, with a preference for anonymised or pseudonymised data, and to give at least one worked example. Ours is this. A fraud-detection model retrained on the controller's own transaction data, for the fraud-prevention purpose notified at collection, is ordinarily directly related. A customer-service assistant trained on customers' correspondence and then offered to other customers or licensed to other businesses is ordinarily not, and requires notice and consent.
A guideline cannot create a legal basis the Act does not contain, and we have not asked JPDP to read one in. Whether Act 709 should provide a basis for AI development is a question for a consultation on the Act itself, and we take no position on it. We ask only that the Commissioner refer it to the Minister, and that the Framework not be drafted as though it had been answered. This is the third time we have raised the training question this year: with the National AI Office, with MyIPO, and now with the body best placed to answer it.
Buying AI: consumer accounts, offshore services and local models
Most Malaysian organisations will never train a model. They will buy software with AI features, build a chatbot on someone else's model, call a general-purpose model through an API, and find that their staff are already using consumer AI tools. Part F of the Framework, on procurement, is the Part that will be used most, and we think it is the strongest. Our recommendations deal with the points where controllers most often cannot tell what it requires of them.
The consumer account problem. As we understand the terms commonly offered, the consumer tiers of popular AI services may allow the provider to use what users type in to improve its models unless the user opts out, while business tiers and API access usually exclude that use by default. The position differs between providers and changes over time. Where it applies, the position under Act 709 is clear. When an employee puts customer data into a consumer account whose terms allow training, the employer has disclosed personal data to a third party for a purpose that was never notified. Section 8 does not allow that without consent, and section 40 does not allow it at all for sensitive data without explicit consent.
Three compliant routes, at three costs. First, no personal data goes into the tool at all, which a written acceptable-use policy can require at no cost. Second, where the provider offers a working opt-out from training, every account used for work has it switched on, checked and recorded, and no sensitive personal data goes in. Third, a business tier or API with no-training terms, which is the only route for sensitive personal data or for processing at volume.
Offshore services and local models. We ask the Framework to say that a Transfer Impact Assessment is expected for any external AI service that processes personal data outside Malaysia, and to add three factors the Cross-Border Transfer Guidelines do not reach: where the data is stored and processed, including by sub-processors; the destination's law on access by public authorities; and the oversight and redress available to a data subject in Malaysia. We also ask JPDP to recognise running an open model on infrastructure the controller controls, or in a Malaysian cloud region, as a data-protection-by-design measure, while being honest that the controller then takes on the security, testing and monitoring work a hosted provider would otherwise do.
Standard terms. A company that accepts a global provider's standard terms negotiates nothing. The only "arrangements" it can make are the provider's terms and data processing addendum, the settings it chooses, and its record of both. We ask the Framework to say so, so that paragraph 21.3 is not read as requiring a negotiated contract most controllers cannot obtain. Annexure C offers a checklist for reviewing standard terms against paragraph 21.3, and model clauses for the cases where the controller holds the pen.
The ADMP Guideline and human oversight
The Commissioner already has an instrument on AI used in decisions about individuals: the Guideline on Automated Decision-Making and Profiling. The Framework does not mention it, and on three points it says something softer. The ADMP Guideline makes a DPIA mandatory wherever automated decision-making and profiling is present; the Framework says "where appropriate". The ADMP Guideline requires the DPO to be engaged at the earliest possible stage; the Framework asks that the DPO be "appropriately involved". The ADMP Guideline says AI must not be relied upon as the sole factor in decisions concerning a data subject; the Framework contains no human-oversight standard at all.
A controller deploying an AI credit-scoring model and reading only the Framework would conclude that a DPIA is optional and that nothing stops the model being the sole basis of the decision. Reading the ADMP Guideline, it would conclude the opposite on both. We ask that the two be aligned for systems that make or materially support significant decisions, and that human oversight be defined by capability: the person understands what the system optimises for, has the information needed to evaluate its output, and is empowered to depart from it. A person "in the loop" without those three things is not exercising oversight.
One clarification goes with this. Using AI should not by itself require an organisation to appoint a DPO. Whether a DPO must be appointed is governed by Circular No. 2/2025 and the DPO Guidelines. The duty to assess and the duty to appoint are separate questions, and the Framework should keep them separate.
Biometric data, which the Framework does not mention
The word "biometric" does not appear in the Framework. Since the 2024 amendments, biometric data is sensitive personal data under Act 709, defined as "any personal data resulting from technical processing relating to the physical, physiological or behavioural characteristics of a person". Processing it needs explicit consent or another condition under section 40, and contravention is an offence carrying a fine of up to RM200,000, imprisonment of up to two years, or both.
The Malaysian definition follows the EU Artificial Intelligence Act rather than the GDPR, and on its wording it does not require the data to be used to identify anyone. On that reading, which we think is the better one but do not put forward as settled, an AI tool that scores a caller's tone, reads a shopper's mood from camera footage or flags a user by typing rhythm is producing sensitive personal data. AI creates biometric data as a by-product, from inputs that are not themselves biometric. A retailer offered a voice-analytics add-on by its call-centre software vendor has no reason, on the Framework as drafted, to think that "calls may be recorded" is not enough.
We ask the Framework to define biometric data, state the Commissioner's view on the identification question, say that AI systems can create biometric data, require explicit consent with a specific notice and, where reasonably achievable, an alternative for those who decline, and require a DPIA before such a system is deployed.
Data subject rights
Part G of the Framework is carefully done, and its extension of the right of access to personal data generated by an AI system is welcome. We ask it to settle the questions Data Protection Officers will meet on the first access request involving AI: that inferences, scores and profiles about an identifiable person are personal data within the right of access where retrievable; that model weights and parameters are not; that prompt and output logs will often contain personal data; and that correction and withdrawal of consent require fixing the stored record and stopping further processing, not retraining the model. We also ask JPDP to say whether AI-generated inferences fall within the new right to data portability.
We also ask the Framework to be clear about what the Act gives. Act 709 confers no general right to object to automated decision-making or profiling as such, and no right to require human review. But section 42 lets a data subject require a controller, by written notice, to stop processing that is causing or is likely to cause unwarranted substantial damage or distress, and that applies to processing through an AI system as to any other. The Framework does not mention section 42, and it should: it is the data subject's real remedy against harmful AI processing under the Act as it stands.
One record, one assessment
The Framework asks controllers to keep overlapping records in three places (paragraphs 39.3, 40.4 and 42.3). We suggest a single AI Processing Record, published as a template, scaled to the significance of the system, and capable of forming part of the records controllers already keep under section 44 of the Act and the Commissioner's guidelines. Its entry for data sources should also serve as the training-data record that any text and data mining exception under the Copyright Act will require, so that one record serves JPDP and, in time, MyIPO.
The same logic applies across regimes. The AI Governance Bill is reported to be on its way to Cabinet. We asked the National AI Office to let a DPIA satisfy the Bill's assessment in respect of personal data, and we ask JPDP to make the matching commitment, so that each AI system needs one assessment rather than two. For smaller controllers, we also suggest published templates, an enquiry channel for AI-related questions, and a twelve-month transition period, the first six months guidance-only.
The 11 recommendations
The full text of each recommendation, with the analysis behind it, is set out in the written submission.
| No. | Subject | Recommendation in brief |
|---|---|---|
| 1 | Status and effect | Add a clause stating the Framework's legal effect (comply or explain) and its relationship to the Commissioner's other instruments |
| 2 | Scope and proportionality | Exclude rules-based systems; give "proportionate" a two-level reference point; map the AI Service Provider onto processor and third party |
| 3 | ADMP consistency and oversight | Align with the ADMP Guideline on DPIA, DPO involvement and the no-sole-factor rule; add a human-oversight standard |
| 4 | Training on existing data | Use the Act's "directly related" test in paras 6.3, 7.4 and 8.3(d); say how it applies to training; coordinate with MyIPO; refer the reform question upward |
| 5 | Material change and testing | Give indicative triggers for "material change" and ask that acceptance criteria be set before testing |
| 6 | Procurement of external AI | Role determination, consumer-tier terms, unobtainable due diligence, a fuller TIA for offshore services, local deployment of open models, model clauses |
| 7 | Data subject rights | Clarify inferences, model weights, logs, correction, withdrawal and portability; refer to section 42; do not imply rights the Act does not confer |
| 8 | Fairness, security and breach | Anchor fairness to the Principles; add four AI-specific fields to the breach form; set a processor-to-controller notification window |
| 9 | Records and SME support | One AI Processing Record in place of three lists; a published template; a transition period; a sandbox aligned with NAIO |
| 10 | Other regimes | State the boundary with the AI Governance Bill; adopt a one-assessment principle; local instruments first among references |
| 11 | Biometric data | Name biometric data, sensitive since the 2024 amendments; state that AI can create it; connect the section 40 and DPIA safeguards |
Common questions about AI and personal data protection in Malaysia
Is JPDP's AI and Personal Data Protection Framework legally binding?
The Framework is a draft Guideline, issued for consultation under section 48(g) of the Personal Data Protection Act 2010. A guideline is not a code of practice or a regulation, but the Personal Data Protection Principles it interprets are binding, and contravening them is an offence carrying a fine of up to RM1,000,000, imprisonment of up to three years, or both. The draft does not say what follows if a controller departs from it. Our submission asks JPDP to state its effect on a comply-or-explain basis.
Can a company train AI on customer data it already holds?
Only where Act 709 allows it. The Act's test is whether the training purpose is directly related to the purpose for which the data was collected. If it is not, the company needs to give notice and, unless one of the limited grounds in section 6(2) applies, obtain consent; sensitive personal data needs explicit consent. Act 709 has no general legitimate-interests or product-improvement ground. The draft Framework states the test three different ways, and our submission asks JPDP to use the Act's own test and explain how it applies to training.
Can employees put customer personal data into consumer AI tools?
Often not lawfully. Where a consumer AI service's terms allow the provider to use inputs to improve its models, an employee entering customer data discloses it to a third party for a purpose that was never notified. Section 8 of Act 709 does not allow that without consent, and section 40 does not allow it for sensitive data without explicit consent. The employer remains responsible. The draft Framework prohibits entering personal data into an AI system the organisation has not authorised. The practical routes are to keep personal data out of such tools, to use a verified training opt-out on every work account, or to use a business tier or API with no-training terms.
Does using AI require a DPIA in Malaysia?
Not in every case, but often. The Commissioner's DPIA Guideline treats the use of innovative technology as a qualitative factor, and illustrates that factor with AI. The ADMP Guideline makes a DPIA mandatory wherever automated decision-making and profiling is present. The draft Framework requires a DPIA only "where appropriate". Our submission asks that it be required for AI systems that make or materially support decisions with legal or similarly significant effects on individuals.
Does a company need a Data Protection Officer because it uses AI?
Not because of AI as such. Whether a DPO must be appointed is governed by the thresholds in Circular No. 2/2025 and the Commissioner's DPO Guidelines. Where an organisation embarks on automated decision-making and profiling, the ADMP Guideline expects the DPO to be engaged from the earliest stage. Our submission asks the Framework to keep the duty to assess AI risk separate from the duty to appoint a DPO.
Is voice, face or emotion analysis by AI biometric data under the PDPA?
Very possibly. Since the 2024 amendments, Act 709 defines biometric data as personal data resulting from technical processing relating to a person's physical, physiological or behavioural characteristics, and treats it as sensitive personal data requiring explicit consent or another condition under section 40. On its wording the definition does not require the data to be used to identify anyone, so an AI tool analysing voice, facial expression or typing pattern may be creating sensitive personal data. That reading is not settled, and our submission asks JPDP to state its view.
When will the Framework be finalised?
No date has been announced. The public consultation ran from 5 October to 23 October 2026, and the Framework may change before it is issued. We track material developments on this page.
What should businesses using AI do now?
Four things hold whatever the final text says. First, list the AI tools in use, including those staff use on their own accounts, and put an acceptable-use policy in place. Second, check each tool's terms on training use, retention and storage location, and switch off training on your inputs where you can. Third, before reusing customer data to train or fine-tune anything, ask whether the purpose is directly related to why the data was collected. Fourth, check whether any tool analyses voices, faces or behaviour, because that may be biometric data.
Developments
We record material developments here as they occur.
- Our submission filed with JPDP, comprising the written submission and Annexures A, B, C and D. The public consultation closes on 23 October 2026.
- JPDP opens Public Consultation Paper No. 1/2026 on the Unified Public Consultation portal, publishing the draft Framework in Bahasa Malaysia and English.
Primary sources
- Unified Public Consultation portal: the consultation listing for Public Consultation Paper No. 1/2026, including the draft Framework
- JPDP, the Personal Data Protection Department, Malaysia
- Personal Data Protection Act 2010 (Act 709), as amended by the Personal Data Protection (Amendment) Act 2024 (Act A1727)
Related reading
- Malaysia's AI Governance Bill: our submission to the consultation: our first AI consultation submission of 2026, filed with the National AI Office
- AI and copyright in Malaysia: our submission on the Copyright Act amendments, and the copyright half of the training-data question
- Personal data protection in Malaysia: the PDPA framework on which the Framework builds
- The Data Protection Officer: mandatory appointment, and the natural owner of AI risk inside an organisation
Key contact
Edwin Lee
Founder and Managing Partner, Edwin Lee & Partners
Edwin advises Malaysian and international organisations on data protection, technology and commercial matters, including compliance with the Personal Data Protection Act 2010 and the Commissioner's 2024 to 2025 instruments, and acts as the named Data Protection Officer on client engagements. He co-edited Beyond Data Protection: Strategic Case Studies and Practical Guidance (Springer, 2013), and has filed written submissions on three of Malaysia's 2026 consultations shaping the law of artificial intelligence: the AI Governance Bill, the Copyright Act amendments and JPDP's AI and Personal Data Protection Framework.
If your organisation uses AI on personal data, buys AI services, or builds with AI, we are happy to discuss how the Framework is likely to apply.
The documents on this page were prepared by Edwin Lee & Partners and submitted in response to a public consultation. They set out our proposals to that consultation and do not describe what the law will be. Nothing on this page constitutes legal advice to any person; specific advice should be sought for particular circumstances.