AI Consultancy vs In-House AI Team UK

Every AI vendor pitch ends the same way: “You need us.” Every internal champion’s pitch ends the same way too: “We should build the team ourselves.” Both are selling something. This guide does the maths with UK-specific numbers so you can make the call based on your situation, not someone else’s business model.

Most of the existing content on this topic comes from US or offshore consultancies using US salary data and US market assumptions. The UK market is different: smaller talent pool, different tax structure, IR35 considerations, and day rates that reflect London and regional cost variations. The numbers here are specific to the UK in 2026.

The actual cost comparison: UK salary benchmarks vs consultancy day rates

A senior AI/ML engineer in the UK commands £70,000 to £110,000 in base salary. That number is not the real cost.

Employer National Insurance, pension contributions, workspace, equipment, training budget, and management overhead push the total cost to employer to £90,000 to £140,000 per year. A junior or mid-level AI engineer sits at £45,000 to £70,000 in salary, with total cost to employer around £60,000 to £95,000.

UK AI consultancy day rates range from £800 to £1,500 depending on seniority and specialisation. RAG and LLM specialists command the higher end. Most firms also offer fixed-price project scoping as an alternative to day rates.

Here is where the comparison gets honest. Take a six-month project requiring senior AI expertise at three days per week. At £1,200 per day, that is roughly £93,600 in consultancy fees. Hiring one senior engineer at £100,000 salary costs approximately £65,000 for the same six months in total employer cost, but you will not have a productive senior engineer for six months. You will have a new hire still learning your codebase and domain for the first three to six of them.

The recruitment fee alone, typically 15 to 25 percent of first-year salary, adds £15,000 to £25,000 before your new hire writes a line of code. Factor in three to six months of reduced productivity during onboarding, and the first-year effective cost of a senior hire is closer to £130,000 to £180,000 when you account for the output gap.

Neither option is cheaper in absolute terms. The question is what you get for the money and when you get it.

There is also the cost nobody calculates: management time. A new hire needs onboarding, one-to-ones, performance reviews, career development conversations, and someone senior enough to evaluate their technical decisions. If you do not already have an AI-literate technical lead, you are asking a non-specialist manager to supervise specialist work. That gap shows up in delayed projects, not in the salary budget.

A consultancy engagement, by contrast, comes with its own management layer. You define what you want built, agree on milestones, and review deliverables. You do not manage the individuals doing the work. For companies without existing AI leadership, this difference in management overhead is often the deciding factor, even when the raw numbers favour hiring.

For a full breakdown of what AI projects cost in the UK and where the budget actually goes, see our AI development cost guide.

Time to first working software: 60 to 90 days vs 6 to 12 months recruiting

The UK AI talent market is tight. Hiring a senior ML engineer with production experience takes three to six months if you are lucky. That timeline assumes you have a compelling offer, a clear role definition, and a recruiter who understands the difference between someone who has trained a model in a notebook and someone who has deployed one to production.

Many companies underestimate how long the hiring process really takes. Writing the job description, briefing recruiters, reviewing CVs, running technical interviews, negotiating offers, and waiting out notice periods add up. A three-month recruitment timeline is optimistic for senior roles. If your first-choice candidate declines or fails the technical assessment, you are back to month one.

A consultancy engagement typically delivers a first working system in 60 to 90 days from kickoff. That includes discovery, proof of concept, and initial production deployment. The speed difference is not just about availability. An established consultancy brings existing frameworks, reusable infrastructure, and pattern recognition from previous projects that a newly hired engineer, however talented, does not have on day one.

This matters when the business case has a deadline. If the board approved budget in Q1 and expects a working proof of concept by Q3, you do not have time to recruit, onboard, and then start building. A consultancy compresses that timeline because the team is already assembled and experienced with the technology stack.

There is also a compounding effect with in-house hiring that people overlook. Your first AI hire works alone, without peers to review their work, debate architectural decisions with, or cover when they are on leave. A team of one is fragile. A consultancy, even a small one, brings a team with complementary skills and built-in redundancy from day one.

But a consultancy delivers a project. An in-house engineer builds ongoing capability. A project ends. Capability compounds. These are fundamentally different investments, and confusing them is how companies end up disappointed with either option.

What you lose with a consultancy

This is the section that most consultancy websites skip. Here is what you are actually trading away.

Institutional knowledge leaves when the engagement ends. Your consultancy partner understands the design decisions, the edge cases, the reasons behind specific architectural choices. When they move to their next client, that knowledge goes with them. Documentation helps. It does not fully replace the person who built the thing.

IP ownership requires explicit contractual protection. Most reputable consultancies assign IP to the client by default in the contract. Not all do. If your agreement does not explicitly state that you own the code, models, and data artefacts produced during the engagement, you have a problem. Read the contract before you sign, not after.

Dependency risk is real. If one consultancy builds your entire AI stack and you have nobody internally who understands it, you are dependent on that firm for every change, fix, and upgrade. This is not a theoretical risk. It is the most common failure mode we see in organisations that outsource AI work without a handover plan.

Handover quality varies wildly between firms. Some consultancies produce comprehensive documentation, run knowledge transfer sessions, and pair with your engineers during a transition period. Others deliver a Git repository and an invoice. The handover plan should be a line item in your statement of work, not an afterthought discussed in the final week.

You lose the ability to pivot quickly. An in-house engineer sitting ten feet from your product team can shift priorities in a day. A consultancy operates against a statement of work. Changing scope mid-engagement means renegotiating timelines and cost, which introduces friction that slows you down exactly when you need to move fast.

Cultural integration does not happen. External teams do not attend your all-hands, do not understand your internal politics, and do not have the context that comes from being embedded in your organisation. For projects that require deep understanding of how your business actually operates (not just how the API works), this gap can produce technically correct systems that nobody wants to use.

When in-house makes sense

There are situations where building an internal AI team is clearly the right move. Trying to solve these with a consultancy creates more problems than it solves.

AI is your product. If artificial intelligence is the core of what you sell, not a tool that supports your operations, you need permanent staff who live inside the problem domain every day. No consultancy can substitute for a team that eats, sleeps, and iterates on your core product.

You need daily model iteration. Some use cases require continuous experimentation: retraining models on new data, testing new architectures, adjusting outputs based on user feedback in near-real-time. This cadence of work does not fit a consultancy engagement model. It requires dedicated engineers with full context.

You are planning to hire five or more AI engineers within two years. If your AI ambitions are that large, start recruiting now. The lead time to build a team of that size in the UK is 9 to 18 months, and each hire gets harder as you compete for a shrinking pool of experienced candidates. Waiting until you “need” the team means you are already a year behind.

You have the management capacity. This is the constraint companies underestimate. An AI team needs technical leadership, clear priorities, and integration with your product and engineering organisation. If you do not have a technical leader who can manage AI engineers effectively, hiring them creates a team without direction.

Your data and infrastructure are ready. Building an in-house team only makes sense if they have something to work with. If your data is scattered across spreadsheets and legacy databases with no API access, your first hire will spend six months on data engineering before touching any AI work. That is demoralising for a senior ML engineer and expensive for you. Sort the foundation out first, whether internally or with outside help, then hire the team to build on it.

When a consultancy wins

Equally, there are situations where hiring full-time is an expensive way to solve what is actually a bounded problem.

The project has a clear scope and end date. A RAG system over your knowledge base. An AI agent that automates a specific workflow. A voice AI integration for your contact centre. These are defined deliverables, not open-ended research programmes. Hiring a permanent engineer for a six-month project means you are paying for the role long after the project is done.

You need production-quality output before you can justify headcount. This is the chicken-and-egg problem most mid-market companies face. The board wants to see AI delivering value before approving headcount. A consultancy delivers that proof point. A recruitment process delivers a candidate in six months and a working system sometime after that.

The skill required is niche and will not be needed full-time. Computer vision, voice AI, MLOps infrastructure, compliance-grade AI systems. These specialisms command premium salaries. If you need three months of deep expertise in one of them, paying a full-time salary for the other nine months is waste.

Your compliance requirements demand certified processes. If your project requires ISO 27001 certified development practices or specific security controls, a consultancy that already holds those certifications saves you the time and cost of building that capability internally. You inherit their compliance posture for the duration of the engagement.

You want to validate the opportunity before committing headcount. A consultancy engagement is reversible in a way that hiring is not. If you engage a consultancy for a three-month proof of concept and the results are underwhelming, you have spent £30,000 to £50,000 and learned something valuable. If you hire a senior engineer and the initiative does not work out, you are looking at redundancy processes, notice periods, and £100,000+ in sunk cost before you can redirect.

The hybrid model: consultants build, your team scales

Most companies that succeed with AI in the long term do not pick one model and stick with it. They sequence them.

The pattern that works: engage a consultancy for the initial build, insist on a structured knowledge transfer, and hire your first in-house AI engineer during the engagement so they can learn the system as it is being built. The consultancy leaves behind a working system and a team member who understands it.

The handover plan matters more than the build plan. A technically excellent system that nobody internal understands is a liability, not an asset. When evaluating consultancies, ask how they handle transition. Ask for references from clients who successfully brought work in-house after the engagement ended.

The hybrid model also works in reverse. Companies with established AI teams bring in consultancies for specific capabilities they lack internally, or to handle capacity spikes without permanent headcount increases. This is staff augmentation, and it is a different commercial model from project-based consulting.

What does a good handover actually look like? At minimum: documented architecture decisions, runbooks for common operations, a recorded walkthrough of the codebase, and at least two weeks of paired working between the consultancy team and your internal engineer. The gold standard is a consultancy that writes themselves out of the engagement, making your team self-sufficient rather than dependent. Ask prospective partners what their last three handovers looked like. If they cannot answer specifically, that tells you something.

The sequencing also matters commercially. If you hire your first AI engineer at the same time you engage a consultancy, that engineer’s salary overlaps with the consultancy fees for three to six months. Budget for this overlap deliberately. The alternative, hiring after the consultancy leaves, means your new hire inherits a system they did not build and did not watch being built. The learning curve is steeper and the risk of misunderstanding architectural decisions is higher.

IR35 and the contractor question

If you are considering engaging individual AI contractors through their own limited companies rather than a consultancy firm, IR35 status must be assessed. Since the 2021 off-payroll working rules, the responsibility for determining employment status sits with the hiring organisation for medium and large businesses.

Most consultancy firms, including OpenKit, operate as B2B service providers delivering defined project outcomes. IR35 does not apply to these engagements because the relationship is between two businesses, not an employer and a disguised employee. If you engage an individual contractor, the assessment is more complex. Get your legal team involved before the engagement starts, not after HMRC asks questions.

The practical implication: if you are weighing between hiring a freelance AI contractor and engaging a consultancy firm, the IR35 question adds administrative overhead and financial risk to the contractor route. Inside IR35, the contractor’s effective cost to you increases significantly once you account for employer NI contributions. Outside IR35, HMRC may challenge the determination later. A B2B consultancy engagement sidesteps this entirely.

For more on what an AI consulting engagement actually involves and how to evaluate firms, see our guide to AI consulting for UK businesses.

Talk to us about your build-or-buy decision

If you are weighing this decision, we can help you think through it. We have built AI systems for companies that went on to hire internal teams, and we have augmented companies that already had strong AI capability but needed specific expertise.

We will be honest about whether a consultancy engagement is the right answer for your situation. Sometimes it is not. We have told prospective clients to hire internally when their requirements clearly called for a permanent team, and we have scoped consultancy engagements that explicitly included a transition plan to make us redundant within six months.

A conversation costs nothing, and we would rather point you toward the right approach than sell you the wrong one.

Scope a consultancy engagement or start a conversation about your project.