很多企业已经运行多年的 ERP、CRM、OA 或行业系统，数据和流程都在其中。为了增加AI能力直接重写整个系统，风险通常大于收益。更现实的做法是保留核心交易和权限规则，在边界清晰的接口层逐步接入AI。
路径一：增加统一搜索和知识问答
如果用户主要问题是“找不到资料”和“不会用系统”，可以先建设跨文档与业务说明的搜索。它不直接修改业务数据，风险相对较低，适合成为首个验证场景。
实施前需要确认旧系统是否能提供可用的文档、帮助信息和只读查询接口，并把原权限映射到检索层。
路径二：增加摘要、分类与信息提取
工单、项目记录、合同附件、巡检说明和客户沟通中包含大量非结构化文字。模型可以辅助生成摘要、建议分类或提取字段，再由用户确认后写入原系统。
这种“模型建议、人工确认”的方式保留了确定性校验，适合在准确率尚未稳定时灰度使用。
路径三：提供自然语言查询入口
用户可以用自然语言表达查询意图，由中间层转换成受控参数，再调用原系统查询接口。这里不应让模型直接生成并执行任意 SQL，而应使用预先定义的工具和参数白名单。
查询结果还需要经过字段权限、数据范围和脱敏规则处理，确保自然语言入口不会绕过原有控制。
路径四：用Agent编排跨系统任务
当一个任务需要查询多个系统、生成文档并通知相关人员时，可以使用智能体编排工具调用。但每个工具必须定义输入、输出、权限、超时、重试和回滚方式。
涉及付款、合同、审批结果、账号权限等高风险操作时，应保留人工确认或原系统审批，不能只依赖模型判断。
改造前先回答五个问题
- 原系统是否有稳定接口，还是只能直接访问数据库？
- 用户与数据权限如何同步？
- 哪些操作只读，哪些会改变业务状态？
- 出错后如何撤销、回退或转人工？
- 如何记录模型输入、工具调用与最终结果？
分阶段实施建议
先从只读、低风险、高频的任务开始，建立评测和使用反馈。第二阶段再增加需要用户确认的写入动作，最后才考虑跨系统自动化。每次扩展都应重新检查权限、成本、延迟和失败处理。
旧系统AI改造的价值在于复用已经稳定的业务资产，而不是用一个聊天页面掩盖系统问题。接口、权限和数据质量仍然是项目的基础。