AI-Specific Due Diligence for Third-Party Software

Art Richards, Berlin
4 hours ago
6 min read

AI-specific due diligence adds AI questions to the standard vendor review. It checks how an AI feature works, what data it uses, which systems and suppliers it depends on, and how the organization plans to use it.

The review connects four records: the vendor, the software, the AI feature, and its intended use. One product may contain several AI features, and the same feature may carry different risks in different business processes.

Standard vendor reviews may not cover AI

Security, privacy, financial, and operational reviews remain essential. However, a review completed when software was first purchased may not cover an AI feature added later. It may also miss a new model, connector, data-processing location, or terms governing the use of customer data.

In an April 2026 review of Validaitor's curated enterprise-software library, 76% of products contained detected AI features. The library focuses on enterprise software, so this is not an estimate for all software. The finding is based on vendor product, security, and data-handling documents linked in the library.

Approved software can therefore contain an AI feature that has not been assessed. AI-specific due diligence can address this gap during procurement or as part of a review of software already in use.

The depth of the review should match the use. An assistant that summarizes public material does not need the same controls as one that reads employee files, connects to business systems, or supports an important decision.

The AI feature and intended use define the review

An application-level statement that a product “uses AI” does not support a risk decision.

The review should record:

the AI feature, version, and stated purpose;
who can use it and through which account type;
the task it will perform and the outputs it will produce;
the business, personal, or sensitive data it may process;
the files, systems, connectors, and actions it can access;
the people or business processes its output may affect; and
the business owner for the proposed use.

Separate use records are needed when the same feature supports different work. A document assistant summarizing a public report presents a different risk from the same assistant reviewing employment files.

This distinction also matters under the EU AI Act. An organization using a vendor's AI system under its authority is generally the deployer, while the vendor is generally the provider. The rules depend on the feature and how it is used, not only on the software product.

Six areas cover the main AI-specific questions

Review area	Questions to answer
Use and impact	What will the feature do? Who will use it or be affected? What could happen if its output is wrong or unsuitable?
Data handling	What data will it receive? Where is the data processed and stored? How long is it kept? Can the vendor use it for training or improvement? Can that use be turned off?
Models and suppliers	Which model, external AI service, hosting provider, or other supplier is involved? What data is shared with them? How are changes reported?
Access and actions	Which files, systems, and connectors can it access? What actions can it take? Are approval steps in place, and can actions be reversed?
Performance and oversight	What are the known limits? How will outputs be tested and checked? Who monitors the feature and handles problems?
Legal position and records	What is the stated purpose and legal classification? What instructions, logs, test results, version records, and incident-reporting process are available?

These questions show where the vendor's responsibility ends and where the organization must add its own controls. For example, a vendor may offer regional processing and a commitment not to train on customer data. The organization still needs to confirm that the correct account and settings are in use and define which data employees may submit.

Risk assessment serves a different purpose

AI-specific questions, above, collect the facts needed for a review.

Risk assessment uses those facts to judge what could go wrong, how serious the effect could be, and how likely it is.

	AI-specific questions	Risk assessment
Purpose	Establish how the feature works and how the organization will use it.	Evaluate the exposure created by the feature and its use.
Method	Ask about data, models, suppliers, access, actions, performance, oversight, and legal records.	Assess each risk using the evidence, business context, current controls, impact, and likelihood.
Output	Documented facts, supporting sources, and open questions.	Risk ratings, required controls, remaining risk, and a use decision.

An answer to an AI-specific question is an input to the risk assessment, not the risk conclusion. For example, confirming that a feature sends data to an external model provider establishes a fact. The resulting risk depends on which data is shared, the provider's terms and controls, the business purpose, and the possible effect of unauthorized access or use.

Evidence supports the assessment

The review should separate documented facts from assumptions and open questions. Useful evidence includes:

AI terms, contracts, and data processing agreements;
privacy, security, trust, and compliance documents;
product, administrator, and support documents;
model or system cards, test results, and known limitations;
supplier, hosting, and processing-location information; and
release notes, version history, incident-reporting processes, and change notices.

Each important conclusion should link to its source. The record should identify the relevant product version, account type, region, and review date. A product page may confirm that an AI feature exists, but the contract or administrator guide may be needed to confirm how customer data is used.

Eight AI risks require specific assessment

AI features create different types of risk. Each one needs evidence and controls that match the way the feature works and is used.

Unauthorized use of customer data. The vendor or model provider may use prompts, files, or outputs for training, product improvement, or another purpose that the organization has not approved.
Data shared with other suppliers. Inputs or outputs may pass to model providers, hosting services, or other companies without sufficient visibility or control.
Data kept for too long. Prompts, files, outputs, or chat histories may remain stored beyond the period the organization requires.
Data processed in the wrong region. AI data may be stored or processed outside the required country or region.
Incorrect output used in a decision. Inaccurate or misleading output may influence decisions about people, operations, finance, safety, or compliance.
Too much access to business systems. The AI feature may have wider access to files, records, connectors, or actions than its task requires.
Harmful or toxic content. The feature may generate or expose users to discriminatory, offensive, unsafe, or otherwise harmful material.
Prompt injection and input manipulation. Malicious or untrusted content may alter the AI's instructions, expose data, or cause unintended actions.

Each risk needs its own assessment. Data-location risk depends on hosting, contracts, and settings. Incorrect-output risk depends on the task, its effect, and the checks applied. Prompt-injection risk depends on what the feature can receive, access, and do.

Impact and likelihood should be assessed separately. The current risk score should remain separate from proposed treatments. A contract clause, setting, or approval step reduces the recorded risk only after an owner confirms that it has been put in place.

The review ends in a recorded use decision

The review should end with one of four recorded outcomes:

Approved: the evidence and current controls support the use.
Approved with controls: the use can start after named controls are in place.
Restricted pending evidence: only limited use is allowed while important questions remain open.
Not approved: the risk cannot be reduced to an acceptable level for this use.

Controls may include enterprise accounts, regional processing, retention limits, rules for sensitive data, restricted connectors, output checks, human approval, contract terms, employee guidance, and incident procedures.

The record should name the person who approved the use, the owner of each control, and the person who accepted the remaining risk.

Changes to the product or use trigger reassessment

AI due diligence is not a one-time task. The decision should be reviewed when there is:

a new or automatically activated AI feature;
a different model, supplier, or processing location;
a new connector, permission, or automated action;
a change to training, retention, deletion, or customer-data terms;
a new team, purpose, source of data, or affected group;
use in employment, credit, safety, or another important decision; or
a serious incident, control failure, performance problem, or regulatory change.

Not every change requires a full vendor review. The changed information should go to the owner of the earlier decision, who can keep the decision, update the controls, restrict the use, or suspend it.

How Validaitor supports AI-specific due diligence

Validaitor helps organizations find AI features in their software, match products to source-linked vendor information, assess common AI risks, and assign treatments to named owners. The result is a clear path from software discovery to a documented decision and ongoing review.

For a review of the AI features across your third-party software estate, talk to us.

Review your third-party AI estate