产品数据收集与隐私告知缺口排查

能帮做什么

新功能增加了一个手机号字段，隐私政策是否要更新，不能只看有没有写“手机号”。还要看为什么收集、是否必填、交给谁、保存多久，以及用户拒绝后能否继续使用其它功能。

WorkBuddy 可以把产品需求、字段清单、数据流程文字和隐私告知放在一起，找出描述不一致或材料不完整的位置，形成法务与产品共同核对的清单。它不凭隐私政策文本推定系统实际行为。

准备什么

提供本次功能的 PRD、注册与授权流程文字、字段清单、是否必填、触发条件、处理目的、存储和接收方说明，以及当前用户协议和隐私告知。补充公司确认的个人信息审查要求与已批准的历史说明。

使用字段定义和脱敏样例即可，通常不需要上传真实客户名单。说明产品版本和本次变更点；没有数据链路的，请技术人员补充文字，不用假设所有字段都留在企业内部。

具体怎么做

第一步：按功能拆出处理活动

让 WorkBuddy 按“用户做什么—系统收集什么—为了什么—给谁处理”的顺序列出活动。手机号、设备标识和行为记录不要只按是否包含姓名判断；单独或结合其它信息可能识别个人的内容，应交由法务核对。

第二步：核对实际需求与告知

逐项比对字段、目的、收集时机、可选性、接收方、保存和退出安排。标明哪些来自产品材料，哪些来自告知文本。文本没有写明和系统确实没有该行为是两件事，应分别记录。

第三步：将缺口变成分工问题

产品确认字段必要性与拒绝后的体验，技术确认实际调用和访问，法务判断处理基础及适用要求。对不确定事项列出需要补的事实，先不生成一段笼统的“完善隐私政策”作为结论。

可直接交给 WorkBuddy 的完整要求

请基于提供的产品需求、字段表、数据处理流程文字、隐私告知及企业确认规则，整理个人信息处理活动和告知缺口草稿。以本次产品版本为范围，不读取真实用户数据库。

输出活动清单，字段包括功能步骤、数据字段、是否必填、收集时机、处理目的、接收方、保存安排、用户拒绝或退出方式、材料位置。未说明的标为待补。再与告知文本逐项对应，列出不一致、未覆盖及需要专业判断的事项。

针对每项缺口提出一个具体问题，建议由产品、技术或法务谁来回答。例如询问某字段为何为基础功能所必需、第三方实际收到哪些数据。不要把去标识化直接当作匿名化，不把用户协议或企业采购合同直接视为全部处理活动的合法依据。

只输出待复核表和告知修改候选，不判断整体已合规，不自动决定同意方式或评估义务，不修改生产系统。

得到什么

得到处理活动清单、产品与告知对照表和补证问题表。例如字段表列出定位信息，告知只写“改善服务”，应指出具体目的和必要性尚未明确，要求产品补充使用场景、技术补充精度及调用条件，再由法务判断如何告知和处理。

怎么检查

抽查关键字段是否回到 PRD 或技术说明，第三方和保存安排是否有来源。检查是否把收集、分析、共享、训练混成一个目的；是否将可选字段写成必需；是否把没有材料误写成没有处理行为。修改候选必须基于已确认事实。

异常处理

PRD 与实际实现不一致时，以技术确认的信息补齐差异，不直接覆盖原有描述。资料只说“已脱敏”，仍需明确可否恢复或关联到个人。涉及敏感信息、未成年人、自动化决策或跨境访问的，单独标出并交法务专项确认。

人工决定

产品对业务必要性负责，技术对实际链路负责，法务决定处理基础、告知及同意要求和是否需要进一步评估。是否上线由授权人员批准。补齐一段文字不能自动证明系统处理方式已合规。

第三方组件更新时怎么补充

将下面这段一并交给 WorkBuddy：“在处理活动表中增加应用版本、SDK 名称及版本、启用模块、技术确认日期和第三方清单版本。核对组件更新是否改变字段、目的、接收方或保存安排，保留当前与拟变更情况；供应商声明不能当作实际检测结果。缺少版本或配置的列为待补，不直接改告知。”SDK 的接入、升级和退出事项按 134 场景继续处理，本表负责确认它们是否完整进入产品整体告知。