AI governance
The PDPA Liability Gap: Who Pays When Your AI Agent Gets It Wrong
Under Singapore's PDPA, the organisation that deployed the AI agent at its customer carries the accountability, not the vendor who built or hosts the model. The gap is in your assumptions, not the law.
By Siddharth Surana, Founder & CEO / / 7 min read
Under Singapore's Personal Data Protection Act, the organisation that deployed the AI agent at its customer is liable when that agent mishandles personal data. Not the vendor who built or hosts the model. This is the inversion most operators get wrong. The intuitive assumption runs the other way: if a third-party model makes the mistake, the model builder pays. The PDPA holds the opposite. Section 4(3) gives the deploying organisation "the same obligation under this Act ... as if the personal data were processed by the organisation itself", while section 4(2) relieves the vendor, acting as a data intermediary, of nearly every obligation except data security, retention limits, and breach notification (PDPA s4). So the "liability gap" is really a liability illusion. There is no gap on the regulator's side. The full weight sits on the deployer, and the only gap is in the deployer's own expectations.
The single accountability model, in plain statute
The PDPA does not split responsibility the way many operators expect. Section 4(3) is explicit. An organisation has the same obligation under the Act for personal data processed on its behalf and for its purposes by a data intermediary, "as if the personal data were processed by the organisation itself" (PDPA s4). Outsourcing the processing does not outsource the accountability. The duty stays with whoever holds the customer relationship.
The counterpart provision, section 4(2), is what creates the false sense of safety. A data intermediary processing personal data on behalf of another organisation under a written contract carries no obligation under the Act, except for the Protection Obligation under section 24, the Retention Limitation Obligation under section 25, and the data-breach notification duties under sections 26C(3)(a) and 26E (PDPA s4). Read the two sections together and the picture is unambiguous. The vendor owes you security, retention discipline, and a breach alert. Everything else stays with you: consent, notification, accuracy, purpose, and the overarching duty to protect. This single-accountability reading is consistent with the statute, but it is offered here as analysis, not as a direct quotation of the regulator.
Where the AI developer ends and the deployer begins
The line matters most when a third-party AI provider is in the loop. The PDPC's Advisory Guidelines on Use of Personal Data in AI Recommendation and Decision Systems, published on 1 March 2024, separate the AI developer, who works in the training and testing phase, from the deploying organisation, which works in the consumer-facing phase (PDPC Advisory Guidelines). A third-party AI provider can sit in the position of a data intermediary. The organisation putting the agent in front of customers carries the consent, notification, and accountability duties for that consumer-facing processing.
For an AI agent acting on live customer data, this is the operative reading. The model builder's exposure is bounded by the data-intermediary rules. The business deploying the agent answers for whether the agent had a lawful basis to use the data, whether the customer was told, and whether the outcome can be defended. A vendor SLA can shift commercial risk between two companies by contract. It cannot move the statutory obligation off the organisation the regulator will hold to account.
Marina Bay Sands: the accountable party is the organisation
The most recent enforcement signal makes the principle concrete. On 28 October 2025 the PDPC imposed a financial penalty of S$315,000 on Marina Bay Sands Pte Ltd for breach of the Protection Obligation under section 24, after the personal data of 665,495 patrons was exposed during a 2023 software migration and later surfaced on the dark web (PDPC Enforcement Decision). The penalty landed on the organisation that held the customer relationship.
The lesson generalises past this one case. When a failure happens inside a technical process, the accountable party is still the organisation whose customers were affected, not the layer of the stack where the fault sat. The logic that placed accountability on the organisation in a software migration places it on the organisation when the failing component is an autonomous agent. The customer relationship is the anchor for liability, and that anchor does not move because the failure was technical or outsourced.
The financial weight behind the obligation
The reason this matters is the size of the downside. The maximum PDPA financial penalty is the higher of S$1 million or 10% of the organisation's annual turnover in Singapore, with the turnover-based cap in effect since 1 October 2022 (CMS Legal Update). For any organisation with material Singapore revenue, the 10% figure is the one that bites.
The breach-notification regime sets the clock that exposure runs on. A data breach is notifiable if it is likely to result in significant harm to an affected individual, or if it is of significant scale, and the prescribed threshold for significant scale is 500 affected individuals (Notification of Data Breaches Regulations 2021). The sequence is tight. A data intermediary must notify the organisation it serves without undue delay on discovering a breach. The organisation then assesses notifiability. The PDPC must be notified no later than 3 calendar days after the breach is assessed as notifiable (PDPA s26C to s26D). An AI agent acting on personal data across a large volume of customer interactions can, in a single faulty run, affect enough individuals to cross the 500-individual line that makes a breach notifiable. The assessment and notification duties then fall on the deployer, not the vendor.
Why this is a structured-context problem
Singapore's broader governance posture points to where deployers should spend their effort. The Model AI Governance Framework for Generative AI, published by IMDA and the AI Verify Foundation, sets out nine dimensions, including accountability and incident reporting, as core mechanisms for responsible development and deployment (AI Verify Foundation). In 2025 Singapore advanced the supporting tooling: Singapore Standard SS 714:2025 for data protection, a Global AI Assurance Sandbox addressing risks such as data leakage and prompt injection, and a Privacy Enhancing Technologies adoption guide for generative AI use cases (Chambers Data Protection and Privacy 2026).
Accountability and incident reporting are not document exercises. They are evidentiary ones. When the regulator asks what data the agent touched, on what basis, and whether the customer was notified, the deployer needs answers that can be produced from records, not reconstructed from memory. An AI agent stays inside its PDPA obligations only if the business context it acts on is structured, governed, and auditable. If the agent draws on customer data the deployer cannot account for, the agent has already breached the deployer's duty, no matter who built the model. Accountability you cannot evidence is accountability you cannot defend.
Where Origin Pi fits
Origin Pi builds the agent-ready business layer: a governed business brain that keeps the context an AI agent acts on structured, machine-readable, and auditable, so accountability can be evidenced rather than assumed. That is the regulator's test, restated as an engineering requirement. Our AI governance work establishes the accountability and oversight structure for autonomous agents. Our AI compliance work maps that structure to the specific obligations, including the PDPA, that a deploying organisation carries. The agent-readiness case here is made by the statute, not by a vendor pitch.
Sources
- PDPA section 4(2) imposes no obligation on a data intermediary except the Protection Obligation (s24), the Retention Limitation Obligation (s25), and the data-breach notification duties under s26C(3)(a) and s26E.
- PDPC Advisory Guidelines on Use of Personal Data in AI Recommendation and Decision Systems (1 March 2024) distinguish the AI developer from the deploying organisation, which carries consent, notification, and accountability duties.
- A breach is notifiable if likely to cause significant harm or of significant scale; the prescribed threshold for significant scale is 500 affected individuals.
- A data intermediary must notify the organisation without undue delay, and the PDPC must be notified no later than 3 calendar days after the breach is assessed as notifiable.
- The maximum PDPA penalty is the higher of S$1 million or 10% of annual Singapore turnover, effective 1 October 2022.
- On 28 October 2025 the PDPC fined Marina Bay Sands Pte Ltd S$315,000 for breach of the Protection Obligation after the data of 665,495 patrons was exposed in a 2023 software migration.
- Singapore's Model AI Governance Framework for Generative AI (IMDA and AI Verify Foundation, 2024) sets out nine dimensions, including accountability and incident reporting.
- In 2025 Singapore advanced SS 714:2025 for data protection, a Global AI Assurance Sandbox addressing data leakage and prompt injection, and a PET adoption guide for generative AI.
Common questions.
Who is liable when an AI agent mishandles personal data under Singapore's PDPA?
Does using a third-party AI model transfer PDPA accountability to the vendor?
What obligations does an AI vendor actually carry as a data intermediary?
What does the Marina Bay Sands decision tell deployers about AI liability?
How fast must a PDPA data breach be reported if an AI agent causes it?
What is the maximum financial penalty for a PDPA breach in Singapore?
Where this connects.
Continue reading.
Work with Origin Pi.
Building the agent-ready layer for your business? Send a note. Real reply, no funnel.