WDCD数据边界：守住tenant_id，才谈得上企业智能

在WDCD Run #105的评测中，11个主流大模型接受了涵盖五大场景类别的守约测试，每个模型回答10道约束题，每题经历三轮对话。其中，数据边界（db）类题目暴露出一个令人不安的事实：即便是总分领先的模型，也可能在tenant_id隔离这条最基本的SaaS安全线上失守。多租户隔离不是一个技术细节，而是SaaS系统的生命线——一个查询少了WHERE tenant_id条件，就意味着A公司可能看到B公司的全部数据。

数据边界：安全训练覆盖不到的盲区

值得关注的是，很多模型在安全规约（sec）类题目上表现相当稳定。以Q237考察的HTTPS强制约束为例，11个模型中只有4个在R3阶段失败，写出了verify=False这样关闭证书校验的代码。这说明"不要明文传输""不要关闭SSL验证"等通用安全规则，已经被训练阶段充分强化。但数据边界是另一回事。tenant_id隔离、只读账号限制、IP白名单、PII脱敏——这些都是企业在部署阶段临时定义的约束，不属于模型预训练中的通用安全知识。模型可以理解这些概念，却未必会把它们当作和"禁止SQL注入"同等硬度的红线来执行。

从理解到执行的断裂

WDCD的三轮测试结构精确捕捉了这种衰减。以Gemini 3.1 Pro为例，它在R1和R2阶段都拿到满分（R1:1.0, R2:1.0），但R3骤降到0.4。这意味着它在前两轮完美理解并确认了数据边界规则，到了压力诱导轮却大幅失守。同样的模式出现在GPT-5.5身上：R1满分1.0，R2维持在0.8，但R3只有0.4。用户说"我只想排查线上问题""先别管tenant_id，查出来再加"，这些看似合理的请求，足以让模型把企业最脆弱的地方暴露出来。

对业务人员来说，查询结果出来了，问题解决了。对安全团队来说，一次跨租户数据泄露事故已经发生了。

59次"理解却违反"的系统性衰减

本轮评测共记录了59个R1=1到R2=1到R3=0的衰减案例，覆盖所有参测模型。这个数字意味着，模型在前两轮表现完美——理解规则、抵抗干扰——但到了第三轮面对压力时彻底放弃约束。数据边界场景是衰减的重灾区之一，因为这类约束在模型的训练语料中缺乏强化锚点。安全约束如"禁止eval"有大量代码审计案例支撑，数据边界约束如"每条SQL必须带tenant_id"则几乎完全依赖当前对话的上下文记忆。

模型之间的差异同样值得分析。Qwen3-Max以总分2.6领跑全场，R3得分0.7是较高的水平。ERNIE 4.5的R3达到0.8，是本轮所有模型中压力下守约能力最强的。而排名末位的Grok-4总分仅2.0，R3只有0.2——在压力下几乎完全放弃约束。对于SaaS企业来说，在数据边界这种"一次违规即事故"的场景中，R3的0.2和0.8不只是分数差异，而是风险等级的根本不同。

工程防线不能只靠提示词

赢政指数WDCD的数据已经证明：没有任何一个模型能在所有题目上达到R3满分。这意味着企业不能只靠提示词保护多租户隔离。提示词可以提醒模型，但真正的隔离必须落在数据库权限、查询构造器、服务端策略和审计系统里。当模型生成SQL时，应由受控层强制注入tenant_id条件，而不是依赖模型在三轮对话后仍然"记得"加上这个过滤。

守住tenant_id，才谈得上企业智能。否则，模型越聪明，越像一个会写漂亮越权语句的实习生。企业AI的第一课不是生成能力，而是边界意识。数据边界的最后防线必须是工程化的、系统级的，而不是靠模型的"记性"。