The dead end of “we will just train our own model”

In 95% of conversations about deploying “your own AI”, business confuses the tool with the solution — and, worse, throws classic machine learning (ML) and large language models (LLMs) into the same bucket. When it comes to rollouts, precision in terminology is not academic nitpicking; it is the difference between a sound investment and a burned budget.

A bespoke model can make sense, but you need to know which category of tool you are choosing.

When your own model is your greatest asset (classic ML)

Before you get carried away with generative models, understand that in business you often need not a conversationalist but a ruthless classifier.

Imagine processing thousands of invoices every month. You need a system that recognises industry-specific names, reads line codes, and assigns them flawlessly to the right categories: capital expenditure, raw materials, operating costs. Pointing a general-purpose large language model (LLM) at that job is using a cannon on a fly — it will be expensive, slow, and you risk the model starting to invent answers (hallucinate).

That is exactly where training a narrow machine-learning model is a bullseye. You teach it on your data, load your closed vocabulary, and build an algorithm that is 100% deterministic. It costs a fraction of an LLM, runs in a fraction of a second, and does exactly one thing — but does it perfectly.

The language calculator (LLM models)

The picture changes when your problem is not simple classification but working with meaning. Language underpins business — from product specifications and client emails to source code (yes, that is language too).

That is where large language models step in (Gemini, GPT-4, Claude). They are “language calculators”. They grasp semantics and logic. Do not treat them as omniscient specialists; treat them as exceptionally capable concierges. A concierge will not calculate factory profitability on their own, but they will understand your question, extract the intent, and pass the task to the right narrow system.

The blind alley: “Let’s train our own LLM on company documents”

The company buys LLM licences. A year passes, adoption sits at 23%, the model has no data access, processes still limp along. Then comes the “brilliant” optimisation idea: let’s build our own model on our contracts!

It sounds sensible, but technologically it is a blind alley.

After training, a language model does not behave like a database. It does not store files it could quote from. It stores tokens in mathematical space. If you ask about a specific clause from a March 2023 agreement, at best it will generate something very similar. In business, “very similar” means financial loss. Training your own heavyweight LLM only makes sense when you have a huge team, millions for infrastructure, and knowledge the rest of the world does not have.

For work on documents, use RAG (Retrieval-Augmented Generation). You take a ready-made cloud model and attach a trusted knowledge base. The concierge does not guess — they go to the designated archive, read the document, return with an answer, and cite the source (page and paragraph). If the document is silent, the concierge stays silent too.

Orchestration: a concierge who knows where to look

The real shift is not the model itself but its integration with your environment. A concierge wired through APIs to your marketplace connector, CRM, ERP, and warehouse.

Utility is the key. The smartest system is worthless if it still needs manual copy-paste. Real automation lets a field salesperson dictate a meeting note while driving; the integrated stack extracts the action, updates the opportunity in the CRM, and sends a summary to the client. Before you build that, hard integration work awaits: access policies, process mapping, and wiring systems together.

Three questions before the budget

Before you spend on an AI rollout, answer three questions:

1. Is the problem algorithmic or decision-based? Do you have hard rules, a repeatable process, a specific vocabulary (e.g. invoice categorisation)? Deploy a narrow bespoke ML model or a rules engine built on if-then logic.

2. Is the problem linguistic? Is the core about understanding text, transforming documents, or customer service? Use a ready-made LLM connected to RAG.

3. Is the problem integrative? Do you have the data but systems do not talk to each other? Build data flows and APIs first; only then bring in a model to conduct the orchestra.

Unsure which class of problem you are facing? This is the moment for a diagnostic conversation — before you launch another pilot nobody will remember in six months.