在移动互联网时代，在移动应用中人脸识别已成为最高频的生物特征验证方式。然而，这种“非接触式”的便捷背后，隐藏着数据过度采集、特征值逆向还原和云端泄露的风险，数据安全风险已从云端蔓延至终端。
“明者防祸于未萌，智者图患于将来。”作为个人信息保护标准体系的重要拼图，GB/T 41819-2022《信息安全技术 人脸识别数据安全要求》（以下简称“GB/T 41819”）为端侧人脸识别划定了清晰的技术红线。该标准已于2022年10月12日正式发布，于2023年5月1日正式开始实施。对人脸识别数据从收集、存储、使用到删除的全生命周期提出了系统性合规要求。
本文将围绕标准中 “6 人脸识别数据收集要求、7人脸识别数据存储要求、9人脸识别数据传输要求、11 人脸识别数据删除要求”的具体要求小节展开详细解读，聚焦企业在移动应用场景下如何正确对待人脸识别数据，一起梳理讨论企业的合规思路。
一、条款原文
图1：“GB/T 41819”部分条款内容
二、条款解读
下面，我们将针对 APP、小程序、H5 等移动应用端场景，重点围绕标准中 “第6章 人脸识别数据收集要求、第7章 人脸识别数据存储要求、第9章 人脸识别数据传输要求、第11章 人脸识别数据删除要求”的具体条款，梳理可落地的合规实践要点。
（一）人脸识别数据收集要求
1、针对“6-a）收集人脸识别数据时,应向数据主体告知人脸识别数据的相关事项,包括但不限于数据处理者的名称和联系方式、个人信息保护负责人的姓名和联系方式、处理规则、必要性依据等,并征得数据主体单独同意或书面同意;未取得数据主体单独同意收集的人脸图像应立即删除并确保不可恢复;”的解析。
1）告知：移动应用提供者在收集人脸信息时需向用户同步告知用户人脸识别的相关事项，可在触发人脸功能前，通过独立弹窗/半屏页等形式，明确告知：
数据处理者身份（名称+联系方式）
个人信息保护负责人（姓名+联系方式）
处理规则（收集/存储/使用/共享/删除）
必要性依据/具体用途（实际目的）
图2：人脸识别协议告知内容合规示例
2）单独同意：人脸信息属于敏感个人信息，需获取“单独同意”——即不能与其他授权捆绑，移动应用提供者可在人脸识别信息告知协议的弹窗交互设计时遵循以下原则：独立界面（必须使用独立于《用户协议》《隐私政策》的专属弹窗或页面）、禁止捆绑（弹窗内只能包含人脸识别授权事项，不能混入其他权限或条款）、选项明确（用户需单独勾选“同意”，不能默认打勾）。
图3：人脸识别协议告知弹窗合规示例
3）立即删除：如用户拒绝或未完成授权流程，已收集的人脸图像（如预览流中的帧）需立即删除并确保不可恢复。
2、针对“6-b）数据主体不同意收集人脸识别数据的,不应拒绝数据主体使用基本业务功能;”的解析。
重点：人脸识别应是“可选项”，而“非必选项”，移动应用端落地措施：
1）功能分级设计
在功能架构层面，需明确区分“基本业务功能”与“扩展业务功能”。
对于资讯浏览、商品浏览等基本业务功能，App 不得索取人脸权限;对于刷脸支付、登录等扩展业务功能，虽可索取权限，但必须同步提供替代验证方式。
2）提供替代方案
在提供人脸登录入口的同时，必须保留“密码登录”“短信验证码登录”等同等便捷的替代路径。不得人为增加非人脸验证方式的获取难度，能让用户在拒绝人脸后仍能使用服务。
3）拒绝后的行为规范
用户明确拒绝人脸识别后,应用不得在 48 小时内再次弹出授权提示。同时，不得以“体验不佳”“安全隐患”等理由，对用户进行反复诱导或施压，保障用户的自主选择权。
3、针对“6-c）应采用需要数据主体主动配合的措施收集人脸识别数据;应在识别过程中持续告知数据主体验证目的,并通过语言、文字等向数据主体进行提示;”的解析。
重点：防止App在后台静默采集人脸图像。不得自动默认采集，移动应用提供者可通过持续告知的UI实现，如：
采集前：弹窗告知目的&预计采集时长
采集中：顶部状态栏持续显示“人脸采集中”提示，并配合语音播报（无障碍场景）
采集后：明确告知“验证成功/失败”
4、针对“6-d）应仅收集生成人脸特征所需的最小数量、最少图像类型的人脸图像;”的解析。
移动应用提供者应采用“最小数量&最少类型”的方法，即在满足生物特征识别功能的前提下，通过技术手段将采集规模控制在绝对必要的范围内，不得超量、超范围采集。应仅采集足以生成有效人脸特征的数据样本。在绝大多数场景下，单次采集只需获取 1 张符合质量标准的人脸图像即可完成特征提取。严禁为了所谓的“提高识别率”或“算法训练”而无故增加采集张数。严禁在用户不知情或未授权的情况下，为后续可能的“算法升级”或“拓展功能”进行前置性的批量数据囤积，对于采集的次数、内容严格把控。
5、针对“6-e）应采取安全措施保证人脸识别数据的真实性、完整性和一致性,防止人脸识别数据在收集过程中泄漏或篡改;”的解析。
重点：防止注入攻击（照片/视频/3D面具）、中间人攻击、数据篡改。对于人脸识别数据，移动应用提供者应采用加密传输、权限控制、去标识化/匿名化等安全措施以保障传收集人脸识别数据的安全性。
（二）人脸识别数据存储要求
1、针对“7-a）应采用物理或逻辑隔离方式分别存储人脸识别数据和个人身份信息等;”的解析。
人脸识别数据属于生物识别信息，是敏感个人信息中的“最高敏感级”，应与一般个人身份信息实现存储层面的解耦。采用物理或逻辑隔离方式能有效降低“关联识别”风险。如果人脸特征值与姓名、身份证号、手机号存储在同一个表、同一行，一旦数据库泄露，攻击者可直接获得“人脸→身份”的映射关系，人脸识别便失去“不可直接识别”的隐私保护意义，致使原本不可逆的生物特征彻底丧失隐私保护屏障。因此移动应用提供者必须通过分库存储、分表存储或数据拆分等技术手段，确保人脸特征值不以明文或关联形式与普通身份信息共存于同一数据结构中，从底层阻断关联泄露风险。
2、针对“7-b）应采取加密存储等安全措施存储人脸识别数据;”的解析。
人脸识别数据作为最高敏感级的生物信息，必须采取加密存储等实质性安全措施，以确保数据的机密性与完整性。即使攻击者突破了存储边界（如拖库、物理提取终端），有效的加密机制也能使数据保持“不可读”状态，从而阻断其被还原或滥用的风险。移动应用提供者在存储人脸识别数据时，应采用强加密算法（如 AES-256）对人脸特征向量实施静态加密，并结合密钥管理机制（如 HSM 或云 KMS）实现密钥的安全托管与轮换。严禁以明文形式保存人脸模板或原始图像；若因业务必需必须存储原始图像，需同步实施同等强度的加密措施，并限定极短的保留周期，确保数据“可用不可见、存而不泄”。
针对“7-c）数据主体个人所有且具备人脸识别功能的信息技术产品,包括但不限于移动智能终端、智能家居设备等,应将人脸识别数据存储在信息技术产品中,并可由数据主体删除;”的解析。
本条款虽直接指向移动智能终端等硬件设备，但其确立的“数据本地化存储”与“用户删除权”的立法精神，对移动应用同样具有强指导意义。移动应用提供者应优先采用端侧识别架构，即在用户设备本地完成人脸比对与特征提取，避免将敏感生物信息上传至云端；若因业务场景确需上传，必须仅传输不可逆的特征值，并取得用户的单独、明示同意；同时，应在移动应用内显著位置设置数据删除入口，确保用户能够随时撤回授权并清除相关数据，切实保障数据主体对其个人信息的控制权。
（三）人脸识别数据传输要求
针对“数据处理者应采取双向身份鉴别、数据完整性校验、数据加密等措施保障人脸识别数据传输安全。”的解析。
人脸识别数据的传输环节，是数据从“端”到“云”的必经之路，也是最易被攻击者“半道劫持”的薄弱环节。筑牢“传输关”，作为移动应用提供者，在传输人脸识别数据过程中可采用以下安全措施：
图4：传输过程中可用安全措施示意图
（四）人脸识别数据删除要求
针对“数据处理者在发生以下情况时,应在15日内删除人脸识别数据并确保不可恢复:a)人脸识别数据处理目的已实现、无法实现或者为实现处理目的不再必要;b)人脸识别数据存储时间达到数据主体单独同意或书面同意的存储期限;c)数据主体撤回同意或明示停止使用;d)数据处理者停止提供人脸识别业务;e)数据主体一年未使用数据处理者提供的产品或服务;f)法律、行政法规规定的其他情形。”的解析。
“靡不有初，鲜克有终”。数据合规，始于收集，终于删除。本条提出两项核心要求：15日内删除、确保不可恢复；以及提出了六种触发条件：目的不再必要、存储期限届满、撤回同意/停止使用、业务停止、一年未使用、法律其他情形。
图5：六种触发条件的责任边界与实务要点示意图
三、结 语
GB/T 41819-2022中第六章（收集）、第七章（存储）、第九章（传输）、第十一章（删除），共同构成了人脸识别数据从流入、留存、流动到最终消亡的全生命周期安全防线。
正如古训所警：“千里之堤，溃于蚁穴”，对于移动应用提供者而言，这四章不是孤立的条款堆砌，而是一道环环相扣、缺一不可的合规闭环。四者环环相扣，任何一环的缺失，都可能导致整体合规体系的崩溃。
合规不是选择题，而是必答题；不是终点线，而是起跑线。人脸识别数据安全合规之路，道阻且长，行则将至。愿每一位从业者以标准为尺、以法律为绳，在技术与合规的平衡木上，行稳致远。
（本文作者：北京梆梆安全科技有限公司 黄康概 鲍佳）
声明：本文来自CCIA数据安全工作委员会，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。
