Picture a normal working day in a marketing team. There is a promotional email to send to a very large mailing list, so someone asks an AI tool to write a script that sends it out in batches. The script runs, the test looks fine, and the campaign goes out. That is more or less how Singapore ended up with what the Personal Data Protection Commission (PDPC) describes as its first AI data breach, and the company involved is Bee Cheng Hiang, a name many of us associate with bak kwa at Chinese New Year.
I have been reading up on it since the Straits Times reported the story on last week, and it sits right where marketing and AI governance overlap, which happens to be where I spend a good deal of my time.
What actually happened
The Bee Cheng Hiang AI data breach came down to a single mass email sent in April. According to Mothership’s report on the PDPC’s findings, an employee in the marketing team used a generative AI tool to build a Python script for the send, and 95,364 members ended up with their email addresses exposed. The emails went out in batches of 1,000, the Straits Times reported, and everyone in a batch could see everyone else’s address. Only email addresses were affected, and the PDPC said there was no evidence they were misused afterwards.
The emails went out on 25 April and the company told the PDPC two days later. The PDPC accepted a voluntary undertaking from the company on 2 September, published the details on 21 September, and the story reached the news on 30 September. A mistake made in a single send took more than four months to reach an agreed undertaking with the regulator, which is something to remember when we get to the cost of checking.
The AI did what it was asked
It is tempting to look at this AI data breach and blame the tool. The PDPC’s findings point somewhere else. It said the breach did not come from a malfunction in the AI tool, and that the prompt given to it had no specific instruction to keep each recipient’s address hidden from the others. The tool wrote the script it was asked to write, and the instructions left a gap.
According to the Straits Times, the visible difference between the correct code and the faulty code came down to the placement of a couple of brackets. That is a small thing to get wrong and an easy thing to miss, especially when AI-generated code arrives looking polished and runs without complaint. It also helps to remember that this was the first time Bee Cheng Hiang had attempted to bring AI tools into its business operations. Anyone who has briefed a new colleague knows how easily the most obvious instruction goes unsaid.
Why this AI data breach is a governance story
The PDPC then looked at everything around the script. It said Bee Cheng Hiang did not test the script robustly enough before it went live, had no review process for supervisory checks of the employee’s work, and had no governance framework or policies to guide staff on using generative AI at work.
Nothing on that list is exotic. Every gap behind this AI data breach could have been closed with a rule on paper, and I find that oddly reassuring. Governance has a reputation for being something banks and technology giants do, with committees and acronyms attached. At this scale it is closer to one page that says who checks what before anything reaches a customer.
AI has also made it possible for people in marketing to produce working code without ever learning to read it. That is useful, and it means the person asking for the script may be the person least equipped to spot what is wrong with it. A script that touches a mailing list of this size is a data protection task whichever department asked for it, so the checking has to be built into the process and cannot depend on one person’s instinct.
The test that checked the wrong thing
What intrigued me about the story is how the script was tested. The Straits Times reported that the check involved looking at activity logs, without anyone reviewing the content of the actual test email. The logs could confirm that emails had been sent. Only the email itself could show what a recipient would see, and one glance at the To field would have given the game away.
Marketing teams are good at reviewing the message. Subject lines get debated, copy goes through a couple of rounds, and the creative gets signed off. The machinery that delivers it, whether that is a platform, a plug-in or a script someone asked an AI tool to write, tends to get a glance at best. In my experience that gap was there long before AI arrived, and an AI data breach like this one simply makes it visible.
I wrote recently about red teaming and testing before deployment after Singapore’s speech at the UN, and this is the same instinct at its smallest possible scale. Open the test email, read it the way the customer would, and try to break it before someone else does.
Why this is a brand trust story as well
A mailing list is a collection of small acts of trust. Each of those 95,364 members handed over an email address to hear from a brand they chose, and under the PDPA that handover is an agreement, since organisations generally need consent to collect personal data and are expected to protect it once they have it. Brand equity gets built one reliable experience at a time, and an email that shows a thousand strangers your address is a fairly efficient way of spending some of it.
The part that stings for a marketer is that the breach arrived inside the brand’s own marketing. The email that was meant to deepen the relationship was the one that exposed it. A customer caught up in an AI data breach is unlikely to wonder whether a person or a program wrote the code. They see a company that was careless with their details, and the name that gets attached to the mistake is the company’s.
The PDPC found no evidence that the addresses were misused, which is a relief. A customer has no way of checking that for themselves, though, and has to take the company’s word for it, which is a fair description of what brand trust amounts to.
In fairness to Bee Cheng Hiang, the PDPC said the company took prompt remedial action once it found the error. It halted the send, rectified the script and told the affected customers, and it now requires at least two employees to verify every bulk email before it goes out. Under the undertaking it will also set up a framework governing how employees use AI for coding, which AsiaOne reported includes independent technical reviews of AI-generated code that involves personal data. That is a sensible response to a first AI data breach, and a useful template for everyone who has not had theirs yet.
What I would do before the next send
My advice is to treat anything AI builds for you as needing a second reader the moment it touches customer data. Four habits would have given this error several chances to be caught. Open the test email and read it as the recipient would, rather than trusting a log. Ask a second person to check any bulk send, which is exactly what Bee Cheng Hiang does now.
The other two are a little more formal. Write a one-page AI policy that covers what staff may ask AI to build, what data they may paste into it, and who signs off before anything reaches customers. And before adopting any new AI tool, run a data protection impact assessment, which the PDPC recommends and explains in its own guide. That sits close to the PDPC’s wider advice to develop policies and processes for AI use and to put testing and review mechanisms in place.
None of this slows a team down much. A second reader on a bulk send adds a few minutes, whereas this one mistake took from 25 April to 2 September to reach an undertaking with the regulator and has since become a news story with the company’s name on it. Any team using AI to build small tools is one forgotten instruction away from its own AI data breach, and the cheapest moment to find the gap is before the send button.
So who checks the work in your team when AI writes the script, and does that person know it is their job? If the answer is no one, what would it take to change that this week?
