TRW & Co · PDPA and data protection
PDPC Advisory Guidelines on Personal Data in Generative AI
The PDPC generative AI guidelines, published on 20 July 2026, explain how the PDPA applies when organisations train, fine-tune and deploy generative AI. The key practical question is whether existing data can be used without fresh consent. Often it can, under the business improvement or research exceptions, but only with documented reasoning, minimised data and clear allocation of responsibility across vendors.
Key pointThe business improvement exception can support fine-tuning on your own customer data for your own service, but it rarely covers a vendor training its general model on that data; that usually needs consent backed by an AI-specific notification.
At a glance
Published 20 July 2026
The PDPC issued the final Advisory Guidelines on Use of Personal Data in Generative AI after consulting from 2 June to 1 July 2026.
Advisory, not new law
The guidelines interpret existing PDPA obligations and exceptions; they indicate how the PDPC is likely to assess generative AI projects in practice.
Exceptions can replace consent
Business improvement, research and publicly available exceptions may support training without consent where their conditions are met and documented.
Specific notices required
Where consent is relied on, generic product-improvement wording is unlikely to suffice; notices should describe AI training, data categories and withdrawal.
Deployers carry primary responsibility
Organisations deploying generative AI systems are primarily responsible for PDPA compliance, including prompts, outputs and agent activity data they generate.
Swipe or scroll →
The PDPC generative AI guidelines: the short answer
The PDPC generative AI guidelines are the Personal Data Protection Commission's Advisory Guidelines on Use of Personal Data in Generative AI, published on 20 July 2026 after a public consultation that ran from 2 June to 1 July 2026. They explain how the Personal Data Protection Act 2012 (PDPA) applies at each stage of a generative AI system's life: collecting training data, developing and fine-tuning models, deploying them, and handling individuals' requests afterwards.
The guidelines do not create new law. They are advisory, and they sit on top of existing PDPA obligations and exceptions. Their practical value is that they tell organisations which consent exceptions the PDPC regards as realistically available for AI work, what documentation it expects, and how responsibility is shared between model providers, system providers and deploying organisations.
For most businesses the decisive question is narrow: can we use the personal data we already hold to train, fine-tune or evaluate a model without fresh consent? The answer turns largely on the business improvement and research exceptions, and on what the PDPC now calls AI-specific notifications.
Where the guidelines sit in Singapore's framework
The PDPC generative AI guidelines should be read with two earlier PDPC documents: the Advisory Guidelines on Use of Personal Data in AI Recommendation and Decision Systems, issued in March 2024, and the Advisory Guidelines on Key Concepts in the PDPA. The 2024 guidelines addressed traditional machine learning; the 2026 guidelines extend the same logic to large language models, image generators and AI agents.
They also complement non-PDPA instruments: the Infocomm Media Development Authority's model governance frameworks, including the Model AI Governance Framework for Agentic AI, and sector rules such as those issued by the Monetary Authority of Singapore. For a broader view of AI governance obligations, see our AI governance practice page; for a general introduction to how the PDPA meets AI, see our existing note on AI and personal data in Singapore.
Who the guidelines address
The guidelines distinguish three roles. Model providers develop and train generative AI models. System providers build applications on those models, often customising them for clients or delivering them as software as a service. System deployers are organisations that put the system to work with their own customers or staff.
One company can hold more than one role. A bank that fine-tunes an open-weight model on its own data and deploys it to customers is both a model developer and a deployer, and its obligations follow each activity.
Training and fine-tuning: which basis can you rely on?
The PDPA starts from consent. The PDPC generative AI guidelines accept that consent is often impractical for training data, and point organisations to existing exceptions. Which one fits depends on where the data came from.
Two preliminary questions save time. First, is the data personal data at all once it has been prepared for training? If identifiers can be stripped and the residual risk of re-identification is low, the PDPA may not apply to the training set. Second, is the organisation acting for itself or for a client? A system provider processing a client's data on the client's instructions does not need its own legal basis for that processing, but it cannot reuse the data for its own model without one.
Only once those questions are answered does it make sense to choose between the exceptions and consent. The table below summarises the realistic options.
| Data source | Likely basis | Key conditions | Documentation expected |
|---|---|---|---|
| Publicly accessible web data | Publicly available exception | Data genuinely available to the public; a reasonable person would consider the use appropriate | Written reasoning where it is arguable that data behind a paywall, login or geo-block is not public |
| Customer or user data you already hold, for internal model improvement | Business improvement exception | Purpose cannot reasonably be achieved without identifiable data; use is one a reasonable person would consider appropriate; sharing limited to within the organisation or its group | Assessment of necessity and appropriateness; anonymisation considered first |
| Customer or user data used for broader research | Research exception | Identifiable data necessary; clear public benefit; results not used to make decisions about the individual; published results do not identify individuals | Research protocol and publication controls |
| User data where no exception fits | Consent | AI-specific notification explaining the AI purpose, data used, processing and how to withdraw | Notice wording, consent records and withdrawal process |
| Anonymised data | Outside the PDPA if truly anonymised | Re-identification risk must be low in context | Anonymisation assessment and controls |
The business improvement exception in practice
The business improvement exception lets an organisation use personal data without consent to improve or develop its own goods and services, improve its methods and processes, or understand its customers better. For generative AI, this is the most relevant exception for fine-tuning a model on customer interactions to improve the organisation's own service.
Its limits matter. The organisation must show that the purpose cannot reasonably be achieved with anonymised or aggregated data, and that a reasonable person would consider the use appropriate. It does not authorise sharing data with unrelated companies, so it will not usually cover a vendor that wants to train its general-purpose model on a client's customer data.
The research exception in practice
The research exception is narrower in purpose but can extend to commercial research. It requires a clear public benefit, and it fails if the outputs are used to make decisions affecting the individuals whose data was used, or if published results could identify them. It suits model evaluation studies and safety research better than routine product tuning.
Where an exception applies, the PDPC accepts that a separate AI-specific notification is generally not required. Our guide to consent obligations explains how the exceptions interact with deemed consent.
Write down which exception you rely on, and why, before the training run starts. The PDPC expects documentation, often in a data protection impact assessment, and a reasoned record made at the time is far more persuasive than an explanation assembled after a complaint.
AI-specific notifications and the public data question
Where consent is the basis, the PDPC is clear that generic wording such as "product improvement" or "new product development" is unlikely to be enough. An AI-specific notification should say that data will be used to train or fine-tune AI models, which categories of data are involved, how they will be processed, and how individuals can decline or withdraw consent.
No particular format is prescribed. The information can sit in an existing privacy notice or terms of use, provided it is clear enough for meaningful consent. Our guide to notification duties covers drafting.
On public data, the PDPC generative AI guidelines accept that web-scraped content can be used under the publicly available exception. Content behind digital barriers such as paywalls, registration walls or geo-blocking needs closer analysis of the barrier's purpose and effect and whether the same data is freely available elsewhere. The final guidelines dropped an earlier proposal that scrapers should notify website operators first, but they keep the expectation that uncertain cases are reasoned and recorded.
Deployment: responsibility across the value chain
Under the PDPC generative AI guidelines, the deploying organisation bears primary responsibility for ensuring that the system it chooses meets PDPA obligations, whether built in-house or bought as a service. Model providers are encouraged to publish retention policies for identifiable training data and to share model-level safeguards downstream. System providers that process data for deployers will often be data intermediaries, with protection and retention obligations of their own.
Deployment also creates new data. Prompts, outputs and the activity logs of AI agents can contain personal data and must be protected, retained only as long as needed and covered by written policies. The guidelines specifically flag agentic systems as needing regular review of safeguards.
- Map the roles. Identify who is model provider, system provider and deployer for each system, and record it.
- Fix the basis. For each data source used in training or fine-tuning, record the exception or consent relied on.
- Minimise and anonymise. Strip identifiers and reduce datasets before training wherever the purpose allows.
- Paper the vendor chain. Allocate PDPA duties, security, incident notification and retention in contracts; see our note on vendor contracts.
- Control new data streams. Set retention and access rules for prompts, outputs and agent logs.
- Prepare for requests. Build a process for access and correction requests that reach data used in training.
- Review periodically. Reassess safeguards when models are retrained, vendors change or agents gain new tools.
Access, correction and retention after training
Individuals keep their rights after their data has been used to train a model. The guidelines confirm that access and correction obligations continue to apply, subject to the normal PDPA exceptions, and that data held by a data intermediary counts as within the organisation's control. Our guide to access requests sets out the general process.
Because removing data from trained weights is technically difficult, the PDPC recommends practical measures: verifying accuracy at collection, cleaning data before training, keeping provenance records, excluding inaccurate data from future training runs and using output filters in the meantime. Training data kept for future models needs a retention rationale that is reviewed regularly.
Illustrative scenario: fine-tuning a customer service assistant
This scenario is illustrative only and uses generic parties. A Singapore retailer wants to fine-tune a licensed language model on two years of customer chat transcripts so that its assistant answers product questions better. The vendor also asks for permission to use the transcripts to improve its general model.
For its own fine-tuning, the retailer assesses the business improvement exception: it removes names, phone numbers and order identifiers that are not needed, records why anonymised summaries would not achieve the purpose, and concludes that customers would reasonably expect transcripts to improve service quality. It records the analysis in its impact assessment.
The vendor's request is different. Using the data to train a model for other clients is not the retailer's own business improvement. The retailer declines, adds a no-training clause to the contract and requires deletion of transcripts after processing. If it later wants to allow vendor training, it will need consent supported by an AI-specific notification.
Risks and common mistakes
Treating "product improvement" wording as AI consent
Many privacy notices already mention product improvement. The PDPC has signalled that this is unlikely to support meaningful consent to AI training. Organisations relying on consent should update notices to mention AI development specifically, and consider how existing customers are told. Relying on an outdated notice is one of the easiest gaps for a complainant to identify.
Stretching the business improvement exception to vendors
The exception covers the organisation's own improvement purposes and sharing within a group. It does not usually cover a supplier that wants to train a general model on client data. Contracts that silently allow vendor training can leave the client without a lawful basis. Check standard terms of AI tools carefully and negotiate opt-outs where needed.
Ignoring prompts and agent logs
Teams focus on training data and forget that deployed systems generate fresh personal data every day. Prompts can include health details, financial information or third-party data. Without retention limits and access controls, these logs become a breach risk and a source of difficult access requests. Treat them as a new dataset with its own owner.
No record of the public-data analysis
Where data was scraped from sources behind logins or paywalls, the PDPC expects written reasoning on why it was treated as publicly available. A model trained without that record is hard to defend later, and retraining without the data can be costly. Make the assessment part of the data acquisition sign-off.
Cross-border angle
Many generative AI services are hosted, trained or supported outside Singapore. Transfers of personal data abroad remain subject to the PDPA transfer limitation obligation, so contracts with overseas model and system providers need comparable protection clauses. Our guide to cross-border data transfers explains the mechanisms.
Groups operating in the UK or the EU will find the PDPC's approach more permissive on consent exceptions but similar in its emphasis on documentation and accountability. A single group AI data standard, with Singapore-specific notes on the business improvement and research exceptions, is usually easier to run than separate playbooks.
What to do now
As of October 2026, organisations using or building generative AI should treat the PDPC generative AI guidelines as the PDPC's likely benchmark in any investigation. A short programme covers most of the risk:
- Inventory generative AI systems in use, including tools bought by business units.
- Record the role you play and the legal basis for each training or fine-tuning dataset.
- Update privacy notices with AI-specific wording where consent is relied on.
- Review vendor terms for training rights, retention and data intermediary duties.
- Set retention rules for prompts, outputs and agent logs.
- Test the access and correction process against a model-related request.
For help applying the PDPC generative AI guidelines to a specific project, please contact TRW & Co. Our data protection and PDPA and technology transactions teams work together on AI procurement and deployment.
Frequently asked questions
01Are the PDPC generative AI guidelines legally binding?
No. They are advisory guidelines that explain how the PDPC interprets the PDPA in the context of generative AI. The underlying PDPA obligations are binding, and the PDPC can enforce them with directions and financial penalties. In practice, the guidelines indicate what the PDPC will look for in an investigation, so departing from them without a documented reason increases risk. They should be read with the 2024 guidelines on AI recommendation and decision systems.
02Can we train an AI model on customer data without consent in Singapore?
Sometimes. The business improvement exception may allow an organisation to use customer data to improve its own products or services if identifiable data is genuinely necessary and a reasonable person would consider the use appropriate. The research exception may apply where there is a clear public benefit and results will not be used to make decisions about individuals. Where neither fits, consent supported by an AI-specific notification is needed. Anonymised data falls outside the PDPA if re-identification risk is low.
03Is scraping public websites for AI training allowed under the PDPA?
Personal data that is genuinely publicly available can generally be used under the publicly available exception. Data behind paywalls, logins or geo-blocking needs a closer look at the barrier's purpose and whether the data is freely available elsewhere. Where it is reasonably arguable that data is not public, the PDPC expects written reasoning, for example in an impact assessment. Other laws, such as copyright and website terms, may also restrict scraping.
04Who is responsible if an AI vendor mishandles our customers' data?
The deploying organisation bears primary responsibility for ensuring the system it uses complies with the PDPA. A vendor processing data on its behalf will often be a data intermediary with its own protection and retention obligations, but that does not remove the deployer's accountability. Contracts should allocate security, incident notification, retention, training rights and cooperation on access requests, and deployers should review vendor safeguards periodically.
05Do access and correction rights apply to data used to train a model?
Yes. Individuals can request access to and correction of their personal data even after it has been used in generative AI development, subject to the usual PDPA exceptions. Because data cannot easily be removed from trained models, the PDPC recommends practical steps such as data cleaning before training, provenance records, excluding inaccurate data from future training runs and using output filters while technical removal methods mature.
06Do we need a new privacy notice for generative AI?
If you rely on consent for AI training, your notice should specifically say that personal data will be used to develop or fine-tune AI models, which data is involved, how it is processed and how to withdraw. No set format is required, so the wording can be added to an existing privacy notice or terms. If you rely on an exception such as business improvement, a separate AI-specific notification is generally not required, though transparency remains good practice.
Sources and official materials
- Personal Data Protection Commission — Advisory Guidelines on Use of Personal Data in Generative AI and related guidance
- PDPC Advisory Guidelines on Use of Personal Data in AI Recommendation and Decision Systems — Earlier guidance on business improvement and research exceptions for AI
- Personal Data Protection Act 2012 (Singapore Statutes Online) — Consent obligation, exceptions and transfer limitation
- MDDI: Model AI Governance Framework for Agentic AI — Complementary governance guidance for AI agents
- IMDA: Artificial intelligence — Model governance frameworks and testing resources
General information only, current as at 20 October 2026. It is not legal advice and does not create a lawyer–client relationship. Singapore law and regulatory practice change; check current official sources and take advice on the facts of your matter.
