手机屏幕亮起，一个工具类应用请求访问通讯录。它给出的理由很顺滑：方便邀请好友。问题在于，用户只是想把图片裁成方形，通讯录和这件事并没有天然联系。这样的瞬间，构成了讨论数据隐私的起点：不是抽象地反对采集，而是追问采集是否与当下任务相称。
授权弹窗之后，真正发生的事
多数人已经习惯在弹窗里点“允许”，再迅速回到手头的事。授权动作只有一秒，后续的数据流向却可能延续很久。产品团队常把权限视为功能开关，用户则把它当作一次性选择；两种理解之间的落差，正是数据隐私容易被磨损的地方。可操作的做法不是把弹窗做得更复杂，而是让权限与功能一一对应：用相机时只请求相机，用位置时说明是单次还是持续，用通讯录时给出拒绝后仍可使用的路径。
少收一点，未必少做一点
人工智能功能往往依赖数据，但“依赖”不等于“全量收取”。文本润色未必要保留完整历史，语音转写未必要长期存储原始音频，设备端可完成的推理也未必要先上传。数据最小化不是一句口号，它要求团队在功能设计时就回答几个笨问题：这项数据是否直接服务于当前功能，处理完成后能否删除原始内容，用户能否撤回不再需要的授权。
- 先问用途：采集是为了完成眼前任务，还是为以后可能的功能预留？
- 再问时长：结果产生后，原始数据是否还有必要继续保留？
- 最后问可见性：用户能否知道哪些数据被使用，并撤回不再需要的权限？
这些问题不保证风险归零，却能让保护从一句声明变成产品流程里的具体动作。对于人工智能功能而言，减少不必要的原始数据留存，也能降低后续泄露和误用的概率；这不等于削弱能力，而是把能力建立在清晰的边界上。
边界不是拒绝，而是可解释
有人把隐私保护理解成少用人工智能，这当然是一种选择，但对多数产品而言并不现实。更实际的边界是“可解释”：为什么需要、用在哪里、保存多久、谁能接触。解释不必写成法律文本，但应当让普通用户看得懂。如果一款产品只能说“为了改善体验”，却说不出改善了什么，信任就很难建立。隐私保护的难点也在这里：它很少在功能成功时被看见，却会在一次不合适的授权请求里被明显感知。
回到那个裁图应用。它完全可以先完成裁剪，在用户主动选择分享时再请求通讯录；也可以把“允许”拆成更细的选项，让拒绝不导致功能停摆。技术能力越强，越需要这种克制。不是每一次采集都值得发生，也不是每一次拒绝都意味着产品失败。对用户来说，知道自己交出了什么；对产品来说，知道为什么收取——这大概是数据隐私朴素而耐用的底线。