What to Do When Your AI Vendor Relationship Has Gone Wrong

The contract said eight months. It had been sixteen. The vendor was citing the bank's IT team as the primary delay. The bank's IT team was citing underdocumented API requirements from the vendor. The CFO had stopped attending the steering committee and had started asking her EA to pull the original contract. Nobody was lying exactly — but nobody was telling the whole truth either, and the engagement had been in polite stalemate for the better part of a year.

How vendor relationships go wrong in AI implementations

The failure pattern is nearly always the same, even when the specifics differ. It starts with a gap between what was sold and what was scoped. The sales process surfaces institutional pain, proposes a compelling solution, and builds confidence — but the contract that follows is written at a higher level of abstraction than the actual work requires. What counts as "integration complete" is not defined. What counts as "model performing" is not specified. What the vendor is responsible for versus what the bank is responsible for lives in a paragraph of mutual cooperation language that neither party scrutinizes until something goes wrong.

Scope creep is almost always the first visible symptom. The bank discovers mid-implementation that the use case is larger than anticipated, or that data preparation work the vendor assumed was done is actually undone, or that the integration touches a system nobody mentioned in the sales cycle. The vendor flags the additional work. The bank asks why it wasn't in the original scope. The vendor says it was implied. The bank says it wasn't explicit. The change order negotiation starts. And then it starts again six weeks later.

The second pattern I see is the vendor's implementation team being different from the vendor's sales team — sometimes dramatically. The sales team knew the institution, understood the use case, and communicated clearly. The implementation team is focused on technical delivery and has a different understanding of what was promised. At mid-market institutions specifically, this gap is often compounded by the vendor having assigned a less experienced implementation lead than what the sales cycle implied.

The third pattern is the one I documented in Pattern 5 of why bank AI pilots fail: the vendor sold directly but is delivering through a partner the bank has never met. The partner has its own timeline pressures, its own interpretation of the scope, and its own relationship with the vendor that may or may not be well-managed. The bank is now managing a relationship it didn't know it was entering.

Then comes the moment when both sides stop talking honestly. This usually happens around month five or six of a stalled engagement. The vendor's project manager stops volunteering bad news in status updates. The bank's project owner stops escalating internally because they don't want to be associated with a failing initiative. The steering committee meetings become performance — everyone knows the milestones are being missed, and nobody says it directly. The stalemate is comfortable for both parties in the short term and destructive for both in the long term.

The stalemate is not the final state. It is the state that exists when nobody has been willing to say what is actually true. That conversation is almost always more productive than either party expects — because most vendors want the implementation to succeed too.

The three options when a vendor relationship has gone wrong

When I'm brought in to assess a stalled AI vendor engagement at a financial institution, the first thing I do is establish which of three situations the institution is actually in. The options are renegotiation, replacement, or termination with partial recovery. Each requires a different approach, and confusing them is expensive.

Renegotiation is the right option when the underlying technology is sound, the vendor has the capability to deliver, and the failure is primarily a scope and accountability problem rather than a capability problem. This is the majority of situations I encounter. The vendor can deliver something valuable — it just isn't the thing that was originally described, on the timeline that was originally committed to. The path forward is an honest re-scoping conversation that produces a revised contract with specific deliverables, specific timelines, and specific accountability mechanisms. I'll describe how to run that conversation below.

Replacement is the right option when the vendor genuinely cannot deliver the capability that the institution needs, and when staying in the relationship longer will cost more than the exit and restart. This is a harder call to make than it sounds, because the sunk cost is real and visible and the replacement cost is uncertain and prospective. The calculation that matters is not "what have we spent" but "what will we spend over the next 18 months in each scenario." Run both scenarios with real numbers before making the decision. Include the exit costs — contract termination fees, data migration, institutional momentum lost — and include the realistic cost of a new vendor relationship starting from scratch, which includes another discovery process, another data preparation effort, and another MRM validation cycle.

Termination with partial recovery is the right option when the vendor relationship is unsalvageable, but where you have built something during the engagement worth preserving. This is more common than full termination with nothing to show. The bank may have completed substantial data preparation work, documented internal processes, built integration infrastructure, or produced governance artifacts that transfer to a successor vendor relationship. Before terminating, inventory what exists and what is portable. The data work almost always transfers. The integration work sometimes does. The vendor-specific configuration almost never does. Know which is which before you sign the termination notice.

How to approach the renegotiation conversation

The renegotiation conversation works when both parties enter it with a shared interest in producing an outcome — and when the bank goes in with a clear view of what it actually needs, not a defense of what was originally promised.

Start internally. Before the conversation with the vendor, the bank's project owner, the business line sponsor, and the IT lead need to agree on three things: what the institution actually needs from this system in order for it to create value, what the realistic timeline is given what has been built so far, and what accountability mechanisms will prevent the same stalemate from recurring. If those three things are not agreed internally, the renegotiation with the vendor will be unfocused and the vendor will fill the vacuum with their preferred framing.

When you go to the vendor, lead with the shared problem. Not an accusation, and not a defense of your own team's performance. Something like: "We have both missed the original milestones. We need to produce a revised scope that reflects reality and that we can both commit to. Here's what the institution needs in order for this to work. What can you realistically deliver, and when?" That framing gives the vendor's project leadership room to be honest about what they can actually do — which is often different from what their sales team promised and which they may have been reluctant to say until someone opened the door.

The revised scope document that comes out of this conversation needs to be more specific than the original contract. Not just milestone names, but milestone definitions: what does "integration complete" mean, specifically? What test will confirm it? Who approves it? What happens if the milestone is missed? The specificity is not adversarial. It is the thing that prevents the next stalemate from forming.

One structural element I recommend adding to every renegotiation: a 60-day checkpoint with a binary decision point. If specific deliverables are not met at 60 days, the institution has the right to exit the renegotiated contract without penalty. This changes the incentive structure for the vendor and it changes the internal accountability dynamic for the bank. It also, in practice, rarely gets triggered — because the existence of the checkpoint changes behavior on both sides.

What to put in the next contract

The contract provisions that would have prevented this situation are almost never complicated. They just require someone to negotiate them explicitly rather than accepting the vendor's standard terms.

Milestone definitions with acceptance criteria. Every milestone in the project plan needs a corresponding definition of what constitutes completion, who tests it, and who signs off. "Integration complete" is not a milestone. "Data feed from core system to model environment passing X records per day with Y error rate, confirmed by bank IT and vendor implementation lead" is a milestone.

Implementation team identification before signing. The contract should name the specific individuals who will lead the implementation on the vendor side, or at minimum require that the bank approve the implementation lead before contract execution. If the vendor delivers through a partner, the partner needs to be identified and the bank's right to meet the partner team before signing needs to be explicit.

Remedies for milestone failure. When a milestone is missed, what happens? Most vendor contracts are silent on this or have remedy provisions so narrow they are never triggered. The provision I push for is simple: if a milestone is missed by more than 30 days without a mutually agreed revised date, the bank has the right to a fee credit equal to the monthly retainer for that period and the right to exit without penalty if the milestone remains unmet at 60 days. Most vendors will push back on this. That pushback is information about how confident they are in their own timeline.

Data handling and portability. The contract needs to specify what data the vendor has access to, how it is used, and what happens to it at contract termination. It also needs to specify that any models, configurations, or derived artifacts built on bank data are owned by the bank and portable on exit. This is the provision most often missing from first-generation vendor contracts — and the one most painful to have missed when a termination happens.

For a full evaluation framework before you're in a vendor relationship that needs rescuing, the vendor selection criteria I use with mid-market institutions address most of these issues at the front end. The renegotiation and termination playbook exists because vendor selection doesn't always go as planned — but the best leverage point is always before you sign.