The Marketing Fog Around Custom AI

Fine-tuning, RAG, system prompts, and the marketing fog around “custom AI.”

One of the most frustrating things in the current AI scene is how casually people use the word trained.

• “Our model is trained on your data.”
• “Our AI is trained for your business.”
• “Our custom model understands your brand.”
• “Our proprietary AI learns your voice.”

That kind of wording gets attention. It sounds powerful. It sounds like the company has built something deep, technical, expensive, and uniquely theirs.

Sometimes they have. Often, they have not.

Sometimes what they actually have is:

• a system prompt,
• a retrieval layer,
• a vector database,
• a dashboard,
• and an API call to someone else’s model.

That may still be useful.

But it is not the same thing as training a model from scratch.

And if people do not understand the difference, they will keep paying for fog.

The sentence that started bothering me

I remember seeing systems claiming “our models are trained,” and I got excited for a moment.

Then I looked closer. They were using an API.

And I thought:

Wait. I thought you created your own LLM.

That is the problem. The claim sounds like one thing to ordinary users and another thing to people who know the technical loopholes.

“Trained on your data” can mean several very different things.

• It can mean a model was actually fine-tuned.
• It can mean the system retrieves your uploaded documents and includes relevant pieces in the prompt.
• It can mean the system prompt contains your brand rules.
• It can mean your content is stored in a database and searched at runtime.
• It can mean the company is collecting examples to improve future outputs.
• It can even mean very little at all.
• If you do not know the difference, you will probably fall for the better marketing phrase.

And the industry knows this.

API access is not model training

Using an API is not bad.

Let me be clear about that.

Most serious AI applications today rely on APIs from major model providers. An API lets software send a request to a model and receive a response. OpenAI’s text generation documentation, for example, describes API text generation as sending text inputs to a model and receiving generated output back. (OpenAI Platform)

That is a normal way to build.

There is nothing wrong with building a product on top of an API.

A good API-based product can still have real value:

• clean interface,
• strong workflow design,
• good retrieval,
• better routing,
• team permissions,
• approval flows,
• project memory,
• security choices,
• automation,
• logging,
• auditing,
• domain-specific UX.

Those things matter.

But using an API does not mean you trained the base model.
It means you are calling a model someone else trained.

That distinction is not an insult. It is literacy.

A wrapper is not automatically worthless

The phrase API wrapper gets thrown around like an insult.

Sometimes it is deserved.

If a product is just a thin prompt box around an existing model with inflated claims, then yes, call it what it is.

But not every wrapper is lazy.

A well-built wrapper can be the actual product.

Think of it this way:

The model is the engine.

The wrapper can be the steering system, dashboard, safety cage, fuel gauge, navigation, braking logic, passenger rules, maintenance log, and route planner.

That is not nothing.

The problem is not that people build on APIs.

The problem is when they pretend the wrapper is a newly trained intelligence.

• If you built routing, say you built routing.
• If you built retrieval, say you built retrieval.
• If you built a dashboard, say you built a dashboard.
• If you built a workflow layer, say you built a workflow layer.
• If you fine-tuned a model, say fine-tuned.
• If you trained a foundation model from scratch, then say trained.

But do not use the most impressive word just because the least technical customer will not know how to challenge it.

Training from scratch is a different universe

Training a large language model from scratch is not the same as putting a few documents into a knowledge base.

• It is not the same as making a chatbot with your brand voice.
• It is not the same as using RAG.
• It is not the same as writing a strong system prompt.

Training a frontier-scale model requires enormous datasets, engineering teams, compute infrastructure, evaluation pipelines, safety work, and significant capital. A 2024 research paper on the rising cost of frontier AI training estimated that costs for the most compute-intensive models have been growing rapidly since 2016, with major expenses such as accelerator chips and staff costs reaching tens of millions of dollars for key frontier models. (arXiv)

So when a small SaaS product casually implies that it has “trained an AI model” for every customer, we need to ask:

• Trained how?
• From scratch?
• Fine-tuned?
• RAG?
• Prompted?
• Stored?
• Indexed?

Because those are not the same thing.

Fine-tuning is real — but it is not the same as building a foundation model

Fine-tuning is a real model optimization technique.

It can be useful.

OpenAI’s model optimization documentation describes fine-tuning as taking an already pre-trained base model, providing examples of expected inputs and outputs, and producing a model that performs better for a specific task. The same documentation frames optimization as a combination of evals, prompt engineering, and sometimes fine-tuning. (OpenAI Platform)

That matters.

Fine-tuning starts with someone else’s pre-trained model.

You are not creating the base intelligence from zero. You are adapting an existing model toward a narrower behavior, format, style, or task.

That can be valuable.

It can help with consistent formatting, specific classification tasks, translation nuance, instruction-following failures, or reducing prompt length at scale. OpenAI’s docs describe supervised fine-tuning as providing examples of correct responses to guide the model’s behavior, often using human-generated “ground truth” examples. (OpenAI Platform)

So yes, fine-tuning can justify saying a model was fine-tuned.

But even then, the honest phrase is:

fine-tuned from a base model

not

we created our own AI from scratch

unless that is actually what happened.

RAG is not training either

RAG — retrieval-augmented generation — is another useful technique that often gets blurred into “training.”

In simple terms, RAG lets a system retrieve relevant information from external data sources and include that information in the model’s context before generation. It is a way to give a model access to current, private, or domain-specific information without changing the model’s underlying weights. OpenAI’s retrieval documentation describes vector stores as containers that power semantic search, where files are chunked, embedded, and indexed for retrieval. (OpenAI Platform)

That is powerful.

It is also not the same as training.

If I upload a folder of policy documents and the chatbot can answer questions from them, that does not necessarily mean the model was trained on those documents.

It may mean the documents were indexed, searched, retrieved, and inserted into the prompt.

That is not lesser.

It is just different.

And different matters.

Because if your data is retrieved at runtime, you should be asking questions about indexing, storage, permissions, retrieval quality, freshness, chunking, and source attribution.

If your data is used for fine-tuning, you should be asking different questions about training jobs, datasets, retention, model versions, evals, and whether your examples are being used to change model behavior.

If your data is used to train a foundation model, that is an entirely different level of data governance.

One word cannot cover all of that.

System prompts are not training

Another common layer is the system prompt.

A system prompt can be powerful. It can define role, tone, constraints, formatting, workflow rules, and operating behavior.

But a system prompt is not training.

It is instruction.

It can shape a model’s behavior for a session or application. It can make a product feel customized. It can create the impression of a specialized assistant.

But if the only customization is a system prompt, then the model was not trained on your business.

It was instructed about your business.

Again, that may still be useful.

But say what it is.

The marketing fog benefits someone

This is the part people often avoid saying.

The fog is profitable.

• Model providers benefit from API usage.
• Startups benefit from sounding more proprietary than they are.
• Investors benefit when a company sounds like an AI company instead of a workflow tool.
• Media benefits from grander headlines.
• Consultants benefit when the buyer does not know which layer is doing the work.

So nobody in the chain has a strong incentive to say:

Actually, this is a dashboard plus retrieval plus an API call.

But the user needs that sentence.

Because without it, ordinary builders, writers, creators, and small business owners end up paying for mythology.

They think they are buying a trained intelligence.

They may actually be buying a nicer interface around someone else’s model.

Again, that interface may be worth paying for.

But it should be sold honestly.

The honest vocabulary

Here is the vocabulary I wish more products would use.

• API-based AI product
  The product calls an external model through an API. This is common and valid.
• System-prompted assistant
  The model is guided by instructions, tone rules, role definitions, or workflow constraints.
• RAG / retrieval-based assistant
  The system retrieves relevant information from files, databases, or other sources and passes it into the model context.
• Fine-tuned model
  A pre-trained base model has been further trained on task-specific examples.
• Self-hosted open model
  The company runs an open-weight model on its own infrastructure or rented infrastructure.
• Foundation model trained from scratch
  The company trained the core model itself from large datasets and significant compute.
• Agentic workflow
  The system can use tools, follow steps, call APIs, inspect files, or perform actions under defined rules.
• Custom AI system
  A broader phrase that may include any combination of prompts, retrieval, tools, APIs, UI, permissions, workflow, and fine-tuning.

These are not interchangeable.

And if a company refuses to clarify which one it means, that tells you something.

Questions to ask before buying the claim

The next time a product says “our AI is trained on your data,” ask:

• What base model are you using?
• Is this your own model, an open model, or an API from another provider?
• Was the model trained from scratch?
• Was it fine-tuned?
• Is it using RAG or retrieval?
• Are my documents stored in a database or vector store?
• Are my documents used to change model weights?
• Can I delete my data?
• Can I export my data?
• Is my data used to train future models?
• What happens if the model provider changes pricing, retires a model, or updates behavior?
• Do you provide citations or source retrieval?
• How do you evaluate output quality?
• What exactly is proprietary here: the model, the data layer, the workflow, the interface, or the prompt?

These are not rude questions. They are normal questions.
A serious company should be able to answer them.

Why this matters for small builders

This matters especially for people who are not full-time developers.

Writers. Designers. Teachers. Community owners. Small business owners. Vibe coders. Creative technologists.

These are the people most likely to be told:

• Do not worry about the details.
• Just use this.
• Just upload your data.
• Just trust the trained AI.

But if they do not know the difference between API access, RAG, fine-tuning, prompting, and training from scratch, they cannot make informed decisions about cost, privacy, portability, reliability, or ownership.

That is not empowerment.
That is dependency wearing a friendly UI.

And I do not think AI literacy should belong only to technical insiders.

Information is not hidden. Documentation exists. The problem is that the market often rewards confusion more than clarity.

What I am not saying

• I am not saying every API wrapper is a scam.
• I am not saying every SaaS product is dishonest.
• I am not saying everyone needs to train their own model.
• Most people absolutely do not need to train their own model.
• I am not saying RAG is fake.
• I am not saying fine-tuning is useless.
• I am not saying system prompts are trivial.

I am saying: name the layer correctly.

Because once the layer is named, people can make real decisions.

• They can decide whether they need the product.
• They can compare pricing fairly.
• They can evaluate privacy risk.
• They can understand whether they are paying for model capability, workflow design, retrieval quality, interface polish, compliance, support, or branding.

That is literacy.

The Atelier position

At Algorithm Atelier, this distinction matters because we build and write with AI in a human-led way.

We do not need to pretend that every useful system is a newly trained model.

• A good framework can be built on top of existing models.
• A good continuity system can use retrieval without pretending the model “remembers” everything.
• A good assistant can be shaped by prompts without pretending it was trained from scratch.
• A good workflow can be valuable because the architecture is sound.

There is dignity in honest architecture.

There is no need to inflate it.

My own framework works because of routing, source hierarchy, approval flow, structured continuity, and human governance. Not because I secretly trained a frontier model in the basement.

That would require me to sell my car, my house, and probably several souls. No, thank you.

The skill is not always in owning the base model. Sometimes the skill is knowing what to build around it.

The point

• Stop calling every API wrapper a trained model.
• Stop using “trained” as a fog machine.
• Stop letting customers believe RAG is the same as fine-tuning.
• Stop pretending a system prompt is proprietary intelligence.
• Stop hiding the actual architecture behind grand language.
• Say what the system is.
• Say what layer you built.
• Say where the model comes from.
• Say what happens to user data.
• Say what is retrieved, what is stored, what is fine-tuned, and what is merely instructed.

That is not anti-AI.

That is AI literacy.

And honestly?

If the product is good, the truth will not make it smaller.

It will make it trustworthy.