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

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

2025 年 11 月，欧盟委员会提出了 Digital Omnibus 一揽子方案，其中一项是把 Cookie 同意规则从电子隐私指令直接搬进 GDPR，成为新的第 88a 条和第 88b 条。截至 2026 年 10 月 10 日，一揽子方案中涉及 GDPR 和电子隐私的部分还没有进入三方谈判。理事会尚无谈判授权：原定 10 月 7 日由欧盟各国大使进行的表决被推迟，据报道改到 2026 年 10 月 11 日。欧洲议会方面，LIBE 和 ITRE 两个委员会在 2026 年 6 月 22 日发布了报告草案，收到超过 1750 项修正案，至今没有进行委员会表决。

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

今天的位置

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

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

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

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

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

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

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

Digital Omnibus 会改变什么

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

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

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

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

机器可读信号具有法律约束力。 第 88b 条会要求尊重在浏览器或操作系统层面给出的自动同意信号。这里架构变化最大。这也是成员国最不喜欢的部分：下文介绍的理事会文本把第 88b 条整条删除了。

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

理事会文本有什么不同

成员国手里的是另一份文本。爱尔兰轮值主席国 2026 年 10 月 2 日提出的妥协文本（理事会文件 13886/26）是作为理事会与欧洲议会谈判的授权起草的，截至 2026 年 10 月 10 日尚未通过。它在几个地方改动了欧盟委员会的设计：

• Cookie 规则留在电子隐私指令里。 第 5 条第 3 款原地改写，第 88a 条和第 88b 条不加入 GDPR。这份文本里没有尊重浏览器信号的义务。
• 六种目的无需同意：传输通信、用户明确要求的服务、产生匿名汇总数据的第一方受众度量、依据《欧洲媒体自由法》进行的媒体受众度量、安全，以及在不做用户画像的前提下度量情境广告的展示和效果。
• 一键拒绝。 用户必须能够"通过单击按钮或同等方式"拒绝。
• 更短的等待期。 用户拒绝后，"至少四个月"内不得为同一目的再次请求，而欧盟委员会文本是六个月。
• 欧盟委员会的两个设想保留下来：96 小时的数据泄露通报期限，以及个人数据的相对定义。

这是谈判立场，不是法律，而欧洲议会还没有通过自己的立场。

为什么不能干等

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

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

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

我们今天会怎么建

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

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

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

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

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

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

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

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

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

建模目的，而不是供应商

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

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

建一份可查询的同意日志

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

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

为机器可读信号做准备

理事会文本删除了第 88b 条，因此尊重浏览器信号的约束性义务可能根本不会出现。尽管如此，仍应把同意层设计成能接受多个来源的输入：界面里的选择、存储的历史选择和外部信号，并给它们明确的优先级。

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

区分必要项并给出理由

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

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

我们见到的最常见错误

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

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

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

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

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

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

现实的时间线是什么

如果 Digital Omnibus 通过，可以预期在适用前有过渡期。在欧盟委员会的文本里，Cookie 条款会在生效后约六个月适用；理事会文本则给成员国 24 个月，把新的第 5 条第 3 款转化为国内法，但其最终条款仍写着六个月的日期，这一冲突要由谈判各方解决。浏览器信号义务可能根本不会到来。之后各国机关会发布指引。实际意义是：在相当一段时间里，你被衡量的仍然是现行规则。

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

这与别的东西在哪里相交

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

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

如果你需要帮忙

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

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

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