Digital Omnibus 之后的 Cookie 同意：什么会变，现在该建什么

Cookie 横幅是互联网上最不受待见的界面。它同时也是被监管得最多的界面之一，因为它可见、可测，而且有成千上万的人在举报。

2025 年 11 月，欧盟委员会提出了 Digital Omnibus 一揽子方案，其中一项是把 Cookie 同意规则从电子隐私指令直接搬进 GDPR，成为新的第 88a 条和第 88b 条。三方谈判持续到 2026 年中，最终文本尚未出炉。

这就是每个产品团队眼下面对的矛盾：现行规则仍然有效，而且执法很积极，但你据以构建的规则很可能在一两年内改变。以下是我们对这段时间该怎么做的看法。

今天的位置

当前的法律状态是两部法律不太舒服的组合。

电子隐私指令管的是设备本身。在用户终端设备上存储数据或从中读取数据需要同意，除非这对提供用户明确请求的服务是绝对必要的。这覆盖 Cookie、localStorage、设备指纹和跟踪像素。

GDPR 管的是随后收集的个人数据：处理依据、透明度、权利、留存。

这就是为什么"我们对分析有合法利益"解决不了 Cookie 问题。处理依据覆盖的是处理。访问设备仍然需要同意。

有效同意的现行要求，如多家监管机构所细化：

• 拒绝和接受一样容易，同一层级、外观一致的按钮。
• 非必要目的不得预先勾选。
• 可按目的分开选择。
• 清楚说明谁会拿到数据。
• 撤回和给予一样容易。
• 不得设置强制接受才能访问、且无真实替代的墙。
• 保存同意证据。

还有一个让大多数站点栽跟头的实操测试：在用户做出选择之前，不加载任何非必要的东西。

Digital Omnibus 会改变什么

这份提案是一次实质性的简化尝试，主要内容包括：

同意和 Cookie 成为 GDPR 的事。 第 88a 条会把关于在设备中存储和访问数据的规则搬进 GDPR，结束两部法律的割裂，并给数据保护机关明确的管辖权。

更宽的豁免。 提案会扩大不需要同意的情形，涵盖网络安全、在特定条件下的受众度量，以及服务运行所必需的部分。这是细节上争议最大的一块。

拒绝后六个月静默。 如果用户拒绝，六个月内不得再提出同一请求，除非在有限情形下。这直指横幅疲劳。

机器可读信号具有法律约束力。 第 88b 条会要求尊重在浏览器或操作系统层面给出的自动同意信号。这里架构变化最大。

一揽子方案的其他部分还提出了对个人数据定义、人工智能训练的合法利益和数据泄露通报的澄清。这些同样不是定局。

为什么不能干等

两件事让"等等看"成为糟糕的选择。

第一，现行执法没有暂停。数据保护机关仍在开展横幅行动，缺少拒绝选项仍是最常见的发现。"我们在等 Omnibus"在 2026 年的审计里不是抗辩理由。

第二，提案的方向已经足够清楚，可以指导架构，即使细节会变。机器可读信号、尊重拒绝状态、按目的分开选择，都是现在就值得建的东西，无论最终文本如何。

我们今天会怎么建

下面这套同意架构在现行规则下成立，并且能以较小的改动挺过可能的变化。

让同意状态成为服务端概念

最常见的错误是把同意当作浏览器的事。同意平台设一个 Cookie，脚本去查它，然后就没了。

一旦服务端做了任何依赖同意的事情，这就崩了：个性化、服务端跟踪、向广告平台发送事件、A/B 分流。这些都发生在浏览器脚本来得及表态之前。

把同意状态存成服务端能按请求读取的形式，并让它成为两侧所有非必要处理的前置条件。

条件化脚本加载，而不是事后拦截

拦截是事后补救。它在同意平台认识那个脚本时有效，在不认识时静默失败。

改为这样构建标签加载：在同意状态已知且为肯定之前，非必要脚本根本不存在于 DOM 中。这通常意味着一个小的加载控制器，读取按目的的同意并注入对应的标签。

这样测试就简单了：干净配置文件、网络面板、不点击、没有第三方请求。这就是监管机构会跑的同一个测试。

建模目的，而不是供应商

列出 47 家供应商的横幅是糟糕的界面，也难以维护。列出四个目的的横幅可读，而且在供应商变动时仍然正确。

把供应商映射放在目的之下，而不是作为用户看到的第一层选择。用户仍然必须能看到供应商清单，但它可以在第二层。

建一份可查询的同意日志

你必须能回答：谁同意了、哪些目的、什么时候、来自横幅的哪个版本、状态何时变过。把它存成事件日志，而不是当前状态，因为当前状态不会告诉你某个事件被记录时生效的是什么。

这也是为什么拟议的六个月规则很容易实现：如果你有带时间戳的拒绝事件，实现静默期就是加一个条件。

为机器可读信号做准备

即使第 88b 条没有以现在的形式通过，方向也是清楚的。把同意层设计成能接受多个来源的输入：界面里的选择、存储的历史选择和外部信号，并给它们明确的优先级。

实践中这意味着解析同意的逻辑集中在一个函数里，而不是散落在横幅的组件树中。

区分必要项并给出理由

写下为什么每一个被归为必要的 Cookie 是必要的。会话、负载均衡、CSRF 令牌、语言选择：这些很容易。分析不是，哪怕它被叫作第一方分析。

这份清单是第一个会被问到的东西，它也决定了如果 Omnibus 通过，你是否会从扩大的豁免中受益。

我们见到的最常见错误

拒绝按钮在第二层。 至今如此。这是执法行动中最常见的单项发现。

同意没有覆盖服务端跟踪。 团队因为浏览器限制转向服务端事件发送，却没有把它接到同意上。现在无论用户选了什么，事件照发。

每次访问同意都被重置。 通常是 Cookie 生命周期或域设置错了。用户被迫无休止地回答同一个问题，而这正是拟议的静默期想要终结的。

撤回被藏起来。 如果接受只要一次点击，撤回却要翻隐私政策，那就不是一样容易。

没有同意证据。 平台显示一个仪表盘，但你自己的系统里什么都没有。换供应商，证据就没了。

子供应商悄悄出现。 通过标签管理加进来的一个营销工具，带来另外三个。没有人更新横幅的供应商清单。

现实的时间线是什么

如果 Digital Omnibus 通过，可以预期在适用前有过渡期，之后各国机关会发布指引。实际意义是：在相当一段时间里，你被衡量的仍然是现行规则。

我们对客户说的是：按现行规则建，但要建成让变化只是配置而不是重写。按目的分开、事件式日志、服务端状态和一个解析函数，就给了你这份弹性。

这与别的东西在哪里相交

同意基础设施牵扯的不只是横幅。它驱动个性化、分析、广告，以及越来越多的人工智能功能。如果你的产品用了人工智能，人工智能法案的透明度义务会加上自己的告知层，而从用户角度看这是同一场对话：发生了什么、谁决定、怎么说明。

地基仍然是 GDPR 本身，我们在网站 GDPR 指南里过了一遍，完整的监管图景在我们的 2026 年欧盟数字合规指南里。

如果你需要帮忙

我们为在欧洲经营的公司构建同意架构、标签管理和分析流水线。实践中这多半是管道工作：把同意状态送到需要它的地方，并确保在该发之前什么都不发出去。

写信到 office@c9group.dev，或者看看我们的欧盟市场进入页面。

我们不提供法律建议。什么算必要、什么不算，是你们律师的问题，我们围绕他们的答案来建系统。