ai 智能安全风险可能表现为哪些问题

很多团队做安全评审时卡在同一句话上：知道有风险，但不知道风险长什么样，于是清单写成了一堆形容词。这篇换个入口，先不讨论威胁分类，而是从你每天能看到的输出、日志、账单、工单里，把「智能安全风险可能表现为哪些问题」还原成可观察的现象，再按现象分流到对应的排查动作。适合产品、测试和刚接安全职责的研发一起过一遍。

很多团队做安全评审时卡在同一句话上：知道有风险，但不知道风险长什么样，于是清单写成了一堆形容词——「模型不听话」「可能被绕过」「数据有风险」。这种清单交上去，研发不知道改哪一行，测试不知道写什么用例。换个入口：先不讨论威胁分类，而是从你每天能看到的输出、日志、账单、工单里，把智能安全风险还原成能观察到的现象。

所谓「现象」，是指第三方照着你的步骤能复现出来的东西。同一段提示词在两个账号下给出不同结论，是现象；工具调用返回了预期外的字段，是现象；用户原文出现在外部日志里，是现象。「模型不安全」不是现象，是结论。这篇就按「先分现象、再查链路、最后记录交接」的顺序走一遍，产品、测试和刚接安全职责的研发可以一起过。

先分清：哪些是「现象」，哪些是「解释」

评审会上最容易吵起来的就是这一层。有人拿一张截图说「你看它乱答」，另一个人说「这是偶发」。判断标准其实很硬：能不能被第三方复现。复现不了的东西只能记为观察项，不能进风险清单，否则下次评审还得重新吵一遍。

输出内容越界

回答里出现了本不该对外的内容，比如内部代号、未公开配置、其他用户的上下文

动作越权

模型调用了不该调的工具或接口，或者调用参数超出了当前用户权限范围

数据流向异常

本该留在内网的内容出现在外部日志、第三方埋点或错误上报里

交互话术漂移

同一问题在不同时段、不同账号下口径不一致，像是换了个脑子

排查的起点是时间戳和请求标识，不是截图。没有可回溯的请求 ID，后面切变量、查链路都做不了，只能靠人肉回忆，效率低还容易互相甩锅。

一张现象对照表：看到什么，先查什么

下面这张表的作用是分流，不是定责。看到某一类现象，先按对应方向查第一层，别一上来就怀疑模型本身——多数问题出在拼接、权限和日志上。

话术漂移这类问题的判定逻辑，可以借鉴站内模型对比检测的文章思路：同一批提示词、同一时段、多次跑，看差异是跟着模型走还是跟着节点走。想把不同渠道的响应稳定性放在一起比，可以到 /tools/speed-test 核对当时的数字，别凭感觉下结论。

排查顺序：从近到远，从便宜到贵

顺序错了会浪费很多时间。最常见的是现象还没复现，就先讨论要不要加一层防护，结果防护加上去，现象被盖住了，下个月换个入口又来一次，谁也不知道当初到底修了什么。

1. 第一步：固定变量同一提示词、同一账号、同一时段连跑三遍，先确认是否稳定复现。复现不了的记为观察项，不进本次修复范围。
2. 第二步：切一层只改提示词不改模型，只改模型不改提示词，各跑一轮，看现象跟着谁走。跟着谁走，问题就大概率在谁那一层。
3. 第三步：查链路从入口到出口按顺序看请求日志、工具调用记录、输出过滤记录，找出在哪一环丢的约束。这一步要带着请求 ID 走。
4. 第四步：加防护到这一步再加过滤、加权限、加审计。在没定位到环节之前加防护，通常只是把现象盖住。

• 复查节奏按周而不是按天，单日波动容易被误判成恶化
• 每次只改一个变量，改两个以上的结果是没法归因的
• 工具调用记录要连参数一起留，只留工具名看不出越权
• 输出过滤记录和原始输出分开存，混在一起没法判断是模型输出还是过滤后结果
• 站内关于站点波动的对照测试方法可以参考，思路是一样的

把现象记成能交接的东西

安全排查最怕的是「只有当时那个人知道」。轮到交接或者加班换人，全部重来一遍。解决办法不复杂：把现象记成固定的四件套，谁拿到都能接着往下走。

• 复现步骤：从哪个入口、用什么账号、按什么顺序操作
• 原始输入：用户原文和系统提示词分开记录
• 原始输出：未经过滤的模型输出，以及过滤后的返回内容
• 时间与请求标识：时间戳、请求 ID、所在的节点或版本标识

结论部分写「观察到什么」，不要写「我认为是什么」。判断和事实分两栏写，复核的人可以推翻判断，但事实要保留下来。这样下次同类现象出现时，才有可以对照的历史记录。