Three steps to finding the right AI development partner

Most AI partner selections start with a capability question — who can build this — and that is the wrong opening. It produces a shortlist of vendors who can all build something, and no basis for choosing between them.

The three steps below start somewhere else.

Step 1 — Define the decision, not the technology

Before evaluating anyone, write down what you want to be different. Three specifics make the rest of the process possible:

Which decision improves, and who makes it today. “Use AI in customer service” is a technology wish. “Automate first-line ticket classification so routing is not manual — measured by time to first qualified response” is a brief. The second can be scoped, estimated and abandoned; the first cannot.

What the answer is worth. If the process runs forty times a month and each instance saves twenty minutes, that is the budget envelope. A great many AI projects are proposed without anyone having done this arithmetic, and they collapse at the first finance review.

What you already know about your data. Can you answer the question today with SQL and enough time? If not, the model will not answer it either — it will produce a plausible number with no basis. The honest version of this is covered in AI architecture: why data governance decides the outcome.

A partner given this brief will tell you quickly whether it is feasible. A partner given “we want to do AI” will tell you it is.

Step 2 — Evaluate on evidence, not on claims

Every vendor now has an AI practice. The differences are visible in specific questions.

Ask about a project that did not work. What was attempted, why it failed, what changed afterwards. A partner with no such story either has not done enough work or is not being straight — and in this field, where most pilots do not reach production, the absence is telling.

Ask how they evaluate. Not accuracy on a test set — how they decide whether a system is good enough for a real decision, what they measure after deployment, and how they detect degradation. Teams that cannot answer this build things that work on the day they are demonstrated.

Ask what they would do with imperfect data. The correct answer involves scoping the data work explicitly, not absorbing it as an assumption. A partner who does not raise data quality unprompted has not built many production systems.

Ask who specifically works on it. Named people, available, with continuity through the engagement. This predicts outcomes here more strongly than any certification.

Ask when they would recommend not using a model. The best answer is a real example. A partner whose answer to every problem is a model is selling capacity, not judgement.

Step 3 — Structure the engagement so capability transfers

The structural question is whether you end up with a capability or a dependency. It is decided by the contract, not by goodwill.

Who owns the model, the training data and the pipeline? Write it down. “We built it for you” and “you own it” are different statements.

What documentation do you receive? Enough for your own team to retrain, redeploy and debug — or enough to admire.

Who holds credentials and infrastructure access? If only the partner can deploy, you have a dependency regardless of what the contract says about ownership.

What does exit look like? Data export, handover, a notice period that allows transition. For FINMA-supervised businesses this is a requirement rather than a precaution.

Governance belongs in the contract

For DACH companies this is not optional and it is frequently omitted from AI engagements.

Under the EU AI Act, a system influencing employment, creditworthiness, essential services or safety is high-risk and requires documented data governance, technical documentation, logging and defined human oversight. That catches Swiss companies whose output reaches EU users — the Act follows the market, not the company’s address.

Under revDSG/nDSG and GDPR, automated decisions affecting individuals have to be explainable, and the provenance of training data has to be demonstrable.

None of this can be produced retrospectively. So the partner has to produce it as they build, and that expectation belongs in the statement of work rather than in a conversation after the audit. Ask directly: what artefacts do we receive that we would need to show a regulator?

Start small, with a defined end

Whatever the selection process concludes, the most informative step is a first engagement that is small, real and time-boxed — one use case, a defined outcome, a fixed end date.

It tells you more about how a partner works than any reference call, and it costs a fraction of discovering the same thing during a programme. That is exactly the shape of the AI Sprint: one process, fixed scope and price, a working application on your own data, with the code and hosting staying with you.

Related reading

• Six AI adoption challenges Swiss companies hit
• What makes a great AI team: the skills that matter
• The EU AI Act is enforceable: what DACH CTOs should do now

If you are running a selection and want the shortlist pressure-tested, book a call. No obligation.