PDPA and AI: what PDPC’s 2026 guidelines expect of SMEs

If your business uses ChatGPT-style tools or a customer chatbot that someone else built, PDPC’s Advisory Guidelines on Use of Personal Data in Generative AI treat you as a “system deployer”. They say a deployer bears primary responsibility for ensuring that the AI systems it has chosen can meet its PDPA obligations, so, on our reading, a vendor’s assurances alone do not settle the question for you.

Paragraphs 9.1 to 9.5 are where the PDPA and AI meet for a deployer: five responsibilities, in wording that runs from “must” to “encouraged”. Have enough information on how a tool protects data (9.1), keep each use to a defined purpose (9.2), safeguard prompts, outputs and other new data sources (9.3), write the rules down (9.4), and review safeguards regularly, especially for agentic features (9.5). The guidelines were issued on 20 July 2026 and are advisory, not legally binding. This is general information, not legal advice.

Which role does your business play?

PDPC names three roles around a generative AI tool (paragraph 6.2). The plain-language examples are ours.

• Model provider: develops and makes available the underlying model. If it runs your customers’ messages through the model for you, PDPC treats it as a data intermediary with a protection duty of its own (paragraph 7.4).
• System provider: develops and makes available a system built on a model, bespoke or off the shelf, such as the software company whose chatbot or document tool you buy. When it processes data for you, it is a data intermediary (paragraph 8.1).
• System deployer: uses and/or enables the use of such a system under its authority. On our reading, that is you once you buy a licence, switch on an AI feature or let staff use a tool for work.

A business that builds its own system in-house also takes on the provider roles (paragraph 9.1), and PDPC wants an organisation with several roles to be clear about each (paragraph 6.3). Buying from a vendor does not move the responsibility (paragraph 9.1), and personal data a vendor holds on your behalf still counts as under your control when you handle access and correction requests (paragraph 10.2).

How binding is PDPC’s wording for deployers?

The guidelines are advisory, but the deployer paragraphs are framed around PDPA obligations, and their wording varies in strength:

• “Must”: when procuring a system, have enough information on upstream safeguards to assess it as a whole (9.1). Safeguard personal data you hold or control, including prompts, outputs and agent activity data; designate who is responsible for each source; and educate users on which types of personal data may be entered (9.3).
• “Should”: be disciplined about each use’s purpose and the personal data it needs (9.2); review whether safeguards are still enough, especially for agentic features (9.5).
• “Encouraged” or “good practice”: written policies and documented processes, where making them available in advance, for example on your website, shows accountability (9.4); a retention policy that explains why data is kept longer, with regular reviews (7.3, which PDPC extends to deployers that retain personal data to develop and deploy AI systems).

On our reading, softer wording does not make the underlying PDPA obligation optional: the guidelines tie purpose limitation to section 18 (9.2), protection to section 24 (footnote 20) and retention limitation to section 25 (7.2).

What do PDPC’s three deployer examples look like in a small business?

PDPC follows paragraphs 9.2, 9.4 and 9.5 with Organisations A, B and C. The versions below are our own fictional equivalents, not PDPC’s examples.

Organisation A: document triage (9.2). PDPC’s Organisation A defines a medical-records triage system’s purpose as the administrative prioritisation of documents and gives it no access to other databases such as billing systems or patient contact lists. Illustrative version: a nine-agent property agency uses AI to sort enquiries into queues (viewing requests, document submissions, complaints). It needs only the enquiry type, property reference and preferred timing, and the tool is not connected to tenancy documents or commission records.

Organisation B: HR chatbot (9.3 and 9.4). PDPC’s Organisation B makes its HR unit responsible for the chatbot’s prompts and outputs, sets guidelines on what a prompt may contain, scans prompts for common personal identifiers, limits access to prompt logs to authorised maintenance personnel and documents this in guidelines given to all employees. Illustrative version: a 40-person logistics company adds a policy chatbot to its HR system. The HR manager owns prompts and outputs, staff are told to ask how a leave rule applies rather than paste a medical certificate, and the vendor is asked who can read the logs. The rules go into a one-page staff AI policy.

Organisation C: sales assistant with agentic features (9.5). PDPC’s Organisation C adds role-based limits on the assistant’s file and network access, tags more sensitive personal data for stricter handling and escalates complex or high-risk tasks to humans. Illustrative version: a 15-person furniture retailer lets an assistant draft follow-ups from customer notes. It limits which folders the assistant can open, tags notes that mention a customer’s health or money difficulties, and requires a person to approve anything involving a refund or a dispute. PDPC points to IMDA’s Model AI Governance Framework for Agentic AI (version 1.5, published 20 May 2026, updated 5 June 2026); see our checklist on that framework and what agentic AI means.

Can staff paste customer details into ChatGPT?

The guidelines do not name ChatGPT or any other product, and they neither approve nor ban a tool. They do say a deployer must educate users on the specific types of personal data that should be entered, for example only pre-defined categories (9.3), and, when procuring a system, must have enough information on upstream safeguards to assess it as a whole (9.1).

So the question becomes: which tool, which data, which purpose? A workable rule, our suggestion and not PDPC’s, is two short lists per approved tool. Allowed: for example a customer’s first name and the text of an enquiry. Not allowed until you have assessed the tool: identity numbers, payment details, health or financial hardship. Under this rule, a personal account on a tool you have not assessed sits outside both lists, because you would have nothing to show what the vendor does with the data.

A customer chatbot adds notification. Customers’ messages will often contain personal data, and the PDPA’s Notification Obligation (section 20(1), quoted in paragraph 4.2) requires an organisation to tell individuals the purposes for which their personal data is collected, used or disclosed. PDPC points system providers to IMDA’s Transparency Guidelines for Generative AI Chatbots for transparency practices (paragraph 8.3); see our guide to IMDA’s chatbot information card. Training is where PDPC is firmer: for large-scale training or fine-tuning on user data, a general statement such as “new product development” is insufficient and an AI-specific notification is needed (paragraphs 4.3 to 4.6); where no exception or deemed consent applies, consent is required (paragraph 4.2). That passage concerns changes to a model’s parameters or capabilities (its footnote 11), so ask each vendor whether it does this with your customers’ data.

What if a customer asks what your AI tool holds about them?

Access and correction duties cover personal data collected, used or disclosed to develop or deploy an AI system, including data a data intermediary holds for you (paragraphs 10.2 and 10.3). You must comply unless a PDPA exception applies, such as unreasonable burden or expense. PDPC accepts this is hard with AI (paragraph 10.4). Where reasonable and appropriate, it expects organisations to review requests case by case and accede where reasonable, for instance when the data sits in a retrieval-augmented generation database. Until inaccurate data can be removed from models, it says organisations can consider output filters (paragraph 10.5).

PDPC’s page on the Data Protection Obligations states the Accuracy Obligation as making reasonable effort to ensure that the personal data collected is accurate and complete, especially if it is likely to be used to make a decision that affects the individual or to be disclosed to another organisation. PDPC does not apply this to AI output in so many words; our inference is that a tool stating something false about a named customer raises an accuracy question, so see checks before customers see an answer.

What to check before you rely on a generative AI tool

Copy this list for each tool. The list is ours; the numbers show the paragraph of the 2026 guidelines each item draws on, unless stated.

1. Role (6.3). Note whether you only use the tool or also build or customise systems.
2. Vendor information (9.1). Record what the vendor says about access controls, data residency, retention and incident and breach procedures, which PDPC calls good practice for providers to share (7.5 and 8.3). Gaps are questions for the vendor; see AI vendor questions before you sign.
3. Purpose (9.2). One sentence on what the tool is for and which personal data that needs. Disconnect the rest, as Organisation A does.
4. Data sources (9.3). List prompts, outputs, logs, agent activity and internal data the tool can reach. Name an owner for each.
5. User instructions (9.3). Tell staff, and customers where relevant, which categories of personal data may be entered and how they will be processed.
6. Written rules (9.4). Put items 2 to 5 in a short policy and consider publishing a summary. PDPC’s 2024 guidelines say section 12 of the PDPA requires policies and practices to meet your obligations, and suggest a short, simple policy (paragraphs 10.2 and 10.4).
7. Retention (7.3). Decide how long prompts, outputs and logs are kept, and why. PDPC calls a retention policy with a rationale for longer retention good practice and extends it to deployers that retain personal data to develop and deploy generative AI systems. The PDPA duty is to stop keeping personal data, or dispose of it properly, when it is no longer needed for any business or legal purpose (PDPC chart).
8. Overseas processing. Ask where the tool processes data. The 2026 guidelines do not discuss the Transfer Limitation Obligation, but the chart summarises it as applying to transferring personal data overseas.
9. Requests and breaches (10.2 to 10.5). Decide who handles access and correction requests, including for data your vendor holds (your DPO’s published contact can receive them), and how the vendor would tell you of a breach. The chart says a breach likely to cause significant harm, or of significant scale, goes to PDPC and affected individuals as soon as practicable; the chart dates from May 2021, so check PDPC’s current breach-notification guidance for the deadline, which we did not read for this article. See also our PDPA data breach notification playbook.
10. Review (9.5). Diarise a review date, and another before switching on any agent or automation feature. Set limits and human escalation first; our note on what a chatbot or agent may do helps.

Start with the tool your team uses most: complete items 2 to 5 for it, then repeat. More are in the AI topic.

Common questions