AI vendor questions: 15 to ask before you sign

A demo has gone well and the contract is on your desk. The AI vendor questions worth asking before you sign come to 15, in five groups: data, testing, human control, contract and exit. Each ties to PDPC or IMDA guidance. A scoring sheet turns the answers into a decision.

PDPC’s Advisory Guidelines on Use of Personal Data in Generative AI, issued on 20 July 2026, say a business that deploys a generative AI system bears primary responsibility for ensuring it can meet its PDPA obligations, and that when procuring one it must ensure it has sufficient information on upstream safeguards for a holistic assessment (paragraph 9.1). They are advisory, not law, and this article is general information, not legal advice. Our walk-through of the guidelines covers the rest of a deployer’s duties.

What does PDPC expect a buyer to know before signing?

The 2026 guidelines give buyers no question list, but they say it is good practice for system providers to share data security and protection measures (for example access controls, residency and retention policies), testing and performance metrics, and incident response and data breach procedures (for example notification timelines) (paragraph 8.3). That is good practice, not a duty, so a vendor can decline; our scoring below treats a refusal as an answer. The questions to ask an AI vendor follow from that list.

Three points shape who owes what:

• Your vendor is probably your data intermediary. Under a written contract it is subject to the protection and retention obligations and must report breaches to you, but PDPC’s guide on data protection clauses (1 February 2021) says you stay liable for its acts or omissions in processing your data that amount to a breach (paragraphs 3 to 5). Our glossary defines data intermediary.
• Part V of PDPC’s 2024 guidelines is not for every purchase. The procurement part of the guidelines on AI recommendation and decision systems (issued 1 March 2024) is for service providers building bespoke or fully customisable AI systems, and is not relevant to organisations that retail commercial off-the-shelf solutions using AI (paragraph 11.1). For ready-made software the 2026 guidelines fit better: they cover system providers that retail off-the-shelf systems (8.1) and what system and model providers should share (8.3, 7.5).
• The testing questions borrow from IMDA. Its Starter Kit for Testing LLM-Based Applications for Safety and Reliability (Version 1.0, January 2026) is voluntary, aimed at developers, testers and compliance professionals, and names five risks.

Numbers in brackets are paragraphs of PDPC’s 2026 guidelines unless another document is named. “Sample clause” means a clause in PDPC’s 2021 guide. Practical detail with no reference, such as what to ask for, is our suggestion.

Data: where does your information go, and who else sees it?

• Q1. Where is our data processed and stored, and can it leave Singapore? Ask for the residency statement and a list of the other companies that handle the data. PDPC lists residency among what system providers should share as good practice (8.3), and sample clause 2.3 bars overseas transfer without your prior written consent.
• Q2. Is anything we enter used to train or improve a model, by you or your model provider? A model provider that uses end-user prompts for model development is itself an organisation under the PDPA (7.1), and a general notice is not enough to obtain consent for large-scale training on user data (4.4). Sample clause 2.2 limits use to the agreement’s purposes unless you consent in writing or the law requires it.
• Q3. How long are prompts, outputs and logs kept, who can read them, and how are they deleted? PDPC lists access controls and retention policies as shareable (8.3) and extends its retention-policy good practice to system providers (7.3). Sample clauses 2.4.2 (optional, for sensitive data) and 2.7.1 cover need-to-know access and retention.

Testing: what has the vendor actually tested?

• Q4. Which of the five risks did you test, on what, and what pass mark did you set beforehand? The Starter Kit’s five risks are hallucination, bias in decision making, undesirable content, data leakage and adversarial prompts. It says thresholds should be set before testing (sections 1.2.1, 3.1.4) and simple tests are prudent even where a risk is not material (3.1.3). Weigh any “not tested” against that, in our view; silence scores zero.
• Q5. Can we see the results, failures included, and run our own questions before signing? The Starter Kit warns that a 99% pass can hide critical failures (3.7.1) and highly encourages custom test sets (3.2.1). Bring your own real enquiries, some it should refuse (our suggestion); our guide to AI hallucination checks covers sizing and scoring.
• Q6. How do you monitor the tool after launch, and what do you retest when it changes? Pre-deployment tests are a snapshot, the Starter Kit says, because the model may drift. It suggests retesting after changes to the language model, prompts or integrations (3.7.3). Ask who retests and whether you see the results.

Human control: where does a person step in?

• Q7. What can the tool read, send or change, and can we narrow each permission? PDPC’s Organisation C example restricts an assistant’s file and network access by role (9.5). If the tool reads inboxes, uploads or web pages, ask about testing against hidden instructions in that content (Starter Kit section 3.6.2). Our guide to agents and chatbots has demo checks; see also what agentic AI means.
• Q8. When does a person step in, who approves, and is every action logged? Organisation C escalates complex or high-risk tasks to people (9.5), and the Starter Kit treats autonomy and output volume as raising the chance of errors (3.1.2). Ask for the handover rule and a sample log in writing, and name who owns prompts, outputs and activity data in your business (9.3).
• Q9. If it informs a decision about a person, can staff see why, and what training comes with it? For bespoke or customisable systems, the 2024 guidelines encourage plain-language explanations and training for those who rely on the system (11.7). The Starter Kit says bias testing is highly context-dependent, with no core benchmark (1.2.2), so ask what it covers. See our CV screening guide.

Contract: what will the vendor put in writing?

• Q10. Will you sign data-processing terms, with the security measures attached? PDPC’s sample clauses cover PDPA compliance (2.1), purpose (2.2), overseas transfer (2.3), a security schedule that cannot change without your written consent (2.4.1), access and correction help (2.5, 2.6) and retention (2.7). PDPC advises legal advice on drafting.
• Q11. How fast will you tell us of a suspected breach, and what will you tell us? The 2021 guide says a contractor with reason to believe a breach has occurred must tell the customer without undue delay; the customer assesses and, if it is notifiable, tells PDPC as soon as practicable and no later than three calendar days after the assessment (paragraph 4; PDPC’s newer pages count from the determination that a breach is notifiable, as our breach playbook explains). Sample clause 2.8 asks for immediate notice of a breach of its clauses 2.2 to 2.7. The guide is from 2021, so check PDPC’s current breach guidance.
• Q12. If your failure puts us in breach, who pays, and does that cover your suppliers? Sample clause 2.9 has the contractor indemnify the customer for its breach of clauses 2.2 to 2.7 and for any act, omission or negligence of it or its subcontractor that results in the customer breaching the PDPA.

Exit: how do you leave with your data deleted?

• Q13. On exit, will you return or delete everything and confirm in writing? Sample clause 2.7.2 has the contractor return or delete your personal data on request, confirm in writing and instruct third parties to do likewise. Ask what “everything” covers (prompts, outputs, logs, indexes, backups) and by when; that list is our suggestion.
• Q14. Can you find, export and correct one person’s data quickly, and can we export our own material? Data your vendor holds still counts as under your control for access and correction requests, and an intermediary may forward requests but need not (2026 guidelines, 10.2). Sample clauses 2.5 and 2.6 require help on written request. Exporting your own documents and templates is our suggestion.
• Q15. What notice will we get before you change the model, your suppliers or the terms, and can we leave if we object? The sample security schedule cannot change without your written consent (2.4.1), and the Starter Kit lists a change of language model as a reason to retest (3.7.3). Notice periods and exit rights are our suggestions.

How do you score the vendor replies?

Score each answer 0, 1 or 2 and note the evidence beside it:

• 2: specific, written and backed by something you can read, such as a document, a test summary or a clause.
• 1: general or spoken, or “on request”, with nothing to read yet.
• 0: no answer, a refusal, or marketing language that ignores the question.

Before reading any replies, mark your must-haves and fix the decision rule, as the Starter Kit advises for test pass marks, so the goalposts cannot move (3.1.4). If the tool will touch customers’ names, contact details or anything sensitive, Q1, Q2, Q3, Q10, Q11 and Q13 are must-haves. The rule is our suggestion, so adjust it to your risk:

• 24 or more out of 30, and no zero on a must-have: go to a pilot, with every score of 1 written up as an open item.
• 18–23, or 24 or more with a zero on a must-have: send the gaps back in writing and score again.
• Under 18: do not sign, whatever the must-haves.

Also total each group out of 6.

What does a scored comparison of two vendors look like?

This is an illustration: the firm, both vendors and their replies are fictional. A 25-person air-conditioning servicing company in Woodlands wants an assistant to draft customer email replies and summarise technicians’ job notes, which hold names, addresses and phone numbers. Its must-haves are the six above, and Vendor B’s demo was the slicker one. The Q1 replies show the difference:

• Q1, where is our data? A: “Stored in Singapore. Text is sent to our model provider for processing; their location and our contract terms are on the attached supplier sheet.” Score 2: documented, so whether any overseas processing is acceptable is now the firm’s informed decision. B: “We use leading cloud infrastructure with industry-standard security.” Score 0: no location and no list, on a must-have.

The group totals were:

• Vendor A: data 5, testing 5, human control 5, contract 5, exit 4. 5 + 5 + 5 + 5 + 4 = 24, with no zero on a must-have. It goes to a pilot, and its six scores of 1 (Q3, Q6, Q9, Q12, Q14, Q15) become the open items.
• Vendor B: data 2, testing 1, human control 5, contract 2, exit 2. 2 + 1 + 5 + 2 + 2 = 12, with a zero on Q1. It fails the rule twice, so the firm does not sign.

Vendor B scores well only on human control, which a demo can show.

What to do before you sign

As an AI procurement checklist for a Singapore SME, these steps are our suggestion:

1. List the personal data the tool will touch. If there is none, confidential documents still deserve Q1 to Q3.
2. Mark your must-haves and fix the decision rule.
3. Send the 15 questions in writing and score only what you can read.
4. Pilot the tool on your own test questions, sized and scored as in our hallucination guide, and rerun them after any change.
5. Put the answers that matter into the contract, and take legal advice on the wording.
6. Before go-live, write a one-page AI use policy for staff, name who owns prompts, outputs and activity data, and diarise a review date.

More guides on using AI at work are in the AI topic.

Common questions