# 授权运营中的"最小必要"如何写进审批流 "最小必要"在各类数据规范里几乎都是基本原则，但在授权运营的实际操作里，它常常停留在纸面：审批单上勾一个"同意"，数据就整表整库地出了门。要让原则真正落地，关键不在写一份更长的制度，而在把"目的"和"范围"拆成审批流里可勾选、可留痕的具体动作。 ## 一、用"用途结构化"锁住目的限定 目的限定要求数据提供与明确、合理的目的直接相关。落到审批入口，应把"申请用途"从自由文本框改为结构化字段：业务场景、使用方式、预期产出三栏必填，且要与已有的授权范围匹配。像"科研""分析"这类过于宽泛的表述，应退回补正，而不是默认放行。这一步不是给业务设卡，而是为后面"给哪些字段"划出边界。具体口径需结合机构实际判断。 ## 二、把"最小"下沉到字段级白名单 "最小"最难的是度量。建议审批对象从表/库下钻到字段：依据分类分级结果，对每个候选字段标注"必需/可选/不予提供"。例如为做人群统计，可能只需年龄区间与科室，不必给完整身份与明细。审批人据此生成字段白名单，超范围字段默认不授权。这样业务可用性与防过度收集可同时成立。必要性分级口径需结合机构实际判断，并随场景迭代。 ## 三、授权链与处理方式要在审批单留痕 审批不只决定"给什么"，还要确认"凭什么给""以什么形态给"。来源与授权链是前置条件：采集与授权是否合法、委托与融合关系是否留痕，都应在材料中可复核。输出形态上，须区分去标识化（脱敏）与匿名化：脱敏数据在多数情形下仍可能被关联重识别，仍属个人信息；匿名化则是不可逆地去除可识别性。二者不可混用，也不能把"已脱敏"简单等同于"已安全"。审批单应记录所选方式及理由。 ## 四、审批之后仍有监督与回收 一次签字不等于一劳永逸。闭环要求审批后做使用监督：监测实际调用是否偏离申请目的（目的漂移），并设置授权期限与到期自动回收。对停用、超期或用途变更的情形，触发复核或回收，并将全过程记入审计轨迹，供内外部审查调用。把审批、使用、回收串成一条可追溯的链路，"最小必要"才能在数据生命周期内持续成立，而非只停留在签字那一刻。 ## 五、可执行清单 1. 将"申请用途"改为结构化字段（场景、方式、产出必填），对模糊表述退回补正。 2. 建立字段级必要性分级（必需/可选/不予提供），审批仅生成字段白名单，超范围默认不授权。 3. 把来源与授权链设为审批前置条件，确保合法基础与委托、融合关系可复核。 4. 审批单显式选择脱敏或匿名化并留理由，严格区分二者，不把"已脱敏"等同"安全"。 5. 配置使用监督、目的漂移检测与到期回收机制，将审批—使用—回收纳入统一审计轨迹。
