PDPC Proposed Advisory Guidelines on GenAI · Submission Framework
CONSULTATIONPDPC issued proposed advisory guidelines on 2 June 2026. Public consultation closes 1 July 2026. This document outlines the framework for Alliance Healthcare's submission, structured around five consultation questions and our unique dual perspective as both DPO and AI builder.
Most consultation responses will come from large enterprises, law firms, and big tech. Their perspective is valid but incomplete. They have dedicated compliance teams, legal departments, and vendor risk functions. SMEs do not.
Our submission addresses the gap between what the guidelines assume about organisational capacity and what SMEs and AI builders actually have.
Two roles, rarely combined:
| Role | What we see | What most submitters miss |
|---|---|---|
| DPO at Alliance Healthcare | The compliance burden of implementing guidelines inside a real organisation with finite resources | The practical cost of building AI-specific notification systems, vendor assessment workflows, and data provenance tracking from scratch |
| AI builder (ShiokAlarm) | The engineering reality of training data handling, model architecture, and what 'machine unlearning' actually means in practice | The gap between regulatory expectations and current technical capabilities — especially for access/correction on trained models |
| Combined | Where the guidelines work, where they create asymmetry, and where they assume capacity that does not exist for SMEs | The asymmetry problem: big tech can absorb compliance costs. SMEs cannot. The guidelines risk entrenching that divide. |
The guidelines assume organisations can: assess digital barriers, notify source organisations before scraping, build AI-specific notification systems, request and evaluate upstream security documentation, implement data provenance tracking, and track machine unlearning maturity. Large organisations can do this. Most SMEs cannot. If the guidelines do not account for this capacity gap, they will disproportionately burden the organisations least able to bear it.
Consultation question: Are there other examples of 'digital barriers' under paragraph 3.4 that would be useful to clarify?
We will comment on the 'notify before scraping' best practice in paragraph 3.7. The obligation creates a coordination problem that the guidelines do not fully address. Specifically: who at the source organisation should be notified, through what channel, and within what timeframe should they respond? Without clarity, the collecting organisation cannot plan its data collection pipeline, and the notified organisation may not have the internal capacity to assess whether its data is publicly available.
Recommendation: The guidelines should specify a default notification channel (e.g. a standardised form or DPO contact) and a reasonable response window (e.g. 30 days). Silence after the window should not constitute denial.
Additional barrier examples worth clarifying:
Consultation question: Should organisations provide AI-Specific Notifications in situations other than Generative AI Model training and/or fine-tuning?
From an SME DPO and builder perspective, the four-element notification standard (model function, data types, training method, opt-out mechanism) is theoretically sound but practically heavy. For a small organisation deploying a third-party SaaS GenAI tool, the deployer may not know the model's function in sufficient detail to describe it to users. The information asymmetry between Model Providers and Deployers is real.
Recommendation: The guidelines should clarify that Deployers relying on third-party models can satisfy AI-Specific Notification obligations by disclosing what they know (the use case, the data types they control, the opt-out mechanism) without needing to describe the Model Provider's internal training methodology. Model Providers should bear the obligation to disclose model-level information to Deployers.
The example in the guidelines (social media platform with in-platform pop-ups, dedicated privacy page, email notification with opt-out link) describes a four-touchpoint notification system. That is achievable for a platform with engineering resources. For an SME with a static website and a contact form, this is a significant build. The guidelines should acknowledge tiered expectations based on organisational size and technical capacity.
Consultation question: Are there other best practices at paragraphs 4.6 (notifications) and 10.4 (access/correction)?
Paragraph 10.4(c) asks organisations to 'track the maturity of and adopt appropriate technical measures (e.g. machine unlearning) to remove inaccurate personal data from models.' As someone building AI systems, I can say directly: machine unlearning is not production-ready. Current research approaches (gradient ascent, influence functions, retraining from scratch) are either unreliable, computationally expensive, or both. No major model provider offers a production-grade unlearning guarantee.
Recommendation: The guidelines should state explicitly that machine unlearning is an emerging technology, not a current solution. The best practice should be reframed as: (1) prevent personal data from entering training sets where possible via upstream filtering, (2) maintain provenance records so data can be excluded from future training runs, and (3) track unlearning research but do not represent it as a current compliance mechanism.
If PDPC expects organisations to remove specific personal data from trained models, the honest answer is: the technology does not exist at production quality today. The guidelines should acknowledge this gap rather than implying it is a matter of adoption. Otherwise, organisations will claim compliance they cannot actually deliver.
Consultation question: Is there additional information on data protection safeguards that would be helpful for Model and System Providers to share with downstream stakeholders?
As a Deployer (Alliance Healthcare) procuring GenAI systems, the single biggest gap is not the type of information shared — it is whether it gets shared at all. Many SaaS AI vendors do not proactively provide security documentation. SMEs lack the procurement leverage to demand it. The result: Deployers cannot conduct the 'holistic assessment' the guidelines require because the information is not available.
Recommendation: The guidelines should state that Model and System Providers have an obligation to proactively provide a minimum baseline of data protection information to Deployers, not just on request. This baseline should include: data residency, retention periods, access controls, training data handling (whether user data is used for model training), and breach notification commitments. Without proactive disclosure, the Deployer obligation is impossible to meet for SMEs.
| Information type | Currently shared by vendors? | Critical for SME Deployers? |
|---|---|---|
| Whether user data is used for model training | Sometimes, buried in ToS | Yes — determines notification obligations |
| Data residency and storage location | Rarely proactively | Yes — determines cross-border considerations |
| Retention periods for inference data | Rarely | Yes — determines Retention Limitation compliance |
| Access control documentation | On request only, if at all | Yes — determines Protection Obligation assessment |
| Breach notification commitments | In contracts, not always clear | Yes — determines breach response timeline |
Consultation question: Are there other agent-specific data challenges or risks that would be helpful to clarify at paragraph 9.5?
I am building agentic features into a consumer iOS application (ShiokAlarm). From the builder side, the data protection risks the guidelines mention (unauthorised access, use, disclosure) are real, but there are additional challenges worth surfacing:
1. Scope creep in agent actions. An agent tasked with a specific objective may access data tangential to that objective to complete the task. The Purpose Limitation Obligation becomes harder to enforce when the agent itself decides what data it needs.
2. Data accumulation through tool use. Agents that call external APIs or tools accumulate data in their context windows. This data may include personal data from third-party sources that the Deployer did not originally collect. Who is responsible for this incidental data?
3. Audit trail gaps. Agent reasoning is often opaque. If an agent accesses personal data, the audit trail may not capture why it did so or whether the access was justified by the user's objective.
Recommendation: The guidelines should add that Deployers of agentic AI must: (1) scope agent permissions to the minimum data access needed for the stated objective, (2) implement logging that captures not just what data the agent accessed but the reasoning context, and (3) establish boundaries on tool use to prevent incidental collection of personal data from third-party sources.
The guidelines reference IMDA's Model AI Governance Framework for Agentic AI. That is good. But the PDPC guidelines should include at least a baseline expectation for agent-level data access controls. Relying entirely on a separate framework creates a gap: Deployers reading PDPC guidelines may not realise additional agentic obligations exist elsewhere.
Per paragraph 3.1 of the cover note, submissions should follow this structure:
Email: corporate@pdpc.gov.sg
Subject: PDPC's Public Consultation on Proposed Advisory Guidelines on use of Personal Data in Generative AI
Format: Microsoft Word
Deadline: 1 July 2026, 5:00 PM
| # | Argument | Consultation Q | Our ask |
|---|---|---|---|
| 1 | Digital barrier notification needs a default channel and response window | Q1 | Standardised notification form + 30-day response window |
| 2 | AI-Specific Notifications should be tiered for SMEs and split between Deployers and Model Providers | Q2 | Deployers disclose what they control; Model Providers disclose model-level info |
| 3 | Machine unlearning is not production-ready and the guidelines should say so | Q3 | Reframe as upstream prevention + provenance tracking, not unlearning |
| 4 | Vendors should proactively provide baseline data protection info, not just on request | Q4 | Minimum baseline disclosure obligation on Model/System Providers |
| 5 | Agentic AI needs agent-level access scoping, reasoning-context logging, and tool-use boundaries | Q5 | Add baseline agentic data controls to PDPC guidelines, not just reference IMDA |
Every argument comes back to the same point: the guidelines are directionally correct but assume organisational capacity that most SMEs do not have. The fix is not to lower the bar — it is to clarify who bears which obligation, provide practical implementation pathways, and be honest about where technology is not yet ready.