Grok 文本水印默认开启：7 个模型，工具参数一起标

2026 年 11 月 7 日起，xAI 对 7 个 Grok API 模型默认开启不可见文本水印，覆盖普通文本、结构化输出和工具调用参数。开发者不改一行代码，就多了一条披露义务。

结论：默认值一变，责任就跟着变了

合规要求通常以选项的形式出现：要不要标、标哪一段、标在哪个市场。xAI 这次把它写进了默认值，等于把选择题改成了默认项。

默认值的分量比想象中重。绝大多数团队不会逐条读 changelog，更不会主动去关一个默认开启的合规功能。默认开启，实际效果就是全量覆盖。

覆盖范围是 7 个模型：grok-4.7、grok-4.6、grok-4.5、grok-4.3，以及 grok-4.20 的推理版、非推理版和多智能体版。

这七个基本就是当前的主力产品线，从最新的 4.7 一直到 4.3，中间没有留下空档。想靠切模型来绕开，在自家产品线里绕不掉。

接口层面没有例外：api.x.ai 与各区域端点都算，Responses API 与 Chat Completions API 都算。没有参数要传，也没有开关要调。

时间点也很清楚。官方给的理由是遵守 EU AI Act 第 50 条，该条对 2026 年 8 月 2 日之前已上市系统的标记截止日是 12 月 2 日。xAI 提前近一个月落地。

提前落地有它的算盘。改一次默认值，比逐个客户沟通、逐份合同补充条款要便宜得多；代价由调用方在事后承担。

影响面：JSON 和函数参数也在统计分布里

官方文档写明，水印覆盖普通文本、结构化输出和工具调用参数。这一条比「文本加水印」重要得多。

文本水印影响的是人读到的内容；工具参数影响的是机器读到的内容。agent 链路里，参数会被下游系统直接消费，格式、字段、取值都要严格匹配。

也就是说，一段带统计特征的 JSON 会进入你的数据库、消息队列和第三方 SaaS。水印不改变 JSON 的合法性，但改变了它的可检测性。

还有一层容易被忽略：同一 prompt 在 11 月 7 日前后，输出不再逐 token 可比。做回归测试和缓存比对的团队，会看到一批无法解释的差异。

差异通常很小，几个 token 的措辞变化，函数参数里某个字段的顺序变一下。对断言式测试，这点差异足够让一整条用例翻红。

具体到链路，一段函数参数会被写进工单系统、被消息队列回放、被第二个模型当作输入再消费。它的生命周期比原始响应长得多。

也就是说，水印的统计特征会跟着数据一起流下去，而大多数下游系统并不知道这件事存在。这不是安全问题，是数据契约问题。

机制与检测：不改一个字，只改选词的概率

生成时

官方说法是不插入字符、不插入标记、不插入隐藏文本。做法是在生成过程中轻微影响 token 的选择。

单个 token 看起来完全正常，读者看不出差别。要几百个 token 之后，统计偏差才累积到可以测出来的程度。

这就是短文本容易判成 uncertain 的原因：样本太少，信号和随机波动分不开。

这类水印的通例是：生成时按一个密钥对候选词的概率做微小偏置，检测时用同一个密钥回算，看实际选词是否系统性偏离无偏分布。密钥不公开，检测才成立。

偏置幅度必须小到不改变可读性，又要大到能在几百个 token 里被统计出来。这两端的余量，决定了它在改写面前有多脆弱。

对集成方来说，唯一确定、逐请求可见的信号是响应头 x-watermark: true。

检测时

检测结果是三档：watermarked、not watermarked、uncertain。长文本信号更强，这是统计水印的固有性质，不是实现缺陷。

检测 API 需要提交申请，不对外开放。官方未公布审核标准，也未公布获批机构的数量。

这意味着标记能力可以大规模施加，验证能力却集中在少数手里。披露义务是普遍的，核验手段是稀缺的，这个不对称值得记住。

门槛设在申请上，有它的道理。检测器一旦开放，任何人都能反复试探哪些改写能削弱信号，等于把对抗方法免费发出去。

代价是这项透明度措施的实际覆盖面很窄。学校、平台、监管机构如果不能自测，「可检测」这一条就只在纸面上成立。

三家路线：差别不在技术，在默认值

同一部法规，三家厂商给出了三种默认值。下表只用公开信息，技术细节各家都没有公开到可复现的程度。

Anthropic 选的是最严：全球、默认、不给出口。代价是灵活度全部让给了确定性。

OpenAI 选的是最窄：只覆盖欧盟的消费端产品，API 保持默认关闭，客户按模型自己选。它把合规边界画在监管辖区上。

xAI 选的是默认开启加一个出口。它既拿到了「默认合规」的姿势，又没有把需要干净文本的客户挡在门外——代价是出口本身要签字。

三条路线里，只有 xAI 把「关掉」做成了一个需要承担责任的正式动作。这也是它最值得研究的地方。

法条只规定结果——机器可读、可检测——没有规定方法，也没有规定默认值。三家读的是同一条，选的是三种工程姿态。

所以这张表比的不是技术水平，是风险分配方式。谁承担默认状态下的合规成本，谁的客户承担例外状态下的合规成本，一目了然。

真正的风险不是被检测，是退出即担责

关闭路径只有一条：团队管理员在控制台按模型关闭，作用于该团队全部 API key，5 分钟内生效，写审计日志。

关闭之前要确认两件事：适用法律确实存在例外，以及标记与披露责任由客户自己承担。

这句话改变了性质。你关掉水印，不是「恢复原状」，是「接管义务」。原来由供应商承担的合规责任，随一次点击转到你的名下。

官方文档还写明，部分模型可能被锁定为开启。也就是说，不是每扇门都有把手。

所以真问题不是「能不能关」，而是「关了之后谁负责、拿什么证明」。前者是产品功能，后者是法律风险。

审计日志这一条值得单独看。它意味着「谁在什么时候关掉了哪个模型的水印」在公司内部是可查的，事后无法否认。

对一个要出海的团队，这个决定通常不该由工程师单独做。它需要法务确认辖区、确认用途、确认是否有例外条款可用。

还有一层现实约束：关闭是团队级、按模型的。一条产品线关掉水印，共用 key 的其他产品线也一起进入未标记状态。

工程动作：四个不要，一个补记录

第一，不要在网关或代理层统一剥离响应头。自定义头最容易在 CDN、反向代理、SDK 封装里被丢掉。

第二，不要把 x-watermark 从日志 schema 里删掉。它是逐请求唯一确定的水印信号，丢了就无法回溯某段文本的状态。

第三，不要在关闭水印后继续沿用「未标记」的对外承诺。关闭是团队级、按模型的，任何一次配置回滚都会让承诺失效。

第四个「不要」是别把水印当内容鉴权手段。它证明的是「大概率出自某个模型」，不是「这段内容可信」。

反过来说，还有一件事要做：把水印状态写进数据血缘。哪一批数据来自标记状态为 true 的输出，应该能在数据集里查得到。

否则半年后做模型对比时，你只能凭日期去猜哪批样本跨过了 11 月 7 日这条线。这属于事后无法补救的那类记录缺失。

还没确认的五件事

Grok 应用与 X 是否同样默认标记，官方未公布。API 侧的变更不能直接外推到消费端产品。

水印在改写、翻译、摘要之后的稳健性，官方未给出阈值。统计水印的样本会被逐次改写消耗掉，但消耗到什么程度失效，没有公开数据。

客户通知邮件的具体内容，公开渠道未见原文。对已经上线的集成方，这决定了他们是否真的「被告知」。

「不影响质量与速度」目前是厂商自述。要证实它，需要同一模型在水印开、关两种状态下的对照评测，截至发稿没有看到第三方发布。

生成时的概率偏置是否影响格式合规率与拒答率，官方没有单独说明。对输出 schema 严格的业务，这一项比平均质量分更值得测。

这五件事不影响现在的动作。它们只影响一件事：别把「官方说」当成「已验证」。默认值可以马上适配，结论要等复现。

合规正在从「你要做什么」，变成「你默认得到了什么」。默认值就是新的合规条款，读它比读公告更有用。

参考来源：xAI 开发者文档 Output Watermarking、Santage 与 DeAI News 整理、EU AI Act 第 50 条。

延伸阅读：

• GPT-6 Cyber 被评为关键级：AI 发布开始分级
• 11 月大模型 API 价格表：9 个新价，最贵差 200 倍