ai安全 技术与实战

很多团队一听到「AI 安全」就先想到买工具、上审计，但真出事时往往卡在不知道先查哪一步。这篇不铺概念，按技术方向分成几块：输入侧、输出侧、密钥与权限、日志与数据边界、供应链与中转，每块给判断标准和可照着做的动作，并说清哪些做法在什么情况下不成立。

很多团队一听到「AI 安全」就先想到买工具、上审计，但真出事时往往卡在不知道先查哪一步。见过一个五人小团队，Key 泄露后被刷了两天，第一反应是查模型有没有被越狱，其实真正的问题在资产侧。所以这篇不铺概念，按技术方向分成几块：输入侧、输出侧、密钥与权限、日志与数据边界、供应链与中转。

每块都会给判断标准和能照着做的动作，并说清哪些做法在什么情况下不成立。如果你的环境是纯离线内网实验，很多条目可以直接砍掉；但如果接了外部用户输入、接了第三方模型、或者输出会落到生产库，那就一条都别省。先明确你这次要防的到底是「钱被刷」「数据被带出」还是「输出不可信」，方向不同，手段完全不一样。

先把「AI 安全」拆成能干的活

安全需求按面向拆，比按技术名词拆好用得多。输入侧关心的是用户可控内容进模型时有没有获得不该有的指挥权；输出侧关心模型说的话能不能被信任使用；资产侧管 Key、账号、额度；数据侧管进出边界与留存；供应链侧管模型来源、中转与依赖。每一类对应的失败表现不同，别拿同一套手段硬套。

判断标准很简单：如果一个安全措施说不清它挡住哪种失败，那它多半只是心理安慰。不适用场景也要讲清楚，纯离线、无外网、无用户输入的内网实验环境，可以砍掉大半条目，把精力留给真正有外部暴露面的部分。

输入侧：用户可控内容怎么处理

输入侧的技术方向包括指令与数据分离、结构化输入、白名单工具调用、上下文清理与长度约束，核心是别让外部文本获得「指挥权」。实战里最常见的坑，是把用户原文直接拼进会触发工具调用的提示里，模型分不清哪句是指令哪句是数据。

1. 把系统指令与用户内容分开物理上放在不同字段，并显式标注边界，别用同一个字符串拼起来
2. 工具调用走参数校验不要让模型自由拼字符串去执行，工具参数要有类型、范围、白名单校验
3. 限制上下文内容与长度外部抓来的内容先进清理流程，再去拼接；清理规则要能验证，不能只是删几个关键词
4. 验证方式构造几条带指令的外部文本，看工具调用是否真的被拦住，拦不住就说明这层没生效

输出侧：模型说的话到底能不能信

输出要过三类关：格式校验看能不能解析，内容校验看有没有越界内容，事实校验看有没有依据来源。技术方向包括结构化输出约束、引用回链、二次校验模型、规则与正则兜底、人工抽检。关键在于把模型的输出当成「待审草稿」，而不是当成结论。

• 结构化输出约束：让模型按固定结构返回，解析失败就丢弃重试，别硬猜
• 引用回链：要求关键结论带上来源位置，便于人工和程序双向核对
• 二次校验：用规则或另一个模型做交叉检查，但别把校验也交给同一个模型
• 正则与规则兜底：对确定性的字段（编号、格式、枚举值）用规则卡，成本低且稳定
• 人工抽检：按比例抽查高风险输出，抽检记录本身也是证据

判断标准：凡是要直接落库、直接发给客户、直接触发交易的输出，都必须有非模型的校验环节。不适用场景：内部草稿、辅助检索这类低风险场景，可以只做格式校验，把成本省下来。

密钥与权限：把「能做什么」收窄

这一块的技术方向是最小权限、按用途拆 Key、按环境隔离、轮换与失效机制、用量上限与告警。听起来基础，但出事最多的就是这里。判断一个团队管没管住，看它能不能拿出一张四列齐全的表。

用途

这个 Key 具体服务于哪个功能，一句话说清

可访问范围

能调用哪些能力、访问哪些数据，越窄越好

负责人

出问题时第一个该找谁、谁能停用它

上次轮换时间

用来判断轮换节奏有没有真的在执行

判断标准：一个 Key 被多个服务、多个环境共用，或者没有用量上限，就属于没管住。不适用场景：个人本地调试可以简化，但别把调试 Key 带进生产代码或提交到仓库，这一步没有例外。

数据边界：东西到底发到哪了

数据边界的技术方向包括进出链路的资产盘点、字段级脱敏、日志与缓存留存的清理、第三方回传路径确认。光看架构图没用，得拿一条真实请求实际追一遍。

1. 选一条真实请求用带典型字段的真实样例，不要用构造的干净数据
2. 逐站追踪落点从用户输入一路追到模型服务商、日志系统、缓存、监控，看每一站落没落原文
3. 标注字段级差异哪些字段必须原文、哪些可以脱敏、哪些根本不需要传，逐字段标出来
4. 确认回传路径第三方有没有回传、回传到哪、留存多久，能问清就问清

判断标准：说不清某类字段在哪一站被记录，就等于没有边界；脱敏能降低但不能消除风险。不适用场景：数据本身已公开或不可回溯到个人的场景，可以减少脱敏层级。各家服务商的数据处理口径会变，具体条款到站内的资料库页面核对当时的版本，别照搬旧印象。

供应链与中转：别只信一个名字

供应链侧的技术方向包括来源核实、链路加密确认、能力与宣传是否一致、异常波动监测。中转和第三方通道尤其要小心，因为名字和实际能力之间经常有落差。

判断标准：关键业务不该把唯一通路压在一个说不清运营主体的中转上，至少留一条可切换的备份。想比较不同通道的实际表现，可以到站内的检测页面跑一遍再决定，具体结果以你实测时为准。不适用场景：非关键、可重试、结果只是参考的用途，容忍度可以高一些。

日志、告警与出事后的处置框架

技术方向包括日志脱敏与留存策略、异常用量告警、处置剧本、证据留存。这一块最容易被忽略，因为平时看不出问题，出事时才发现在手忙脚乱。

• 日志脱敏：写入前就该脱敏，别指望事后清理
• 留存策略：留多久、谁能查、过期怎么删，写成明文规则
• 异常告警：用量、失败率、异常调用模式都要有阈值，且要有人收
• 证据留存：处置过程中的操作记录同样是证据，按时间顺序留好
• 处置剧本：谁先做、按什么顺序，提前写成一张纸贴在显眼处

处置顺序建议是：先止损（堵住入口、停用凭据），再确认范围，再补证据，再对外沟通。判断标准：如果告警只在账单出问题后才响，那属于事后统计不是监控。不适用场景：小团队人手有限时可以只留一条关键告警，但要把处置顺序写下来，别只存在脑子里。

把上面这些排进你的排期

最后落到执行。先用一次自查把五类风险各打一个「有/无」标签，缺的那类优先补，别按技术时髦度排。第二步给每条措施配一个可验证的验收动作，比如「新 Key 只有单一用途」「输出落库前有一条非模型校验」。第三步定节奏：一次性的盘点、定期轮换、持续监控分开安排，混在一起做不完。

判断标准：三个月内没有任何一项被实际触发或复核，说明要么措施无效，要么根本没在跑。另外提醒一句，涉及具体服务商的能力和条款，别用一两年前的记忆做决策，到站内资料库和检测页面核对当时的数字和结论，再定要不要调整。