Bee Cheng Hiang AI Data Breach: PDPC Undertaking and SME Lessons

The Bee Cheng Hiang data breach was not an AI malfunction. An employee used a generative AI tool to write a bulk-email script, tested it by reading activity logs, and deployed it with no second person reviewing it, so each of 95,364 members' email addresses was shown to up to 999 other members. PDPC accepted a voluntary undertaking and imposed no financial penalty. For an SME owner or CTO, the useful part is the five measures that undertaking lists. They translate into controls for anyone on staff who now writes code with AI.

PDPC posted the undertaking on its website on 21 September 2026. On 30 September 2026 it told The Straits Times, as reported by The Business Times, that this was the first AI-related data breach notified to it. The same day it published an advisory on unauthorised AI tools whose illustration describes the same failure. This is general information, not legal advice.

What happened at Bee Cheng Hiang?

On 25 April 2026, Bee Cheng Hiang Marketing sent a marketing email to its members in batches of 1,000, with every address in each batch visible in the "To" field. According to PDPC's undertaking page, posted 21 September 2026, 95,364 people were affected, the data was email addresses only, and the company notified PDPC on 27 April.

The script was Python, written by one employee "through the personal use of a generative artificial intelligence ("AI") tool," in PDPC's words. It called an email-sending service (PDPC's comparison names SendGrid) and built each batch's recipient list. Here is the line that went out, exactly as PDPC published it:

"personalizations": [{"to": [{"email": str(e)} for e in chunk]}]

And the corrected version:

"personalizations": [{"to": [{"email": str(e)}] } for e in chunk]

PDPC describes the error as a missing bracket. If you do not read code, watch where the loop (for e in chunk) sits. In the first version it sits inside a single "personalization", which is one email, so all 1,000 addresses land on one message. In the second it sits outside, so the service builds 1,000 separate emails with one address each. Same data, same tool, same send button.

PDPC records that the company halted the sends, fixed the script and told every affected member. It also introduced its own rule: at least two staff now double-check every bulk email before it goes out. PDPC found "no evidence of further misuse" of the addresses, and notes this was the first time the company had tried to use AI tools in its operations.

Why does PDPC say the AI tool did not malfunction?

PDPC puts the fault in the prompt, not the tool: the prompt never asked for other recipients to be hidden, and the script did not hide them. In PDPC's words, this "was not a malfunction in the AI tool but resulted from the prompt given to the AI tool to write a programme to send "mass email using a local list" in batches, without specific instructions to block the visibility of other recipients' email addresses to each individual recipient."

A prompt is a specification. A developer writing a bulk mailer by hand usually hides other recipients without being told; an AI tool applies what it is told, plus whatever its training makes likely. Unstated requirements are where AI-written code breaks, and privacy requirements are usually the unstated ones.

Then the test. The employee "did not realise the error before deploying the script, as testing was done by checking activity logs without reviewing the contents of the actual test email." The logs said the emails went out. They did. A log proves delivery; only the inbox shows who else got the message.

PDPC also told CNA on 30 September 2026 that "the incident was caused by a human error in developing the email distribution code with an AI tool." The undertaking page adds that the affected data "was not managed, processed, or generated by any AI-powered operation or process." So "AI-related" means AI wrote the code. No customer data went into a model; the controls belong between generated code and production.

PDPC named the likely causes: pre-deployment testing that was not thorough enough, reliance on "a single employee without a review process for supervisory checks," and no "governance framework or policies in place to guide employees on the use of generative AI tools for work."

What is a voluntary undertaking, and why was there no fine?

A voluntary undertaking is a written remediation commitment PDPC can accept under section 48L of the PDPA instead of running a full investigation. PDPC's Guide on Active Enforcement (revised 1 October 2022) says PDPC may accept one when it "achieves a similar or better enforcement outcome more effectively and efficiently than a full investigation," that executing it "does not amount to an admission of breach of the PDPA," and that PDPC publishes it.

Two details in that guide matter to an SME. The request "must be made soon after the incident is known" and "must be accompanied with a remediation plan", with no extra time to write one. And the guide looks for accountable practices already in place, citing IMDA's Data Protection Trustmark as an example, so the route available after an incident depends on what you built before it. PDPC is unlikely to accept an undertaking for a repeat incident, a wilful or egregious breach, or an organisation that refutes responsibility.

It is not a free pass. PDPC "will verify the Organisation's compliance," and unmet terms can bring directions or a full investigation that could end in a penalty.

Do not read the statutory maximum as the price Bee Cheng Hiang escaped. According to the same guide, section 48J allows a penalty of up to S$1 million, or 10% of annual Singapore turnover where that turnover exceeds S$10 million, whichever is higher. Below S$10 million in Singapore turnover, the ceiling per the guide is S$1 million. PDPC also says it first considers "whether directions without financial penalties are effective in remedying the breach."

Notification runs on its own clock. A breach affecting 500 or more people is of "significant scale" under regulation 4 of the Notification of Data Breaches Regulations 2021, and PDPA section 26D requires notifying PDPC no later than 3 calendar days after the organisation assesses a breach as notifiable. The clock starts at that assessment, so name who makes it. At 95,364 people, headcount alone clears the threshold.

Which of the five undertaking measures would have stopped the bug?

Only an automated block in the sending path stops this bug whoever wrote or reviewed the code; a test send read by a person would also have caught it. Bee Cheng Hiang's undertaking, executed on 2 September 2026, lists five measures (the page says "including"). They bind one company, but they were shaped around a real failure, which makes them a practical starting list.

The table ranks each measure by whether it would have stopped this bug (our judgement, not a PDPC finding) and by effort.

Review and test sends are human gates: they work when a person is careful on the day. Measure (d) is structural. It stops this class of bug even when the author is rushed and the reviewer skims, which is how most SME releases happen. If you can fund one control this quarter, fund the one that does not depend on attention.

Treat any script that reads your customer list and sends outside the company as a software release, whoever wrote it.

What the automated check should do

Our recommended version takes one developer about a day:

• Count the addresses in every recipient entry before sending. More than one external address: refuse the whole batch and alert a named owner.
• Add a dry-run mode that writes the exact payload for three test recipients to a file the reviewer reads. This bug was visible in the payload, never in the prompt.
• Seed every live batch with one internal "canary" inbox that someone watches.
• Send the first live batch small, around 20 recipients, and pause until someone opens the canary. Here, that would have stopped the failure after one batch instead of roughly 96.
• Log which script version ran and who approved it.

Measure (a) cites the AI Verify Testing Framework, launched by IMDA and PDPC on 25 May 2022, which tests AI systems against 11 governance principles. For a small firm, what matters here is a named approver and testing that proves the outcome.

Illustrative example: a 40-person retailer has 20,000 loyalty members and one marketing executive who now asks an AI tool for small scripts. A second technical reader costs about 30 minutes per script. A test send to five internal inboxes costs about 10 minutes. The pre-send check above costs about a day of a developer's time, once. The decision: build the check first, because it protects every future script; make the test send mandatory second; add the review rule third. The numbers are made up. The ordering logic is the point.

What did PDPC's 30 September advisory add for everyone else?

PDPC's 30 September 2026 advisory turns the Bee Cheng Hiang failure into recommendations for every organisation, tied to the section 24 duty to make reasonable security arrangements. The Advisory for Data Protection Risks When Using Unauthorised AI Tools for the Development of Software or Scripts groups its measures under three concerns: shadow AI, no human in the loop, and inadequate testing.

Its illustration is a Company A employee who builds an email workflow with a public AI tool on a personal account, deploys it "without conducting any testing, human review, or approval," and sends bulk email through the "TO:" field. PDPC says the result constitutes "a potential breach of the organisation's obligations under the PDPA."

The advisory is guidance. It does not amend section 24. What it adds is a dated, public description of this failure on PDPC's website, nine days after the undertaking page and ten weeks after PDPC's Advisory Guidelines on Use of Personal Data in Generative AI of 20 July 2026. Our reading: an organisation with the same gaps after 30 September 2026 will find it harder to argue that nobody had described the risk. That is not the same as showing any one missing control was unreasonable.

Four recommendations go further than the undertaking for small firms:

• An inventory of AI tools kept alongside the ICT asset list, recording each tool's purpose, data flows and intended users. That is PDPC's first answer to shadow AI.
• Review of AI-generated code, scripts and workflows "by technically competent personnel before deployment." A manager approving a script they cannot read does not meet that.
• Logging inputs and outputs to AI tools.
• No production personal data in test environments, with synthetic data instead.

The advisory also reaches a risk this case did not involve: staff pasting a customer export, an API key or a database password into a personal AI account to debug a script. Nothing on your side records it. An inventory and a company-account rule make it visible.

How should a small firm split the responsibilities?

In a small firm the failure point is one person who can prompt the tool, read the logs and press send, so split those acts before you write a policy. The person who opens the test inbox should not be the person who wrote the prompt.

The owner or MD decides that AI-written scripts touching customers count as releases, and names who signs them off.

The CTO or technical lead owns the automated send check, the test-inbox rule and a short list of what counts as "touching personal data", without which nobody knows which scripts need review.

Whoever acts as data protection officer owns the breach procedure: who stops the sending gateway, and who makes the notifiability assessment that starts the 3-day clock. Bee Cheng Hiang's two-person check came after the send. Yours should exist before the next campaign.

Where Origin Pi stands

We read this case as an early signal that, in Singapore, AI-generated code is treated as the organisation's code from the moment it runs. PDPC did not blame the tool. It asked who reviewed the script, how it was tested and what policy governed it, and we apply the same questions to the automations we build.

When we design automations that contact customers or read customer records, we put the checks in the sending path itself: bounded permissions on what a script or agent may send and to whom, a confirm step before anything leaves at volume, and an audit trail showing which version ran, who approved it and what it actually sent. We design so that nobody has to notice on the day.

See our PDPA liability analysis for who pays when automation goes wrong, and our note on PDPC's July guidance on personal data in generative AI. Our AI governance work starts from the same release-path view.

Before your next bulk send, add the recipient-count refusal to the sending path and send the first run to five internal inboxes. Then read what arrived.