Does the PDPA require an on-premise LLM?

21 Oct 2026 · Not legal advice

No. Singapore's Personal Data Protection Act does not say where a language model must run. It cares about control. Personal data you keep in your possession or under your direct control carries the full set of PDPA obligations wherever the server sits. Personal data you hand to someone outside Singapore, such as an overseas model API, may only leave under the Act's transfer rules, which require a comparable standard of protection backed by a contract, binding corporate rules, a law or a recognised certification. A private, open-weight model on infrastructure you control removes that transfer question for prompts and documents. It does not remove anything else.

Does the PDPA ban sending personal data to a cloud LLM?

No. Section 26 of the PDPA says an organisation must not transfer personal data outside Singapore "except in accordance with requirements prescribed under this Act" to ensure a standard of protection "comparable to the protection under this Act". It is a condition, not a ban.

PDPC's own examples include cloud services. In its Advisory Guidelines on Key Concepts, a company using a US-based CRM cloud service "must comply with the Transfer Limitation Obligation by ensuring that the service provider is able to afford adequate protection to the personal data transferred." Another example covers a Singapore cloud provider that copies data to its servers in London and Hong Kong: the customer, not the provider, carries the transfer obligation.

So the question for a hosted LLM is the same as for any other overseas processor: does the transfer meet the prescribed conditions?

What does the transfer rule actually require?

Under the Personal Data Protection Regulations 2021, as PDPC summarises them in chapter 19 of the Key Concepts guidelines, the overseas recipient must be bound to protect the data to a standard comparable to the PDPA in one of these ways:

• A law in the destination that imposes that standard.
• A contract that imposes a comparable standard and specifies the countries and territories the data may be transferred to.
• Binding corporate rules, for transfers within a corporate group, naming the recipients, the destinations, and the rights and obligations.
• Another legally binding instrument.
• A specified certification held by the recipient: Global CBPR or APEC CBPR if it receives the data as an organisation, or additionally Global PRP or APEC PRP if it receives it as a data intermediary.

The regulations also treat the obligation as met in some narrower cases, such as informed consent from the individual, transfers necessary for a contract with the individual, data in transit and data publicly available in Singapore. PDPC encourages organisations to rely on these only when they cannot use legally enforceable obligations or certifications.

For an LLM vendor, the practical check is the contract. If it does not name where your prompts, files, logs and fine-tuning data may be processed, it does not meet the contract route as PDPC describes it.

Does an on-premise LLM make you PDPA compliant?

No. It changes one obligation and leaves the rest.

PDPC is explicit that the transfer rule bites when an organisation "relinquishes possession or direct control" of personal data. Where data "remains in the possession or control of an organisation", even overseas, "the organisation has to comply with all the Data Protection Provisions". PDPC's examples include an organisation that "stores personal data in an overseas data centre on servers that it owns and directly maintains."

Two things follow:

• The test is control, not postcode. A model on servers you own and run is outside the transfer rule even if the rack is not in Singapore. A model on a vendor's servers in Singapore is not "on-premise" in this sense: the vendor is your data intermediary, and if it moves data abroad, the transfer obligation is yours.
• Every other obligation stays. Running the model yourself does not touch consent, notification or purpose. Section 24 still requires "reasonable security arrangements" against unauthorised access, use, disclosure, copying or modification. Retention limits still apply to prompt logs and vector indexes. If a breach is notifiable, section 26D still gives you no more than 3 calendar days from your assessment to tell the Commission.

Is the firm that builds your private LLM a data intermediary?

If it processes your personal data while building the system, yes, on PDPC's reading. The Commission's Advisory Guidelines on the Use of Personal Data in AI Recommendation and Decision Systems (issued 1 March 2024) say third-party developers of bespoke AI systems, which it calls Service Providers, "are data intermediaries who have obligations under the PDPA i.e., Protection and Retention Obligations." Under section 4(2) of the Act, a data intermediary processing under a written contract carries the protection and retention obligations, and the duty to tell its client about a data breach, but not the rest.

The client keeps the rest. Section 4(3) gives an organisation "the same obligation" for data processed on its behalf by a data intermediary "as if the personal data were processed by the organisation itself", and PDPC's Key Concepts guidelines say the organisation "remains liable" for that processing.

Two caveats on those AI guidelines. They are advisory and "not legally binding". And they are written for recommendation and decision systems; they do not address generative AI by name. Their good practices still fit an LLM build: data mapping and labelling of what went into training or retrieval, and a provenance record of where each dataset came from and how it was transformed.

We build these systems, so this applies to us. Where we touch client personal data during a build, we are the client's data intermediary, and the contract should say so.

What does Singapore's generative AI framework add?

The Model AI Governance Framework for Generative AI, released on 30 May 2024 through IMDA's AI Verify Foundation, is a set of practical suggestions, not a statute. It names nine dimensions: accountability, data, trusted development and deployment, incident reporting, testing and assurance, security, content provenance, safety and alignment R&D, and AI for public good. For a private deployment, the ones that turn into engineering work are data, security, incident reporting and testing.

When is on-premise the simpler route?

Our view, from the rules above: run the model under your own control when you cannot get an overseas provider to commit, in a contract, to where your data is processed; when a client or sector agreement already forbids handing the data to a third party; or when you want the transfer question off the table for a workload that mixes many kinds of personal data. Use a hosted model when the data is not personal, or the vendor's contract or certification fits the routes above and your team has no appetite to run GPUs.

A five-line checklist

1. List which workflows send personal data to a model, and where each model runs.
2. For any model outside your control, find the contract clause or certification that meets section 26.
3. Treat prompts, retrieved documents, logs and indexes as personal data with a retention period.
4. Put whoever builds or hosts the system under a written data intermediary contract.
5. Rehearse the section 26D clock: assess, then notify within 3 calendar days if notifiable.