The AI Wrote the Script. Who Checked What It Sent?

The AI Wrote the Script. Who Checked What It Sent?

Someone on your team needs to send a campaign to your member list. The AI tool they already use can write the script for them. They run a test, and the email goes out.

Then you find out every recipient could see everyone else's email address.

That's the outline of a case PDPC published in September, involving Bee Cheng Hiang Marketing.

What happened

On 25 April 2026, the company sent a marketing email to its members in batches of 1,000. The script was supposed to send one email per person. Instead, it sent one email to each batch, with all 1,000 addresses sitting in the "To" field. In total, 95,364 members were affected, and each address was visible to up to 999 other people. Only email addresses were involved. The company notified PDPC on 27 April.

The cause was a single missing bracket in a Python script. An employee had developed it through the personal use of a generative AI tool, and the undertaking describes it as the company's first attempt at using AI in its business.

PDPC was clear that this was not a malfunction in the AI tool. The employee asked for a programme to send a "mass email using a local list" in batches. They didn't ask it to keep recipients hidden from each other. The result came from the prompt, not from a fault in the tool.

The test that checked the wrong thing

The employee did test the script. But the test meant checking the activity logs, not opening the test email.

A log tells you the email went out. It doesn't tell you what the person receiving it can see.

Why this keeps happening

The failure was ordinary. One employee was given a task, an AI tool made it quick, and nobody else looked at the result. It's the same pattern as the Marina Bay Sands migration we wrote about last week: one person, one unchecked step.

AI makes that pattern easier to fall into. When a tool hands you working code in minutes, a second pair of eyes feels like a delay. And people tend to test whether something ran, not what it does to the people on the other end.

PDPC's view, set out in the undertaking, is that the incident likely occurred because the company:

• didn't do sufficiently thorough pre-deployment testing
• relied on a single employee, with no supervisory review of the work
• had no governance framework or policies guiding employees on using generative AI for work

One more detail is worth a pause. The undertaking says the script came from the employee's "personal use" of an AI tool. PDPC doesn't expand on that. But it's a fair question for any business: do you know which AI tools your team are using for work today?

What this is, and isn't

PDPC accepted a voluntary undertaking from the company, executed on 2 September 2026. It is not a financial penalty, and it isn't a finding of breach. The text doesn't name a specific PDPA obligation either.

PDPC did add a general message: before adopting AI tools, carry out appropriate data protection impact assessments, develop policies and processes, and put testing and review mechanisms in place.

What PDPC's generative AI guidelines add

On 20 July 2026, PDPC issued its Advisory Guidelines on Use of Personal Data in Generative AI. They're advisory, not legally binding, and the PDPA prevails over them. The undertaking doesn't refer to them, and most of the Guidelines deal with personal data going into and through AI systems, not AI-written code.

Section 9 is the part for ordinary businesses. It's aimed at organisations that use generative AI systems, which PDPC calls system deployers, and it lines up closely with what was missing here. In short, it says:

• You carry the primary responsibility for making sure the AI system you choose can meet your PDPA obligations.
• You should track the new data flowing through these systems, assign responsibility for it, and tell staff what personal data may be put in.
• PDPC encourages clear written policies and documented processes.
• You should review your safeguards regularly, especially if the tools can act on their own across several steps.

What I'd put in place

This list is my professional view. It draws on what Bee Cheng Hiang committed to in its undertaking, but none of it is a PDPC rule.

• Test with dummy recipients. Send the real email to test accounts first, and have someone open it as the recipient would.
• Have a second person review AI-generated work that touches personal data before it runs. The company committed to independent review of AI-generated code, and to two-person checks on bulk emails.
• Write down which AI tools staff can use for work, and what personal data may and may not go into them.
• Name an owner for your bulk email process, and for each system that holds customer or member data.
• Ask whoever manages your email platform whether it can block a bulk send that puts several recipients in one message. The company committed to building that control.

If you only take one rule from this, make it this one: AI can write it, but a person still has to check what the customer receives.

A small case with a clear lesson

This was email addresses only, and it ended in an undertaking, not a penalty. That's what makes it useful. It shows how little it takes: one prompt, one missing bracket, one test that looked at the wrong thing.

If you're unsure where AI use currently sits in your team, or who signs off on bulk sends and system changes, that's the kind of ownership gap we help businesses close at Veritos. The aim is to turn "someone should check this" into a task that's visible, owned and doesn't quietly slip.