PDPA Checklist for GPT, Claude, and Gemini Features in Singapore Apps

Putting a model in a Singapore product is easy. Keeping personal data on a path you can explain is the work.

This is a checklist for product owners, ops leads, and the DPO who will be asked "where did that prompt go?" It is not legal advice. It is not a second commercial page for ChatGPT and LLM features in web and mobile apps. That URL owns the build. This article owns the data-handling design.

If the model must also write back to ERP or CRM, you have crossed into agents. Use AI agents vs chatbots, then the human-in-the-loop approval checklist. Come back here for what the model is allowed to see and store.

Read this with the PDPC Advisory Guidelines on Use of Personal Data in Generative AI and the AI recommendation and decision systems guidance. Those documents are advisory. Your counsel still signs off the hard cases.

SectionWhat this checklist is for

A feature that sends text, files, or retrieved chunks to GPT, Claude, Gemini, or an open model, then shows an answer or a draft in your web or mobile app.

| Piece | What you must be able to say | |---|---| | Data in | Which fields, files, or tickets the model can see | | Data out | What leaves your network, to whom, and in which region | | Purpose | Why that personal data is needed for this feature | | Log | What you keep, who can open it, and when it is deleted | | Review | Which outputs a human sees before a customer or ledger does | | Exit | How you stop the vendor and delete what they hold |

If you cannot fill that table for one screen, do not put live customer data on the feature.

SectionChecklist 1: Name the data the model will see

Do this before you pick a vendor.

• [ ] Write the user job in one sentence (internal SOP lookup, CS draft, quote summary)
• [ ] List the exact sources: which collection, folder, or API, not "our CRM"
• [ ] Mark each field: personal data, business confidential, or neither
• [ ] Strip identifiers you do not need (NRIC, full address, bank account, medical notes)
• [ ] Decide whether conversation history is stored, and for how long
• [ ] Confirm the same access rules apply as the source system (CS must not retrieve payroll)

Personal data is not only a name. A ticket that names a customer, a voice transcript, a photo of a workplace, or a retrieved contract clause can all identify someone.

If the source of truth is documents that change, retrieval is usually the first ship. That decision lives in when RAG beats fine-tuning. The PDPA question is whether those chunks should ever leave the building.

SectionChecklist 2: Decide what may leave the organisation

Every hosted API is a transfer. Treat it as one.

• [ ] Draw the path: app → your API → vendor (or your VPC) → back
• [ ] List what is in the request: prompt, history, retrieved chunks, tool results, uploaded files
• [ ] Say whether the vendor may retain prompts for abuse review, debugging, or training
• [ ] Get that answer in the current data-processing terms, not a sales deck
• [ ] Turn off training-on-your-data where the console or contract allows it
• [ ] Do not send secrets, passwords, or payment credentials "to help the model"

Singapore's PDPA includes a transfer limitation obligation: personal data should not go overseas unless you can show comparable protection. Many public model APIs process outside Singapore. That is not automatically forbidden. It is a fact you must document and control.

If the buyer or your DPO will not accept an overseas hop, you need a Singapore-region option or a model you run yourself. That is a product constraint, not a later surprise.

SectionChecklist 3: Pick vendor, region, and contract on purpose

Hosted GPT, Claude, or Gemini is fine for many first features. It is not the only shape.

| Option | When it is a reasonable first choice | What you still owe | |---|---|---| | Public vendor API | No personal data, or a narrow internal corpus you have approved | Written retention and training-use terms | | Cloud AI platform with a named region | You need a contract, VPC controls, and a region you can point to | Confirm the current region list in writing. Lists change. | | Singapore-region inference | Buyer policy or sector rules say data should not leave SG | Same logging and access rules as any other processor | | Self-hosted open model | You must keep prompts and logs inside your network | You now own GPUs, patching, and eval. Do not skip them. |

Check, in writing:

• [ ] Who is the organisation and who is the data intermediary
• [ ] Region of inference, embeddings, and stored conversations
• [ ] Retention window and deletion on request
• [ ] Whether staff at the vendor can open prompts
• [ ] Sub-processors (logging, eval, support tools)
• [ ] How you will export or wipe data if you leave

Do not claim a vendor "is PDPA compliant" because they have a DPA PDF. You remain responsible for the feature you ship. The PDPC generative-AI guidance is clear that system deployers carry primary responsibility for the systems they choose.

The commercial build for this layer is ChatGPT integration for web and mobile apps. Broader custom AI work sits on AI development Singapore. Capability detail (models, RAG, vision) is on the AI/ML development hub.

SectionChecklist 4: Log enough to defend, not enough to create a second store

Assume a customer or your DPO asks why a sentence went out.

Log:

• [ ] Request id, user role, and timestamp
• [ ] Which sources were retrieved (ids, not full NRIC-bearing text if you can avoid it)
• [ ] Model name and prompt version
• [ ] Whether a human edited the output
• [ ] Final action (shown, drafted, discarded)

Do not:

• [ ] Keep raw prompts that contain NRIC, medical, or bank details unless the DPO has a written reason and a deletion date
• [ ] Copy production conversations into a shared Slack channel
• [ ] Give the model admin credentials "for the demo"
• [ ] Store vendor debug dumps in an open bucket

Redact at write time. A log that is itself a personal-data database needs the same access control and retention as the app.

Approval logging (who signed a credit note) is a different checklist. Use human-in-the-loop AI approvals for the gate. Use this page for what the log may contain.

SectionChecklist 5: Put a human on outputs that use personal data

Review is not only an ops control. It is a data-protection control.

• [ ] Customer-facing text that mentions a person is draft-only in version one
• [ ] The reviewer sees the source snippet, not only the model paragraph
• [ ] The reviewer is a named role that already had access to that record
• [ ] Rejected drafts are deleted or locked on the same retention clock as tickets
• [ ] The model cannot email, post, or SMS on its own

Do not invent a new audience for personal data. If finance should not read CS tickets today, they should not review the CS assistant tomorrow.

When the next step is a write to a system of record, the product is an agent. Scope that on AI agents Singapore, not as a hidden toggle on a chat widget.

SectionChecklist 6: Know when Singapore-region or self-hosted actually matters

Stay on a hosted model when:

• The feature is internal
• The corpus is SOPs, price lists, or policies with little or no personal data
• You have written vendor terms and training-use is off
• Latency and cost matter more than geography in month one

Move region or self-host when any of these are true:

• [ ] The buyer contract says personal data must stay in Singapore
• [ ] The corpus is customer files, HR, medical, or regulated financial records
• [ ] You cannot get a comparable-protection story for the overseas hop
• [ ] The vendor retains prompts in a region you cannot name
• [ ] You need to delete a person's data from the model path and the vendor cannot say how

Self-hosting is an operations product. You still need eval, access control, and a patch plan. It is not a shortcut around PDPA. It only changes where the processing happens.

SectionChecklist 7: Retention, access, and a way to stop

• [ ] Retention period for chats, drafts, embeddings, and logs, written down
• [ ] A path to find and delete one person's data in those stores
• [ ] Access logs for who opened a conversation
• [ ] A kill switch: disable the feature without redeploying the whole app
• [ ] A vendor-exit note: what you delete, what they delete, who confirms

If you cannot delete a person's retrieved chunk or chat transcript, you are not ready for customer personal data on that feature.

SectionWhat we will not do in a first LLM sprint

• Index all of email or WhatsApp and "handle PDPA later"
• Send production NRIC or bank fields to a public playground key
• Promise that a hosted model "never stores anything" without the current terms
• Skip the DPO because the feature is "only a chatbot"
• Treat this checklist as a substitute for counsel on a regulated build

If you are still choosing the problem, start with AI consulting Singapore. If you already have the screen and the data source, start on ChatGPT integration for web and mobile apps.

SectionHow we run this before the first production prompt

1. Fill the table at the top for one screen.
2. Classify the fields. Remove what the model does not need.
3. Pick vendor and region against that classification, not against a demo.
4. Ship with redacted logs, draft-only customer text, and a kill switch.
5. Only then widen the corpus.

That slice is the integration job. It is not a second money page. Use ChatGPT integration for web and mobile apps to scope it.

SectionFAQ

Is sending a prompt to GPT, Claude, or Gemini a PDPA transfer?

If the prompt or the retrieved context includes personal data, treat it as personal data leaving your control. Confirm region, retention, and training-use in the current vendor terms.

Do we need a Singapore-region model on day one?

No. You need a written reason for the path you chose. Many first internal assistants never send personal data. Customer-facing or regulated corpora change that.

Can we anonymise and skip the rest?

Sometimes, if the remaining data cannot identify someone, alone or with other data you hold. That bar is easy to fail on tickets and contracts. When in doubt, minimise and keep the path documented.

Does human review make the feature PDPA-safe?

No. Review stops a bad send. It does not fix an overseas hop you cannot explain, or a log that keeps NRIC forever. Pair this page with human-in-the-loop approvals when a write is involved.

Where should I go if I already know we need the feature in an existing app?

ChatGPT integration for web and mobile apps. Bring the screen, the source list, and what must not leave Singapore. If the model must call tools, use AI agents Singapore. If the work is a wider AI application, use AI development Singapore.

Next step: Use ChatGPT integration for web and mobile apps to scope one in-product assistant with a data path you can defend. Use AI agents Singapore only when the model must take actions, not only draft or answer.