AI 產品抓取網頁是否合法？創辦人建置前應權衡的法律風險

Web scraping is not illegal by default, but it is not a free lunch either. The legal exposure of an AI product built on scraped data depends on three things: whether the data is public or behind a login, whether it contains personal data, and whether you republish it or only use it internally. Get those three right in the design and most of the risk disappears before a lawyer ever sees the product.

This is a founder's guide, not legal advice. The point is to help you ask the right questions before you spend a build budget on a feature that compliance may force you to rip out.

Where the risk actually sits

Founders tend to worry about the wrong thing. The fear is "hacking" style liability. In practice, scraping disputes land in four buckets.

1. Contract: the site's terms of service

Most commercial sites ban automated access in their terms. Whether those terms bind you depends heavily on whether you agreed to them. Browse-wrap terms (a footer link nobody clicks) are weaker than click-wrap terms you accepted when creating an account. The practical rule: scraping behind a login you created means you agreed to the terms, and you are now in breach-of-contract territory. Scraping public pages without an account is a much weaker claim against you.

2. Computer misuse laws

Statutes like the US Computer Fraud and Abuse Act (18 U.S.C. § 1030) are about unauthorised access. Recent US case law has narrowed this for publicly available pages, but circumventing authentication, IP bans or technical blocks puts you back in scope. If you have to defeat a block to keep scraping, treat that as a signal to stop, not an engineering challenge.

3. Personal data: GDPR and its cousins

This is the bucket that bites AI products hardest. If you scrape names, emails, job titles or anything that identifies a person, you are processing personal data and need a lawful basis under GDPR Article 6, plus transparency and deletion obligations. "It was public" is not a lawful basis on its own. Scraping personal data at scale and then enriching it with an LLM makes this worse, because you are now profiling.

4. Copyright and database rights

Factual data (prices, opening hours, product specs) is weakly protected. Articles, images, descriptions and curated datasets are not. In the EU, the Database Directive 96/9/EC adds a separate right over substantial extraction from structured collections. The 2019 Digital Single Market Directive carved out a text-and-data-mining exception for commercial use, but rights holders can opt out through machine-readable means. That is why robots.txt and similar signals matter more in Europe than their informal status suggests.

The risk ladder, from safe to stop

Use this to place your feature before scoping it:

• Low risk: public pages, no login, factual or company-level data, used internally to generate your own output (a summary, a score, a draft). Rate-limited, respects robots.txt.
• Medium risk: public pages but you store and display excerpts of the original content to users, or you build a searchable index of a competitor's catalogue.
• High risk: personal data at scale (profiles, contact details), data behind any authentication, or republishing copyrighted content as your product.
• Stop: bypassing blocks, scraping health or financial data about individuals, or scraping platforms whose terms you accepted and which explicitly forbid it.

If your feature is "medium" or above, that is not an automatic no. It means the legal review and the data design need to happen before the sprint, and the cost estimate in your scraping pipeline budget should include them.

Design choices that lower exposure

Legal risk in scraping is mostly an architecture decision. A few patterns move a feature down the ladder without killing it.

Extract facts, drop the source

The biggest lever is retention. If you fetch a page, extract the handful of facts you need and discard the raw HTML, you hold almost no copyrightable material and a minimal footprint of anything personal. If you store full page copies "in case we need them later", you have built a copy of someone else's site.

We run this pattern in our own outreach engine. It fetches each prospect's public site with a self-hosted Firecrawl instance and passes the content to a local LLM in a single call that both extracts what the company does and drafts one tailored email. The raw page content is thrown away after the call. We originally tried a multi-step chain (crawl, summarise, classify, draft) and the single-call version was both cheaper and produced better emails, which is a useful reminder that simpler pipelines often win on compliance too, because there are fewer places where data lingers.

Scrape the company, not the people

For sales and market-intelligence use cases, almost everything you need is company-level: what they sell, who they sell to, what stack they advertise, what they recently launched. Scope your extraction prompt to that and explicitly instruct the model to ignore personal names and contact details. In our outreach engine the extraction prompt asks for exactly one thing, what the company does, and the only person-level field anywhere in the pipeline is the single address the email goes to. That one address still needs a lawful basis, but there is no shadow database of individuals to defend, because the pipeline never had a place to put one.

Respect the signals, log that you did

Honour robots.txt, identify your crawler with a real user agent and contact URL, rate-limit per domain, and keep a log of which pages were fetched and when. None of this is strictly required everywhere, but when a site owner complains, "we honoured your robots.txt and crawled at one request every few seconds" is a very different conversation from "we rotated residential proxies to get around your block".

Prefer official data when it exists

Many sites you would scrape also publish feeds, sitemaps, APIs or structured data. An API with terms you accept is slower to integrate but gives you a contract you can point to. If a data vendor already licenses what you need, compare their price to the cost of building and defending a scraper. That is a genuine build-vs-buy decision, not an engineering preference.

Self-host or use a scraping API?

If scraped data is a core input to your product, self-hosting an open-source crawler such as Firecrawl is usually the right call. The reason we self-host it for our outreach engine is not cost, it is that every answer to the review questions above becomes ours to give: the rate limit is set in our config, robots.txt handling is our code, the fetched page lives in memory on our box for one LLM call and is then gone, and nothing leaves our infrastructure because the model is local too. That is a short, checkable story to tell a data-protection officer. For a low-volume or experimental feature, a hosted scraping API gets you to a signal faster, and you can migrate once the feature proves itself.

Either way, check what the provider does with the content it fetches for you. Some hosted services cache pages or use them to improve their own systems, which makes your retention policy only as good as theirs. If you have promised "we discard the raw page after extraction" and your provider keeps a copy, that promise is already broken.

Questions to settle before you brief an agency

• What exactly do we extract, and what do we delete immediately after?
• Does any of it identify a person? If so, what is our lawful basis and deletion path?
• Will users ever see the original content, or only our derived output?
• Is anything behind a login or a block we would need to circumvent?
• Which jurisdictions are the sites and our users in?
• Is there an API or licensed source that makes this moot?

Bring answers to these to your first scoping call and the estimate you get back will be far more accurate. If the feature touches outreach, read our notes on cold email deliverability as well, because a technically clean scraper paired with a spammy send pipeline still ends badly.

The short version

Scraping public, factual, company-level data and turning it into your own output is a well-trodden, defensible path. Scraping people, scraping behind logins, or republishing what you scraped is where products get pulled. Decide which side of that line your feature sits on before you build, design the pipeline to keep as little as possible, and treat blocks as a stop sign.

If you are weighing an AI product that depends on external web data and want a second opinion on the architecture and the risk ladder, let's talk.

Originally published on the Pykero blog.