How to choose an AI vendor: the questions to ask before you sign

Most organisations at your scale have already had the first AI conversation. Some have run a pilot. A few have signed a contract. Almost none have done adequate due diligence before committing.

The mistake is understandable. AI vendors are well-funded, well-rehearsed and very good at demonstrations. The demos work. The case studies sound relevant. The pricing looks manageable. So the deal moves forward on enthusiasm rather than scrutiny.

What gets missed is not technical. It is commercial and operational: who owns the outputs, what happens to your data, how does this actually integrate with your existing systems, and what does the vendor look like eighteen months in when the implementation team has moved on?

This article gives you a structured set of questions to ask before you sign any AI vendor contract - covering data governance, integration, commercial terms, vendor stability and the internal capabilities you need to make any of it work. Use it as a checklist and as a negotiating frame.

Start with data: who owns what, and where does it go

Before you evaluate any capability, you need to understand what the vendor intends to do with your data. This is not a legal formality. It is a strategic question.

Some AI vendors - particularly those offering SaaS-based tools built on large language models - use customer data to improve their models. That may be acceptable in some contexts. It is rarely acceptable when the data includes customer transaction records, pricing logic, margin data or any information that would constitute a competitive advantage.

Ask these questions directly, and get written answers:

1. Will our data be used to train or fine-tune any model, whether proprietary or third-party?
2. Where is our data stored, and in which jurisdictions?
3. What is the data retention policy, and what happens to our data if we terminate the contract?
4. Who has access to our data within your organisation, and under what controls?
5. How do you handle a data breach, and what are your contractual obligations to notify us?

A mid-market retailer we worked with discovered, mid-negotiation, that their prospective AI vendor's standard terms allowed model training on client data unless the client had explicitly opted out - a clause buried in a third-party data processing addendum. They nearly missed it. Their legal team had been reviewing the master services agreement, not the addendum.

Read the full contract stack, not just the headline document.

Integration: the question vendors would rather you did not ask

Vendors will show you their integrations page. It lists every platform they connect to. It tells you almost nothing useful.

What matters is not whether a connector exists. It is how that connector works, what it requires of your team to maintain, and what breaks when your source systems change - which they will.

Ask:

1. Is this a native integration or a middleware dependency? If middleware, who manages it?
2. What are the data latency characteristics? Is this real-time, near-real-time or batch?
3. What happens when our upstream system changes schema or version? What is the remediation process and who owns it?
4. What does the implementation require from our internal team, and for how long?

That last question exposes more than vendors intend. A vendor who says implementation takes two weeks for a complex enterprise environment is either oversimplifying or has not done this at your scale before. A vendor who says it depends and then gives you a specific list of dependencies is telling you the truth.

A logistics business we advised was mid-implementation when their ERP vendor released a major update. The AI platform they had contracted had no formal process for schema changes. Three months of integration work had to be partially rebuilt. The cost was not in the contract.

Ask about the failure modes, not just the features.

Commercial terms: what the standard contract does not protect you from

The headline price is rarely where the risk lives. It is in the renewal mechanics, the usage-based overage clauses and the exit provisions.

Scrutinise three areas specifically.

Pricing structure. Is this per-seat, per-query, per-API-call or some combination? Usage-based pricing is common in AI tooling and can scale in ways that are difficult to forecast. A financial services firm that benchmarked at 50,000 queries per month during a pilot may be running 2 million per month eighteen months into production. That is not a hypothetical - it is a pattern we see regularly. Model the upper-bound scenario, not the expected case.

Lock-in mechanics. Does the vendor's system store data in a proprietary format? Are your trained models, your fine-tuned parameters or your configured workflows portable if you leave? If the answer is no, you are not buying software - you are renting access to your own institutional knowledge.

SLA teeth. Service level agreements mean nothing without remedies. An SLA that offers service credits worth 5% of monthly fees is not a meaningful incentive for a vendor to maintain uptime. Ask what the remedies are, whether they are capped and whether they cover consequential losses.

Vendor stability: the question that feels rude to ask

You need to ask it anyway.

The AI vendor landscape is contracting. Companies that raised at 2021 valuations on 2021 growth assumptions are facing difficult renewals with their own investors. Some will be acquired. Some will pivot. Some will wind down.

If you are embedding a vendor's system into core commercial or operational processes, you need to understand their financial position. That is not aggressive - it is governance.

Ask:

1. When did you last raise capital, and what is your current runway?
2. What percentage of revenue comes from contracts of more than twelve months?
3. Who are your five largest clients, and can we speak to two of them?
4. What is your plan if you are acquired - specifically, what happens to our contract?

A private equity-backed consumer goods business we worked with signed a three-year AI contract nine months before their vendor was acqui-hired by a larger platform. The functionality they had contracted for was deprecated inside six months. Their contract had no acquisition clause.

Build an acquisition clause into every AI contract. It is not standard. Insist on it.

Internal readiness: the question you need to ask yourself

No vendor selection process is complete without an honest assessment of your own organisation.

The majority of AI implementations that fail do not fail because the technology was wrong. They fail because the organisation was not ready to receive it - no clear ownership, no data foundations, no internal capability to maintain or adapt the system once the vendor's implementation team has left.

Before you sign, answer these questions internally:

1. Do we have a named owner for this system post-go-live, with time allocated and authority to make decisions?
2. Is our underlying data clean enough, governed well enough and accessible enough to support what we are buying?
3. Do we have the internal capability to evaluate vendor outputs critically - or will we be entirely dependent on the vendor to tell us whether it is working?
4. What does success look like in twelve months, and how will we measure it?

If you cannot answer question four, do not sign the contract yet. A well-structured diagnostic engagement - typically two to four weeks - can establish that baseline, identify the integration risks and give you a much stronger position in vendor negotiations.

What happens if you skip this process

The cost of poor vendor selection at your scale is not a failed pilot. It is a two or three-year contract that becomes operationally embedded before anyone realises it does not work as promised, exposes you to data risk you did not knowingly accept, or creates dependencies that are expensive to exit.

Senior leaders who have done rigorous vendor due diligence rarely regret the time it took. Those who have signed on momentum and paid for it later are consistent about one thing: the warning signs were visible. They just did not have a framework to see them.

The questions above are not exhaustive. They are a starting point. If you are approaching a significant AI vendor decision and want independent scrutiny of the commercial terms, the integration architecture or the vendor's claims, a Rodan diagnostic engagement will give you that - typically within two weeks and at a fixed cost. Contact us to discuss what that would involve for your specific situation.