When AI Vendor Due Diligence Applies and What to Do Next

AI vendor due diligence should start before a supplier's AI service receives meaningful data, connects to business systems, or influences consequential decisions. Repeat the relevant checks when its purpose, permissions, data handling, or service changes. Your next step is to define the intended use, assign an accountable owner, and collect evidence for a scoped approval decision.

For SaaS teams, this review connects purchasing with product, security, privacy, and operational decisions. The recommendations below describe a practical workflow, not a universal statutory questionnaire. The depth of review should reflect what could go wrong and who could be affected. An assistant drafting public help text needs a different assessment from an agent modifying customer accounts.

Recognise the triggers

Start at the point where the team can still change suppliers, narrow the use, or negotiate terms. Waiting until contract signature or launch makes unresolved questions harder to address. Include free trials, employee subscriptions, APIs, embedded models, and AI features activated inside an existing platform.

Use these events to open or reopen a review:

• New purchase: a team proposes an AI service or integration.
• New capability: an existing supplier adds an assistant, retrieval feature, or automated action.
• Expanded data: a pilot moves from synthetic examples to customer records or confidential documents.
• Expanded authority: a tool moves from suggesting actions to executing them.
• Material change: model routing, hosting, retention, terms, or subcontractors change in a way relevant to the approval.
• Adverse evidence: an incident, complaint, or failed evaluation challenges an assumption supporting continued use.

A renewal is a useful checkpoint, but it should not be the only trigger. Give someone responsibility for receiving service notices and connecting them to the deployment record. A supplier relationship may remain unchanged while the actual risk changes substantially.

Decide which checks apply

Write one sentence describing the task, users, data, and action boundary. For example: “Support employees use the enterprise workspace to draft answers from public documentation; employees send replies; customer tickets are excluded.” Record the purchased tier and configuration as well as the vendor name.

Then identify the relevant review tracks. Privacy reviewers assess personal-data processing; security reviewers assess access and integrations; product owners assess output quality and failure consequences; legal reviewers assess applicable obligations and contractual allocation. Procurement coordinates the evidence and commercial process. In a small company, one person may hold several roles, but each decision still needs a named owner.

Where GDPR applies, Article 28 requires sufficient guarantees from processors. GDPR, Article 28. Ask your privacy reviewer to establish the parties' roles and the processing arrangement before treating a vendor's standard agreement as sufficient.

For AI Act scoping, ask legal reviewers to identify the relevant role, intended purpose, provisions, and application dates. A supplier's general compliance statement does not answer those deployment-specific questions. Record the rationale and unresolved issues rather than copying a marketing claim into your approval.

As checked on 10 September 2026, the high-risk milestones are 2 December 2027 for Annex III and 2 August 2028 for Annex I. European Commission timetable update. Check the provisions relevant to your use separately before deciding what must happen now.

When a narrower review is reasonable

If a product has no AI functionality, the ordinary supplier process may be enough. If a tool handles only public material and cannot access systems or take actions, a shorter AI assessment may be proportionate. Record those boundaries explicitly and confirm that the configuration enforces them.

No personal data does not automatically mean no review. Confidentiality, intellectual property, reliability, business continuity, and customer commitments may still matter. Conversely, the presence of AI does not justify requesting every document from every supplier. Ask for evidence that addresses a specific decision, and explain why a check is inapplicable.

A pilot is a way to gather evidence within an agreed boundary. It is not automatic permission to upload production records. Define the pilot's data, users, integrations, duration, and stop conditions before giving access. Decide who can authorise expansion after the results are reviewed.

Follow a six-step decision workflow

1. Create the use record

Capture the task, service, tier, users, data categories, locations, integrations, and allowed actions. Name the business owner and technical owner. Link to the architecture or data-flow sketch and list explicitly excluded uses. This record becomes the common reference for specialist reviewers.

Separate the intended deployment from possible future features. If the team hopes to automate refunds later, record that as a future change requiring review. Do not let a broad product roadmap silently expand the current approval.

2. Trace data and access

Ask what happens to prompts, attachments, retrieved material, outputs, feedback, and logs. Establish retention, deletion, support access, onward recipients, and whether information is used for training. Match the answers to the exact service tier and settings you intend to use.

For connected services, record credentials and permissions. Prefer the minimum access needed for the task, then test the boundary. A read-only description in a procurement form is not enough if the integration actually receives write permissions. Retain a configuration export or equivalent evidence with the review.

3. Match claims to evidence

Use a short evidence table: claim, supporting document or test, scope, date, reviewer, and remaining gap. A security report may support security controls within its stated scope; a contract supports agreed commitments; a test supports observed behaviour under recorded conditions. Keep these distinctions visible.

Request follow-up where a document excludes the AI feature or covers a different environment. If evidence is unavailable, record the uncertainty and its effect on the decision. A supplier's size, reputation, or polished demonstration should not close an unanswered question.

4. Test the actual workflow

Choose acceptance criteria before testing. Include representative tasks, incomplete information, misleading inputs, permission boundaries, and recovery after failure. Use synthetic or otherwise authorised data. Record the service version where available, settings, date, results, and unresolved failures.

Test human review too. Can the reviewer inspect the supporting material, reject an incorrect suggestion, and stop an action in time? If not, change the workflow or narrow the capability. A high average quality score should not conceal a failure that exposes another customer's information.

5. Make an explicit decision

Choose an outcome: approve within scope, approve with conditions, restrict to a pilot, escalate, or reject. State which conditions block production and which are follow-up improvements. Assign every condition an owner, deadline, and required completion evidence.

Record residual risks and any authorised exception with its rationale and expiry. Contract signature should not silently override a technical or privacy blocker. Ensure the person enabling the integration can understand the decision without reconstructing discussions across email and chat.

6. Monitor and prepare an exit

Set a review date based on the use and its risks, alongside the event triggers above. Assign responsibility for notices, incidents, complaints, and evaluation results. Reopen only the affected checks when that is justified, retaining the earlier decision history.

Describe how to revoke access, remove integrations, export needed records, request deletion, and continue the task during an outage or exit. Exercise the critical steps before relying on them. Reusable records can also reduce the duplication discussed in our guide to manual vendor risk reviews.

Example: an assistant starts reading private tickets

Imagine a support team already uses an assistant to draft responses from public documentation. Product now wants to retrieve private tickets. The supplier and subscription remain the same, but the data boundary changes. That change should trigger review before the feature is enabled.

The owner updates the use record. Privacy checks the processing arrangement; security tests ticket permissions and cross-customer separation; product tests whether answers expose unnecessary information. Procurement confirms that the relevant commitments cover the new feature. The team keeps the original drafting use while these checks run.

If retrieval permissions fail, the new capability stays blocked. If the checks pass, approval records the allowed data, settings, test results, oversight, and reopening triggers. This is an illustrative decision process, not a conclusion that a particular deployment satisfies every applicable law.

Common mistakes to avoid

Approving a company name rather than a defined use makes later changes invisible. Collecting a large document bundle without recording findings creates storage rather than evidence. Calling a pilot “low risk” without limiting its data or permissions leaves the important question unanswered.

Another mistake is assigning every action to “compliance.” The business owner must explain the task and accept operational responsibility; engineering must verify controls; specialists must make decisions within their expertise. A coordinator can keep the process moving without becoming the owner of every risk.

FAQ

What is the practical purpose of this review?

To decide whether a particular service can be used for a defined task, with supporting evidence, conditions, and accountable owners. The output should tell a team what it can enable and what remains restricted.

What should a founder document first?

The intended task, data, permissions, and owner. Those facts make the next questions specific. Start with one meaningful use instead of distributing an undifferentiated questionnaire across the company.

Must every change restart the entire assessment?

No. Assess the change against the recorded assumptions and reopen the relevant checks. Keep the rationale when a change has no material effect. Escalate when the implications are unclear.

What should happen next week?

Select one proposed or live AI service. Write its use record, identify the largest evidence gap, and assign a reviewer. Agree a bounded decision and record the next trigger before expanding access.

Sources and image credit

Legal references were checked on 10 September 2026. Linked sources support the specific legal and timetable statements; the workflow and example are editorial recommendations.

Photo: Team Meeting, woodleywonderworks, CC BY 2.0. Resized to 1280 × 482 pixels. Illustrative photograph.