Singapore PDPA Rules for Generative AI: 2026 PDPC Guidance

The short answer

In Singapore you can use personal data to build or fine-tune a generative AI model without fresh consent only if a recognised exception applies — most commonly the Publicly Available Exception for web-scraped data, or the business improvement and research exceptions for data you already hold. If none applies, you must obtain consent, and since 20 July 2026 the Personal Data Protection Commission (PDPC) has made clear that a generic privacy-policy line about “new product development” is not enough: you need an AI-Specific Notification.

Stratgik is a technology firm, not a law firm, and nothing here is legal advice. Where an obligation turns on your specific facts — and under the Personal Data Protection Act 2012 (PDPA) much of it does — take Singapore-qualified legal advice.

What changed on 20 July 2026

On 20 July 2026 the PDPC issued the Advisory Guidelines on Use of Personal Data in Generative AI. They build on the earlier Advisory Guidelines on Use of Personal Data in AI Recommendation and Decision Systems (1 March 2024) rather than replacing them.

The guidelines are advisory. They do not change the PDPA itself — the Act prevails in any inconsistency — but they set out how the Commission reads the law, so they are the benchmark an organisation will be measured against. They are organised around three stages of the generative AI lifecycle: development, deployment and post-deployment.

Development: can you use the data at all?

Web-scraped data and the Publicly Available Exception

Paragraph 1 of Part 2 of the First Schedule to the PDPA lets organisations collect, use or disclose publicly available personal data without consent — data generally available to the public, obtainable with few or no restrictions.

The 2026 guidelines address the harder question: data behind a digital barrier. The PDPC defines that as any technical or financial measure meaningfully restricting access — paywalls, registration requirements, authentication, geo-blocking, age-gates, and anti-bot measures such as rate limits and CAPTCHAs. Crucially, a digital barrier does not automatically make data non-public. Weigh four factors: the purpose of the barrier, its effect (is the data open to the public at large or only a specific group?), the number and complexity of steps needed to get past it, and whether the same data is freely available elsewhere.

Examples run both ways. Public-agency registers remain publicly available even where a fee is charged; metered news paywalls count as monetisation rather than substantive barriers; open forums asking only for a username and email are still publicly available. A professional-body database requiring membership details, by contrast, confines access to a specific group and is likely not publicly available.

Two points are easy to miss. If it is reasonably arguable that data is not publicly available and you rely on the exception anyway, you must record your assessment in a Data Protection Impact Assessment or equivalent and produce it if asked. And the exception says nothing about contracts: terms of service prohibiting scraping still bind you, as do IP and criminal law.

User data and the consent exceptions

For data your customers gave you, or generated through use of your product, first ask whether an exception to consent applies. Two are most relevant.

The business improvement exception (Part 5 of the First Schedule and Division 2, Part 2 of the Second Schedule) covers improving or developing goods, services, methods or processes; understanding customer behaviour; and identifying or personalising offerings. Two conditions attach: the purpose cannot reasonably be achieved without individually identifiable data, and the use must be what a reasonable person would consider appropriate. Sharing under it is limited to related companies.

The research exception (Division 3, Part 2 of the Second Schedule) covers broader R&D without immediate application to your products. It requires that the purpose cannot reasonably be accomplished without identifiable data, a clear public benefit, that results are not used to make decisions affecting the individual, and that published results do not identify individuals. It carries no related-company restriction.

The PDPC gives a pointed example of where business improvement runs out: an apparel company that rebrands as an AI model developer and wants to train on customer names, transaction histories and behavioural data is departing so far from its past commercial activity that a reasonable person would not consider the use appropriate. Fresh consent is required.

AI-Specific Notifications: the practical headline

Where consent is the basis, the Notification Obligation under sections 14(1) and 20(1) of the PDPA applies. The 2026 guidelines draw a line between two kinds of notice.

The Commission encourages four things, so far as practicable: the model functions requiring personal data; a clear description of the data types used; how that data trains or fine-tunes the model; and how individuals can decline or withdraw consent, with instructions or an accessible opt-out.

Notifications can be layered, and one AI-Specific Notification can cover several models if it captures the different processing contexts. Form is your discretion: privacy policy, terms of service, in-product notice or email update.

One hard limit: you must not require consent to AI-development use as a condition of providing a product or service, beyond what is reasonable to provide that service.

Note the scope: “large-scale training and/or fine-tuning” refers only to activities that develop or modify a model’s parameters or underlying capabilities. Using a third-party model through an API to answer customer queries is a deployment question, covered next.

Deployment: which role are you in?

Most Singapore businesses buying AI are not training models. The guidelines allocate responsibilities across three roles, and one organisation can occupy different roles in different contexts.

If you are buying AI in Singapore, you are almost certainly a System Deployer, and that is the row that matters. You need enough information on upstream safeguards to assess a vendor before procuring; you must define the purpose and the amount of personal data required rather than letting a general-purpose system roam; and you must treat prompts, outputs and tool activity as personal data you are responsible for.

Agentic systems get a specific warning: independent multi-step planning with access to external tools exacerbates data protection risk and complicates responsibility allocation. One carve-out is worth knowing — where a Model Provider releases open weights and has no access to personal data downstream, it is not subject to PDPA obligations for that data. Responsibility sits with whoever deploys it.

Post-deployment: access and correction requests

Sections 21, 22 and 22A give individuals rights of access and correction, and those apply to personal data used for model or system development and deployment. Data under your control includes data transferred to a data intermediary, so a vendor relationship does not put it out of reach.

The PDPC acknowledges the difficulty — training data held as embeddings, temporary context windows, and the known hardness of removing specific information from a trained model. Its expectation is best-effort and improving: verify accuracy at collection, de-duplicate, keep provenance records, handle requests case by case and accede where reasonable (a retrieval-augmented generation database is called out as a place where you usually can), strip inaccurate data before future training runs, and use output filters meanwhile.

What non-compliance costs

Since 1 October 2022, the maximum financial penalty for breaching the PDPA’s data protection provisions is 10% of annual turnover in Singapore where that turnover exceeds S$10 million, and S$1 million in all other cases. Turnover is assessed from the most recent audited accounts available when the penalty is imposed. These penalties attach to the PDPA obligations themselves, not to the advisory guidelines — but because the Commission enforces the Act consistently with its published guidance, a documented approach that follows them is the practical defence.

A practical checklist

• Record, per use case, whether you are a Model Provider, System Provider or System Deployer, and whether you act as an organisation or a data intermediary.
• Inventory the personal data flowing into each system: prompts, uploaded files, outputs and agent or tool activity logs.
• For any training or fine-tuning on user data, identify and record your lawful basis: business improvement, research, or consent.
• If relying on consent, replace general “product development” language with an AI-Specific Notification.
• For scraped data behind any digital barrier, complete a DPIA before collection, and separately check terms of service, IP and licensing.
• Document a retention policy for training and inference data, with a rationale for longer retention.
• Before procuring, request vendor documentation on access controls, data residency, retention, leakage testing and breach notification timelines.
• Configure purpose-bound access so the system cannot reach databases outside its defined use.
• Publish internal guidance on what staff may enter into prompts; scan or redact identifiers where feasible.
• Build a workable route for access and correction requests, including removal from RAG stores and future training sets.
• Anonymise and minimise wherever the use case allows — anonymised data falls outside the PDPA — and review agentic use cases separately and more often.

Still deciding which processes to automate before tackling the compliance layer? Our AI automation opportunity scanner is a starting point, and our Singapore practice page sets out how we work here.

How Singapore compares

Singapore’s approach is interpretive rather than legislative: instead of an AI act, the PDPC has clarified how an existing statute applies, alongside IMDA’s Model AI Governance Framework for Agentic AI. For a business operating across markets, the Singapore work is largely documentation and governance rather than a new regime — but it does not transfer cleanly to India’s DPDP Act or the UK’s position after the Data (Use and Access) Act 2025. Treat the notification and lawful-basis layer as market-specific from the start; our custom software page covers how that is structured.

Frequently asked questions

Do I need consent to use my own customer data to fine-tune an AI model in Singapore?

Not necessarily. The business improvement exception may apply if the use improves or develops your goods, services or processes, cannot reasonably be achieved with de-identified data, and is what a reasonable person would consider appropriate. If the use is a significant departure from what customers would expect from your business, the PDPC’s view is that fresh consent is needed.

Is a line in my privacy policy about “product improvement” enough?

Not for large-scale generative AI training or fine-tuning where consent is your basis. The PDPC states that General Notifications are insufficient and an AI-Specific Notification is required — one naming AI or generative AI model development explicitly, with the data types, model functions and opt-out route.

Can I scrape public websites to train a model?

Where the data is genuinely publicly accessible without restriction, the Publicly Available Exception can apply, subject to the reasonableness test. Where it sits behind a paywall, login or anti-bot measure, assess public availability on the facts and document it. Separately, terms of service, IP and criminal law apply regardless of the PDPA position.

We only use ChatGPT or a similar tool — does any of this apply?

Yes. You are a System Deployer, and the guidelines place primary responsibility on deployers for ensuring their chosen system lets them meet their PDPA obligations: define the purpose, limit the personal data entered, secure prompts and outputs, check upstream vendor safeguards, and tell staff what they may input.

Are the 2026 guidelines legally binding?

No. They are advisory and do not modify the PDPA, which prevails in any inconsistency. However, the Commission administers and enforces the Act in line with its published guidance, so following the guidelines is the practical way to demonstrate compliance — and the financial penalties for breaching the underlying PDPA obligations are real.

What should we do first if we have already deployed AI without reviewing this?

Start with an inventory: which systems, which personal data, which role you occupy in each. Then establish your lawful basis for any training on user data, fix the notification if consent is the basis, and document retention and vendor safeguards. Most organisations find the gap is documentation rather than underlying practice.

The 2026 guidelines do not make generative AI harder to use in Singapore — they make the paperwork explicit. Organisations that can show a written lawful-basis assessment, an honest AI-Specific Notification and a defined purpose for each deployed system are in a good position; those relying on a generic privacy-policy line are not. For a structured way through this, see our Singapore PDPA compliance page, and take Singapore-qualified legal advice on anything turning on your facts. Written by the Stratgik team.