AI Made the Code, But Humans Caused the Breach: What Singapore’s Bee Cheng Hiang Incident Teaches Businesses About AI Security

Artificial intelligence is quickly becoming part of everyday business operations. Companies are using AI to write emails, create marketing campaigns, analyze data, generate images, write software and automate repetitive tasks.
But a recent incident in Singapore shows that using AI at work can create a new kind of security risk.
More than 95,000 Bee Cheng Hiang customers had their email addresses accidentally exposed after an employee used a generative AI tool to help create code for a marketing email campaign. The incident was reported as Singapore's first AI-related data breach by the Personal Data Protection Commission (PDPC).
The important part is that the AI system itself did not malfunction.
The problem came from how a human instructed the AI, how the generated code was tested, and the lack of a proper review process.
This incident raises an important question for every company using AI: When AI writes part of your business process, who is responsible for checking what it actually does?
What Happened at Bee Cheng Hiang?
Bee Cheng Hiang, a Singapore-based food company known for its bak kwa products, used a generative AI tool to help an employee create code for sending marketing emails.
The employee wanted to send emails to customers in batches. However, the prompt given to the AI did not clearly instruct the generated program to keep each customer's email address hidden from other recipients.
The resulting code caused emails to be sent to groups of around 1,000 customers in a way that exposed the recipients' email addresses to one another. More than 95,000 customers were affected.
The emails were sent on April 25, 2026, and the company notified the PDPC two days later.
The exposed information was limited to customer email addresses. According to the PDPC, there was no evidence that the addresses were subsequently misused.
That detail is important because this was not a case where an AI model independently accessed a customer database and stole information.
Instead, AI was used as a coding assistant, and human decisions surrounding that code resulted in the exposure.
The AI Was Not “Hacked”
One of the biggest lessons from the incident is the difference between an AI failure and an AI-assisted human error.
The PDPC specifically clarified that the incident was not caused by a malfunction in the AI tool.
The employee asked the AI to generate code for mass email distribution. Because the instructions did not clearly specify that individual customer addresses needed to remain private, the generated code behaved incorrectly.
According to the PDPC, a small difference in the code, involving the placement of brackets, changed how the program worked.
This is a major issue for businesses adopting AI coding tools.
AI can generate code that looks professional and technically convincing. But code that looks correct is not necessarily code that is safe.
A developer or employee still needs to understand what the code does, test it properly and review its security implications.
Why AI Coding Creates a New Business Risk
Traditional software development normally involves multiple stages.
A developer writes code. Another developer may review it. The software is tested. Security teams may examine it. Then it is deployed.
AI can make this process much faster.
An employee can describe what they want in ordinary language and receive working code within seconds.
That speed is useful, but it can also remove some of the traditional safeguards.
An employee who does not fully understand programming may trust the AI-generated result because it works during a basic test.
This creates a dangerous assumption:
“If the AI generated it and the program runs, it must be correct.”
That assumption is not safe.
The Bee Cheng Hiang incident demonstrates why organizations need to treat AI-generated code like human-written code: it needs testing, review and security checks before it touches real customer data.
Testing the Code Was Not Enough
Another important lesson was the way the company tested the system.
The employee checked activity logs but did not review the actual content of the test email.
That meant the technical system appeared to be functioning, while the privacy problem remained unnoticed.
This is a common problem with automated systems.
A system can report:
“Email sent successfully.”
But that does not answer the more important question:
“Was the email sent correctly and safely?”
For a marketing system, testing should therefore involve dummy customer accounts and real-world scenarios.
A company should check exactly who receives the email, what information appears in the email, whether recipients can see other recipients and whether personal information is accidentally included.
The PDPC said Bee Cheng Hiang had not conducted sufficiently robust testing before deployment.
The Problem Was Bigger Than One Bad Prompt
It may be tempting to describe this incident as simply a case of someone writing a bad AI prompt.
But the deeper issue was organizational.
According to the PDPC, the company relied on a single employee without a supervisory review process. It also did not have a governance framework or policies explaining how employees should use generative AI at work.
That distinction matters.
If a company gives employees powerful AI tools but provides no rules about how those tools should be used, the company is effectively allowing employees to create their own AI workflows.
That can become particularly risky when the workflows involve customer information.
What Should Companies Do Differently?
The first step is to create clear rules around AI use.
Employees should know what information can be entered into AI systems and what information cannot.
Customer databases, passwords, financial information, private communications and other sensitive information should receive special protection.
Companies should also identify which AI tools are approved for business use.
The second step is human review.
AI-generated code should not automatically move into production simply because it works.
For systems involving personal data, organizations should consider independent technical reviews, particularly when employees without deep software expertise are using AI to generate or modify code.
The third step is realistic testing.
Instead of testing only whether a program runs, companies should test what the program actually does.
For example, before sending a bulk marketing email, a company could send it to several dummy accounts and verify that every recipient sees only their own information.
Bee Cheng Hiang has since introduced double-verification checks involving at least two employees for bulk email communications.
AI Governance Is Becoming a Business Requirement
The Bee Cheng Hiang case is part of a larger shift.
AI is moving from experimental technology into ordinary business processes.
Employees are using AI to write marketing copy, create software, analyze documents, produce images and automate customer communication.
Even seemingly simple activities can involve personal data.
For example, a marketing team might use AI to create a campaign and then connect that campaign to a customer database.
A designer might use AI to edit a product image and accidentally upload information contained in the original file.
Someone might use AI to remove background online from a product photograph while also uploading an image containing sensitive information in the background.
The technology itself may not be designed to cause harm. The risk comes from how people use it, what information they provide and what automated processes are connected to it.
That means AI governance cannot remain only an IT issue.
Marketing, sales, customer service, design and operations teams may all need AI-use policies.
The Singapore Incident Is a Warning for E-Commerce Too
E-commerce businesses should pay particular attention.
Online stores constantly handle customer information, including names, email addresses, shipping details and purchase histories.
At the same time, e-commerce teams increasingly use AI for product photography, marketing campaigns, email automation, customer support and content creation.
The more AI tools become connected to business systems, the more important access controls and testing become.
For example, an AI tool used to generate product content may be low risk when working with public product information.
The risk becomes different when it is connected to private customer databases.
Businesses need to understand that distinction.
AI adoption should not mean giving every tool access to everything.
What Bee Cheng Hiang Changed
Following the incident, Bee Cheng Hiang stopped the problematic email distribution, corrected the code and notified affected customers.
The company also agreed to strengthen its compliance with Singapore's Personal Data Protection Act.
Its follow-up measures include independent technical reviews of AI-generated code involving personal data, testing emails using dummy accounts, stronger software security reviews and employee data-protection training.
The company also plans to implement automated technical controls capable of blocking mass emails containing multiple addresses in a single email field.
These measures demonstrate an important principle:
Security should not depend entirely on an employee remembering to do the right thing.
Technology should provide additional protection.
The Bigger Lesson: AI Needs Human Oversight
The Bee Cheng Hiang incident does not show that businesses should stop using AI.
Instead, it shows why businesses need to use AI responsibly.
AI can dramatically reduce the time required to complete many tasks. It can help employees write code, create content and automate processes that previously required much more manual work.
But speed creates a new responsibility.
Before AI-generated work reaches customers, organizations need to ask:
What did the AI create?
What could go wrong?
Was it tested with realistic data?
Did another person review it?
Could personal information be exposed?
These questions are becoming just as important as the traditional questions around software security.
The Singapore case is especially useful because the incident was not caused by an advanced cyberattack or an autonomous AI system. It came from something much simpler: an employee using AI to write code without sufficient instructions, testing or review.
That makes the lesson relevant to almost every organization experimenting with AI.
The future of AI in business will not depend only on how powerful AI models become. It will also depend on whether companies build the right systems around them.
AI can write the code. Humans still need to check what that code is allowed to do.