TL;DR: The PDPA (Singapore's Personal Data Protection Act) treats AI like any other way of handling customer data: your company is responsible for personal data staff put into AI tools, and for anything they build with AI that uses it. Two rules cover most of the risk:
- Keep personal data out of free, personal AI accounts.
- Don't let anything built with AI email customers or change their records until a second person has checked and tested it.
The second rule comes from an advisory the PDPC (Personal Data Protection Commission, which enforces the Act) published on 30 September 2026, explained in full below, with five questions you can ask your team.
Most small companies now use AI somewhere, often without a decision from anyone. It touches personal data in two ways: what staff type into AI tools, and what they build with them, such as a script that sends emails, a spreadsheet macro or an automation that updates customer records. This guide covers both. The section on what staff type in is short, because our earlier post covers it in detail. The section on what staff build is longer, because the PDPC has just published new guidance on it.
What staff type into AI tools
- The plan matters more than the brand. Business plans from OpenAI, Anthropic and Microsoft say they don't train their AI on your data. Free and personal versions have different terms. Keep work in company accounts.
- Sort data into three piles. Public material can go in anywhere. Internal material belongs in a company account. Customer or staff personal data needs approval first.
- Personal data sent overseas needs the same protection. Many AI tools process data outside Singapore, and the PDPA requires comparable protection wherever it goes. Business plans come with a data-protection agreement with your company. Personal accounts don't.
- Give staff a written rule. Our earlier post has a one-page rule sheet you can download and fill in.
What staff build with AI: the PDPC's new advisory
This is the newer risk, and it's easy to miss because the person doing it is usually trying to help. The PDPC's advisory opens with an example. It describes an employee at "Company A" who wanted to speed up customer emails. They used a public AI tool, on their own personal account, to write a small program that sent emails automatically. They ran it on the real customer list straight away. Nobody tested or looked at it, and IT didn't know it existed.
The program put every customer's email address in the "To" line of one email, resulting in all the email addresses becoming visible. The PDPC calls this an unauthorised disclosure of customers' personal data, and a potential breach of the company's obligations under the PDPA.
Notice what went wrong. Nobody was hacked, and the AI didn't leak anything. It wrote a program that did roughly what was asked, with one mistake that any careful person would have caught in a test run sent to the team first. The issue was that nobody checked before it went out.
Why the company is responsible, not the employee
The PDPA makes your company responsible for protecting the personal data it holds, whoever touches it. The advisory points to Section 24 of the PDPA, which requires organisations to make "reasonable security arrangements" to protect personal data in their possession or under their control. A program built by a well-meaning employee on a personal account is still your company handling your customers' data.
The PDPC doesn't tell companies to ban AI tools, instead it asks them to put some process around what gets built.
What the PDPC expects, in plain words
The advisory names three problems and lists fixes for each. Some of the fixes, such as penetration testing and load testing, are written for companies with an IT department. Here is what each one means for a small business.
1. Tools nobody knows about
The PDPC calls this "Shadow AI": AI tools staff start using without the company knowing, which may send personal data to outside services nobody has checked.
What it asks for: a regularly reviewed list of the AI tools in use, with what each is for, what data goes through it and who uses it. Written rules about personal data in AI tools. And access kept to the people who need it.
For a small company: keep one list of AI tools and of anything staff have built with them that touches customer or staff data. Our checklist for IT has a tool inventory you can start from. Add a row for each home-built script or automation.
2. Nobody checking the AI's work
The PDPC warns against "excessive trust" in what AI produces. It says code, scripts and automations written by AI must be reviewed and checked by someone technically competent before they are used.
What it asks for: train staff on what data can go into AI tools and how it flows through them. Train anyone building with AI in safe coding habits. Keep a record of what goes into and comes out of AI tools, so mistakes can be traced.
For a small company: one rule does most of the work. Nothing built with AI is allowed to email customers, change customer records or share files outside the company until a second person has checked it. If nobody in the company can read code, ask an external developer to check it.
3. Not testing before real use
AI-written code can contain mistakes that aren't obvious until it runs. The PDPC says any system handling personal data should be reviewed and tested before it goes live, again after changes, and from time to time after that.
What it asks for: proper testing at each stage, and security testing before launch for systems that need it. Write down how each tool is set up. And don't test with real personal data. Use made-up data instead (the PDPC calls this synthetic data).
For a small company: try it on a made-up list first, then send it to your own team, and only then to customers. Never copy the real customer list into a test.
Five questions to ask about anything staff have built
You don't need to read the code to ask these. If the person who built it can't answer one, that's where the risk is.
- What customer or staff data does it read? Names, emails, phone numbers, NRIC numbers, payment details.
- Who does it send things to, and how? For emails: does each person get their own email, or do they see each other's addresses? If it's one email, the addresses belong in "BCC", not "To" or "CC". A proper mailing tool sends one email per person.
- Has it been tried on made-up data and on our own team first? Ask to see the test.
- Whose account does it run on? If it's a personal account, a free tool or someone's own laptop, move it to a company account or stop using it.
- Who looks after it if it breaks, or if the person who built it leaves? A program only one person understands can stop working at any time, and nobody else will know how to fix it.
Your options
As with AI use generally, there are three levels of control. Most small companies should pick the middle one.
- Light. Ask staff to tell you about anything they have built with AI that touches customer or staff data, and go through the five questions together. It costs an afternoon.
- Middle. Do the light step, then add the rule: nothing built with AI emails customers, changes their records or shares files outside the company until a second person has checked it and it has been tested on made-up data. Add each tool to your AI tool list with an owner's name.
- Strict. Only IT, or an external developer you have hired, can build anything that touches personal data. Staff can use AI to draft ideas, but the working version goes through normal review and testing. This suits companies handling health, financial or children's data, or ones whose clients have asked for it in writing.
Some of what staff build will turn out to be something the business now relies on every day. That's a good sign: someone found a real problem worth solving. It's also the point to stop treating it as a side project and have it built properly, with testing, a company account and someone responsible for it.
What we don't know
- The advisory is guidance, not a new law. It explains how the PDPC sees an existing duty under Section 24. It doesn't say what penalty a case like Company A's would get.
- "Technically competent" isn't defined. The advisory doesn't say how much review is enough for a small script. The suggestion of a second person, or an external developer for small companies, is our recommendation, not the PDPC's.
- We haven't covered every kind of tool. The advisory is about software and scripts. Spreadsheet macros and no-code automation tools such as Zapier or Power Automate aren't named, but the same reasoning appears to apply to anything that handles personal data automatically.
- This is not legal advice. If something has already gone out to the wrong people, speak to a lawyer, and remember that a reportable breach must reach the PDPC within 3 calendar days of deciding that it is reportable.
Related reading: Is It Safe to Put Company Data Into AI Tools? covers what staff can type in, with a one-page rule sheet. How to Prevent AI Tools From Exposing Company Data is a checklist for IT, including the tool inventory.