Almost every product team building with AI right now is quietly making the same decision without realising it. Which kind of AI is going to sit under our product? A general foundation model from a big provider?
A version of one that we fine-tuned on our own data? Or an industry-trained AI that was built for our domain from the start? The pitch decks from every vendor make it sound like a preference.
It is not a preference. It is a decision that shapes cost, control, accuracy, and how much of the product you actually own a year from now. Most teams pick by which vendor called first. That is why so many AI backbones get rebuilt after the first year.
So how do you actually pick the right one? That is the point of this piece. You will see what these 3 categories really are without the buzzwords, the 3 buckets almost every AI product falls into, the 3 decisions that separate the right backbone from the loud one, the 4 things that break AI backbone decisions after launch, a simple shape that keeps your product loose from any one model provider, and the 3 signs somebody is selling you fine-tuning you do not need. All of it is written for the product owner making the call, not the researcher tuning the model, because the product owner is the person who has to justify the invoice.
Why does this matter more this year than a few years back? Because the choice is real now. A few years back, if you wanted useful AI, you called one of 2 vendors and paid the retail rate.
Today, there are 3 distinct paths (foundation model as an interface, fine-tuned models as a middle ground, industry-trained models as full products), each with genuine strengths and honest weaknesses. Teams that pick well end up with backbones they can grow into. Teams that pick because "everyone is using X" find themselves rebuilding when their competitor with a smarter pick pulls ahead.
3
Backbone types your product can build on: general foundation model, fine-tuned model, and industry-trained AI framework. Each is honest for a different situation.
3
Decisions that pick the right backbone: how much domain data you own, how specialised your product is, and how much accuracy versus speed matters.
4
Things that quietly break AI backbone decisions after launch: provider price shifts, capability drift, model deprecation, and data-leak liability.
1
Model-abstraction layer that keeps your product loose from any one provider. Skip it and switching backbones later becomes a rewrite.
The rest of this piece walks the answer in the order the questions come up during a real conversation with a product team about AI. What are the 3 things? Which one fits you?
What decides the pick? What breaks after launch? How do you build so a change is cheap?
And how do you spot a vendor selling you the wrong backbone? Boring on purpose, because the boring backbone decisions are the ones that survive the next model release.
AI Backbones, Broken Down Without the Buzzwords
What is a foundation model? A foundation model is a very large computer program trained on huge amounts of general text, code, images, or all 3 together. GPT-4, Claude, Gemini, and open-source versions like Llama and Mistral are all foundation models.
They are called foundation because you build your product on top of them the way a house sits on a foundation; you did not build the foundation yourself, and you probably could not. The provider updates them regularly, they cost you per use rather than per unit built, and they know a lot about almost everything and nothing specific about your product.
What is a fine-tuned model? A fine-tuned model is a foundation model that has been further trained on your own data (customer conversations, your product documentation, examples of the kind of output you want) so it behaves closer to what your product needs. You start with somebody else's foundation and teach it your dialect.
Fine-tuning does not create new intelligence; it shapes existing intelligence to match your context. The cost is up-front (you have to prepare the training data and run the fine-tuning job) and the payoff is that responses are more predictable, more on-brand, and more accurate for your specific use case.
What is an industry-trained AI framework? An industry-trained AI is a model, or a set of models plus the tooling around them, that was designed and trained from the start for a specific industry. Legal AI trained on legal documents, court cases, and contracts.
Healthcare AI trained on medical literature, clinical guidelines, and (sometimes) anonymised patient data. Finance AI trained on regulatory filings, market data, and industry-specific terminology. These are usually sold as products, not as raw models. You pay a subscription and you get an AI that already speaks your industry's language, at the cost of less flexibility to shape it further.
What about small language models? A small language model is a foundation model that has been made much smaller (Phi, Gemma, Llama-3B, Qwen-1.5B) so it can run cheaper, faster, and sometimes on your own hardware. Small models are worse at broad general tasks and often very good at focused ones, especially when fine-tuned. They fit inside the same 3 backbone categories above; picking a small language model as your foundation is a size choice inside the foundation-model bucket, not a fourth bucket.
The Backbone Question
If you cannot say in one sentence which of the 3 backbones your product is built on, your team is likely holding the assumption implicitly and paying for it in ways nobody is tracking. Every AI product has a backbone; picking it deliberately is the difference between an AI product you own and an AI subscription you rent.
Which of the 3 Backbones Fits Your Product?
Which of the 3 backbones does your product actually need? Almost every "we need AI in our product" conversation resolves into one of them once you push on the actual use case. Knowing which one you are in changes everything: the cost profile, the launch effort, the ongoing tuning, and how much your product owns versus rents.
3 Backbones
What "We Need an AI Model" Almost Always Turns Out to Mean
Backbone 1
Foundation Model As-Is (Through an API)
You call GPT-4, Claude, or an open-source equivalent through their standard interface. No training on your side; you shape behaviour through the way you ask (prompt design) and by giving the model your data at question time (retrieval). Cheapest to start, fastest to launch, weakest at deep specialisation. Around half of AI product ideas fit here honestly and never need to leave this bucket.
Backbone 2
Fine-Tuned Model on Your Own Data
You take a foundation model and teach it your dialect, using examples of the input and output you want. The model then behaves closer to your product on every request without needing lengthy prompts. Higher up-front effort, better predictability, worth doing when your product needs a consistent voice or a specific output shape that prompting alone cannot deliver reliably. Roughly a quarter of AI products belong here.
Backbone 3
Industry-Trained AI Framework
You subscribe to an AI system built for your industry (legal, healthcare, finance, insurance). It already understands your domain vocabulary, your document types, your regulatory context. Fastest to a working demo in a specialised domain, expensive at scale, hardest to customise beyond what the vendor decided. Fits a smaller share of products but the fit, when it fits, is close.
Where to Land
Ask 3 questions: how specialised is my product's domain, how much of my own data do I have that a model could learn from, and how much do I need to keep customising over time. Two or three highs on those pushes you off backbone 1; a high on domain but low on data pushes you toward backbone 3; a high on both pushes you toward backbone 2.
Why does the backbone matter so much before you start building? Because each backbone has a completely different pricing shape, launch effort, and ongoing operational load. A backbone-1 product treated as backbone-2 spends a lot preparing training data it did not need to prepare.
A backbone-2 product built on backbone 1 keeps sending giant prompts that could have been trained-in and paying for every one of them forever. And a backbone-3 product built as backbone 1 tries to explain the entire domain to the model on every request and hits accuracy walls the industry-trained product would have cleared automatically. Getting the backbone right is the single decision that decides whether the next year of AI feels smooth or feels like ongoing repair.
3 Decisions That Pick the Right Backbone
Once you know the 3 backbones exist, which questions actually separate the right one from the loud one? The 3 decisions below are the ones that keep showing up. Every other input (vendor brand, pricing pages, dashboard quality) is downstream of these 3.
The Backbone Comparison
3 Backbones Across the Criteria That Actually Matter
Backbone
Best Fit
Control
Effort
Speed to Production
Foundation
General reasoning, mixed tasks, uncertain product-market fit
Low
Low
Fastest
Fine-Tuned
Repeatable narrow task with real labelled data
Medium
High
Slower
Industry-Trained
Regulated or highly specialised domain (legal, health, finance)
High
Very High
Slowest
Reading This Table
Move down the table only if the effort and speed trade-offs are earned by the product. Foundation is the default; fine-tuned needs the data honesty check below; industry-trained needs a domain that genuinely rewards the extra investment.
01
How Much Real Domain Data Do You Actually Own?
Fine-tuning needs data. Not a little; a lot. Ideally thousands of clean, labelled examples of the input you receive and the output you want. Most products that assume they have that data actually have a fraction of it, mostly messy and unlabelled. If your data is small, dirty, or not really representative of what your product does, fine-tuning will produce a model that behaves worse than the original foundation model with a good prompt. Answer this question honestly first; the wrong data volume answer pushes you out of backbone 2 whether the vendor pitch admits it or not.
02
How Specialised Is Your Domain, Really?
"We are in a niche" is what every team says. The real question is whether the niche uses specialised vocabulary, has domain-specific reasoning patterns, or produces documents with structures a general model has never seen. Legal, medical, and finance are genuinely specialised in this way. E-commerce, general SaaS, and most marketing products are not, no matter how the founder describes them. If your domain is genuinely specialised in ways a general model gets wrong repeatedly, an industry-trained AI (backbone 3) may fit better than fine-tuning your own. If not, backbone 1 with strong prompt design is often enough.
03
Which Matters More: Accuracy, Speed, or Cost Predictability?
Foundation models through an API give you the highest accuracy on general tasks but the cost scales with every request and the speed depends on the provider. Fine-tuned models give you predictable behaviour at a predictable cost but require the up-front investment. Industry-trained products give you accuracy in the domain but at a per-user subscription that scales with your customer base. Answer honestly which of the 3 your product's competitive edge depends on. The right backbone is the one that gives you the most of whichever you picked, at an acceptable trade on the other two.
The Order to Answer These In
Answer the data question first, the specialisation question second, the accuracy-vs-speed-vs-cost question third. Teams that answer them in reverse usually pick the backbone with the flashiest capabilities and then discover they do not have the data to feed it, or the domain is not as niche as the vendor implied, or the pricing shape does not match their product's traffic pattern.
4 Things That Quietly Break AI Backbone Decisions After Launch
What actually goes wrong with AI backbone choices once they are running in production? The 4 below show up in almost every backbone decision that felt clean at launch and started causing arguments a few weeks in. All of them are survivable if the backbone was picked with them in mind. Skipping them at launch is why so many AI-powered products end up rebuilding their model layer.
01
Provider Price Shifts You Cannot Negotiate
Your provider raises the per-call price, or restructures the pricing tiers, or ends the discount that made the maths work. If your product runs on backbone 1 with no abstraction, that price shift lands on your cost of goods immediately. Fine-tuned models on your own infrastructure are more insulated but not free either. Industry-trained subscriptions renew on the vendor's terms. Assume the price you see today is not the price you get in a year, and pick the backbone whose pricing shape is one your business can absorb if the numbers shift.
02
Capability Drift Between Model Versions
Foundation models get updated. Sometimes those updates improve everything; sometimes they subtly change behaviour in ways that break your carefully-tuned prompts, or degrade performance on the specific task your product depends on. Your product started giving different answers to the same question, and nobody on your team knows why. Products that treat the model as a black box behind a version-locked interface survive drift cleanly. Products that call the latest version every time are the ones with the mystery quality regressions.
03
Model Deprecation on Provider Timelines You Do Not Control
The model version your product depends on gets scheduled for retirement. You are given a window to migrate. Sometimes the successor is better; sometimes it behaves differently enough that everything your product does needs re-testing. Fine-tuned models built on a deprecated foundation have to be re-tuned on the successor. Industry-trained products handle this behind their subscription but you have no visibility into the change. Every backbone choice has to include a plan for the day the version underneath it goes away.
04
Data-Leak Liability You Did Not Read Into
Every time your product sends a customer message to a foundation model API, the customer data leaves your system. The provider promises they do not train on it; the regulator in your customer's region may not accept that promise as sufficient. Fine-tuning requires you to hand over training data with the same considerations. Industry-trained products vary widely on how they handle customer data. Every backbone has a data-leak profile; picking the backbone without reading it usually leads to a compliance conversation you did not schedule.
Why These Feel Like Model Failures But Are Not
All 4 of these look like the model letting you down. All 4 are actually your backbone choice not being ready for them. The 4 things happen to every AI product; the ones that were designed for them absorb them without customer-visible effects. The ones that were not are the ones you read about doing a "big migration" a year in.
A Shape That Keeps Your Product Loose From Any One Model Provider
So what does an AI product built to survive backbone changes actually look like? Not fancy. The shape below is the arrangement that keeps your product code from ever calling a specific model provider directly, so that moving between foundation models, fine-tuned versions, and industry frameworks is an adapter swap and not a rewrite.
Every layer has one job. When the model underneath changes (and it will), the change stays contained.
Architecture
A Shape That Keeps Your Product Loose From Any One AI Provider
Layer 1
Your Product
Talks to the model abstraction below, never to a specific provider directly. Knows about intents (summarise, classify, extract, generate) not about model names.
Layer 2
Model Abstraction
One clean interface for every AI operation your product does. Provider names live only inside this layer. Adding a second provider means adding an adapter, not touching the product.
Layer 3
Provider Adapters
One adapter per backbone: your GPT-4 wiring, your Claude wiring, your fine-tuned model wiring, your industry framework wiring. Each translates your abstraction into that provider's calls.
Layer 4
Evaluation Store
Records every request, every model response, every rating. Your source of truth for what your model actually did, independent of any provider dashboard.
↓
The Payoff
What This Shape Actually Buys You
Switch Backbones
Start on backbone 1, add a fine-tuned adapter when the volume justifies it, add an industry backbone for one workflow and keep the others.
Survive Deprecation
The model version underneath gets retired. You swap the adapter, keep the product code unchanged, and re-run evals to confirm.
Compare Cleanly
Run the same request through 2 backbones through the same interface. The eval store tells you which is actually better on your data.
Why This Shape Buys You Time
The AI world moves faster than your product can. Backbones you would not have picked a year back are worth picking today; backbones you would have picked a year back are becoming obsolete. The abstraction layer is what turns "the AI world moved" from a rewrite conversation into a routine model swap.
Why go to this trouble when the current model works fine? Because AI backbone decisions are one of the few product choices that compound the longer you defer changing them. A product that could have swapped models in a bounded piece of work at year one becomes a product that cannot swap models at year three because "answer format" and "prompt template" and 40 other product decisions all quietly assume the specific model's quirks. The abstraction layer is what keeps the door open when the door is worth walking through.
3 Signs You Are Being Sold Fine-Tuning You Do Not Need
How do you tell whether a vendor pitching fine-tuning to your team is proposing something your product actually benefits from, or something that will produce a bill and no improvement? The 3 signs below give it away. If you spot more than one, the fine-tuning pitch is probably not the right answer for your product yet.
01
The Pitch Cannot Show a Baseline of "Foundation Model Plus Good Prompt"
Fine-tuning is worth doing when a well-designed prompt on a strong foundation model is provably not enough. If the vendor cannot show you the baseline (a serious attempt at solving the same problem with backbone 1 and a well-crafted prompt), they are skipping the cheapest possible answer. Insist on the baseline first. Half the time the baseline turns out to be good enough and the fine-tuning conversation ends there. The other half, the baseline gives you a real benchmark to compare fine-tuning against.
02
The Vendor Cannot Tell You How Much Data They Need or Why
Fine-tuning outcomes are shaped by data volume, data quality, and how representative the training set is of real production traffic. A vendor who understands fine-tuning talks about all 3 upfront and asks what your data looks like before quoting a price. A vendor who does not, quotes a flat fine-tuning fee and figures the data out later. That "later" is where fine-tuning projects fail. If nobody has looked at your data with you before the invoice, the fine-tuning is a bet, not a plan.
03
There Is No Plan for Re-Tuning When the Foundation Underneath Changes
A fine-tuned model is built on a specific version of a specific foundation model. When that foundation model is deprecated, replaced, or shifts in behaviour, your fine-tuning has to be redone. A vendor who understands this bakes re-tuning into the ongoing plan; a vendor who does not sells you the initial fine-tuning and disappears when the successor foundation lands. Ask what happens on foundation change before you sign. Silence is the answer that tells you everything.
The Fine-Tune Filter
Ask the vendor 3 things in the same meeting: show me the baseline of foundation-model-plus-good-prompt on this task, tell me what data volume and quality you need to make fine-tuning work, and describe what happens when the foundation model underneath gets deprecated. Vendors selling honest fine-tuning answer all 3. Vendors selling fine-tuning as a product line answer none.
Frequently Asked Questions
Is fine-tuning always better than a good prompt on a foundation model?
No, and this is the single most common wrong assumption in AI product decisions right now. A carefully-designed prompt on a strong foundation model, combined with giving the model your relevant data at question time (retrieval), can outperform a poorly-executed fine-tune on almost every task. Fine-tuning wins when your product needs a specific output format, a specific voice, or a consistent behaviour that prompting cannot deliver reliably. It also wins when your prompts have grown so long they are expensive to send every time. Outside those cases, the foundation-plus-good-prompt approach is often the right first move, and fine-tuning is the escalation when the baseline is provably not enough.
Should you use an open-source model or a closed-source one?
Depends on 3 things. First, do you need to run the model on your own infrastructure for data-sovereignty or cost reasons; open-source models let you, closed-source ones usually do not. Second, do you need the absolute highest capability ceiling on the hardest general tasks; closed-source frontier models still lead there. Third, how important is provider-independence to your business; open-source models let you switch providers or self-host, closed-source ones lock you to the vendor. For products with heavy compliance needs or unpredictable traffic, open-source is often the honest pick. For products where capability is the differentiator, closed-source is often worth the trade. Most real products end up using both, through the abstraction layer covered above.
What is the difference between fine-tuning and retrieval-augmented generation?
Fine-tuning changes the model itself by training it on your examples. Retrieval-augmented generation (usually shortened to RAG) keeps the model unchanged and gives it your relevant data at question time. Fine-tuning is like teaching somebody your dialect permanently; retrieval is like handing them a briefing note before every conversation. Retrieval is cheaper to start, easier to update (you change the data, not the model), and better when your knowledge changes often. Fine-tuning is better when you need behaviour or output format changes that retrieval cannot deliver. Many real products use both, at different points in the workflow.
Are industry-trained AI products actually better than a well-configured foundation model?
Sometimes. In genuinely specialised domains (legal contract analysis, radiology imaging, structured financial disclosure), industry-trained products often outperform a foundation model on the specific tasks they were built for, because the training data went deeper than any general model has. In less specialised domains, the industry-trained pitch is often the same foundation model wrapped in a vertical brand, with modest additional training. Ask the vendor exactly what makes their model industry-trained (what data, how much of it, from where, and how the model measurably outperforms a foundation baseline). If the answer is vague, the "industry-trained" label is marketing, and a well-configured foundation model will likely do the same job at a fraction of the cost.
How much data do you actually need to fine-tune a useful model?
Enough is a range, not a number. For simple format or tone adjustments, a few hundred well-labelled examples can move the model meaningfully. For real behaviour shaping on a complex task, several thousand quality examples is a reasonable floor. For the kind of deep domain adaptation that would replace an industry-trained product, tens of thousands or more, usually with domain experts labelling. What matters more than raw volume is the quality: examples that genuinely reflect what your product will see in production, labelled consistently by people who know the right answer. A small clean dataset almost always beats a large messy one.
What happens when the foundation model your product depends on gets deprecated?
Every provider deprecates model versions on their own schedule; foundation models get replaced by successors and old versions are retired. If your product was talking to a specific model directly, you have to update every call, re-test every prompt, and re-run every fine-tune. If your product was talking through the abstraction layer covered above, you swap the adapter, re-run your eval suite, and confirm the successor model matches or exceeds the old one on your specific tasks. The abstraction layer is the difference between "we did a migration" as a one-week project and "we did a migration" as a quarter-long saga. Every AI product built for the long run has the abstraction layer, whether the team called it that or not.
Can Entexis help you pick and set up the right AI backbone for your product?
Yes. Entexis designs and builds AI product foundations across all 3 backbones: foundation models through an API, fine-tuned models on customer data, and integrations with industry-trained AI frameworks. That work starts with the sorting conversation to make sure you are picking the backbone that fits your product's data, domain, and pricing shape, rather than the one your last vendor pitched. We then design the model-abstraction layer that keeps you loose from any one provider, wire the evaluation store that lets you compare backbones on your own tasks, and deliver a foundation your product can scale on without rewriting when the AI world moves. Reach out with what your product does, roughly how much domain data you already have, and where you are today in the backbone decision, and we can walk through what the right foundation looks like for your specific product.
So where does that leave your product? The 3 backbones above are the real decision every AI product makes, whether the team makes it deliberately or by default. Backbone 1 fits most product ideas honestly and never needs to leave that bucket.
Backbone 2 pays back when your data volume, domain specialisation, and behaviour needs justify the up-front effort. Backbone 3 fits a smaller share of products but fits closely when the industry is genuinely specialised. The 4 things that break backbone decisions after launch (price shifts, capability drift, deprecation, data-leak liability) happen to every product; the ones designed for them absorb them without customer-visible effects.
The abstraction layer is what keeps the door open when the AI world moves under you. Get the backbone right first, put the abstraction layer in from day one, and your product survives the next model release cleanly. Skip either and you find yourself doing a model migration that turned into a product rewrite.
Want to Pick the Right AI Backbone Before the Invoice Arrives?
At Entexis, we design and build AI product foundations across foundation-model, fine-tuned, and industry-trained backbones. We start with the sorting conversation to make sure you are picking the backbone that fits your data, your domain, and your product's pricing shape, then design the abstraction layer that keeps you loose from any one provider, wire the evaluation store that lets you compare backbones on your own tasks, and deliver a foundation your product can scale on without rewriting when the AI world moves. Your product runs on the backbone that actually fits, your team stops rebuilding when the model underneath changes, and your AI cost matches what the product actually earns from it. Start the conversation with Entexis.
Ready to Add AI to Your Business?
From intelligent chatbots to workflow automation, we build AI solutions that understand your domain, your data, and your users. Tell us what you need.
We'll get back within one business day.
Thank You!
We've received your message and will get back to you within one business day.
Try the AI workflows we build, for real, right now.
Same workflow patterns Entexis rolls into client setups. Try them in your browser, no signup. If one feels like it'd help your team, we build a private version tuned to your data.
