PDPA and AI Chatbots: 8 Checks Before Go-Live

PDPA and AI chatbots: what must you check?

Use this as the go-live gate. A “no” or “unknown” should have an owner and a resolution before customers enter real data.

This is an operating checklist, not a new set of legal obligations. It is drawn from the PDPA's accountability, consent, purpose, notification, access, correction, accuracy, protection, retention, transfer and breach-notification duties, together with PDPC's AI guidance.

PDPC advisory guidelines explain how the Commission interprets the PDPA and describe good practices; they are not a separate chatbot licence. The binding question remains whether the organisation complies with the Act and applicable regulations in its actual data flow.

1–3. Does your notice cover the chatbot and AI training?

Begin with purpose. A delivery chatbot may reasonably need a name, mobile number, order reference and address. It probably does not need an NRIC number, a full payment-card number or a copy of an identity document just to answer “where is my order?”. Data minimisation is the practical result: collect only what the documented job requires, and do not invite sensitive information in a free-text prompt when a safer field will do.

The PDPA generally requires consent unless an exception applies, limits collection, use and disclosure to purposes a reasonable person would consider appropriate, and requires the individual to be informed of those purposes before collection, use or disclosure. Put the short notice where the conversation starts. Say who is operating the bot, what data it needs, what it will do with the data and how the customer can reach a person or the DPO. A link to the full policy can carry the detail, but it should not be the first time the customer learns the purpose.

Now separate service delivery from model development. A customer may expect a transcript to be used to complete an order and let staff resolve the conversation. That does not automatically mean the customer agreed to have the transcript reused for model training. Treat model development as a separate purpose: document the legal basis, give an appropriate notice and provide a withdrawal route where consent is required.

This distinction changes the safest default. Configure customer prompts and transcripts not to train or fine-tune a model unless the business has deliberately assessed that purpose and its legal basis. For testing, prefer synthetic or properly anonymised conversations. Removing a name is not enough if the remaining details can still identify the customer when combined.

4. What must you check in the chatbot vendor contract?

Draw the vendor chain, not only the vendor logo. Identify the chatbot provider, messaging channel, implementation partner, support staff, analytics tools, connected business systems, sub-processors and backup locations. For each one, record what personal data it receives, its role, processing location, retention period and whether it may use the data for its own purposes.

A service provider processing personal data on your behalf may be a data intermediary. PDPC's AI guidance says a bespoke AI service provider acting in that role has direct Protection and Retention Limitation obligations, while the deploying organisation remains responsible for the other applicable duties. The contract should therefore set documented instructions, confidentiality and access controls, security standards, sub-processor controls, deletion or return, help with access and correction requests, breach escalation and audit evidence.

Ask one question plainly: does any personal data leave Singapore? The PDPA does not ban overseas processing. It requires the transferring organisation to ensure a standard of protection comparable to the PDPA, using the mechanisms allowed by the legislation and regulations. A region selector is useful evidence, but it is not a transfer assessment by itself; check support access, sub-processors and backups too.

Also ask whether the vendor stores prompts, how long logs persist, whether staff can view conversations, whether your data is used to improve a shared service, and how deletion propagates. If the answer is “see standard terms”, read the exact terms in force at go-live and save the version you approved.

5–7. How should an AI chatbot be bounded and tested?

Treat the bot as a staff member with a narrowly written job, limited access and an escalation rule.

• 5. Set permissions and approval gates: Give the chatbot access only to the fields and actions required for its workflow. Let it answer approved questions and prepare routine actions; require a person for refunds, identity changes, financial commitments, disputed facts and other consequential or irreversible steps. IMDA's 2026 agentic AI framework likewise puts meaningful human accountability and limits on tool and data access at the centre of deployment.
• 6. Preserve accuracy and individual rights: Do not let generated text silently overwrite a customer record. Show staff the source for a proposed change and log who approved it. Test whether the team can find personal data held in the transcript or connected record, correct it where the PDPA requires, explain the use and route a withdrawal or access request to a person. Handle each request through a documented process. Model complexity is no excuse for a blanket refusal.
• 7. Test security, failure and deletion: Use synthetic data to test attempts to reveal another customer's order, override instructions, extract hidden information, upload malicious files or push the bot into an unauthorised action. Verify authentication, least-privilege access, encryption, secrets handling, rate limits, monitoring, staff access, safe failure, human handoff, rollback, log redaction and scheduled deletion.

A polished happy path proves very little. Run wrong-order numbers, reused phone numbers, shared family accounts, ambiguous names, abusive messages, unsupported languages, unavailable connected systems and a customer who asks the bot to forget previous instructions. The release decision should be based on recorded pass criteria and unresolved-risk owners, not a demo that worked once.

Retention needs its own test. The PDPA requires an organisation to stop retaining documents containing personal data, or remove the means of association, when the original purpose is no longer served and retention is no longer necessary for legal or business purposes. Apply that rule to transcripts, exports, evaluation sets, logs and backups, not only the customer record visible to staff.

8. Who owns the PDPA decision and breach response?

Singapore organisations must designate at least one person responsible for PDPA compliance and make the DPO's business contact information public. The DPO does not need to run the chatbot day to day, but should be able to challenge the data map, legal basis, notice, vendor terms, transfer assessment, access controls, retention schedule and incident route before signing off.

Name an operational owner as well. That person watches failure and complaint patterns, approves changes to prompts or permissions, keeps the vendor record current and can pause the bot. A production change that adds a new data source or action should reopen the relevant checks; a launch review is not permanent approval for a different workflow.

Prepare for a chatbot incident before customers arrive. PDPC's breach guide says an organisation with reason to believe a breach occurred should assess whether it is notifiable in a reasonable and expeditious manner, generally within 30 calendar days. After determining that a breach is notifiable, the organisation must notify PDPC as soon as practicable and no later than three calendar days; affected individuals must also be notified as soon as practicable where the statutory significant-harm test applies, subject to the Act's exceptions and prohibitions.

The playbook should say who can disable the bot and integrations, preserve logs, contact the vendor, assess affected data and people, reach the DPO and communicate with customers. It should work outside office hours, because a compromised bot will not wait for the next management meeting.

What does a PDPA-ready chatbot flow look like?

Consider a Singapore wholesaler using a WhatsApp chatbot for stock questions, orders and delivery updates. This is a worked example, not a claim that one design fits every business.

Compared with manual handling, the chatbot removes repeated catalogue replies, copying order fields and routine status checks. Compared with hiring another administrator, it can cover the repetitive path without adding a new inbox shift. Neither comparison removes the need for a responsible person: staff still resolve identity uncertainty, complaints, exceptions and decisions the bot is not authorised to make.

This is also how to scope a customer operations AI agent: one job, explicit data access, documented approvals and a clean handoff. For the wider control model, use the agentic AI governance checklist alongside this PDPA review.

What evidence should you keep before go-live?

Put the evidence in one release record so the owner, DPO and incident team can find the same answer.

• 1. Data-flow map: Fields, purposes, systems, recipients, countries, logs, backups and deletion points for one end-to-end conversation.
• 2. Customer communications: The opening notice, full privacy notice, consent or exception analysis, human-contact route and any AI-specific training notification.
• 3. Vendor file: Signed terms, processing instructions, sub-processors, transfer safeguards, retention, deletion, security and breach duties.
• 4. Control record: Permissions, approval gates, test cases, results, accepted risks, monitoring, rollback and change owner.
• 5. Rights and incident procedures: Access and correction handling, withdrawal route, retention schedule, DPO details, breach assessment and escalation contacts.

If the chatbot will initiate marketing messages to Singapore telephone numbers, run a separate Do Not Call review before activation. PDPC's DNC guidance covers the duty to check the register, the alternative of clear and unambiguous consent in evidential form, and sender identification requirements. A customer-service conversation does not silently create permission for every later campaign.

This checklist is operational guidance, not legal advice. A business handling health, financial, children's or other high-impact data should obtain advice for its sector and exact use case before launch.