I want to draw a distinction that most organizations miss: there's a difference between a data infrastructure strategy and a data strategy. Infrastructure is about where data lives and how you access it. Strategy is about what data you collect, why you collect it, and how it creates compounding value over time.
Most companies have the first. Few have the second. And the ones that win in AI almost always have both.
Data as a Byproduct vs Data as a Product
When data is a byproduct, it's the residue of your operations. You run a hospital, so you have patient records. You run an e-commerce site, so you have transaction logs. You run a support operation, so you have ticket histories. This data exists because your business runs, not because you designed a data asset.
When data is a product, you've made deliberate decisions about what to collect, at what granularity, with what structure, to enable specific downstream capabilities. You're not just capturing what happens to exist - you're designing for the data you'll need in two years to build capabilities you haven't built yet.
The difference matters because byproduct data is usually structured for operational use, not for training or inference. It has gaps, inconsistencies, and quality issues that are fine for operations but fatal for ML. Product data is designed with future use in mind.
Walmart's supply chain data is a product. They've spent decades building the infrastructure to capture granular sell-through data at the SKU and store level, specifically because that data powers their demand forecasting and replenishment systems. That data asset is worth more than most of their technology. It's not a byproduct of running stores - it's a deliberate investment in a data asset.
The Data Flywheel
A data flywheel is a self-reinforcing loop where more users generate more data, which improves your model, which improves your product, which attracts more users. This is the mechanism behind Google Search, Spotify recommendations, and Amazon product ranking. Understanding whether you can build a flywheel is one of the most important questions in AI product strategy.
Most companies think they have a flywheel when they have a data collection process. They're not the same thing. A flywheel requires three conditions:
- The data generated by use actually improves the model. Not all usage data is training signal. Click data, for example, is notoriously noisy - people click on things they regret, things they ignore after clicking, things they misidentify. You need data that captures revealed preference, not just behavior.
- The improvement from more data is meaningful at scale. Most models exhibit diminishing returns on data past a certain volume. If you already have 10 million training examples, the marginal value of the next 10 million might be negligible. A flywheel only creates compounding advantage if improvement continues to scale.
- The loop is fast enough to matter. If it takes six months to collect data, retrain the model, and deploy it, your flywheel is too slow to be a real competitive advantage. You need a loop that can run in weeks, not quarters.
In healthcare, I've seen data flywheel claims that don't hold up. A company collects EHR data from 100 hospitals, trains a clinical risk model, deploys it, and claims they have a flywheel because each new hospital adds data. But the model only retrains quarterly, the data requires extensive manual annotation before it becomes training signal, and the accuracy improvement from adding hospitals 101-200 is marginal. That's not a flywheel. That's a data collection process.
Labeling Economics
One of the most underappreciated costs in enterprise AI is labeling. Not data collection - data labeling. Getting humans to annotate your training examples, classify your edge cases, evaluate your model outputs. This is frequently the bottleneck between having data and having useful data.
The economics of labeling are brutal at scale. Clinical NLP tasks - extracting diagnoses from notes, identifying adverse drug events, coding procedures - require medical professionals who cost $60-150/hour. At industrial volumes, the labeling budget easily exceeds the model training budget.
There are three approaches to this problem, and most teams default to the most expensive one:
Human Annotation (Most Expensive)
Pay domain experts to label data. Appropriate for high-stakes, low-volume tasks where accuracy matters enormously and edge cases are frequent. Clinical trials eligibility screening. Financial statement fraud detection. Legal document review. Don't use this for high-volume, lower-stakes tasks.
Programmatic Labeling
Use rules, heuristics, and weak supervision to generate noisy labels at scale, then use techniques like label smoothing and noise modeling to deal with the noise. Snorkel AI built an entire platform around this. The tradeoff is label quality: you get 85-90% accuracy labels at 1/10th the cost of human annotation. For many applications, that's sufficient.
Feedback Loops from Deployment
The most efficient labeling is when users provide implicit or explicit feedback on model outputs during normal use. When a radiologist overrides an AI recommendation, that's a label. When a user edits an AI-generated summary, that's a label. When someone marks an email as not-spam after your filter caught it, that's a label. Designing your product to capture these feedback signals is one of the highest-use data strategy decisions you can make.
At Edxcare, we built an adaptive learning system where student engagement signals - time-on-task, replay behavior, quiz attempts - served as implicit labels for content quality and difficulty calibration. We never had to pay anyone to annotate. The students' behavior was the annotation. This fundamentally changed our labeling economics.
Data Moats: What's Real and What's Not
The term data moat gets thrown around in AI strategy discussions as if collecting data automatically creates defensibility. It usually doesn't. Here's what actually creates a data moat versus what just feels like one.
Real Data Moats
Proprietary data that cannot be replicated: Decades of patient outcomes from an integrated health system. Real-time financial transaction data from processing millions of payments. User behavior data from a platform that has network effects. This data exists because of your specific position in a market that's hard to replicate.
Data with increasing marginal value: Some data types get more valuable as you accumulate more of it, not less. Rare disease phenotypes. Long-tail language patterns. Niche domain expertise. For these, having 10x more data isn't marginally better - it's categorically better because you're covering cases your competitors can't even see.
Data you've structured specifically for AI: The same raw data, organized for machine consumption rather than operational use, is a different asset entirely. Epic's EHR data becomes a moat when they structure it in ways that enable population health models. The underlying data might be commodity - the structured, curated, AI-ready version of it isn't.
Fake Data Moats
Large volumes of generic data: Having 100 million customer records doesn't create a moat if someone else also has 100 million customer records. Volume without uniqueness isn't a moat - it's a cost center.
Data that's already available elsewhere: Web-scraped data. Publicly available financial filings. Open government datasets. These aren't moats. They're commodities. Everyone has access to them.
Historical data that doesn't reflect current distribution: Data that's years old and represents a market or user base that no longer exists doesn't create defensibility. It creates models that are confidently wrong about the current world.
The Data Strategy Questions Worth Asking
When I'm evaluating an AI product's data strategy, I ask these questions:
- What data does this product generate that we don't have today?
- Is that data a training signal for improving the model, or is it just operational logs?
- What's our labeling strategy? What does a label cost, and how many do we need?
- What data would a competitor need to replicate our AI capability? Do they have access to it?
- What does our data look like in two years if we execute well? What's the asset we're building?
Most teams can answer the first question and struggle with the rest. The rest are the questions that determine whether you're building a data strategy or just a data infrastructure.
The Uncomfortable Conclusion
Building a real data strategy is slow, expensive, and doesn't produce results for 18-24 months. That's why most organizations don't have one - they have a data infrastructure strategy dressed up in the language of data strategy.
The organizations that do it right - Google, Amazon, Epic, Palantir - made explicit decisions years in advance about what data assets they wanted to own, structured their products to generate that data, and invested in the labeling and curation infrastructure to make the raw data useful. They treated data as a capital asset, not an operational byproduct.
That framing is the starting point. If your data is a byproduct of your operations, you're at the mercy of whatever your operations happen to produce. If your data is a product you're deliberately building, you're building an asset that compounds.
