Your AI Vendor Doesn't Have a Data Problem. You Do.

For: COO or operations lead at a 50–300 person company who signed a contract with an AI vendor six months ago, has seen little to no business impact, and is privately starting to blame the vendor

If your AI implementation has stalled six months in, the vendor is probably not the reason. The reason is that your operational data — scattered across spreadsheets, a 12-year-old ERP, three SaaS tools, and the heads of four senior operators who never wrote anything down — was never in a state any model could learn from. The contract you signed bought you a capable model and an integration team. It did not, and could not, buy you a clean signal to point it at.

This is the uncomfortable thesis: AI vendor selection is almost never the critical path to a failed implementation. The critical path runs through your own data pipelines, your process documentation, and the quiet tribal knowledge your operations run on. Most companies discover this only after the contract is signed, the pilot has missed its targets, and the blame has already been quietly pointed outward.

The pattern is the same almost every time

A COO at a 150-person company signs with an AI vendor. The pitch was concrete: cut manual ticket triage by 60%, automate invoice matching, surface churn risk a quarter earlier. The vendor was credible. Their demo worked. References checked out.

Six months later, the model is technically live, but nothing has changed operationally. Ticket triage still routes through the same two team leads. Finance still matches invoices in Excel. The churn predictions are either obvious (the customer who hasn't logged in for 90 days is at risk — thanks) or unexplainably wrong.

The instinct at this point is to blame the vendor. Sometimes that is fair. More often, if you trace the failure backwards, you find the same three things:

• The training data the vendor was given was a CSV export from one system, missing the context that lives in three others.
• The "process" the AI was meant to automate was never actually a single process. It was four senior people making judgment calls that no one had documented.
• The success metric was defined against a baseline no one had measured cleanly before the project started.

None of those are vendor problems. They are data and operations problems, and they existed long before the AI conversation started. The AI project just made them visible.

Why this gets misdiagnosed

Enterprise AI data readiness is hard to assess from the inside. Operators look at their data and see something familiar and workable, because they have spent years compensating for its gaps in their heads. When a Senior Account Manager looks at a half-empty CRM field, she fills it in mentally from memory. When the warehouse lead looks at an inventory number she knows is wrong, she corrects it before she acts on it. The data looks fine to them because they are the missing pipeline.

A model has none of that context. It takes the field at face value. It takes the wrong inventory count and confidently makes a wrong prediction. Then the operator who would have caught the error in her head looks at the output and concludes the AI is broken.

This is the core mechanism behind most AI project failure reasons we see. The vendor delivers a model that performs exactly as specified on the data it was given. The data it was given is a thin, decontextualized slice of how the business actually runs. The gap between those two things is invisible until production.

Three examples of where the real failure sits

Consider an AI-assisted drug interaction check for a pharmacy operation. The model itself is the easy part — interaction logic is well-understood, and there are good clinical datasets to fine-tune against. The hard part is that the pharmacy's prescription data lives in handwritten notes scanned as PDFs, a billing system that stores drugs by SKU rather than molecule, and a customer file where allergies are sometimes a structured field and sometimes a free-text comment. We saw this shape of problem directly while building HealthPotli's e-pharmacy platform. Without normalizing those three sources first, no AI layer on top would have produced trustworthy output. The work that mattered was upstream of the model.

Or take logistics. A freight marketplace wants AI-driven route optimization. The model is, again, the easy part. The hard part is that load data, truck availability, driver preferences, and historical lane economics live in five places, and the "price for this lane" is often a phone-call negotiation that never gets written down. Optimizing on partial inputs gives you confidently wrong recommendations. The Vahak build forced the data plumbing to come first; the intelligence layer came after.

Or fintech. AI credit scoring for thin-file borrowers sounds like a modeling problem. In practice, the modeling is commodity. The differentiator is whether you can pull clean signal from bank statements, KYC documents, and alternative data sources, and whether that pipeline is reliable enough to underwrite a loan against. The work on Cashpo's lending stack was 70% data engineering before any scoring model became useful.

In all three cases, swapping the AI vendor would have changed nothing. The constraint was upstream.

The strongest counter-argument

The honest pushback is: sometimes the vendor really did overpromise. Some vendors sell capabilities they cannot deliver. Some pitch a generic LLM wrapper as a domain solution. Some have integration teams that disappear after kickoff. Those vendors exist, and if you signed with one, the diagnosis above does not apply.

So how do you tell the difference? A few honest tests:

• Ask the vendor for the input data they're actually using. If they can produce a clean schema, sample records, and a list of fields they flagged as low-quality, they did their job. If they cannot, that is on them.
• Look at where the model fails. If it fails on cases your operators would also find hard, the model is fine and your process is ambiguous. If it fails on cases your operators handle easily, the model is genuinely underperforming.
• Check whether anyone defined a clean baseline before the project started. If no one measured the current triage accuracy, current invoice match rate, or current churn prediction lead time, then "AI didn't move the needle" is unfalsifiable. You don't have a vendor problem. You have a measurement problem.

If those tests point at the vendor, replace the vendor. If they point inward — and in our experience they usually do — replacing the vendor will reproduce the same failure with a different logo.

What to do differently from here

If you are six months into a stalled implementation, do this before you fire anyone:

1. Audit the data the model is actually consuming. Not the data you intended to give it. The actual fields, the actual completeness rates, the actual update frequencies. Most COOs are surprised by what they find.
2. Find the undocumented judgment calls. For each process the AI was meant to support, identify which decisions your senior operators were making in their heads. Those are the decisions the model has no input for. Either capture them as data, or accept the model will not match human performance on those cases.
3. Re-baseline the success metric. Measure the pre-AI process cleanly for two to four weeks. You cannot claim a project failed against a baseline you never established.
4. Decide what the next 90 days are for. If the answer is "fix the data so the model has something to learn from," that is a different project than "replace the vendor." Run the right one.

For most operations leads reading this, the AI vendor is not the problem worth solving. The problem worth solving is that your business has been running on undocumented process and fragmented data for years, and the AI project was the first thing honest enough to surface it. Treat that as the gift it is. Fix the upstream. The model will start working — with this vendor or any other.

If you want a structured way to assess where your data and process gaps actually sit before you sign or re-sign anything, that is what a proper digital transformation engagement is for, and it is the work that makes everything downstream — AI, automation, analytics — actually function.

Frequently Asked Questions

How do I know if my AI project is failing because of the vendor or because of my data?

Ask the vendor for the exact input schema and data quality flags they are working with. If they cannot produce that, the vendor is underperforming. If they can, look at where the model fails — failures on cases your operators also find ambiguous point to data and process gaps, not vendor incompetence.

What does "enterprise AI data readiness" actually mean in practice?

It means three things: your operational data is consolidated and consistent enough that a model can read it without human translation, the processes you want to automate are documented as decisions rather than tribal judgment, and you have a clean pre-project baseline to measure against. Most companies have none of the three when they sign their first AI contract.

Should I replace my AI vendor if I'm six months in with no impact?

Probably not as your first move. Run a data and process audit first. If the audit shows the vendor was given thin or inconsistent inputs, replacing them will reproduce the same failure. If the audit shows the inputs were clean and the model still underperformed, replace them.

How long does it take to get our data ready for AI, and what does it cost?

It depends entirely on how fragmented your current systems are, how much process is undocumented, and what AI use case you are targeting. There is no useful generic answer — contact CodeNicely for a personalized assessment against your actual stack and operations.

Is this also true for smaller companies, or only enterprises?

It is arguably more true for SMBs. Smaller companies run on more tribal knowledge and less documented process, so the gap between "data the AI sees" and "how the business actually runs" is usually wider. The good news is that the surface area to fix is smaller. See our approach for digitizing SMB operations for context.