The AI partner worth hiring is one you stop needing What the research says about getting AI live with outside help, and when to build it yourself

Sooner or later, someone in the leadership meeting asks it: should we bring in a partner for this, or build it ourselves?

It's a fair question, and most of the advice on it comes from people with something to sell. Consultancies say partner. Software vendors say buy. Your own engineers, if any of them have spare time, say build. We sell partnering, so read us with the same skepticism.

The research gives a more useful answer than any of them. Outside help does get more AI into production. But the newest analyst warnings aren't about companies that went it alone. They're about companies that hired a partner, got a system live, and then couldn't run it once the partner left.

So the better question goes one step further: what happens on the day the partner leaves? The partners worth hiring answer that before any work starts. We call it the day-one exit plan: who owns the code, who on your team learns to run it, and the date the partner's access ends, all written down before anyone builds anything.

Most AI work stalls between the pilot and the payoff

Gartner surveyed 2,002 CIOs and found only 13% say AI has delivered significant value to their enterprise. S&P Global found the share of companies abandoning most of their AI initiatives rose from 17% to 42% in a single year. On average, 46% of projects were scrapped somewhere between proof of concept and broad adoption.

The picture is improving. BCG's 2026 index found nearly half of companies now capture meaningful value from AI, a sharp rise from 2025. So "most AI fails" is getting old. What's growing is the gap between companies that get AI into production and companies stuck running pilots.

Gartner's Alicia Mullery summed it up in four words: "Volume is not value." The same research found that companies with written criteria for when a pilot should not go to production were 2.3 times as likely to be AI leaders. Only 31% have those criteria.

The play.

• If you lead the team: Before the next pilot starts, write down the result that would make you stop it.
• If you're on the team: Ask what "done" and "stop" look like for the pilot you're on. If nobody can say, that's the first thing to fix.

The hard part is rarely the model

RAND interviewed 65 experienced data scientists and engineers about why AI projects fail. The top root cause was misunderstanding the problem, followed by missing data, chasing new technology over real user problems, and weak infrastructure. Only the fifth cause was that the problem was beyond what AI can do.

BCG puts numbers on it: 10% of AI value comes from algorithms, 20% from data and technology, and 70% from people and processes.

That 70% is the core of this post. A good partner brings pattern recognition for the first four failure causes, because they've watched the wrong problem get picked before. But the 70% sits with your people and your processes. No partner can carry it for you, and no tool can either. That makes the partner's real job leaving your team able to carry it.

Outside help gets more of the work live

The strongest number for partnering comes from MIT's NANDA initiative: pilots built through strategic partnerships were about twice as likely to reach full deployment as those built internally, roughly 67% against 33%.

Read the fine print before you quote it. The study rests on 52 organization interviews and surveys of 153 leaders at conferences. "Partnership" there mostly means buying and customizing vendor tools, not hiring a consulting team. And the authors say the gap may reflect the organizations themselves rather than the approach alone. It's a useful signal, not proof.

The talent math is harder to argue with. In the World Economic Forum's survey, 63% of employers named skills gaps as their biggest barrier to changing their business. Bain projects that up to half of US AI jobs could go unfilled by 2027. Levels.fyi puts average self-reported pay for AI-focused software engineers at about $245,000. S&P Global found 46% of companies turning to integrators and consultants to close AI skills gaps, while 49% are reskilling their own staff.

Most companies need this expertise for months, not forever. That argues for borrowing it while your own people learn, not renting it indefinitely.

Going alone often skips the guardrails

The quieter risk of doing it yourself is that governance comes last. IBM's 2025 breach study (IBM sells security products, so weigh it accordingly) found that 13% of organizations had a breach of an AI model or application, and 97% of those lacked proper AI access controls. Where employees used unapproved AI tools heavily, breaches cost about $670,000 more.

"Going alone" often doesn't mean one team building one tool. It means dozens of people using AI however they see fit. In a KPMG and University of Melbourne study of 48,000 people, 57% said they hide their use of AI at work, and only 40% said their workplace had a policy or guidance on generative AI.

That flips the usual objection. Leaders worry that a partner adds risk. The bigger risk is often the AI already running inside the company with no access controls and no policy. Hard limits, full logs and a pause button the client controls belong in the original build, not in the cleanup after an incident.

The honest catch: some partners leave you more stuck

Here's the part most "why you need a partner" articles leave out. Gartner now predicts that 70% of enterprises will abandon agentic AI built by vendors' forward-deployed engineers by 2028, citing rising costs and an inability to change those systems on their own. That's a forecast, not a measurement. But it lines up with what buyers already report. In a Zapier survey of 500 US enterprise executives, only 6% said they could drop their main AI vendor without their work being interrupted, and 58% of those who tried to switch failed or needed far more effort than expected.

Think about what this does to the people left behind. The partner's engineers move on to the next client. Your team inherits a system they're expected to answer for and can't fix. Every change request becomes a new statement of work, and every outage becomes a call to someone who no longer remembers the code. That's how a project meant to free people up ends up making them nervous of their own tools.

Gartner's advice to buyers reads like a contract checklist. Its analyst Mukul Saha tells companies to "execute the exit plan established at the start" instead of extending an engagement because the internal team isn't ready. That's the day-one exit plan, in an analyst's words.

What good partnerships leave behind

The research points to one ingredient over the rest: what the client's team learns along the way. MIT Sloan Management Review and BCG found that the odds of significant financial benefit from AI rose from 10% to 73% for companies that added organizational learning on top of good data, technology and talent. That study is from 2020 and correlational, but it's still the clearest data on why learning matters.

Here's what to ask any partner for, ourselves included. Together, these five make up the day-one exit plan:

1. Code and data in your accounts from day one. Not transferred at the end. If the partner holds the keys, you hold a dependency.
2. Your people in the build, not just at the demo. Name who on your team works alongside the partner, and for how many hours a week, before the contract is signed.
3. Stop rules before money. Written criteria for go and no-go, agreed before the pilot starts, so a weak result ends the work instead of extending it.
4. Controls in the original scope. Access limits, logs, rollback and a pause button you control, priced in from the start.
5. An end date for the partner's access. Written into the contract. Any support after that should be optional, capped, and set to expire.

If you're not the one signing the contract, you can still ask for most of this. Ask who on your team will be trained to run the system, and ask to sit in the working sessions rather than the final demo. The person who gets the call when it breaks is the right person to learn how it works.

The test: If your partner's access ended tomorrow, could someone on your team change the system by Friday?

When an AI partner isn't for you

Building in-house is getting easier. McKinsey found that 32% of companies decided against buying software because they could build it themselves with AI coding tools. Going it alone is usually the right call when most of these are true:

• You've shipped AI to production before, and it's still running.
• You have engineers with spare time who already know your data.
• Access controls and an AI policy are in place.
• The workflow is simple, stays inside one team, and is easy to reverse.

If most are false (pilots keep stalling, hiring would take months, shadow AI is already common, or the workflow crosses systems and teams), outside help usually pays for itself. Either way, the deciding factor is the one Gartner names: whether your team can run and change the system once it's built.

Common questions

Should we build AI in-house instead of hiring a partner?

If you've shipped AI that's still running and have engineers with time to spare, often yes. If pilots keep stalling, a partner who builds alongside your team is usually faster. Even then, the goal is to end up able to build in-house.

How do we avoid vendor lock-in with an AI partner?

The worry is reasonable: the Zapier numbers say most companies are already locked in somewhere. Put ownership in the contract (code and data in your accounts, documentation as a deliverable, named internal operators, an end date for access), then test it before that date by having your team make a change without the partner in the room.

What should an AI partner leave behind?

A running system, the runbooks to operate it, at least two people trained to run, break and repair it, and the go and no-go criteria that got it there. If all you have at the end is the system, you bought a dependency.

Won't bringing in a partner make my team feel replaced?

It can, if the partner builds around them. That fear protects something real: people's standing as the ones who know how the work gets done. A partner who builds with them in the room leaves them knowing more about their own systems, not less. We covered that fear in more detail in The three fears every team has about AI.

What happens on the day they leave

Back to the question from the leadership meeting. Partner or build? The research says partner, more often than not, if your pilots keep stalling, you're short on people, or AI is already running in your company without guardrails. It also says the choice of partner matters more than the choice to partner.

So ask the question one step further. Can they get it live, and what happens on the day they leave? If the answer is that your team keeps running it and the partner's access quietly ends, you've found the right one.

How Cantera Works gets you there

This is the work we sell, so weigh it with that in mind. Every engagement is built around the day-one exit plan.

• The Survey (three weeks, fixed fee) picks the right problem first, which is RAND's top cause of failure. It ends with a costed roadmap and a list of things your team can build without us.
• The Pilot (one workflow, four to six weeks) starts read-only and is measured against stop rules you set up front. It ends in go or no-go, with the reasoning shown.
• The Build puts your people in the room. Two of your operators are trained to run, break and repair it, the code lives in your accounts from day one, and our access ends on a date in the contract.

One thing you can do without us: take your current AI vendor contract, or the draft on your desk, and check it against the five points above. Anything missing is worth asking for before you sign or renew, whoever your partner is.

Your next step

Pick the AI project you're least sure about, whether you plan to partner on it or not, and book a thirty-minute readiness call. No pitch deck, no commitment; leaders and team members are both welcome.