How to choose an AI implementation partner: 10 questions

Choosing an AI implementation partner means assessing more than a demonstration or a list of model names. The partner needs to understand the business decision, work with the available data and explain how the system will be tested, operated and maintained.

The right choice depends on the project. A software team, a specialist consultancy and an internal team can each be suitable. Labels such as “AI studio” do not establish competence, and company size alone does not establish reliability.

Use the following questions to compare proposals against the work you need done.

1. What problem are we solving, and does it need AI?

Ask the team to describe the current process, the intended outcome and the alternatives. A rules-based workflow, better integration or a simpler interface may address the problem without a model.

A useful proposal distinguishes the business outcome from the technology. “Reduce avoidable re-entry of order data” can be evaluated. “Add an AI agent” leaves the purpose unclear.

2. What evidence supports your experience?

Ask for relevant examples, the team’s role and an explanation of how a system was evaluated in operation. Where results are shared, ask about the baseline, measurement period and limits of attribution.

Confidentiality agreements can restrict both client names and project details. Lack of a public case study does not prove lack of experience. Alternative evidence can include a permitted reference call, an anonymised technical walkthrough or a demonstration using non-confidential data.

Do not treat a prototype and an operational system as interchangeable. Equally, a production system need not run around the clock or have the same service requirements as every other system.

3. How will you assess the data?

The answer should cover availability, permissions, quality and relevance to the intended use. For predictive work, ask how targets are defined and how the team will prevent information from the future leaking into evaluation.

For document retrieval or an assistant, ask about source quality, access restrictions, update procedures and test questions. A large collection of documents does not automatically make a useful RAG system.

The assessment can be proportionate to the project. What matters is that assumptions are tested before expensive commitments depend on them.

4. Who will do the work?

Ask which roles are needed and who will be responsible for each. Depending on the project, these may include process analysis, software engineering, data preparation, model evaluation, security and user research.

Request relevant experience and expected availability. Clarify subcontracting, handovers and what happens if a key person changes. A long list of tools or certificates is less useful than an explanation of how the proposed team will deliver this scope.

5. How will success and failure be measured?

Agree a baseline and acceptance criteria before testing the solution. Accuracy alone may hide costly errors or an imbalanced dataset. Discuss precision, recall, false positives, response quality or other measures appropriate to the task.

Separate model performance from business outcomes. A model can perform well on a test set without creating value if the surrounding workflow does not use its output effectively.

Ask what happens if the evidence does not support proceeding. A limited experiment can legitimately recommend stopping, changing the approach or collecting better data. A promise of a particular ROI before those questions are answered is not a substitute for evaluation.

6. What does an initial pilot establish?

A pilot should test a specific uncertainty with representative data and clear boundaries. Define its deliverables, exclusions, acceptance criteria and the decision it will support.

A fixed price can be appropriate for a well-defined scope; time-based billing can be appropriate for uncertain exploratory work. Neither model, by itself, demonstrates quality. Compare how uncertainty, spending limits and changes are managed.

A successful pilot also does not settle the cost of deployment. Integration, permissions, recovery procedures, training and ongoing operation may still require work.

7. How will privacy, security and legal responsibilities be handled?

Ask where data go, who can access them and what external services are used. Clarify retention, logging, incident response and responsibility for the client’s infrastructure.

The AI Act entered into force in August 2024, with obligations applying in phases. Assess the intended use and the roles of the organisations involved; a vendor brand or a human approval step is not a complete classification.

The technical team should be able to work with the organisation’s privacy and legal advisers. General claims of “GDPR compliance” or “AI Act readiness” need concrete scope and evidence. See GDPR and AI at work.

8. What happens after deployment?

Define who monitors availability, errors, costs and output quality. Decide when a change in data, model or business process requires reevaluation. Retraining is not automatically the right response to every problem.

Support arrangements should match the system’s importance. Ask about response times, escalation, maintenance, exclusions and the distinction between incident response and resolution. An SLA or contractual penalty does not, by itself, prove financial stability or delivery quality.

Make sure the operational owner has documentation, access and a recovery procedure. A system should remain understandable after the original project team moves on.

9. What rights, access and exit arrangements will we have?

Clarify ownership of newly created code, the timing of rights transfer and the licences governing existing libraries, models and third-party services. Access to a repository is not necessarily the same as ownership of every component.

Agree documentation, deployment instructions, credentials, data export and handover obligations. Code escrow may be useful in some arrangements, but it is not a universal replacement for working access and clear contractual rights.

Check whether another qualified team could operate or extend the solution and what migration would involve.

10. What drives the price and schedule?

Compare proposals using the same scope and assumptions. Include discovery, implementation, integrations, testing, training, infrastructure, licences, maintenance and future changes in the cost discussion.

Ask which dependencies may alter the schedule: data access, stakeholder availability, procurement, security review or integration constraints. An estimate should explain these assumptions instead of presenting one duration as standard for all AI projects.

For financial comparison, distinguish estimated benefits from guaranteed outcomes and include operating costs. NPV and IRR can help where the timing of cash flows matters.

Build a comparison that reflects your priorities

Use a simple evaluation sheet with evidence for each criterion: relevant experience, understanding of the process, evaluation plan, security, team, handover, support and total cost.

Set weights according to the project. A regulated decision system and an internal drafting tool may require different emphasis. Record unresolved questions alongside scores; a precise-looking total cannot repair missing evidence.

Warning signs include unexplained guarantees, unclear scope, inaccessible data flows and refusal to define ownership. Positive signs include testable assumptions, a clear operational plan and a willingness to recommend a simpler approach when it fits.

How QA10 structures the work

QA10 is a venture studio. Q-Dev provides custom software delivery. Q-Journey starts with an audit and can continue into software delivery, with or without AI, followed by further development of the business process.

Q-Dev projects have four gates: design, MVP, deployment, and training with the start of maintenance. Each gate includes a meeting and an acceptance document with the agreed number of corrections. After approval, two additional rounds of changes to the completed work are available at that gate. Changes outside the contract scope can affect the price; changes can also affect the schedule.

The first six months of maintenance are included. Rights to the code in Q-Dev and Q-Journey transfer after full project payment. Scope and dates are agreed individually. Book a 30-minute conversation to discuss the work you need.

FAQ

Does an SME always need an external AI partner?

No. The right approach depends on internal skills, the task and the capacity to operate the result. External support can fill specific gaps, but the organisation still needs an owner for the process and its outcomes.

Can we start with a small pilot?

Yes, if the pilot has a defined question, representative data and acceptance criteria. Its purpose is to inform a decision about further work. It does not guarantee a particular production cost, schedule or financial return.

How long should an AI implementation take?

There is no universal duration. Scope, data readiness, integrations, review requirements and client availability affect the schedule. Ask for an estimate that identifies assumptions, dependencies and decision points.

How should we compare competing proposals?

Use a common scope and compare evidence, responsibilities, acceptance criteria, total cost and ongoing operation. Set evaluation weights according to the project and keep unresolved assumptions visible.