Singapore PDPA AI Controls Mapping: Obligation, Owner, Test and Evidence

Singapore's Personal Data Protection Act 2012 applies through a set of data protection obligations rather than an AI-specific compliance schedule. On 1 March 2024, the Personal Data Protection Commission published guidance for AI recommendation and decision systems, connecting Consent, Notification and Accountability to AI development and deployment.

A controls mapping has to add six fields the Act leaves to implementation: objective, owner, control point, test, evidence and coverage. I am mapping those fields for an organisation deploying hosted AI over HTTP. Full means a control can be enforced on that path. Partial means the path supplies evidence or one component. Outside means another function owns the operative control.

Accountability: sections 11 and 12

Objective: assign responsibility and maintain policies and practices that give effect to the PDPA.

Owner: privacy, with executive approval.

Control: appoint a data protection officer, publish business contact details, approve each AI use before deployment, and maintain a role register covering the organisation, data intermediary, Model Provider, System Provider and System Deployer roles relevant to the service.

Test and evidence: choose one production system and produce its DPO escalation, signed assessment, role determination, policy version and approval date. The PDPC's Generative AI guidance emphasises that one entity may hold different roles in different contexts.

Coverage verdict: This control receives Partial coverage. Request records bind live activity to the approved policy version. Appointment, approval and policy publication stay with privacy.

Purpose Limitation: sections 18 and 20

Objective: keep collection, use and disclosure within a reasonable, stated purpose communicated before processing.

Owner: product and privacy define the purpose. AI platform engineering enforces destination scope.

Control: attach permitted data classes, user roles and model destinations to each approved purpose. Evaluate that rule on every request.

Test and evidence: use a support agent identity to send a synthetic customer record to the approved support model, then attempt the same request against an unapproved general-purpose endpoint. Keep the purpose register, permit record and denial record.

Coverage verdict: Full for destination enforcement on HTTP AI traffic. Purpose definition and the reasonable-person assessment remain Outside.

Notification and Consent: sections 13 and 20

Objective: provide meaningful information about the personal data and AI purpose, then record consent, deemed consent or a valid exception.

Owner: Product and privacy teams own this control.

Control: version the notice and consent surface. Where legitimate interests applies, document the adverse-effect assessment and the required disclosure. Link the approved notice or exception to the policy governing deployed traffic.

Test and evidence: start a synthetic customer flow and confirm the current notice appears before AI processing. Withdraw consent and verify the product route changes. Sample runtime destinations against providers described by that notice.

Coverage verdict: This control receives Partial coverage. Runtime evidence tests whether processing matched the notice. Notice design, consent capture and exception analysis occur off the request path.

Accuracy: section 23

Objective: keep personal data accurate and complete where it is likely to be used for a decision affecting an individual or disclosed to another organisation.

Owner: the business decision owner, with model risk and data governance.

Control: validate input quality, require human review for consequential outputs about identifiable people, restrict output use by decision type, and preserve the request and response for dispute handling.

Test and evidence: place a synthetic inaccurate fact in an AI-generated account summary, route it through the 10 August 2026 review procedure, and confirm the reviewer stops it before the customer record changes. Keep the evaluation, reviewer action and reconstructable request record.

Coverage verdict: This control receives Partial coverage. A gateway preserves and constrains traffic. Truth assessment and source correction remain Outside.

Protection: section 24

Objective: make reasonable security arrangements against unauthorised access, collection, use, disclosure, copying, modification, disposal or similar risks.

Owner: security engineering and AI platform engineering.

Control: classify personal data inside the request, minimise the payload, authorise the destination against the originating identity, fail closed on evaluator error, and write an independent decision record.

Test and evidence: send a known synthetic identifier to an unapproved endpoint, induce a policy timeout, and alter a service account's asserted user identity. Each test should produce a restrictive outcome and a record naming the rule applied.

Coverage verdict: Full for authenticated HTTP traffic crossing the AI request boundary. Storage security, endpoint protection and model development controls remain Outside.

Retention Limitation: section 25

Objective: stop retaining personal data, or remove association with an individual, after the original purpose and legal or business need end.

Owner: data governance and procurement.

Control: maintain a schedule for AI requests, responses and decision records, plus provider terms covering prompt retention. Automate disposal or de-identification and retain proof of execution.

Test and evidence: create a synthetic record with a short test period, run the disposal job, query each covered store and retain the result. Check the provider's retention setting against the contract.

Coverage verdict: This control receives Partial coverage. A gateway applies retention to its decision records. Enterprise stores and provider-held data require separate controls.

Transfer Limitation: section 26

Objective: ensure personal data transferred outside Singapore receives protection comparable to the PDPA.

Owner: legal and procurement establish the transfer mechanism. AI platform engineering enforces destination and region.

Control: map every overseas model endpoint to the selected route under Part 3 of the Personal Data Protection Regulations 2021. The PDPC's cross-border transfer guide includes contractual and certification resources. Apply a region allowlist per request.

Test and evidence: change an SDK base URL to a region absent from the approved map. Keep the agreement or certification, route map, blocked request and alert.

Coverage verdict: Full for route enforcement, Partial for the obligation as a whole. Legal adequacy stays with counsel.

Access and Correction: sections 21 and 22

Objective: let an individual access personal data and information about its use or disclosure, then correct qualifying errors and send corrections where required.

Owner: privacy operations and data governance.

Control: operate a rights workflow backed by searchable disclosure history. Route corrections to source systems and preserve the response decision.

Test and evidence: query a synthetic customer across a date range, list the AI providers that received their data, and correct an inaccurate source field. Keep the access export, destination history, correction ticket and downstream notification record.

Coverage verdict: This control receives Partial coverage. Per-request records supply disclosure history. Identity verification, exemptions, correction and response delivery stay with privacy.

Data Breach Notification: Part 6A

Objective: assess suspected breaches and notify the PDPC and affected individuals where statutory thresholds apply.

Owner: incident response with privacy and legal.

Control: query affected AI requests by time, identity, data class and destination; preserve containment actions; document the notifiability decision. Since 1 February 2021, notification to the PDPC is due as soon as practicable and within three calendar days after determining that a breach is notifiable.

Test and evidence: run a tabletop involving an agent sending personal data to an unapproved endpoint. Produce the affected set in one working day, then complete the legal assessment and draft notification.

Coverage verdict: This control receives Partial coverage. Runtime records bound the incident. Privacy makes the statutory decision and notification.

The mapping table

The table has two Full runtime controls and zero rows that turn wholly green through a gateway purchase. That is the useful result. A mapping that marks Accountability, Consent, Accuracy and Retention as solved by an inline proxy has confused evidence production with legal performance.

My candid view: Transfer Limitation is the row most likely to look complete in a board pack and fail in production. Procurement may name Singapore or an approved overseas location while a changed base URL sends a request elsewhere. Actual transfer occurs when the payload crosses the request boundary, so the final technical test belongs at that boundary. The contract establishes permission, while the route record establishes what happened in production.

Control ownership and gap treatment

Each Partial or Outside verdict needs a remediation owner and date. Privacy owns missing notices and exception assessments. Data governance owns disposal across internal stores. The business decision owner handles accuracy and human review. Legal owns the comparable-protection mechanism. Security and platform engineering own classification, destination enforcement, identity propagation and restrictive failure behaviour.

The Singapore PDPA compliance checklist turns these rows into dependency-ordered tests. The Singapore PDPA audit evidence guide packages the artifacts for sampling and reconstruction.

DeepInspect

DeepInspect is the enforcement point behind the Full runtime verdicts and the evidence source behind several Partial rows. It sits inline between authenticated users or agents and HTTP-based LLM endpoints. Every request is evaluated against identity, role, data classification, destination and policy before the model receives it. An evaluator error meets a fail-closed default, and the per-decision record is signed and tamper-evident.

Against this mapping, DeepInspect enforces purpose-scoped destinations, classifies the outbound payload for Protection, binds the originating principal to the request, applies region policy for overseas transfers, and supplies disclosure and incident histories for Access and Data Breach Notification. DPO appointment, notices, consent, exception analysis, accuracy review, contracts, enterprise retention and rights decisions remain with the owners named above. Book a technical deep dive at deepinspect.ai.