Verify the promise before commitment
AI Vendor Due Diligence
Investigate an AI supplier's service boundary, information handling, responsibilities and exit evidence, with a worked tender-assistant procurement case.
AI vendor due diligence asks whether a supplier's claims are sufficiently supported for your intended use. It is most valuable before a commercial commitment makes an unresolved issue difficult to challenge. The task is to establish what is being purchased, who operates it, how information and authority move through it, and what happens when the service changes or ends.
This guide is for procurement, security, privacy and business owners examining a prospective or existing supplier. It provides a practical evidence request and decision process. Comparing several qualified proposals is a separate job covered by the AI vendor evaluation scorecard.
Identify the supplier arrangement you are actually buying
Distinguish the contracting entity, application provider, model provider, hosting operator and delivery partner. They may be the same organisation, or several organisations with different responsibilities. Ask which party controls configuration, receives support requests, sees customer information and can change the underlying service.
Write a one-page use description before sending a questionnaire. Include users, data categories, locations to be assessed, connected systems, permitted actions and the consequences of an error. A public-content drafting service and a customer-account action agent require different diligence even if the vendor is the same.
The UK NCSC supply-chain security guidance treats understanding, controlling and checking supplier arrangements as connected activities. It is a useful methodological reference, not Saudi law. The method below extends the buyer's evidence discipline to a defined AI service.
Turn broad claims into bounded questions
Consider the hypothetical claim “customer data is not used for training”. Ask which information it covers: prompts, uploaded files, outputs, feedback and support material. Ask whether the statement applies to the purchased plan, enabled features and underlying providers. Separate model training from retention, human support access and operational logging; one statement does not answer all four questions.
Similarly, “Arabic supported” should lead to a task-specific evaluation, not an assumption about every dialect, document format or specialist term. “Enterprise security” should lead to the exact access, administration and investigation capabilities required. “Easy exit” should produce an export demonstration and an agreed process.
Record the supplier's answer in its own bounded terms. Avoid upgrading “available on an optional plan” to “included”, “on the roadmap” to “implemented”, or “tested in a benchmark” to “effective in our workflow”. These small changes in wording can create large gaps between the procurement decision and delivered service.
Use a claim-to-evidence request pack
| Question family | Evidence requested | Buyer verification |
|---|---|---|
| Service identity and scope | Contracting entity, product/version, service description and exclusions | Reconcile proposal, order form and actual configuration |
| Information handling | Data-flow map, retention terms, training-use terms and deletion process | Trace one representative record through its lifecycle |
| Other providers | Relevant subcontractor and underlying-service roles | Identify which promises depend on another party |
| Access and actions | User/admin roles, integration permissions and approval options | Observe an attempted out-of-scope action in an agreed test |
| Quality and limitations | Evaluation method, known limits and configuration-specific results | Test representative buyer cases, including difficult Arabic examples |
| Operations and change | Incident cooperation, support boundaries and change-notification process | Walk through a realistic service disruption and model change |
| Exit and continuity | Export format, configuration ownership and termination assistance | Inspect an export and identify what cannot be transferred |
For each requested item, record the evidence date, applicable product scope, reviewer and unresolved question. A document can be authentic but irrelevant to the service being bought. Treat a sales answer, contract commitment, configuration demonstration and independent report as different evidence types.
Ask fewer questions when consequences are limited, but do not remove questions that decide whether the use is acceptable. A short high-quality review of a bounded service is more useful than a long generic questionnaire completed by someone who does not know the proposed configuration.
Test the buyer's responsibilities explicitly
Suppliers often rely on customer settings, source permissions or human review. Identify these conditions and ask whether your organisation can operate them reliably. A control that requires daily expert attention may be unsuitable if nobody has that capacity.
Prepare a responsibility schedule covering provisioning, access removal, document updates, quality review, incident handling, approval rules and spending limits. Give each activity one accountable party, with supporting parties and response expectations. Resolve gaps between “supplier platform” and “customer application” before they become an operational dispute.
For Saudi requirements, have the relevant specialists assess actual entity and information scope. The NCA guide for AI systems explains why a supplier's general compliance statement is insufficient. The contract and technical evidence should support the buyer's applicability decision rather than substitute for it.
A worked example: procuring a tender-response assistant
Imagine a Saudi professional-services firm evaluating a fictional assistant that drafts tender answers from approved case studies. Its sales proposal states that documents remain private, Arabic is supported and all data can be exported. The intended use includes confidential project descriptions, but final submissions remain with a human bid manager.
The buyer traces a representative document and discovers three unresolved questions. The no-training commitment covers the main application but not an optional feedback feature. Arabic demonstrations use short questions, while the firm's tenders contain long bilingual tables. The export includes source files but not the curated answer library and approval history.
These are not automatically reasons to reject the supplier. They are specific decision conditions. Disable or separately approve the feedback feature; run an agreed evaluation on authorised representative tender material; and negotiate an export format or operational workaround for the answer library. Give each condition an owner and evidence deadline.
Procurement should distinguish an accepted limitation from a missing answer. If the firm deliberately accepts a manual library export, record its effort and responsibility. If the vendor cannot explain feedback handling, the information boundary remains unresolved. Both should not receive the same green status.
Convert findings into enforceable delivery conditions
Agree which statements belong in the contract, service schedule or acceptance criteria. Technical demonstrations alone may not commit the supplier to maintain a feature. Contract wording alone may not prove that the current configuration implements it. Align the two and have the appropriate legal and technical owners review their respective parts.
Useful conditions specify the deliverable, evidence, deadline and consequence of non-completion. “Provide security documents” is vague. “Provide evidence covering the purchased service and resolve the identified administrator-access question before production information is uploaded” gives the decision a meaningful boundary.
Match the commercial structure to remaining uncertainty using engagement models. A limited discovery or evaluation stage can establish evidence before a larger commitment. Avoid paying for a long deployment phase on the assumption that unresolved feasibility or information-handling issues will naturally disappear.
Plan diligence after signature
Keep a supplier record containing approved scope, evidence, responsibilities, conditions and review triggers. Revisit it when the service adds providers, changes processing arrangements, expands authority, materially changes model behaviour or reaches renewal. Review dates should reflect the consequence and pace of change, not merely the calendar anniversary.
Track supplier incidents and whether the agreed cooperation actually occurred. If a control assumption fails, update the risk register and use the authorised decision route. For material claims requiring independent challenge, scope AI assurance separately.
During acquisitions, supplier diligence is only one component of AI due diligence for M&A. Contracts may need review for transferability and change-of-control consequences; a normal product renewal review does not answer those transaction questions.
Prepare an enquiry around unresolved evidence
Open for AI's agentic AI consulting can help define requirements, boundaries and an evaluation plan. It also provides delivery services, so agree conflict disclosures and preserve buyer control over supplier decisions. Bring a redacted proposal, intended-use description and your three most consequential unanswered questions to discuss an AI supplier evidence review.
FAQ
Your questions, answered.
Should vendor due diligence happen before an AI proof of concept?
Complete a proportionate review before sharing information or granting access for the experiment. Establish the permitted data, environment, supplier roles and exit arrangements. A limited PoC may need less evidence than production, but it still needs a clear boundary. Expand the review when the proposed use or exposure increases.
What does a no-training promise fail to answer?
It does not by itself explain retention, support access, logs, optional features or every underlying provider's role. Ask which information and purchased configuration the promise covers, and check the contractual and technical evidence. Treat each information-handling question separately instead of assuming one attractive statement resolves the whole lifecycle.
Do we need to understand the supplier's underlying AI providers?
Understand the parties that materially affect your information, service continuity, contractual promises or action authority. You do not necessarily need every internal engineering detail. You do need enough visibility to identify whose controls and terms your decision depends on and who is responsible when something changes.
Who should complete and approve the supplier review?
Procurement can coordinate it, but technical, privacy, security, legal and business owners should review the questions within their remit. Identify one accountable decision owner and a route for unresolved conflicts. A supplier questionnaire completed only by sales and procurement can miss the actual configuration and operating obligations.
Can a supplier be approved with unresolved conditions?
Only through an explicit authorised decision defining what may proceed and what remains blocked. State each condition, owner, evidence deadline and consequence if it is not met. A restricted evaluation may be acceptable while production use remains unavailable. Do not label missing answers as accepted limitations without a conscious decision.
What should we review at renewal beyond price?
Review whether the approved use, service configuration, providers, information handling, support performance and exit arrangements have changed. Examine incidents and unresolved conditions from the previous period. Confirm that the evidence still covers the service actually used, including any features enabled informally since the original procurement decision.