Before you pay for an AI trained on your data, ask what you would own.
"We'll build you a private AI, trained on your own data."
That pitch makes three promises, and each one has a cheaper answer than training a model.
It will know your business. Ask it what you charged a customer last March and the right system looks it up in your order history and shows the invoice. A trained model remembers approximately, and approximately is the wrong standard for a price. Train it on fifteen years of service tickets and it also learns which repairs your technicians made, including the ones that never worked.
It will cost less. Say a million AI requests a month cost you $2,000 through a hosted model. Run your own and cut that by three quarters, and you save $18,000 a year, which will not cover the person who keeps your model running. At a tenth of that volume, the saving is $1,800.
Your data stays private. Paid business agreements with the major AI providers generally exclude your data from training. Where data truly cannot leave, you can run an existing model on your own servers without training it on anything.
Custom models do earn their place in a few narrow cases. For most owner-operated businesses, the asset worth paying for is the access to your records and the history of which decisions worked.
I wrote up the five questions to ask before you sign one of these proposals.
The pitch usually arrives in one sentence: we will build you a private AI, trained on your own data, so it knows your business and nothing leaves the building. It sounds like the responsible version of AI. You keep control, the system learns how you work, and you stop paying a large lab every time someone asks a question.
That sentence bundles three promises, and each of them has a cheaper answer than training a model. For most owner-operated businesses, a custom model means paying to own the part of AI that gets cheaper every few months, while the part that holds its value goes unbuilt.
Three different projects under one name
"Our own AI" can describe very different pieces of work, and a proposal rarely says which one it is pricing.
The first is an existing AI model given access to your files and systems. Nothing about the model changes. It looks things up in your documents, your order history or your job records when it needs them, the way a new employee would use the shared drive. This is what most businesses mean when they say they want AI that knows their business, and it is the cheapest of the three to build and to replace.
The second is an existing model trained further on a few thousand worked examples of one narrow task: sorting incoming orders, reading a particular kind of form, grading photos of damaged goods. The model gets better at that behaviour. It does not come away knowing your history.
The third is training a model on your whole archive, the emails, quotes, job notes and manuals, so that it absorbs how your business works, or in the extreme building one from nothing. This is the expensive one, it needs the most data and the most testing, and it is usually what "trained on your data" implies in a pitch.
Where the model runs is a separate question again. You can run an off-the-shelf model on your own servers without training it on anything. Ownership, customisation and hosting are three decisions, and a proposal that treats them as one is asking you to pay for all three when you may need one.
"It will know our business"
This is the strongest-sounding promise and the weakest reason to train a model.
Suppose your operations manager asks what you charged a customer for a 40-case order last March. That is a lookup. The answer sits in your order system, and the job is to find it reliably and show where it came from. A model trained to remember it will remember it approximately, and approximately is the wrong standard for a price. The first kind of project, an existing model with access to your records, answers that question better and cites the invoice.
Training sounds like the fix for records nobody has organised: years of emails, job notes, quotes and spreadsheets in four formats. But if your documents are too inconsistent to turn into reliable data, they are too inconsistent to turn into reliable training data. The mess goes into the model with everything else.
There is a less obvious risk. Records show what your people did, not whether it worked. Train a model on fifteen years of service tickets and it learns which parts technicians usually replaced, including the replacements that never fixed the problem. You end up with a system that is very good at repeating the company's habits, mistakes included, with more confidence than the technician had.
"It will cost less to run"
A small model you host yourself can cost less per question than a large one from a lab. The comparison that matters is different: the full cost of building and maintaining your own model against the cheapest off-the-shelf model that does the job. The labs now sell small, cheap models as well as their flagship ones, and those are what you are really competing with.
Run the numbers on a busy case. A million AI requests a month, at two tenths of a cent each through a hosted model, is $2,000 a month. If your own model brought the running cost down to a twentieth of a cent per request, you would save about $18,000 a year. That saving has to pay for the servers, the monitoring, the security work and the person who keeps the model running, and it will not. If your business sends a tenth of that volume, the saving is $1,800 a year.
Volume changes the picture only at a scale few owner-operated companies reach, and even there it justifies a careful cost comparison before anything is built.
"Our data stays private"
This concern is legitimate and deserves a real answer. Confidential pricing, customer lists and contract terms should not end up somewhere you cannot see, and removing names from a document does not make its commercial content harmless.
But the consumer chat app your staff may be using and a business agreement with the same provider are different products. Paid business and API terms from the major providers generally exclude your data from model training by default; free tiers can differ. The questions that remain are about how long data is kept, who can access it, where it is stored and what the contract lets you enforce. Those belong in the proposal review, and they have answers.
If the answer is still no, and some data genuinely cannot leave your control, the fix is to run an existing open model on infrastructure you control. Nothing about that requires training it on your data. Running it yourself is not automatically safer either: someone now has to patch it, watch it and respond when something goes wrong, and a carelessly set up internal system can leak more than a properly configured business account.
The larger exposure is somewhere else. Once an AI system can read your email, your accounting and your customer records, the risk is what it can reach and who can steer it into reaching it. That risk is the same whether the model is yours or rented. Privacy is a reason to control where data flows and what the system is allowed to touch, and it is rarely a reason to own the model.
The model you build is aimed at a moving target
Say a vendor spends six months tuning a model until it beats what is on the market today. By the time it goes live, the labs may have shipped a cheaper model that does the same task better, and the one after that is already coming. Your custom model has to be retrained, re-tested or retired, and the proposal rarely prices that.
General-purpose models will not make every custom model obsolete, but they keep raising the bar a custom one has to clear. The model yours has to beat is next year's cheap, off-the-shelf small one, which you would get without building anything.
When building your own does make sense
There are real cases, and they are narrow.
The clearest one is a hard physical constraint: equipment that has to work without a reliable connection, on hardware with little memory and power. Being offline alone only means running an existing model locally. Training one of your own makes sense when the off-the-shelf models small enough for that hardware have been tried and cannot do the job.
The second is a very repetitive, very high-volume job where a specialised model has been shown to be accurate enough and cheaper after every cost is counted, compared against cheap hosted models and against ordinary software that needs no AI at all.
The third is a business that holds records of expert decisions together with their outcomes: which loads were approved and which of those went bad, which parts passed inspection and which came back. A model trained on that can learn something an off-the-shelf model cannot pick up from instructions. Two conditions apply. The records have to show what worked, not only what people did, and the trained model has to beat the alternatives on your real cases. Often a conventional prediction model, the kind that has been around for decades, does the job better than a language model.
In each case the test is the same: a specific, measurable problem that an existing model, given the same access, cannot solve as well.
What is worth owning instead
What holds its value is the access and the records. That means reliable connections between your systems, clear rules on what an AI may see and do, and a way to check whether its suggestions actually worked. All of it carries over when you swap one model for a better one. The swap still needs adjusting and testing on your own cases, but that is weeks of work on top of what you built, not a rebuild.
The most valuable records are the ones few companies keep: the link between a decision and what happened next. A price change is logged, but whether it held the margin six months later usually is not. The same goes for the supplier behind most of the rework, the repair that prevented a callback and the customer who quietly stopped being profitable. Most businesses keep good records of what they did and far weaker ones of what it led to. Building that is useful today for ordinary reporting, and it is the raw material for any AI you adopt later, custom or not.
Questions for the proposal on your desk
If someone is pitching you a model of your own, five questions will tell you most of what you need.
What exactly will be trained, on which records, and who cleans them? A real answer names the systems and the hours. "All your data" is not an answer.
What will it do better, measured how, and compared to what? The comparison has to include an off-the-shelf model with access to the same records. If the vendor has not tested that, they do not know whether the custom part adds anything.
Who retrains or replaces it when a better model comes out, and what does that cost? If the answer is "we will handle that", ask for the price in writing.
What do we own if we stop working with you: the model, the cleaned data, the connections to our systems? Price the exit before you price the entry.
Where does our data go during training and afterwards, and under what contract? This one has a definite answer, and a vendor who cannot give it has not looked.
Reading the answers is harder when everyone in the room gains from a yes. When the commitment is large and the answers sound fine but you still cannot tell, it is worth asking someone independent to look at it with you, someone who understands the technology and is not paid more if you sign.
The question underneath all five is simple to ask and hard to dodge: what would we gain by owning this model that we could not get by giving an existing one better access to our records? If nobody can give a specific, measurable answer, the model is not what you need to build.