远程医疗隐私保护的技术架构与业务需求的匹配

远程医疗隐私保护的技术架构与业务需求的匹配演讲人CONTENTS引言：远程医疗发展与隐私保护的必然关联远程医疗隐私保护的业务需求解析远程医疗隐私保护的技术架构分层设计技术架构与业务需求的匹配实践：场景化解决方案匹配过程中的挑战与未来展望总结：以业务需求为锚点，构建动态匹配的隐私保护体系目录远程医疗隐私保护的技术架构与业务需求的匹配01引言：远程医疗发展与隐私保护的必然关联引言：远程医疗发展与隐私保护的必然关联近年来，远程医疗从“补充选项”加速成为“医疗基础设施”。据《中国远程医疗健康行业报告》显示，2023年我国远程医疗用户规模突破3亿，年增长率达28%；尤其在新冠疫情催化下，在线问诊、远程会诊、慢病管理等场景渗透率显著提升。然而，医疗数据的敏感性（涉及患者生理、病史、基因等核心隐私）与远程医疗的“跨地域、跨机构、网络化”特性交织，使得隐私保护成为行业发展的“生命线”。我曾参与某省级远程医疗平台的建设，深刻体会到隐私保护的复杂性：一位偏远地区的患者通过平台连接三甲医院专家，其病历影像、检查报告需跨越公网传输；多家医院为联合诊疗共享患者数据，却面临“数据孤岛”与“隐私泄露”的双重矛盾；AI辅助诊断系统需海量数据训练，但原始数据直接使用可能暴露患者身份……这些场景印证了一个核心命题：远程医疗的隐私保护，绝非单纯的技术堆砌，而是技术架构与业务需求的“动态匹配”——既要以业务场景为导向设计防护策略，又需以技术能力为支撑释放业务价值。引言：远程医疗发展与隐私保护的必然关联本文将从业务需求出发，分层解析隐私保护技术架构，并通过场景化案例探讨二者匹配的实践路径，最终展望未来挑战与优化方向，为行业提供兼具理论深度与实践参考的解决方案。02远程医疗隐私保护的业务需求解析远程医疗隐私保护的业务需求解析远程医疗的业务场景复杂多元，不同场景的隐私诉求、合规要求、利益相关方诉求存在显著差异。唯有精准拆解需求，才能为技术架构设计提供“靶心”。核心业务场景及其隐私诉求远程医疗的业务场景可分为四类，每类场景的隐私痛点与核心需求各不相同：核心业务场景及其隐私诉求在线问诊：实时交互中的“轻量级”隐私保护在线问诊是远程医疗的基础场景，核心流程为“患者发起-医生接诊-处方开具”，涉及患者基本信息（姓名、身份证号）、主诉症状、病史描述、检查报告（如化验单、影像）等数据。其隐私诉求聚焦于“传输安全”与“过程可控”：患者担心公网传输中数据被窃取，医生则需确保问诊内容不被无关方获取。例如，皮肤科患者通过图文问诊上传皮损照片，需防止照片在传输中被滥用；儿科家长代为问诊时，需严格保护儿童身份信息与病情隐私。核心业务场景及其隐私诉求远程会诊：多机构协作中的“高壁垒”隐私保护远程会诊通常涉及基层医院、上级医院、第三方专家机构的多方协作，需共享患者完整的病历档案（包括既往病史、手术记录、病理切片等）。此时，隐私保护的核心矛盾是“数据共享需求”与“隐私隔离要求”。一方面，专家需全面了解患者病情以制定诊疗方案；另一方面，各医院担心患者数据被过度复制或用于非诊疗目的。例如，某县级医院通过远程会诊平台邀请北京专家会诊，需确保患者数据仅在参与会诊的医院和专家间流转，且专家无法导出原始数据用于其他研究。核心业务场景及其隐私诉求慢病管理：长期追踪中的“持续性”隐私保护慢病管理（如糖尿病、高血压）需长期监测患者生命体征（血糖、血压）、用药记录、生活方式数据，通过可穿戴设备、家用医疗设备实时上传数据。其隐私诉求在于“数据主权”与“使用透明”：患者需明确知晓数据被谁使用、用于何种目的，并有权随时撤回授权。例如，糖尿病患者通过智能血糖仪上传数据，平台若需将数据用于AI并发症预测，必须获得患者二次授权，且患者可通过APP查看数据流向记录。核心业务场景及其隐私诉求AI辅助诊断：数据训练中的“不可逆”隐私保护AI辅助诊断模型需海量医疗数据训练，若直接使用原始数据（如CT影像、病理图像），存在患者身份暴露、隐私泄露的“不可逆风险”（一旦数据泄露，无法通过“重置密码”等方式挽回）。此时，隐私保护的核心诉求是“数据可用不可见”——模型能从数据中学习诊断规律，但无法反演患者个体信息。例如，某企业训练肺结节AI检测模型，需联合10家医院共100万份CT数据，但任何一家医院都不愿提供原始影像，以免患者隐私受损。合规性需求：法规框架下的硬性约束医疗健康数据是受监管最严格的数据类型之一，远程医疗的隐私保护必须以合规为底线。我国已形成以《个人信息保护法》（PIPL）、《数据安全法》、《网络安全法》为核心，以《医疗健康数据安全管理规范》（GB/T42430-2023）、《互联网诊疗管理办法》等为补充的法规体系，对远程医疗隐私保护提出明确要求：合规性需求：法规框架下的硬性约束“知情-同意”原则的刚性执行《个人信息保护法》第十三条规定，处理敏感个人信息（如医疗健康数据）需取得个人“单独同意”。远程医疗平台在收集患者数据时，需以“显著方式、易懂语言”告知收集目的、方式、范围及存储期限，不得通过“默认勾选”、“捆绑授权”等方式获取同意。例如，某平台曾因“注册时默认勾选‘允许数据用于科研’”被监管部门处罚，最终改为“分步授权+选项勾选”模式。合规性需求：法规框架下的硬性约束数据全生命周期的合规管控《数据安全法》要求对数据实行“全生命周期管理”。远程医疗数据从采集（如患者填写问卷）、传输（如加密上传）、存储（如数据库加密）、使用（如AI模型训练）、共享（如会诊数据交换）到销毁（如过期数据删除），每个环节需建立对应的隐私保护措施。例如，存储患者病历的数据库需采用“字段级加密”，即使数据库被攻破，攻击者也无法获取明文数据。合规性需求：法规框架下的硬性约束跨境传输的严格限制医疗健康数据属于“重要数据”，跨境传输需通过安全评估。若远程医疗平台涉及境外专家参与会诊（如海外远程会诊），需确保数据境内存储，确需跨境的，需通过“数据出境安全评估”、“个人信息保护认证”等合规路径。例如，某国际远程会诊平台因未申报数据跨境传输被叫停，后通过“境内数据脱敏+境外专家临时访问权限管控”方案恢复服务。利益相关方诉求的多维平衡远程医疗涉及患者、医疗机构、医护人员、平台方、监管方等多方主体，各方的隐私诉求存在潜在冲突，需通过技术架构实现“动态平衡”：-患者：核心诉求是“隐私权优先”，希望数据仅用于诊疗目的，且自身对数据有绝对控制权（如查看、修改、删除）。但部分患者因隐私顾虑拒绝提供必要数据（如隐瞒病史），反而影响诊疗效果，需通过“隐私保护透明化”缓解焦虑。-医疗机构：既需通过数据共享提升诊疗效率（如远程会诊中调取患者既往病史），又担心数据泄露引发法律风险（如患者起诉医院侵犯隐私）。其诉求是“数据价值与安全的平衡”，例如通过“隐私计算”实现数据共享不泄露原始数据。-医护人员：作为数据直接使用者，需便捷获取患者数据以快速响应诊疗需求，但过度复杂的隐私保护措施可能增加工作负担（如多次验证身份）。其诉求是“安全与效率的兼顾”，例如通过“单点登录+角色权限控制”简化操作。利益相关方诉求的多维平衡-监管方：核心诉求是“风险可控”，通过技术手段确保远程医疗平台符合法规要求，同时避免过度监管阻碍行业创新。例如，通过“区块链存证”实现数据操作可追溯，降低监管成本。03远程医疗隐私保护的技术架构分层设计远程医疗隐私保护的技术架构分层设计面对复杂多元的业务需求，远程医疗隐私保护需构建“分层解耦、协同防护”的技术架构。本文参考NIST网络安全框架，将架构分为“基础设施层-数据层-应用层-安全层”四层，每层聚焦不同隐私保护目标，共同支撑业务合规与效率。基础设施层：隐私保护的数据底座基础设施层是远程医疗的“运行基石”，其隐私保护核心是“环境安全”与“资源隔离”，确保数据在存储和传输时的物理与逻辑安全。基础设施层：隐私保护的数据底座云计算架构选择：按数据敏感度匹配部署模式远程医疗平台需根据数据敏感度选择云架构：公有云（如阿里云、腾讯云）适合部署非敏感业务（如用户注册、问诊预约），因其弹性扩展成本低；私有云（如医疗机构自建云）适合存储敏感数据（如患者病历、影像），因其物理隔离性强；混合云（敏感数据存私有云，非敏感数据存公有云）则平衡了安全与成本。例如，某省级远程医疗平台采用“混合云”架构，患者病历影像存储在本地私有云，问诊预约系统部署在公有云，通过“安全通道”实现数据互通。基础设施层：隐私保护的数据底座边缘计算：靠近数据源的“轻量化”隐私处理边缘计算将计算能力下沉至数据采集端（如可穿戴设备、基层医院终端），可减少数据传输量，降低隐私泄露风险。例如，智能血糖仪在测量血糖后，先在本地对数据进行“脱敏处理”（去除患者姓名、身份证号，仅保留血糖值和加密ID），再上传至平台，避免原始数据公网传输。此外，边缘计算还可支持“实时隐私保护”，如语音问诊中，本地终端先对语音进行“关键词脱敏”（隐去“身份证号”“住址”等敏感词），再传输给医生，防止信息泄露。基础设施层：隐私保护的数据底座硬件安全模块（HSM）：密钥管理的“物理保险箱”加密技术是隐私保护的核心，但密钥管理是“阿喀琉斯之踵”。硬件安全模块（HSM）是专门用于存储和管理密钥的物理设备，通过“硬件级加密”和“访问控制”防止密钥泄露。例如，远程医疗平台使用HSM存储数据库加密密钥，即使服务器被攻破，攻击者也无法获取密钥，数据仍保持加密状态。数据层：全生命周期的隐私管控数据层是隐私保护的“核心战场”，需对数据从“产生到销毁”的全生命周期实施精细化管理，确保数据“可用不可见、使用可追溯”。数据层：全生命周期的隐私管控数据采集：最小化原则与用户授权-最小化采集：仅采集诊疗必需的数据，避免“过度索权”。例如，在线问诊平台仅收集患者主诉、过敏史等必要信息，无需获取其通讯录、位置权限等无关数据。-动态授权：通过“细粒度授权”让用户控制数据使用范围。例如，患者授权“某三甲医院专家查看其近3个月血糖数据”，同时禁止平台将数据用于广告推送，授权可通过“一键撤回”终止。数据层：全生命周期的隐私管控数据存储：加密技术与存储隔离-静态加密：对存储的数据（如数据库、文件）进行加密，防止数据被物理窃取。常用技术包括“透明数据加密（TDE）”（加密数据库文件）、“文件系统加密”（加密存储设备数据）。例如，某医院电子病历系统采用AES-256算法加密数据库，即使硬盘被盗，数据也无法解密。-存储隔离：通过逻辑或物理隔离，防止敏感数据与非敏感数据混合存储。例如，将患者病历数据存储在“安全数据库集群”，与普通用户数据（如问诊记录日志）隔离，设置严格的访问控制策略，仅授权人员可访问安全集群。数据层：全生命周期的隐私管控数据传输：端到端安全通道远程医疗数据传输需确保“全程加密”，防止公网监听与篡改。常用技术包括：-TLS/SSL协议：在传输层加密数据，适用于浏览器与服务器、APP与服务器之间的通信。例如，患者通过APP上传检查报告时，HTTPS协议（TLS加密）可防止报告被第三方截获。-DTLS协议：针对UDP协议（如实时音视频会诊）的加密传输，解决TLS无法直接应用于UDP的问题。例如，远程会诊中的视频通话采用DTLS加密，确保音视频数据不被窃听。-量子加密前瞻：面对未来量子计算对传统加密算法的威胁，部分机构已试点“量子密钥分发（QKD）”，通过量子信道传输密钥，实现“理论上无条件安全”的加密传输。例如，某高校与医院合作开展QKD远程医疗实验，成功实现跨城100公里的安全数据传输。数据层：全生命周期的隐私管控数据使用：隐私计算技术赋能隐私计算是“数据可用不可见”的核心技术，可在不暴露原始数据的前提下实现数据价值挖掘。主流技术包括：-联邦学习（FederatedLearning）：多方在不共享原始数据的情况下，联合训练AI模型。例如，5家医院通过联邦学习训练糖尿病预测模型，各医院将模型参数上传至中央服务器聚合，原始数据保留在本地，模型效果接近使用全部原始数据训练的结果。-安全多方计算（SMPC）：多方在不泄露各自输入数据的前提下，联合计算函数结果。例如，两家医院需联合统计某地区糖尿病患者平均年龄，通过SMPC技术，双方输入各自患者的年龄数据，系统仅输出平均值，不泄露单个患者年龄。数据层：全生命周期的隐私管控数据使用：隐私计算技术赋能-可信执行环境（TEE）：在CPU中创建“隔离执行环境”（如IntelSGX、ARMTrustZone），数据在该环境中处理时，即使操作系统内核被攻破，也无法获取数据。例如，远程会诊平台使用TEE存储患者数据，专家仅能在TEE中查看数据，无法导出或截屏。-差分隐私（DifferentialPrivacy）：在数据集中添加“calibrated噪声”，使查询结果无法反演个体信息。例如，某平台发布某地区高血压患病率数据时，通过差分隐私技术添加噪声，攻击者无法通过多次查询推断出某位患者是否患病。数据层：全生命周期的隐私管控数据销毁：不可恢复的彻底清除根据“被遗忘权”要求，用户有权要求删除其数据，且数据需被“不可恢复”清除。常用技术包括：-逻辑销毁：删除文件系统中的数据索引，使数据无法被系统访问，但数据仍可能被恢复（适用于非敏感数据）。-物理销毁：对存储介质（如硬盘、U盘）进行消磁、粉碎，确保数据无法恢复（适用于敏感数据）。例如，患者要求注销账户后，平台需对其病历数据进行物理销毁，并出具《数据销毁证明》。应用层：场景化隐私功能嵌入应用层是直接面向用户（患者、医生、管理员）的界面，需将隐私保护功能“无缝嵌入”业务流程，避免“安全与效率的冲突”。应用层：场景化隐私功能嵌入身份认证与访问控制：精准匹配“身份-权限-数据”-多因素认证（MFA）：结合“所知（密码）+所有（手机验证码）+所是（生物特征）”，提升账户安全性。例如，医生登录远程会诊系统时，需输入密码+指纹验证，防止账户被盗用导致患者数据泄露。01-基于角色的访问控制（RBAC）：根据用户角色（如主治医生、实习医生、管理员）分配不同权限。例如，主治医生可查看患者完整病历，实习医生仅能查看被授权的部分病历，管理员可管理用户权限但无法查看患者数据。02-属性基访问控制（ABAC）：基于用户属性（如科室、职称）、数据属性（如数据密级、患者病情）、环境属性（如访问时间、地点）动态控制权限。例如，心内科医生仅能在工作时间内访问本科室患者的心电图数据，且无法下载原始文件。03应用层：场景化隐私功能嵌入隐私协议设计：用户友好的授权与追溯-分层授权协议：将数据授权分为“基础授权”（如问诊数据使用）、“扩展授权”（如数据用于科研）、“敏感授权”（如数据跨境传输），用户可逐级选择授权范围。例如，患者在首次问诊时需签署《基础授权协议》，若平台需将数据用于AI模型训练，需弹出《扩展授权协议》供用户勾选同意。-数据使用追溯：通过区块链技术记录数据操作日志（如谁在何时、何地、以何种目的访问了数据），确保操作可追溯、不可篡改。例如，某患者的病历数据被医生查看后，系统自动生成一条包含“医生ID、访问时间、访问内容”的区块链记录，患者可通过APP查看这些记录。应用层：场景化隐私功能嵌入隐私增强的用户界面：降低用户隐私焦虑-隐私仪表盘：可视化展示数据使用情况（如“您的数据被2位医生用于会诊，1次用于科研”），让用户对数据流向有清晰认知。-隐私设置中心：提供“一键隐藏敏感信息”（如病历中的身份证号仅显示后4位）、“授权管理”（可随时撤回非必要授权）等功能，增强用户控制感。安全层：整体防护与运营安全层是隐私保护的“指挥中心”，通过监测、响应、培训等手段，确保技术架构持续有效运行。安全层：整体防护与运营安全审计：全流程日志与异常监测-集中式日志管理：收集各层系统日志（如登录日志、数据访问日志、加密模块日志），通过SIEM（安全信息和事件管理）系统统一分析，发现异常行为（如短时间内多次失败登录、非工作时段访问敏感数据）。-AI审计模型：利用机器学习学习正常用户行为模式，识别异常操作。例如，某医生通常在白天访问患者数据，若系统检测到其在凌晨3点大量下载病历，可触发告警并自动冻结账户。安全层：整体防护与运营入侵检测与防御（IDS/IPS）-网络层IDS/IPS：监测网络流量中的异常数据包（如SQL注入、暴力破解攻击），阻断恶意流量。例如，IPS检测到某IP地址频繁向远程医疗服务器发送SQL注入语句，可自动封禁该IP。-应用层WAF：防护Web应用漏洞（如XSS、CSRF），防止攻击者通过漏洞窃取用户数据。例如，WAF可过滤恶意脚本，避免攻击者通过XSS攻击获取患者Cookie。安全层：整体防护与运营应急响应机制：隐私泄露的快速处置1制定《隐私安全事件应急预案》，明确“监测-研判-处置-溯源-整改”流程。例如，一旦发生数据泄露，需在24小时内启动响应：2-隔离风险：立即暂停受影响系统，防止泄露扩大；3-告知用户：按照法规要求通知受影响患者及监管部门；4-溯源分析：通过日志、区块链记录等定位泄露原因；5-整改加固：修复漏洞，更新防护策略，避免类似事件再次发生。安全层：整体防护与运营安全意识培训：从“被动防护”到“主动免疫”医护人员是隐私保护的“最后一道防线”，需定期开展培训：01-医护人员：培训内容包括数据分类分级、安全操作规范（如不随意泄露患者信息、定期更换密码）、应急流程；02-患者：通过APP推送、宣传手册等方式，普及隐私保护知识（如如何识别钓鱼链接、如何查看数据授权记录）。0304技术架构与业务需求的匹配实践：场景化解决方案技术架构与业务需求的匹配实践：场景化解决方案技术架构的价值，最终体现在对业务需求的精准响应上。以下结合四类核心业务场景，分析技术架构如何与业务痛点“对症下药”。在线问诊场景：实时交互与隐私保护的平衡业务痛点：患者需快速上传症状数据（如照片、语音），医生需实时查看并反馈，但公网传输存在数据泄露风险，且复杂的隐私保护流程可能影响问诊体验。技术匹配方案：-边缘层：可穿戴设备/手机终端对上传的图片/语音进行“本地脱敏”（如隐去背景中的个人信息），减少传输数据量；-传输层：采用DTLS+TLS1.3加密传输，确保音视频、文字数据全程加密；-应用层：医生端设置“临时访问权限”（如查看权限仅持续24小时），过期自动失效；患者端提供“敏感信息隐藏”功能（如身份证号仅显示后4位）；-安全层：部署AI审计模型，监测异常访问（如非主治医生查看患者主诉），并实时告警。在线问诊场景：实时交互与隐私保护的平衡案例效果：某互联网医院采用该方案后，患者数据泄露投诉率下降90%，平均问诊时长缩短至8分钟（较之前缩短30%），医生反馈“隐私保护措施几乎不影响操作效率”。远程会诊场景：跨机构数据共享的“安全孤岛”突破业务痛点：多医院数据不互通（如基层医院无患者完整病史），专家需全面了解患者病情，但直接共享原始数据存在隐私泄露风险。技术匹配方案：-数据层：采用联邦学习技术，各医院在本地训练模型，仅上传模型参数至中央服务器聚合，原始数据不出院；-应用层：基于区块链的“数据共享存证系统”，记录每次数据调用的“发起方、接收方、数据内容、使用目的”，确保可追溯；-安全层：使用可信执行环境（TEE）存储患者数据，专家仅能在TEE中查看数据，无法导出或截图。远程会诊场景：跨机构数据共享的“安全孤岛”突破案例效果：某区域医疗中心通过联邦学习平台，联合5家三甲医院开展远程会诊，专家调取患者完整病史的时间从原来的2小时缩短至10分钟，且未发生一起数据泄露事件。某专家评价：“以前会诊像‘盲人摸象’，现在能全面掌握患者情况，诊断准确率提升了20%。”慢病管理场景：患者数据主权的长期保障业务痛点：患者需长期授权数据使用，担心数据被平台滥用（如用于商业推送），且缺乏便捷的数据管理工具。技术匹配方案：-数据层：采用“差分隐私+区块链”技术，平台发布统计分析结果（如某社区糖尿病患者血糖达标率）时，通过差分隐私添加噪声，保护个体隐私；区块链记录数据授权与使用记录，确保透明可追溯；-应用层：开发“数据主权管理模块”，患者可通过APP查看数据流向（如“您的血糖数据于2023年10月被用于AI并发症研究”），并支持“一键撤回授权”；-安全层：定期开展“数据安全审计”，检查平台是否存在超范围使用数据的行为，并向患者公开审计报告。慢病管理场景：患者数据主权的长期保障案例效果：某糖尿病管理平台采用该方案后，用户数据授权率从35%提升至78%，用户满意度达92%。一位患者表示：“以前不知道自己的数据被怎么用，现在能随时看到记录，才敢放心让平台管理我的健康数据。”AI辅助诊断场景：高质量训练数据与隐私保护的协同业务痛点：AI模型需海量数据训练，但原始数据涉及患者隐私，直接使用可能导致“数据泄露不可逆”；且不同医院数据标准不统一，影响模型效果。技术匹配方案：-数据层：采用“联邦学习+模型水印”技术，各医院在本地训练模型，中央服务器聚合后生成“全局模型”；同时，在模型中嵌入“数字水印”，追踪数据来源（如某医院提供的训练数据占比），防止模型被滥用；-应用层：设置“数据使用审计”功能，监管方可通过平台查看各医院数据参与训练的情况，确保合规；-安全层：采用“差分隐私”对训练数据进行扰动，防止模型反演患者个体信息（如通过CT影像反演患者身份）。AI辅助诊断场景：高质量训练数据与隐私保护的协同案例效果：某AI企业通过该方案联合20家医院训练肺结节检测模型，模型AUC达0.92（接近中心化训练效果），且未发生数据泄露事件。某合作医院表示：“既参与了AI模型研发，又保护了患者隐私，一举两得。”05匹配过程中的挑战与未来展望匹配过程中的挑战与未来展望尽管技术架构与业务需求的匹配已取得显著进展，但远程医疗隐私保护仍面临诸多挑战，需行业协同突破。当前面临的核心挑战技术成本与业务效益的平衡隐私计算技术（如联邦学习、TEE）部署成本高（如服务器、算法开发），中小医疗机构难以承担；而降低成本可能影响保护效果（如简化加密算法）。例如，某基层医院曾因采购不起HSM设备，采用软件加密存储患者数据，结果遭遇勒索软件攻击，导致数据泄露。当前面临的核心挑战法规动态更新与技术迭代的适配法规政策随行业发展不断更新（如《生成式AI服务管理暂行办法》要求AI训练数据需符合隐私保护要求），但技术迭代速度可能滞后于法规变化。例如，某平台已部署联邦学习系统，但新规要求“训练数据需通过第三方安全评估”，导致原有流程需重新调整。当前面临的核心挑战患者隐私意识与数据利用的矛盾部分患者因隐私过度担忧拒绝提供必要数据（如隐瞒传染病史），影响诊疗效果；部分患者则因缺乏隐私意识随意授权（如点击“同意”前未阅读条款），导致数据被滥用。如何平衡“隐私保护”与“数据利用”，仍是行业难题。当前面临的核心挑战新兴技术带来的隐私风险元宇宙医疗场景中，虚拟诊疗需采集用户动作、表情等生物特征数据，存在“身份冒用”风险；脑机接口技术直接读取用户神经信号，可能暴露用户思维隐私。这些新兴场景对现有隐私保护技术提出更高要求。未来优化方向技术融合：构建“隐私保护技术栈”将联邦学习、TEE、差分隐私、区块链等技术深度融合，形成“1+1>2”的协同效应。例如，“联邦学习+区块链”可解决数据共享与追溯问题，“TEE+差分隐私”可提升AI训练的