Procuring AI Safely: A Practical Framework for Supplier Due Diligence and Contracting

A procurement team buys an AI-enabled contract-review platform through a familiar software agreement.

The supplier’s security documentation is acceptable. The data-processing schedule is signed. Service levels cover availability and support. The demonstration shows that the platform can identify clauses, summarise obligations and flag potential risk significantly faster than a manual first review.

Six months later, the supplier changes the model supporting the service.

The procurement team was not told in advance. The new model uses a different hosting arrangement and produces materially different results on parts of the contract population. The supplier has also added a subprocessor, expanded the use of customer interactions for product improvement and altered the way prompts and outputs are retained.

The original contract contains no effective model-change control, no agreed performance baseline, no obligation to disclose the underlying AI value chain and no practical right to obtain the evidence needed to investigate the change.

The organisation has bought an AI capability. It has not bought control over the conditions on which that capability depends.

That distinction is becoming one of procurement’s most important governance problems.

AI is not only acquired through products labelled as artificial intelligence. It is increasingly embedded in sourcing platforms, contract tools, recruitment systems, finance software, customer services, supplier operations and outsourced business processes. A supplier may use a third-party model, cloud service, specialist dataset and multiple subprocessors to deliver one apparently simple feature.

The buyer can remain accountable for the outcome even when the relevant technical choices sit several tiers down the supply chain.

KOR’s central argument is therefore:

AI supplier due diligence must follow the capability from use-case definition through selection, contracting, live operation and exit. It cannot end with a questionnaire or a signed software agreement.

Procurement has two roles in the AI transition. It is a user of AI inside its own function, and it is the organisational gatekeeper for AI acquired throughout the wider supply base. A function cannot credibly claim advanced AI governance if it controls employee use while buying AI-enabled services whose models, data practices, change mechanisms and operating boundaries remain poorly understood.

Many established technology controls remain essential for AI: financial stability, information security, privacy, resilience, service management, accessibility, intellectual property and business continuity.

AI does not replace those controls. It adds new questions to them.

A conventional SaaS assessment may establish where data is hosted, whether encryption is used and which security certifications the supplier holds. It may still fail to establish:

• which model or models support the service;
• whether the supplier developed, fine-tuned or merely integrated them;
• which third parties can alter the model or its availability;
• what data was used to train, tune or evaluate the system;
• whether customer prompts, documents or outputs are retained or reused;
• what performance measure is appropriate to the buyer’s actual task;
• how the system fails across different populations and conditions;
• what human review remains necessary;
• how a model or subprocessor change will affect the service;
• what evidence the buyer can obtain when an incident or dispute occurs;
• how the organisation can transition away without losing data, records or operational knowledge.

The supplier’s answer that it uses “industry-leading AI” resolves none of those issues.

Nor does a generic statement that the service is compliant with applicable law. Compliance depends on the system, role, jurisdiction and use case. Procurement needs enough information to determine which obligations apply and how responsibilities will be discharged in practice.

Current guidance consistently points towards continuing, evidence-based control.

The UK Government’s Guidelines for AI procurement recommend defining the problem before selecting the technology, assessing data quality and availability, seeking clarity about models and training data, testing across relevant conditions, considering independent audit, avoiding unnecessary black-box dependency and planning for end-of-life. The guidance was developed for public-sector buyers, but the underlying commercial questions apply more widely.

The Cabinet Office’s PPN 017 on improving transparency of AI use in procurement reinforces proportionate due diligence where AI affects tender responses or service delivery. It recognises that clarification, additional evidence, presentations or other checks may be required to establish the credibility of supplier claims.

The ICO’s contracts and third parties toolkit expects organisations to map information flows, establish data-protection roles, undertake due diligence on accuracy and bias, agree appropriate performance expectations before procurement, control subprocessors and document technical and organisational settings. It also identifies the value of accuracy-related KPIs or service levels and continuing re-evaluation. The ICO currently states that parts of its AI guidance are under review following the Data (Use and Access) Act, so organisations should check the latest position before relying on it for legal interpretation.

The UK Government’s 2026 AI Management Essentials asks whether organisations maintain a current record of the AI systems they use and whether they request the necessary documentation, assets and resources from third-party providers.

The NIST AI Risk Management Framework requires organisations to map risks across all components of an AI system, including third-party data and software, document human-oversight arrangements and identify controls for third-party AI technologies.

Taken together, these sources support a practical conclusion: procurement cannot manage third-party AI through supplier reputation and standard terms alone. It needs a proportionate body of evidence linked to the intended use and maintained after award.

KOR’s proposed framework has five gates:

1. Discover — define the use case and identify the complete AI value chain.
2. Evaluate — test the supplier’s claims and evidence against the intended operating conditions.
3. Contract — convert critical assumptions and controls into enforceable obligations.
4. Monitor — maintain assurance as models, data, suppliers and usage change.
5. Exit — preserve control over data, records, continuity and transition.

The gates are connected. Weak discovery produces vague evaluation. Weak evaluation produces generic contract drafting. Weak contracts limit the evidence available for monitoring. Weak exit provisions increase lock-in and reduce the buyer’s ability to act when assurance deteriorates.

The visual should show the buyer moving through Discover, Evaluate, Contract, Monitor and Exit while the contracted supplier connects to an underlying model provider, cloud infrastructure, datasets and subprocessors.

Before progressing an AI supplier, procurement should be able to answer ten questions:

1. What business problem and decision boundary is the system intended to support?
2. Which supplier, model provider, hosting provider, dataset and subprocessor form the delivery chain?
3. What customer, personal, confidential or commercially sensitive data enters the system, and how is it retained or reused?
4. What evidence supports performance claims under the buyer’s actual operating conditions?
5. What are the known limitations, failure modes and groups or scenarios for which performance is weaker?
6. What human review, override and escalation remain necessary?
7. Which legal and regulatory roles do the parties perform in the relevant jurisdictions?
8. What must the supplier disclose before changing a model, provider, data practice or material feature?
9. What audit, incident, monitoring and remediation evidence will be available during the contract?
10. Can the organisation exit with its data, records, configurations and operational continuity intact?

A positive questionnaire response is not enough. The buyer should record the artefact or evidence relied upon, any limitation, the accountable owner and the contractual or operational control that follows.

Due diligence should begin before the supplier questionnaire.

The buyer first needs to define what it is procuring, how it will be used and what could go wrong. Without that context, teams either ask every supplier the same exhaustive questions or accept superficial answers because they cannot distinguish material information from technical detail.

Define the intended use

Procurement should establish:

• the business problem being addressed;
• the users and affected stakeholders;
• the decision, recommendation or workflow influenced by the system;
• the data required;
• the likely consequence of error;
• the geographical and regulatory scope;
• whether the system informs, recommends, generates, classifies or acts;
• the degree of human oversight expected;
• prohibited or out-of-scope uses;
• the conditions under which use should be suspended.

A tool summarising low-risk internal documents does not require the same evidence as a system ranking job applicants, recommending supplier exclusion or generating contractual positions. Proportionality should follow the consequence and context of the use case, not the supplier’s marketing category.

Map the complete delivery chain

The contracted supplier may not be the model provider. Procurement should identify:

• the contracting entity;
• the product owner and service operator;
• the underlying model provider and model family;
• cloud and hosting providers;
• external datasets or data suppliers;
• subprocessors;
• implementation and support partners;
• open-source or third-party components;
• locations from which the service is developed, operated and supported;
• which party can make a material technical or commercial change.

This value-chain map is central to supplier assurance. It shows where evidence must come from and which dependencies the direct supplier actually controls.

Determine the parties’ roles

Legal roles cannot be solved through procurement terminology alone. The buyer, supplier and underlying providers may have different responsibilities under data-protection, sectoral or AI-specific rules.

For organisations operating in or supplying into the EU, the EU AI Act distinguishes providers, deployers, importers, distributors and other actors. Article 25 addresses responsibilities along the AI value chain and requires written allocation of information and assistance in specified high-risk contexts. Article 26 places obligations on deployers of high-risk systems, including competent human oversight, monitoring and incident response. Article 50 transparency obligations apply from 2 August 2026 for specified systems and content.

The commercial lesson is not that every AI contract requires the same EU clauses. It is that the parties must understand which role each is performing, and the contract must provide the information and cooperation needed to discharge that role where the regime applies.

Supplier questionnaires are useful for collecting information consistently. They are weak when a positive answer is treated as proof.

A supplier may state that it tests for bias, maintains human oversight and follows secure-development practices. Procurement should ask what those statements mean for the system and version being purchased.

KOR’s Evidence Confidence Model provides a useful distinction:

• Provisional: the supplier asserts that a control or capability exists.
• Substantiated: relevant policies, reports, architecture, test results or contractual evidence support the claim.
• Verified: observed operation, telemetry, independent testing, incident evidence or measured outcomes support it within the defined scope.

Not every procurement requires independent verification of every supplier statement. The evidence standard should reflect the decision and risk. But the buyer should know whether it is relying on assertion, documentation or operating proof.

1. Supplier governance and accountability

Assess whether the supplier has clear ownership for AI risk, product performance, security, data protection and incident response.

Questions include:

• Who is accountable for the AI-enabled service?
• How are new use cases and model changes approved?
• How are risks and incidents escalated?
• Which decisions remain with the supplier, model provider and buyer?
• Can the supplier demonstrate that policies affect product and operational decisions?
• What assurance applies to subcontractors and underlying model providers?

Positive evidence may include governance records, named accountable roles, model-change procedures, risk assessments, incident logs and examples of corrective action.

A polished responsible-AI policy is relevant. It is not evidence that the live product is managed responsibly.

2. Model, system and performance transparency

The buyer does not necessarily need access to source code or proprietary model weights. It does need enough transparency to understand the operating boundary and manage the service.

Ask:

• What model or models support the service?
• Has the supplier developed, fine-tuned, configured or only integrated them?
• What version is currently in production?
• What task was the system designed to perform?
• What representative tests have been conducted?
• Which performance metrics are used, and why are they appropriate?
• What known limitations, failure modes and foreseeable misuse exist?
• How does performance vary across languages, document types, user groups or operating conditions?
• What explainability or traceability is available to users and investigators?
• What triggers re-testing?

Performance evidence should be relevant to the buyer’s use case. A vendor benchmark showing strong general reasoning does not establish reliable clause identification across the organisation’s contract estate.

3. Data provenance, use and control

AI supplier due diligence should map data through the entire service.

Procurement should understand:

• the data used to train, fine-tune and evaluate the system;
• what the supplier can credibly disclose about provenance and limitations;
• customer inputs, prompts, documents and outputs;
• whether customer data is used for training, tuning, analytics or service improvement;
• retention periods and deletion mechanisms;
• data locations and transfers;
• access by supplier personnel and subprocessors;
• intellectual-property and confidentiality treatment;
• data-quality and representativeness requirements;
• whether synthetic or licensed data is used;
• how rights requests, investigations and legal holds are supported.

Procurement should avoid demanding impossible certainty. Some large models have complex training histories that cannot be reduced to a complete itemised list. The relevant question is whether the available information is sufficient for the intended use and risk—and what restrictions are required where uncertainty remains.

4. Bias, fairness and affected groups

A generic statement that a model is “unbiased” should be treated with caution. Performance and impact depend on the task, data, thresholds and context.

Due diligence should examine:

• which groups or situations may be affected;
• whether the supplier has tested relevant performance differences;
• which fairness measures were selected;
• what trade-offs were made;
• how the buyer’s own data and workflow may create new risks;
• how complaints, overrides and harmful outcomes are recorded;
• whether testing covers the intended geography and population;
• what remediation is available if outcomes become unacceptable.

The ICO recommends due diligence on expected bias and discrimination and warns against procuring services or datasets where harmful effects cannot be mitigated. The buyer should translate that principle into use-case-specific acceptance and monitoring criteria rather than rely on a supplier-wide ethical statement.

5. Security, resilience and dependency

AI introduces familiar software risks and additional attack surfaces. Depending on the service, those may include prompt injection, data exfiltration, insecure tool connections, model manipulation, poisoned data or unauthorised access to logs and generated content.

Assess:

• secure design and development practices;
• access control and privileged administration;
• encryption and secrets management;
• logging and monitoring;
• vulnerability disclosure and remediation;
• penetration, red-team or adversarial testing;
• prompt-injection and data-exfiltration controls where relevant;
• isolation between customers;
• model and dependency security;
• fallback arrangements and service degradation;
• incident communication;
• concentration risk and dependency on a single model or cloud provider.

The NCSC Software Security Code of Practice gives software customers a practical evidence route: request the supplier’s Assurance Principles and Claims documentation, test the claims, seek independent assurance where risk warrants it and continue requesting updates after award.

6. Human oversight and operational use

The supplier may provide the technical means for review, but the buyer must determine whether those controls are usable in its own process.

Questions include:

• Which outputs require human review?
• What information does the reviewer receive?
• Can the reviewer understand the source, confidence or limitation of the output?
• Can users override, reject or escalate it?
• Are reviews logged?
• What competence and authority must reviewers have?
• Does the product design create automation bias or superficial approval?
• Can the service be suspended without destabilising the wider process?

“Human in the loop” is not a control description. It is a label. Procurement should require an operational account of what the human does, when, using which evidence and with what authority.

7. Intellectual property and confidentiality

AI services can create uncertainty about inputs, outputs, training data and infringement claims.

Commercial review should consider:

• ownership and permitted use of customer inputs;
• ownership and permitted use of generated outputs;
• whether the supplier can reuse prompts or outputs;
• protection of confidential and commercially sensitive information;
• supplier warranties concerning rights to models, data and components;
• handling of third-party infringement claims;
• indemnity scope and exclusions;
• obligations to replace, modify or cease affected functionality;
• preservation of customer rights on termination;
• restrictions on using the buyer’s name, data or outcomes for model improvement or marketing.

The appropriate allocation depends on the service and negotiating position. Standard wording should not obscure the practical question: who bears the cost if the buyer can no longer use an important output or capability lawfully?

8. Operating capability, viability and exit

A technically strong AI feature can still create commercial dependency on a supplier that lacks the capability or incentives to support it reliably.

Assess:

• financial and operational viability;
• product roadmap and support model;
• reliance on upstream providers;
• capacity to investigate incidents and performance problems;
• availability of skilled personnel;
• portability of data, prompts, configurations, logs and evaluation records;
• transition support;
• deletion and certification;
• continuity if an underlying model is withdrawn;
• ability to use an alternative model or provider;
• treatment of customer-specific tuning or configuration on exit.

Exit planning should begin before award. Otherwise, the organisation discovers the real cost of dependency when leverage is weakest.

The objective is not to collect the largest possible document pack. It is to obtain decision-relevant evidence and record what remains uncertain.

Due diligence identifies the conditions on which the decision depends. Contracting should preserve those conditions and give the buyer a remedy when they change.

An AI contract does not need to become a technical manual. It should, however, allocate responsibilities and make the material supplier commitments enforceable.

1. Defined scope and permitted use

Specify the intended service, approved uses, prohibited uses, user population, data types and operating boundary. This reduces the risk that the system is later used for a materially different purpose without review.

2. System and value-chain disclosure

Require an accurate description of the AI-enabled service, underlying providers and material dependencies. The contract should state which information must remain current.

3. Data instructions and restrictions

Address data roles, permitted processing, retention, training or improvement use, access, transfers, deletion and support for investigations and rights requests.

4. Performance and acceptance

Define measures appropriate to the use case. These may include accuracy, error rates, false positives or negatives, robustness, latency, availability, correction rates or other task-specific outcomes.

Avoid guaranteeing an abstract level of “AI accuracy” without defining the population, method and threshold.

5. Documentation and evidence

Require the supplier to provide and maintain relevant technical, operational, risk and assurance documentation. The obligation should cover the evidence the buyer needs to operate the service safely, not merely documents the supplier already produces.

6. Human oversight and user support

Define the supplier’s responsibilities for user instructions, review features, training, traceability, escalation and safe suspension.

7. Security and incident response

Include security controls, vulnerability handling, notification timelines, cooperation, evidence preservation, remediation and service-continuity obligations.

8. Subprocessors and upstream providers

Control appointment and replacement of material subprocessors or model providers. The buyer may require notice, objection rights, equivalent obligations and continued supplier accountability.

9. Material model and service changes

This is one of the most important AI-specific controls.

The agreement should define a material change. Examples may include:

• replacement of the underlying model or model provider;
• significant model-version change;
• new training or use of customer data;
• change in hosting or processing location;
• new subprocessor;
• material change to performance or limitations;
• change to human-review or explainability features;
• change that affects legal role or regulatory classification;
• withdrawal of a safety, security or assurance control;
• change to pricing or dependency that affects the business case.

For material changes, the buyer may require advance notice, updated documentation, re-testing, approval, a remediation period, suspension rights or termination without disproportionate penalty.

Not every model update should require formal consent. That could make the service unmanageable. The contract should distinguish routine maintenance from changes that alter the buyer’s risk, obligation or expected outcome.

10. Audit, testing and assurance rights

Rights should be proportionate. Options include:

• access to existing independent reports;
• targeted information requests;
• customer or third-party testing;
• audit following an incident or material change;
• assurance against agreed standards;
• evidence of remediation;
• regulator cooperation.

Unlimited audit language may be commercially unrealistic. A tiered assurance model often produces better evidence with less friction.

11. Intellectual property, liability and insurance

Allocate rights and financial responsibility for relevant loss scenarios. The drafting should consider data misuse, confidentiality, infringement, discriminatory or inaccurate outcomes, regulatory breach, security incidents and failure to meet contractual performance.

Liability should align with actual exposure and available insurance, not simply repeat the supplier’s standard SaaS cap.

12. Suspension, termination and exit

Preserve the ability to act when the evidence no longer supports use. Address:

• emergency suspension;
• termination for unresolved material change;
• transition assistance;
• export of data, configurations, logs and records;
• deletion and certification;
• continuity during migration;
• customer-specific tuning or artefacts;
• post-termination confidentiality and audit support.

Legal counsel should adapt these controls to the transaction and applicable law. The framework identifies the commercial outcomes to protect; it is not a substitute for transaction-specific legal drafting.

AI supplier assurance often weakens precisely when dependency increases.

At award, the supplier provides its strongest documentation and senior attention. During operation, models change, subprocessors are added, vulnerabilities emerge, data drifts and users apply the system to a wider range of tasks.

A mature contract-management plan should monitor:

• model and version changes;
• upstream provider and subprocessor changes;
• security vulnerabilities and incidents;
• service performance and error patterns;
• bias or performance variation where relevant;
• data use and retention;
• user complaints, overrides and corrections;
• operation of human-review controls;
• regulatory or classification changes;
• audit findings and remediation;
• value, cost and continued suitability;
• evidence that contract commitments remain true.

Monitoring frequency should reflect risk and rate of change. A low-risk internal assistant may be reviewed through routine service management. A consequential system affecting people, access, safety or regulated decisions requires stronger and more frequent assurance.

The NCSC advises software customers to maintain ongoing assurance by requesting periodic security updates and checking that controls remain effective. The same principle applies more broadly to AI: due diligence is a current evidence position, not a permanent supplier attribute.

Termination is not only a commercial event. It is an AI governance event.

The buyer may need to preserve:

• decision and audit records;
• prompts and outputs relevant to business or legal obligations;
• model and version information;
• evaluation results;
• incident and correction records;
• customer-specific configurations;
• data lineage and processing evidence;
• documentation needed to explain past use.

At the same time, it may require the supplier to return or delete data, disable access, remove tuning artefacts and certify completion.

The transition plan should also address operational continuity. If users have embedded the capability into sourcing, contracting or supplier management, sudden withdrawal may create its own control and service risk.

The UK Government’s AI procurement guidance explicitly identifies end-of-life planning as part of responsible procurement. KOR’s view is that exit evidence should be specified at the beginning, not negotiated after trust has broken down.

A multinational procurement function wants to buy a platform that ingests supplier contracts, extracts clauses, summarises obligations and flags deviations from approved positions.

Initial supplier proposition

The supplier offers:

• rapid implementation;
• a proprietary contract model;
• standard security certification;
• claimed high accuracy;
• a conventional SaaS agreement;
• customer data excluded from general model training;
• quarterly product updates.

What discovery reveals

The value-chain review finds:

• the “proprietary” service uses a third-party general-purpose model for part of the workflow;
• a separate document-processing provider performs extraction;
• customer contracts are retained temporarily for troubleshooting;
• prompts and outputs are logged by the direct supplier;
• the underlying model provider may change without customer consent;
• performance testing used a curated English-language contract set;
• the buyer intends to deploy across several jurisdictions and contract types;
• the service will inform legal escalation but not make final legal decisions.

What evaluation should test

The buyer should require:

• testing on representative contracts, languages and clause types;
• separate reporting of extraction and interpretation errors;
• false-positive and false-negative analysis for priority risks;
• evidence of document segregation and access control;
• the data-flow and retention model;
• the supplier’s evaluation and model-change process;
• practical review and override features;
• logs sufficient to investigate a disputed output;
• supplier and subprocessor incident arrangements;
• continuity if the underlying model changes or becomes unavailable.

What the contract should protect

The agreement should address:

• approved data and use cases;
• restrictions on training and product-improvement use;
• retention and deletion;
• model and subprocessor disclosure;
• performance measures tied to agreed contract populations;
• review and traceability features;
• advance notice and re-testing for material model changes;
• incident cooperation and evidence preservation;
• continuing supplier accountability for upstream providers;
• transition support and export of relevant data and records.

The decision

The result may still be to buy the platform. Good due diligence is not designed to prevent AI procurement. It is designed to expose the conditions under which the purchase remains defensible.

The buyer may approve a bounded first deployment, limit the initial contract population, require stronger review for specific clause categories and make wider rollout conditional on verified performance.

That is controlled procurement—not risk avoidance.

Starting with the supplier’s product category

The fact that a supplier calls its product a copilot, assistant or intelligence platform tells the buyer little about the decision risk. Start with the use case and consequence.

Accepting certifications without checking scope

An assurance report may cover the supplier’s organisation but not the model, version, configuration, subprocessor or use case being purchased.

Asking for maximum transparency without a decision purpose

Demanding source code, model weights or complete training-data disclosure may be irrelevant, impractical or commercially impossible. Ask for the information needed to assess, operate, monitor and exit the specific service.

Treating standard contract clauses as control

A clause has little value if the buyer lacks the information, process or ownership needed to use it.

Focusing only on personal data

Data protection is central, but supplier AI risk may also concern confidentiality, IP, security, discrimination, operational resilience, inaccurate outputs, regulatory classification and commercial dependency.

Ignoring AI embedded in ordinary services

A supplier may use AI in service delivery even where the procurement was not labelled an AI procurement. Discovery questions should apply proportionately across relevant categories.

Completing due diligence only once

The evidence can become stale when models, providers, data, regulation or operating scope change.

Making the direct supplier responsible without testing its leverage

A supplier cannot meaningfully guarantee control over an upstream model provider if its own contract gives it no information, notice or remedy. Procurement should examine how obligations flow down the value chain.

The AI Readiness in Procurement overview explains why visible activity does not establish the organisational capability required for scale.

The Procurement AI Maturity Model treats supplier and third-party AI control as one of the capabilities that must strengthen before the function can claim controlled or adaptive scale.

The Readiness–Realisation Matrix asks whether supplier dependencies and controls are strong enough for the intended deployment boundary.

The Evidence Confidence Model distinguishes supplier assertions from substantiated documentation and verified operating evidence.

The Procurement AI Adoption Model tests whether employees can use and challenge the procured capability within the approved workflow.

The forthcoming value-realisation article will examine whether the complete cost of supplier assurance, integration, change and operation has been included in the business case.

Together, these models prevent a familiar procurement error: treating the successful purchase of technology as evidence that the organisation is ready to depend on it.

Procurement will rarely have complete certainty about an AI system. Models are complex, supply chains are layered and technology changes quickly.

The objective is not perfect transparency or zero risk.

It is to preserve three practical capabilities:

1. The right to understand — enough information and evidence to assess how the service works, where its boundaries sit and who controls the important dependencies.
2. The right to intervene — meaningful notice, monitoring, review, suspension and remediation when performance, risk or obligations change.
3. The right to leave — workable transition, data control and continuity when the evidence no longer supports continued use.

A supplier questionnaire cannot create those rights on its own. A contract cannot compensate for a poorly defined use case. Monitoring cannot work without evidence, ownership and escalation.

AI supplier due diligence is therefore not a specialist check added near contract signature. It is a lifecycle discipline connecting procurement strategy, technical assurance, risk, legal drafting, contract management and operational adoption.

The leadership question is not simply:

Has the supplier answered our AI questionnaire?

It is:

Do we understand the AI value chain, have evidence proportionate to the decision, and retain enough contractual and operational control to respond when the system changes?

That is the difference between buying AI and procuring it responsibly.

What is AI supplier due diligence?

AI supplier due diligence is the process of assessing the organisations, models, data, infrastructure, controls and dependencies behind an AI-enabled product or service. It should test whether supplier claims are supported by evidence and whether the buyer can govern the capability throughout its lifecycle.

What should procurement ask an AI supplier?

Procurement should ask about the intended use, underlying models, data flows, training and evaluation, performance limitations, bias, security, human oversight, subprocessors, material changes, incident handling, intellectual property, monitoring and exit. The questions should be proportionate to the use case and consequence of error.

Are standard SaaS contracts sufficient for AI?

Sometimes they provide a useful baseline, but they may not address model providers, customer-data use, evaluation evidence, material model changes, AI-specific performance, human oversight or the information needed to investigate incidents. The gap depends on the service and risk.

Does an AI buyer need access to the supplier’s source code?

Usually not. Buyers need enough transparency to assess, use, monitor and exit the service. That may be provided through architecture, model and system documentation, evaluation results, logs, assurance reports and contractual information rights rather than source-code access.

What is a material model change?

A material model change is one that alters the buyer’s risk, obligations, performance expectation or dependency. It may include replacing the underlying model, changing data use, adding a material subprocessor, changing hosting, removing a control or altering system performance or limitations.

How often should AI supplier due diligence be repeated?

The frequency should reflect risk and rate of change. Reassessment should also be triggered by material model or supplier changes, incidents, significant performance deterioration, expansion into new use cases or jurisdictions, or regulatory change.

Is this framework legal advice?

No. It is a procurement and governance framework. Contract language and legal obligations should be reviewed by appropriate counsel in light of the specific transaction, jurisdiction and AI system role.

What is AI supplier due diligence?

AI supplier due diligence is the structured assessment of a third-party AI provider before and during a contract. It tests whether the supplier, system, model, data practices and delivery chain are suitable for the intended use and whether the buyer can maintain appropriate control.

Is AI vendor due diligence different from conventional software due diligence?

Yes. Conventional security, privacy, resilience and financial checks remain necessary, but AI introduces additional questions about model provenance, training and customer-data use, variable performance, bias, human oversight, model changes, auditability and the wider AI value chain.

What evidence should procurement request from an AI supplier?

The evidence should be proportionate to the use case and may include system and model documentation, data-flow and retention information, evaluation results, known limitations, security and resilience assurance, subprocessor details, incident records, human-oversight design and evidence supporting regulatory or certification claims.

Which AI contract clauses are most important?

Important controls usually include defined permitted use, data-use restrictions, model and subprocessor transparency, performance and testing obligations, human-oversight responsibilities, incident notification, audit and information rights, material-change control, intellectual-property allocation, remediation, termination and exit assistance.

How often should an AI supplier be reassessed?

Reassessment should occur on a risk-based cycle and whenever there is a material trigger, such as a model or provider change, new data use, expanded scope, serious incident, regulatory change, deteriorating performance or contract renewal.

Is an ISO/IEC 42001 certificate enough to approve an AI supplier?

No. Certification may provide useful evidence about the supplier’s AI management system, but it does not establish that a particular product is suitable for the buyer’s use case, performs adequately on the buyer’s data or contains the necessary contractual protections.

Who should own AI supplier due diligence?

Procurement should coordinate the commercial process, but accountability is multidisciplinary. The business owner, legal, privacy, security, technology, risk and relevant control functions should contribute according to the use case and the consequences of failure.