业务系统都在内网，AI 接入的争议常集中在"服务器放哪里"，但更关键的判断在别处：把"AI 入口—连接器—目标系统"三个位置和每一步经过的边界画清楚之前，选型结论都不成立。本文给出三位置核对方法、四类部署比较框架和五阶段验收清单，供 IT 团队做内网接入评估时直接对照。
先说结论：内网连接的核心不是把 ERP 或 MES 搬到云上，而是把现有系统中允许使用的业务能力，按员工身份与授权边界提供给 AI 工作入口。部署位置要服从数据流向、身份映射、原系统权限和运维边界；只说"支持私有化"或"支持云端"，回答不了"谁在哪个位置调用什么、结果从哪里回"这类实际问题。
三个位置先分清
- AI 工作入口：员工发起查询、分析与办理的地方，例如 WorkBuddy、DeepSeekHarness 或标准 MCP 客户端等已验证入口。
- AI 系统连接器：把业务能力发布为可授权能力（如 MCP Tool），并做身份、权限、审计控制的一层。
- 目标业务系统：ERP、MES、WMS、OA 等，业务事实、功能权限与数据权限的最终判断仍在这里。
三个位置可以同处企业网络，也可以分布在云端与内网。讨论"内网 MCP 服务"时，要明确 MCP Tool 在哪里发布、哪个员工能发现和调用它、连接器如何抵达目标系统、结果如何返回。选了本地部署不代表数据必然不出网；用了云端入口，也不代表要把整个业务数据库搬出去。
先画调用链，再谈部署
动手评估前，把一条完整调用链的核对清单画出来。以下 JSON 是配置/方法示例，字段按企业实际环境填写，不代表已上线配置：
{
"call_chain_checklist": {
"ai_entry": {
"location": "内网 | 云端 | 混合",
"verified_entries": ["WorkBuddy", "DeepSeekHarness", "标准MCP客户端"]
},
"connector": {
"location": "待评估",
"tool_publish": "哪个MCP Tool在此发布",
"visibility": "按员工/用户组/组织授权",
"audit_scope": "员工/系统/能力/时间/执行结果"
},
"target_system": {
"system": "ERP | MES | WMS | OA",
"access_method": "只读SQL | RESTful接口 | 业务页面",
"identity_mapping": "员工个人账号（非超级账号）",
"final_permission": "目标系统对功能与数据权限作最终判断",
"write_ops": "新增/修改/删除/审批默认人工确认"
},
"network_paths": {
"allowed_directions": [],
"forbidden_paths": [],
"failure_handling": "超时/断连时结果与重试规则"
}
}
}
这张清单的作用是把"技术可达"和"业务授权"拆开：连接器能访问某个接口，只证明通路存在；不同员工能看到什么范围，仍要由身份映射与目标系统数据权限决定。
四类部署怎么比较
| 方式 | 适合优先讨论的条件 | 要核对的问题 |
|---|---|---|
| 客户服务器或私有云本地部署 | 业务系统和主要使用入口均处企业网络，运维团队希望自行管理运行环境 | 计算资源、升级窗口、账号映射、备份及企业网络策略由谁负责 |
| 独立单租户部署 | 企业要求相对独立的运行边界，同时允许按评估方案与内网系统连接 | 租户边界、网络通路、运维职责和目标系统连接条件 |
| 多租户 SaaS | 企业网络政策允许相应业务能力接入，并希望减少自建运行环境工作 | 哪些数据和调用可以跨边界，员工身份如何映射，目标系统接口如何到达 |
| 混合部署 | AI 入口、连接器、业务系统分布在云端与企业内网，需要分别安排位置 | 每一段通路、故障切换、权限终判和审计归属是否清晰 |
传统做法只问"能否连通"和"服务器放哪里"；推荐做法先给业务场景画数据流与身份流，再确认目标系统权限终判、关键操作确认和审计。SaaS 不等于整体上传业务库，本地也不等于自动满足所有内控要求。
五阶段验收，不只验证"AI 回答了问题"
- 选一个可核查的问题：一类员工、一个业务结果、一组现有系统；写清预期答案由哪些字段支撑、谁负责判断结果正确性。
- 盘点系统与网络：标注数据流向、允许的网络通路、现有接口与原页面；与业务系统负责人确认可读字段、查询口径和异常返回；与安全及运维团队确认部署环境和运维责任。通路不允许就调整范围，不绕过原控制。
- 连接并发布能力：从只读 SQL、RESTful API 或业务页面选条件成熟的一项，定义输入、输出和业务语义，发布为可授权能力；返回结果保留来源、时间或可核查标识。
- 配置身份与授权：AI 用户关联到真实员工个人账号；按员工、用户组或组织配置能力授权，再用目标系统权限验证数据范围；测试同一问题由不同岗位发起时结果是否符合各自可见范围。
- 联调并业务验收：业务负责人核对结果，安全团队核对权限，流程负责人核对关键确认，运维团队核对审计与异常。至少测试无权限、目标系统超时、数据缺失和撤权后的调用。
一个常见反例：连接器能访问库存接口，却只能用一个公共账号查库存——技术上"拿到了数据"，业务上无法解释不同仓库管理员为何应看到不同范围。这是把"通路"当成"授权"的典型误判。
部署边界提醒
- 内网可达不等于业务授权：MCP Tool 可见性与目标系统的数据权限是两道判断。
- 不为方便接入共享高权限账号：员工身份映射和目标系统个人权限需要按场景联调。
- 查询场景的成功不等于写入场景的成功：新增、修改、删除和审批默认要求人工确认。
- 不承诺任意网络隔离条件都能直接打通：连接方向、边界策略和具体部署拓扑以项目评估为准。
关于产品侧：星云PLUS AI 系统连接器支持客户服务器或私有云、独立单租户、多租户 SaaS 和混合部署，支持针对内外网隔离条件设计项目方案；具体兼容范围以项目评估为准。本文的核对清单为方法示例，部署、接口与业务链路未验证前，不应写成已稳定运行或客户成果。
本文由星云PLUS团队整理。进一步了解接入与部署边界，可参阅产品白皮书：www.xingyunzuo.cn/resources/a…
