How Far to Insource AI: Drawing the Line Against Outsourcing

Hello, this is Ryuta Hamamoto from TIMEWELL.

"We should be insourcing AI, right?"

I get asked this a lot, and it is hard to answer. Insourcing is a means, not an objective, so the answer depends on what it is a means to.

You do not need everything in house. Equally, handing it all over causes its own problems. The question is where the line goes. This piece is about drawing it, from the buyer's side.

The short version:

• Insourcing is not the objective. The axes are how often it changes, and how much operational knowledge matters
• Almost no company needs to build its own model
• Assume you are short of people. 85.5% of firms are short of people to drive DX
• When outsourcing, ask for the reasoning, not just the deliverable
• The core of insourcing is not technical capability. It is holding the ability to decide

The word covers too much ground

Split the term first. "Insourcing AI" mixes about five different layers.

1. Building the model. Training a foundation model in house. Almost no company needs this. The costs and the people are an order of magnitude apart.

2. Tuning a model on your own data. Additional training, fine-tuning. Worth checking first whether retrieval gets you there.

3. Building the application. Screens and processing fitted to the work. This is where you build if nothing off the shelf fits.

4. Embedding it in the work, and operating it. Where in the process it gets used, where a human checks, what happens when accuracy degrades.

5. Deciding how it gets used. What to delegate, what not to, how to verify output.

Insourcing debates go in circles because people are talking about different layers. For most companies, 4 and 5 are what matter, and 1 and 2 are irrelevant.

And 4 and 5 are the layers that are intrinsically hard to outsource, because they cannot be decided without knowing the business.

Two axes are enough

I keep the criteria simple. Two axes.

Axis 1: does it change often?

Anything you want to adjust weekly belongs inside. If a single change needs a quotation, a purchase order, and two weeks, improvement stops.

Getting value out of AI never works first time. Adjust the prompt, swap out the reference material, change the review step. The number of those small loops determines the outcome. If every loop requires external capacity, you cannot run enough of them.

Conversely, insourcing something you touch once a year buys you almost nothing.

Axis 2: can it be decided without operational knowledge?

"Is this quotation reasonable?" "Is this the right way to phrase it for this customer?" "Can this step be skipped?" An outsider cannot make these calls, and teaching the basis for them is itself hard.

Meanwhile, "which model do we use," "how is the infrastructure configured," "how does authentication work" can all be settled without knowing the business. Those go outside without issue.

Split on those two and it usually falls out like this.

	Changes often	Changes rarely
Needs operational knowledge	Insource (top priority)	Lean insource; keep the criteria inside
No operational knowledge needed	Insource, or an outsourcer who can move fast	Outsource

Top left is what belongs inside. And because that is about operational knowledge rather than technical skill, it usually sits with people close to the work rather than with IT.

Being short of people is the premise

Every insourcing discussion reaches "we don't have the people."

Which is true. In IPA's survey published in July 2026, covering 1,799 Japanese companies, 85.5% described themselves as somewhat or severely short of people to drive DX¹.

The same survey shows a majority reporting shortages across most categories of AI-related talent, with a persistently high shortage of employees who combine operational knowledge with basic AI literacy and can drive AI adoption inside the company¹.

That is precisely the profile needed for the top-left box. The scarcest capability is the one that most needs to sit inside.

Which inverts the conclusion. Being short of people is a reason not to insource everything. Concentrate the few you have in the top left and send the bottom right out. Try to bring it all inside and nobody is left where it matters.

When outsourcing, ask for the reasoning

For the part that goes out, settle something at contract time.

Ask for the reasoning, not just the deliverable.

Being given something that works is table stakes. The issue is what comes after: without why the design is what it is, and what was tried and rejected, every future change starts with explaining everything from scratch.

Concretely, put these in the contract:

• Documentation including the rationale for design decisions
• Options considered and rejected, with reasons
• The metrics to watch in operation, and what to do when they degrade
• Enough information for a different supplier to take over

The fourth matters. Do not create a state only one company understands. This is not about distrust — people move on, and strategies change.

One more. Always have at least one person from your side working alongside them. Hand it all over and receive only the deliverable, and the next change is another procurement. With one person who was in the room, you have an internal point of contact, and the next engagement gets smaller.

The core of insourcing is not technical skill

This is the part I most want to land.

Insourcing is usually pictured as hiring engineers so you can build things. That is part of it. It is not the core.

The core is holding the ability to decide.

• You can decide for yourselves which processes to apply it to
• When it does not work, you can form a hypothesis about why
• You can judge whether a vendor's proposal is reasonable
• You can judge when to stop

Get those four and you are effectively insourced even with the implementation outside. Conversely, if you build everything in house but let a vendor decide what it is for, that is not insourcing.

Getting to the point of judging requires some hands-on exposure. Outsource everything and that exposure never happens. That is the real cost of handing it all over: not the missing technical skill, but the judgement that never develops.

How to start

A realistic sequence.

1. Inventory what currently goes outside. What, at what cost, changed how often. Anything where changes take a long time is an insourcing candidate.

2. Pick one top-left item. Changes often, needs operational knowledge — exactly one. Bringing several inside at once usually fails.

3. Name one person and protect their time. Part-time on top of everything else does not move. State how many hours a week.

4. Ask the supplier to work alongside you. Not "please do all of it" but "do it with us so we can do it next time." That changes the contract, so raise it at the start.

5. Once it runs, pick the next one. One at a time, in sequence.

There is more on pilots in getting out of PoC limbo, and on organisational retention in why generative AI does not stick.

Through WARP we work in that "do it together so you can do it next time" shape. It takes longer than building and delivering, and the right outcome is that the next engagement is smaller.

In summary

• Insourcing is not the objective. The axes are frequency of change and operational knowledge
• Almost no company needs to build its own model
• Assume a shortage. 85.5% are short of people to drive DX
• Because of that shortage, do not insource everything. Concentrate the few in the top left
• Outsourcing should yield the reasoning, in a state another supplier could pick up
• The core of insourcing is holding the ability to decide, not technical skill
• Start with exactly one, with a named owner and protected time

To talk through where your line should sit, get in touch.

References

Footnotes

1. Key points on DX and AI adoption trends among Japanese companies (IPA, 16 July 2026, Japanese). The combined 85.5% describing themselves as somewhat or severely short of people to drive DX, and the persistently high shortage of employees combining operational knowledge with basic AI literacy, come from this material. 1,799 responses, fielded 17 April to 12 June 2026 ↩ ↩²