Voluntary, dated, concrete, and almost nobody has written a practical "here is what to put on yours" piece. Here is that piece.
The medicine-label metaphor is the point: a chatbot information card should tell users what it is for, what it is not for, and who to call.
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.
Businesses scoping a chatbot in Singapore that will need the card, the notification layer and — most decisively — an ROI justification for the build itself, can start with a costed footprint via the AI chatbot ROI calculator. Rollout and long-term operation of that chatbot inside the SG obligations set is the work of our AI automation service.
References
- PDPC / IMDA, voluntary transparency guidance on chatbot information cards, released alongside the final Advisory Guidelines, 20 July 2026 — pdpc.gov.sg (opens in a new tab)
- Minister for Digital Development and Information Josephine Teo, Singapore Data Festival keynote, 20 July 2026
Ready to grow your business with proven digital marketing?
Our team specialises in performance marketing for Malaysian businesses — from clinics and property developers to national institutions and marketplace brands.
Published by shakalakaa team · Editorial standards