Skip to content
Is there an AI for this?

Compliance

IBM watsonx.ai in Singapore

Structured issue-spotting for deploying IBM watsonx.ai in Singapore, read against the rules for that jurisdiction.

Source
Rules engine over a generic brief — no anchored quote on this page
Verified
Evidence not verified
Confidence
Low

Structured issue-spotting to support your own review — not legal advice. Verify against the cited primary sources and your counsel.

01What this reading assumes

Jurisdiction
Singapore
Principal framework
Personal Data Protection Act 2012 (Act 26 of 2012), supported by the Personal Data Protection Regulations 2021 (S 63/2021, in operation 1 February 2021). Consent, notification, purpose limitation, accuracy, protection, retention, transfer limitation and accountability obligations apply to any organisation processing personal data, including data used to train or run an AI system. The PDPC issues advisory guidelines that explain how those obligations land on AI — one set for AI recommendation and decision systems from March 2024, and one for generative AI published in July 2026. Sectoral layers sit above: the Cybersecurity Act for critical information infrastructure, HSA guidance for software medical devices, and the Health Information Act 2026 once it is brought into operation.
Delivery assessed
Enterprise SaaS
Data leaves the network
unknown — the deciding question for a hosted product
Vendor home jurisdiction
United States
Verified vendor positions
none — every vendor position below is a question, not an assurance
Rules evaluated
38
Rules fired
14

Assumptions about use

  • An internal deployment used by employees, not a public-facing product.
  • A person reads the output before acting on it — but that is not recorded, so the engine reports it as a gap rather than assuming it.
  • No significant automated decision is taken about a person by the system alone.

02Issues to work through

14 · 0 anchored

Cross Cutting

OUR RECOMMENDATIONSeverity HIGHconfidentiality-duties

Confidentiality duties bind independently of data protection law

RECOMMENDATION

Material can be entirely free of personal data and still be the material a contract stops you disclosing. Client retainers, non-disclosure agreements, supplier contracts and common-law duties are the usual sources, and several of them require consent before a third party processes the material at all — which a model API call is.

Required checks
  • Review the confidentiality clauses in the contracts covering the material going into the system.
  • Identify any contract requiring notice or consent before a subcontractor processes the material.
  • Decide whether the deployment needs a confidentiality carve-out negotiated into new contracts.
Vendor questions
  • Will the vendor accept a confidentiality undertaking beyond its standard terms?
  • Which staff at the vendor can access customer content, under what controls?
Technical controls
  • Segregate the most sensitive corpora into an index that the general assistant cannot reach.

Human review required — take this to your counsel

OUR RECOMMENDATIONSeverity HIGHprompt-handling

What ends up in a prompt, and where it goes next

RECOMMENDATION

Every prompt is a transfer of whatever it contains. Staff paste more than they intend, retrieved context travels with the prompt, and system prompts can often be extracted from the output. Assume anything reaching the model has left your control unless the contract and the architecture say otherwise.

Required checks
  • Write down which categories of information may be entered into a prompt, and tell people.
  • Establish what the system prompt contains and whether disclosing it would matter.
  • Establish which shadow tools staff are already using; the policy has to name the permitted ones.
Vendor questions
  • Are prompts and completions retained, for how long, and can retention be set to zero?
  • Are prompts used for abuse monitoring, and if so who can read them and for how long?
Technical controls
  • Redact or block high-risk patterns before the prompt leaves the application.
  • Keep prompt and completion logs out of general-purpose observability tools.
  • Set an explicit retention period on prompt logs and enforce it.
OUR RECOMMENDATIONSeverity MEDIUMvendor-acceptable-use

The acceptable-use policy may exclude your use case

RECOMMENDATION

Acceptable-use policies commonly carve out unsupervised legal, medical and financial advice, decisions about people without human review, and some surveillance and biometric uses. They are incorporated into the contract by reference and change without a signature, so the version that matters is the one live on the day you rely on it.

Required checks
  • Read the acceptable-use policy against your actual use case, not against a summary of it.
  • Where a carve-out applies, decide whether human review brings the use back inside the policy.
  • Set a reminder to re-read the policy — it changes without notice to you.
Vendor questions
  • Does your acceptable-use policy permit this use case, and will you confirm that in writing?
  • How are we notified when the acceptable-use policy changes?

Human review required — take this to your counsel

OUR RECOMMENDATIONSeverity MEDIUMauditability-practice

Being able to reconstruct a decision months later

RECOMMENDATION

The question that arrives after a complaint is what the system was shown and what it produced on a particular day. Models change, prompts change, and indexes are rebuilt, so the answer has to be recorded at the time. Without it, the only available response is that the output cannot be reproduced.

Required checks
  • Decide what is recorded per interaction: model and version, prompt template version, retrieved document ids, output, reviewer and outcome.
  • Set how long those records are kept, balanced against the retention duties that also apply to them.
Vendor questions
  • Does the vendor pin model versions, and how much notice is given before a model is retired or changed?
Technical controls
  • Version prompt templates in source control and log the version used.
  • Log the model identifier and version returned by the provider, not the one you requested.
OUR RECOMMENDATIONSeverity MEDIUMvendor-documentation

Vendor documentation has not been verified

RECOMMENDATION

We could not verify a data processing agreement, a subprocessor list, a position on training on customer data and a stated processing region for this vendor from a retrieved document. That is a gap in our evidence, not a finding against the vendor: until a document has been fetched and read, nothing here should be treated as settled either way.

Required checks
  • Obtain the current versions of the processing agreement, subprocessor list, security page and any regional-processing commitment.
  • Check that what the sales conversation promised also appears in the contract.
Vendor questions
  • Where is your data processing agreement published, and which version applies to us?
  • Where is your subprocessor list, and how much notice do we get before it changes?
  • Do you train on customer content by default, and where is that stated contractually?
  • In which country or region is inference performed, and where are logs retained?
OUR RECOMMENDATIONSeverity MEDIUMhuman-oversight-practice

We were not told whether a person reviews the output

RECOMMENDATION

Where output influences a decision about a person, the reviewer has to be able to disagree with it. That needs three things a rubber-stamp review lacks: enough information to judge, enough time to judge, and an override that is used often enough to be real. Design it before the volume makes it impossible.

Required checks
  • Name the role that reviews the output and what they see when they do.
  • Decide what evidence is retained about each review, so the practice can be shown to exist.
  • Set a threshold below which the system must not act without review.
Vendor questions
  • Does the product expose the retrieved context and the confidence behind a suggestion, or only the answer?
Technical controls
  • Show the reviewer the retrieved sources next to the suggestion, not the suggestion alone.
  • Record the reviewer’s decision, including overrides, as part of the audit trail.

Human review required — take this to your counsel

OUR RECOMMENDATIONSeverity MEDIUMlogging-practice

An AI deployment creates new copies of the data

RECOMMENDATION

Vector indexes, prompt logs, completion caches, evaluation datasets, fine-tuning checkpoints and backups are all copies of the source material in places the existing retention schedule does not mention. Deletion requests are the moment this is discovered, because deleting the source document does not delete its embedding.

Required checks
  • List every store the deployment creates and add each to the retention schedule.
  • Establish how a deletion request propagates to the index, the caches and the logs.
  • Establish how long backups keep material that has been deleted from the live system.
Vendor questions
  • What does the vendor retain, where, and for how long after we delete our copy?
Technical controls
  • Store the source document id with every embedding so deletion can cascade.
  • Set time-to-live on prompt and completion logs rather than relying on manual cleanup.
OUR RECOMMENDATIONSeverity LOWvendor-terms

The vendor’s terms may not permit the deployment you are planning

RECOMMENDATION

Provider terms routinely restrict things architectures assume: sharing seats, building a competing service, benchmarking and publishing results, reselling capacity, and processing certain data categories. A consumer or self-serve plan often carries different terms from the enterprise agreement, and the enterprise agreement is the one worth reading.

Required checks
  • Identify which contract actually governs — self-serve terms, an order form, or a negotiated agreement.
  • Check restrictions on seat sharing and on service accounts, which a shared internal assistant can breach without anyone noticing.
  • Check whether the terms allow the categories of data you intend to send.
Vendor questions
  • Which agreement governs our use, and can we have the current version in writing?
  • Are there restrictions on the data categories or the industries we may use the service for?

Singapore

LEGAL REQUIREMENTSeverity HIGHsg-pdpa

PDPA consent and notification reach the training data as well as the live prompt

ASSESSMENT

The Personal Data Protection Act governs the collection, use and disclosure of personal data by organisations, and an AI deployment does all three. Consent obtained for the original purpose does not automatically cover using the same records to build or tune a model, and a notification written for a support desk does not describe a system that generates text about the person.

Required checks
  • Separate the purposes: what the data was collected for, and what the AI system now does with it.
  • Decide whether an AI-specific notification is needed for re-use of existing customer data, and write it before the build.
  • For scraped or licensed training data, record why each source is lawful rather than assuming publicly available means unrestricted.
Vendor questions
  • What was your model trained on, and can you evidence the basis for any personal data in it?
Technical controls
  • Keep a per-source record of what entered the index or the fine-tuning set, so a consent question can be answered from the record.

Human review required — take this to your counsel

LEGAL REQUIREMENTSeverity HIGHsg-pdp-regulations-2021

There is no adequacy list, so every recipient needs its own route

ASSESSMENT

The Personal Data Protection Regulations 2021 set out the requirements for a transfer out of Singapore: the recipient must be bound by legally enforceable obligations, or hold a specified certification. Singapore publishes no adequacy list, so no destination is simply acceptable. Sending prompts and retrieved documents to a model provider is a transfer, and so is its use of a subprocessor further down the chain.

Required checks
  • Pick a route per recipient — contract terms, a recognised certification, comparable law or binding corporate rules — and record which one and why.
  • Extend the analysis to the vendor’s subprocessors, because the obligation follows the data rather than stopping at the contract you signed.
  • Keep the evidence with the vendor file, not in a slide, because this is what a PDPC enquiry asks for.
Vendor questions
  • Which certification do you hold — Global CBPR, Global PRP, APEC CBPR or APEC PRP — and can you show the certificate?
  • Will you accept the ASEAN Model Contractual Clauses, and do they flow down to your subprocessors?
  • Where is inference performed, and can it be pinned to a named region?
Technical controls
  • Pin the inference region where the vendor supports it, and alert when a request is served from anywhere else.

Human review required — take this to your counsel

OUR RECOMMENDATIONSeverity MEDIUMsg-pdp-regulations-2021

We have no evidence of this vendor’s transfer route out of Singapore

RECOMMENDATION

We could not verify which route this vendor relies on for transfers out of Singapore — contract terms, a specified certification, comparable law or binding corporate rules. That is a gap in our evidence, not a finding against the vendor, and it is the single question that decides whether the Transfer Limitation Obligation is met. Ask it in writing and keep the answer with the vendor file.

Required checks
  • Get the transfer route in writing before signing, not during an incident.
Vendor questions
  • Which transfer route do you rely on for personal data leaving Singapore, and can you evidence it?
  • Does that route cover your subprocessors, and how are we told when they change?
RECOMMENDED PRACTICESeverity MEDIUMsg-mgf-genai

The Model AI Governance Framework for Generative AI is the yardstick, not the law

ASSESSMENT

The Model AI Governance Framework for Generative AI outlines nine dimensions intended to create a trusted environment for generative AI, covering accountability, data, trusted development, incident reporting, testing and assurance, security, content provenance, safety research and public good. It carries no penalty. It is also the vocabulary a Singapore regulator, enterprise buyer or auditor will use, so a deployment that cannot speak it has a harder conversation.

Required checks
  • Walk the nine dimensions once and record which ones this deployment genuinely engages, rather than adopting all of them.
  • Decide who is accountable for the system by name, because the framework starts there and so does every follow-up question.
  • Set up incident reporting before launch — it is the dimension most often missing at the point it is needed.
Vendor questions
  • Have you mapped your product to the Model AI Governance Framework for Generative AI, and will you share it?
RECOMMENDED PRACTICESeverity MEDIUMsg-mgf-agentic-ai

An agent that acts does not move the accountability anywhere

ASSESSMENT

IMDA’s framework for agentic AI provides guidance on deploying agents responsibly, recommends technical and non-technical measures to mitigate the risks, and emphasises that humans are ultimately accountable. The practical consequence is that autonomy has to be bounded on purpose: which actions the agent may take alone, which need approval, and what the record shows afterwards.

Required checks
  • List the actions the agent can take and mark each one as autonomous or requiring approval, before it goes live.
  • Name the person accountable for the agent’s actions, and check they can actually intervene.
  • Decide what the end user is told about the agent, and whether they can tell when they are talking to one.
Vendor questions
  • What limits can be placed on the actions your agent can take, and are those limits enforced by your platform or by our prompt?
  • What audit record does a completed agent run leave, and how long is it retained?
Technical controls
  • Put irreversible actions behind an approval step, and log the approver alongside the agent’s reasoning trace.

Human review required — take this to your counsel

RECOMMENDED PRACTICESeverity LOWsg-ai-verify

AI Verify turns a governance claim into documentary evidence

ASSESSMENT

The AI Verify Testing Framework assesses an AI system against eleven internationally recognised governance principles, each with desired outcomes reached through named processes and validated by documentary evidence. That last step is the useful part: it converts "we govern our AI" into a set of artefacts somebody else can check, which is exactly what a buyer or a regulator asks for.

Required checks
  • Produce the evidence as the project runs rather than reconstructing it when an enterprise questionnaire arrives.
  • Consider the Global AI Assurance Sandbox if independent testing would unblock a customer or a launch.
Vendor questions
  • Has your product been tested under AI Verify or in the assurance sandbox, and can you share the report?

Structured issue-spotting to support your own review — not legal advice. Verify against the cited primary sources and your counsel.


03What this reading does not know

4
  • Whether any of the data falls into a special or sensitive category.
  • Whether any material is covered by legal professional privilege.
  • Whether prompts or documents leave the company network.
  • Whether a person reviews the output before it is acted on.

04Instruments these issues point at

6

All instruments recorded for Singapore


05Vendor documents being watched

3

06Ask about your own deployment

This page reads the rules against a generic organisation. Your size, industry, data and existing contracts change which of these issues matter and which fall away.

  1. 01What do we need to check before using IBM watsonx.ai in Singapore?