How to Create an AI Model: Four Routes, and Which One You Actually Need

If you are not yet sure what a model is doing when it answers you, start with a simple explanation of AI and come back. "How do I create an AI model" is really four different questions wearing one sentence. Depending on what you actually want, the answer is an afternoon of writing instructions, a weekend of plumbing, a few weeks of data work, or a research programme with a budget. Picking the wrong one is the most common and most expensive mistake in this whole area, so the useful thing to do first is work out which question you are asking.

Route 1: instruct an existing model

You write instructions, examples and constraints that turn a general model into something that reliably does one job. No training, no data pipeline, no infrastructure. This is what most people mean when they say they want to "build an AI" for summarising support tickets, drafting quotes, or sorting inbound enquiries.

It is unglamorous and it is where the overwhelming majority of working systems live. The published guidance from the model providers themselves — Anthropic's prompt engineering documentation is a reasonable starting point — is mostly about being specific, giving examples, and defining the output format, none of which requires any machine learning knowledge.

• —Effort: hours to days.
• —Cost: the price of the API calls, or nothing if you use a chat interface.
• —When it is right: the model already knows how to do the task, it just needs to know your version of it.
• —When it fails: the task depends on information the model has never seen, or the behaviour needs to be consistent across thousands of calls in a way instructions cannot hold.

If your instructions are not producing consistent output, the problem is usually the instructions rather than the model. How to Write a Prompt That Works First Try covers the structure that fixes most of it.

Route 2: give the model your information

The next step up is retrieval: you keep the general model and feed it the relevant slice of your own documents at the moment it answers. This is what people are usually reaching for when they say they want an AI trained on their company data. In almost every case they do not want training — they want retrieval, which is faster, cheaper, updates the moment a document changes, and can cite where an answer came from.

The same category covers connecting a model to tools and systems so it can look things up or take an action rather than guessing. The tool use documentation describes the mechanics; the hard part is not the wiring but deciding what the model is allowed to do and how you check that it did the right thing.

• —Effort: days to weeks, mostly software engineering.
• —Cost: modest — storage, embeddings, API calls.
• —When it is right: the model needs facts it does not have, especially facts that change.
• —When it fails: your documents are a mess. Retrieval quality is bounded by the quality and structure of what you are retrieving from, and no amount of clever indexing fixes contradictory source material.

Retrieval handles what the model needs to know. Fine-tuning handles how it needs to behave. Most people asking to "train a model on our data" want the first one.

Route 3: fine-tune

Fine-tuning takes an existing model and adjusts it on your examples so it adopts a behaviour, format or tone consistently, without being told each time. It is a real technique with a real use case, and it is also the step people jump to too early.

The practical requirement is examples — enough pairs of input and the output you wanted, consistent enough that a pattern exists to learn. Gathering and cleaning those is the actual work; the training run itself is largely a matter of following the provider's documented process, such as OpenAI's fine-tuning guide. A useful test before committing: if you cannot write the task definition down in a couple of pages, the task is probably too loose to fine-tune and should be split into narrower pieces or left on instructions.

• —Effort: weeks, dominated by data collection and evaluation.
• —Cost: training compute plus the ongoing cost of serving a custom model.
• —When it is right: a stable behaviour or output format you need thousands of times, where instructions keep drifting.
• —When it fails: you use it to teach facts. Fine-tuning is bad at knowledge and good at behaviour, and a fine-tuned model still needs retrieval for anything that changes.

Route 4: train a model yourself

Two very different things sit under this heading, and conflating them is why people think building a model is impossible.

The first is a classical machine learning model — predicting churn, classifying images, forecasting demand. This is genuinely achievable on a laptop. You need labelled data, a library, and a discipline about evaluation. The scikit-learn getting started guide will take you from a spreadsheet to a fitted, evaluated model in an afternoon — in Python, like almost everything else in the artificial intelligence programming language landscape — and for a great many business problems a small model on clean data outperforms anything involving a language model.

The second is training a large language model from scratch. That means an enormous corpus, a cluster, months of engineering and a budget that is not a personal one. The architecture is public — the transformer paper is freely readable — but the recipe is not the constraint. Data and compute are, and unless you are at an organisation with both, this route is a subject to understand rather than a thing to do.

Choosing, in five questions

1. 01Does a general model already do roughly the right thing when asked clearly? If yes, stay on route 1 and stop reading.
2. 02Does it need information it does not have? Route 2. If that information changes, definitely route 2 and not fine-tuning.
3. 03Is the failure consistency rather than knowledge — right answers, wrong shape, thousands of times? Route 3, once you have the examples.
4. 04Is the task actually a prediction over structured data you already hold? Route 4, classical, and probably simpler than anything above it.
5. 05Are you trying to build a general-purpose model? Then the honest answer is that you are describing a research programme, and the useful version of the goal is a specific narrow model instead.

The part everyone skips

Whichever route you take, the thing that decides whether it works is evaluation: a fixed set of test cases with known good answers, run every time you change something, so you can tell an improvement from a regression. Without it you are adjusting a system based on how the last three outputs felt, which is how projects end up worse after two months of work.

This matters more than it sounds because these systems fail confidently. A model producing a fluent, plausible, wrong answer looks exactly like one producing a right answer, and your test set is the only thing standing between those two states. What AI Is Actually Bad At covers the failure modes worth building test cases around, and evaluation is also one of the skills that shows up repeatedly in AI engineer job postings precisely because so few people do it.

A sensible first project

• —Pick one repetitive task you personally do, where you can judge whether the output is right.
• —Write ten test cases first — real inputs, with the answer you would accept.
• —Solve it with instructions alone. Measure against your ten cases.
• —Only if that plateaus, add retrieval. Measure again.
• —Only if that plateaus, consider fine-tuning or a classical model. Measure again.

That sequence is dull and it is also how most working systems actually got built. If you are not sure which task to choose, Find the Repetitive Part is a short test for spotting the one in your week that is worth automating.

The short version

Creating an AI model means one of four things, and they differ by orders of magnitude in effort. Instruct an existing model; give it your information; fine-tune it for behaviour; or train something yourself, which is achievable for classical prediction and out of reach for a general language model. Start at route one, add a test set immediately, and move up only when you have measured that the current route is genuinely stuck.

Most useful AI work is closer to route one than people expect. Coursium teaches that practical layer — using the tools well and checking what they give you. Stay ahead of AI by learning them on your phone.