14-陪伴机器人的隐私与合规-健康情绪数据的处理原则这个系列写到最后一篇咱们聊点看不见但最要命的东西隐私与合规。AI 伙伴AI-Partner是台陪伴机器人天天陪老人聊天、记你情绪、量你心率、看你是否跌倒。它掌握的数据比大多数 App 都更私密——身份、健康、情绪、对话甚至家里的影像。这些数据处理不好就不是产品体验差而是出事。本篇不讲虚的给你一套可直接落地的合规清单逐条对应到 AI 伙伴AI-Partner的真实实现现状。一、先给数据分个类分级合规第一步你得先知道自己在处理什么级别的数据。AI 伙伴AI-Partner涉及的数据大致分五类敏感程度递增类别例子落库位置敏感级别身份数据昵称、openId、手机号、生日、家庭角色t_user中手机号属敏感个人信息健康数据心率、血压、步数、睡眠、跌倒记录t_health_record高健康是敏感个人信息情绪数据情绪类型、强度、上下文、对话回应t_emotion_record中高可反推心理状态对话数据用户说了啥、机器人回了啥t_conversation中高含大量自由文本位置/影像设备位置、摄像头画面、姿态关键点端侧为主高影像最敏感为什么要分级因为级别决定处理方式健康与影像这类高敏感数据必须端侧优先、最小化上报、强授权身份类里的手机号不能随便展示、不能默认收集。注意一个现实AI 伙伴AI-Partner当前对话表t_conversation存的是原文user_message/assistant_message为 TEXT情绪表存的是自由文本context——这些都可能无意中记下用户的隐私。分级之后你才能决定哪些字段要加密、哪些要脱敏、哪些干脆不存。二、最小必要采集能不收就不收最小必要是个人信息保护的头号原则只收集实现功能必需的数据不收集多余的。对照 AI 伙伴AI-Partner现状字段是否必要备注t_user.phone看场景只有要做紧急联系/账号找回才需要平时可不强制t_user.birthday弱必要用于年龄化语气可选项别强制t_health_record.value必要健康守护核心但单位/数值要规范t_emotion_record.context谨慎自由文本可能记隐私建议限长可关摄像头原始画面不必要上云见第四节端侧优先一个常见反例为了个性化推荐偷偷收集位置、通讯录——这既非最小必要也缺授权是大忌。AI 伙伴AI-Partner目前不收集通讯录、不强制位置方向是对的但t_user.phone默认允许空实现上没强制要这点保持住。三、授权与告知把同意放在采集之前合规不是偷偷做了再写个隐私政策而是先告知、后授权、可撤回。落到产品上至少要有三件事隐私政策告知用户首次使用时清楚说明收集什么、为什么、存多久、给谁看。分项授权健康数据、紧急联系人、摄像头权限要分项单独同意不能一个勾选全授权。可撤回用户能随时关掉某类采集、能删除自己的数据见第五节。现状对照AI 伙伴AI-Partner的t_user有status1 正常 / 0 禁用可作为账号级停用的开关但没有细到按数据类型撤回授权的字段或接口。长期记忆t_memory的active字段是软删开关见系列一情绪、健康记录目前没有对应的用户自助删除入口。这是要补的。特别提一句人设里的硬边界和合规完全同频// 项目源码agent/persona/PersonaProvider.javaPERSONA_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的status0表示禁用也算一种停用态。软删的好处是不会让关联数据瞬间悬空、便于审计但软删不等于合规意义上的删除。当用户依法要求删除我的所有数据时最终必须做真删除物理DELETE或匿名化。建议的留存/删除策略表数据类型默认留存到期动作用户撤回对话原文t_conversation设上限如 180 天滚动清理或匿名化支持整户删除健康记录t_health_record较长健康趋势有价值超期归档/脱敏支持删除本人记录情绪记录t_emotion_record中清理支持删除告警工单t_alert较长安全留痕脱敏留存关联用户删除时联动端侧影像不留存不入云天然不出设备一个关键点删除要级联。删用户时其记忆、对话、健康、情绪、告警要一并处理否则留一地孤儿数据。当前t_alert.user_id允许 NULL、各表无外键级联删除得靠代码显式实现不能指望数据库。六、日志与审计谁能看、做了什么合规还要可追溯谁在什么时候查了某个老人的健康数据、触发了什么通知要有记录。AI 伙伴AI-Partner现状建告警工单时log.warn(新告警工单 #{} ...)留了操作日志但没有数据访问审计日志——比如家属 App 拉取老人健康趋势目前不会单独记谁、何时、查了谁。对高敏感数据建议加一张轻量审计表或写入现有日志系统谁 动作 对象 时间 结果。这既是合规要求也是出事时自证清白的证据。另外提醒日志本身也可能泄密。如果log.warn把手机号、健康数值、对话原文打进应用日志而这些日志又被集中收集、权限宽松反而制造新风险。日志里该脱敏的手机号中间四位、完整对话正文要打码。给个具体做法告警日志只记工单号 用户脱敏 ID 类型 级别绝不记原始数值和联系方式对话审计日志只记谁查了谁的健康趋势时间类型“不把趋势内容本身写进审计表——内容留在业务表里审计表只留动作指纹”。这样即便审计库被拖库攻击者拿到的也只是某人某时查了某类数据的行为记录拿不到具体健康数值危害等级直接降一档。七、免责与医疗建议边界陪伴机器人不是医疗器械这一点要在产品和合规层面写死不诊断心率 145、血压 190/120 这类异常系统只提醒注意、建告警工单绝不出您得了某某病的结论。不替代就医任何健康处置以专业医生和急救机构意见为准。明确引导人设回复要求第 5 条原文就是——“涉及医疗、用药、法律等专业问题明确提示请以专业人士意见为准你只做善意提醒。”对应到告警第 11 篇提到的TYPE_DEVICE_FAULT把健康异常借用了设备故障类型从合规表达上也不够清晰——健康异常应该有自己独立的类型与告知话术让人一眼看出这是健康提醒不是设备坏了。这也是前面埋的改进点之一。八、可直接执行的合规清单表最后把上面八节压成一张照着打勾的清单给做二次开发或接产线的朋友#合规动作当前实现待办1数据分类分级身份/健康/情绪/对话/位置已有表但无显式分级标记加分级元数据/文档2最小必要采集不收多余字段phone 可选、不收通讯录保持勿扩张3隐私政策告知 首次弹窗未见专门实现补隐私政策与告知4分项授权健康/摄像头/紧急联系人无细粒度授权建授权表5授权可撤回仅账号级 status按数据类型撤回接口6端侧优先影像不出设备已做只传结构化事件保持并修端侧解析 bug7留存期限 到期清理无期限策略设各类 TTL8用户自助删除真删除仅记忆软删补健康/情绪/对话删除9账号注销级联删除无外键需代码级联实现级联清理10数据访问审计日志仅告警 warn 日志加审计表/脱敏日志11医疗免责话术人设已写告警话术同步明确12老人/未成年人监护同意无专门流程加监护人同意链路九、健康/紧急场景合规提醒必读本文所有合规建议均以保护用户权益、遵循最小必要与授权原则为底色是否就医、如何处置健康问题一律以专业医生和急救机构意见为准。AI 伙伴AI-Partner的健康与跌倒能力仅做善意提醒与记录留痕不构成医疗诊断或急救服务。涉及紧急健康风险请立即联系家人或拨打急救电话勿依赖设备自动响应。十、小结隐私与合规不是上线前的补丁而是架构一开始就该长进骨头里的东西。AI 伙伴AI-Partner有两个做对的地方值得肯定端侧优先影像不出设备和人设里的不冒充、不编造、不承诺边界也有明确的待办细粒度授权、留存期限、真删除级联、访问审计。把上面那张 12 条清单逐条打勾这台陪伴机器人才算真正靠谱——既陪得了你也守得住你。