制定企业数据采集政策:一份实用模板

大多数收集网络数据的公司都没有成文的规则来规范这项工作。一名开发人员为定价项目搭建了一个爬虫,另一个团队把它复制过去用于潜在客户调研,一名承包商又加了第三个,结果没人能说清究竟收集了哪些网站的数据、存储了哪些个人数据,也没人知道该由谁来回应网站所有者的投诉。工作本身通常没有问题,问题在于没人能证明它没有问题。

一份简短的内部政策就能解决这个问题。它为工程师提供清晰的默认规则,让法务和安全团队只需审查一次而非每次都审查,并且在客户、审计方或网站向公司询问其如何收集数据时,能给出明确答复。本指南将说明这样一份政策需要涵盖哪些内容,并提供一份可供调整使用的模板。

要点总结

• 一份收集政策应当简短到工程师愿意去读:范围、审批流程、关于数据来源的规则、关于个人数据的规则,以及当有人提出异议时该怎么办。
• 让安全路径成为默认选项。公开的、无需登录的页面,诚实标识身份,适度的访问速度,以及遵守 robots.txt,这些无需特别审批;其他情况则需要。
• 把异议当作真正的异议对待。以法国数据保护机构为例,它要求收集方排除那些通过 robots.txt 或 CAPTCHA 表示反对的网站。
• 个人数据会改变一切:明确你可以收集哪些数据,在收集时就将其最小化,设定保留期限,并确保可以删除。
• 指定一名负责人和一套下架处理流程。收到第一起投诉时才去决定由谁来处理,为时已晚。
• 这份模板只是一个起点,并非法律意见;请让法律顾问根据你所在的司法辖区和合同条款进行审查。

为什么成文政策很重要

有三个实际原因。

一致性。 没有成文规则时,每个项目都会自行决定如何处理 robots.txt、访问速度、个人数据和保留期限。有些项目会谨慎行事,有些则不会,而公司要为最不谨慎的那个项目承担风险。

速度。 有了清晰默认规则的政策,大多数项目无需开会就能启动。法务和安全只需审查一次政策,之后只需处理例外情况。

证据。 数据保护监管机构要求数据控制者能够证明自己采取了哪些保障措施。例如,法国数据保护机构 CNIL 发布了关于通过网络爬取收集个人数据的指引,其中列出了诸如预先确定收集标准、排除明确表示反对的网站(包括通过 robots.txt 或 CAPTCHA 表示反对的)、过滤掉不必要的数据,以及一旦识别出敏感数据就立即删除等措施。一份成文政策正是你用来证明这些措施确实存在的方式。

政策需要涵盖的内容

章节	它回答的问题
目的与范围	这适用于哪些活动和团队?
角色	谁负责维护政策,谁批准项目,谁回应投诉?
默认规则	任何项目在不经请示的情况下可以做什么?
审批	哪些情况需要批准,由谁批准,需要提供哪些信息?
数据来源	哪些网站和页面在允许范围内,我们如何对待它们发出的信号?
个人数据	我们可以收集哪些关于个人的数据,如何将其最小化并加以保护?
技术操作规范	收集方如何标识自己的身份、控制请求速度、处理凭证?
供应商	我们对代理和数据供应商有哪些要求?
存储与保留	收集到的数据存放在哪里,谁可以访问,保留多长时间?
异议与下架	当网站所有者、个人或监管机构提出异议时该怎么办?
记录与审查	我们记录哪些内容,何时审查该政策?

模板

根据贵公司情况调整措辞,删除不适用的部分,并保持简洁。方括号中的文字需由你自行填写。

1. 目的与范围

本政策规范 [公司名称] 及其员工和承包商对网站及在线服务进行自动化数据收集的行为,包括爬虫、抓取程序、浏览器自动化,以及向代表我方收集数据的第三方购买的数据。本政策不涵盖我方用户自愿提供给我方的数据,也不涵盖依照其自身条款使用的官方 API,但第 6 节适用的情形除外。

2. 角色

• 政策负责人: [角色,例如数据主管] 负责维护本政策及收集项目登记册。
• 审批人: [法务联系人] 和 [安全联系人] 负责批准第 4 节规定需要审批的项目。
• 项目负责人: 每个收集项目都应指定一名负责遵守本政策的人员。
• 下架处理联系人: [角色及共享邮箱] 负责接收并回应第 10 节所述的异议。

3. 适用于所有项目的默认规则

任何项目在满足以下条件时均可直接推进,无需进一步审批:

• 仅收集任何访客无需登录即可查看的公开页面;
• 遵守适用于该收集方的 robots.txt 及其他机器可读的退出选项;
• 诚实标识收集方身份,不将自动化流量伪装成特定个人;
• 控制请求速度,确保对目标不造成明显负载;
• 不收集超出第 6 节所允许范围的个人数据;
• 在启动前已记录在项目登记册中。

4. 需要审批的项目

项目若符合以下任一情形,须在启动前获得审批人的书面批准:

• 收集的个人数据超出为商业目的公开发布的商业联系方式;
• 收集任何特殊类别数据,例如健康、宗教或政治观点信息;
• 从登录后的页面、付费墙后或受其他访问控制保护的页面收集数据;
• 在网站已表明反对后仍继续收集,包括通过 robots.txt、CAPTCHA、屏蔽、合同条款或直接要求表达的反对;
• 用于训练、微调或评估机器学习模型;
• 将收集到的数据出售、许可或分享给 [公司名称] 之外的第三方。

申请中需说明目的、数据来源、数据字段、涉及的个人数据及其法律依据、预计数据量、保留期限以及项目负责人。

5. 数据来源及其信号

• 如果存在覆盖该需求的官方 API、数据源或许可,应优先使用。
• 在收集开始前,阅读并记录每个数据来源的相关条款。
• 将 robots.txt、速率限制、CAPTCHA、屏蔽以及公开的保留声明视为网站意愿的信号,而不是需要绕过的障碍。
• 不得规避访问控制、技术保护措施或身份验证。
• 一旦某数据来源表示反对,应立即停止从该来源收集数据,并在登记册中记录停止事宜。

6. 个人数据

• 仅收集既定目的所需的个人数据,并在收集时尽可能过滤掉其他个人数据。
• 除非根据第 4 节获得批准,否则绝不收集特殊类别数据;若因意外收集到此类数据,应在识别出后立即删除。
• 在分析不需要身份本身的情况下,对标识符进行假名化处理。
• 除非获得批准,否则不得将收集到的数据与其他来源的数据合并以识别个人身份。
• 确保能够根据个人请求找到并删除其数据。

7. 技术操作规范

• 代理、API 及目标账户的凭证应存储在经批准的密钥管理系统中,绝不写入代码。
• 仅使用符合第 8 节要求的代理和数据供应商。
• 为每次收集运行记录时间、数据来源、收集所在位置以及所用配置。
• 监控请求量和错误率,当某数据来源开始拒绝请求时自动暂停收集。

8. 供应商

代理和数据供应商必须能够说明其网络或数据的来源以及获得了何种同意,运行客户身份识别流程,执行可接受使用政策,并签署与本政策一致的条款。政策负责人应保留一份已批准供应商名单。

9. 存储与保留

• 仅将收集到的数据存储在 [已批准的系统] 中,访问权限仅限于有需要的人员。
• 原始收集页面保留时间不超过 [期限],提取出的数据保留时间不超过 [期限],除非审批中另有规定。
• 在保留期结束时删除数据,并记录删除情况。

10. 异议与下架

• 网站所有者、个人或监管机构提出的任何异议应在 [一个工作日] 内转交给下架处理联系人。
• 在审查异议期间,相关收集活动应暂停,除非法务另有建议。
• 下架处理联系人应在 [期限] 内作出回应,并记录异议内容、处理决定以及删除的任何数据。
• 针对同一项目的反复异议应触发对该项目审批的重新审查。

11. 记录与审查

政策负责人应保留项目登记册、审批记录、供应商名单及下架处理日志,并至少 [每年] 审查一次本政策,在法律或公司业务发生重大变化时也应及时审查。

让政策真正落地

一份放在共享硬盘里的政策不会带来任何改变。以下几个做法能让它真正发挥作用:

• 将登记流程放在项目启动的地方。 在工程师已经在使用的工具中设置一份简短表单,将默认规则列为勾选项,这样可以在项目启动之前而非之后就加以把关。
• 将默认规则内置到代码中。 一个共享的收集库,能够遵守 robots.txt、设置诚实的 User-Agent、控制请求速度并记录收集上下文,会使遵循政策成为最省力的路径,而不是额外的步骤。遵守 robots.txt 和 AI 退出声明 一文介绍了应关注哪些信号。
• 记录数据的观测位置。 按每次运行记录时间、位置和配置,正是日后为收集到的数据辩护的关键所在,正如 建立数据来源观测点标准的理由 一文所论证的那样。
• 审查你的供应商。 询问代理供应商其 IP 的来源方式,参见 供应商如何合乎道德地获取住宅 IP 以及 廉价代理背后的恶意软件经济,了解这一点为何重要。
• 让密钥远离代码。 在 CI/CD 中运行爬虫 展示了如何安全地处理代理凭证。
• 在动手之前先读懂信号。 快速检查某个数据来源受到何种保护机制保护,正如 我们的反爬虫技术栈查询工具 所示,能让你及早判断一个项目属于默认规则范围,还是需要审批。

关于更广泛的法律问题,参见 网络爬取是否合法 和 住宅代理与 GDPR;关于日常实践,参见 网络爬取最佳实践。

结语

数据收集政策不需要很长。它需要明确的范围、能让大多数工作顺利推进的安全默认规则、针对高风险情形的审批流程、关于个人数据的严格规定,以及在有人提出异议时负责回应的指定人员。

只需写一次,将其默认规则内置到工程师使用的工具中,并保持登记册的更新。这样,下次有人问起贵公司如何收集网络数据时,你给出的将是一份文档,而不是一阵手忙脚乱。请根据你的具体情况调整本模板,并在采用前让法律顾问进行审查。

来源与参考资料

• CNIL,合法利益的法律依据:关于网络爬取数据收集应实施措施的重点说明。
• IETF,RFC 9309:机器人排除协议,2022 年 9 月。