AI陪伴机器人的隐私与合规-健康情绪数据的处理原则

14-陪伴机器人的隐私与合规-健康情绪数据的处理原则

这个系列写到最后一篇，咱们聊点"看不见但最要命"的东西：隐私与合规。

AI 伙伴（AI-Partner）是台陪伴机器人，天天陪老人聊天、记你情绪、量你心率、看你是否跌倒。它掌握的数据，比大多数 App 都更私密——身份、健康、情绪、对话，甚至家里的影像。这些数据处理不好，就不是"产品体验差"，而是"出事"。

本篇不讲虚的，给你一套可直接落地的合规清单，逐条对应到 AI 伙伴（AI-Partner）的真实实现现状。

一、先给数据分个类分级

合规第一步：你得先知道自己在处理什么级别的数据。AI 伙伴（AI-Partner）涉及的数据大致分五类，敏感程度递增：

为什么要分级？因为级别决定处理方式：健康与影像这类高敏感数据，必须端侧优先、最小化上报、强授权；身份类里的手机号，不能随便展示、不能默认收集。

注意一个现实：AI 伙伴（AI-Partner）当前对话表 t_conversation 存的是原文（user_message/assistant_message 为 TEXT），情绪表存的是自由文本 context——这些都可能无意中记下用户的隐私。分级之后，你才能决定哪些字段要加密、哪些要脱敏、哪些干脆不存。

二、最小必要采集：能不收就不收

"最小必要"是个人信息保护的头号原则：只收集实现功能必需的数据，不收集多余的。

对照 AI 伙伴（AI-Partner）现状：

一个常见反例：为了"个性化推荐"偷偷收集位置、通讯录——这既非最小必要，也缺授权，是大忌。AI 伙伴（AI-Partner）目前不收集通讯录、不强制位置，方向是对的；但 t_user.phone 默认允许空，实现上没强制要，这点保持住。

三、授权与告知：把"同意"放在采集之前

合规不是"偷偷做了再写个隐私政策"，而是先告知、后授权、可撤回。

落到产品上，至少要有三件事：

1. 隐私政策告知：用户首次使用时，清楚说明收集什么、为什么、存多久、给谁看。
2. 分项授权：健康数据、紧急联系人、摄像头权限，要分项单独同意，不能"一个勾选全授权"。
3. 可撤回：用户能随时关掉某类采集、能删除自己的数据（见第五节）。

现状对照：AI 伙伴（AI-Partner）的 t_user 有 status（1 正常 / 0 禁用），可作为"账号级停用"的开关；但没有细到"按数据类型撤回授权"的字段或接口。长期记忆 t_memory 的 active 字段是"软删"开关（见系列一），情绪、健康记录目前没有对应的用户自助删除入口。这是要补的。

特别提一句人设里的硬边界，和合规完全同频：

// 项目源码：agent/persona/PersonaProvider.java（PERSONA_RULES 节选）
你不可以：编造用户未提供的信息、冒充真人、承诺无法兑现的功能。
当用户有紧急健康风险（如跌倒、剧烈胸痛、严重呼吸困难）时，
明确建议立即联系家人/急救，并使用工具记录告警。

“不编造、不冒充真人、不承诺无法实现的功能”——这三条本质上也是合规要求：别误导用户以为机器人是医生、是真人、能包办一切。

四、端侧优先：图像不出设备，是合规的护城河

这是 AI 伙伴（AI-Partner）在视觉链路上的一个正确设计，值得单独表扬。

回顾第 12 篇：摄像头在 RK3566 端侧跑 YOLO11-pose，判定跌倒后，通过 MQTT 上报的是结构化事件：

// 上行 JSON（项目调研报告摘录）
{ "event": "fall", "userId": 1, "confidence": 0.92 }

注意：上报的是"跌倒 + 置信度"，不是一帧画面、不是一段视频。原始影像留在设备上，云端只拿到提炼后的关键点结果和判定结论。

这种"端侧推理、只传结构化结果"的架构，对合规价值巨大：

• 影像不出设备 → 不涉及大规模生物识别图像存储 → 大幅降低泄露与滥用风险；
• 云端拿不到人脸原图 → 即使后端被攻破，也拿不到能识别个人的画面；
• 符合"最小必要"：为了判跌倒，确实不需要把高清视频传上云。

代价是端侧算力要求（RK3566 的 6 TOPS NPU 就是这个用处），以及端侧关键点解析要准确（第 12 篇提到的 reshape(-1,3) 错位风险要修）。但方向上，这是陪伴机器人该走的路——让最敏感的数据，死在离用户最近的地方。

五、数据留存与删除：软删是真删的前奏

数据不是"存了就永远在"。合规要求：到期限、用户撤回、账号注销，都要能删。

AI 伙伴（AI-Partner）里已经有一套"软删"机制，值得讲清：

• t_memory 的 remove：不是物理删除，而是 setActive(false)（软删）+ 重建画像摘要。
• t_user 的 status：0 表示禁用，也算一种"停用"态。

软删的好处是不会让关联数据瞬间悬空、便于审计；但软删不等于合规意义上的删除。当用户依法要求"删除我的所有数据"时，最终必须做真删除（物理 DELETE 或匿名化）。

建议的留存/删除策略表：

一个关键点：删除要"级联"。删用户时，其记忆、对话、健康、情绪、告警要一并处理，否则留一地孤儿数据。当前 t_alert.user_id 允许 NULL、各表无外键，级联删除得靠代码显式实现，不能指望数据库。

六、日志与审计：谁能看、做了什么

合规还要"可追溯"：谁在什么时候查了某个老人的健康数据、触发了什么通知，要有记录。

AI 伙伴（AI-Partner）现状：

• 建告警工单时 log.warn("新告警工单 #{} ...")，留了操作日志；
• 但没有"数据访问审计日志"——比如家属 App 拉取老人健康趋势，目前不会单独记"谁、何时、查了谁"。

对高敏感数据，建议加一张轻量审计表（或写入现有日志系统）：谁 + 动作 + 对象 + 时间 + 结果。这既是合规要求，也是出事时自证清白的证据。

另外提醒：日志本身也可能泄密。如果 log.warn 把手机号、健康数值、对话原文打进应用日志，而这些日志又被集中收集、权限宽松，反而制造新风险。日志里该脱敏的（手机号中间四位、完整对话正文）要打码。

给个具体做法：告警日志只记"工单号 + 用户脱敏 ID + 类型 + 级别"，绝不记原始数值和联系方式；对话审计日志只记"谁查了谁的健康趋势（时间+类型）“，不把趋势内容本身写进审计表——内容留在业务表里，审计表只留"动作指纹”。这样即便审计库被拖库，攻击者拿到的也只是"某人某时查了某类数据"的行为记录，拿不到具体健康数值，危害等级直接降一档。

七、免责与医疗建议边界

陪伴机器人不是医疗器械，这一点要在产品和合规层面写死：

• 不诊断：心率 145、血压 190/120 这类异常，系统只"提醒注意、建告警工单"，绝不出"您得了某某病"的结论。
• 不替代就医：任何健康处置以专业医生和急救机构意见为准。
• 明确引导：人设回复要求第 5 条原文就是——“涉及医疗、用药、法律等专业问题，明确提示请以专业人士意见为准，你只做善意提醒。”

对应到告警：第 11 篇提到的 TYPE_DEVICE_FAULT 把健康异常"借用"了设备故障类型，从合规表达上也不够清晰——健康异常应该有自己独立的类型与告知话术，让人一眼看出"这是健康提醒，不是设备坏了"。这也是前面埋的改进点之一。

八、可直接执行的合规清单表

最后，把上面八节压成一张"照着打勾"的清单，给做二次开发或接产线的朋友：

九、健康/紧急场景合规提醒（必读）

• 本文所有合规建议，均以"保护用户权益、遵循最小必要与授权原则"为底色；是否就医、如何处置健康问题，一律以专业医生和急救机构意见为准。
• AI 伙伴（AI-Partner）的健康与跌倒能力仅做善意提醒与记录留痕，不构成医疗诊断或急救服务。
• 涉及紧急健康风险，请立即联系家人或拨打急救电话，勿依赖设备自动响应。

十、小结

隐私与合规不是上线前的"补丁"，而是架构一开始就该长进骨头里的东西。AI 伙伴（AI-Partner）有两个做对的地方值得肯定：端侧优先（影像不出设备）和人设里的"不冒充、不编造、不承诺"边界；也有明确的待办：细粒度授权、留存期限、真删除级联、访问审计。

把上面那张 12 条清单逐条打勾，这台陪伴机器人才算真正"靠谱"——既陪得了你，也守得住你。