调研结果

GDPR正文里没有对此作出规定，但recital部分有两条还是值得关注。

Recital 18首先明确，自然人出于纯粹个人或家庭活动目的处理个人数据的，不受 GDPR 规制。但它同时强调，对于为此类个人或家庭活动提供个人数据处理手段的控制者或处理者，GDPR 仍然适用。

这项规定与本文讨论的问题直接相关。假设消费者购买了一台智能硬件设备，自行决定是否使用，并且所有个人数据的采集、分析和存储都在设备本地完成，那么消费者自身的处理活动可能适用家庭活动豁免。但这一豁免并不当然延伸至设备制造商。

但另一方面，Recital 18 并没有直接说设备制造商是否必然属于controller或processor。它的表述是“controllers or processors which provide the means”，也就是说，它预设了这种场景下提供处理手段的主体已经具有controller或processor身份，但不等于提供处理手段就能和controller/processor身份画等号。

所以，Recital 18只能推导出：消费者享有家庭活动中个人信息处理活动的豁免，并不意味着设备制造商也可以当然免责。

Recital 78又说，在开发、设计、选择和使用以个人数据处理为基础，或者为实现其功能而需要处理个人数据的应用程序、服务和产品时，应当鼓励相关产品、服务和应用程序的生产商在开发和设计过程中考虑个人数据保护权利，并在充分考虑现有技术水平的基础上，确保数据控制者和数据处理者能够履行其数据保护义务。“鼓励”这个词语就很微妙，它似乎是在暗示作为生产商并不是mandatorily需要去满足PbD义务，而只是一个better to have的倡导。特别是这一条前半句还是对controller的should要求，前后两句产生鲜明对比，是否说明生产商不受到GDPR的强制管辖？

在EDPB《车联网个人数据保护指南》（Guidelines 01/2020）里，EDPB也援引了recital 18的观点，并在此基础上往前更近了一步—GDPR 仍适用于为此类个人或家庭活动提供个人数据处理手段的数据控制者或数据处理者（例如汽车制造商、服务提供商等）。

如果单看这一句，似乎可以理解为 EDPB 认为汽车制造商（硬件制造商）也落入 GDPR 的监管范围，无论其身份是 controller 还是 processor。但我觉得不能就此下结论。首先，这份指南讨论的是车联网场景，汽车制造商可能通过远程服务、数据回传等方式参与个人数据处理，其事实背景未必与本文假设的完全本地处理情形一致。更重要的是，EDPB 在紧接着的论述中使用了“when they are acting as data controller or data processor”这种限定表述。换句话说，EDPB 强调的是：当制造商具有 C/P 身份时，不能因消费者享有家庭活动豁免而免除其 GDPR 义务；但至于制造商仅提供一台完全本地运行、自己无法接触数据的设备时，是否仍然构成 C/P，指南并未明确回答。（有点像是先有鸡还是先有蛋的问题）

同样的思考方式还出现在EDPB《关于智能眼镜的声明》（Statement on Smart glasses）第3.1节：

• 第24段：EDPB在讨论智能眼镜的透明度要求时，特意使用了“controllers and producers”的表述，建议二者在设计和开发智能眼镜时，考虑结合多种透明度保障措施，让周围的人能够及时意识到设备正在处理个人数据，并提供GDPR要求的相关信息。

• 脚注21： EDPB进一步援引GDPR Recital 78，指出鼓励智能眼镜制造商（producer）及相关应用程序、服务提供商在产品设计和开发过程中考虑个人数据保护权利，并确保controller和processor能够履行其数据保护义务。这里同样区分了“producers”和“controllers/processors”。

我的疑惑在于：将producer和controller/processor并列提及是为了强调两种不同属性的身份（但可以在一个人身上）呢？还是区分两类主体呢？是为了强调两种不同性质的身份（即同一主体可以兼具两种身份），还是在暗示这两类主体的互斥关系呢？

EDPB两个指南都给我一种“听君一席话 听君一席话”的感觉：如果硬件厂商是controller或processor，那么它当然需要履行相应的GDPR义务；但如果硬件厂商只是producer，EDPB鼓励其在产品设计阶段考虑数据保护。那么，硬件厂商究竟对应哪个角色？不知道。

英国ICO在《消费级物联网产品及服务指南》之“IOT产品使用哪些信息一节”中也讨论了类似问题。ICO举了智能行车记录仪和智能音箱的例子，认为消费者出于个人或家庭目的使用设备，可以适用家庭活动豁免；但制造商开展的个人数据处理仍然属于UK GDPR的适用范围。https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/online-tracking/guidance-for-consumer-internet-of-things-products-and-services/what-information-do-iot-products-use/

不过，我认为这两个例子同样没有解决本文的问题。首先，ICO并未明确说明相关数据完全在设备本地处理，且制造商无法远程访问。其次，ICO使用的是“The manufacturer’s processing of personal information”或者“ processing carried out by a legal entity for its own purposes”这样的表述，实际上已经预设制造商参与了相关处理，却没有解释仅仅设计和提供处理工具是否也构成这种参与。（这两句对应的原文我就不截图了，意义不大，可自行搜索关键词）

另外这个指南之“如何确保IoT产品的可问责制”一节还提了两个和这个问题有点关系的例子。https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/online-tracking/guidance-for-consumer-internet-of-things-products-and-services/how-do-we-ensure-accountability-in-iot-products/

• API示例：ICO认为，单纯开发、提供API并不当然使提供者成为controller。但是，如果API的使用方无法根据自身需要配置相关处理操作，而API提供者通过预先设计这些操作，对处理目的和方式产生了实质性影响，那么API提供者也可能构成joint controller。这个例子至少说明即使处理活动最终由使用方启动，技术提供者仍可能因为预先决定了处理操作而参与决定处理目的和方式。那么，对于那些数据采集类型、频率、分析算法均由制造商预先确定，用户只能选择是否启用功能的智能硬件，是否也可以采用类似的逻辑？当然，API案例本身并非纯本地处理场景所以也不算是“属于”派的直接证据。

  

• 儿童离线玩具示例：ICO认为，如果企业提供的电子玩具或其他产品完全不连接互联网，个人信息仅存储在产品内部，那么这些产品可能无需遵守英国《儿童守则》（Children's Code）。但ICO紧接着强调，即使企业不从设备收集任何信息，在制造这些产品时，也仍然必须遵循设计数据保护原则（data protection by design approach）。但问题又来了：GDPR下设计和默认的数据保护义务直接约束的是controller。此处表态究竟意味着即使制造商不接触数据也仍然可能构成controller？还是说，ICO单独讲PbD义务拎出来扩张至不是controller的制造商身上呢？

德国下萨克森州数据保护监管机构在2024年1月发布的《医疗健康领域数据保护常见问题》第25问中有一个比较明确的表态：如果健康应用的制造商／运营商仅负责生产应用及相应软件，个人数据仅在应用本身之上或内部处理，完全处于用户的独立控制范围，且制造商／运营商无法访问这些数据，那么制造商／运营商既不是C也不是P。https://www.datenschutzkonferenz-online.de/media/dskb/2023_11_06_Beschluss_cloudbasierte_digitale_Gesundheitsanwendungen.pdf。

这一表述与本文讨论的纯本地处理情形已经相当接近。可以看出下萨克森州是“不属于派”的。

不过，文件针对的是数字健康应用软件，而非独立运行的硬件设备。而且，监管机构并未进一步解释，如果制造商通过产品设计预先决定了数据采集范围、处理算法及输出结果，是否仍然属于“仅负责生产应用”的情形。

法国CNIL可以说是旗帜鲜明的不属于派。在2025年《移动应用建议》第3.3节中，CNIL明确表态，如果同时满足以下两个条件，提供个人数据处理工具的第三方可能既不是controller，也不是processor（https://www.cnil.fr/sites/default/files/2025-05/recommendation-mobiles-app.pdf）：

• 处理活动完全由用户自主决定和控制，且仅为了用户自身目的实施；

• 处理活动发生在与第三方隔离的环境中。 第三方虽然提供了处理工具，但之后无法再介入相关数据处理。

和德国一对比就能看出法国更加激进。德国监管机构的态度是，如果制造商仅仅生产应用它就不是C/P。但这个问题的思考链条断在了“仅生产是否包含预置处理设计”。而CNIL的两个条件方法论绕开了这个问题，而是从从另一头入手：不管制造商在产品设计阶段决定了什么，而是看具体处理活动由谁实施和控制，以及制造商在提供工具后是否还能介入数据处理。如果答案都是否，那制造商就不是C/P。

而且CNIL还给了一个例子↓：某应用程序出于其自身特定功能的目的（例如修图）访问用户的照片。这些数据仅在用户终端内存储和访问，不会向应用程序发布者或操作系统提供商的服务器共享任何信息。应用程序发布者和操作系统提供商均无法以任何方式介入这些数据的处理。在这种情况下，该应用程序仅作为向用户提供的一项软件工具运行。应用程序发布者和操作系统提供商应被视为单纯的第三方，因为二者既不决定相关数据处理的目的，也不决定处理方式。

可以说到了CNIL，这个问题才被以一种明确、果决的方式得到回答——即使预先设计了数据处理功能，也不意味着设计者决定了GDPR意义上的处理目的和方式。至少在CNIL列举的这些纯本地处理场景中，产品的技术设计权与具体处理活动的决定权被明确区分开来。

上文大多是观点和意见，我也尝试去搜索一些案例或者实践做法，但并没有找到和这个问题的核心矛盾点特别相关的，所以就不贴了。

我为什么认为硬件制造商极有可能是Controller

在监管机构大部分模棱两可+CNIL立场鲜明的背景下，我仍然倾向于认为，硬件制造商可能，且极有可能构成controller。以下是我的理由。

第一层：先划清几个法律概念的边界

我想先说一个可能有些基础、但又容易被忽略的问题：个人数据、个人数据处理活动、GDPR的适用范围、controller/processor身份，以及具体合规义务，这几个话题的外延其实并不总是重叠的。

个人数据是啥此篇就不讨论了。

首先，个人数据处理（processing）本身是一个范围非常广泛的概念。GDPR第2条规定，本条例适用于全部或部分通过自动化手段进行的个人数据处理行为，以及通过自动化手段以外的其他方式对构成或旨在构成存档系统一部分的个人数据所进行的处理行为。

这就意味着1）存在着属于processing但没有落入GDPR管辖范围的处理活动。比如，手写记录了其他人的姓名、电话号码当然属于对个人数据的处理，也就是processing。但如果这些记录只是零散地写在纸上，也没有被纳入或计划纳入按照特定标准组织的存档系统，那么就不满足GDPR的适用条件。但还是要提醒的是，所谓的自动化、半自动化手段是一个非常低的标准，比如电子文档的复制粘贴这么简单的动作就已经构成通过自动化手段进行的个人数据处理。所以，不能仅仅因为数据产生、记录和存储在设备内部，就说这里没有发生个人数据处理。

但反过来说，2）存在个人数据处理，也不意味着GDPR就必然适用。例如，Art.2(2)(c)明确排除的自然人在纯粹个人或家庭活动中开展的处理，就是本话题的一个重要变量。除此之外，还需要考虑Article 3规定的地域适用范围（也不展开了）。

再往下，3）即使某项处理活动受到GDPR约束，也仍然需要识别相关主体的法律角色才能锚定GDPR合规义务。关于这一点我把它放到第二层去展开讨论。

最后，即使认定制造商构成controller，也不意味着它必须以与云服务运营商完全相同的方式履行GDPR义务。更直白一点，我认为4）即使把纯本地设备制造商认定为controller，也不会因此给它增加特别沉重的GDPR合规负担。例如，我们可以设想一款完全本地运行的健康监测设备。基于设备制造商已经构成controller的前提，它如何履行GDPR的义务呢？我举几个例子：

• 数据跨境：数据都不在制造商手上就不存在跨境的现实条件，义务不存在。

• 数据主体行权响应： 制造商自己不掌握终端设备处理的数据无法直接响应行权请求，但制造商可以通过在设备端预先设计数据查看、更正和删除功能，以及远程指导用户操作的方式履行义务。

• 数据泄露报告：报告的前提是知悉，但制造商很难隔空洞察。如果制造商被数据主体（消费者）告知设备遗失可能产生数据泄露，它才需要去考虑数据泄露的报告义务。但如果硬件本身具备足够高的安保性，那么制造商也有机会去argue不会产生风险。

我之所以先区分这些概念，是因为“本地处理是否属于processing”“制造商是否属于controller”“制造商具体需要履行哪些义务”，其实是三个不同的问题。如果一开始就把它们混在一起，很容易把一些极端情况想象成反对制造商controller身份的理由，比如U盘厂商难道是controller?摄像机厂商难道是controller?

第二层：制造商就一定受到GDPR管辖吗？

此处我觉得需要再咂摸一下recital 18的说法：但对于为上述个人或家庭活动提供个人数据处理工具的控制者或处理者，本条例仍然适用。它说的是为家庭活动提供处理工具的controller或者processor仍然受GDPR约束，但它没有说，所有为家庭活动提供处理工具的制造商都必须是controller或者processor。这是不是暗示着，本地处理场景下，制造商的法律身份判定实际是三分法：C、P，或者单纯的工具人？

关于何种情况构成controller我放在第三层分析。此处我列一下我在三分法下的其他两点疑问：

1. 如果制造者是processor，那谁是controller?消费者吗？所以大逻辑是“消费者虽然是Controller但根据家庭事务例外条款不受 GDPR 约束”？

2. 制造商真的在代表消费者处理数据吗？制造商既不知道消费者何时开始处理数据，也不能访问或介入数据处理，那么它到底接受了消费者什么指示呢？行为表指示？又是如何与数量众多、身份未知的消费者签署委托处理协议呢？购买合同内嵌入DPA？

这个问题怎么想怎么觉得别扭，所以我自己更喜欢二分法：要么C，要么工具人。但在这个点上我仍然有很多问题没想通，所以强行跳过他。

第三层：制造商在何种情况下构成纯本地处理活动的Controller？

关于如何判定controller，答案永远是“谁决定处理目的和处理方式”。而关于什么叫决定处理目的和处理方式，我之前在小思考 | 数据控制者和处理者，到底怎么分？也是写了十万个为什么...

直接讨论智能硬件场景的话，我认为不能低估制造商在产品设计阶段对处理目的和方式作出的决定。

先看处理目的。举个例子，消费者购买一款智能健康设备，可能只是为了了解自己的身体状况。但设备具体通过哪些个人数据来评价健康状况、要识别什么异常、给出什么分析结果，往往已经由制造商设计好了。制造商可以决定，这款设备不仅要测量心率，还要持续分析心率变化并识别异常趋势；或者，它不仅记录运动轨迹，还要根据轨迹和运动表现评价用户的运动状态。

如果出现这样的设计，我倾向于此时制造商已经构成controller了。因为制造商实际上已经预先规定了数据将被用于什么分析、实现什么目标。消费者购买设备的总体动机，与设备内部每一项数据处理所要实现的具体用途，并不完全是一回事。

再看处理方式。EDPB《GDPR下数据控制者及数据处理者概念的指南》（Guidelines 07/2020）区分了essential means和non-essential means。其中，处理哪些个人数据、处理期限、数据主体类别以及接收者类别等，都可能属于应由controller决定的核心处理方式。而在智能硬件的场景下，制造商往往已经决定了设备需要采集哪些个人数据、何时采集、保存哪些分析结果以及保存多久。但如果一款设备预先规定，必须持续采集某些数据，并按照固定规则和流程去做数据加工、分析等等，消费者又无法实质改变这些安排，那么制造商已经不只是决定设备功能，而是实质性决定了“设备将如何处理个人数据”。

我举个例子，汽车事件数据记录器（Event Data Recorder，EDR）固定安装在车辆内，持续记录各种车辆参数；一旦发生事故，系统就会保存事故发生前一段时间内的记录，否则便会丢弃这些记录。与普通存储设备不同，EDR作为预装在车辆中的记录装置，用户无法决定记录哪些数据，而是设备按照制造商预设的规则自动记录。这是即使EDR制造商无法访问数据，也构成controller。（这个例子来自瑞士律所Schellenberg Wittmer的合伙人Roland Mathys在2019年发表的《从不同参与者的视角看物联网数据保护》（Datenschutz aus Sicht verschiedener Akteure beim Internet der Dinge）脚注7，我觉得很生动）https://www.swlegal.com/media/filer_public/c5/4b/c54b2d19-9def-4613-b837-504658697cd2/datenschutz_aus_sicht_verschiedener_akteure_beim_iot.pdf

接下来还有一个问题：消费者购买和启用产品，是否意味着消费者才是作出数据处理决定的人？

我觉得不能直接画等号。在许多智能设备中，消费者能够作出的决定其实非常有限：要么接受制造商已经设计好的处理规则，要么停止使用某项功能，甚至停止使用整个产品。我认为，这种购买或使用上的选择权，不应当被直接等同于对数据处理目的和方式的决定权。即使用户能够启用/关闭功能，也不能因此直接否认制造商对该功能启用之后的数据处理规则所作的决定。消费者决定是否使用产品，与制造商决定产品内部如何处理个人数据，可以同时存在。前者并不必然排除后者。

当然我承认这里仍然存在解释空间，需要个案评估。不能仅仅因为制造商设计了某项功能，就当然认为它决定了GDPR意义上的处理目的。 否则，所有软件和硬件制造商和controller之间就变成绝对等号关系，这显然不是一个合理的结论。关键还是要区分：制造商究竟只是为用户提供了一种处理数据的能力，还是已经通过产品设计，对具体个人数据的处理目的和核心方式作出了实质性的决定。

比如，我们可以比较普通相机和安装在屋顶上的监控摄像头。

普通相机当然也有预设的拍摄、记录和存储功能，但制造商并没有决定用户究竟要拍摄什么、为什么拍摄，以及拍摄之后如何使用照片。消费者可以用它拍景拍人拍昆虫，拍任何可能涉及自然人也可能不涉及的画面。在这种情况下，我觉得很难仅仅因为制造商设计了影像记录功能，就认定它决定了个人数据处理的目的和方式。

但如果是一套专门用于住宅安全监控的摄像头系统，情况可能就有所不同。因为制造商会预先设计设备必须持续识别摄像范围内（射程多远也是制造商决定的）的人员、记录其出现时间、也许还会提取特定行为特征并按照固定规则保存分析结果，而消费者实质不能改变这些处理规则。那么，制造商就不仅仅是在提供一种可以拍摄影像的能力，而是已经预先规定了设备要针对哪些个人数据开展什么处理，以及这些处理所要实现的具体目的。

当然，在安保摄像头场景下，是消费者决定是否安装摄像头、安装在哪里、监控什么区域以及为了什么目的使用。但消费者对设备使用场景的决定，并不必然排除制造商对设备内部特定数据处理目的和核心方式的决定。 两者完全有可能同时存在（甚至构成共同处理）。

第三层：为什么不能把“制造商是否真实参与数据处理活动”作为责任边界？

“纯硬件制造商不参与、不控制、不影响实际的数据处理”是为“硬件制造商构成controller”喊冤的一个重要依据。我的反驳理由如下：

首先，EDPB《GDPR下数据控制者及数据处理者概念的指南》其实已经说得很明确：controller并不需要实际访问正在处理的个人数据。这说明实际接触数据不是认定controller身份的必要条件。

其次，我认为，制造商不接触数据的现象会随着技术发展变得越来越普遍。今天我们讨论的可能还是普通的运动手环、健康监测设备或者车载传感器。但随着设备终端能力的发展，设备完全可以在本地完成越来越复杂的数据采集、分析和决策。一款AI Agent持续观察用户行为、记录用户偏好、分析大量个人信息，并在设备内部自主完成一系列操作，而所有数据都不需要上传到Agent provider的服务器上。在这种情况下，我们还能仅仅因为制造商没有接触数据，就认为制造商与这些处理活动完全没有法律关系吗？我觉得很难接受这种解释。因为这意味着，制造商完全可以预先设计一套对个人隐私侵入性非常高的数据处理规则，让设备持续采集用户的声音、位置、行为习惯，甚至推断用户的健康状况、情绪状态和亲密关系。高侵入性带来的用户高粘性可以让制造商从中获益。但同时它又因为数据没有回传，就不承担这些处理的必要性、合理性和安全性义务。更可怕的是，消费者可能根本不知道设备究竟在分析自己什么，也没有能力改变这些规则。 如果这条路径成立，设备终端能力越来越强大，GDPR的监管边界反而可能越来越窄，这感觉不合常理。

再者，我认为本地处理可能是数据最小化和隐私保护的一种实现方式，但它不是排除 GDPR 责任的依据。 设想：一款设备的全部数据处理规则都由制造商预先设定，但是否将数据同步至云端，由消费者通过一个开关决定，制造商无论如何都没办法突破这个技术边界。在消费者不打开开关的情况下，设备就是一款纯终端硬件产品。如果按照“制造商能否接触数据”的判断标准，是不是意味着消费者打开开关时，制造商才可能是controller；关闭开关后，制造商又不再是controller？但无法自洽的是：开关的状态并不必然改变设备内部原有的数据采集和分析规则，也不必然改变制造商对这些规则已经作出的决定。发生变化的只是数据是否向外传输，而不是制造商对终端内部处理活动的决定权。如果仅凭开关状态就改变制造商对同一项本地处理活动的法律身份，实际上是把数据访问能力误当成了controller的认定标准。

所以，制造商能不能取得数据，与制造商是否决定了数据处理的目的和方式，是两个需要分别判断的问题。前者不能直接代替后者。

第四层：如果制造商不属于 controller，现有法律能够填补保护缺口吗？

前面讨论的是法律解释。下面我想再从实际后果的角度考虑一下。

假设某个制造商设计了一款设备，要求持续收集大量个人数据。其中一些数据与设备的核心功能没有明显关系，消费者也无法选择关闭相关采集。所有数据都保存在本地，因此制造商无法访问这些数据。

如果凭这一点就将制造商完全排除在controller身份之外，会发生什么？消费者可能既无法改变设备的数据采集规则，也无法要求制造商解释这些数据采集是否必要、是否符合目的限制原则。而大量个人数据在同一个物理设备上持续积累，本身也存在风险。

当然，欧盟现在并不是完全没有针对这些设备的法律，比如近期讨论度很高的Data Act和CRA，前者管数据后者管安全。它们看起来最有可能填补纯本地处理场景中的保护缺口。

但是，Data Act关注的是联网产品及相关服务产生的数据如何被用户访问、使用和共享，要求制造商在设计产品时考虑让用户能够方便、安全地获取相关数据，但不要求他们考虑为什么处理这些个人数据、处理多少以及处理多久才是合理的。

而CRA主要针对带有数字元素的产品提出网络安全要求，例如安全设计、漏洞管理以及产品生命周期内的安全维护。这些规定当然能够减少设备遭受攻击、数据被非法获取等风险。但它管不了安全边界类数据处理的量级和必要性。

所以说还得是GDPR！我不是主张为了填补空白而强行认定制造商是controller，而是说，当制造商预先作出的设计决定究竟属于普通产品设计，还是对个人数据处理目的和核心方式的决定，本身就存在解释空间时，隐私保护的法益应当被优先保障，这至少构成了支持“属于论”的理由。

在本文起草过程中，我读到了这三篇文章都非常好，强烈推荐：

1. 中立派：Who is responsible for data processingin smart homes? Reconsidering jointcontrollership and the householdexemption（https://academic.oup.com/idpl/article/10/4/279/5900395）

2. 属于派：Device Manufacturers as Controllers: Expanding the Concept of ‘Controllership’ in the GDPR（https://www.sciencedirect.com/science/article/pii/S0267364922001054）

3. 不属于派：Personal data controllers and device producers: Mind the gap（https://www.sciencedirect.com/science/article/pii/S2212473X25000458）

总结一下，这道题的正确答案犹未可知，但这个问题一定会随着AI端侧处理能力的强大而愈发显眼。也是因为如此，我才趁着立法者/监管机构没有明确表态之前斗胆分享我的想法。

这个想法并不周延，逻辑链路上还有不少我没有迈过去的小疙瘩，甚至有些“先射箭、再画靶”的嫌疑，而且对于我的客户而言并不是一个他们爱听的观点。总之就抛砖引玉与大家探讨吧，也欢迎批评指正。

最后，感谢所有与我讨论此题的客户！

作者｜肖莆羚令

• 法规解析：

• GDPR：

• GDPR之外：