嵌入式AI隐私为何泄露？密钥怎么管？

把推理放到本地，并不自动等于隐私安全；很多泄露发生在日志、特征和升级包边界。嵌入式AI如果只保护原始数据，不保护模型和中间结果，攻击面仍然很宽。

隐私泄露的第一条路径，是中间特征被当成无害数据。摄像头原图也许不会上传，但人脸 embedding、声纹向量、缺陷特征和低置信样本截图仍可能带有可识别信息；调试日志里保存的输入裁剪、分类分数和时间地点，也足够还原用户行为。若设备在异常时自动打包现场数据，工程上很方便，合规上却可能绕过了采集授权和保留期限。

因此，端侧推理也要把数据分级。原始输入、中间特征、模型输出和诊断日志应分别规定存储位置、保留时间、脱敏方式和上传条件。嵌入式AI设备若必须回传样本用于改进模型，最好在端侧先裁剪、模糊或提取不可逆摘要，并用事件触发限制采集频率。否则本地推理只减少了持续上传，并没有消除敏感数据在设备内被读取的风险。

密钥管理则决定模型和数据保护是否真的落地。把加密模型和解密密钥同时放在普通文件系统里，攻击者拿到固件包或调试口后就能离线还原；用同一把全局密钥烧进所有设备，也会让单台设备泄露演变成整批失守。更可靠的做法，是在安全产线或可信执行环境里注入设备唯一密钥，模型包用设备或批次级密钥派生解密，密钥本体不出安全存储区。

安全启动和反回滚也必须配套。若启动链不验证固件和模型签名，攻击者可以刷入旧版本运行时，绕过后续加密或访问控制；若允许降级到存在漏洞的模型加载器，密钥再安全也会被旧逻辑误用。模型文件、配置阈值和运行时库应共同参与签名校验，版本号单调递增，回滚只允许回到仍受信任的上一个槽位，而不是任意旧包。

生产测试流程同样会留下风险。为了校准和验收临时开放的导出命令、明文样本目录或通用调试证书，如果没有在出厂前撤销，就会成为现场最容易被利用的入口。密钥注入应有可审计的批次记录，测试密钥和量产密钥必须隔离；维修模式也应只允许受限诊断，不能顺手读取完整模型和样本缓存。

量产后还要关闭不必要的调试面。串口 shell、JTAG、ADB、离线日志导出和工厂测试命令，都可能绕过应用层权限直接读到缓存或模型。安全测试应覆盖断网、异常重启、升级失败和维修模式，确认这些状态下密钥不会被打印，缓存不会被明文落盘，样本不会被无授权导出。若设备支持远程诊断，诊断令牌也要有短有效期和最小权限，访问记录还应写入不可随意删除的审计日志，避免成为长期后门；密钥轮换要能兼容离线设备，并保证轮换失败不破坏旧包验证。退役设备还要擦除密钥和本地样本索引，防止二次流通泄露。

所以，本地推理只是隐私保护的起点。把特征、日志、模型和密钥都纳入同一条信任链，嵌入式AI才不会在边缘设备上留下新的泄露口。