How to choose an AI implementation partner: 7 questions before you sign
Don't choose on the demo. Choose on who owns what gets built, what happens after the vendor leaves, and how you measure that it worked. Seven questions to ask any vendor, us included.
In short: you don't choose an AI implementation company on the demo. You choose on three things: who owns what gets built in the end, what happens after the vendor leaves, and how you measure that it worked. Everything else follows from those.
Full disclosure: this is exactly the service we sell. So use this list to check us too.
Why the choice is hard
Plenty of vendors in Israel now offer "AI implementation". Large integrators, studios that build agents, trainers who run workshops, and consultants who write strategy. Every one of them will show you a good demo.
The trouble starts after the demo. Per MIT NANDA, in 2025 about 95% of corporate AI pilots produced no measurable result. What we see in the field: most projects don't stall because of the model, but because nobody in the organization knows how to work with what was built, and nobody stays to fix it.
Seven questions to ask any vendor
1. Who owns the code, the connections and the subscriptions in the end?
A good answer: the subscriptions are in the company's name, straight from the vendor. The code and the data move to you when the engagement ends, and that is in the contract.
Red flag: "it runs on our platform". The day you want to leave, you start from zero.
2. How will you connect the AI to our systems?
A good answer: through MCP, an open connection standard every major AI tool supports. Where an official connector exists, use it; where none does (Priority or SAP Business One, for example), build one, and it stays yours.
The question to ask almost word for word: "Is the connection you are building MCP, and who owns it in the end?"
3. What do you do before you build?
A good answer: mapping. Department by department, find what repeats every day and rank it by value. If you have already built something, a good vendor starts by checking what exists: does it answer correctly, does anyone use it, and who knows how to fix it.
Red flag: a quote for a bot before anyone asked what the department does by hand twice a day.
4. How will our people learn to work with it?
A good answer: small groups, each department on its own examples, laptops open. Then support, until employees build small things on their own.
Red flag: one lecture in a hall, then "good luck".
5. What happens to our data?
A good answer, in three parts:
- Work on the vendor's enterprise channels, where data is not used for training.
- Every connection to a core system runs under its own service account, with least privilege.
- Every write to the ERP or CRM passes human approval and is logged.
Red flag: "don't worry, it's secure", with no detail.
6. How will we know it worked?
A good answer: every use case has a number before work starts, in hours or in money. Measure before and after. And measure how many employees actually use the tool.
Red flag: a success metric that reads "we delivered three bots".
7. What happens after handover?
A good answer: someone answers questions from the field, fixes what breaks, and builds the next thing in line. With a monthly report, and no lock-in period.
Red flag: a contract that ends on delivery day, followed by "hourly rate on request".
How to tell if it pays off
The math itself is simple:
- Pick one process and measure how many hours a month it takes today.
- Estimate, conservatively, how much of that AI will save.
- Compare with the monthly cost of the tool and the support.
If the saving doesn't cover the cost on paper, it won't in reality either. If it does, start with that process only, and expand once the number moves.
The right order
People learn the tool first. Then they can say exactly what should be automated. Only then do you build, and harden what already works by hand.
A vendor offering the reverse order, the system first and "we'll train your people" later, is selling you the easy part.
If you're choosing now, here's how our process works. And if another vendor's proposal is on your desk, run it past these seven questions before you sign.
Questions people ask
How do you choose an AI implementation company?
Not on the demo. Ask every vendor three questions first: who ends up owning the code, the connections and the subscriptions; what happens after handover, when something breaks; and how you will measure that it worked, with a number agreed before you start. A vendor with a clear answer to all three moves to the next round.
How do you measure the ROI of an AI rollout?
For every use case, agree one number upfront: hours per month, errors, or response time. Measure before and after. If the number does not move, stop and find out why. Also measure how many employees actually use the tool, because a tool nobody uses saves nothing.
Should we hire an in-house AI person or work with an outside company?
In a company without a dev team, a single AI hire becomes a bottleneck and a dependency on one person. Per MIT NANDA (2025), projects where an outside party was accountable for making it work reached production about twice as often (67% vs 33%). What matters is that the capability ends up with your team, not with the vendor.
How much does an AI rollout cost?
It depends on the structure. A mapping workshop is usually a fixed day rate, ongoing support is a monthly hours quota, and a single system is a one-off build fee plus monthly maintenance. What to demand from any vendor: a written price upfront, with a clear scope, before work starts.