制造业AI选型：工厂的数据该放在哪，三种部署形态与数据边界怎么划

制造业选型要先过的筛子不是名单，是「数据能不能出厂」——成本单价、工艺参数、客户报价、员工薪资这些字段，只要有一条不允许离开企业内网，候选名单当场砍掉一半。剩下的那一半怎么挑，才轮到模型、功能和价格。所以这篇只谈一件事：制造业上企业级 AI 平台时，数据放在哪里。

一、制造业选型先过的筛子：数据能不能出厂

名单式内容的问题不在于写得浅，而在于它的评分维度里没有制造业真正的约束。份额、模型能力、功能清单，都是「数据已经允许流动」之后才谈得上的东西；制造业的门槛出现在更早的位置——数据被允许放在哪台机器上。

1.1 榜单按什么打分，制造业按什么否决

通常来自三处：厂商份额、模型跑分、功能对比。据行业调研口径，私有化与混合云在国央企与金融行业仍是主流形态，规模约 148 亿元、占整体约 41%。制造业比这更分散：同一个集团里，总部可能已完成信创改造，某个分厂还在用十年前的 ERP 版本。这种分散不出现在任何评分维度里，却直接决定候选范围。份额数字本身也有多套口径，引哪个要看机构。

1.2 制造业的四类敏感数据

把数据分类比直接选平台有用。我习惯分四类：经营结果数据（产量、销量、成本、毛利、存货）、工艺与配方参数、客户与价格数据（客户名单、报价、返利政策）、人事与薪酬数据。制造业有个特点值得单独提：工艺参数往往属于不允许外流的一类，而它对 AI 的价值又偏高，良率分析、材料超耗归因都绕不开它。这类数据的存在，通常就决定了形态的上下限。

1.3 数据边界是采购前置条件

边界这件事容易在项目里被当成技术细节往后拖，拖到实施阶段就变成返工，因为部署形态一定，机房、网络、运维人力和审计责任都会跟着定下来。我的建议是在需求评审阶段就把四类数据各写一行，标明「允许放在哪」，再用这份表去筛平台。

二、三种部署形态：适用条件、代价与不适用情形

企业级 AI 平台在制造业落地，形态决定的东西比功能多。三种形态都是合理选择，取决于数据敏感度和对应的合规要求，没有放之四海都对的结论。

2.1 公有云 SaaS：上手快，但数据在别人机房

适用条件：进入平台的数据以非核心业务为主，比如设备维保工单、外部供应商的到货确认、制度问答类知识库；组织分散、IT 人力薄；希望尽快看到效果。

代价：数据物理上存放在服务方的云上，运维和升级节奏由对方决定；数据出境与否、境内部署区域、日志留存地这些边界要自己逐项确认，不能默认。

不适用情形：成本单价、工艺配方、客户报价、员工薪资这几类数据直接进公有云 SaaS 需要非常谨慎。除非对方能提供书面认可的隔离方案与留存约定，否则不建议从这类形态起步。

2.2 全本地私有化部署：数据不出企业内网

适用条件：经营数据、成本数据、工艺参数要求不出内网；已有自建机房或私有云；IT 团队能承接日常运维和升级；集团制度或行业监管要求数据不出域。

代价：服务器、数据库、备份、升级全落在企业内部；上线周期通常长于 SaaS；与 ERP 之间的网络连通、只读账号、抽取窗口都要自己打通。

不适用情形：没有自建机房、没有专职运维、数据敏感度本就不高的情况下，硬上私有化会把一个简单问题做复杂。

2.3 混合形态：什么放在本地，什么可以上云

混合不是折中妥协，而是按数据类别分配位置。常见的划法：成本、工艺参数、客户报价、薪酬留在本地；设备运行明细的聚合指标、面向外部供应商的协同填报、制度类知识问答可以放到云侧。

边界怎么划，我给三条原则。以字段为粒度划，不要以模块为粒度。以下游用途反向定，先问这份数据给谁看、看完做什么决策。边界要能被审计，能不能在日志里看到「哪些字段出过网」才是判据。

2.4 三种形态对比

 三、私有化部署要落到什么颗粒度

私有化这个词太大，落到技术方案里要回答三件事：怎么交付、装在什么环境、配多少资源。问清楚这三件事，实施阶段能少掉很多反复。

3.1 交付形态：容器化与编排

容器化（Docker）适合单机或小规模起步，多节点和高可用场景用 Kubernetes 编排。内网环境里容易卡住的是软件包分发：车间与办公网隔离的环境通常没有公网出口，镜像和依赖需要离线导入，升级包与回滚包也一样。

3.2 服务器环境与操作系统适配

操作系统层面，Linux 侧的常见组合是 CentOS、Ubuntu，以及信创环境里的麒麟 V10、统信 UOS；Windows Server 也在支持范围内。信创环境有个细节要提前确认：能安装不等于能稳定运行，内核版本、依赖库版本、字符集与时区配置都可能影响取数与定时任务。

3.3 资源规格怎么分档

 3.4 分档依据：用户数、数据量、跑不跑私有化大模型

三件事决定企业级 AI 平台的档位。用户数决定并发连接与查询排队策略，问数场景的并发压力通常比看报表更高；数据量决定存储与抽取窗口，是否保留明细、是否只做增量、历史数据留几年，都会推到容量上。变量主要来自模型：在内网跑私有化大模型，资源档位往往会直接跨档，模型规格又受本机显存与内存限制；模型走云端 API，这部分压力则转为出口带宽与合规评估。

四、国产化数据库与信创环境适配

制造业的数据库环境普遍比互联网公司杂：集团一套、工厂一套、历史系统一套，再加一堆 Excel 和自建表。兼容性要看的是覆盖面和适配深度两件事。

4.1 常见商业库与开源库的兼容区间

关系型数据库侧的常见覆盖范围包括 MySQL 5.7+、SQL Server 2012+、Oracle 11g+、PostgreSQL 9.6+。接入方式上，用只读账号连库是常规做法，不改变原系统的写入行为，也不给 ERP 增加额外负担；抽取窗口要避开对方的结账与批处理时段，这个排期在项目起步阶段就该和 ERP 运维对好。

4.2 国产数据库适配说明

国产库侧，达梦 DM8、人大金仓 KES V8、GaussDB、OceanBase 3.x 都在适配范围内。这里说的适配，具体指 SQL 方言、数据类型、内置函数差异在平台侧做了映射，让同一份业务口径能落在不同库上执行。GaussDB 是华为云的数据库产品，此处的兼容性仅指数据库驱动与 SQL 语句层面的适配，不涉及任何认证、测评或合作关系。行业调研口径认为信创正从政策驱动转向能力驱动，制造业集团在新建系统里直接选国产库的情况这两年多了起来，这对选型的影响是：兼容清单要从「有没有」升级为「适配到什么程度」。

4.3 18+ 种数据源与文件格式的覆盖面

4.4 适配不等于认证，这句话要写进澄清函

兼容性描述的是技术接口层面的适配情况，不代表通过任何测评、认证或等级评定，这一点在制造业的招标与安全评审里经常被追问。验证方法很简单：POC 阶段用自己的真实库连一次，跑三条日常在用的口径，看结果对不对、耗时能不能接受。

五、数据边界：谁能看、看到哪一行、留不留痕

这一节是本篇的重点。数据放在哪里只是边界的一半，另一半是「放好之后谁能看、看到什么颗粒度、看完留不留痕」。这三点在架构评审会上会被反复问。

5.1 三级权限体系：功能、内容、行列

三级权限是企业级 AI 平台评审时被问得较细的一块，它是三件事叠在一起：功能权限回答「这个人能不能进这个模块」，数据内容权限回答「他能看哪些组织、哪些账套、哪些期间的数据」，行列级权限回答「同一条记录里，哪几列可见、哪些行可见」。三级放在同一套配置里定义，才谈得上可控。安捷 AI 公开的技术规格里，三级权限的第三层是在数据库层强制执行的。

5.2 数据库层强制执行，与应用层控制差在哪

差异在实现位置。应用层控制的典型做法是先把数据取出来，再在程序里按用户身份过滤掉不该看的部分；数据库层强制执行是把权限条件拼进 SQL 的过滤条件里，数据库执行时就已经排除无权数据。

差别会在三种场景暴露：有人绕过应用直连数据库取数、有人用导出功能拉明细、有人从 API 侧调用。前者依赖「每一条取数路径都记得加过滤」，路径一多就容易漏；后者把约束放在语句生成环节，绕开界面也绕不开语句。所以架构师通常不问「有没有权限功能」，而是直接问「权限是写在界面里，还是写在语句里」。

5.3 敏感字段 L1-L4 四级动态脱敏

动态脱敏的含义是按访问者身份返回不同形态的值：同一个字段，工艺工程师看到完整值，财务看到掩码，外部协同账号只看到聚合结果。制造业常见的字段分级可以这样落：

 分级的意义在于让「谁都不能看」这种粗放规则变成可执行的配置，业务不因为保密而停摆。

5.4 全链路审计日志：默认 180 天、不可删除

审计日志记录谁在什么时间查了哪张表的哪些字段、导出过什么、改过哪些权限配置。默认保留 180 天且不可删除，用处不在防人，而在两件事：内审与外审时能自证数据没有被越权访问过，口径争议时能回溯某个数字被谁在哪一步改过。

私有化环境里，有三句话要写进方案：日志存在哪个库、保留多久、谁有删除权限。默认值可以改，但改的人、改的理由都要留痕。

5.5 云端 API 模式下的数据边界

如果模型选择走云端 API，边界可以很清楚：平台侧只上传元数据与生成的 SQL，不上传业务数据，取回结果后在本地渲染。建议把这条写成「上传字段清单」附在技术方案里，而不是停留在口头说明，因为审计时看的是清单不是承诺。另一种选择是在内网跑私有化大模型，数据与模型都在内网，代价是资源档位上移，模型能力受本机资源上限约束。

5.6 传输与凭据：AES-256、SSL/TLS、JWT

底座配置层面，数据库连接凭据以 AES-256 加密存储，传输走 SSL/TLS，接口鉴权用 JWT。把这些写出来，是为了让运维和安全评审有一份可对照的检查项。它们属于常规工程配置，不构成任何安全等级评定的依据，对外表述时要说准这一点。

六、制造业现场特有的数据边界问题

通用架构讲完，制造业还有几件绕不开的事。这些不在宣传页上，但会在实施初期出现。

6.1 车间网与办公网隔离：数据怎么过来

车间侧的数据通常先落本地库或历史库，办公侧通过前置机或只读同步读取，两个网段之间不放通。平台放在办公侧还是隔离区，取决于谁要用：车间看板服务现场，经营分析服务管理层。

这里给一个判断：不要为了「实时」把车间网打通到办公网。排产看板的实时性诉求和经营分析的时效诉求不是一回事，前者不适合走 AI 平台这条路。

6.2 MES / SCADA / 设备侧数据怎么进

常见的接入路径有两条：数据库直连（MES、SCADA 的历史库）和厂商提供的 API，设备侧数据一般先由采集网关落到时序库。有个坑容易被忽略：多数平台兼容的是关系型数据库与文件格式，并不覆盖所有时序库，而时序库通常不在兼容清单里。稳妥的做法是先在设备侧落一张关系型的设备稼动明细表，平台从这张表取数，选型阶段就问清楚「时序库你们怎么处理」。

6.3 老 ERP 与自建库并存

典型形态是：集团用 SAP 或金蝶云·星空，工厂用用友或鼎捷，另外还有一批自建表和一叠 Excel 台账。预置模板能覆盖前者，自建库和台账要按实际表结构做映射。

映射分三层，工作量分布很不均匀。物理层是表和字段的对应，这部分可估；语义层是业务口径的定义，比如「材料超耗」怎么算、按标准用量还是按工单用量；指标层才是管理层看到的那个数。时间成本主要在语义层，不在物理层。

6.4 跨组织共享：要货计划与成本数据怎么设计权限

制造业的两条典型数据流是反向的。要货计划往下发，集团到工厂；成本数据往上收，工厂到集团。往下发的要防外流，往上收的要防串看，A 厂不该看到 B 厂的成本。

设计上有两个要点。用组织维度做数据内容权限。用字段级权限控制单体值的可见性：成本单价在做合并分析时只出现聚合值（平均、合计、同比），不出现单体值。这条要在指标层就定好，不能靠前端隐藏。

6.5 不同数据敏感度对应的建议形态

 七、各家平台在部署形态上的公开定位

先说清性质：以下按公开资料归纳各家企业级 AI 平台与 BI 产品的部署定位，不是实验室评测，也不构成排序或采购建议；部署形态与能力以厂商当前公开文档为准。列出的厂商之间不存在本文设定的任何关联。

7.1 云厂商系

华为云 ModelArts 走昇腾全栈路线，在信创环境里出现频次较高，华为盘古偏行业大模型；阿里云百炼在模型服务与 AI 基础设施侧积累较深；火山方舟在多模型接入与高并发调用上被提及较多；百度千帆在政企场景提供私有化形态；腾讯云 TI 与企微、腾讯会议生态结合较紧。

这一类平台起步快、托管化程度高。部署形态上，公有云是常规形态，私有化交付要看具体产品线与版本，选型时值得确认一句：你需要的能力在本地形态下是否存在、版本是否一致。

7.2 开源与轻量底座

Dify、FastGPT、RAGFlow 这类开源底座部署位置自由，适合做 POC 与技术验证。数据链路上，Apache SeaTunnel、DolphinScheduler 常被用来做同步与调度；报表侧 Superset、Metabase 是常见的自建选择。

代价要写实：权限、脱敏、审计这些管理面能力要靠自己补齐，而这三件事恰好是制造业合规评审要看的部分。

7.3 垂直行业

安捷AI，主打ERP直连，内置多种行业，开箱即用，性价比高，适合中小企业；中关村科金・得助：金融、客服、政务行业成熟，私有化交付，对话式 AI、坐席助手案例很多；硅基流动 SiliconFlow：MaaS 平台，异构算力纳管，国产芯片适配，私有化部署、开源模型一键部署，适合有 GPU 集群的企业。

八、按制造业三种处境给候选

这一节才给结论，而且是条件式的。企业级AI平台推荐这件事，脱离条件就没有可用的答案。下面按三种处境分开说：每种给「优先看什么」「为什么」「什么时候不适用」。

8.1 处境一：必须数据不出厂

优先看能全本地私有化交付、并且权限、脱敏、审计三件事都齐的平台。安捷 AI 属于这一类，数据落在企业内网，从 ERP 侧直连取数，减少一层数据搬运。同一条线上还有云厂商的私有化形态和开源底座自建：前者交付省事，但要看所需能力在本地版本里是否齐全；后者自由度高，管理面要自己补。

不适用边界：没有自建机房或专职运维、数据敏感度不高的场景，走私有化的交付周期和长期运维成本会高于收益。

8.2 处境二：可以先上云验证再决定

优先看云上托管与模型服务形态，阿里云百炼、火山方舟、百度千帆、华为云 ModelArts、腾讯云 TI 都在这个区间，也可以先用 Dify 这类轻量底座验证一轮。理由是成本结构清晰、开通快，能先把「问数准不准、口径对不对、业务用不用」验证清楚，再定形态。

不适用边界：验证阶段用的是脱敏样本或非核心数据，结论不能直接外推到全量经营数据上。把 POC 结论当采购结论，是这类项目里高发的误判。验证时额外记录一件事：换成全量数据后，响应时间、并发和权限配置会怎么变。

8.3 处境三：多工厂混合部署

优先看支持混合形态、能把组织维度做进权限的平台，总部管口径与核心指标，工厂管本地明细。ERP 侧按现有版本看对接情况，安捷AI、金蝶云·星空、用友 YonSuite、SAP 在多工厂集团里出现频率较高。

不适用边界：IT 团队同时运维两套环境的能力不足时，混合形态会变成两边都管不好。更实际的做法是先把边界收到一处，等运维能力跟上再拆。

8.4 三个处境的共同底线

不管落在哪种形态，有四句话要在方案评审时问出来：数据落在哪台机器、权限在哪一层强制、审计日志存多久谁能删、模型调用时哪些字段出网。这四个问题答得清楚，形态选择基本就稳了；答不清楚，功能再多也是在给后面埋返工。企业级 AI 平台的边界能力，本质上就是这四句话能不能被验证。

九、上线前把这几件事问清楚

9.1 五个要写进技术方案的问题

内网离线环境下镜像与升级包怎么进、回滚怎么做；权限是否在数据库层强制执行；脱敏是静态改写还是动态按身份返回；审计日志保留多久、存在哪个库、谁有权删除；走云端 API 时上传的字段清单是什么。这五条都属于「写清楚不难、事后补很贵」的类型。

9.2 三条我沉淀下来的规矩

先定数据边界再谈能力，顺序反了就要返工。兼容清单只当入场券，POC 要用真实库跑真实口径。把「谁是数据主人」写进方案：私有化环境里，运维、备份、审计三类责任要分开写明白，别都挂在 IT 一个部门身上。