这些工作仍然重要，但美国犹他州、得克萨斯州和路易斯安那州近年通过的应用商店问责法案，正在把问题推向更底层的位置。根据未来隐私论坛（FPF）2026 年 6 月 2 日更新的比较表，三州均在 2025 年通过了这类法案，核心是在应用商店层面建立用户年龄验证和未成年人父母同意机制，并同时对应用商店提供者和应用开发者设置义务。FPF 也特别说明，三州义务结构大体相似，但在关键术语、适用范围和核心义务上存在重要差异；路易斯安那州和犹他州又在 2026 年作出修法，使三州模式进一步分化。

这类规则的真正影响，不只是多了一项"儿童合规"要求。它更重要的变化在于，未成年人保护开始被做成一套基础设施：应用商店负责在入口处识别年龄、绑定父母账户、取得同意、传递年龄与同意状态；开发者则需要把这些信号落实到自己的产品体验、数据处理、购买流程、重大变更管理和安全默认设置中。

一、监管为什么开始盯上应用商店

单个应用各自承担未成年人保护义务，表面上符合"谁提供服务，谁承担责任"的逻辑，但在实践中会遇到几个难题。

首先是重复验证。一个未成年人可能在多个应用中反复填写年龄，甚至在不同场景下给出不同年龄。开发者越多，验证标准越分散，父母和用户越难判断哪些信息被收集、谁在处理这些信息、同意记录存在哪里。

其次是能力差异。大型平台可以建立复杂的年龄识别、家长控制和内容分级体系，但大量中小开发者很难独立完成同样水平的合规设计。监管如果只依赖每个开发者自行判断，制度效果会很不稳定。

更重要的是，单个应用通常只掌握自己的服务链路，却无法完整控制账户创建、应用下载、应用购买、应用内购买、家庭账户、设备入口和应用分发生态。应用商店恰好位于这些链路的交汇处。它既掌握账户和下载，也掌握支付、内购、开发者接口、设备生态和家庭账户能力。把年龄验证和父母同意前移到应用商店层面，可以让未成年人保护从单个应用内部动作，变成整个分发生态的统一信号机制。

这也是三州法案共同指向的制度逻辑。犹他州、得克萨斯州和路易斯安那州的具体设计并不完全相同，但它们都在尝试让应用商店成为未成年人保护的新入口。

这意味着，企业的第一步已经不再是简单判断"我的产品是不是儿童应用"。更准确的问题是：产品是否通过应用商店进入相关州用户场景，是否可能被未成年人使用，是否存在下载、购买、应用内购买、家庭账户、连接设备、预装应用、共享账户或青少年高频使用场景。只要这些问题的答案是肯定的，企业就不能只从自己的应用界面理解未成年人保护，而要把应用商店、账户系统和开发者接口一起纳入合规设计。

二、适用入口：不是只看儿童应用，而是看应用分发生态

三州规则的共同逻辑，不是只监管儿童应用，而是抓住应用商店这一分发入口。犹他州定义中明确指向允许犹他州用户下载应用到移动设备的应用商店；得克萨斯州和路易斯安那州虽然在定义中没有同样写明地域限制，但在实体义务中设置管辖连接点；路易斯安那州 2026 年修法进一步把可下载应用至连接设备的服务纳入应用商店定义。

适用入口。 犹他州定义中明确写入"犹他州用户"；得克萨斯州和路易斯安那州定义中未同样写明地域限定，但实体义务中有管辖连接点。企业不要只判断"是否儿童应用"，还要判断是否通过应用商店触达相关州用户。

设备范围。 路易斯安那州 2026 年修法将连接设备纳入范围，智能电视、车载设备、共享设备场景也要纳入评估。

开发者范围。 得克萨斯州缺少对"开发者"和"应用"的直接定义，FPF 认为这可能造成范围不确定。出海企业不能只等应用商店处理，自己的开发者义务仍需单独评估。

这类规则会让"应用商店—开发者—用户账户—父母账户"成为一个共同运行的合规链条。对于开发者而言，应用商店完成年龄验证，并不意味着开发者从未成年人合规中退出。相反，开发者会被接入一条新的信号链：应用商店负责产生年龄和同意信号，开发者负责将这些信号落实到产品和数据处理活动中。

三、年龄验证：年龄类别不是标签，而是产品治理触发器

三州都围绕四类年龄类别展开：十三岁以下、十三至十六岁、十六至十八岁和成年人。这个设计本身很值得注意，它没有要求所有场景都处理精确年龄，而是把用户归入不同年龄区间，再基于年龄区间触发不同的保护措施。

但三州对"年龄类别"的定义并不完全一致。得克萨斯州把年龄类别定义为应用商店为指定用户所属年龄类别而收集的信息；犹他州和路易斯安那州则把年龄类别定义为年龄区间本身，并另行处理年龄验证过程中收集的数据。FPF 特别指出，得克萨斯州这种定义会影响应用商店必须向开发者共享的信息范围，因为年龄类别不仅包括被分配的年龄区间，也包括用于分配该年龄区间的信息。

年龄类别。 得克萨斯州定义为"为指定用户年龄类别而收集的信息"——包含用于分配年龄区间的数据本身；犹他和路易斯安那定义为年龄区间本身，另设"年龄类别数据"概念。得克萨斯州的数据共享和删除压力更高，企业要区分"年龄区间信号"和"年龄验证数据"。

验证方式。 三州均使用商业上可用且合理设计的方法；犹他和路易斯安那允许未成年人场景下结合父母声明和账户信息（vouching）；路易斯安那还可使用由机动车办公室授权的实时年龄验证系统——即 LA Wallet 数字身份系统。

现有账户。 犹他州条文中出现"现有账户在生效日后十二个月内"的表述，但 FPF 分析栏提示三州均无明确现有账户年龄验证要求。现有账户处理不宜简单外推。

年龄类别的意义，不是让企业知道用户究竟几岁，而是让产品能够基于年龄区间自动改变运行方式。一个十三岁以下用户、一个十三至十六岁用户、一个十六至十八岁用户，面对的下载、购买、广告、推荐、社交、智能聊天和数据收集规则，本来就不应完全一样。

这里的企业动作应当非常具体。广告模块要知道是否可以进行个性化展示；推荐模块要知道是否需要限制内容；社交模块要知道是否开放陌生人互动；支付模块要知道是否允许应用内购买；内容模块要知道是否展示特定类型内容；智能聊天或陪伴类功能要知道是否需要更严格的安全边界和人工干预机制。年龄验证本身也会带来新的隐私风险——如果验证机制设计过重，儿童保护就可能反过来变成新的身份数据收集入口。

四、父母同意：从弹窗变成账户级授权链路

未成年人保护里最容易被简化的概念，是父母同意。很多产品过去会把父母同意理解为注册或使用前的一个弹窗。但在三州规则里，父母同意被嵌入到账户体系之中：未成年人账户需要与父母账户关联；下载应用、购买应用、应用内购买等行为，需要从关联父母账户取得同意。

父母账户关联。 得克萨斯州不仅要求验证成年人身份，还要求验证其有法律权限代表未成年人作决定——确认一个人已成年相对容易，确认这个成年人是否有权代表某个未成年人作决定，则可能涉及监护关系、家庭结构、离异家庭、共享账户、争议处理和申诉纠错。

下载与购买同意。 得克萨斯州包含一项独特规定——禁止应用商店取得一次性总括同意覆盖多个购买或下载（§121.026(3)）——犹他和路易斯安那无此明示禁止。同意颗粒度要细化，不能只设计一个"家长总授权"。

预装应用。 路易斯安那州要求首次访问预装应用前完成父母账户关联和同意；犹他州要求应用商店在开发者请求时提供可用年龄类别信息并协助取得父母同意，但不要求访问前完成关联。

撤回同意。 三州均要求应用商店向开发者共享父母撤回同意通知。产品需要有撤回后的功能降级、暂停、限制购买或数据处理机制。

父母同意不再只是页面上的一个按钮，而是账户关系、授权颗粒度、同意记录、撤回通知和产品响应共同组成的运行链路。

五、父母披露：不是只写隐私政策，而是提供可理解的决策材料

三州都要求在取得父母同意时向父母提供相关披露，内容通常包括应用年龄评级、数据收集和共享情况，以及开发者为保护个人数据采取的措施。得克萨斯州更为细致，要求披露导致年龄评级的具体内容或元素，以及个人数据使用的性质，而不仅是收集和共享。

应用年龄评级。 父母同意披露中通常需要包含；得克萨斯州要求提供评级及导致评级的具体内容或元素。企业要能解释为什么应用或功能适合某一年龄段。

数据处理说明。 得克萨斯州还要求披露个人数据使用的性质。不能只写泛泛的隐私政策，需要形成可供应用商店和父母理解的分层说明。

保护措施披露。 安全措施、权限控制、数据最小化、保留期限需要有可复核材料。

这类披露不是简单把隐私政策再复制一遍。父母要作出的是具体授权决定：是否允许孩子下载、购买、内购或继续使用某个应用。因此披露材料应当围绕父母决策组织，而不是围绕企业免责组织。

六、开发者义务：应用商店产生信号，开发者负责执行

这类法案最值得关注的部分，是应用商店与开发者之间的信号传递。三州规则共同建立了一种新的协同机制：应用商店负责产生年龄类别和父母同意信号，开发者负责基于这些信号调整自己的产品和数据处理活动。

信号与响应。 应用商店传递年龄类别信号→开发者根据年龄区间调整功能、内容、推荐、广告、社交、支付和安全默认设置。应用商店传递父母同意状态→开发者判断是否允许下载、购买、内购或继续使用。应用商店传递撤回同意通知→开发者触发权限降级、暂停服务或限制购买。

不能怎么做。 不能只把年龄类别存为合规字段而不改变产品行为。不能把应用商店取得同意理解为开发者免责。撤回同意后不能继续按原状态处理未成年人数据。不能将年龄验证数据用于画像、广告定向或商业推荐。

三州在开发者义务上存在明显差异。得克萨斯州要求开发者为每个应用和每个应用内购买提供年龄评级，并提供导致评级的具体内容或元素，完成必要验证后应删除应用商店提供的个人数据。犹他州和路易斯安那州未明确要求创建年龄评级体系，但允许开发者每十二个月一次核验准确性，在有合理怀疑账户转让或误用时可额外请求数据。路易斯安那州还允许开发者实际知道内部信息更准确时依赖内部信息，并规定开发者使用最低年龄类别配置安全默认设置。

得克萨斯州对开发者更不友好，也更具有提示意义。它提醒企业，年龄治理不能只靠应用商店给一个信号。开发者自己也要能解释：这个应用为什么适合某个年龄段，某个应用内购买为什么需要限制，验证完成后从应用商店取得的数据有没有及时删除。

七、重大变更：产品发布流程要增加未成年人合规闸口

三州规则中还有一个容易被低估的机制：重大变更。重大变更通常包括数据收集、存储或共享类别变化，年龄评级或内容描述变化，新增应用内购买或广告；得克萨斯州和路易斯安那州还覆盖应用功能或用户体验的重大变化。

触发评估的产品变化。 新增广告或改变广告模式、新增应用内购买或订阅、新增数据收集存储或共享、接入新的第三方工具包、上线社交或私信或陌生人互动、上线智能聊天或陪伴或推荐功能、调整年龄评级或内容描述——这些都需要进入未成年人合规评估。得克萨斯州的触发门槛可能更低，因为它覆盖影响或改变评级及评级依据内容或元素的变化。

通知对象和时间差异。 犹他和路易斯安那似乎要求通知所有用户或账户持有人；得克萨斯似乎只要求通知与未成年人关联的父母账户持有人。FPF 还提示，得克萨斯州是唯一要求开发者在重大变更"实施前"通知应用商店的州——犹他和路易斯安那均未规定通知必须在实施前进行。

企业应当把重大变更评估放进版本发布流程，而不是等上线后再由法务修改隐私政策。

八、复杂账户和设备：路易斯安那州提示了下一阶段问题

路易斯安那州 2026 年修法很有意思。它新增家庭账户应用的定义和相关例外，FPF 说明这些修改是为了协调立法目标与依赖家庭或共享账户应用的运营现实，例如流媒体服务。

未成年人并不总是拿着自己的手机、使用自己的账户、主动下载自己的应用。大量儿童和青少年是在家庭订阅、共享账户、智能电视、预装应用和连接设备中使用数字服务。未成年人保护正在从"注册时识别年龄"，走向"持续判断谁在使用、谁能授权、谁应受到保护"。

路易斯安那州的家庭账户应用例外需要准确理解——它并不是全面豁免。按照 FPF 的比较，它只是在安全默认设置和功能访问方面设置了一个较窄例外：开发者可以使用主账户持有人的年龄范围作为指定年龄类别，并允许主账户持有人声明子账户的年龄类别；但家庭账户应用开发者仍然受到法律其他要求约束。

九、禁止性要求、责任限制与执法风险

这类规则不仅设置义务，也设置了禁止性要求。三州普遍禁止在未取得父母同意的情况下对未成年人账户执行合同或服务条款，禁止在父母同意披露中作出虚假或误导性陈述，并限制年龄类别信息或相关数据的进一步共享。路易斯安那州 2026 年修法将原本关于共享年龄类别信息的限制，调整为禁止出售年龄类别信息。

得克萨斯州还为两种特定类型的应用设置了父母同意例外：一是提供紧急服务访问的应用（如报警电话、危机热线），要求限制数据收集且无需账户创建；二是由非营利组织运营或合作、用于高等教育入学或分班标准化考试的应用。犹他和路易斯安那在 2026 年修法后删除了各自的例外条款；三州均以"且"连接例外条件，意味着所有条件必须同时满足。

责任限制。 三州均为开发者提供某种形式的责任限制——开发者善意依赖应用商店提供的年龄类别和同意信息可降低风险。FPF 特别指出，犹他州是唯一没有为应用商店年龄验证和父母同意义务提供责任限制的州。

执法路径。 犹他州 2026 修法后主要依赖私人诉讼（实际损害或每项违法 $1,000，取高）。得克萨斯州将违反行为纳入欺骗性贸易实践法，既有州执法也可能触发消费者私人诉讼。路易斯安那州由总检察长执法，执法前至少 45 日书面通知并提供整改期，未整改或重复违法后每项最高 $10,000，违反行政或法院命令最高 $5,000。

生效时间。 得克萨斯州已于 2026 年 1 月 1 日生效；犹他州分阶段生效，商店和开发者义务及执法条款于 2027 年 5 月 6 日生效；路易斯安那州于 2027 年 7 月 1 日生效。得克萨斯和路易斯安那没有设置规则制定程序，不能期待后续一定有强制监管细则统一解释。

十、开发者接口：规则已经进入技术实现层

FPF 附录整理了苹果和谷歌围绕年龄信号提供或计划提供的开发者接口信息。苹果将提供年龄范围接口，使应用能够接收新账户用户的年龄范围信息，相关信号共享仅限于要求应用商店提供年龄信号的司法辖区；十八岁以下用户的新苹果账户将需要加入家庭共享组。谷歌将通过年龄信号接口向应用提供用户年龄验证、监督状态、年龄范围和其他适用信号；由于得克萨斯州法案初步禁令，谷歌在 2026 年 1 月 1 日关闭了该接口测试版的实时响应返回。

这说明规则已经进入开发者文档和技术接口层面。企业不能把它只当成法律团队需要阅读的新法规。真正的合规工作会落在产品字段、接口调用、后端状态、权限控制、日志留存、数据删除和版本发布流程上。

结语：儿童保护正在进入账户、接口和默认设置

应用商店问责法案提醒企业，未成年人保护正在从单个应用内部，进入更底层的账户、接口和默认设置。

过去企业可能把儿童合规理解为几项文件工作：写儿童隐私政策，设计家长同意弹窗，限制部分功能。现在美国州法正在把问题拆得更细：谁识别年龄，谁确认父母，谁取得同意，谁传递信号，谁在产品内执行限制，谁在重大变更后重新通知，谁删除不再必要的数据，谁在发生争议时承担责任。

三州共同塑造了方向：应用商店成为未成年人保护入口，开发者接入年龄与同意信号。三州差异则说明，这套制度仍在成型。得克萨斯州更强调父母授权、开发者评级和数据删除；路易斯安那州更努力处理连接设备、家庭账户和预装应用；犹他州则保留了较清晰的州内用户和移动应用入口。

对企业而言，真正重要的不是记住每个州的每一项条文，而是看清这个趋势：未成年人合规正在从"写给用户看的合规文件"，转向"产品实际运行时的治理机制"。谁能把年龄类别、父母同意、撤回通知、重大变更、数据最小化和安全默认设置做进系统，谁才真正具备应对下一阶段儿童网络保护规则的能力。

延伸阅读

FPF: TX, UT, LA App Store Accountability Act Comparison Chart (June 2, 2026)

https://fpf.org/wp-content/uploads/2026/06/FPF-Legislation-TX-UT-LA-App-Store-Accountability-Act-Comparison-Chart.pdf

#AI治理 #儿童网络保护 #应用商店问责 #美国州法 #数据合规 #年龄验证 #那一片数据星辰

说明：本文件为公众号渲染试稿，建议在浏览器中打开后复制渲染结果，再粘贴到公众号编辑器。