What the guidance actually asks for
Three headings, in the guidance\'s framing:
- What the chatbot can and cannot do. Scope of tasks it handles well, tasks it does not handle, tasks it will refuse.
- How user data is handled. What is collected, what happens to it, whether it is used for training, retention.
- How to report problems. A named channel — not a generic support email — for a user who thinks the chatbot has done something wrong.
A working template
The card below is a defensible starting point for a Singapore business running a public-facing chatbot. Copy, edit for your specifics, publish alongside the chatbot itself:
About this chatbot
This is an AI-powered assistant operated by [Company Name] (Singapore UEN [xxxxxxx]). It uses [named model / model family] provided by [vendor].
What it can do: Answer questions about our services, help you book an appointment, provide general information about [scope].
What it cannot do: Give personalised professional advice on [medical / legal / financial matters — as applicable]. Confirm bookings without human review. Access your account or make changes to your records.
Data: Your messages are transmitted to [vendor] for processing. [We do / do not] use your messages for model training. Conversations are retained for [n days] for quality review and then deleted.
Human handover: Type "speak to a person" or contact us at [named channel / phone / email].
Report a problem: If the chatbot gave incorrect or harmful information, email [named contact] — we log every report and review within 2 business days.
Why this is worth doing even though it is voluntary
Three reasons:
- It doubles as PDPA compliance evidence. The "data" section of the card overlaps directly with the AI-Specific Notification requirement that is mandatory.
- It is a live trust signal. Businesses publishing a card are declaring the chatbot is not a mystery. In a market where consumer scepticism about AI is well-documented, this is a differentiator now and becomes table stakes later.
- It is documentation if something goes wrong. If a complaint reaches the PDPC or the CCCS, being able to point at a public card that named the chatbot\'s scope, its limits, and the reporting channel is a stronger position than not being able to.
Common failure modes
- Card buried in the terms of service. The point is that the card is next to the chatbot, not in a legal document behind a link.
- Card that describes capabilities but not limits. The "cannot do" section is the operationally important one.
- Reporting channel that is a generic support inbox. Name the actual owner or the actual triage process.
- Card written by the vendor, not the deployer. The deployer\'s use of the chatbot is the specific thing the card should describe.
Related reading
- The mandatory AI-Specific Notification requirement
- DNC + PDPA for Singapore lead follow-up
- shakalakaa Singapore practice
References
- PDPC / IMDA, voluntary transparency guidance on chatbot information cards, released alongside the final Advisory Guidelines, 20 July 2026 — pdpc.gov.sg
- Minister for Digital Development and Information Josephine Teo, Singapore Data Festival keynote, 20 July 2026