Singapore PDPA AI Compliance Checklist: 12 Items With a Completion Test
This Singapore PDPA AI compliance checklist turns the PDPC obligations into twelve dependency-ordered actions for an organisation deploying AI. Each item names an owner, an objective completion test and the evidence to retain, covering scope, purpose, notification, accountability, protection, overseas transfers, retention, access and breach response without assigning legal work to an HTTP gateway.
The Personal Data Protection Commission published its AI recommendation and decision systems guidance on 1 March 2024. It applies Singapore's Personal Data Protection Act 2012 to the development, testing, monitoring and deployment of AI systems, with specific treatment of Consent, Notification and Accountability.
This Singapore PDPA AI compliance checklist runs in dependency order. Item 8 needs the inventory in item 1, the purpose in item 3 and the request record in item 6. Each item has one owner and a completion test that a reviewer outside that team can run.
1. Inventory the deployed AI systems and roles
The PDPC's Generative AI guidance distinguishes Model Providers, System Providers and System Deployers. An entity may act as an organisation in one context and a data intermediary in another.
Owner: privacy with AI platform engineering.
Done when: every AI system has a row naming its owner, role, purpose, model endpoint, provider, processing region, personal-data categories and go-live date. The approved list reconciles against 30 days of observed HTTP egress, with each unexplained endpoint assigned for approval or blocking.
Keep: role register, architecture diagram, endpoint inventory and reconciliation report.
2. Appoint the data protection officer and publish contact details
The PDPA Accountability Obligation requires at least one individual to carry data protection responsibility, supported by policies and practices that give effect to the Act.
Owner: executive management and privacy.
Done when: the appointment is recorded, the DPO's business contact information is publicly available, and each system from item 1 has a named business and technical owner. On 10 August 2026, a staff member outside privacy should be able to locate the DPO contact and the escalation route without opening an internal organisation chart.
Keep: appointment record, public contact page and responsibility matrix.
3. State the purpose at the level of each AI feature
Section 18 of the PDPA limits collection, use and disclosure to purposes a reasonable person would consider appropriate. The PDPC's 2024 AI guidance asks organisations to explain the AI function, personal-data types and relationship between the processing and the feature.
Owner: Product and privacy teams share responsibility.
Done when: each inventory row has a purpose specific enough to distinguish customer-support summarisation from employee performance analysis. A reviewer can name one plausible use that falls outside the statement.
Keep: purpose register, product requirement and approval date.
4. Record the notice, consent or applicable exception
Sections 13 and 20 underpin Consent and Notification. The PDPC says meaningful consent depends on information about the personal-data types and purpose. Where legitimate interests supports processing, the organisation assesses adverse effects, ensures the interest outweighs them, and makes its reliance known.
Owner: Privacy and product teams share responsibility.
Done when: each purpose in item 3 links to a notice version and consent record, deemed-consent basis or documented exception. A synthetic user flow displays the notice before processing begins, and withdrawal follows the documented path.
Keep: notice text, version history, consent event or exception assessment, and withdrawal test.
5. Complete the deployment assessment before go-live
The PDPC's 1 March 2024 guidance encourages data protection impact assessments and documentation proportionate to harm and system autonomy. Higher-impact recommendations and decisions warrant clearer safeguards and human oversight.
Owner: privacy with security and the business decision owner.
Done when: every new AI system has a dated assessment before production approval. It covers data sources, purpose, accuracy, affected individuals, provider role, overseas transfer, retention, access, correction, security measures and human review.
Keep: signed assessment, risk register and approval decision. A document dated after go-live belongs in remediation history.
6. Write an independent record for every outbound AI request
Items 7 through 10 need evidence of actual processing. An application log written by the same component making the model call creates the self-attestation problem, particularly when a crash occurs after the response and before the log commit.
Owner: AI platform engineering owns this control.
Done when: a sampled hour produces one external record per HTTP request, carrying the originating identity, role, data class, endpoint, region, policy version, outcome and timestamp. The calling application has no custody of the record write path.
Keep: sample export, record schema, integrity test and retention configuration.
7. Minimise and classify the outbound payload
The PDPC's AI guidance recommends data minimisation and safeguards during development and deployment. A prompt may assemble names, account details and support history into one context window even when the task needs a few fields.
Owner: security and AI platform engineering.
Done when: a test prompt containing an approved synthetic identifier plus excess personal data is classified at the request boundary. Policy redacts the excess fields or refuses the request, and item 6 records the action.
Keep: test payload, classification result, policy decision and exception procedure.
8. Bind destination access to purpose and identity
The Purpose Limitation and Protection Obligations meet at the outbound call. An authenticated service credential usually identifies the application. The compliance record needs the person or agent that originated the request and the destination that purpose permits.
Owner: AI platform engineering with privacy approval.
Done when: a support agent can use the approved support model for the data classes in item 3, while the same payload sent to an unapproved general-purpose endpoint is refused. Both decisions carry the originating principal rather than a shared service account.
Keep: identity mapping, destination policy, permit record and denial record.
9. Enforce the overseas transfer decision per request
The Transfer Limitation Obligation requires comparable protection for personal data transferred outside Singapore. The PDPC's cross-border transfer resources point to Part 3 of the Personal Data Protection Regulations 2021 and contractual or certification routes.
Owner: legal for the mechanism, AI platform engineering for enforcement.
Done when: every approved model region maps to a documented transfer mechanism. A base URL changed to an unapproved region is refused at the request boundary and appears in the item 6 record.
Keep: agreement or certification evidence, region allowlist, configuration test and denial record.
10. Test protection controls in failure conditions
Section 24 requires reasonable security arrangements. A policy service that passes traffic during an evaluator timeout protects personal data only during normal operation.
Owner: Security engineering owns this control.
Done when: an induced policy timeout on 10 August 2026 refuses outbound model requests, records the failure and alerts the on-call path. A separate test confirms that an unknown endpoint and an unclassified payload receive the configured restrictive outcome.
Keep: test plan, console capture showing the denied request, alert ticket and remediation owner.
11. Make retention, access and correction operational
The PDPA requires disposal or de-identification when retention no longer serves the collection purpose and legal or business needs. It also gives individuals access to personal data and information about its use or disclosure, with correction where appropriate.
Owner: data governance and privacy.
Done when: internal AI records and provider-held prompts have documented retention periods. Given a synthetic person and date range, the access workflow can identify related AI disclosures and route a correction. A disposal test leaves evidence that the applicable records were removed or de-identified.
Keep: retention schedule, provider terms, access export, correction ticket and disposal certificate.
12. Run the data breach decision path against the clock
Mandatory breach notification has applied since 1 February 2021. Where a breach is notifiable, the organisation informs the PDPC as soon as practicable and no later than three calendar days after making that determination. Affected individuals are notified as soon as practicable where significant harm is likely.
Owner: incident response and privacy.
Done when: a tabletop involving prompts sent to an unapproved endpoint produces the affected identities, data classes, request count, destination, time window and containment record in one working day. Privacy then documents the notifiability decision and who would notify the PDPC.
Keep: incident query, assessment, decision log, draft notification and after-action record.
Completion register
Use one row per test. The evidence link should point to the artifact rather than to a project plan.
My candid view: item 6 deserves priority over a polished AI policy. The policy can state every approved provider in twelve-point type, while a request record shows the endpoint a production agent actually called at 02:14. The second artifact settles the factual question and gives the first one something measurable to govern.
Work outside the HTTP request path
Items 2 through 5 and item 11 contain legal, organisational, product and data-governance work. A gateway contributes runtime facts and enforcement evidence. It cannot appoint the DPO, draft a meaningful notice, determine the legal exception, assess output accuracy, conduct human review, correct a source record or execute disposal across enterprise stores.
The Singapore PDPA controls mapping assigns those responsibilities obligation by obligation. The audit evidence guide shows how to package the resulting records for review.
DeepInspect
DeepInspect is the control point behind items 6 through 10 and supplies runtime evidence to items 1, 11 and 12. 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, with a fail-closed default. The decision record is signed, tamper-evident and written outside the application's custody.
That component supplies the observed endpoint inventory, independent request record, payload classification, principal binding, destination and region enforcement, failure test result, disclosure history and bounded incident set. The appointment, notice, exception assessment, deployment approval, provider agreement, retention programme and rights workflow stay with their named owners. Book a technical deep dive at deepinspect.ai.
Frequently asked questions
- Does every Singapore organisation need this checklist?
The PDPA applies broadly to organisations collecting, using or disclosing personal data in Singapore, subject to statutory scope and exceptions. AI adds a processing mechanism rather than a separate legal category. Use the checklist where a deployed AI feature handles personal data, then adapt the role and sector requirements with counsel.
- Is consent always required for an AI system?
Consent is one basis described by the PDPC, alongside deemed consent and statutory exceptions such as legitimate interests in appropriate circumstances. The organisation should document the route used, meet its conditions, and connect it to the actual purpose and processing. A generic AI entry in a privacy policy gives weak evidence of that connection.
- Which checklist item tests the Protection Obligation?
Items 7, 8 and 10 test it on AI traffic. They classify and minimise the payload, bind destination permission to purpose and identity, and confirm restrictive behaviour during failure. The broader Protection Obligation also covers storage, access control, patching, incident response and other systems beyond the model call.
- What changes when the model provider is overseas?
Item 9 adds the Transfer Limitation analysis and enforcement test. Legal establishes the comparable-protection mechanism. Platform engineering ensures each request reaches a destination and region covered by that mechanism, with a record available afterward.
- How often should the checklist run?
Reconcile the inventory and endpoint traffic quarterly. Re-run items 6 through 10 after changes to identity propagation, routing, model providers, payload composition or policy services. Repeat the breach tabletop annually and after a material incident. Privacy should set the review cycle for notices, exceptions, assessments and retention.