Common AI Vendor Due Diligence Mistakes SaaS Teams Still Make

The most damaging AI vendor due diligence mistakes are approving an undefined use, accepting assurances without evidence, overlooking data flows, and letting approval survive material changes. Review the service, configuration, and intended task together. Record what you tested, what remains uncertain, who accepts the risk, and which changes reopen the decision.

For founders and compliance leads, the practical purpose is to make a defensible purchasing and deployment decision. A completed questionnaire cannot tell engineering which integrations are permitted or tell an account manager which customer promises are supported. A useful review connects those decisions to evidence and named owners.

The recommendations below are an operational approach, not a mandatory questionnaire or a certification. Scale them to the consequences of failure. A tool summarising public documentation and an agent changing customer permissions should not pass through an identical approval process.

When this review matters

Run the review before introducing customer data, connecting internal systems, or committing to a production launch. Include AI features added to existing suppliers: an approved collaboration platform does not automatically have approval to analyse every document using a newly enabled assistant.

Repeat relevant checks when the purpose, model routing, data categories, access permissions, contract, or human oversight changes. If a product has no AI functionality, ordinary vendor review may be sufficient. If personal data is absent, some privacy checks may be inapplicable, but confidentiality, security, reliability, and exit planning can still matter. Explain every exclusion.

1. Approving the vendor instead of the use

“Vendor approved” conceals the boundary that matters. The same supplier may offer a consumer account, an enterprise workspace, and an API with different controls. A successful evaluation of one tier does not establish that another is suitable for confidential product information.

Write the approval around a task: “Draft support replies using approved help articles; employees check every reply; no account changes.” Include the product tier, environment, users, allowed data, integrations, and excluded uses. Give the business owner and technical owner separate responsibilities.

Before buying, ask an engineer who did not attend the sales calls to explain the permitted configuration from the record. If they cannot, the scope is still too vague. Resolve that ambiguity before procurement treats a signed order as permission to deploy.

2. Treating assurance documents as universal proof

A security report can support particular claims within its scope and reporting period. It does not establish whether an AI service produces reliable answers, respects your retrieval permissions, or meets your contractual needs. An impressive demonstration answers even fewer of those questions.

Match each important claim to evidence: the relevant report section, a contractual commitment, a configuration export, or a reproducible test. Record exceptions and the date reviewed. Check that the evidence covers the product you will actually use, including the AI feature and relevant hosting environment.

Ask follow-up questions where coverage is unclear. If a vendor declines to provide evidence, retain the gap and its consequence for approval. Confidentiality may justify controlled access to a report; it does not transform an unverified statement into a completed check. Consider a restricted pilot or another supplier when uncertainty is material.

3. Confusing training restrictions with complete data protection

“We do not train on customer data” leaves important questions unanswered. Trace prompts, attachments, retrieved documents, outputs, feedback, and logs separately. Establish retention, deletion, human access, processing locations, and onward recipients for each relevant category. Check whether optional feedback or support workflows change the arrangement.

For processing subject to GDPR, Article 28 requires sufficient processor guarantees and appropriate contractual terms. Article 35 requires a DPIA where processing is likely to create high risk to individuals. These duties turn on the processing, not the AI label. GDPR, Articles 28 and 35.

Have privacy reviewers assess roles, lawful basis, notices, and relevant international transfers. Give technical owners responsibility for confirming settings. Test deletion using authorised sample data and document any retained copies or exclusions. A signed processing agreement and a verified configuration answer different questions; retain both in the approval record.

4. Accepting an undifferentiated AI Act compliance claim

A vendor's “AI Act compliant” statement needs an explanation of the role, system, purpose, provisions, and application dates it covers. Ask your reviewer to document your own position too. A model supplier's responsibilities do not automatically describe the responsibilities of the business integrating its service.

Check classification and value-chain responsibilities against the current legislation, including Articles 3, 6, and 25. Review prohibited practices and transparency requirements separately. Ask for a provision-specific assessment when branding, modification, or a changed intended purpose could affect the analysis. AI Act, consolidated text.

As checked on 10 September 2026, the amended timetable places the main Annex III high-risk rules at 2 December 2027 and the Annex I product-related high-risk rules at 2 August 2028. Those extensions do not postpone every obligation. Record the provisions and transitions relevant to your use. European Commission: AI Omnibus enters into force.

5. Testing a demonstration instead of your workflow

A polished demonstration rarely contains your awkward documents, conflicting instructions, unsupported languages, or permission boundaries. Define acceptance criteria before testing. Use synthetic or otherwise authorised material that reflects the task, including cases where the right outcome is to decline or escalate.

For a retrieval assistant, test whether a user can obtain documents they should not access. For an agent, test whether untrusted content can redirect actions and whether permissions limit the damage. Include incomplete inputs, plausible errors, and recovery after interruption. Record the model or service version where available, settings, date, and results.

Give serious failures a clear disposition: block launch, remove the capability, restrict the pilot, or require remediation and retesting. An average quality score should not hide a failure that exposes another customer's information. Ask the business owner to agree which outcomes are unacceptable before discussing how impressive the successful answers look.

6. Naming a human reviewer without making review workable

“Human in the loop” is not a complete control description. The reviewer needs enough information, time, authority, and access to challenge the output. If a support employee must approve dozens of suggestions in seconds, an approval button may add little practical scrutiny.

Specify what the person checks, which source material they can inspect, how they reject an output, and when they escalate. Test the review process with incorrect suggestions. Confirm that the person can prevent an action before it happens and that the fallback does not depend on the same unreliable output.

Keep evidence of the exercise and adjust staffing or product design when the process fails. Measure overrides and recurring errors to identify problems, while avoiding incentives that discourage reviewers from rejecting suggestions. Treat oversight as part of the workflow design, with an accountable owner.

7. Leaving contracts disconnected from settings and incidents

Sales promises, signed terms, and the deployed configuration can describe different arrangements. Compare the purchased tier with commitments on permitted use, confidentiality, retention, training, incident cooperation, changes, and termination. Check rights and restrictions concerning inputs and outputs without assuming ownership from marketing language.

For every important configurable promise, record the setting, who controls it, and how changes are detected. For incident support, identify a usable contact and the information you need to investigate: affected services, relevant logs, timing, containment steps, and follow-up. Negotiate cooperation appropriate to your own obligations and customer commitments.

Separate commercial preferences from conditions that must be met before production access. An unresolved data-handling condition should not become a routine follow-up item simply because the launch date is close. Record any accepted exception, its rationale, the authorised approver, and its expiry.

8. Allowing approval to outlive its assumptions

A review becomes stale when a drafting tool starts sending messages or a read-only assistant gains write access. Renewal alone is a poor trigger for these changes. Assign an owner to monitor service notices, incidents, complaints, evaluation failures, and expanded use.

Maintain explicit reopening triggers and connect them to engineering change management. Keep the approval history so a reviewer can see which configuration was accepted and why. Test how to revoke credentials, remove integrations, export necessary records, request deletion, and continue the business task during an outage or exit.

NIST's voluntary AI RMF uses Govern, Map, Measure, and Manage to organise continuing risk work. It can structure your process without certifying legal compliance. NIST AI RMF Core. Reusable evidence also helps reduce the duplication described in our article on manual vendor risk reviews.

A repair workflow for an existing approval

Start with one live AI service that handles meaningful data or permissions. Do not launch a company-wide questionnaire exercise before proving the process on that service.

1. Reconstruct the scope. Record the task, tier, data, integrations, owners, and current permissions. Compare these with the original approval.
2. Identify unsupported assumptions. Mark missing evidence, untested controls, unexplained exclusions, and changes that escaped review.
3. Contain material gaps. Restrict data or capabilities while specialists assess the issue. Assign each action an owner and deadline.
4. Make an explicit decision. Approve within scope, approve with conditions, restrict the pilot, escalate, or reject. State which conditions block production use.
5. Schedule follow-through. Record the next review date and change triggers. Verify completion using evidence rather than closing tasks on verbal assurance.

Keep a compact decision record containing evidence links, findings, residual risks, accepted exceptions, and the approving person's name. A colleague should be able to understand the decision without reconstructing a chain of chat messages. Reuse that record for customer and investor questions, with appropriate access controls.

Example: a support assistant gains refund permissions

Imagine a SaaS team approved a supplier to draft responses from public help articles. Three months later, product enables retrieval from private tickets and lets the assistant initiate refunds. The vendor is unchanged, but the approved data boundary and action boundary have both moved.

The team should reopen the review before enabling those capabilities. It could retain drafting while checking ticket access, log retention, refund authorisation, misuse scenarios, and recovery. A limited pilot might use synthetic tickets and simulated refunds while the outstanding questions are resolved.

Approval would then describe the accepted permissions, test evidence, human checks, and remaining restrictions. If the refund authorisation test fails, a strong drafting score would not justify enabling payments. This example illustrates a decision process; it does not establish that a particular support or payment use is legally permitted.

FAQ

What is the biggest mistake?

Treating approval as a permanent property of a supplier. Approve a defined use with evidence, conditions, owners, and reopening triggers. Keep the record aligned with the deployment.

Does a small vendor require automatic rejection?

No. Assess the evidence and risks of the intended service. Alternative evidence or a narrower use may be acceptable. Record unresolved uncertainty instead of treating size or reputation as a substitute for review.

What should a founder document first?

The actual task, allowed data, permissions, and accountable owner. These facts let security, privacy, legal, and product reviewers ask relevant questions instead of requesting a generic document bundle.

When can the team proceed despite missing information?

Only within an explicitly approved scope whose conditions address the gap. A restricted pilot can help gather evidence, but calling something a pilot does not make sensitive processing or broad permissions acceptable. Escalate unresolved launch blockers to the authorised decision-maker.

Sources and image credit

Legal references were checked on 10 September 2026. The linked GDPR provisions, consolidated AI Act, Commission timetable update, and NIST framework support the specific references above. The operational examples and recommended workflow are editorial guidance.

Photo: Team Meeting, woodleywonderworks, CC BY 2.0. Wikimedia thumbnail resized to 1280 × 482 pixels. The photograph illustrates collaboration and does not depict an AI vendor review.