传统 ERP、CRM 和 OA 如何安全接入大模型？

很多企业已经稳定运行 ERP、CRM 和 OA 多年。这些系统保存着订单、客户、合同、审批、库存、财务和员工信息，也是企业日常经营的重要基础。

大模型可以帮助员工用自然语言查询数据、总结客户情况、提取单据、生成审批说明或编排跨系统任务。但安全接入绝不是把数据库账号交给模型，也不是在现有系统旁边增加一个可以读取全部数据的聊天框。

更稳妥的原则是：既有系统继续作为权威数据源和业务规则执行者，大模型负责理解、提取、生成与辅助判断；所有数据读取和业务动作都必须经过可控制、可验证、可审计的系统接口。

先明确：接入大模型需要实现什么能力

同样是“AI 升级”，技术边界可能完全不同。企业应先明确首期目标属于哪一类：

信息查询

例如：“这个客户最近三个月有哪些未完成订单？”“我的待审批事项有哪些？”系统需要识别用户意图，按原有权限查询业务系统，并组织成易读答案。

内容辅助

例如：总结客户沟通记录、生成跟进建议、提取合同字段、起草审批说明。大模型读取授权数据后形成草稿，用户确认后再使用。

流程建议

例如：根据订单、库存和历史规则提示异常，建议下一步处理人或审批路径。系统提供依据和建议，业务人员作出决定。

自动执行

例如：创建 CRM 跟进任务、生成采购申请、更新工单状态或发送通知。AI 会调用业务系统执行写操作，需要更严格的授权、校验、确认和回退。

首期项目通常应从信息查询和内容辅助开始。能够安全、稳定地“读”和“建议”，不等于已经具备自动“写”和“执行”的条件。

不建议采用的三种直接接入方式

1. 让模型直接连接生产数据库

模型如果能够自由生成并执行查询语句，可能造成越权读取、大范围数据暴露、性能冲击或误修改。数据库结构也会被深度暴露给模型和中间组件。

即使只开放只读账号，过大的表级权限仍可能让普通用户通过模型查询本来无权查看的数据。

2. 使用一个高权限公共账号访问所有系统

公共服务账号会抹去真实用户身份。系统难以判断发起人是谁、原本拥有什么权限，也难以追溯某次查询或操作的责任。

3. 先把全量数据复制到模型平台再做权限

把 ERP、CRM 和 OA 全量同步到一个统一索引或外部平台，可能扩大数据暴露面。若同步过程中丢失原系统的用户、部门、项目和字段权限，后续仅靠前端隐藏无法恢复真实边界。

正确思路不是让模型“拥有系统”，而是让模型在受控范围内“请求系统提供完成当前任务所需的信息或动作”。

推荐采用四层隔离架构

传统系统接入大模型，可以划分为四个相对独立的层次。

在这个架构中，大模型不保存业务系统的管理员密码，也不直接决定任意接口和参数。AI 编排层只能调用预先注册的业务工具，例如“查询本人待办”“读取授权客户摘要”“创建跟进任务草稿”。安全集成层负责把这些工具转换为受控 API 请求。

工业和信息化部的工业控制系统网络安全防护指南提出，对必要的远程服务采用安全接入代理，实施身份认证、应用鉴权、访问范围与授权时间限制，并留存审计日志。该指南针对工业控制系统，不能直接替代普通企业软件的安全设计，但其“系统边界、受控代理、身份鉴别、最小范围”的思路同样具有参考价值。来源：工业和信息化部《工业控制系统网络安全防护指南》

身份和权限必须继承原系统，而不是重新发明

员工通过 AI 查询 CRM 时，看到的范围不应超过他直接登录 CRM 时的权限。实现这一点，需要在每次请求中保留真实身份和权限上下文：

• 用户账号、员工编号和组织状态；
• 所属公司、部门、岗位和角色；
• 负责的客户、区域、项目或业务单元；
• 当前请求允许的读取、创建、修改或审批操作；
• 临时授权、授权期限和审批记录。

对于支持单点登录和标准授权协议的系统，可以传递用户身份或使用受控的委托授权；对于老旧系统，可以通过安全中间层建立身份映射，但不能让所有用户共享同一套无限制权限。

零信任架构强调，不应仅因用户位于企业内网或使用企业设备就自动信任；访问应围绕用户、设备和具体资源进行验证，并授予完成任务所需的最小权限。这一原则适合指导 AI 接入层的身份与权限设计。

数据最小化：模型只接触完成任务所需的信息

企业应按场景定义数据视图，而不是把整张业务表发送给模型。

例如，生成客户跟进摘要可能需要客户名称、联系人职务、最近沟通记录和未完成事项，但不一定需要身份证号、银行账户、完整合同价格或其他部门的备注。

建议建立三层控制：

1. 记录过滤：只查询用户有权访问的客户、订单、流程或项目。
2. 字段过滤：只返回当前任务所需字段，敏感字段默认不提供。
3. 内容处理：根据场景进行脱敏、截断、格式校验和敏感内容识别。

数据分类分级结果应能够落到接口和字段层。仅在制度中标注“敏感数据”，却让 AI 服务账号可以读取全部字段，无法形成实际保护。

政务领域大模型部署应用指引要求做好身份识别、权限管理、数据分类分级、来源追溯和运行日志，并防止敏感信息进入不适当的模型环境。该指引面向政务场景，企业需要结合自身行业与适用规则设计，但其全生命周期治理方法具有参考意义。来源：《政务领域人工智能大模型部署应用指引》

用“工具白名单”替代模型自由操作

大模型擅长理解自然语言，但不应自由决定如何访问数据库或调用任意接口。更安全的方式是由开发团队预先定义有限的工具：

每个工具都应明确：谁能调用、哪些参数允许传入、最大查询范围、是否涉及写操作、是否需要二次确认、超时与重试规则，以及失败后如何处理。

模型输出的参数不能直接信任。系统应使用类型、长度、格式、枚举、业务状态和权限规则进行二次校验，再决定是否调用真实接口。

读写分离，写操作默认需要确认

AI 接入可以按风险逐步开放：

第一阶段：只读查询

查询本人待办、客户摘要、订单状态、制度和知识资料。验证身份、权限、数据准确性和系统性能。

第二阶段：生成草稿

生成 CRM 跟进记录、OA 申请说明、邮件和任务建议，由用户修改并确认。

第三阶段：低风险写入

在用户明确确认后，创建待办、备注或草稿记录。设置操作白名单、幂等控制和撤销能力。

第四阶段：有条件自动执行

只在规则明确、风险较低、异常可识别的范围自动推进流程。关键审批、金额、合同和对外承诺继续由有权人员确认。

读取权限、建议权限、写入权限和审批权限必须分开。AI 可以帮助准备审批材料，但不应因为能读取流程就自动获得审批人的权限。

防范提示词注入和间接指令

传统系统接入大模型后，风险不只来自员工输入。客户邮件、合同、工单和网页内容中也可能包含恶意或误导性文字，例如要求模型忽略规则、泄露信息或调用工具。

这些外部内容应被视为业务数据，而不是系统指令。工程上可以采用：

• 区分系统规则、用户请求和外部资料的信任级别；
• 不允许检索到的文档直接修改工具权限；
• 工具调用前执行身份、参数和业务规则校验；
• 对敏感操作使用确定性规则和人工确认；
• 限制单次查询范围、调用次数和资源消耗；
• 识别异常指令、越权意图和批量探测；
• 对外部内容触发的操作保留完整证据。

《政务领域人工智能大模型部署应用指引》也提出识别并拦截提示词注入、资源消耗攻击，建立合理的拒答机制并开展日志审计。企业可以据此检查自己的输入、工具和异常处置链路，而不能只依赖模型自身拒绝恶意请求。

模型部署方式要与数据场景匹配

企业可以使用公共云 API、企业专有实例、私有化模型或混合架构。选择时需要核对：

• 数据发送到哪个区域和服务；
• 输入、输出和日志保存多久；
• 服务商是否会把企业数据用于训练；
• 是否支持关闭内容留存或配置专有数据边界；
• 传输和存储是否加密；
• 企业能否审计、导出和删除数据；
• 模型不可用时是否有降级方案；
• 供应商或模型切换时，业务接口是否需要重建。

并非所有敏感场景都必须从零私有化，也不是使用知名云服务就自动安全。应根据数据分类、任务风险、性能、成本和内部运维能力选择，并通过合同、配置和技术测试确认实际边界。

生成式 AI 风险管理资料指出，第三方生成式 AI 集成可能增加知识产权、数据隐私和信息安全风险，需要明确数据收集、使用与风险管理要求。

日志必须能够还原一次 AI 操作

普通应用日志记录“谁调用了哪个接口”还不够。AI 业务链路建议记录：

• 用户身份、角色和当时的授权状态；
• 用户请求及业务场景；
• AI 使用了哪些工具和参数；
• 查询了哪些业务对象和字段；
• 权限检查、规则校验和内容过滤结果；
• 模型、提示模板和工作流版本；
• 生成的建议、引用和置信或异常标记；
• 用户是否确认、修改或取消；
• 最终写入哪个系统、返回什么结果；
• 失败、重试、转人工和回退记录。

日志本身可能包含敏感数据，应设置访问权限、保存期限、脱敏和防篡改措施。审计目标是能够解释发生了什么、由谁发起、基于什么依据，以及最终产生了什么业务影响。

旧系统没有标准 API 怎么办

传统软件可能缺少现代接口。可以按风险优先级选择：

1. 使用厂商正式接口或扩展机制：优先选择，兼容性和业务规则通常更可控。
2. 建立只读数据视图或同步副本：用于查询和分析，避免模型直接访问生产表；需要处理同步延迟和字段权限。
3. 建设安全中间件：把老系统能力封装为受控服务，统一身份、参数校验、限流和日志。
4. 采用 RPA 处理少量界面操作：适合临时过渡，但界面变化容易导致失败，必须有状态校验和人工接管。
5. 评估系统升级或替换：如果核心系统接口封闭、维护停止且严重阻碍业务演进，继续叠加自动化可能增加长期风险。

不要为了快速演示，绕过系统规则直接修改数据库。这样可能破坏业务校验、事务一致性和厂商支持边界。

上线前需要完成哪些安全测试

身份与权限测试

• 不同部门、岗位和项目成员能否只看到授权数据；
• 调岗、离职和临时授权到期后是否及时回收；
• 服务账号是否超出当前工具所需权限；
• 用户是否能通过自然语言绕过原系统访问边界。

数据安全测试

• 敏感字段是否在查询、模型输入、日志和界面中正确处理；
• 批量查询、连续推断和数据导出是否受到限制；
• 第三方模型调用是否符合企业配置和合同约定；
• 缓存、历史会话和错误信息是否泄露数据。

工具与接口测试

• 模型生成非法参数时是否被拒绝；
• 重复请求是否会重复创建订单、任务或流程；
• 接口超时、部分成功和系统不可用时如何处理；
• 未经确认的写操作是否能够被阻断；
• 是否存在绕过 API 直接访问数据库的路径。

业务与回退测试

• AI 建议错误时，用户能否识别和修改；
• 执行失败后能否回到明确状态；
• 能否立即停用某个工具、模型或工作流；
• 关闭 AI 后，原有 ERP、CRM 和 OA 是否仍可独立运行。

“可关闭、可降级、可回退”是传统系统 AI 升级的重要安全目标。

一份安全接入检查清单

鑫宇科创的非侵入式升级路径

结合传统软件 AI 升级项目，可以按以下步骤推进：

1. 系统与权限盘点：梳理 ERP、CRM、OA 的数据、接口、账号、审批规则和现有安全边界。
2. 选择低风险切入点：优先从授权查询、摘要、字段提取和草稿生成开始，形成可验证的业务指标。
3. 建设安全集成层：用标准接口或安全中间件隔离模型与核心系统，落实身份映射、字段过滤、工具白名单和日志。
4. 逐步开放业务动作：先草稿、后确认写入，再根据质量和风险决定是否在有限范围自动执行。
5. 持续监测与回退：跟踪准确性、人工修改、越权尝试、接口失败和成本，保留随时关闭 AI 而不影响原系统运行的能力。

安全接入大模型的核心，不是把原有系统推倒重建，而是在保持核心系统稳定的前提下，为 AI 建立一条身份明确、权限受控、数据最小、操作可审计、异常可回退的通道。

如果企业已有 ERP、CRM 或 OA，却不确定哪些能力适合接入大模型，可以先通过传统软件 AI 升级进行系统接口、数据权限和业务流程评估，再选择非侵入式接入、局部定制或分阶段升级方案。