Practical AI for Australian Small Business

AI Vendor Due Diligence: The Questions to Ask and How to Read the Answers

If your business has already decided that an AI product is worth evaluating, the harder question is whether the vendor's answers support a safe, workable contract. This AI vendor due diligence checklist separates specific, verifiable answers from reassuring language that leaves the important decisions unresolved.

Last verified: 4 September 2026. References checked against current legislation.

Editorial Perspective

This page records a jurisdiction-neutral vendor checklist and the relevant guidance published by privacy and consumer-protection authorities in the European Union, United Kingdom, United States, Canada and Australia. It reports what those authorities have said and links to each primary source. It does not provide legal advice, approve vendors or prescribe a compliance outcome. Practical rollout guidance belongs in Need to Know AI's implementation resources.

This article summarises publicly available guidance from regulators and official sources. It is general educational information only and does not constitute legal or professional advice. Requirements vary by jurisdiction. Consult your regional authority or a qualified professional for advice specific to your situation.

If your business has already decided that an AI product is worth evaluating, the harder question is whether the vendor's answers support a safe, workable contract. This AI vendor due diligence checklist separates specific, verifiable answers from reassuring language that leaves the important decisions unresolved.

In short: A credible answer names the data, purpose, location, parties, controls, evidence, timeframes and contractual commitment involved. A vague answer relies on words such as "appropriate", "industry standard" or "as necessary" without defining their scope. Treat unanswered points as unresolved, not as evidence that the vendor's practices are acceptable.

A real vendor answer is specific enough to verify

A real answer identifies what will happen, who will do it and where the commitment appears in the contract. The strongest answers also provide evidence that can be checked independently, such as a recent audit report, security certification scope, subprocessor register or documented deletion process.

Apply this eight-part specificity test to every response:

  1. Scope: Which product, plan, account type and feature does the answer cover?
  2. Data: Does it cover prompts, uploaded files, outputs, usage metadata, support records and logs?
  3. Purpose: For which defined purposes may each data category be used?
  4. Parties and places: Which legal entities, subprocessors and processing locations are involved?
  5. Controls: Which settings or contractual restrictions change the handling?
  6. Evidence: Which current document, report or test supports the statement?
  7. Timing: What notification, retention, deletion or response period applies?
  8. Commitment: Is the answer binding, or is it only a description on a marketing page?

An answer can be detailed without being useful. A forty-page security document that never identifies the service covered, relevant controls or exceptions is still a non-answer.

The AI vendor due diligence checklist

The questions below are operational and commercial prompts. They are not presented as universal legal duties. Regional privacy rules may make some questions legally significant, as the authority summaries later in this page explain.

Question for the vendor What a real answer contains What a non-answer looks like
What customer data does the service collect or receive? A data map covering prompts, files, outputs, account details, telemetry, logs and support content, with purposes for each category. "We only collect data needed to provide the service."
Is customer content used to train or improve models? Separate answers for model training, product improvement, abuse monitoring and human review, including defaults, opt-out controls, plan differences and contractual terms. "We respect customer privacy" or "data is not sold." Neither answers the training question.
Where is each data category stored, processed and remotely accessed? Named countries or regions for primary storage, backups, support access and model processing, plus the mechanism for notifying customers of changes. "Data is stored securely in the cloud" or "regional hosting is available" without naming what remains outside the selected region.
Which subprocessors can access the data? A current list of legal entities, services performed, locations, relevant data categories and advance-change process. A generic statement that "trusted partners" may be used as necessary.
Which security controls apply to this service? Service-specific controls, the scope and date of independent assurance, encryption details, access controls, vulnerability handling and any exclusions. "Bank-grade security" or a certification logo with no report scope.
What happens after a security incident? A defined notification trigger, communication channel, timeframe, investigation support and allocation of responsibility for providing affected records. "We notify customers where required" with no trigger, timing or cooperation terms.
What happens to data when the contract ends? Export formats, retention periods, backup treatment, deletion method, completion timeframe and written confirmation where offered. "Data may be retained in accordance with policy."
Who owns inputs and outputs, and what licences are granted? Separate ownership and licence terms for customer content, generated output, feedback and vendor materials, including survival after termination and identified exceptions. "Customers retain their rights" without explaining the licence granted to the vendor or third-party claims.
How are liability and indemnities allocated? The cap, exclusions, claim types, indemnity scope, defence control and whether privacy, confidentiality, security or intellectual-property claims receive different treatment. "Standard limitations apply" or a headline cap that ignores broad exclusions elsewhere.
Can the vendor change these commitments? Notice periods, customer objection or termination rights, the documents incorporated into the contract and an archive or version history. A right to change policies at any time merely by posting an update.

Read the documents as one contract, not separate promises

The practical comparison is between the sales answer and the enforceable document set. Record where each answer appears: the order form, master agreement, data processing addendum, security schedule, service description, privacy notice or linked policy.

Linked documents can matter as much as the signed order. Check whether the agreement incorporates them, whether one document overrides another and whether the vendor can amend a linked policy without direct notice. These are contract-review questions, not conclusions about enforceability in any jurisdiction.

Evidence also needs a matching scope. A security report for the vendor's corporate systems may not cover the AI service, while a data-residency commitment may apply to stored content but exclude support access, telemetry, backups or model inference.

Data training answers require four separate distinctions

"We do not train on customer data" is incomplete unless the vendor defines both "train" and "customer data". The answer can be tested by separating four activities:

  • model training or fine-tuning;
  • service improvement and evaluation;
  • safety, fraud or abuse monitoring, including human review;
  • retention of prompts and outputs for logging or support.

The response also needs to distinguish default settings from optional controls and plan-specific promises. A control visible in the product interface is not equivalent to a contractual restriction, while a contract term may still contain exceptions that permit particular processing.

Regional authorities focus on different legal questions

The neutral checklist does not decide which law applies. That depends on the business, people, data, sector, locations and intended use. The following table reports selected authority positions relevant to vendor and processor arrangements.

Region What the authority says Due-diligence questions it supports
European Union Article 28 of the GDPR says a controller is to use processors providing sufficient guarantees, requires specified processor-contract terms and addresses prior authorisation for subprocessors. Chapter V addresses transfers to third countries. The EDPB's Opinion 22/2024 says controllers should have the identity of processors and subprocessors readily available, while the extent of verification can vary with processing risk. Sources: GDPR text and EDPB Opinion 22/2024. Which entity processes which data? What guarantees and evidence are available? Which subprocessors participate, and how are changes authorised? Which transfer arrangement is relied upon?
United Kingdom The ICO's processor-contract guidance covers processing instructions, confidentiality, security, subprocessors, rights assistance, end-of-contract provisions and audits. The ICO currently marks this guidance as under review following the Data (Use and Access) Act, so its status warrants rechecking before reliance. Source: ICO contracts and liabilities guidance. Does the contract contain the relevant processor terms? What evidence supports the vendor's guarantees? What happens at termination, during an audit or when a subprocessor changes?
United States The FTC's general small-business security guidance tells businesses to put vendor security expectations in writing, verify compliance and address data use, sharing, retention and deletion. This is published regulatory guidance, not a statement that one uniform federal vendor rule applies to every business; sectoral and state requirements can differ. Source: FTC cybersecurity guidance for small business. Are security expectations specific and verifiable? How may data be used or shared? What monitoring evidence and incident process are available?
Canada The OPC's cross-border guidance explains that organisations subject to PIPEDA remain accountable for personal information transferred for processing and describes contractual or other means for comparable protection. It also notes that a contract cannot override the laws of the foreign jurisdiction. Source: OPC cross-border processing guidance. Which third parties and jurisdictions are involved? What contractual safeguards, audit rights and transparency measures apply? Which foreign-law access risks remain outside the contract's control?

The checklist cannot approve a vendor

No answer format proves that a vendor is suitable for every workload. Regulators describe relevant responsibilities and considerations, but they do not endorse individual products or settle commercial questions about acceptable liability, output ownership, service continuity or switching cost.

The business's risk tolerance, sector rules, data sensitivity and intended decisions still matter. Ambiguous legal effect, unusual indemnities, high-impact automated decisions or unresolved cross-border issues belong with a qualified adviser in the relevant jurisdiction.

Questions the buying team still has to resolve

A complete vendor response leaves a separate set of internal decision questions:

  • Which planned workflows match the service and contract actually assessed?
  • Which data categories would enter the system, including through integrations and staff mistakes?
  • Which vendor answers are binding, evidenced and current?
  • Which exceptions remain, and what would their practical effect be?
  • Which unresolved answers would block the proposed use case?
  • Who owns the decision to accept commercial, security and regulatory uncertainty?

These are governance questions, not a substitute for jurisdiction-specific advice. A low-risk drafting tool used with public material and a system influencing employment, credit, health or customer access do not present the same decision.

For Australian businesses

The Office of the Australian Information Commissioner says due diligence for commercially available AI products should consider intended use, testing, human oversight, privacy and security risks, data flows, and who can access information entered into or generated by the system. The same guidance highlights the need to examine whether product terms or settings allow input data to be collected for further training or development. Source: OAIC guidance on commercially available AI products.

For overseas handling, Australian Privacy Principle 8.1 states that, before certain overseas disclosures, an APP entity takes reasonable steps to ensure the overseas recipient does not breach the applicable principles. The OAIC explains that whether overseas cloud handling is a "use" or "disclosure" can depend on effective control, and its guidance discusses contracts, subcontractors, security measures, monitoring, retrieval and deletion. Sources: Privacy Act 1988, APP 8 and OAIC guidance on sending personal information overseas.

The OAIC's data-breach guidance also discusses contractual allocation of breach assessment, information provision and notification roles where several parties are involved. Whether those provisions apply to a particular business or incident requires assessment of the facts and relevant coverage. Source: OAIC Notifiable Data Breaches guidance.

How this was researched

This guide is researched against primary regulatory sources and official regulator guidance, checked against those documents as of the date shown, and written for a business with no dedicated compliance function. We report what a named authority has published and link the document so you can read it yourself. We do not tell you what your legal obligations are.

Related reading: free AI acceptable use policy template, free AI register template, shadow AI audit checklist, guide to assessing AI risk, AI data residency comparison, AI vendor breach response plan template, and guide to liability for AI-generated content.

Related reading: Claude AI Review: Pricing, Features, and Business Verdict and Is Claude Pro Worth It? An Honest Assessment for Business Users.

Free tools: AI Privacy Risk Scorer to score your current AI tool setup against data-privacy best practice | AI Compliance Checker to check whether your AI tools meet your compliance obligations.

Is a security certification enough to approve an AI vendor?

No. A certification can support one part of the assessment, but its scope, covered service, audit period and exceptions matter. It does not answer questions about model training, output ownership, liability, retention or subprocessors.

What if a large vendor refuses to complete a questionnaire?

Public documentation can still be mapped against the checklist, but unanswered questions remain unresolved. The decision then becomes whether the proposed workload fits the evidence and contract available, rather than whether the vendor's reputation feels reassuring.

Does "no training" mean prompts are not stored or reviewed?

Not necessarily. Training, product improvement, safety review, support access and operational logging can be distinct activities. The vendor's answer needs to address each activity, its default setting, retention period and contractual basis.

How often does vendor due diligence need reviewing?

There is no universal interval for every business and jurisdiction. Sensible review triggers include a material service change, new subprocessor, policy amendment, security incident, contract renewal or higher-risk use case; any legally required timing needs confirmation for the relevant jurisdiction.

Methodology and source boundary

Need to Know AI reviewed primary legislation and regulator guidance for processor contracts, service-provider security, cross-border processing and commercial AI privacy. Sources were checked on 4 September 2026. The checklist itself is an editorial synthesis of recurring contract and evidence questions, and it is labelled as operational judgement rather than a universal statement of law.

This assessment did not test a named product, examine confidential vendor evidence or provide a legal interpretation. Product terms, regulator guidance and legislation can change, so the relevant documents and effective dates need checking when the checklist is used.

Find official guidance for your region

Requirements vary by jurisdiction. This article provides general information only. Consult your regional authority or a qualified professional for advice specific to your situation.

The information in this article is general in nature. It reflects a summary of publicly available guidance and does not constitute legal, privacy, or professional advice. Your obligations will depend on your specific situation, jurisdiction, and business circumstances. Do not rely on this article as a substitute for qualified legal or professional advice.

Compare the regional AI governance references before assessing a vendor for a jurisdiction-specific use case.

Compare the regional AI governance...

How this page was verified

On 4 September 2026, every source this page points to was checked. The page sets out questions and drafting prompts rather than statements of law, so the check confirmed that each regulator document it cites was still the current version.

  • 5 claims checked
  • 5 sources confirmed current

This is desk research against published documents. It is not independent testing, legal review, or an audit, and a document can change after it is checked. What this standard covers, and what it does not.