age-verification-methods

年龄验证和估算方法

概述

年龄验证和年龄估算是两种不同但互为补充的方法，用于确定用户是否为儿童，以便采取适当的数据保护措施。年龄验证通过文件或交易凭证对年龄进行确定性确认。年龄估算则通过面部分析、行为分析或设备信号等技术方法，对年龄进行概率性评估。选择适当的方法时，需要平衡准确性、隐私影响、可访问性和适度性。本技能涵盖各种可用方法、其在 GDPR、《英国适龄设计规范》（UK AADC）、COPPA 以及欧盟《数字服务法》（DSA）和英国《2023 年在线安全法》等新兴法规下的监管背景，并根据 ICO 和 CNIL 的建议提供实施指导。

监管背景

GDPR 第 8(2) 条

“控制者应考虑到可用技术，尽合理努力在此类情况下核实同意是否由对儿童负有父母责任的人给予或授权。”

“尽合理努力”这一标准取决于具体情境。EDPB 未规定具体技术，但要求控制者采取与数据处理风险相称的验证措施。

英国《适龄设计规范》第 3 项标准——适龄应用

“基于风险采取措施，识别各个用户的年龄，并确保将本规范中的标准有效应用于儿童用户。”ICO 指南指出，所需的确定程度取决于数据处理给儿童带来的风险。风险越高，越需要采用更可靠的年龄保证方法。

英国《2023 年在线安全法》

第 11(3) 条要求受监管的用户对用户服务和搜索服务提供商采用“适度的系统或流程”，以防止儿童接触到对其有害的首要优先内容。Ofcom 的实践守则将年龄验证列为色情内容的建议措施，并将年龄估算列为更广泛内容类别的建议措施。

欧盟《数字服务法》——第 28 条

可供未成年人使用的在线平台提供商必须采取适当且相称的措施，确保未成年人在其服务中享有高度的隐私、安全和保障。这包括对有内容限制的服务进行年龄验证。

法国——《SREN 法》（2024 年）

法国关于规范和保障数字空间的法律要求访问色情网站时进行年龄验证，并强制采用经 CNIL 认证的技术解决方案，在不识别用户身份的情况下验证年龄。CNIL 批准的参考系统要求采用“双盲”架构，使身份验证提供商和内容提供商无法将用户身份与内容访问关联起来。

年龄验证方法

方法 1：基于证件的验证

描述：用户上传或出示政府签发的身份证件（护照、国民身份证、驾驶执照），通过核验证件安全特征，并可选择与政府数据库进行比对来验证证件。

技术实现：

• 光学字符识别（OCR）提取出生日期和证件详情
• 对符合 ICAO Doc 9303 标准的护照和身份证进行机读区（MRZ）验证
• 证件真实性检查：全息图检测、微缩印刷分析、紫外线特征验证（适用于出示实体证件的情况）
• 可选：读取符合 ICAO 9303 Part 10 标准的电子护照 NFC 芯片
• 可选：活体检测，确认出示证件的人与照片中的人相符

准确度：非常高（结合活体检测时为 99% 以上）

隐私注意事项：

• 收集高度敏感的身份数据（身份证号码、全名、地址、照片）
• 数据最小化：仅提取出生日期，并在验证后立即丢弃完整证件图像
• 存储：不保留证件图像或完整身份数据；仅保留二元的年龄已确认标记和验证令牌
• 根据第 35 条，由于涉及大规模处理身份证件，必须进行 DPIA

无障碍性：无法覆盖没有政府签发身份证件的人群（据选举委员会 2021 年数据，估计有 150 万英国成年人没有带照片的身份证件）。不适合作为唯一方法。

适用场景：有年龄限制的内容（赌博、酒类、成人内容）、高风险服务

方法 2：面部年龄估算（基于 AI）

描述：机器学习模型通过设备摄像头采集的面部图像估算用户年龄。估算结果为年龄范围（例如“18 岁以上”或“13—17 岁”），而非精确年龄。

技术实现：

• 使用大规模带年龄标签的面部数据集训练的卷积神经网络（CNN）
• 在设备端实时处理（边缘计算），避免将面部图像传输到服务器
• 活体检测，防止通过照片或视频回放进行欺骗
• 年龄估算结果会给出置信区间（例如，估算年龄为 14 +/- 2 岁，置信度为 95%）
• 面部图像在易失性内存中处理，不会被存储

准确度：平均绝对误差（MAE）为 1.5—3 年，具体取决于模型和人口统计特征。准确度因以下因素而异：年龄组（对 8 岁以下儿童和 65 岁以上成人的准确度较低）、种族（一些商业系统存在有据可查的偏差）、光照和图像质量。

隐私注意事项：

• 根据 GDPR 第 4(14) 条和第 9(1) 条，如果面部图像用于唯一身份识别，则属于生物识别数据
• 如果仅用于年龄估算（而非身份识别），处理行为可能不构成第 9 条所指的“为唯一身份识别目的而处理的生物识别数据”——ICO 已在其《儿童守则》指南中确认这一解释
• 在设备端处理且不向服务器传输数据，可大幅降低隐私风险
• 即使在设备端处理，由于面部数据的敏感性，仍建议进行 DPIA

主要提供商：Yoti（Age Estimation）、VerifyMyAge（EstimateMyAge）、Privately SA

ICO 立场：ICO 表示，在本地处理图像、不存储图像且不识别个人的面部年龄估算技术，可以作为一种适度的年龄保障方法。2022 年，ICO 与澳大利亚信息专员办公室（OAIC）联合审计了 Yoti 的年龄估算技术，并得出结论：在实施适当保障措施的情况下，该技术符合数据保护要求。

方法 3：数字身份验证

描述：用户通过可信的数字身份提供商（eID、数字钱包、开放银行）进行身份验证。该提供商确认用户的年龄，但不会向依赖方（服务提供商）披露用户的完整身份信息。

技术实现：

• 使用 OpenID Connect for Identity Assurance（OIDC4IDA）协议进行基于属性的验证
• 身份提供商通过签名断言确认特定属性（例如，“is_over_18”：true）
• 依赖方仅接收年龄属性，不会收到用户的姓名、地址或其他身份数据
• 欧盟数字身份钱包（eIDAS 2.0 Regulation，预计于 2026 年推出）将支持选择性披露属性
• 英国数字身份与属性信任框架（DIATF）为身份提供商提供认证机制

准确性：非常高（取决于身份提供商对基础身份的验证）

隐私注意事项：

• 最少披露数据：仅共享特定年龄属性
• 身份提供商知道用户的身份，但不知道用户访问的是哪项服务（如果采用双盲架构）
• 服务提供商知道用户正在访问其服务，但不知道用户的完整身份
• 符合 CNIL 推荐的年龄验证“双盲”方法

适用场景：为 eIDAS 2.0 数字身份钱包做准备的欧盟/欧洲经济区服务；使用 DIATF 认证提供商的英国服务

方法 4：自我声明并辅以风险缓解措施

描述：用户通过出生日期字段或年龄范围选择器申报年龄。将申报结果作为基准，并辅以基于风险的措施来检测虚假申报。

技术实现：

• 中立的年龄提示：“您的出生日期是什么？”并提供可滚动的日期选择器（不默认显示当前日期）
• 不提示“正确”答案或所采用的年龄门槛
• 可能表明申报不实的行为信号：立即重新输入不同日期、Cookie 中存在此前申报的记录、输入速度模式与申报年龄不符
• 如果怀疑申报不实，则升级为更高保证级别的验证方法

准确性：单独使用时较低。儿童经常在网上虚报年龄。Ofcom 2023 年的研究发现，33% 的英国 8-17 岁青少年尽管未达到平台规定的最低年龄，仍拥有社交媒体个人资料。

隐私注意事项：仅收集最少数据（用户申报的出生日期）。不处理生物特征数据。不收集身份证明文件。

适用场景：作为低风险服务的第一道筛查措施；对于中高风险服务，始终应结合其他保障措施

方法 5：信用卡或支付验证

描述：根据用户持有信用卡（通常仅发放给年满 18 岁的成年人），通过货币交易推断其年龄。

技术实现：

• 收取一笔小额交易（USD/EUR/GBP 0.50），并在 48 小时内退款
• 必须使用信用卡（而非可能发放给未成年人的借记卡或预付卡）
• 向持卡人发送交易通知，作为审计记录
• 部分实现会使用 3D Secure（3DS2）认证来加强身份保证

准确性：中等。这能证明当事人可以使用信用卡，而这与年满 18 岁有关，但无法验证持卡人的具体年龄。儿童可能会使用父母的卡。

隐私注意事项：支付卡数据受 PCI DSS 要求约束。服务不应存储完整的卡片信息。仅应保留交易确认信息和二元的“持有信用卡”标记。

方法 6：移动网络运营商（MNO）验证

描述：移动网络运营商根据与 SIM/eSIM 关联的用户订户信息确认用户所属的年龄段，同时不向请求服务披露用户身份。

技术实现：

• 使用用户的手机号码向 MNO 发起 API 调用（通过 GBG、boku 或 Sinch 等聚合服务商）
• MNO 返回二元响应（例如，"is_over_18": true/false），不披露身份
• 依据 MNO 在订户注册时收集的年龄数据（销售点进行的 ID 检查）

准确性：在判断用户是否年满 18 岁方面准确性高，因为 MNO 注册通常涉及 ID 验证。对于更精细的年龄判断（例如区分 13 岁和 15 岁），确定性较低，因为 MNO 可能不会记录准确的出生日期。

隐私考量：服务只能获知年龄段。MNO 会获知用户正在访问哪项服务（除非中间架构能够避免这一情况）。建议针对 MNO 的数据处理开展 DPIA。

准确性与隐私权衡矩阵

方法	准确性	隐私影响	适用场景
基于证件	非常高	非常高（收集 ID）	年龄限制商品（赌博、酒类）
面部年龄估算	高（MAE 为 1.5-3 年）	中等（设备端）至高（服务端）	一般在线服务、社交媒体
数字身份	非常高	低（仅披露属性）	任何服务；隐私与准确性的最佳平衡
自我声明	低	非常低	初步筛查；仅适用于低风险服务
信用卡	中等	中等（支付数据）	用于家长同意的补充验证
MNO 验证	高	低至中等	移动优先服务；补充检查

基于风险的选择框架

第 1 步：对服务风险级别进行分类

风险级别	标准	示例
高	与陌生人直接消息交流、陌生人可见的用户生成内容、年龄限制内容、针对儿童的变现功能	社交媒体、约会应用、赌博、在线市场
中	内容个性化、应用内购买、经过审核的社区功能、带有用户画像的教育服务	EdTech 平台、游戏、流媒体服务
低	静态内容交付、无社交功能、不共享数据、不创建用户画像	信息类网站、单人离线游戏

第 2 步：选择最低验证级别

风险级别	最低验证要求	建议方法
高	基于证件 OR 面部估算 + 活体检测	基于证件，并提供数字身份作为替代方案
中	面部年龄估算（设备端）OR 自我声明 + 风险信号	面部年龄估算，并设置升级处理路径
低	自我声明 + 中性提示	自我声明，并通过基于 Cookie 的重新进入检测

第 3 步：进行比例原则测试

针对每种选定的方法，记录：

1. 为什么有必要使用此方法来保护儿童？
2. 是否可以使用侵入性更低的方法达到同等保护水平？
3. 哪些保障措施可以最大限度地降低此方法对隐私的影响（数据最小化、设备端处理、立即删除）？
4. 此方法如何兼顾无 ID 用户和残障用户的无障碍需求？

BrightPath Learning Inc. — 年龄验证实施方案

BrightPath Learning Inc. 运营一个被归类为中等风险的教育平台（提供带有进度跟踪和个性化功能的教育内容，不包含与陌生人社交的功能）。

已实施方案：分层验证

1. 第 1 层 — 自我声明：注册时使用中立的出生日期提示和可滚动的日期选择器。用于确定初始分流方向（儿童账户或成人账户）。
2. 第 2 层 — 家长账户：对于声明年龄低于适用门槛的用户，将触发家长同意流程。家长创建账户，并通过信用卡小额交易进行验证。
3. 第 3 层 — 异常检测：监测行为信号以发现不一致情况：儿童账户与家长账户的 IP 地址不匹配、电子邮件域名相同，可能表明用户在自行验证、同一位家长在短时间内创建多个儿童账户。
4. 第 4 层 — 升级验证：如果检测到异常，会要求家长完成视频验证通话，或上传政府签发的身份证件（验证完成后立即删除）。

年龄验证数据保留期限：

• 自我声明的出生日期：在账户生命周期内保留
• 信用卡交易记录：保留 90 天（用于对账），然后删除；仅保留“家长已验证”标记
• 政府身份证件图像：在内存中处理，不予存储；保留验证结果
• 人脸图像：不收集（BrightPath 不使用人脸年龄估算）

新兴标准与立法

IEEE 2089.1-2024 — 适龄数字服务框架

已发布的标准，为在数字服务中实施适龄设计提供框架，包括年龄保障方法及其在不同风险情境中的应用指南。

ISO/IEC 27566 — 年龄保障系统（制定中）

年龄保障系统工作草案标准，涵盖年龄验证和年龄估算。涉及准确性、隐私、无障碍性、互操作性和治理要求。

欧盟数字身份钱包（eIDAS 2.0）

修订后的 eIDAS 法规要求欧盟成员国在 2026 年前向公民提供数字身份钱包。该钱包将支持选择性属性披露，使用户能够证明自己已超过特定年龄，而无需透露完整身份或出生日期。这将成为欧盟服务首选的年龄验证方式。

集成点

• GDPR 家长同意：年龄验证是判断是否需要根据第 8 条取得家长同意的前提
• 英国 AADC 实施：AADC 标准 3 要求采用与风险相称的年龄保障措施
• 年龄门控服务：年龄验证结果用于决定是否允许访问、重定向或屏蔽用户
• COPPA 合规：COPPA 要求将年龄筛查纳入家长同意流程
• 儿童隐私声明：年龄验证结果决定显示哪个版本的隐私声明（儿童友好版或标准版）