核对 SDK 接入变更与退出的数据处理安排

能帮做什么

产品准备接入第三方登录、定位或推送组件，研发说只是升级版本，隐私清单却还沿用旧说明。法务需要问清：版本和功能变了什么，会接触哪些信息，哪些安排已经验证，旧版本停用后留下的数据如何处理？

SDK 是嵌入应用、提供特定功能的软件开发工具包。WorkBuddy 可以读取接入材料，将当前版本、拟变更版本、合同与披露说明逐项对应，形成待核事项；也可以在停用时整理交接和数据处置材料，帮助各部门确认遗漏。

准备什么

准备应用及版本、SDK 名称和供应商、当前与拟采用版本、功能模块和配置说明、供应商隐私规则及接入文档、合同、现有第三方清单、内部准入规则。技术人员还应提供实际权限调用、数据接收方和传输说明；有测试报告时一并提供。

本次如果是退出，再补停用日期、历史数据存放位置、供应商返还删除答复及依法保留的说明。文件含客户或用户数据时，先取得授权并按公司要求脱敏，不必为说明组件功能上传整批真实用户数据。

具体怎么做

第一步：锁定实际使用的组件

先建立组件事实卡，写清哪个应用版本使用哪个 SDK 版本、启用哪些模块。供应商品牌相同、版本不同的材料分别记录。没有配置和技术说明时，先列为待补，不能仅凭官网功能介绍推断实际采集范围。

第二步：比较声明、设计与验证结果

按处理目的、信息种类、权限、传输接收方、保存期限等列出当前与拟安排。将供应商规则、企业设计和实际测试分列，避免一句“供应商承诺合规”覆盖全部问题。变更了目的、方式或信息种类时，列给法务判断告知、同意和合同是否需要调整。

第三步：让配置与披露同步落地

把每个差异改成具体待办，例如“拟启用位置模块，但清单未列位置信息，请产品确认必要性、技术补实际调用说明、法务核对告知安排”。批准后的上线版本、模块开关和第三方清单应对应同一范围，不能只改文字、不核实际配置。

第四步：核对退出后的遗留事项

停用时分别记录是否停止调用、关联权限或凭据如何处置、历史数据由谁返还或删除、哪些项目尚无回执。涉及依法保存或技术难删的情况，记录具体依据、限制处理安排和后续复核时间，交专业人员判断。应用删除一段代码，不能直接证明供应商已经删除历史数据。

可直接交给 WorkBuddy 的完整要求

请依据我提供的应用版本、SDK 接入或变更单、供应商规则、合同、第三方清单和技术验证材料，整理本次 SDK 数据处理核对草稿。先说明范围是首次接入、升级变更还是退出；按应用版本、SDK 版本和启用配置建立事实卡。材料缺失直接写待补，不推测实际采集行为。

输出三部分：一是组件事实卡，列供应商、版本、模块、用途、信息种类、权限、接收方、保存期限及材料位置；二是差异和补证表，将供应商声明、内部设计、技术验证结果分列，写出当前与拟安排、差异、待补证明、建议责任人和状态；三是退出事项表，列停止调用、权限凭据、历史数据返还或删除、依法保留说明、披露更新及未完成事项。

对新旧处理目的、方式、信息种类的变化作显著提示，列为法务待判，不自行认定是否应重新同意。引用已有文件名和原文位置支持每个差异。区分委托处理、共同处理和独立接收方关系尚未确认的情况；不要把全部 SDK 当作受托人。供应商没有回执写未确认，不写已删除；仅有官网说明不写已实测。不得批准接入、替换或上线，不联系供应商，不改应用、不撤权限、不删除数据。

得到什么

得到组件事实卡、差异及补证表、退出事项表。例如，一行可以写：“升级说明增加设备识别信息，当前披露未体现；需研发补实际采集说明，产品确认用途，法务核对处理依据与告知安排。”每项都能交给明确的人员继续处理。

怎么检查

核对应用、组件版本和配置是否对应；关键差异能否回到原句或技术报告；退出事项是否区分停用、数据处置和披露更新。检查有没有把供应商声明写成实测结果，或把缺材料写成已经违规。

异常处理与人工决定

版本不明先补版本，规则与实测冲突保留两种证据，热更新造成范围不清时交技术人员补充。产品判断必要功能，技术人员验证实际行为与停用，法务判断处理关系及法律要求，企业授权人员决定接入、变更和退出。WorkBuddy 整理出的表格不证明组件已通过技术检测或数据已被删除。