By KYN AI Advisory Team — AI implementation specialists, Singapore
The Personal Data Protection Act (PDPA) applies to an AI system the same way it applies to any other system that handles personal data. If your AI reads customer emails, sorts enquiries or drafts messages, you remain responsible for that data, whether you or a vendor runs the software. Six practical duties follow: know why you hold the data, have a basis to use it, limit who and what can see it, control your vendors, delete it when you no longer need it, and be ready to report a breach.
This is a working checklist, not legal advice. For anything contested, ask a lawyer or your Data Protection Officer. The Personal Data Protection Commission (PDPC) publishes the PDPA overview and its guidance on its own site. We could not retrieve the statute text in full while writing this, so we state obligations at the level the PDPC describes and avoid quoting section numbers or penalty figures.
Does the PDPA apply when an AI reads the data?
Yes. The law is concerned with what happens to personal data, not with the technology. If an AI agent reads an email that contains a name, a phone number or an NRIC number, that is processing personal data. Your obligations are the same as if a staff member read it.
Two things change in practice.
Scale. A person reads a few hundred messages a week. An agent can read thousands. A mistake in access or retention repeats at that scale.
Visibility. A person can explain what they did. An agent needs a log that does. If you cannot show what the agent read and did, you cannot answer a customer who asks.
What are the six duties for an AI system?
Duty 1: Know the purpose
Write down why each type of personal data is in the system. "To sort inbound enquiries and route them to the right salesperson" is a purpose. "To train AI" is not specific enough on its own.
If the system does something new with the data later, such as using enquiry text to build a marketing list, check the purpose first.
Duty 2: Have a basis to use the data
The PDPA works mainly on consent, with defined exceptions. The PDPC has published advisory guidelines on using personal data in AI recommendation and decision systems. Law-firm summaries we read describe them as non-binding, aimed at systems that make recommendations, predictions or decisions, and as covering when exceptions such as business improvement may apply. We could not open the PDPC's final text, so read it directly before relying on an exception.
For an SME using customer enquiries to run a reply desk, the usual position is simple: the customer gave their details to get a response, and the system helps you respond. Document that reasoning.
Duty 3: Limit who and what can see the data
This is the duty where design matters most.
- Named accounts. No shared logins. Every person has an account, and every action is tied to it.
- Row-level security. The database itself decides which rows a user or agent can read. This is stronger than hiding data in the screen.
- Restricted agent accounts. An agent gets its own account with the minimum permissions it needs. It does not borrow an administrator's.
- Minimum data to the model. Send the AI the fields it needs, not the whole record. A reply sorter does not need the customer's address.
See multi-tenant database security for what to ask your developer.
Duty 4: Control your vendors
An AI vendor, a cloud provider and a model provider each handle your data in some way. For each, find out:
- where the data is stored and processed;
- whether the model provider keeps or trains on your inputs;
- who at the vendor can see it;
- what happens to it when you stop.
Put the answers in a contract. The questions in what to ask an AI vendor about security apply here. A system in a cloud account in your own name makes this easier, because the data sits under your control and you can revoke the vendor's access.
Duty 5: Retain only as long as you need
Decide a retention period per data type and build deletion in. An agent log that keeps full email bodies forever is a data store you did not plan. Log the action, the actor and the time. Keep the content only where you need it, and for a stated period.
Deletion is itself a risky action. In our systems, deletions wait for a named person.
Duty 6: Be ready to report a breach
The PDPC's data breach reporting page refers to a three-day deadline for notifying the PDPC. The page does not set out when the three days start or how a notifiable breach is defined, and we did not retrieve the guide it links to. Read the PDPC's guide on managing and notifying data breaches and write your procedure from that.
What you can prepare now:
- a named person who decides whether an incident is a breach;
- a log that lets you see what was accessed and by which account;
- a contact list for your vendors, so you can ask them what happened quickly;
- a template for the notice.
An audit log with the actor on every action is what makes a breach assessment fast. Without it, the first days go to finding out what happened.
What about customer rights over AI decisions?
Customers can ask what personal data you hold about them and ask for correction. Your system must be able to find that data. If it sits across email, a CRM, a spreadsheet and an agent's working memory, finding it is slow.
Design for retrieval from the start: one record per person, with links to every place their data was used. This is a data design task, not an AI task.
If an AI system influences a decision that affects a customer, such as declining an enquiry or setting a priority, keep a human responsible for the outcome. Let a person review any decision that materially affects someone. See approval placement in AI workflows.
What about marketing messages?
Sending is separate from storing. Messages to Singapore numbers and emails have their own rules, including the Do Not Call Registry and the Spam Control Act. An AI agent that drafts outreach must check a suppression list before any send, and a person approves messages to new contacts. We cover the limits in what an AI sales agent can and cannot do.
What if you serve customers in Hong Kong, Indonesia or Malaysia?
Each has its own regime, and the PDPA does not cover them. Check the rule for the country where the customer lives. Build per-country settings into the system, since consent wording, retention and notice rules differ.
Where KYN fits
KYN builds systems that run in a cloud account in the client's name. Named accounts use the cloud provider's identity service, with no shared logins. The database uses row-level security, each user gets one restricted account per session, and agents have their own restricted accounts. Every action is logged with the actor. Outbound messages, money, filings and deletions wait for a named person.
The first 14 days are a review of your stack and interviews with your team, which is when we map where personal data lives. A full build ships in under 90 days. See security and infrastructure.
Frequently asked questions
Do I need a Data Protection Officer to use an AI system?
The PDPA requires organisations to designate someone responsible for data protection, regardless of whether they use AI. Confirm the current requirement on the PDPC site. The person should know where the AI system sits in your data map.
Can I paste customer data into a public AI chat tool?
Avoid it. You lose control over where the data goes and how long it is kept. Use a tool or system under a contract that states retention and training terms, and send only the fields needed.
Who is responsible if a vendor's AI leaks my customers' data?
You remain responsible to your customers for the data you collected, and the vendor has duties as well. Allocate responsibility in the contract and confirm that the vendor must tell you quickly about an incident.
Checked 30 October 2026.
Curious whether Marketing agents fits your business? Talk to KYN on WhatsApp — no forms, just a conversation.
