"Just scrape it" sounds efficient until you have to defend what you built. In AI, that phrase has become shorthand for one of the most dangerous habits in product development: collecting data first and asking questions about provenance, rights, and consent later. The problem is not only that this approach is messy. The problem is that it creates products whose foundations are difficult to explain, difficult to audit, and sometimes difficult to defend at all.

I keep seeing the same pattern across AI teams: the fastest prototype is often the least defensible production plan. A dataset gets assembled from public pages, the model performs well in a demo, and everyone celebrates progress. Then legal asks where the content came from, procurement wants a rights story, or a customer asks whether the system was trained on material that was actually allowed to be used. That is when "just scrape it" stops sounding clever and starts sounding expensive.

The price list now exists

For years, "expensive" was hypothetical. It is not anymore. In 2025, Anthropic agreed to pay $1.5 billion to settle a class action brought by authors — the largest publicly reported copyright settlement in US history, covering roughly half a million books at an implied rate of around $3,000 per work. The court granted final consideration of the deal in 2026, and the terms include something more instructive than the money: destruction of the pirated dataset itself.

The detail every AI team should tattoo somewhere visible is why Anthropic lost the argument that mattered. The judge actually ruled that training on copyrighted books can be transformative fair use — a genuine win for AI developers. What was not fair use was the acquisition: downloading over seven million books from pirate libraries. The court drew a bright line between what you do with data and how you obtained it, and rejected the idea that a legitimate end use retroactively blesses an illegitimate source.

That distinction is now the organising principle of AI data risk, and it is compounding. Music publishers filed a $3.1 billion claim against the same company in January 2026 built on the same acquisition theory. As of mid-2026, more than seventy AI copyright cases are active or recently resolved across US and international courts, with cumulative claimed damages estimated beyond $50 billion. Earlier, in Thomson Reuters v. Ross Intelligence, a US court rejected fair use for training on proprietary legal content outright. Outcomes vary by jurisdiction — Getty's UK case against Stability AI largely fell apart in late 2025, even as parallel US proceedings continue — but the direction is singular: how the data entered your system is now a litigated question with a market price.

Provenance is the product

Data provenance is not administrative overhead. It is the record of where data came from, what rights attached to it, how it was transformed, and whether it can be reused responsibly in a downstream system. Without that record, AI teams can still build something that works technically, but they cannot reliably explain, govern, or defend it later. That is why the NIST AI Risk Management Framework and its Generative AI Profile treat data privacy, intellectual property, and provenance as core risk areas rather than optional governance extras.

Many teams still misunderstand this point. They treat provenance as a compliance detail that can be cleaned up after launch, when in reality it belongs upstream in product design. If the source material is unclear, the product inherits that uncertainty from day one. Provenance is not separate from the product. It is part of the product.

One of the biggest mistakes AI teams make is assuming that "publicly available" means "safe to use." It does not. A page can be visible to everyone and still carry copyright, contractual restrictions, or ethical constraints. Public access is not permission — and after the settlements of the past year, no court, customer, or investor will accept the conflation.

Consent is not optional

Consent is one of the most under-discussed parts of AI strategy. Teams love to talk about scale, freshness, latency, and model quality, but often skip the harder question: did anyone actually agree to their content being used this way? That question is not only ethical. It is strategic, because systems built on weak consent foundations are harder to trust, harder to license, and harder to scale responsibly.

Researchers working on data authenticity and consent have made a blunt point: current documentation tooling is not enough to solve the core problem. That matches what product teams eventually discover. A spreadsheet of sources is not provenance. A legal note is not governance. And a "public web" label is not a substitute for a real consent strategy.

This is where AI teams reveal whether they are building a product or just accumulating content. Products require boundaries. Accumulation does not. Scraping without a consent framework is simply accumulation with a faster pipeline.

Synthetic data helps, but not magically

Synthetic data is often presented as the clean solution to provenance problems. Sometimes it genuinely helps: it can reduce privacy exposure, support testing, and let teams build when real data is sensitive or scarce. But synthetic data does not erase provenance. It still depends on source material, modelling assumptions, and design choices that need to be understood and documented.

If synthetic data is generated from weak, undocumented, or questionable sources, the risk does not vanish. It moves. You still need to know what influenced the output, what patterns were preserved, and whether the synthetic layer may still reveal characteristics of the original data. I have seen teams use synthetic data as a way to avoid uncomfortable questions. That is the wrong use case. Synthetic data should be a controlled design decision, not a rhetorical shield. If the real goal is to hide a weak provenance story, synthetic data will not save it. It will just make the story harder to trace.

What scraping breaks

The biggest damage from "just scrape it" is not always legal. It is architectural. Once data enters the system without lineage, the company loses the ability to answer basic questions later. Where did this come from? What was licensed? What was transformed? What was excluded? What is derived? That lack of visibility makes governance fragile and slows down every attempt to mature the product.

There is also a second-order business effect that teams often miss. Scraping creates the illusion of abundance. The pipeline fills quickly, so it feels like progress — but what the company actually gets is volume without clarity. I have watched teams build impressive demos on top of data they could not later defend. The prototype looks ready; the product cannot move forward because nobody can prove the data story. That is not a data problem. That is a strategy failure. It is the same trap I described in The Hidden Cost of AI: local speed purchased at the price of organisational understanding.

And provenance does not stop at training data. It matters just as much for retrieval systems, RAG pipelines, fine-tuning inputs, cached outputs, and prompts — any layer where content is reused or transformed. If the source layer is dirty, every layer above it becomes harder to trust.

A better way to build

The better strategy is not "never use external data." It is to stop pretending all data has equal legitimacy. Responsible teams distinguish between licensed, consented, public, internal, and synthetic sources; document what each source is allowed to do; and keep enough lineage to explain those choices later. That is not bureaucracy. That is product resilience — and, after the past year, it is also a valuation input, because acquirers and enterprise buyers have started running data-provenance due diligence the way they run security audits.

In practice, stronger teams do a few things differently. They map source types before model work begins. They keep records of permissions and restrictions. They refuse to collapse all public data into one reusable bucket. They treat provenance as architecture, not cleanup. And they review synthetic data with the same seriousness as source data.

This is where legal and product thinking have to work together. Legal can define the boundaries, but product decides what kind of system it wants to be. If the product depends on data it cannot explain, it is already weaker than it looks.

The cost of shortcuts

"Just scrape it" is attractive because it compresses time. But every shortcut in AI data strategy creates debt somewhere else: legal debt, governance debt, trust debt, reputational debt. The most dangerous part is the delay. The model works for months. The product wins early users. Then someone asks the question that should have been answered on day one: do we actually have the right to use this data, and can we prove where it came from?

A year ago, an unclear answer meant friction. Today it means exposure with a published price per work, a live docket of seventy-plus cases, and a precedent that a legitimate use does not launder an illegitimate source. AI strategy is not only about making models smarter. It is about making the system defendable, explainable, and durable. If your AI strategy starts with "just scrape it," you are not starting with speed. You are starting with hidden risk — and the risk is no longer hidden.