AI Third-Party Risk Questionnaire

An AI third-party risk questionnaire should obtain answers that change a buying or operating decision. It needs to establish what the supplied AI does, whose information it uses, which parties can access it, how results are checked and what happens when the service changes. A long sequence of yes-or-no compliance declarations rarely provides that understanding.

For Saudi buyers, the questionnaire should start with the actual service and intended use, then route relevant questions to business, privacy, security, technology and procurement reviewers. It should allow a supplier to say that a fact is unknown, unsupported or outside the purchased scope. Those answers are useful when they lead to a defined condition; forced certainty is not.

The original questionnaire below is designed for procurement and governance teams to adapt. It is not an official regulatory form or a certification instrument. Use it alongside the AI supplier evidence requirements, which determine whether the submitted material supports the answer, and the procurement policy, which determines who may approve the outcome.

Define the service boundary before sending questions

Give the questionnaire a cover record: supplier legal entity, product and edition, feature, deployment arrangement, intended users, business purpose, information categories and proposed output use. Include whether the system can act on another service or only provide information. Ask the supplier to confirm or correct the record before answering.

Without that boundary, different teams can answer different questions while using the same product name. A security team may describe the main platform, a salesperson may describe an optional AI feature and a technical respondent may describe an underlying model API. The buyer needs to know which statement applies to the service it will actually receive.

Separate the buyer's intended use from the supplier's general supported uses. A service might support several functions, but the questionnaire should assess the chosen one. If the buyer later expands from answering warehouse-process questions to changing shipment records, the earlier answers need review against the changed authority and consequences.

Require an answer format that preserves uncertainty

For each question, request a concise answer, the applicable configuration, evidence reference, response owner, date and any limitation. Use answer states such as supported and evidenced, supplier-attested, planned, not supported, not applicable with reason, and unknown. Avoid an empty “yes” that leaves the reviewer to infer what has actually been demonstrated.

Ask suppliers to distinguish current features from roadmap commitments. A planned control can be commercially relevant, but it should not satisfy a condition needed before live use. Similarly, a buyer-configured control needs an explicit handover task; it is not complete merely because the product supports it.

Allow controlled evidence access where necessary. The supplier may reference a report available under confidentiality restrictions, but should identify its scope and the route for review. Record whether the buyer has inspected it. The UK government's AI Assurance Questionnaire is one public example of linking vendor transparency to evaluation and change questions; the questions here are tailored as an independent operational design.

Use eighteen core questions with targeted follow-ups

Original AI third-party risk questionnaire

Area	Question to ask	Follow-up when the answer is incomplete
1. Function	Which exact feature performs the proposed task, and which related functions are excluded?	Request a feature boundary and the purchased edition
2. Decision use	What decisions or actions is the output designed to support, and what uses are unsupported?	Compare the limitation with the buyer's intended workflow
3. Supply chain	Which parties provide models, hosting, retrieval, monitoring and support for this feature?	Map each party to its actual role and information access
4. Inputs	Which fields, files, connectors and contextual records does the feature receive?	Request a configured data-flow example, including automatic collection
5. Data use	How are customer inputs, outputs and feedback used for service operation or improvement?	Separate each data category and optional setting
6. Copies	Where are prompts, outputs, indexes, logs and backups retained, and under which arrangements?	Identify unknown stages rather than giving one location for the whole service
7. Access	Which supplier and buyer roles can access content, configurations and support records?	Request role-specific evidence and escalation paths
8. Isolation	How is the buyer's information separated from other customers and unauthorised internal users?	Ask for the relevant boundary and test evidence
9. Security handling	How can the buyer report a vulnerability or suspected AI misuse, and how is it triaged?	Confirm contacts, responsibilities and contractual cooperation
10. Evaluation	Which results support this feature for the buyer's task, languages and source conditions?	Request test scope, failure cases, version and limitations
11. Human review	What can a reviewer inspect, correct, reject and trace before a result is relied upon?	Demonstrate the actual review interface and record history
12. Actions	Can the feature send messages, change records or invoke tools, and how is authority constrained?	List enabled actions, approval points and stop controls
13. Change	Which model, feature, provider or data-handling changes are notified to the buyer?	Confirm notice route, timing and options for affected use
14. Continuity	What happens when the feature is unavailable, produces invalid output or has an uncertain action outcome?	Distinguish fallback, retry and reconciliation responsibilities
15. Records	Which activity and decision records can the buyer retrieve, and in what usable format?	Request an export sample with identifiers and timestamps
16. Exit	How are buyer data, access, connected credentials and required records handled at termination?	Separate export, retention, deletion and confirmation scope
17. Buyer duties	Which controls must the buyer configure or operate for the supplier's claims to hold?	Turn each dependency into an owner and acceptance task
18. Known limits	Which unresolved issues, excluded uses or planned controls affect the proposed deployment?	Record their decision consequences and review conditions

These questions are a core set, not a universal maximum. Add domain-specific questions when the intended use affects clinical, financial, employment, public-service or other consequential decisions. Remove irrelevant branches with a reason rather than asking suppliers to complete large sections unrelated to their service.

Worked example: warehouse helpdesk answers and support logs

Consider a fictional warehouse operator buying an assistant that answers staff questions from approved operating instructions. The initial scope is read-only guidance for authorised employees. It excludes updating stock records or directing physical equipment. The supplier answers that customer prompts are not used to train the underlying model.

That answer addresses one question but leaves others open. The buyer asks whether support staff can inspect diagnostic records containing excerpts from prompts and responses. The supplier's first response repeats the no-training statement without describing support access. The reviewer records a partial answer rather than accepting it as a complete data-handling assurance.

Illustrative follow-up record

Question	Current answer state	Next decision-relevant request
Use for underlying-model training	Supplier-attested, with a referenced term	Confirm the term applies to the purchased feature and settings
Prompt excerpts in diagnostics	Not yet explained	Identify fields, retention and filtering configuration
Support access to diagnostics	Unknown for the proposed arrangement	Identify roles, locations, approval and access records
Updating warehouse records	Excluded from the proposed use	Demonstrate that relevant write capabilities are not enabled

The buyer can continue reviewing other evidence while keeping live-data approval conditional on the unresolved handling question. It does not need to label every supplier answer false. It also should not infer that no-training means no retention, no support access or no personal-data processing. Each is a different claim with its own evidence.

If a controlled demonstration uses synthetic operating instructions and no employee records, the buyer may approve that narrow test separately. The questionnaire should show the evaluation boundary so nobody later treats the demonstration as approval for unrestricted live use.

Use branching questions to reduce burden

If the feature has no ability to act, ask the supplier to identify the configuration that establishes the read-only boundary and omit irrelevant transaction details. If it can invoke tools, expand the action branch to cover authority, destination systems, approval, retries and reconciliation. The branch should follow capability, not a supplier's preference for a shorter form.

If the service uses no buyer information beyond public inputs, confirm that limitation and the intended output audience. Do not automatically demand detailed personal-data responses for a hypothetical processing activity outside scope. Conversely, free-text or document inputs may contain information not captured by a simple field list, so the buyer must consider the actual workflow.

Mark unanswered applicability questions as unresolved. A supplier should not select “not applicable” for support access merely because support is rarely used. Ask what would happen in the escalation scenario the contract permits. Branching is a way to focus effort, not to remove inconvenient possibilities from the review.

Route answers to reviewers who can judge them

Assign each answer to the role that can assess its significance. Procurement can coordinate completeness and contractual follow-up; technical owners evaluate configuration and integration; privacy and security owners assess their domains; the business owner judges whether the limitations fit the intended task. A central coordinator should maintain the overall decision state.

Do not ask the supplier to determine the buyer's legal obligations from a generic form. Provide the relevant buyer requirements after the responsible specialists establish them. A supplier can explain capabilities and commitments, but the buyer retains the decision about whether those satisfy the applicable context.

Where reviewers disagree, record the specific question and decision consequence. “Security not approved” is less useful than “the support-access arrangement remains unverified for the proposed information category”. Precise conditions help the supplier provide an answer and help the sponsor understand what can proceed.

Score evidence without concealing a blocking condition

A structured scoring method can help compare suppliers, but define it before reviewing answers. Separate capability fit, evidence confidence and commercial considerations. A feature that is unsupported is different from a feature supported but not demonstrated. A planned capability should not receive the same status as one configured and tested.

Identify mandatory conditions that cannot be offset by strengths elsewhere. A high overall score for usability and price should not hide an unresolved authority or information-handling requirement. Show those conditions explicitly beside any summary score, with the authorised owner and next step.

For the warehouse assistant, the no-training answer may be useful while the support-log question remains open. Averaging the two into a single privacy score can obscure the missing decision. The use case classification framework and risk acceptance record should preserve the actual context and residual concern.

Protect the questionnaire and its attachments

The completed form can reveal architecture, privileged roles, business processes and security weaknesses. Set access and handling rules for the response and supporting files. Request evidence through an approved channel and avoid asking suppliers to send secrets, credentials or production personal data merely to make an answer look concrete.

Use synthetic or appropriately prepared examples for demonstrations where possible. If a restricted report needs review, establish who can inspect it and what findings can be retained. An evidence reference should remain meaningful even when the underlying report cannot be circulated to every stakeholder.

Record the response version and service scope. When a supplier updates an answer, preserve the earlier version and the reason for change. This is especially important if the revised answer affects a contract, trial or activation decision already made.

Turn answers into conditions and ownership

At the end of review, produce a short decision summary: proposed use, material supported claims, unresolved issues, required buyer tasks and conditions for the next step. Link each condition to the question and evidence that created it. The summary should say whether it blocks the whole service, a specific feature or only a proposed expansion.

Do not close an item merely because the supplier answered the follow-up email. The responsible reviewer should confirm that the answer is sufficient for the claim. If a condition requires a configuration test, name the person who will perform it and the evidence needed for acceptance.

Use the approval-route design to obtain the actual decision. The questionnaire informs that decision; it is not itself an approval certificate. A sponsor should be able to see exactly what has been authorised and what remains outside scope.

Run a clarification session using one information journey

When answers remain fragmented, ask the supplier to walk through one controlled request from input to deletion or retained record. Use the buyer's intended workflow, not a generic slide about the entire product. Invite the people who can answer configuration, support and contractual questions, and distinguish answers they confirm from matters they must investigate.

For the warehouse helpdesk, follow a synthetic staff question into retrieval, answer generation, user review, diagnostic recording and a hypothetical support escalation. Ask which stage receives excerpts, which identity can inspect them and what changes if support is enabled. This walkthrough turns the vague question “where is our data?” into a sequence of answerable service questions.

Do not treat the meeting itself as evidence of resolution. Update the relevant questionnaire items, attach references and leave unconfirmed answers open. Send a concise factual record for supplier correction through the agreed procurement process. The buyer's reviewers then decide which replies satisfy the requirement and which need a demonstration or contractual clarification.

Use a response-quality review before supplier scoring

A coordinator can check whether answers refer to the agreed service, identify the respondent, contain usable evidence references and explain exclusions. This is a completeness check, not a technical assurance judgement. A well-formatted answer can still describe an unsuitable arrangement; an incomplete answer may concern a capable service that has not yet been explained adequately.

Flag recurring response problems explicitly: a platform-wide answer to a feature question, a roadmap item presented as current, a certification without relevant scope, or a claim dependent on unassigned buyer configuration. Return those items for clarification rather than spending specialist review time interpreting what the supplier may have intended.

Keep a disagreement register for material items. Identify the competing statements, affected use and owner authorised to decide. In the warehouse example, the open question is support access to diagnostic excerpts, not whether the supplier generally believes in privacy. A precise disagreement can be resolved; a broad debate about trust often cannot.

Finish with an item-level disposition: accepted for the stated purpose, accepted subject to a named task, deferred pending evidence, or not accepted. Preserve the reasoning and the limitation. This produces a questionnaire that supports a defensible buying decision while keeping the supplier's response burden focused on the facts that matter.

Refresh the answers when the service changes

Attach review triggers to material answers. A new provider can reopen supply-chain questions; a new connector can change inputs; enabling tool use can change authority; a support arrangement can change access. Use change triggers to request a focused update rather than resending the full form every time.

At renewal, confirm the service still matches the cover record and review outstanding conditions. Keep answers that remain applicable, with evidence of that confirmation. Preserve historical versions so the organisation can reconstruct the basis for earlier decisions without mistaking old facts for current ones.

For a governance setup discussion about AI supplier questionnaires, bring the intended workflow and a sample of existing supplier answers. AI governance setup can turn the form into a useful review process with clear evidence states, accountable conditions and a manageable supplier burden.