Owning a model on your data.

What this actually involves

Owning a model means taking a base model that already exists - from one of the major labs, or from the open-weights ecosystem - and adapting it to your data. The base model brings general capability; your data brings specificity. The output is a model that is yours to deploy, yours to govern, and yours to keep up to date.

"Adapting" covers a spectrum. At the lighter end: building a retrieval system that pulls relevant context out of your data into the prompts the base model sees. In the middle: structured prompting and tool wiring that bakes your operational specifics into how the model is called. At the heavier end: fine-tuning, where the model's weights themselves are updated on your examples until it has internalised your domain.

The data question is the whole question

The case for door two depends entirely on whether your data is actually a moat. There are two versions of this:

• Real moat. Your data exists because of specific operations, regulatory positioning, or customer relationships that competitors cannot easily replicate. Years of underwriting decisions on a niche product. Sensor logs from a manufacturing process you have refined. Annotated specialist legal corpus. The data itself encodes hard-won know-how.
• False moat.Your data is large, but it is the same kind of data your competitors have. Generic CRM records, public-domain documents, transaction logs that look much like everyone else's. Fine-tuning on this kind of data rebuilds capability that the public models already have, at your cost.

Most organisations have both. The skill is in identifying which subset is actually rare. Owning a model on the rare subset can pay back. Owning a model on the generic subset is an expensive way to feel busy.

What it costs

The visible costs: compute for fine-tuning, infrastructure for inference, an evaluation harness that tells you whether each new version is actually better. Lighter than door one, measured in months not years. Heavier than door three, measured in tens of thousands of pounds at the low end and millions at the high end depending on scale.

The hidden costs are about staying current. Every six months the base models advance. Every twelve months the techniques for adapting them shift. A custom model is a thing you have to keep alive. If your team cannot retrain when the world moves - because the people left, or the budget got cut, or the evaluation harness was never finished - your moat erodes quietly until one day a competitor on door three overtakes you.

When it is the right answer

Door two is the right answer when:

• Your data is genuinely rare, in a domain the public models cover only weakly.
• The task you want the model to do is high-volume - frequent enough that the cost of building a custom system pays back against running the workload through a generic model.
• You can fund maintenance for the long term, not just the build.
• You have, or can build, an evaluation harness that lets you tell whether each version is actually doing the job better than the last.
• You are willing to walk away if the experiments do not pay back. (This is the test most organisations fail.)

The cheaper version of door two

A lot of the value people imagine they need fine-tuning for can be captured with retrieval and structured prompting alone - without ever updating the base model's weights. The base model brings the language and reasoning. Retrieval brings your data into the conversation when it is relevant. The model never had to "learn" your data; it just had to be able to look at it when needed.

This is sometimes called RAG - retrieval-augmented generation. It is the workhorse pattern for door three as well, and it is often the right first step for organisations that think they need door two. Test the retrieval pattern thoroughly before committing to fine-tuning. If retrieval alone gets you 90% of the value, the remaining 10% may not be worth the maintenance cost of a custom model.

What we do here

We help organisations make the door-two decision honestly. The work usually starts with a data audit: what is actually rare, what could be assembled into a training or retrieval corpus, what is generic. From there, we run the cheaper experiment first - retrieval-only on the rare data - and only commit to fine-tuning if the retrieval ceiling is genuinely below what the use case needs.

For most organisations we work with, this turns into a focused door-three programme using their proprietary data through retrieval, with a clear option to graduate to fine-tuning if and when the evidence justifies it. That is usually the right shape.

One conversation, no commitment. We listen first, then suggest a path.