Essay · AI & Defensibility
Why a dataset is not a moat, and what defensibility actually looks like in medical AI · Juan Vegarra
There is a phrase that appears in almost every healthcare AI pitch, and it is doing far less work than the people saying it believe. We have a data moat. It is meant to end the conversation, to signal that the company has something defensible and rare. More often it signals the opposite, that the team has confused a thing they possess with a thing that protects them. This piece is about the difference, why it matters more in medical AI than almost anywhere, and what an actual moat is built from.
Start with the distinction the phrase papers over. Most teams that claim a data moat have a dataset. The two are not the same, and treating them as the same is one of the more expensive mistakes in the field.
A dataset is a snapshot. It captures the world as it was on the day you collected it, and it begins to decay the day after. Clinical practice shifts, scanners change, populations move, and the static pile of data that looked so impressive at the seed round ages quietly in the corner. A moat is something else entirely. A moat is a flywheel, a loop in which every use of the product makes the product better, and every improvement wins the next use. The dataset sits still. The flywheel turns.
A dataset is a snapshot that starts decaying the day after you collect it. A moat is a flywheel that turns every use into an edge on the next one.
Here is the test that cuts through the marketing, and it is worth applying to your own company before an investor applies it for you. If your team stopped touching the product for ninety days, would it still get better on its own. If the answer is yes, because usage feeds a loop that sharpens the model without anyone lifting a finger, you have a flywheel. If the answer is no, because improvement requires your team to manually collect, label, and retrain, you have a dataset with good marketing. Those two things look similar on a slide and are underwritten completely differently by anyone who knows what they are looking at.
Now layer on the competitive reality that makes this urgent, because the threat is not only that your moat is weaker than you think. It is who is on the other side of it. A large share of medical AI products are, structurally, a thin layer over a model someone else built, reading images some other company's hardware captured. The team has tuned a wrapper. They do not own the model and they do not own the data stream.
That is a dangerous place to stand, because the frontier labs are coming down the stack, and they have the two things a wrapper does not. The model and the reach. Anything that lives entirely inside the model layer is, over a long enough horizon, something a better-resourced model company can absorb. You cannot out-clever the people who build the models on the ground they own. The only durable response is to stop competing on their ground and build on ground they have no reason to take.
So where will they not go. Into atoms. Into the physical, regulated, capital-intensive, slow-iterating world of owning the capture itself. The frontier labs are software companies with software economics and software speed. The hard, unglamorous work of building an instrument that captures a proprietary signal, clearing it through a regulator, and deploying it into clinical settings is precisely the work they have no appetite and no structural reason to do. That is the ground worth taking.
A company that owns the instrument generating its data owns both ends of the chain. It captures the data and it interprets it. The data is proprietary from the very first frame, in a format no one else can source, because no one else has the instrument that produces it. That is a fundamentally stronger position than a software product reading a data stream it rents from the hardware vendor who could revoke or replicate it tomorrow. Owning the capture means owning the input, and owning the input is the one thing a model company coming down the stack cannot simply absorb.
This is the point where anyone who has actually built hardware starts typing a rebuttal, and they are right to, so let me say it before they do. Atoms are harder than bits. Hardware iterates slower, burns more capital early, and carries regulatory and manufacturing risk that pure software never touches. The graveyard of hardware companies is real. And, crucially, owning a sensor is not automatically a moat. Plenty of hardware companies sit on genuinely proprietary data streams and do nothing with them, capturing a unique input and then failing to turn it into any compounding advantage at all. The sensor alone is necessary and nowhere near sufficient.
So the claim is not that hardware wins because hardware is hard. That would be confusing difficulty for defensibility. The claim is more specific, and it is the heart of the matter.
The real moat is the combination. A proprietary input that no one else can capture, plus a compounding loop that turns that input into an advantage that grows with every use. The sensor produces data nobody else has. The loop converts that data into a model that gets better the more the product is used. And because the input is proprietary, the gap the loop opens is one competitors cannot close by buying data or licensing a model, because the data they would need does not exist outside your instrument.
That is what defensibility actually looks like in this field. Not a pile of data, however large. Not a clever model, however good, because models are catching up to each other faster every quarter. A unique input feeding a compounding loop, on ground the frontier labs were never going to build. Own the input, run the loop, and the distance between you and everyone else widens on its own.
There is a reason the data flywheel is harder to build in healthcare than in almost any consumer domain, and it is worth understanding because it is also where the advantage hides. In most fields, the system learns quickly whether it was right. A recommendation is clicked or ignored within seconds. In medicine, the ground truth arrives late, expensively, and from somewhere else entirely. Whether a read was correct might only be known after a biopsy, a follow-up scan, a pathology report, a clinical course that plays out over months. The label that teaches the model is delayed, costly, and often noisy.
This is precisely why the moment-of-truth capture matters so much. A system that records what the clinician saw at the decisive instant, and can later link it to the outcome that resolved the question, owns a clean training signal that most medical AI never gets. The hard part is the linkage, connecting the captured moment to the eventual truth, and the teams that solve it have something rare. A flywheel that learns from outcomes, not just from inputs. The label problem is a wall for everyone, and the company that builds the machinery to climb it turns a universal difficulty into a private advantage.
A flywheel needs volume to turn, which creates an obvious chicken-and-egg problem at the start. The loop improves with use, but use requires a product good enough to adopt, which requires the loop to have already turned. Many promising data strategies die in this gap, waiting for a scale that never comes because the early product was not yet good enough to earn it.
The way through is to be honest that scale is the fuel and not the engine. The engine is a product that is useful on day one, before the loop has turned even once, good enough on its initial training to earn real adoption. Only then does usage start spinning the wheel, and only then does the compounding advantage begin to separate you from competitors. Teams that lead with the flywheel as the whole story, before they have a product worth adopting, have the order backwards. Build something worth using cold. Earn the early volume. Then let the loop do what no competitor's loop can, because no competitor has your input.
There is a final move that turns this from a strong position into a durable one, and it runs against the instinct of a lot of AI teams. Do not build your company around a single model. The frontier model that wins your demo today will be surpassed within a year, probably sooner. A company whose entire advantage is wired to one model, one vendor, one architecture, is a company whose moat resets every time the frontier moves, and the frontier moves constantly.
A company built around its own data capture sidesteps this by design. The proprietary input and the compounding loop are permanent. The model that sits on top is a component, swappable as the field advances. When a better model ships, a platform built this way adopts it in an afternoon rather than rebuilding for a year, because its moat was never the model in the first place. Own the input, run the loop, and rent the model. Model-agnostic is not a hedge. It is the thing that lets you stay current forever without betting the company on anyone else's release schedule.
It clarifies a lot to separate the three things founders mean when they say data advantage, because only one of them is a moat. The first is volume, simply having more data than the next team. Volume is the weakest of the three, because data is increasingly abundant and a well-funded competitor can usually buy or assemble their way to enough of it. The second is uniqueness, having data nobody else can get. Uniqueness is stronger, and it is real when your data comes from a source others cannot access. But uniqueness alone is static, and a static advantage erodes as the world moves on from the snapshot you captured.
The third is compounding, and it is the only one that is genuinely a moat. Compounding means each use of the product generates data that improves the product, which drives more use, which generates more data. Volume gives you a head start. Uniqueness gives you something others lack. Only compounding gives you a gap that widens on its own. The strongest position stacks all three, a unique input, in meaningful volume, feeding a loop that compounds, and the weakest pretends that a large static pile is the same as a turning wheel.
A flywheel is easy to draw and hard to build, and most teams that claim one are missing at least one of the parts it actually requires. It needs instrumented capture, so that real-world use is recorded cleanly rather than lost. It needs outcomes or labels, so the system can learn whether it was right, which in medicine is often the hardest part, because the ground truth arrives later and elsewhere. It needs a retraining loop that can actually fold new data back into the model on a sane cadence. And it needs enough deployment to generate signal faster than the world changes underneath it.
Miss any one of those and the wheel does not turn. A product with beautiful capture but no outcome labels learns nothing from what it sees. A product with labels but no retraining loop accumulates lessons it never applies. The reason most data moats are imaginary is not that the teams are dishonest. It is that building a loop with all four parts working together is genuinely difficult, and a slide that says flywheel hides the three parts that are missing.
There is a subtle, underappreciated lever in all of this, and it is the format the data lives in. A company that captures its data in a proprietary native format, rich with detail no standard interchange format preserves, owns something a company piping everything into a commodity standard does not. The proprietary format is where the unique signal lives. At the same time, the product has to play with the rest of the clinical world, which speaks standard formats, so the durable architecture keeps both, a proprietary native layer that holds the full signal and feeds the moat, and a standard interchange layer that lets the product interoperate.
Get that architecture right and you resolve a tension that sinks a lot of platforms. You stay interoperable enough to be adopted, while keeping the rich proprietary signal that competitors, working only in the commodity standard, never even see. The format is not a plumbing detail. It is part of the moat, because it determines whether the unique signal survives capture or gets flattened into something everyone has.
Before claiming a moat in a pitch, a team should sit with one uncomfortable question and answer it honestly. If a well-funded, highly competent competitor decided tomorrow to come straight at us, what exactly stops them. If the honest answer is our model is better, that is not a moat, because models converge and a richer competitor can close a model gap with money and time. If the answer is our dataset is bigger, that is not a moat either, because data is increasingly purchasable and a static pile only depreciates.
The answer that actually stops a competitor is structural. They cannot capture what we capture, because they do not have the instrument, and even if they built one tomorrow, our loop has been compounding on that proprietary input for years and the gap is wider than they can sprint across. That is a moat, because it is not a lead in a race anyone can run. It is a race the competitor cannot enter on the same track. If your honest answer to the question is not structural, you do not have a moat yet, and the most valuable thing the question does is tell you what you still have to build.
All of this matters to valuation, not just to engineering, and it is worth being explicit about why. A company that sells a device competes on the device and is valued like a device company, on units and margins and the next product cycle. A company that owns a proprietary input feeding a compounding loop is something else. It has an advantage that grows rather than depreciates, an asset that the market, when it understands it, underwrites as a platform rather than a product.
That is the prize hiding inside the unglamorous hardware work. Not the sensor as a better gadget, but the sensor as the source of an input no one else has, feeding a loop no one else can run, swappable models riding on top. Get that combination right and the moat is not a phrase in a pitch. It is the thing competitors stare at and cannot cross.
Juan Vegarra is the author of An Outsider's Playbook (forthcoming). The views here are his own. More from the Notebook · Continue the conversation