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

Deep-green and parchment mathematical-line illustration showing a single accountability line running from a customer node through an AI agent node to a deploying organisation node, with a vendor node branched off to one side carrying a thinner line labelled security and breach notification, conveying that liability tracks the deployer not the model builder.

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.

01

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.

02

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.

03

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.

04

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.

05

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.

06

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.

Questions

Common questions.

Who is liable when an AI agent mishandles personal data under Singapore's PDPA?
The organisation that deployed the AI agent at its customer is liable, not the vendor who built or hosts the model. PDPA section 4(3) gives the deploying organisation the same obligation as if it had processed the data itself, while section 4(2) limits the vendor's duties as a data intermediary to security, retention, and breach notification.
Does using a third-party AI model transfer PDPA accountability to the vendor?
No. Outsourcing processing does not transfer accountability. Under PDPA section 4(3), the deploying organisation retains the same obligation as if it processed the data itself. A vendor SLA can shift commercial risk between companies by contract, but it cannot move the statutory obligation off the organisation the regulator holds to account.
What obligations does an AI vendor actually carry as a data intermediary?
Under PDPA section 4(2), a data intermediary processing personal data on behalf of another organisation under a written contract carries only the Protection Obligation (section 24), the Retention Limitation Obligation (section 25), and the data-breach notification duties (sections 26C(3)(a) and 26E). Consent, notification, accuracy, and overall accountability stay with the deploying organisation.
What does the Marina Bay Sands decision tell deployers about AI liability?
On 28 October 2025 the PDPC fined Marina Bay Sands Pte Ltd S$315,000 for breaching the Protection Obligation after the data of 665,495 patrons was exposed in a 2023 software migration. The penalty landed on the organisation holding the customer relationship. The same logic applies when the failing component is an autonomous agent rather than a migration process.
How fast must a PDPA data breach be reported if an AI agent causes it?
A data intermediary must notify the organisation it serves without undue delay on discovering a breach. The organisation then assesses notifiability, and the PDPC must be notified no later than 3 calendar days after the breach is assessed as notifiable. A breach is notifiable if it is likely to cause significant harm or affects 500 or more individuals.
What is the maximum financial penalty for a PDPA breach in Singapore?
The maximum 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. For organisations with material Singapore revenue, the 10% figure is typically the larger and more consequential ceiling.
Next

Work with Origin Pi.

Building the agent-ready layer for your business? Send a note. Real reply, no funnel.