📚 课程目录第4章数据保护

4、数据保护：隐私合规、GDPR与ETSI交叉点、用户数据最小化

数据保护这个话题，说实话，在智能家居领域里是最容易踩坑的地方。我这些年参与过的合规项目，十有八九最后卡在数据隐私上。不是设备功能做不出来，而是数据怎么收集、怎么存、怎么删，这些事没想清楚。

ETSI EN 303 645 里关于数据保护的要求，其实和 GDPR 有很多交叉点。但 ETSI 更落地，它告诉你具体怎么做，而不是只给原则。今天我们就把它拆开来看。

4.1 隐私合规的核心矛盾

智能家居设备天生就要收集数据。温度传感器要读室温，摄像头要传画面，门锁要记录开关时间。没有数据，智能就无从谈起。

但问题来了——用户真的需要你收集这么多数据吗？

我见过一个智能灯泡的项目，厂商在固件里埋了点代码，每次开关灯都上报精确到秒的时间戳，还附带 Wi-Fi 信号强度。为什么要这些？厂商说「为了分析用户习惯」。但用户只是想远程关个灯而已。

这就是核心矛盾：功能必需数据 vs 商业欲望数据。

ETSI 的立场很明确：只收集设备运行所必需的数据。其他的一律不要碰。

4.2 GDPR 与 ETSI 的交叉点

GDPR 是欧洲的通用数据保护条例，它管的是所有处理欧盟公民个人数据的组织。ETSI EN 303 645 是物联网设备的安全标准。两者不是替代关系，而是互补关系。

我习惯把它们的关系画成一张表，这样看得清楚：

维度	GDPR 要求	ETSI 303 645 要求	交叉点
数据最小化	只收集必要数据	Provision 5.7-1: 最小化遥测数据	完全一致
用户同意	明确、知情、可撤回	Provision 5.7-3: 提供数据收集开关	ETSI 给出了实现方式
数据删除	被遗忘权	Provision 5.7-4: 提供删除机制	ETSI 要求接口可操作
透明度	告知数据处理方式	Provision 5.7-2: 披露数据用途	ETSI 要求在产品端展示
数据泄露通知	72小时内通知监管	Provision 5.8-1: 事件日志	ETSI 要求本地日志

你看，ETSI 其实是在帮厂商落地 GDPR。GDPR 说「你要数据最小化」，ETSI 说「好，那你的遥测数据只发必要字段」。GDPR 说「用户要有删除权」，ETSI 说「那你的设备上就得有个恢复出厂设置按钮」。

我的建议：做智能家居产品时，直接把 ETSI 的 Provision 5.7 当成 GDPR 合规的检查清单来用。一条一条过，基本不会漏。

4.3 用户数据最小化——具体怎么做

数据最小化这个词听起来很抽象，但落到代码和产品设计上，其实就几条硬规则。

4.3.1 区分数据类别

我一般把智能家居数据分成三类：

功能数据：设备运行必须的。比如温控器的当前温度、门锁的开闭状态。不收集，设备没法工作。
遥测数据：用于诊断和优化的。比如设备固件版本、信号强度、错误码。可以收集，但要最小化。
行为数据：用户使用习惯。比如几点开灯、离家模式触发频率。这类数据，能不收就不收。

ETSI 允许收集前两类，但对第三类非常谨慎。Provision 5.7-1 明确说：遥测数据必须限制在「设备维护、安全分析、功能改进」范围内。

4.3.2 设计数据最小化的接口

举个例子。一个智能插座，它上报的数据包可能长这样：

// ❌ 不好的做法：上报太多信息
{
  "device_id": "sock-001",
  "timestamp": "2025-03-21T10:30:00Z",
  "power_w": 120,
  "voltage_v": 220,
  "current_a": 0.55,
  "wifi_ssid": "HomeWiFi",
  "wifi_rssi": -45,
  "firmware_ver": "2.1.3",
  "uptime_s": 86400,
  "timezone": "Asia/Shanghai",
  "user_language": "zh-CN"
}

这里面有多少是真正必要的？

power_w 是功能数据，用户要看功耗，必须上报。
wifi_rssi 是遥测数据，用于诊断信号问题，可以接受。
wifi_ssid 呢？厂商想知道用户用的什么路由器。但这属于过度收集。
timezone 和 user_language 呢？完全可以从 App 端获取，不需要设备上报。

按 ETSI 最小化原则，应该改成这样：

// ✅ 好的做法：只上报必要字段
{
  "device_id": "sock-001",
  "timestamp": "2025-03-21T10:30:00Z",
  "power_w": 120,
  "wifi_rssi": -45,
  "firmware_ver": "2.1.3"
}

我曾经踩过的坑：有个项目，我们在设备固件里默认上报了 MAC 地址。后来做 GDPR 合规审查时才发现，MAC 地址在欧洲被视为个人数据。改固件、发 OTA、更新隐私政策，折腾了两个月。从那以后，我要求所有设备上报字段必须经过数据保护官（DPO）审批。

4.4 数据保护的核心流程

下面这张图是我自己总结的数据保护流程，每次做新项目我都会拿出来对照一遍。

4.5 用户同意的设计细节

ETSI Provision 5.7-3 要求设备提供「数据收集的开关」。这个开关怎么设计，其实很有讲究。

我见过一些厂商的做法：在 App 设置里藏一个「允许数据收集」的开关，默认是开的。用户根本找不到。这不符合 ETSI 的精神。

正确的做法是：

首次启动时弹窗说明：告诉用户要收集哪些数据，用来做什么。
提供明确的同意/拒绝选项：拒绝后设备不能降级功能（除非数据是功能必需的）。
开关要容易找到：最好在设备详情页的第一屏就能看到。
用户可以随时关闭：关闭后，已收集的数据应该删除或匿名化。

一个小技巧：把数据收集开关和「帮助改进产品」绑定在一起。用户如果愿意帮忙，就打开；不愿意，也不影响使用。我在一个智能音箱项目里这么做了之后，用户主动开启率反而从 30% 升到了 65%。

4.6 数据删除——不只是恢复出厂设置

ETSI Provision 5.7-4 要求设备提供删除用户数据的机制。很多人以为「恢复出厂设置」就够了。其实不够。

你想想看，用户数据可能分布在三个地方：

设备本地：Flash、EEPROM 里的配置和日志。
云端：厂商服务器上的历史数据。
App 本地：手机上的缓存。

恢复出厂设置只能清掉设备本地。云端和 App 端的数据，需要另外的机制。

我建议的做法是：

// 数据删除接口设计示例
DELETE /api/v1/user/{user_id}/data

// 返回
{
  "status": "deleted",
  "affected_devices": 5,
  "cloud_data_cleared": true,
  "device_reset_triggered": true,
  "app_cache_invalidation": true
}

这个接口要同时触发：云端数据删除、设备远程重置、App 缓存失效通知。三个地方都清了，才算真正完成。

注意：有些厂商为了省事，只在云端标记数据为「已删除」，实际上还留着。这在 GDPR 下是违规的。真正的删除必须是不可逆的。

4.7 透明度——把话说清楚

ETSI Provision 5.7-2 要求厂商披露数据用途。说白了，就是你要告诉用户：我收集这个数据到底用来干嘛。

我见过最差的隐私政策是那种几千字的法律文本，用户根本不会看。好的做法是：

在产品包装上印一个简版：比如「本设备收集温度数据用于自动调节，不上传云端」。
在 App 里用图标+一句话说明：每个数据字段旁边标一个「为什么需要这个」的图标。
提供分层披露：第一层是摘要，第二层是详细说明，第三层才是完整的法律文本。

嗯，这里要注意：透明度不是让你把所有技术细节都写出来，而是让普通用户能看懂。我见过一个厂商在隐私政策里写「本设备使用 AES-256-GCM 加密传输数据」，用户看了只会更困惑。改成「你的数据在传输过程中会被加密保护，别人看不到」，反而更有效。

数据保护这件事，说到底就是尊重用户。你尊重用户的数据，用户才会信任你的产品。ETSI 给了我们一套很清晰的框架，照着做，不会错。