AI vendor due diligence checklist

The problem and the proposal

The proposal describes the specific business problem or workflow it addresses, not only the technology being sold.
The vendor explained how it will scope the work, such as a discovery conversation or a paid audit, before recommending a solution.
The proposal names the workflow in scope, the systems involved and the people who will use the result.
The vendor was willing to say when AI is not the right answer for part of the problem.

Delivery evidence and team

The vendor described a comparable engagement in enough detail to be checked, or explained why none exists yet.
We have at least one reference we can call, including an anonymized one if needed.
The proposal names the people who will do the work and how much of their time is committed.
The vendor explained how specialists are brought in for work that falls outside the skills of the core team.

Data handling, security and access

The proposal states where our data will be processed and stored.
We know how long our data and any outputs will be retained, and when each is deleted.
The vendor has told us in writing whether our data will be used to train any model.
The proposal names every subprocessor or third party service that will handle our data.
Access for the vendor team follows least privilege, with no shared administrator accounts.
We know how and when we will be notified if a security incident affects our data.

Integration with your systems

The vendor has checked which of our systems have APIs or supported integration options, rather than assuming it.
The proposal names who administers each system we need to connect, and confirms they can grant access.
The vendor has asked to see real data or documents from our own systems, not only samples.
We know what happens if a required integration turns out to be unavailable on our current license.

Human oversight and testing

The proposal names the points where a named person approves or reviews output before it takes effect.
The vendor explained how it will test the system against our own real cases before launch.
We have agreed, in writing, what counts as correct for each task the system performs.
The proposal names who owns the exception queue when the system is unsure.

Commercial terms

The proposal states exactly what is included in the build price.
Running and usage costs, such as hosting and model fees, are quoted separately from the build.
We know the process for requesting a change and how it affects cost and timeline.
The contract states who owns the code, the cloud accounts and the documentation once the engagement ends.
We know what happens to our data and our accounts if we leave this vendor.

Support after launch

The proposal states what support is included after launch and what is excluded.
We know who responds when something breaks, and within what time.
Monitoring and model or dependency updates are scoped and priced, not assumed to be included.
We know the plan for what happens when the underlying AI model is retired or changed.

If several sections have gaps, a discovery call with Kastling is a no commitment way to talk through what to ask a shortlisted vendor next. Bring the checklist and the proposal, and we can walk through how we would answer the same questions.

See results