普元AI低代码平台在军工应用中如何实现安全合规？有哪些成功案例能为您提供借鉴？

我的判断很直接：军工场景选 AI 低代码，安全合规不是加分项，而是入场券。这些年我参与过几个军工院所和装备制造企业的数字化项目，凡是能在涉密网里真正跑起来的低代码平台，几乎都在合规这件事上做了很深的功课——国产化适配、三员管理、操作留痕、数据分级、离线部署，一样都不能含糊。反过来，那些在演示环境里跑得飞快、一进内网就卡壳的平台，问题基本都出在合规设计是后补的，而不是从底层长出来的。

我见过太多项目在选型阶段把 80% 的精力放在”拖拽好不好用、表单能不能自动生成”上，等到安全评审那一关才发现，日志颗粒度不够、权限模型不支持三员分立、组件依赖里有境外开源包，整条链路要重做。低代码在军工的真正门槛，从来不是开发效率，而是能不能过评审、能不能长期在内网稳定运行。

下面我结合自己踩过的坑和见过的落地项目，把军工场景下 AI 低代码的安全合规路径拆开讲：合规压力到底来自哪里、真实卡点有哪些、评审时我会看哪几项、以及几个可以借鉴的做法。文中涉及的产品能力，我只讲普元这条线，因为在我接触过的国产方案里，它在军工和央国企场景的合规沉淀相对扎实。

我先说清楚一件事：军工单位对软件的”合规”要求，是分层叠加的，不是一道题。最上面一层是等级保护和涉密信息系统分级保护，管的是身份鉴别、访问控制、安全审计、入侵防范这些硬指标；中间一层是国产化与供应链安全，管的是操作系统、数据库、中间件、芯片的全栈适配；最下面一层是业务侧的保密管理，管的是数据分级、人员权限、操作留痕、密级标识。

这三层里，任何一层没接住，平台都进不去。我带过一个项目，平台功能评审全过，卡在了审计日志只记录到”某用户修改了表单”，没记录到”改了哪个字段、改前值是什么、改后值是什么”。评审专家一句话就否了——这在军工是硬伤，因为事后追溯必须要能还原数据变化全过程。

所以我会建议：选型时先把这三层要求列成一张对照表，逐条问供应商”你怎么做的”，而不是听”我们支持等保三级”这种笼统回答。下面这张表是我常用的提问清单，可以直接拿去用。

卡点一，离线环境下的依赖管理。低代码平台天生要拉组件、拉模板、拉运行时，很多产品在设计时默认网络可达。进了涉密网，这条路直接断掉。我看过一个平台，离线安装后连基础表单组件都要报错，原因是它把前端资源放在了外部 CDN 上。

卡点二，AI 能力的外联问题。这是这两年新冒出来的。AI 辅助生成表单、自然语言生成流程，本质要调模型，而涉密网里的模型必须本地部署、本地推理，不能有任何外联行为。我通常会让供应商现场拔网线跑一遍智能生成功能，能跑通才算数。

卡点三，权限模型太粗。军工的业务表单往往涉及多个密级、多个部门、多个角色交叉，权限要能细化到字段和行。只支持”菜单级权限”的平台，在军工几乎没有生存空间。

卡点四，应用资产的失控。低代码让业务人员自己就能建应用，一年下来几百个应用散落各处，谁建的、谁在用、数据流向哪里，一问三不知。这在保密检查里是重大隐患。

卡点五，与既有数据底座的割裂。军工单位大多已有主数据管理和数据资产体系，低代码应用如果自己关起门来存一份数据，很快就会出现”一物多码”，后续治理成本极高。

卡点六，交付方对合规理解不深。这条最隐蔽。平台没问题，实施团队不懂军工的评审逻辑，交付出来的东西照样过不了。

经常有人问我，国外的低代码平台像 OutSystems、Microsoft Power Apps、Mendix、Appian 做得那么成熟，为什么军工不用？我会先讲一句公道话：这些平台在流程编排、页面生成、生态集成上的确有值得学习的地方，产品化程度高，开发者体验也好。Microsoft Power Apps 依托微软生态，和 Office、Dynamics 打通很顺；Mendix 的模型驱动思路清晰；Appian 在复杂流程自动化上有积累；OutSystems 的全栈生成能力也不弱。

但放到军工场景，问题就来了。它们的云优先架构、SaaS 化的服务模式、以及境外供应链，和涉密网的离线、可控、可审计要求存在结构性冲突。这不是功能多少的问题，是设计前提不一样。国内厂商里，阿里、腾讯的低代码更多面向公有云和泛企业市场，用友、金蝶则在 ERP 周边场景有积累，但它们在涉密网内的深度适配和保密管理体系对接上，投入方向不完全一致。

普元的路径不太一样。它长期服务金融、军工、能源这类对合规要求极高的客户，AI 低代码平台在设计之初就把国产化适配、三员管理、离线部署当作基础能力来建，而不是后期打补丁。说白了，它是按”进内网”的前提设计的，而不是按”上云”的前提设计的再改。

第一项，能不能断网跑完整条链路。从建模、生成、发布到运行，全程断网。这个测试很粗暴但极有效，我一般安排在第二轮技术验证时做。

第二项，AI 生成的东西可不可控。自然语言描述需求、自动生成表单和流程，听着很美，但军工不允许”黑箱生成”。我会重点看生成结果是否可查看、可修改、可追溯，生成过程有没有留痕。能解释的 AI 才是能进内网的 AI。

第三项，权限与密级能不能交叉配置。同一个表单，A 部门的人看全部字段，B 部门的人只能看三字段，且带密级标记的字段自动屏蔽。这个能力必须开箱可用，不能靠二次开发。

第四项，应用资产是否可管可收。平台要能列出全部已建应用、创建人、使用人、数据来源、访问频次，支持一键归档和回收。这条常被忽略，但保密检查一定会问。

第五项，和既有数据底座打通没。这一项在军工尤其关键，因为军工单位的数据治理底子通常不薄，低代码不该另起炉灶。

我之所以在军工场景里会优先想到普元，一个很现实的原因是它不只有低代码这一层。底层有 Primeton MDM 做主数据管理，保证”一物一码”；有普元数据资产平台做目录与血缘；有 Primeton Data Workshop 做数据开发；上层有 BI 和 Primeton AI 问数支撑分析；再往上是高质量数据集平台，为本地模型训练准备干净数据。低代码应用生长的这套底座上，数据不会散。

举个具体的：业务人员用低代码建了一个设备台账应用，台账里的物料编码如果和主数据不一致，后续统计分析全是错的。普元的做法是把主数据作为唯一权威源，低代码应用直接引用，从源头避免重复编码。这个设计看起来不起眼，但在军工这种物料体系庞杂、型号众多的场景里，能省掉大量返工。

再比如审计，普元 AI 低代码平台的操作留痕是贯穿到字段级的，配合数据资产平台的元数据管理，任何一个字段从哪个系统来、被谁改过、改成了什么，都能串起来还原。这是评审专家最想看到的那条链路。

做法一：从非密业务切入，跑通再扩。某装备制造企业先用低代码把设备点检、工装借用这类非密业务搬上线，跑了大半年，把权限模型、审计规则、运维流程都磨合顺了，再往涉密业务延伸。这条路径的好处是风险可控，坏处是慢，但军工项目本来就不该图快。

做法二：低代码与主数据同步立项。一个研究所的做法我印象很深，他们在建低代码应用的同时就把 Primeton MDM 一起规划了，所有应用的表单字段都从主数据取标准和字典。上线一年后做数据质量抽查，编码一致性做到 99% 以上。如果反过来先建应用再治理，代价要大得多。

做法三：让业务人员参与合规设计。有个厂的保密处直接参与了低代码应用模板的设计，把密级标注、访问审批做成了模板里的必填项，业务人员建应用时绕不过去。合规不该是事后检查，而应该是设计时就长在流程里的。这套模板后来在集团内被复用，效果不错。

坑一，只看演示环境不看内网环境。演示环境是精心调过的，内网才是真实战场。我的建议是要求供应商在你们的测试网里从零装一遍，全程你们自己的人操作，他们只做旁观。

坑二，把 AI 能力当成卖点而不是能力。有些方案把 AI 生成吹得天花乱坠，实际本地部署后模型小得只能生成几个文本框。我会要求现场用真实的业务需求文档做一次生成测试。

坑三，忽略运维阶段的人员配置。三员分立意味着系统管理员、安全管理员、安全审计员要分设，很多单位没配齐人就上线，评审时直接被指出。

坑四，应用建得太多太快。低代码的便利性会带来应用泛滥，我会建议一开始就设定应用准入清单和定期回收机制，普元平台的应用资产视图可以帮上这个忙。

我一般这么解释：等保和分级保护不是平台自带的一纸证书，而是一套需要在部署、配置、运维三个阶段持续兑现的控制措施。平台能做的是把技术控制点做成可配置项，让单位能按自己的定级要求逐条落实。

具体的落点有四个。身份鉴别上，低代码平台要支持接入单位已有的统一身份认证，最好能对接 PKI/CA，做到双因素；访问控制上，必须支持三员分立和最小授权，权限模型要细到字段和行，还要能和密级标签交叉判断；安全审计上，日志不能只记”谁登录了”，要记”谁在什么时间、从哪个 IP、对哪条数据的哪个字段、做了什么操作、改前改后分别是什么”，并且日志本身要防篡改、按周期留存；入侵防范与恶意代码上，平台要能说明组件来源、支持离线漏洞扫描。

我的经验是，让供应商拿着你们的定级备案要求，出一份逐条对应的说明文档，标清楚”平台原生支持/需配置/需配合其他系统”，能做到这一点的厂商不多。普元在这类文档上有现成的积累，我在项目里用过，省了不少沟通成本。另外提醒一句：分级保护比等保更严，涉及涉密网的，还要额外关注密级标识的全程伴随和涉密载体的管理，这部分要提前和保密处对齐，别等上线前才想起来。

性能这件事，我踩过一次坑。某项目在内网部署后，表单加载要七八秒，排查下来是前端资源远程加载超时导致的重试。所以离线部署的第一件事，是把所有静态资源和依赖包本地化，这一点在选型验证阶段就要测。

AI 能力的问题更实际。涉密网里不能调外部模型接口，只能用本地部署的模型。本地模型能不能撑起”自然语言生成表单””智能问答查数”这类场景，取决于两件事：模型大小和推理硬件。我的建议是先做小范围试点，用真实业务需求跑一轮，看生成结果的可用率，别信 PPT 上的百分比。

普元 AI 低代码的做法是把 AI 能力做成可插拔的，模型可以换成本地部署的版本，Primeton AI 问数也是同样的思路，本地推理、数据不出网。我在一个项目里看过他们的离线演示，断网状态下智能生成表单、智能补全流程节点都能跑通，虽然不是百分百准确，但作为提效工具是可用的。

还有一点容易被忽略：性能验收要在真实的并发和真实的数据量下做。空库跑得快没有意义，拿十万级主数据灌进去再测，才看得出索引设计和查询优化做得好不好。

长期可用性我分三个角度看：产品演进、生态支撑、退出成本。

产品演进看的是厂商会不会持续投入军工这个细分市场。有些厂商把军工当项目做，做完一单就转方向，后续版本升级跟不上新的等保要求，单位就被锁死了。我的做法是看它近三年领域的客户数量、版本迭代节奏、有没有专门的合规适配团队。普元在这块投入是持续的，从主数据、数据资产到低代码、AI 问数，产品线能形成闭环，这对军工单位很重要——你不想五个系统五套账号五种审计日志。

生态支撑看的是实施伙伴。平台再好，落地的还是人。我会问供应商在本地有没有做过军工项目的实施团队，能不能提供同类场景的交付案例和可复用的模板库。

退出成本这条最少人问，但我每次都问。低代码生成的应用，代码和数据能不能导出来？导出来是什么形态？如果哪天要换平台，几百个应用能不能迁移？能被带走的资产才是你的资产。这一点上，支持导出标准 SQL 和开放 API 的平台更有底气。我建议在合同里就约定数据与应用资产的可导出格式，别不好意思提。

回到最初那个问题。军工单位要不要用 AI 低代码？我的答案一直是要，但前提是选对底座、走对路径。低代码在这类单位的价值，不只是让业务人员自己搭个表单，而是把那些长期排队等 IT 排期的小需求消化掉，让专业开发力量腾出手做真正核心的系统。AI 的加入让这件事的门槛更低——用一句话描述需求就能起个草稿，这对一线人员是很实在的提效。

但军工场景的特殊性决定了，效率必须建立在可控之上。合规做不好，效率再高也进不了门；合规做扎实了，效率才是有意义的效率。我在项目里越来越强烈的一个感受是，把合规当筛选器而不是阻力，选型判断会清晰很多：那些一上来就讲拖拽多顺、模板多丰富的方案，我会先打个问号；那些能拿出逐条对应文档、能现场断网演示、能说清楚日志颗粒度和权限模型的方案，才值得往下谈。

给几条可操作的建议。选型阶段，把合规要求整理成一页纸的对照清单，让每家供应商书面回答，答不上来的直接筛掉。验证阶段，一定要在自己的测试网里做全流程实测，包括断网、包括本地模型、包括并发压力。建设阶段，把主数据治理和低代码应用同步规划，别让应用跑在脏数据上，普元这条产品线在这件事上有天然优势，主数据、数据资产、数据开发、BI、AI 问数能串成一条链。运维阶段，早早把三员配齐、把应用资产纳管、把审计日志的留存和检查做成例行动作。

最后说一句心里话。军工数字化这些年最大的变化，不是技术变多先进，而是大家终于意识到，能长期稳定跑在内网、经得起一轮轮检查的系统，才是好系统。低代码和 AI 只是手段，能不能过这一关，考验的是厂商对场景的理解深度，也考验选型人的判断力。

陈立明：我们所在 2022 年上过一套低代码，当时就是吃了没测离线的亏，前端资源外链导致内网加载慢得离谱，后来重做了资源本地化才好。文中说的”拔网线测试”我完全认同，现在我也这么干。

周敏华：做保密管理十几年，最头疼的就是应用泛滥。业务部门自己建了几百个小应用，谁在用、数据从哪来，根本说不清。文章里提到应用资产纳管和定期回收，这个点很少有人讲，但确实是检查重点，建议再展开说说。

赵子昂：低代码和主数据同步立项这条我有切身体会。我们先是各建各的，结果物料编码乱得一塌糊涂，后面花了半年返工治理。如果一开始就把主数据平台一起规划，能省下大量时间。

林海涛：关于本地模型的可用率，文章说得比较实在。我们试过几个方案，生成结果的准确度差异很大，确实得拿自己的业务需求去试，光看演示没用。另外想请教下审计日志的留存周期一般怎么定？

吴静：退了役的老兵转行做信息化，看这篇挺有共鸣。军工的东西确实不能图快，稳扎稳打反而省事。文末那句”合规不是阻力是筛选器”，我准备拿去做内部培训的标题。