The Moat Isn't the Model. It's What Trained It.
Almost everyone building 'with AI' right now is renting model weights they don't own. Here's the line between a real AI business and a ChatGPT wrapper with branding, and the questions every operator should be able to answer.
Field Notes. A take from inside an operator-run AI shop. We’re not talking about hypothetical AI businesses. We’re talking about the ones already in production, and what separates the ones with a future from the ones with a runway. Dakota
Everyone is “building an AI company” right now. Almost none of them are.
There’s a scene playing out in founder circles, pitch decks, and LinkedIn bios at a scale that would be embarrassing if it weren’t so profitable to ignore. Someone slaps a prompt on top of OpenAI’s API, wraps it in a clean interface, and calls it an AI company.
It isn’t. And the longer the industry pretends otherwise, the more painful the correction is going to be. For the founders. For the investors. For the customers who thought they were buying something proprietary.
The uncomfortable truth most people will not say out loud is simple.
You cannot have an AI business without first having a data-centric business. Full stop.
This is not semantics. This is the line between a technology company and a reseller with a fancy UI.
What “building AI” actually means
When most people say they’re “building with AI,” they mean they’re calling an API. They’re sending a prompt to a model that someone else trained, on data that someone else collected, governed by weights that someone else updated. The output comes back and they pass it to a user.
That is using AI. It is not building it.
Real AI development, the kind that creates durable competitive advantage, is fundamentally about training. And training requires one thing above all else: structured data with clearly defined inputs and outputs.
Not vibes. Not prompts. Not a system message that says “you are a helpful assistant for [COMPANY NAME].” Actual, labeled, structured data that teaches a model to behave in ways a general-purpose model cannot.
The three pillars of a data-centric business
- Systematic data collection. You have a deliberate process for capturing raw signals. Customer interactions. Decisions. Outcomes. Failures. Not just the wins. All of it.
- Structured labeling. Raw data is noise. Structured data is signal. You know what the input is, what the correct output is, and what “correct” even means inside your context.
- Feedback loops tied to outcomes. Your pipeline closes the loop between model output and real-world results, so the system learns what actually worked, not just what seemed reasonable at the time.
Most companies claiming to “build AI” have none of these. They have a database of conversations, maybe. A spreadsheet of outcomes in someone’s Drive. What they do not have is an intentional, structured system for turning business activity into training signal.
Why this matters right now
The commodity trap is moving faster than people think.
Foundation models are getting cheaper, faster, and better every quarter. GPT-4 level capabilities are now available at a fraction of the original cost. Open-source models are closing the gap on proprietary ones at a rate that is genuinely uncomfortable if your entire business depends on the gap existing.
What does that mean for your “AI company” that’s really an API wrapper? Your moat is evaporating. Every capability you’re selling right now (summarization, drafting, classification, extraction) is about to be a free feature in every SaaS tool your customers already pay for.
If your entire competitive advantage lives inside someone else’s model weights, you do not have a competitive advantage. You have a temporary pricing arbitrage.
The companies that survive the commoditization wave are the ones that built data flywheels before the wave hit. They used the early period, when foundation models were expensive and APIs were novel, to quietly do the unglamorous work. Collecting data. Labeling it. Building feedback systems. Training proprietary models on the specific behavior their domain requires.
That work is boring. It does not make for exciting demo videos. But it is the actual barrier to entry. It is the thing nobody can copy.
The three types of “AI companies” out there
Type 1: API wrappers (the most common)
Foundation-model API plus a system prompt, some context injection, maybe retrieval, and a frontend. Entirely dependent on the provider’s pricing, availability, policies, and model quality. The differentiation is user experience and distribution, not intelligence. These are valid businesses. They are not AI companies. They are software companies that use AI as a feature.
Type 2: Fine-tuners (getting somewhere)
These teams have taken the next step. They’re fine-tuning foundation models on their own domain data. The result behaves differently from the base model: more accurate, more consistent, more aligned with the specific task. Fine-tuning requires structured data, which means at least part of the data-centric posture is in place. The moat is real but shallow. It deepens only if they keep generating better training data over time.
Type 3: Data-centric AI businesses (the real thing)
Here, data strategy IS business strategy. Every product decision is also a data decision. The question being asked is “does this feature help us collect better training signal?” before “does this feature delight users?” Product and data flywheel are the same thing. Each user interaction makes the model better. A better model attracts more users. More users generate more data. That is a compounding moat, and it is extraordinarily hard to replicate.
Most people think they’re in Type 3. They’re in Type 1.
What this looks like in practice
Pick a vertical. Legal document review.
The wrapper sends the doc to GPT-4 with a prompt that says “you are an expert legal reviewer, identify risks in this document.” Output goes to the user. Done. Fast to build. Zero proprietary data.
The data-centric AI company has reviewed thousands of legal documents. For each one, a lawyer flagged which clauses were risky and why. Clause type. Risk category. Legal reasoning. Jurisdiction. That signal is structured, stored, and used to fine-tune a model specifically on legal risk identification. The model knows that “indemnification clause with no liability cap” is a specific pattern with a specific risk profile, because it has seen 800 examples of that pattern labeled by real lawyers. It catches risks generic GPT-4 misses, because it has been trained on the exact distribution of problems that actually arise in this domain.
The user experience looks the same. The underlying business is completely different.
The honest questions
Here is the part that stings. If you have not been building data infrastructure from day one, you are behind. You may have a product, customers, even revenue. But you are sitting on a pile of interactions that you never structured for training. That data is still in your database. It is not useless. It needs to be retroactively labeled, cleaned, and structured before it becomes useful training signal, and that process is painful and expensive.
The good news is it is not too late. Foundation models are not going away. Wrappers have a role. Even a late pivot to data-centricity is better than ignoring the problem.
But the pivot has to be deliberate. Every AI company should be able to answer these:
- What is the exact input-output pair that defines “success” in your domain?
- Where does the ground-truth label come from? A human expert? An outcome metric? Something else?
- How many labeled examples do you have today? How many do you generate per week?
- What percentage of your interactions are being captured and structured for future training?
- What does your model know that no foundation model trained on internet data could know?
If you cannot answer these, you do not have an AI strategy. You have an AI dependency.
What to do starting today
If you’re building with AI right now and you haven’t been thinking about this, here is the immediate list.
- Define your gold-standard output. What does “correct” look like in your domain? This is harder than it sounds. If you cannot define it precisely, you cannot label for it, and you cannot train for it.
- Start capturing labeled examples immediately. Every time a human expert reviews an AI output, that is training signal. Log it. Input. Output. Correction. Reason for correction. Every single one.
- Build the feedback loop into the product. Thumbs up/down is a start. Explicit corrections are better. Expert review workflows are best. Make it easy for users, especially the heavy ones, to tell you when the model is wrong.
- Audit what you already have. You probably have more data than you think. Customer emails. Support tickets. Past decisions. Prior outputs that were accepted or rejected. Some of this is recoverable as training signal with the right labeling work.
- Hire for data, not just model use. Most “AI teams” right now are full of prompt engineers and API integrators. The team you need to build a real AI business also needs data engineers, annotation specialists, and people who understand evaluation methodology.
The thing nobody is rushing to do
The AI gold rush is real. The opportunity is real. But most people are rushing to pan for gold in a river someone else owns. The data-centric companies are quietly buying the land.
Data is the asset. The model is just the current best way to use it. Don’t confuse renting the best tool with owning the best resource.
The moat is not the model. It is what trained it.
Build the data business first. The AI will follow.
If you’re staring at this and realizing your “AI strategy” is actually an “AI dependency,” that’s the work. Mapping where your business already generates training signal, and where that signal is leaking out unstructured, is the unglamorous first step that separates the durable AI businesses from the temporary ones. See how we think about that for operators.