AI 接入业务系统之后，企业真正要过的是这三道门

假设 AI 只是把退款政策答错，你大不了重新问一次；但当它已经连接订单系统，并把 5 万元退款打给错误账户时，问题就不再是“模型产生了幻觉”。

企业首先要回答三个更现实的问题：

它使用谁的账号完成了操作？
谁允许它调用退款接口？
如果钱无法追回，最终由谁承担责任？

过去，企业评估 AI，重点是回答是否准确、生成内容是否流畅。现在，随着 RAG、连接器、MCP 和 AI Agent 开始接入 CRM、ERP、财务、客服与代码仓库，竞争焦点正在发生变化：

企业 AI 真正进入业务系统后，关键不再只是“模型能不能回答”，而是“它以谁的身份访问数据、做过什么操作，以及出错后由谁负责”。

这不是给 AI“增加几个安全设置”，而是决定它有没有资格进入核心业务。

一、聊天框只是入口，真正的分水岭是能不能动业务数据

一个没有接入企业系统的 AI，本质上仍是内容工具：总结文档、润色邮件、生成方案。即使答错了，损失通常停留在信息层面。

一旦接入业务系统，风险会沿着一条清晰的阶梯上升：

以客服场景为例：

1. 只读型：知识库助手读取内部制度，回答员工“年假如何计算”。

2. 建议型：客服 AI 查询订单和退款政策，生成处理建议，由员工确认。

3. 执行型：AI 直接修改订单状态、创建退款单，甚至调用支付接口。

三者看起来都叫“客服 AI”，但治理要求完全不同。

API、插件、RAG、MCP 和系统连接器解决的只是能不能连上。企业真正关心的是：

连上之后能看到什么？
能调用哪些工具？
哪些动作必须经过批准？
出错之后能不能撤销？

如果说模型是大脑，那么连接器只是手脚。企业不能因为“手脚能动了”，就默认它拥有开保险柜的权限。

二、第一道门槛：AI 到底以谁的身份工作

企业 AI 常见的身份模式大致有三种。

1. 共用系统账号

所有 AI 请求都使用同一个后台账号，甚至共享一个高权限 API Key。

这种方式开发最快，也最危险。系统可能只知道“AI 服务调用了接口”，却不知道背后是哪名员工发起请求。一旦密钥泄露，攻击者还可能绕开前端，直接调用业务接口。

更麻烦的是，共用账号容易让 AI 获得超出实际需要的权限：为了让一个流程跑通，开发人员常常直接配置管理员权限，结果“查询订单”的助手同时拥有“删除订单”和“导出全部客户”的能力。

2. 继承用户权限

AI 代表当前用户访问系统，员工看不到的数据，AI 原则上也看不到。

Microsoft 公开说明，Microsoft 365 Copilot 会在用户现有权限范围内访问组织内容。这类设计能减少权限穿透，但也暴露出另一个问题：AI 会放大企业原有的权限混乱。

一份文件如果本来就被错误地开放给全员，过去可能没人知道它存在；AI 接入后，相关内容可能在检索中被迅速找到并总结出来。

3. 独立机器身份或服务账号

企业为 AI Agent 建立独立身份，只授予完成特定任务所需的权限。例如：

只能读取订单状态，不能导出完整客户档案；
可以创建退款申请，不能直接完成退款；
可以修改 CRM 跟进状态，不能删除客户；
凭证短期有效，并按周期轮换。

这是更适合生产系统的方式，但前提是企业真正落实最小权限原则。

身份认证不等于业务授权

这两个概念经常被混在一起。

身份认证回答的是：你是谁？
业务授权回答的是：你可以对哪个对象执行什么操作？

一个客服 AI 即使通过了身份认证，也不代表它可以查看完整身份证号；即使能够调用退款 API，也不代表它可以处理任意金额、任意账户的退款。

生产系统通常需要组合使用：

OAuth：通过范围受限的令牌进行委托访问；
RBAC：根据客服、财务、管理员等角色分配权限；
ABAC：根据金额、地区、数据级别和订单状态动态判断；
短期凭证与凭证轮换：降低长期密钥泄露的影响；
二次确认：对付款、删除、批量导出等高风险操作增加审批。

下面这个伪代码展示了一个基本原则：模型可以提出调用工具，但不能独自决定高风险操作是否执行。

def execute_refund(user, order, amount):
check_identity(user)
check_permission(user, action="refund", resource=order)

audit_log.write({
"user_id": user.id,
"order_id": order.id,
"amount": amount,
"action": "refund_requested"
})

if amount > 1000:
return request_human_approval(
approver_role="finance_manager",
payload={
"order_id": order.id,
"amount": amount
}
)

return refund_api.execute(order.id, amount)

这里的 1000 只是演示用阈值，不代表任何行业标准。真实生产环境还需要考虑订单归属、退款原因、账户一致性、反欺诈规则、并发控制和接口幂等性。

AWS 在 Amazon Bedrock Agents 中提供的 return control 机制，就是一种值得参考的设计：Agent 可以识别需要调用的动作及参数，但把控制权返回给应用，由业务系统决定是否真正执行。技术重点不在厂商名称，而在于把“模型建议”和“业务执行”分开。

三、第二道门槛：每一次检索、判断和执行都必须可追溯

传统应用日志往往只记录：

某个账号在某个时间调用了退款接口。

这对 AI 来说远远不够。企业还需要知道：

谁向 AI 提出了请求？
使用的是哪个模型及版本？
AI 检索了哪些文件和业务记录？
调用了什么工具，参数是什么？
权限策略如何判断？
是否经过人工审批？
最终修改了什么，执行是否成功？

只保存聊天记录，并不能形成完整证据链。

一条结构化审计记录可以类似这样：

{
"request_id": "req_2025_xxx",
"user_id": "employee_1024",
"agent_id": "customer_service_agent",
"model_version": "model-v3",
"data_sources": [
"order_8831",
"refund_policy_v7"
],
"tool": "refund_api",
"risk_level": "high",
"approval_status": "approved",
"final_result": "refund_completed"
}

以上代码和日志仅用于展示治理思路，不代表完整的生产安全实现。

值得注意的是，“可解释”不等于保存模型全部内部推理过程。更稳妥的做法，是记录可验证的证据与决策依据，例如引用的数据来源、命中的业务规则、权限判断结果和审批记录，而不是把不可控的自由文本推理当成审计结论。

日志同样不是越多越好。提示词、上下文和工具参数中可能包含个人信息、商业秘密乃至访问凭证，因此还必须设置：

字段脱敏与敏感信息过滤；
日志访问权限；
分类保存期限；
防篡改或追加写入机制；
日志导出与异常访问告警。

中国《网络安全法》第二十一条提出网络日志留存不少于六个月等要求；《数据安全法》第二十七条强调建立全流程数据安全管理制度；《个人信息保护法》第五十一条要求采取分类管理、加密、去标识化、合理确定操作权限等措施。

这些规定不会替企业自动设计一套 AI 审计系统，但它们传递了同一个信号：只要 AI 开始处理真实业务数据，访问控制和安全责任就不能停留在口头承诺上。

四、第三道门槛：AI 出错之后，责任不能推给模型

“这是模型幻觉”可以解释技术原因，却不能回答责任问题。

不同任务的后果并不在同一量级：

AI 写错一段营销文案，可以修改后重新发布；
AI 给出错误退款建议，可能引发客诉，需要员工复核；
AI 自动修改合同、创建采购单或触发付款，可能造成法律和财务后果。

因此，企业必须在上线之前明确责任矩阵。

这也是为什么“人在回路”不能只是界面上放一个确认按钮。

如果审批人只看到一句“是否同意退款”，却看不到订单、收款账户、退款金额、政策依据和 AI 修改的字段，那么这个按钮更像是在转移责任，而不是控制风险。

有效的人工审批至少应展示：

1. 操作对象与影响范围；

2. 数据来源和引用依据；

3. AI 准备调用的工具及参数；

4. 与原始记录相比发生了哪些改动；

5. 风险提示及撤销方式。

企业还可以按照后果进行分级：

低风险任务：允许自动完成，例如内部资料分类、公开内容摘要。
中风险任务：AI 生成建议，员工复核后执行，例如客服退款建议。
高风险任务：AI 只能辅助判断，或必须双重审批，例如付款、合同变更、批量删除和权限授予。

《生成式人工智能服务管理暂行办法》主要适用于在中国境内向公众提供生成式人工智能服务。企业内部研发和使用、且不向境内公众提供服务的情形，不能简单照搬其全部适用逻辑。

但“不直接适用某项面向公众的规定”，也不意味着内部 AI 没有约束。个人信息、数据安全、网络安全、合同责任与行业监管仍然需要分别判断。

五、企业 AI 的下一张入场券，是治理能力

NIST 于 2023 年发布的 AI Risk Management Framework 1.0，将治理、识别、衡量和管理概括为 Govern、Map、Measure、Manage 四类核心职能。ISO/IEC 42001:2023 则从管理体系角度强调组织职责、风险管理、运行控制与持续改进。

它们共同说明了一件事：AI 治理不是上线前做一次安全评审，而是一套持续运行的管理机制。

企业在采购、开发和验收 AI 系统时，可以直接提出以下问题：

AI 是否拥有独立、可识别的身份？
是否遵循最小权限，而不是共用管理员账号？
能否限制到具体数据、字段、动作和金额？
凭证是否短期有效并支持轮换？
是否记录用户、模型、数据来源、工具参数和执行结果？
高风险操作是否需要人工或双重审批？
审批人能否看到完整依据与改动内容？
错误操作能否暂停、撤销或回滚？
模型或策略变更后，是否需要重新评估？
事故发生时，负责人和处置流程是否已经确定？

未来企业比较 AI 产品时，不会只盯着模型榜单和回答效果，还会比较权限粒度、审计能力、部署边界、故障回滚与责任机制。

治理不是为了阻止 AI 做事，恰恰相反，它是为了让 AI 有资格做更重要的事。

企业 AI 的成熟标志，不是它越来越像人，而是企业能够像管理一个员工和一套生产系统那样管理它。

如果你正在搭建企业知识库、客服助手或内部自动化工具，建议先从只读、低权限、可记录的 API 调用开始，验证模型效果与调用链路，再逐步开放写入和执行权限。

可以前往 api.884819.xyz 查看 API 接入方式，为原型选择合适的模型。平台使用用户名和密码即可注册，不需要邮箱验证；没有月租和订阅，按量付费，国产模型如 Deepseek、千问等可免费使用，并内置 AI 对话功能。需要强调的是，模型 API 解决的是能力接入，正式连接企业业务系统前，仍需自行补充身份认证、权限控制、日志审计和人工审批机制。

新用户注册即送体验token。

当权限、审计和责任框架建立之后，下一个更棘手的问题是：企业究竟应该让 AI 自动执行到哪一步？下一篇我们将拆解 AI Agent 的风险分级方法——哪些任务可以全自动，哪些必须人工确认，以及那个常被滥用的“人在回路”，为什么有时只是责任转移。

本文由8848AI原创，转载请注明出处。关注8848AI，带你从零开始学AI。

#企业AI #AIAgent #AI治理 #数据安全 #人工智能 #8848AI #AI教程