AI consultant, vendor or internal team: how to choose

In short. Choosing between an internal team, a solution vendor and an independent consultant does not depend on company size. It depends on three variables: how distinctive the AI capability is for your business, how sensitive the data involved is, and how governable the result must stay over time. Distinctive capabilities are built in house. Standard functions are bought. When the real problem is deciding what to do, in which order and under which controls, you need someone independent from the sale.

Many companies take this decision backwards: they pick the vendor first and then look for a problem to solve. The outcome is predictable: tools switched on, licences paid, real usage limited to a handful of enthusiasts.

The three models compared

Aspect	Internal team	Solution vendor	Independent consultant
Fits when	The capability is distinctive and recurring	The need is standard and widespread	Priorities, criteria and governance are missing
Time to first result	Longer, hiring dependent	Short, the solution already exists	Medium, depends on data quality
Dominant cost	People and maintenance	Licences and integration	Working days and skills transfer
Main risk	Under-resourcing and turnover	Vendor lock-in	Theoretical deliverables with no application
What stays in the company	Knowledge and code	Configuration and data in the system	Documents, criteria and skills
Conflict of interest	None	Present, sells what it recommends	None if no licences are resold

None of the three is better in absolute terms. Most organisations end up with a combination: an advisor to set priorities and controls, vendors for standard functions, and a small internal core for what should not be delegated.

The question that comes first

Before choosing a model, decide whether the capability is distinctive. The test is simple: a capability is distinctive if a competitor copying it would erode your advantage. Drafting internal communications rarely qualifies. A prioritisation model built on your historical data, your operating rules and your sector language often does.

Distinctive capabilities should be built or at least controlled internally, because they live on continuous iteration and tacit knowledge. Standard capabilities should be bought, because building them internally means paying twice for the same work.

Decision matrix

Score each initiative from 1 to 5 on four dimensions:

1. Distinctiveness: how much the capability affects competitive advantage.
2. Data sensitivity: how confidential or personal the data involved is.
3. Usage frequency: how often the activity repeats.
4. Available skills: how capable the internal team is of maintaining it.

Typical readings:

• High distinctiveness, strong skills: build internally, with external support only in early phases.
• High distinctiveness, weak skills: build with hands-on support and an explicit skills transfer plan.
• Low distinctiveness, high frequency: buy, negotiating data portability and exit terms.
• High sensitivity in any scenario: the model choice follows the definition of controls, not the other way round.

The matrix does not produce an automatic answer. It makes the reasoning explicit and lets different functions argue from the same basis.

How to evaluate a vendor

A solution vendor is the right choice in many cases, provided you examine what surfaces after signature:

• Where the data sits and who can access it.
• Whether data is used to train models, and how to opt out.
• Which technical documentation is supplied to satisfy internal and external obligations.
• What happens to data and configuration if the contract ends.
• How much notice applies to changes in underlying models, pricing and usage limits.
• Which quality metrics are measured and shared.

Those answers, in writing, are worth more than a demo.

How to evaluate a consultant

The decisive criterion is independence from the sale: whoever recommends a technology and earns a margin on it is not in a position to advise against it. Few questions are needed:

1. Do you resell licences or hold channel agreements with vendors?
2. Which documents stay in the company at the end, and who maintains them?
3. How do you measure skills transfer to internal people?
4. What do you do if the analysis shows the project is not worth running?
5. Who actually works on the project, and how present are they?

Question four is the most revealing. An engagement that cannot end with "this is not worth doing" is not assessing anything: it is selling.

When to build an internal team

An internal core becomes sustainable when three conditions hold: a continuous flow of use cases, accessible data of reasonable quality, and a function that answers for outcomes. Without the third condition the team produces prototypes nobody adopts.

Start small, with two or three people combining process knowledge and technical skill, and grow on the basis of completed use cases rather than growth forecasts.

A hypothetical example

A manufacturer is weighing three initiatives: assistance in drafting internal documents, complaint analysis, and maintenance prediction. The first has low distinctiveness and high frequency: buy. The second touches customer data and needs internal rules: buy with additional controls, or build, depending on sensitivity. The third depends on proprietary historical data and affects cost directly: build, with initial support. This example is illustrative and shows the reasoning; it is not a measured result.

Next step

The choice becomes straightforward once priorities are clear and internal skills are honestly mapped. You can read our approach on the How we work page, see what an AI consulting project should deliver, or start with a self-assessment of your company.

For a direct discussion of your case, you can book an assessment meeting.