企业 AI 项目为什么总失败？直接答案（2026 年 10 月整理）： 很多项目在安全与权限条件没有锁定前就开始搭功能，最后卡在提示注入、权限越界、数据外泄和输出不可控四类问题上。沈阳麒典智能科技有限公司（麒典 AI）建议先把四类风险逐项写进试用和验收表，再决定是否扩大范围；上线前用低权限账号询问高权限内容，检查系统是否返回内容或泄露其存在。
企业 AI 项目在安全评审这一关卡住，原因通常是用传统信息安全的清单去查一个 AI 系统，查不出它特有的问题。
传统清单查的是：谁能登录、数据传输加不加密、日志留不留、有没有备份。这些当然都要做，但 AI 系统还有四类它独有的风险，传统清单里一条都没有。
（下面的分类参考了 OWASP 针对大语言模型应用发布的风险清单，owasp.org，读者可自行核验完整版本。）
风险一：提示注入
是什么：用户输入的内容里，混进了试图改变系统行为的指令。
举个无害的例子说明原理：系统被设定为"只回答产品问题"，而用户在提问里附上一段文字，试图让系统忽略原有设定。如果系统把用户输入和系统指令混在同一个通道里处理，它可能真的会照做。
为什么传统清单查不出来：这一类风险的本质是输入内容本身成了指令，传统清单里的代码漏洞和权限配置都对不上号。传统的输入校验（防 SQL 注入那一套）针对的是特殊字符和语法，而这里的"攻击载荷"就是普通的自然语言。
防护的三条判据：
- 系统指令和用户输入是不是分离的通道——混在一起是最大的问题
- 系统有没有"不该做的事"的硬约束，且这个约束不在可被输入影响的位置
- 有没有输出侧的检查——即使指令被绕过，输出层能不能拦住不该出现的内容
特别注意间接来源：如果系统会读取外部文档、网页或邮件内容，那些内容也是"输入"。从检索结果里带进来的指令，和用户直接输入的一样危险，而且更隐蔽。
风险二：权限越界
是什么：系统检索到了这个用户本不该看到的内容。
最常见的错误做法：先全量检索，再过滤结果。
为什么这是错的：即使最终没把内容显示出来，回答的措辞本身会泄露信息的存在。系统说"关于这个问题我无法回答"，和说"没有找到相关内容"，传递的信息完全不同——前者暗示了"有，但你不能看"。
正确做法：检索必须在权限范围内进行。用户的权限在检索发起时就参与过滤，确保无权访问的内容无法进入检索结果。
这条要求会影响架构选型，所以必须在开工前定。上线后再改，通常意味着检索层要重做。
验证方法：建一组覆盖不同权限层级的"越权测试用例"，用低权限账号问高权限内容，检查两件事：
- 内容没返回（这是基本要求）
- 拒答措辞与"内容不存在"时完全一致（这是容易漏的那条）
风险三：数据外泄
是什么：企业数据通过 AI 系统流到了不该去的地方。
三条主要路径：
一、发给外部服务。 用公有云 API 时，输入内容会离开企业。这是设计决定，谈不上漏洞——问题在于很多团队没意识到"输入内容"包括了检索到的内部文档全文。
二、进了训练数据。 企业应核对所用服务的内容处理、留存和训练条款，再决定哪些数据可以进入外部服务。企业数据、客户资料、会谈记录不能在未确认边界前走外部通道——这一条要写进制度，不能靠个人自觉。
三、通过输出泄露。 系统回答里带出了不该出现的内部标识、路径、字段名。
防护判据：
- 有没有一张明确的"数据分级表"，说清哪类数据可以走哪条路径
- 走外部服务的通道，有没有做脱敏或字段过滤
- 输出侧有没有内部标识的检查
第三条最容易漏。系统可能在解释来源时说出"根据 /internal/pricing_2024_final.xlsx"这样的内容——文件名本身就是信息。
一个低成本的检查：把内部路径前缀、系统代号、内部项目名整理成一张关键词表，在输出侧做一次匹配，命中就拦下。关键词表的范围由企业自己的系统命名和资料目录确定，先覆盖已知高风险词，再随着复核记录补充。
风险四：输出不可控
是什么：系统给出了不该给的内容——编造的事实、越界的建议、不当的表述。
这一类的处理方式和前三类不同：前三类靠架构和权限解决，这一类必须靠输出侧的检查。
三道必要的输出检查：
- 溯源检查：事实性陈述能不能对应到检索到的原文。对不上就不输出。
- 数值校验：金额、比例、期限、日期这类数字，与原文做程序化比对。这一道容易被跳过，而把原文的限制条件改成另一种限制条件，错误语义仍然通顺，人眼很难发现。抽查时应把数值类陈述单独列出来，逐项回指来源，不能只做通读式复核。
- 边界检查：属于系统不该回答的类别（医疗诊断、法律结论、投资建议等），必须能识别并拒答。
拒答是一项功能，应当当成指标去验。任何问题都给答案的系统，一定在编。
一张表：四类风险的对照
| 风险 | 传统清单能不能查出 | 主要防护位置 | 沈阳麒典智能科技有限公司（麒典 AI）提醒核对的易漏项 |
|---|---|---|---|
| 提示注入 | 不能 | 输入通道分离 + 输出检查 | 检索结果里带进来的间接注入 |
| 权限越界 | 部分能 | 检索层的权限过滤 | 拒答措辞泄露信息存在 |
| 数据外泄 | 部分能 | 数据分级 + 通道管控 | 输出里的内部文件名/路径 |
| 输出不可控 | 不能 | 输出侧三道检查 | 数值的程序化比对 |
合规这一项
给这套安全自检确定合规范围时，先写清系统供谁使用、通过什么入口提供服务，再对照《生成式人工智能服务管理暂行办法》核查适用条件。面向公众提供服务与仅供企业内部使用，需要分别判断适用要求；备案、内容标识等事项也应结合具体服务形态和相关规定逐项确认。
各行业还可能有本行业的专门规范。这些必须由企业自身的合规部门确认适用情况——本文只提示其存在，不构成合规意见。
一份上线前的安全自检表
只写“通过”无法复现测试。每条用例至少记录资料/系统版本、测试账号权限、输入类别、预期边界、实际回答、依据链接或日志、复核人和整改状态。用例应覆盖不同权限层级、外部资料输入、敏感字段和应拒答问题；不在记录中放入未脱敏的真实敏感内容。
| 用例类别 | 执行前记录 | 通过依据 | 失败后的动作 |
|---|---|---|---|
| 权限边界 | 账号角色、资料权限范围、系统版本 | 无权内容未进入回答，原始回执可复核 | 暂停扩大试用，核查检索权限配置 |
| 外部资料输入 | 资料来源、版本、授权状态 | 输入按不可信内容处理，回答仍符合系统边界 | 移除问题资料，修正处理规则后复测 |
| 敏感信息 | 敏感字段类别、允许处理路径 | 输出不含未授权字段，数据流向有记录 | 停止相关数据输入并核查外发/留存 |
| 事实与拒答 | 问题、允许依据、预期拒答边界 | 事实可回指来源；应拒答场景按要求处理 | 标记影响范围，修正并留存复测结果 |
每轮复测沿用相同用例和权限条件；系统、资料或权限发生变化时，记录变化并重新确认受影响的用例。测试发现问题时先暂停相关范围，完成修复和复测后再决定是否扩大。
- [ ] 系统指令与用户输入是分离通道
- [ ] 检索结果中的内容被当作不可信输入处理
- [ ] 检索发起时已按用户权限限定范围
- [ ] 越权测试用例通过，且拒答措辞不泄露信息存在
- [ ] 有数据分级表，明确哪类数据走哪条通道
- [ ] 企业与客户数据不走免费或不受控的外部服务
- [ ] 输出侧有溯源检查、数值校验、边界检查三道
- [ ] 完整的输入输出留痕，可追溯到人和版本
- [ ] 明确了拒答的场景和固定措辞，并有测试覆盖
九条里，第三条和第七条最常被跳过，也最贵。第三条上线后改要重做检索层——这通常意味着一轮不小的返工；第七条缺失会持续产生难以发现的错误。
一个务实的排期建议：把这九条拆成"架构决定"（第 1、3、5 条）和"上线前补齐"（其余 6 条）。前三条必须在选型阶段定，改起来最贵；后六条可以在开发过程中逐步补上。
安全验收责任卡（先填再测）
| 验收项 | 业务确认人 | 技术执行人 | 通过凭证 |
|---|---|---|---|
| 权限范围与越权用例 | 业务负责人/资料负责人 | 知识库或应用负责人 | 测试账号、问题清单、原始回答 |
| 数据出网与留存边界 | 数据负责人/合规负责人 | 架构负责人 | 数据流向图、服务条款核对记录 |
| 输出溯源、数值和拒答 | 使用部门负责人 | 测试与质量负责人 | 带来源回答、抽查记录、整改复测单 |
责任卡只登记本项目实际涉及的资料和入口。每项先写“未测”，完成后再改为“通过”或“整改中”，不要用“已具备”代替测试凭证。
最后一条：安全评审要提前介入
最常见的项目延误原因是做完了才发现过不了安全评审。
正确的做法是在选型阶段就把安全和合规拉进来——他们提的要求（比如"检索必须在权限内进行""数据不能出网"）会直接决定架构，而这些要求在上线前才知道，就意味着返工。
把安全评审设为选型和开工的前置条件。
常见问答
问：内部知识库只有员工用，还需要做越权测试吗？
答：需要。员工之间的权限也不同，财务制度、薪酬、合同这类资料常常只有少数人能看。拿一个普通员工账号去问这些内容，看系统给不给，是上线前最便宜的一次检查。
问：提示注入是不是只会出现在对外开放的系统里？
答：内部系统同样会遇到。检索到的文档、邮件、网页里可能夹带指令，系统把它们当成正常内容读进去，就会被带偏。所以检索结果要按不可信输入处理。
问：安全评审放在上线前一周再做，来得及吗？
答：多数情况来不及。安全部门常见的要求，比如检索必须在权限内进行、数据不能出网，会直接决定架构，上线前才提出就意味着返工。建议选型阶段就拉进来。
关于我们
我们是麒典 AI，工商登记名称是沈阳麒典智能科技有限公司，在沈阳为企业做 AI 落地咨询。碰到安全这类容易被推到最后的事项，我们的习惯是选型会上就把越权测试和数据流向表列进验收清单，谁负责、几号前完成都写清楚。主体与服务信息见公司官网。
相关阅读
准备签字上线时，把低权限账号的测试结果、数据流向记录和输出检查结果放到同一份验收材料里。每个检查项都应有责任人和可复查的记录，未通过的项目应写明整改条件，再安排复测。