PDPC Advisory Guidelines on Generative AI: What SMEs Should Fix

PDPC's Advisory Guidelines on Use of Personal Data in Generative AI, issued 20 July 2026, add no new law but show how PDPC will read the PDPA for AI. Three things change. Where you rely on consent for large-scale training or fine-tuning, a generic "we use data to improve our services" notice falls short. Consent to that training cannot be a condition of using your service beyond what is reasonable. And if you run a chatbot or agent, you carry primary responsibility for the prompts and tool logs it handles, even when a vendor hosts the model. For owners and compliance leads deciding what to fix first.

The guidelines landed at the inaugural Singapore Data Festival (20 to 24 July 2026) after a public consultation that closed on 1 July 2026 with responses from 40 organisations, including Google and DBS, plus 3 individuals (PDPC fact sheet, July 2026).

What are the PDPC generative AI guidelines, and are they binding?

The PDPC generative AI guidelines are advisory guidance, not law. They explain how the binding Personal Data Protection Act 2012 (PDPA) applies when personal data is used to build, deploy or answer questions about generative AI. PDPC says so in paragraph 1.5 of the guidelines: the guidelines "are advisory in nature, are not legally binding on the Commission or on any other party, and do not constitute legal advice."

That sentence is often read as "optional". Wrong reading. Every expectation in the document hangs off a PDPA section: consent (section 13), notification of purpose (section 20), purpose limitation (section 18), protection (section 24), access and correction (sections 21 to 22A). Ignore the guidance and the sections still bind you; you have only ignored the regulator's published view of compliance. This is general information, not legal advice.

The Advisory Guidelines on Use of Personal Data in Generative AI sit alongside PDPC's earlier guidelines on AI recommendation and decision systems and its Key Concepts guidelines. PDPC's fact sheet names two key recommendations from respondents: more examples of "digital barriers" for web scraping, and more categories of safeguard information that vendors can share downstream. The final text carries longer lists for both (paragraphs 3.4 and 8.3).

A second, separate document arrived the same day. IMDA's Transparency Guidelines for Gen AI Chatbots are voluntary and consumer-facing. Keep the tiers straight: PDPA binds, PDPC guidance interprets, IMDA guidance recommends.

What changes at each stage of the generative AI lifecycle?

The PDPC guidelines pair each of their three stages (development, deployment, post-deployment) with an existing PDPA duty plus a more specific expectation. Development is about the legal basis for training data. Deployment is about who answers for the data flowing through a live system. Post-deployment is about access and correction requests when the data sits inside a model or a retrieval index.

The diagram shows the tiers; the table below starts from what your business actually does, so find your row first.

When do you need an AI-specific notification?

You need an AI-Specific Notification when you rely on consent to train or fine-tune a generative AI model, at scale, on personal data your customers gave you. Paragraph 4.4 of the PDPC guidelines is direct: "General Notifications are an insufficient means of obtaining consent to use User Data for Generative AI development, specifically, for large-scale Generative AI Model training and/or fine-tuning."

Two qualifiers shrink the trigger, and most commentary skips both. First, footnote 11 limits it to "activities that develop or modify a model's parameters or underlying capabilities." A chatbot that answers by retrieving your documents (retrieval-augmented generation, or RAG) does not change the model, so this part does not bite. Neither does sending a prompt to a hosted model. Second, the notification matters where consent is your legal basis. Paragraph 4.2 tells organisations to look first at exceptions such as business improvement, or at deemed consent, and only then seek consent.

The exception route is narrower than it looks. PDPC's own example is an apparel company that rebrands as a generative AI developer and wants to train on customer transaction histories; the move is "so significant a departure from past commercial activities" that the business improvement exception fails and fresh consent is needed. The PDPA's First Schedule adds a second limit: the exception covers use only where the purpose cannot reasonably be achieved without data in individually identifiable form. If redacted data would do the job, the exception does not cover the identifiable version. Properly anonymised data falls outside the PDPA altogether, but deleting names is rarely anonymisation.

The word "improvement" is not banned.

PDPC's example of appropriate notice (para 4.7) is a privacy-policy line saying user content "may be used for product improvement purposes, including the training and running of our AI models", layered with a supporting web page, an in-platform update and an email with a decline link. What fails is the notice that never mentions AI. Paragraph 4.6 encourages four items, to the extent practicable: the model's function, the types of personal data, how they will train it, and how to decline or withdraw.

Illustrative example: a home-services company has 30,000 customer accounts and 50,000 past chat transcripts, and wants an AI assistant that drafts replies. Route one is RAG over its price list and service notes. No parameters change, so the AI-Specific Notification question does not arise; the work is purpose limits and protecting chat logs. Route two fine-tunes a model on the 50,000 transcripts. If the company relies on consent and 20% of customers decline, about 10,000 transcripts must be filtered out before every training run. The filter protects future runs only. It cannot pull a decliner's data out of a model already trained, so it must exist, with an owner, before the first fine-tune. The decision: start with retrieval, prove the quality gap, then build the filter.

Why is bundled consent for AI training the trap?

Bundled consent for AI training is the trap because the PDPA itself, not the guidelines, can invalidate it. Section 14(2)(a) bars an organisation from requiring consent, "as a condition of providing a product or service", beyond what is reasonable to provide it. Section 14(3) says consent obtained that way "is not validly given". Paragraph 4.8 of the guidelines applies this to AI model development.

Picture the usual sign-up screen: one checkbox, "I agree to the Terms of Service and Privacy Policy", where the privacy policy now mentions AI training. If the customer cannot use the service without ticking it, the training consent inside it is likely invalid. An optional training tick on the same screen is a different case. Invalid consent leaves you hunting for another legal basis for every record you trained on.

The mistake costs more with generative AI. PDPC acknowledges "limitations to model correction post-training" (para 4.5) and that removing specific information from models is hard (para 10.4). A bad consent design in a CRM is fixed with a database query. In a fine-tuned model, it can mean a retrain. Where PDPC finds an intentional or negligent contravention, the maximum financial penalty for an organisation under section 48J(3) of the PDPA is 10% of annual Singapore turnover if that turnover exceeds S$10 million, otherwise S$1 million.

Do not make AI-training consent a condition of using your service.

The fix is design, not legal drafting. Put AI training on its own line, unticked, with the paragraph 4.6 items in plain words. Let the service work for people who say no. Keep a consent record per customer: notice version, channel and timestamp, the decision, and which training runs used the data. That last field is what lets you honour a withdrawal later. For the owner or MD, the trade is simple: a smaller, clean training set beats a large one you may have to throw away.

What do customer-facing chatbots and AI agents need now?

Customer-facing chatbots and AI agents fall under the deployment part of the guidelines, where the business running the system carries the weight. Paragraph 9.1 says System Deployers "bear primary responsibility for ensuring that the Generative AI Systems they have chosen to use can meet their obligations under the PDPA", whether they built the system or rent it as a service.

Paragraph 9.3 is the line CTOs should pin up. Deployers must safeguard "new categories of data sources that are collected through their systems (e.g. end-user prompts, inputs and generated outputs, agent or tool activity data, internal enterprise data)", and must "track and designate responsibilities" over them. Customers paste NRIC numbers into chat windows; agents write tool-call logs containing whatever they touched. PDPC's HR-chatbot example shows the operating pattern: one unit owns prompts and outputs, prompts are scanned for common identifiers, and only authorised maintenance staff can open the logs. A written retention period is good practice too (para 7.3).

For the technical lead, purpose limitation (para 9.2) becomes an engineering requirement. PDPC's example is a medical-records triage system configured so it "cannot query or retrieve data outside its purpose", with no access to billing or patient contact lists. For agents, paragraph 9.5 asks deployers to review safeguards regularly and points to IMDA's Model AI Governance Framework for Agentic AI (our reading of it). Its sales-assistant example adds role-based controls on the assistant's file and network access, stricter handling for data tagged as sensitive, and "escalating protocols to humans for complex or high-risk tasks". In our terms: bounded permissions and human escalation. A confirm step is one way to build that escalation so people do not rubber-stamp it; that is our design choice, not a control PDPC names, and our confirm step design guide covers it.

For operators and customer-facing staff, the visible change is transparency. IMDA's voluntary chatbot info card covers what the bot can and cannot do, how reliable it is, how data is handled and how to report problems. Several organisations, including Google (for the Gemini app), Meta, DBS, OCBC, Singapore Airlines and Synapxe, indicated the guidelines will provide "a point of reference" over the next 12 months (IMDA, 20 July 2026).

What should you check in AI vendor terms?

AI vendor terms decide which role your vendor plays under the PDPA, and the guidelines make that role switchable. A provider that runs inference or hosts data for you is a data intermediary with its own protection duty (para 7.4). A provider that uses your users' prompts to develop its own models is an organisation for that use (para 7.1), processing for its own purposes rather than yours.

That distinction is where most SME exposure hides.

Under PDPA section 4(3), your obligations cover what an intermediary does on your behalf, as our PDPA liability breakdown explains. Our reading of paragraphs 6.3 and 7.1 together: once a vendor's default "use inputs to improve our models" setting is on, your customers' data leaves the intermediary relationship for a purpose your notice probably never mentioned. The clean fix is to switch the setting off or cover it in the contract, not to stretch your privacy policy.

The guidelines also hand compliance teams a due diligence list. Paragraph 9.1 says deployers must have "sufficient information on upstream safeguards to conduct a holistic assessment". Paragraph 7.5 calls it good practice for model providers to document access controls, data residency, retention and breach procedures; paragraph 8.3 adds input and output filters, data leakage test metrics and notification timelines for system providers. A vendor that cannot answer leaves a gap in the assessment PDPC expects. Data your intermediary holds still counts as under your control for access and correction (para 10.2), and the intermediary need not handle requests itself, so put the find-and-fix duty in the contract.

Where Origin Pi stands

We read these guidelines as PDPC moving consent from the legal page into the product. The obligations are old. What is new is a regulator describing, paragraph by paragraph, the screens and settings that make them real. That favours businesses that treat consent and data flows as system design.

Most SMEs will deploy chatbots and agents on rented models rather than train one, so the exposure sits in deployment: in what flows through prompts and in vendor defaults. We design agent workflows with bounded permissions, so an agent reaches only the data its task needs, and with escalation to a person for high-risk steps. Those two match the controls in paragraph 9.5's sales-assistant example. We add two the guidelines do not prescribe: an audit trail of what the agent touched and why, which gives the owner paragraph 9.3 asks for something to review, and a confirm step that makes escalation a real decision. Our AI compliance work maps each control to the PDPA section it serves.

A first action for this week: list every AI tool your team uses and mark one column, "changes model parameters: yes or no". The "yes" rows need a consent design review. The "no" rows need a named owner for their logs.