AI Consulting vs In-House AI Team: How to Decide

The decision is not really "consulting or in-house". It is a sequencing decision: what do you need to know before you are willing to put someone on the payroll for it? Companies that hire first and validate later end up with expensive specialists maintaining a use case nobody asked for. Companies that outsource everything indefinitely end up renting a capability they meant to own.

This guide compares the two routes on the seven factors that actually decide it, adds the middle path most European SMEs end up taking, and ends with a mapping from your situation to the next step. It assumes you are a mid-sized company in healthcare, manufacturing or a comparably regulated sector, considering your first or second serious AI system.

Should you hire an AI consultancy or build an internal AI team?

Hire an AI consultancy when the problem is still a question, and build an internal AI team when it has become a routine. The reason is not quality of people: it is that an internal team is a fixed commitment made in advance, while an engagement is a variable one made against a defined scope. Before a use case is validated you do not yet know which specialists you need, so hiring commits you to a guess. Once a system is in production and earning, the maths inverts: a permanent team amortises across many projects and accumulates domain knowledge that no external party can match. The comparison below is how the two routes differ on the factors that decide real cases, with the middle path included because it is what most mid-sized companies actually choose.

Two rows decide most real cases: time to first production use case, and hiring risk. The rest tend to be negotiable.

What does an internal AI team actually commit you to?

An internal AI team commits you to fixed costs starting immediately and useful output starting much later, and the gap between those two dates is where most disappointment lives. A minimum viable team is usually three people, a data scientist, an ML engineer and someone who owns the data pipelines, because one person covering all three is a single point of failure rather than a team. Sourcing senior machine learning people takes months in the German and wider European market, notice periods add more, and new hires need time with your data and domain before their output is trustworthy. Then someone has to lead them: an AI-literate manager who sets priorities and says no, which is a second hire most plans quietly omit. None of this argues against building a team. It argues against building one before the work exists to justify it, because the team you hire will define the roadmap it needs to stay busy.

When an internal team is clearly right

Build internally when AI is the product rather than a support function, when several systems are already running and generating a steady stream of work, or when data restrictions make external access genuinely impractical. In those cases the fixed cost is amortised across enough projects to beat engagement pricing, and the domain knowledge compounds.

The failure mode to avoid

The expensive mistake is hiring against an unvalidated use case. The team arrives, discovers the data does not support the original idea, and pivots to something that justifies its existence. You now have a capable team, a roadmap shaped by hiring rather than by strategy, and a budget holder asking what changed.

What does working with an AI consultancy actually commit you to?

An AI consultancy commits you to a scope and a timeline rather than to headcount, which is why it suits an unproven use case and suits a mature one badly. You get people who have already built similar systems, so the first production use case is weeks away rather than quarters, and if the idea turns out not to work you stop. What you take on instead is dependency risk: if nothing is written down and no one on your side was involved in the build, the knowledge leaves when the engagement ends. That is a contracting problem, not an inherent flaw. Documentation, handover and your own engineers working alongside the external team are things you specify in the scope, and a partner who resists that is telling you something useful. Judge the engagement on whether it leaves you more capable, not only on whether it ships.

What to write into the scope

Name the deliverables that outlive the engagement: assignment of code and model weights, an architecture record, runbooks for the system in production, and named people on your side who are part of the build. Without those, you have bought an outcome rather than a capability, which is fine if that was the intention and expensive if it was not.

How does this decision play out in healthcare?

In healthcare the deciding factor is usually not capability but governed access to data. A clinic or medical software company weighing an internal team against a partner is really asking who is allowed to touch patient records, under what agreement, and who can evidence that afterwards. Health data is special-category data under Article 9 of GDPR, large-scale processing normally requires a data protection impact assessment, and if the system supports diagnosis it may also be a regulated medical device. An internal team sidesteps the processor agreement entirely, which is a genuine advantage. A partner can work within it, but only with a documented basis, scoped access and audit logging, and for a first project the pragmatic answer is often to keep identifiable data inside your environment and let the external team work on de-identified or synthetic data until the case is proven. Our healthcare AI practice covers the constraints in more detail, and the specifics of where GDPR and the EU AI Act overlap are worth reading before either route is chosen.

How does this decision play out in manufacturing?

In manufacturing the deciding factor is usually the plant, not the model. A vision inspection or predictive maintenance system lives or dies on line access, sensor data quality, PLC and MES integration and whether operators trust it enough to act on it, and none of those are solved by whoever writes the model. That favours an engagement for the first system, because an external team that has integrated with production lines before will find the constraints in weeks that an internal hire discovers over months. It favours an internal team later, once the integration patterns are established and the work becomes a steady stream of new lines and new defect classes rather than a research question. The ratio that matters is how much of the effort is modelling versus integration: when integration dominates, and it usually does, domain access beats specialist recruitment. Our manufacturing AI practice describes that work.

Which route fits your situation?

Match your situation to the next step rather than to a philosophy, because the same company often needs different answers for different use cases. Four situations cover most cases:

1. The opportunity is unclear, or you are unsure the data supports it. Start with an AI Readiness Audit. It tells you which use case is worth building and whether your data can carry it, before either a hire or an engagement is committed. Hiring at this stage is the most expensive way to find out.
2. The use case is defined but unproven. Run a scoped proof of value. One narrow system, a baseline measured before it starts, a threshold someone has signed, and permission to stop. Our service packages include exactly that shape of engagement.
3. You have something in production and need it owned. This is where a Fractional AI Lead fits: senior ownership of roadmap, architecture and vendor decisions, without a full-time leadership hire, while your own engineers do the building.
4. AI is central and the workload is continuous. Build the internal team, and consider keeping external support for the specialist work that does not justify a permanent role. If you want the transition supported, we structure engagements to hand over rather than to renew.

If you are between the first two, assessing readiness costs less than guessing, and the return you should realistically expect is worth knowing before you size either option.

Does the right answer change as you grow?

The right answer changes roughly once a year for a company actively adopting AI, which is why treating it as a permanent identity choice is the underlying mistake. A realistic path runs: audit to find the use case, an external team to prove it, a fractional lead to own it while your engineers learn it, and a permanent team once the workload is continuous enough to keep one busy. Each step should make the next one cheaper, and the test of the previous step is whether it left you more capable rather than more dependent. Companies that go straight to a permanent team usually pay for the validation anyway, in the form of a first year spent building the wrong thing competently. Avoiding that is mostly a matter of sequencing, which is also the theme of the five mistakes companies make integrating AI.

Frequently asked questions

How long does it take to build an in-house AI team?

Longer than most plans assume once you count sourcing, notice periods, and the months before a new team is productive together. Senior machine learning hires in particular are slow to find and easy to lose, which is why the first project usually cannot wait for the team.

Does using a consultancy mean we never build internal capability?

Only if the engagement is structured that way. A good arrangement puts your engineers alongside the external team and makes documentation and handover explicit deliverables. Capability transfer does not happen by proximity; it happens because someone wrote it into the scope.

Who owns the code and the models we pay a consultancy to build?

Whoever the contract says, which is why it belongs in the scope rather than in an assumption. Ask for assignment of the code, the trained model weights and the architecture documentation on delivery. A partner who cannot commit to that is offering you access to a system rather than ownership of one.

What is the risk of building in-house too early?

Hiring for a shape of problem you have not defined yet. Teams recruited before the first use case is validated frequently end up building the wrong thing competently, and the cost is not just salary but the roadmap those hires justify to protect their own remit.

Is the hybrid model just a compromise?

It is usually the strongest option rather than a middle ground. External senior direction with internal execution gets the architecture decisions right early while the knowledge accumulates where it has to live long term, which neither pure model achieves on its own.