【轨物方案】制造企业上 AI，数据安全不能只靠一句“我们很安全”
制造企业讨论 AI 时，常常出现一种矛盾：业务部门希望 AI 能看懂图纸、查询历史报价、关联材料价格和工时，帮助员工更快完成分析；信息部门却担心，接入这些能力就意味着把核心数据复制到外部，甚至让模型接触到不该外流的技术和经营信息。
这种顾虑并不是对新技术的排斥，而是制造企业必须承担的责任。图纸、BOM、工艺参数、报价策略、供应商价格和客户条件，可能直接关系到企业的竞争优势。任何 AI 方案如果只强调功能，却不能清楚说明数据从哪里来、经过哪里、被谁访问、是否留下副本，就很难进入关键业务。
所以，企业需要的不是一句“数据安全有保障”，而是一套能够被信息部门、业务负责人和审计人员共同检查的边界规则。
企业在建设 AI 能力前，应先把数据分层。哪些数据属于一般内部资料，哪些涉及客户或供应商，哪些包含核心图纸、成本和工艺机密？哪些内容允许在本地环境内被模型处理？哪些外部服务绝对不能访问？哪些场景需要脱敏或经过额外审批？
如果这些问题没有先明确，后续即使选择了本地模型，也不代表整个链路天然安全。数据可能在接入、解析、日志、缓存、备份、运维或异常排查过程中产生额外副本；权限配置也可能因为系统之间规则不一致而扩大访问范围。
因此，数据出网策略应该形成清单，由企业信息岗或授权负责人确认，并落实到技术配置和操作流程中。默认敏感数据留在企业内部；哪些内容允许使用云端能力，必须逐项明确，而不是由项目团队临时判断。
T-HUB 采用的设计思路，是在企业授权范围内只读访问现有系统，按业务问题读取所需信息，再进行关联和分析，而不是一开始就要求企业把所有数据集中复制到一个新平台。
这与“先把所有数据搬出来，再想办法利用”的路径不同。对企业来说，减少不必要的数据复制，可以降低多份数据长期存在带来的权限、同步、留存和销毁管理压力，也能避免知识底座变成又一个需要独立维护的大型数据仓库。
但“取数不入湖”不应被理解为所有数据在任何情况下都绝不落地。实际系统可能需要保存必要的索引、解析结果、业务规则、审计日志，某些历史分析也可能需要只读镜像。关键是把不同对象区分清楚：哪些是原始业务数据，哪些是索引或元数据，哪些是经验规则，哪些是临时计算结果；它们分别保存在哪里、保存多久、由谁管理。
对于确实需要全量历史比对的场景，应在企业书面授权后实施只读镜像，并明确镜像归企业所有、访问范围和删除机制。真正的安全不是回避技术细节，而是让每一种数据处理行为都有明确的理由和责任人。
第一条，不改业务系统。T-HUB 的目标不是替换 ERP、PLM、MES 或 OA，而是在既有业务系统旁边建立受控的只读访问能力。原系统继续承担正式业务流程，知识底座不应擅自修改源数据或绕开原有审批。
第二条，不写回业务数据。只读接入应在技术层面限制写入能力，而不仅仅依赖操作人员“承诺不会改”。对于报价、成本、设计和生产数据，AI 可以提供资料、提示差异、组织证据，但不能在未经授权的情况下把推断结果直接写回正式业务记录。
第三条，不留未经授权的副本。交叉查询按需取数、用完即弃是设计原则；确有必要保留的内容，应有明确的数据类型、保存目的、期限、授权和审计要求。合同、技术方案和验收记录应对这些内容作出可验证的约定。
第四条，关键业务不做无人负责的全自动决策。报价最终由谁签字、设计变更由谁批准、异常结果由谁复核，必须沿用或明确企业的责任体系。AI 的作用是提高信息组织和核查效率，而不是把责任模糊地转移给模型。
这四条铁律的意义，在于让企业能够把“安全可信”拆解为具体问题：系统有没有写权限？日志能不能查？数据副本在哪里？异常由谁处理？回答应当能够被验证，而不是停留在宣传话术。
本地部署可以让应用、数据库以及适用的模型和 OCR 组件运行在客户自己的基础设施中，减少敏感业务数据离开内网的需要。但本地部署并不自动等于安全：服务器账号、网络隔离、补丁升级、备份、日志和运维访问仍然需要管理。
因此，部署方案应与企业现有 IT 管理制度衔接。需要明确运行环境由谁提供，账号和权限由谁审批，系统升级如何进行，远程运维是否允许，故障日志是否包含敏感字段，以及项目结束后如何交接和回收访问权限。
同样重要的是，企业不应被供应商永久绑定。T-HUB 的交付思路包含维护手册和人员培训，让客户 IT 能接手知识库运行、规则维护和数据接入。供应商可以持续提供内容更新和版本升级，但企业应当清楚掌握自身的数据、经验规则和运维边界。
如果 ERP 已经按照组织、项目和岗位设置权限，知识底座就需要在授权范围内遵循既有权限，而不是另建一套长期无法同步的规则。否则，原系统中没有权限查看的资料，可能通过 AI 问答被间接暴露。
数据口径也同样重要。知识底座的分析结果可以用于快速查询、趋势判断和业务辅助，但对外报送、正式考核和审计，应以企业现有正式系统及其确认口径为准。若两者不一致，应将其作为数据质量或口径差异反馈给信息岗和业务负责人核实，而不是修改数据来迎合预期答案。
这要求产品设计保留来源和证据链：答案来自哪份资料、哪个字段、哪个版本？经验规则由谁确认？当引用无法精确定位时，系统是否清楚提示限制？对于扫描件等特殊资料，如果目前只能定位到页而不能精确框选段落，就应该如实说明，不能把能力边界包装成已经实现的功能。
一个知识底座项目是否真正落地，不应只看页面是否打开、文件是否导入或模型是否能够聊天。更有价值的验收问题包括：
第一，是否在没有改动原业务系统的情况下，按授权接入了约定的数据源？
第二，跨系统分析所使用的主键、字段和业务口径，是否经过相关业务岗位确认？
第三，第一批经验规则是否完成来源标注，并在真实业务场景中被调用、核对和记录？
第四，企业自己的人员是否能够按照交付文档独立维护至少一个业务场景？
这四个问题同时覆盖数据接入、分析质量、经验应用和可持续运维。任何一项没有完成，都应该明确记录差距和整改责任，而不是用“AI 已经上线”作为项目成功的唯一标准。
制造企业真正需要的，不是把所有数据交给 AI，而是在自己能够控制的边界内，让 AI 获得完成具体业务任务所需的资料和规则。T-HUB 以只读打通、交叉分析和经验沉淀为核心，通过“取数不入湖”的设计方向、本地化部署以及不改系统、不写回业务数据、不留未经授权副本、关键节点保留人工责任等原则，尝试在知识利用与数据控制之间建立平衡。
