EDPB 刚刚为爬虫编写了一份规范
欧洲数据保护机构对 AI 模型发表过许多看法。但在今年夏天之前，没有任何内容告诉工程师爬虫在抓取第一个页面之前应该做什么。
《关于生成式 AI 背景下网络爬取的 03/2026 号指南》改变了这一点。欧洲数据保护委员会（EDPB）于 2026 年 7 月 7 日通过了该草案，其公众意见征集将于 2026 年 10 月 30 日截止。从字面上看，适用范围很窄：私营公司抓取个人数据用于训练或微调生成式 AI。实际上，这是监管机构迄今发布的最详细的说明，阐述了如何构建一个具有抗辩能力的爬取任务，从发出第一个 request 之前编写的筛选标准，到最后一条记录上的时间戳。
在通读全部 23 页后，我们的理解是：草案并不关心你使用什么工具。它关心的是你是否能说清楚收集了什么、从哪里收集以及何时收集。能够通过单次查询回答这些问题的爬虫不会有问题。而开放式的全网 crawl 则几乎会在每个条款上面临挑战。
（免责声明：这不是法律建议。首先，我们参考的是一份草案；其次，我们是工程师，仅从代码的角度来解读其含义。）
定向还是非定向是关键界限
第 8 段根据收集的明确性和限制程度将爬取分为两类，“而不是根据所使用的技术工具”。定向爬取遵循收集标准：特定域名、特定语言、特定主题。非定向爬取则是跟随发现的每个链接进行抓取的 crawler。委员会的担忧很明确：随着队列的增长，控制者“对其收集和处理的个人数据知之甚少”。
这种区分贯穿全文。数据最小化原则要求你在开始收集之前“定义精确的收集标准”并运行“数据映射和资产清点流程”（第 37 段）。合法利益下的必要性测试指出，缩小标准范围“而不是爬取互联网的大部分内容”，可能正是使数据处理具备必要性的前提（第 52 段）。透明度要求公布数据源列表，最好包含域名、URL 和收集日期（第 30 和 31 段）。
一个在十几个零售域名上抓取固定产品页面列表的价格追踪器，可以通过其配置文件生成所有这些记录。广度优先的 crawl 则做不到。Privacy World 对该草案的评论准确指出了这种冲突：各项合规义务是为清楚自己收集了什么的控制者而写的，而委员会此前恰恰承认，非定向 crawl 可能会包含其无法清点的个人数据。
**这意味着：**如果你抓取的任何内容涉及自然人（带有用户名的评价、包含中介姓名和电话的房源、论坛帖子），你的数据采集标准现在就是一项合规凭证。请将其保存在爬虫旁边的版本控制系统中，而不是只留在某个人的脑子里。
网站的“拒绝”现在会对你产生不利影响
这是将对绝大多数数据流水线产生影响的部分。该草案列出了表明网站明确反对被抓取的技术措施：robots.txt、ai.txt、“查看内容需要机器人身份验证”，以及“要求执行只能由人类完成的操作”的检查（第 37 段）。它对训练数据的建议是排除这些网站。
同样的信号在利益权衡评估（balancing test）中再次出现。当公众知道某个网站采用了这些措施但该网站仍然被抓取时，草案指出他们通常不太会预期到此类数据处理（第 64 段）。示例 5 明确说明了这一点：如果一个平台包含 robots.txt 排除项、仅限人类的检查机制，并声明禁止用于 AI 训练，这意味着其用户“无法合理预期”第三方会出于该目的抓取他们的数据。反之亦然。没有 robots.txt 并不等同于同意（第 45 段）。
法国 CNIL 最早提出了这一观点。其于 2025 年 6 月首次发布的关于合法利益与网络抓取的主题指南指出，当控制者未排除通过 robots.txt 或仅限人类检查表达反对意见的网站时，此类处理“不属于数据主体的合理预期范围”。
在缓解措施中还有两项不太起眼的条款（第 66c 段）。其一排除了仅在登录后可见的个人数据。另一项则涵盖了向爬虫的 User-Agent 与向普通浏览器返回不同内容的网站，“特别是当抓取服务收到的数据多于”普通人所能看到的内容时。如果你的爬虫读取的内部 API 返回的数据比网页展示的更丰富，他们指的就是这种情况。
我们在《搜索、Agent 与训练：Web 的新机器人规则》中讨论了此问题的机器可读层面（robots.txt 扩展、签名 Agent、内容信号），并在《按抓取付费正在将 Web 割裂为两部分》中探讨了宁愿收费也不直接拒绝的发布商。EDPB 的草案是监管机构首次将这些信号视为人们合理预期的证据。
**这意味着：**在采集数据时，按域名将 robots.txt（以及网站具备的 ai.txt）的状态与数据一并记录。如果一年后有人质问某个数据源为何会进入训练集，“我们在抓取当天它是允许的”只有在你当时留存了记录的前提下才能作为抗辩理由。
抓取方可能属于数据处理者
第 3.2.1 节内容简短，很容易被跳过。但不应该忽视它，特别是当你为客户构建爬虫时。如果你代表开发者“根据其书面说明”创建训练数据集，你可能是处理者，而开发者是控制者（第 18 段）。如果你和客户共同确定采集标准，你们可能是共同控制者（第 20 段，示例 1）。如果你自行抓取了数据集，随后他人复用该数据，各方需对各自的处理行为独立承担责任（第 19 段）。
Brian Hengesbaugh 在 IAPP 上针对该草案的专栏文章指出了商业层面的核心问题。当合同将供应商指定为处理者时，客户需要承担该指引所述的合规工作，而供应商自身的直接责任“可能比想象中更有限，也更让人无法高枕无忧”。这种约束是相互的。客户不能直接将合规责任甩给编写爬虫的自由职业者，而自行决定数据源列表的自由职业者最终可能会意外变成控制者。
数据团队现在应作出的调整
大多数商业爬取行为不受此影响。价格、库存水平、产品规格和时间表通常不属于个人数据，因此不在 GDPR 的管辖范围内。草案明确指出，在“混合”数据集中，规则适用于其中的个人数据部分（第 13 段）。因此，包含卖家姓名的商品页面或带有用户名的评价，都会使该部分数据纳入监管范围。
对于确实会收集个人信息的任务，以下是草案要求转化为具体数据管道实现的方式：
| 草案要求 | 数据管道实现 |
|---|---|
| 采集标准 | 每个任务的 URL 规则 |
| 基于语法的过滤 | 解析时通过正则表达式丢弃 |
| 带时间戳的记录 | 每行数据记录 fetched_at |
| 数据源列表 | 配置中的域名列表 |
| 遵循退出机制 | 记录 robots.txt 状态 |
其中的两行需要进一步展开说明。
在解析时过滤，而不是在几周后的清理任务中处理。第 38 段提到了在采集过程中针对社会保障号和电话号码等格式应用正则表达式。从未存储的数据，就是你永远不必解释的数据；第 60 段直截了当地指出了为什么这对 AI 至关重要：模型一旦完成训练，个人数据就“无法轻易从中删除”。
在每条记录上保留来源 URL 和抓取时间。第 42 段要求记录时间戳以确保准确性，但这同样的两个字段也可以解答后续关于某条数据来源的任何疑问。AI Act 已经在收紧训练数据规则（我们在 4 月曾撰文讨论过），而且这些规则一直在反复追问这同一个问题。
如果你为客户开发，必须将说明写入书面规范：数据源、字段、排除项。草案认为，书面说明是让你保持处理者身份而非共同控制者的关键，一页明确的规范远胜于日后就角色认定产生争端。
10 月 30 日之后会发生什么
最终文本仍会修改，而更重大的调整可能来自布鲁塞尔，而非委员会。2026 年 10 月 21 日，理事会就修订 GDPR 的综合数字法案（Digital Omnibus）达成了谈判立场。根据 IAPP 关于该授权的报告，成员国针对 AI 训练数据增加了“关于处理个人数据合法依据的澄清，以及维持适当保护措施的必要性”。下一步是与欧洲议会展开谈判。无论最终措辞如何，成员国都希望保留这些保护措施，这指向了一种与本草案非常相似的利益权衡测试（balancing test）。
我们认为，定向与非定向抓取的划分会在两轮流程中保留下来，因为这是草案中唯一关乎工程实现而非法律条文的部分。监管机构不会去审查爬虫的代码。但它可以索取你的数据采集标准、数据源列表和时间戳，如果工程团队能在当天下午提交这些内容，监管方也就几乎没有争议余地了。
因此，隐私监管机构向抓取工具提出的下一个问题，不会是“它如何运行”，而是“它被指派采集了什么”。