How to Choose an AI Implementation Partner (10 Questions That Reveal Everything)

The short answer

Choose a partner by what they leave behind, not by what they present. Ask for a workflow they took to production, who maintains it now, and what they would refuse to build. The ten questions below surface that in a single meeting.

---

The three kinds of partner

Most of the market falls into three groups, and they are not interchangeable:

• Strategy-only. Excellent frameworks, market scans, roadmaps. The deliverable is a document. Useful if you already have engineering capacity to execute it.
• Build-only. A dev shop that will implement whatever you specify. Fast hands, but they will build the wrong thing accurately if your scoping is weak.
• Execution-led. Scopes and builds and enables the team, with one accountable owner across all three. Fewer of these than the marketing suggests.

The mismatch, not the quality, is what usually goes wrong. Diagnose which kind you need before you shortlist.

The ten questions

1. Show me something you took to production, and tell me who maintains it today. A pilot that a client's own team now owns is the strongest signal in this industry. "We delivered a POC" is not the same claim.

2. What did you refuse to build for a client, and why? Partners with real judgment can name a use case they talked a client out of. Partners who never say no will happily bill you for the wrong thing.

3. Who is actually in the room? Ask which named people do the work, at what percentage of their time. Beware a senior pitch team replaced by juniors on day one.

4. How do you decide build versus buy? You want an explicit process, per use case, with a written rationale. A partner who builds everything custom has an incentive problem.

5. What happens to our data? Which models, hosted where, with what retention, and under what agreement. Anyone vague here has not passed a serious legal review before.

6. How will our own team be able to maintain this? Look for pairing, documentation and enablement built into the plan. If knowledge transfer is a final-week workshop, it will not happen.

7. What is your integration plan for our legacy systems? The right answer names a strategy — an interface layer, a documented API surface, an incremental migration path — not "we'll figure it out in discovery."

8. What is the kill criterion? A partner confident in their work will agree upfront on the number that says stop. Ones who won't have never had a project stopped, which is itself a warning.

9. How do you measure adoption, not delivery? Usage by role, week over week, is a real metric. "Delivered on time" tells you nothing about whether anyone uses it.

10. What do you think is hype right now? Anyone who thinks nothing is overhyped is selling. This question tells you whether you are talking to a practitioner or a brochure.

Red flags

• A fixed price for an undefined scope.
• Training with no follow-up, or a build with no enablement.
• A proposal with no named kill criterion and no phase boundaries.
• Case studies with impressive numbers and no description of the workflow behind them.
• Reluctance to work inside your stack, with your data and your engineers.

Green flags

• They ask about your workflows before they talk about models.
• Phase one is smaller than you expected.
• They name what they will not do.
• Enablement of your team is in the same proposal as the build.
• They can explain a failure and what they changed afterwards.

How we answer these questions

We are an execution-led practice: mapping and prioritization, then building with your team and data, then enabling the people whose work changes — one accountable owner across all three. We are also Anthropic's official partner in Israel, and we work in English and Hebrew. If you want to run the ten questions on us directly, write to info@braightwave.com.