AI vendors are not dishonest. They are optimistic — and they are optimistic about the parts of the implementation they control. The parts they do not control — your data, your integrations, your change management, your compliance review process — are where the promises quietly stop applying.
In three years of AI programme assessments, one pattern shows up more consistently than any other: organisations that are six months behind schedule and significantly over budget on an AI implementation that was sold to them as a twelve-week deployment. The vendor has delivered the software. The software works as specified. And yet the organisation cannot use it, because the conditions the software requires — clean data, mapped workflows, aligned stakeholders, integrated systems — were never part of the vendor's scope.
This is not fraud. It is a scoping gap that both sides share responsibility for. Vendors scope to what they can control and price. Buyers scope to what they want to believe. The result is a contract that is technically honoured and practically useless.
What 'production-ready' actually means in a vendor's vocabulary
When a vendor says their platform is production-ready, they mean the software has been tested, deployed at other clients, and is capable of performing the function it is designed for. They do not mean it is ready to go into production in your environment. Your environment has a data warehouse that was last restructured in 2019, an ERP system the vendor's API was not designed to connect to, and a legal team that has not yet reviewed the data processing agreement. None of those things are the vendor's problem. All of them are your deployment timeline.
The phrase 'seamless integration' is the one that most reliably signals missing context. Integration is never seamless. Every integration involves mapping fields that do not match, resolving authentication protocols that predate the vendor's platform, and managing the lag between the vendor's release cycle and your IT team's change management window. The question is not whether integration will be hard. The question is how hard, and whether your team has the capacity and technical skills to manage it in parallel with their existing responsibilities.
The best AI vendor is not the one with the most impressive demo. It is the one that asks the hardest questions about your environment before they quote you a timeline.
None of this is an argument against working with AI vendors. The platforms available today are genuinely powerful, and few enterprises have the internal capability to build equivalent functionality from scratch. The argument is for going in with accurate expectations — about what the vendor is responsible for, what you are responsible for, and what the realistic timeline looks like when those responsibilities are honestly scoped.
The organisations in our assessment cohort that have the most positive vendor relationships are the ones that did the hardest internal work before the vendor arrived. They audited their data. They mapped their integrations. They got legal and compliance into the room early. By the time the vendor showed up, the difficult conversations had already happened internally. That sequencing is not natural — it requires discipline and a willingness to delay the exciting part. It is also the difference between a deployment that delivers and one that teaches an expensive lesson.
The five questions that change the conversation
The first question is: what does your fastest-to-value customer look like? Not the average customer. The fastest. What was their data infrastructure before they started? How many integrations did they have to build? What internal resources did they commit? If a vendor quotes you a twelve-week deployment timeline, you need to know whether that is achievable for a customer who looks like you — not one who had a greenfield data lake and a dedicated three-person implementation team.
The second question is: what has caused deployments to stall, and at what stage? Every honest vendor has seen implementations slow down or fail. The ones worth working with can tell you why, and what the leading indicators of a stall look like. If the answer is 'our implementations don't stall,' find a different vendor.
The third question is about model drift: after go-live, how does performance degrade over time, and what does the monitoring and retraining process look like? A model that performs at 89% accuracy on day one and 71% accuracy six months later — because the underlying data distribution has shifted — is not a success story. It is a liability that materialises slowly. The fourth question covers explainability: can the model's outputs be explained in terms a regulator, a customer, or a challenged employee can understand? The fifth is about exit: if we need to move to a different vendor in three years, what does data portability look like?
What a well-structured vendor conversation looks like
The best vendor conversations are not demos — they are scoping exercises. Before any technology is shown, the vendor should be asking about your data architecture, your existing integrations, your compliance requirements, and the internal stakeholders who will need to approve and adopt the output. A vendor who leads with a live demo and follows with a proposal has told you something important about their sales process — and it is not reassuring.
Request a technical scoping workshop before any commercial conversation. Bring your data architect, your head of compliance, and the operational owner of the business process being automated. The questions those three people ask in a room together will surface the integration gaps, governance requirements, and change management challenges that a sales conversation will never reach. If the vendor is uncomfortable with that level of scrutiny before a contract is signed, that discomfort is informative.
The shared responsibility model most organisations ignore
Enterprise AI implementations that succeed consistently operate on a shared responsibility model that is written down, not assumed. The vendor is responsible for the software, the model performance within agreed parameters, and the support SLA. The client is responsible for data quality, integration delivery, stakeholder alignment, and change management. Both parties are jointly responsible for defining success metrics before go-live and reviewing them at agreed intervals.
When this model is not written down — when responsibilities are assumed rather than assigned — every problem becomes a negotiation about who failed. The vendor points to the data quality. The client points to the integration gaps they were told the vendor would handle. Everyone is correct about someone else's failure and no one is responsible for fixing it. The shared responsibility model is not bureaucracy. It is the contract that makes the relationship survivable when things go wrong.