AI decisions Sourcing: build, buy or partner
In-house team, AI consultancy or platform: who should build your AI?
Buy a platform when the need is standard and a product already solves it; build an in-house team when AI is part of your core advantage and you have a steady backlog; bring in a consultancy when you need to move faster than you can hire on a hard, cross-functional case and want the capability handed over. Most organisations end up combining the three, and the real decision is what goes where. A consultancy that does not plan its own exit is the most expensive option of all.
The options
In-house team
Your own people design, build and operate the AI systems, with full ownership of code, data and decisions.
AI consultancy
An external firm brings strategy, design and engineering for a defined scope and, if done well, transfers the capability to your team.
Platform
A packaged product, SaaS or licensed, that covers a use case or provides the base to build on, maintained mainly by the vendor.
Side by side
| Criterion | In-house team | AI consultancy | Platform |
|---|---|---|---|
| Time to first value | Slow if you must hire first | Fast if the firm has solved similar problems | Fastest when the use case fits the product |
| Ownership of IP and know-how | Full | Depends on the contract and on real knowledge transfer | Low: you own configuration and data, not the product |
| Fit to your process | As high as your team can build | High: designed around your process | Limited to what the product supports |
| Scaling across use cases | Grows with headcount | Grows with budget; risk of dependency | Grows within the vendor's roadmap |
| Cost profile | Fixed salaries and a long ramp-up | Project-based and variable | Subscription or usage; predictable at first, can grow with adoption |
| Main lock-in risk | Knowledge concentrated in a few key people | Dependence on the firm if there is no handover | Vendor lock-in on data, workflows and models |
| EU AI Act role | Usually provider of what you build, deployer of what you use | If the system is built for you and you put it into service under your name, you can be the provider | Usually deployer; the vendor is the provider |
| Governance and auditability | Your standards, if you have them | Brought by the firm; your team must absorb them | Depends on the vendor's documentation, logs and contract |
| Best at | Core, differentiating capabilities | Hard first cases, cross-functional change and capability building | Standard, commoditised needs |
Choose In-house team when…
- AI is part of your product or your core advantage and you need to own it for years.
- You already have engineering, data and product leadership able to attract and keep AI talent.
- Your backlog is steady enough to keep a team busy and learning.
- Confidentiality or regulation make it hard to involve third parties in the core.
Choose AI consultancy when…
- You need to move faster than you can hire, on a case where an outside team has relevant experience.
- The challenge is cross-functional: strategy, process redesign, data, engineering and governance at once.
- You want to build internal capability and need a partner to co-build and hand over, not just deliver.
- You need an independent view of readiness, risk or architecture before committing budget.
Choose Platform when…
- The use case is standard (meeting notes, writing assistance, ticket summaries) and a product already does it well.
- Speed and low operating effort matter more than differentiation.
- You accept the vendor's roadmap and can live with its limits on data, models and integration.
- You have checked data location, logs and contract terms against your GDPR and AI Act needs.
When to combine them
Most organisations end up with all three: platforms for commodity needs, an internal team that owns the architecture and the critical use cases, and a partner for acceleration and specialist gaps. The rule of thumb is to buy what is standard, build what differentiates, and bring in outside help with a written handover plan, so dependency falls over time instead of growing.
Common mistakes
- Hiring a consultancy for a need that a mature product already covers.
- Outsourcing without knowledge transfer, so every change needs the same supplier.
- Buying a platform for a differentiating process and then bending the process to fit the tool.
- Building an internal team around one or two key people, with no documentation or shared platform.
- Ignoring who becomes the provider under the EU AI Act when a system is built to measure.
How Thinkia approaches it
We are a consultancy, so read this with that in mind. Our honest position: for standard needs a platform is usually the right answer, and we say so. Where we add value is on the cases that cross strategy, process, data and engineering, and on building a capability your team will keep after we leave.
We work as one team with yours and design the exit from the start: code and documentation in your repositories, evaluation sets you own, runbooks and a dated handover. In the Thinkia AI Compass Framework, the Human Amplifier dimension and the AI Champions inside business lines exist precisely so that adoption and know-how stay in the organisation.
We also build products, and we are clear about when they fit. Synapse is a model-agnostic platform for governed agents, model routing, RAG on your own infrastructure and cost dashboards; it makes sense when you want to own your AI layer without building it from scratch, not as a mandatory add-on to every project. We are vendor-agnostic on models and clouds, so platform choices are made on your criteria, not ours.
Thinkia products involved
- SynapseGoverned agentic platform: agents, models, costs and data in one place.
- The MeshThinkia's five service layers: Innovation, Data, Experience, Platform, Autonomy.
Related AI solutions
Frequently asked questions
Is it cheaper to build an in-house AI team?
Not in the short term, and not always in the long term. An internal team pays off when there is a steady backlog of differentiating work. For occasional or standard needs, fixed headcount is harder to justify than a product or a well-scoped engagement.
When should we not hire an AI consultancy?
When a product already solves the need, when the scope is small enough for your own team, when AI is your core product and you will have to build the team anyway, or when the firm will not commit to knowledge transfer. Paying someone to build what you will never be able to maintain is the costliest choice.
How do we avoid becoming dependent on a consultancy?
Write the handover into the scope: co-development with your people, code and documentation in your repositories, evaluation sets you own and a dated handover milestone. If the firm resists, treat it as a signal.
Who is the provider under the EU AI Act if a consultancy builds our system?
The AI Act defines the provider as whoever develops an AI system, or has it developed, and places it on the market or puts it into service under its own name. If a system is built for you and you put it into service, you can be the provider, with the corresponding obligations if it is high-risk. Settle it in the contract and check with your legal team; this is not legal advice.
Can a platform cover regulated use cases?
Sometimes, if the vendor provides the documentation, logs, human oversight features and contractual commitments you need as deployer. Check data location, sub-processors, retention and how model changes are communicated before signing.
Keep exploring
Related decisions
- Build vs buy AI agents: which agents should you own, and which should you rent?
- AI pilot vs production: what actually changes when you scale?
- Microsoft Copilot vs custom AI agents: when is the suite assistant enough, and when do you need your own agents?
- EU AI Act provider vs deployer: which role are you, and what does each one owe?
- Single AI vendor vs multi-model strategy: should you bet on one provider?
Sectors where this decision comes up
Key terms
Thinkia articles
- Enterprise AI Strategy: Apple's Blueprint Ends the 'Build' Era
- Enterprise AI Strategy: The New Moat Beyond the API
- Vendor-Neutral AI: What Is an AI Application Server and Why It Matters
- Enterprise AI Strategy: A Guide to the AI-First Operating System