HomeNewsSingapore's New Generative AI Guidan
9 September 2026Dr. Tobias Höllwarth

Singapore's New Generative AI Guidan

As organisations race to adopt generative AI, Singapore's regulators have provided their clearest indication yet of what responsible AI governance should look like in practice. This article examines how the PDPC and IMDA's latest Guidelines reshape expectations around consent, web scraping, accountability across the AI supply chain, and user-facing transparency, revealing a common theme: effective AI governance begins before a model is deployed.

Singapore's New Generative AI Guidan

What the PDPC and IMDA Expect Across the AI Lifecycle

Singapore has taken an important step in clarifying expectations for the governance of generative AI. On 20 July 2026, the Personal Data Protection Commission ("PDPC") issued its Advisory Guidelines on Use of Personal Data in Generative AI ("Gen AI Guidelines"), while the Infocomm Media Development Authority ("IMDA") released its Transparency Guidelines for Generative AI Chatbots ("AI Chatbot Guidelines"), (together, the “Guidelines”).
Although non-binding, both documents are significant because they explain how existing obligations, particularly under the Personal Data Protection Act 2012 ("PDPA"), are expected to apply in practice. Read together, they suggest that transparency is no longer a standalone disclosure exercise, but a governance requirement spanning model development, deployment and ongoing operation.
They build upon and are intended to be read in conjunction with existing AI guidelines including the PDPC's Advisory Guidelines on the Use of Personal Data in AI Recommendation and Decision Systems, the PDPC’s Advisory Guidelines on Key Concepts in the PDPA, the PDPC’s Guide to Basic Anonymisation, the Infocomm Media Development Authority’s Privacy Enhancing Technologies Adoption Guide, and the Model Artificial Intelligence Governance Framework (Second Edition).
Generic Privacy Notices Are No Longer Enough
The most immediate implication for organisations developing generative AI models concerns how they notify individuals about the use of personal data for training and fine-tuning.
In the Gen AI Guidelines, the PDPC distinguishes between generic notices, such as statements that data may be used for "new product development", and AI-specific notifications. It considers generic notices generally insufficient for obtaining consent to processing user data for Generative AI development, specifically, for large-scale generative AI training or fine-tuning.
Organisations are instead encouraged to explain, in accessible language, the model functions that require the use of personal data, categories of personal data involved, how the data will be used for training or fine-tuning, and how individuals may decline or withdraw consent where applicable.
The emphasis on AI-specific notifications therefore reflects the importance of providing individuals with sufficiently clear and specific information at the outset, when they are deciding whether to consent to the relevant use of their personal data. Put differently, consent arguably plays a particularly important role in the generative AI context, because the scope for meaningful downstream remediation may be technically constrained once personal data has been incorporated into a model.
Web Scraping: Digital Barriers Require a Contextual Assessment
The Gen AI Guidelines also provide welcome clarity on whether organisations can rely on the PDPA's Publicly Available Exception (paragraph 1 of Part 2 of the First Schedule to the PDPA) when web scraping online information, during the pre-training and fine-tuning stages.
The PDPC confirms that publicly available personal data may be collected, used and disclosed for model development without consent where a reasonable person would consider that use appropriate in the circumstances.
Of particular note is that the PDPC rejects a bright-line approach to content behind digital barriers. Paywalls, registration requirements, authentication mechanisms, location or eligibility-based access controls, and tools, systems or configurations that detect and limit or prevent automated programs from accessing online data, do not automatically render data non-public. Organisations should instead assess:
• the purpose of the digital barrier;
• how restrictive the digital barrier is in practice;
• the steps required to obtain access; and
• whether equivalent information is available elsewhere.
Where it is reasonably arguable that personal data behind a digital barrier is not publicly available, but an organisation nevertheless relies on the Publicly Available Exception, it must explain its assessment and reasoning, for example through a Data Protection Impact Assessment.
Deployment: Responsibility Follows Function
Significantly, the PDPC has helpfully provided a practical role-based framework that clarifies the responsibilities of common stakeholders across the AI value chain and emphasises key data protection obligations and risks for the respective stakeholders. In particular, the Gen AI Guidelines distinguish between Model Providers, System Providers and System Deployers as elaborated below.
Before we delve into the roles of each of these stakeholders, we highlight that the PDPA does not use the term “data controller”. Instead, it uses the more general term “organisation” to refer to the entities that have to comply with the data protection obligations in the PDPA. The PDPA also recognises the concept of a “data intermediary”, which is defined as an organisation that processes personal data on behalf of another organisation but does not include an employee of that other organisation. A data intermediary, which processes personal data for the purposes of the data controller pursuant to a written contract, is subject to a limited scope of obligations under the PDPA, specifically:
• Protection Obligation (i.e. the obligation to put in place reasonable security arrangements);
• Retention Limitation Obligation (i.e. to cease retention of personal data where no longer required for legal or business purposes); and
• Data Breach Notification Obligation: If a data intermediary has reason to believe that a data breach has occurred in relation to personal data that it is processing on behalf of and for the purposes of another organisation, it must notify that other organisation without undue delay.
Model Providers
Where Model Providers process personal data to develop and deploy Generative AI Models, (presumably for their own purposes), they are considered organisations under the PDPA. Accordingly, the Model Provider must comply with all obligations under the PDPA in this context.
Model Providers are reminded to ensure compliance with the Retention Limitation Obligation (i.e. the obligation to cease to retain its documents containing personal data, or remove the means by which personal data can be associated with particular individuals when the purpose for which the data was collected is no longer being served, and retention is no longer necessary for legal or business purposes). The PDPC has also highlighted that Model Providers should regularly review the personal data in their possession to determine if such data is still needed. (This guidance similarly applies to System Providers and Deployers who retain personal data to develop and deploy Generative AI Systems.)
Model Providers would be data intermediaries where they process personal data on behalf of downstream end-users, e.g. Model Providers may host data on their infrastructure, or run interference to deliver real-time outputs to end-user inputs. In this connection, the PDPC has emphasised the Protection Obligation and recommended that Model Providers document and make available the measures taken to safeguard personal data from downstream sources. For example, a Model Provider may document their data access controls, data residency and retention policies. (Such information will also support System Providers and Deployers in meeting their PDPA obligations by helping them assess (i) the adequacy of their system-level security arrangements; (ii) whether there has been unauthorised access and modification; and (iii) whether such access and modification is a notifiable data breach.)
System Providers
Where System Providers process personal data as part of their own datasets to develop systems, they are organisations. Where System Providers process data on behalf of downstream deployers (e.g. to customise systems for specific use cases, in delivering their SAAS), they are data intermediaries. To ensure compliance with the Protection Obligation, PDPC has made clear that System Providers are expected to periodically review the need for additional security arrangements as they develop and make available new types of systems. System Providers are to share information on the system-level safeguards they have implemented with downstream deployers to facilitate protection of personal data processed by their systems including data security and protection measures around the development environment (e.g. access controls, residency and retention policies, input and output filters, privacy enhancing technologies), as well as testing metrics (e.g. likelihood of data leakage).
System Deployers
System Deployers bear primary responsibility for ensuring that the AI systems they procure can meet their PDPA obligations. This includes assessing upstream safeguards, defining appropriate purposes and the personal data required, safeguarding new data sources such as prompts, outputs and agent activity data, educating users (e.g. on the types of personal data that should be input into the system), and regularly reviewing safeguards as AI risks evolve.
Overall, given that AI systems involve multiple providers and users, data protection responsibility cannot sit with any one party in isolation. An organisation’s compliance may depend on the data practices and safeguards of upstream providers, making visibility across the AI supply chain critical.
IMDA's Shift Towards User-Facing Transparency
The IMDA's AI Chatbot Guidelines complement the PDPC's data protection focus by setting out how generative AI deployers can provide meaningful transparency to consumers about their applications.
In brief, IMDA proposes a Chatbot Info Card—a single, consolidated reference point that answers the four questions users most commonly care about:
• what the chatbot can be used for;
• how reliable and safe the chatbot is;
• how user data will be used and protected; and
• how users can report issues,
with at least one substantial disclosure in each (ie. a concrete, specific statement that users can act on). The Chatbot Info Card should also be accessible (easy to understand, navigate and find) and provide information that is current and reflective of the most up-to-date knowledge of the chatbot.
Although voluntary, the framework provides a practical benchmark that organisations can adopt before sector-specific transparency requirements emerge. More importantly, it suggests that meaningful transparency is not achieved by simply making information available, but by presenting the information users actually need in a form that is accessible, specific and actionable at the point of use.

Lessons learned

Conclusion: From Compliance by Policy to Compliance by Design
Taken together, the two Guidelines point to a broader shift in how organisations should approach data protection in the generative AI context. The central concern is control: once personal data enters AI training or deployment pipelines, it may become difficult to trace, correct or remove. This makes front-end decisions around data sourcing, purpose, notification, minimisation, retention and responsibility particularly important.

Article provided by INPLP member: Chong Kin Lim (Drew & Napier LLC, Singapore)

By Dr. Tobias HöllwarthAll news