Personal Data Protection Commission (PDPC) Issues Advisory Guidelines on Use of Personal Data in Generative AI

The Advisory Guidelines on Use of Personal Data in Generative AI

The Guidelines address three matters: (i) the collection and use of personal data to develop Generative AI models during the development stage; (ii) the processing of personal data during the deployment stage; and (iii) the handling of individuals’ requests concerning the processing of their personal data post-deployment.

The Guidelines are advisory and not legally binding, and the PDPA prevails in the event of any inconsistency. They are nonetheless the clearest available statement of how the Commission expects the existing statutory obligations to be applied to Generative AI, and should be read alongside the 2024 revised Advisory Guidelines on Key Concepts in the PDPA and the 2024 Advisory Guidelines on Use of Personal Data in AI Recommendation and Decision Systems.

Key Developments

Development Stage: Collection and Use of Personal Data to Develop Generative AI Models

Publicly Available Exception

Organisations developing Generative AI models may rely on the “publicly available exception” under paragraph 1 of Part 2 of the First Schedule to the PDPA to web-scrape personal data from the open web without consent. Reliance on the exception remains subject to section 18 of the PDPA, namely that a reasonable person would consider the use appropriate in the circumstances.

A separate question arises where personal data sits behind a digital barrier, being any technical or financial measure that meaningfully restricts access. Examples include paywalls, registration requirements, authentication mechanisms (passwords, API keys), location geo-blocking, age-gates, and anti-bot measures such as rate limits and CAPTCHA.

A digital barrier does not on its own mean that the data is not publicly available. Public registers accessible on payment of a fee, metered news paywalls operating primarily as monetisation mechanisms, and large open forums requiring only basic registration are considered publicly available data.

By contrast, a database confined to members of a specific professional body is not publicly available data, as the membership requirement is meant to restricts access to a defined group, and that data is not otherwise publicly available.

Organisations must assess whether the data qualifies as publicly available data, weighing the purpose and effect of the barrier, the number and complexity of steps required to reach the data, and whether the same data is freely accessible elsewhere. The assessment should be undertaken in the context of the particular dataset and circumstances, rather than based solely on whether the data can technically be accessed. Where it is reasonably arguable that the data is not publicly available, an organisation relying on the exception must record its assessment and reasoning in a Data Protection Impact Assessment or other written record, and produce that documentation if the PDPC asks it to justify its position.

The PDPC also emphasises that the exception is distinct from contractual terms of use, licensing agreements, and obligations under intellectual property and criminal law. Publicly available data may still be contractually off limits to scrape at scale.

AI-Specific Notifications

Organisations should first consider whether an exception to the consent obligation is available for the intended use of User Data, such as the business improvement or research exception, or whether deemed consent has been given. Where no such alternative applies, organisations must obtain consent in accordance with section 13 of the PDPA. Consent obtained through a General Notification citing broad purposes such as “new product development” will not suffice; organisations must instead provide an AI-Specific Notification.

While organisations retain discretion over the form of an AI-Specific Notification, the PDPC encourages including, to the extent practicable, the function of the model requiring personal data, a clear description of the type of personal data used, how that data will be used to train or fine-tune the model, and how individuals may decline or withdraw.

The requirement for an AI-Specific Notification applies only to activities that develop or modify a model’s parameters or underlying capabilities, that is, large-scale training or fine-tuning. It does not apply simply to all personal data that is processed through an existing Generative AI Model. This reflects the difficulty of correcting a model once trained, and the risk that a Generative AI model may be deployed across use cases the individual never anticipated. To manage user fatigue, organisations may layer notifications, presenting the most relevant information prominently with further detail available elsewhere, and may use a single notification to cover several models where it adequately captures the different processing contexts. 

Consent Must Not Be a Condition of Service

The PDPC reiterates that consent to use User Data for model development cannot be made a condition of providing a product or service beyond what is reasonable to deliver that product or service to the individual.

Anonymisation and Data Minimisation

Organisations are encouraged to anonymise datasets and apply data minimisation where possible when developing Generative AI Models. Where personal data remains necessary, appropriate physical, technical, process and legal controls should be implemented.

Deployment Stage: Processing Personal Data in Deployed GenAI Models and/or Systems

Generative AI spans multiple layers of the technology stack, so personal data may pass through several stakeholders. During the deployment stage, the guide identifies three key stakeholders that bear distinct personal data protection responsibilities.

This includes:

a) Model Providers, who develop and make models available;

b) System Providers; who develop and make available systems built on those models for distribution and use; and

c) System Deployers, who use or enable the use of such systems under their authority.

The same organisation may perform more than one of these roles in different contexts. Organisations should therefore identify the role they occupy in each processing activity and assess the corresponding obligations under the PDPA.

Model Provider

There are two capacities in which a Model Provider can fall under the PDPA, and the obligations differ depending on which applies.

a) As Organisations

Under the PDPA, an entity that collects, uses or discloses personal data is an “organisation”, and must comply with all obligations under the Act. When Model Providers process personal data to develop and deploy Generative AI Models, they fall into this category. This applies even where the data comes from downstream systems, such as end-user prompts used for model development. The distinction is whether the Model Provider is processing the personal data for its own purposes, rather than simply processing it on behalf of a downstream organisation.

The PDPC flags the “Retention Limitation Obligation” (“RLO”) in particular. The RLO, under section 25, requires an organisation to stop retaining personal data, or anonymise it, once the original purpose is no longer served and retention is not needed for legal or business reasons.

The PDPC accepts that Model Providers may need to preserve training data to build or improve future models. Where that data is identifiable, good practice is to publish a retention policy explaining the rationale for longer retention, and to review holdings regularly. The same applies to System Providers and Deployers who retain personal data.

b) As Data Intermediaries

A “data intermediary” is an entity that processes personal data on behalf of another organisation. Model Providers take on this role when they process data for downstream users as part of services delivered through System Deployers. Examples include running “inference” (the process where a trained model generates outputs from new data) or hosting data on their infrastructure.

In this role, the key duty is the “Protection Obligation”, under section 24, which requires reasonable security arrangements to safeguard personal data in the provider’s possession or control. The RLO also applies.

To show compliance, good practice is to document and make available the safeguards applied to downstream data, such as access controls, data residency and retention policies, and breach procedures. This also helps System Providers and Deployers assess their own security and identify notifiable data breaches.

Where a Model Provider processes personal data for its own development purposes it is an organisation subject to the full suite of obligations, with the Retention Limitation Obligation under section 25 singled out for attention. Where it runs inference or hosts data on behalf of downstream users, it is a data intermediary subject principally to the Protection and Retention Limitation Obligations.

System Providers

Section 8 of the Advisory Guidelines addresses providers who are engaged to build bespoke, customisable Generative AI systems, as well as those who develop and retail commercial off-the-shelf systems. Where a system provider processes personal data forming part of its own datasets in order to develop a system, it is an organisation under the Personal Data Protection Act 2012. Where it processes data on behalf of downstream deployers, it is a data intermediary.

The PDPC notes that the diversification of Generative AI systems brings more security and data protection risk, such as prompt injection attacks. To meet their Protection Obligation, system providers are expected to review periodically whether additional security arrangements are required.

It is good practice for system providers to share information on system-level safeguards, such as data security and protection measures around the development environment, testing and performance metrics for data leakage, incident response and data breach procedures with downstream deployers, to facilitate the protection of personal data.

System Deployers

System Deployers are the organisations that use, or enable others to use, Generative AI systems under their authority, whether built in-house or procured as a service. Of the three stakeholders, the PDPC state that System Deployers bear primary responsibility for ensuring that the Generative AI systems they select comply with PDPA obligations.

Before procuring a system, deployers must obtain sufficient information on its upstream safeguards. This requires deployers to understand how personal data is processed within the system, including what data the system can access, whether data is retained, and whether data may subsequently be used for model development or improvement.

Under the Purpose Limitation Obligation in section 18, a deployer may only process personal data for purposes a reasonable person would consider appropriate, and only to the extent those purposes require. Because a Generative AI system is capable of far more, the deployer must be disciplined in scoping both the intended purpose and the volume of personal data used for it.

Deployers must also safeguard the new categories of data their systems generate, including end-user prompts, outputs, agent and tool activity data, and internal enterprise data. For each source, the deployer must assign clear internal responsibility and tell end users, whether staff or customers, what personal data may properly be entered.

Deployers are encouraged to develop clear written policies and to document the processes behind the safeguards they undertake. Making these available in advance, for example on the deployer’s website, further demonstrates accountability under the Act.

Where systems can plan and act independently across multiple steps and external tools, the data protection risks are higher. Deployers should keep their safeguards under review and, when scoping such uses, be transparent about the trade-off between granting the system wider data access and the added capability that brings.

Post-Deployment Stage: Addressing Individual Requests About Personal Data

Individual Access and Correction Obligations

Sections 21, 22 and 22A of the PDPA give individuals the right to request access to, and correction of, their personal data held by an organisation. An organisation must accede to a request unless a PDPA exception applies, for example where giving access would be unreasonably burdensome, or where there are reasonable grounds not to correct.

The organisation is responsible not only for the data it holds itself, but also for data it has passed to a data intermediary, which remains under its control. A data intermediary may forward a request, but the engaging organisation remains responsible for compliance.

The PDPC acknowledges these requests are harder to meet for Generative AI. The data volumes are vast, training data is stored as embeddings rather than in a conventional repository, user data may sit only briefly in context windows, and removing specific information from a trained model is technically difficult.

Where reasonable, the PDPC expects organisations to adopt three sets of best practices. First, handle data well upstream, by verifying accuracy at collection, cleaning data through techniques such as de-duplication and outlier detection, and keeping provenance records of training data lineage. Second, assess requests case by case and accede where reasonable, for instance where the data sits in a retrieval-augmented generation database, and remove inaccurate personal data from training sets before future training runs. Third, track and progressively adopt technical measures to remove inaccurate personal data from models, and in the meantime use output filters and other safeguards to reduce the chance of inaccurate data appearing in outputs.

Practical Implications

Organisations scraping at scale should treat the digital barrier analysis as a documented, dataset-by-dataset exercise.

Organisations that have relied on broad “product improvement” language to train on customer data should review those notices now. For example, a retailer repositioning itself as a model developer cannot rely on the business improvement exception, because training on customer names, transaction histories and behavioural data departs too far from its established activities. Fresh consent is required, and adequate notification includes an updated privacy policy, an in-product notice for acknowledgement, and an email carrying a link to decline.

For the majority of Singapore businesses, which deploy rather than build, the immediate work is putting deployment controls in place. The recurring moves are to define the purpose narrowly, identify only the personal data actually required, and configure access controls so the system cannot reach data it does not need. Where staff interact with a tool directly, such as an HR chatbot, the unit owning the tool should also issue written guidance on what personal data may be entered and record the arrangements in internal AI governance guidelines.

Agentic capability attracts further measures. For an assistant that plans and executes multi-step tasks, these include role-based limits on file and network access, data classification that flags sensitive personal data for stricter handling, and escalation to a human for high-risk tasks.

Organisations procuring from vendors should seek the upstream equivalent in writing before signing. A reasonable request covers access and encryption controls for data processed during inference, a data storage sheet showing where customer data is held, a retention policy for inference data, and, for system providers, disclosure of input redaction filters and testing on how reliably personal identifiers are detected before processing.

Outlook

The Guidelines do not alter the PDPA, but they set out with unusual specificity what the PDPC will look for when it examines an organisation’s reliance on the publicly available exception or the adequacy of its consent mechanics. Compliance work over the next 12 months is likely to turn less on whether an organisation used personal data for Generative AI than on whether it can produce a contemporaneous written record explaining why it was entitled to.

Reference Materials

This article is an expanded version of our contribution to XLNC Magazine No 18 | Autumn 2026.