大模型工程化实战（十六）：政企国产化避坑——合规/信创名录/私有化运维/国产硬件适配/原厂支持这五道关怎么过

目录

• 前言
• 一、问题定义：为什么"实验室选型"搬到政企就废
• 二、核心方案：五道关，先过边界、再谈性能
• • [2.1 五关核对表（本篇的骨架）](#2.1 五关核对表（本篇的骨架）)
  • [2.2 五关逐个说清"它会怎么卡你 + 你该拿什么去核"](#2.2 五关逐个说清“它会怎么卡你 + 你该拿什么去核”)
  • [2.3 判据复用表：这一篇的新话，一句都没有](#2.3 判据复用表：这一篇的新话，一句都没有)
  • [2.4 三个取舍点（每个都有代价）](#2.4 三个取舍点（每个都有代价）)
  • [2.5 边界：这篇不是什么](#2.5 边界：这篇不是什么)
• 三、代码实战：一个纯标准库的政企落地五关核对器
• • [3.1 数据结构：核对项是数据，不是写死的 if-else](#3.1 数据结构：核对项是数据，不是写死的 if-else)
  • [3.2 信创关那一刀：命中 LLM 软件组件，强制返回 PENDING](#3.2 信创关那一刀：命中 LLM 软件组件，强制返回 PENDING)
  • [3.3 运维关：算的是"养得起养不起"](#3.3 运维关：算的是“养得起养不起”)
  • [3.4 主核对：先准入、后运行，全覆盖不含糊](#3.4 主核对：先准入、后运行，全覆盖不含糊)
  • [3.5 9 个断言怎么把这些结论钉死](#3.5 9 个断言怎么把这些结论钉死)
• 四、踩坑记录：这三个坑，每个都真付过费
• • [4.1 我把"数据不出域"理解成了"服务器在我们机房"，漏了审计留痕，验收卡住](#4.1 我把“数据不出域”理解成了“服务器在我们机房”，漏了审计留痕，验收卡住)
  • [4.2 我照着一份"信创兼容清单"选了个组件，交付时才发现那份清单根本不适用](#4.2 我照着一份“信创兼容清单”选了个组件，交付时才发现那份清单根本不适用)
  • [4.3 POC 时原厂工程师帮我架得漂漂亮亮，验收后人一撤，某天夜里集群挂了没人会修](#4.3 POC 时原厂工程师帮我架得漂漂亮亮，验收后人一撤，某天夜里集群挂了没人会修)
• 五、选型对比：三种做法，你该抄哪一种
• • [5.1 大表：政企国产化这条路的三种做法](#5.1 大表：政企国产化这条路的三种做法)
  • [5.2 副表：典型组件的五关核对现状（2026，口径与条目待核实）](#5.2 副表：典型组件的五关核对现状（2026，口径与条目待核实）)
  • [5.3 可复用 checklist：政企国产化落地 8 问](#5.3 可复用 checklist：政企国产化落地 8 问)
• [六、总结 + 下一篇预告](#六、总结 + 下一篇预告)
• [附录 B：典型组件的五关核对现状表（2026，全标"待核实"）](#附录 B：典型组件的五关核对现状表（2026，全标“待核实”）)
• [附录 C：权威源清单（口径与条目以官方原文为准）](#附录 C：权威源清单（口径与条目以官方原文为准）)
• [附录 D：核对器算法说明](#附录 D：核对器算法说明)

---

前言

上一篇《开源工具箱 30+ 选型地图》结尾我留了一句话："这张地图上，'国产化 / 私有化'是一整根约束轴......下一篇《政企国产化避坑》：地图上标了国产化的那些格，背后的坑单独一篇来讲。"今天来还这笔账。

我在第 15 篇那张地图上，把"国产化 / 私有化"标成了一整根轴，每个格子里都摆好了国产候选------向量库的华为 GaussDB、百度 BES，Embedding 的 BGE-M3，推理引擎那一格......写的时候我觉得挺全。可有个政企项目，我照着这张地图选齐了组件------全是国产的、还都开源可私有化------自以为交了个漂亮方案。甲方信息中心的老师看完，问了我三句话：

"这几样在信创名录里吗？"

"上了之后大半夜挂了，谁起来修？"

"跑在我们的国产卡上要是出问题，原厂管不管？"

我一句都答不上来。 那一刻我才知道：我那套"选型"，在政企只完成了第一关；后面还有四关，我一关都没核过。这一篇就把那根轴展开------政企国产化落地要过五道关，顺序不能反，每关给判据，落成一个能核、能对账、能老实说"我核不到"的核对器。

一、问题定义：为什么"实验室选型"搬到政企就废

前十五篇该造的零件我都造了：第 6 篇立了安全边界、第 8 篇把 Trace 定成可回溯、第 10 篇要求放行/拒绝都可追、第 11 篇点了国产向量库的名、第 12 篇强调版本不可变、第 13 篇说模型是耗材、可迁移性第一天就得设计、第 15 篇把几十个工具摊成一张能查的地图。可这些搬到政企落地，会撞上三个误区，一个比一个贵。

误区一：把政企选型当成"更严格的选型"。 其实不是加严，是换了第一性约束------从"在一个开放集合里找最优"，变成"在一个被合规和名录框死的子集里找可行"。实验室里，选型是道技术题：哪个准、哪个快、哪个便宜。政企里，选型是道准入题：这东西能不能进我的网、进不进名录、谁来扛它、原厂认不认账。先有可行解，才谈最优解；边界外的第一名，对你等于不存在。

误区二：以为信创有统一名单。 这是我踩得最狠、也最反直觉的一条。数据库、操作系统、芯片（含 AI 芯片）这类基础设施，确实有相对成熟的名录兜底；可 LLM 这一挂------推理引擎、向量库、Embedding、Agent 框架------没有一张统一的、权威的名单，你只能逐家看原厂公开口径、逐项自己送测。更麻烦的是"信创兼容"这个词，每家的定义都不一样。

误区三：只算建设成本，不算运维/维保/适配成本。 POC 阶段原厂工程师帮你把集群架得漂漂亮亮，演示流畅、领导满意、顺利验收；一验收、人一撤，这套栈就归你了------半夜挂了谁修？版本升级谁做？存储满了谁清？这笔账，没人替你算。

先把结论撂这儿：政企国产化 = 五道关，顺序不能反------① 合规关（数据出不出域、等保/密评、关键操作留审计）→ ② 信创关（进不进名录）→ ③ 运维关（谁半夜起来修）→ ④ 适配关（国产芯片/OS 上跑不跑得动）→ ⑤ 支持关（出事原厂兜不兜底、锁死到什么程度）。每一关的判据，全部从前几篇立过的判据里来，我一个都不新造；落点是一个纯标准库、离线可跑、可断言的"政企落地五关核对器"。

先说清一件事，免得你去搜一个搜不到的东西：这"五关"是我为了"可核对"做的工程化归纳，不是某个部门的官方分类。 但它不悬空------每一关都能挂到公开流程上：合规关挂等保测评和密评，信创关挂安全可靠测评（国测），运维关挂政企采购验收里的 SLA 与驻场服务条款，适配关挂各地的信创适配中心流程，支持关挂政企采购的维保条款。我不发明官方口径，我只是把"政企落地前你得挨个过的那五件事"编成一张能核的表。

二、核心方案：五道关，先过边界、再谈性能

整篇的主线就一句：第 15 篇给了我一张选型地图，地图上"国产化 / 私有化"是一整根约束轴------这一篇把轴展开成五道关。顺序不能反：先过边界（合规、信创），再谈性能；过了边界，还得有人扛运维、有硬件能适配、有原厂认账。

第 15 篇那张地图上的"国产化/私有化"约束轴（只标了、没展开）
   │
   ▼  这一篇把轴展开成"五道关"：政企落地的第一性约束
   │
政企国产化的五道关（顺序不能反：先过边界，再谈性能）
  ① 合规关 ------ 数据出不出域、等保/密评、关键操作留审计       ← 准入门
  ② 信创关 ------ 进不进名录（数据库/操作系统/芯片有国测目录，
              LLM 软件组件没有统一名录，只能逐家看口径）      ← 准入门
  ③ 运维关 ------ 私有化之后，这套栈谁半夜起来修                ← 运行门
  ④ 适配关 ------ 国产芯片/OS/数据库上，跑不跑得动              ← 运行门
  ⑤ 支持关 ------ 出事原厂兜不兜底、兜到哪一层、锁死到什么程度    ← 运行门
   │
   ▼  每一关的判据，全部复用前几篇立过的（不新造）
   │
落点：一个能核对的东西（这是本篇区别于"避坑清单文"的关键）
  核对项数据（CheckItem：关别 + 依据条文/目录条目 + 适用条件 + 判定规则 + 出处 + 核实日期）
        │
        ├──► render_checklist()：把核对项渲染成人看的"五关核对表"（表给人看）
        │
        └──► audit(situation)：输入"我的处境"→ 逐关核对 → PASS/FAIL/PENDING/NEEDS_HUMAN
                               → 确定性吐出"被哪几关卡住 + 带依据的核对结论 + 待人工确认清单"
  一句话：表给人看，程序给人核；两者共用同一份数据，所以不会打架。

顺序为什么不能反？ 这是第 15 篇那条纪律的政企版------第 15 篇我立过"硬约束先过滤、软权重后排序"，约束是第一性条件、不是选完再看的后验项。到了政企，合规和信创就是那两条最硬的硬约束，一票否决。你推理再快，进不了信创名录就是台不能插电的服务器；你模型再强，越过了合规边界就是泄密。先把这两关当过滤器过一遍，剩下的候选才轮得到谈性能。 顺序反了会算出什么？会算出"一个过不了合规的方案，因为在国产卡上跑得快，所以'推荐'"------这种结论在实验室里荒谬，在政企里是事故。

2.1 五关核对表（本篇的骨架）

整篇里这张表最实用，你可以直接抄走。每一关的判据都标了出处，坐实"判据复用、不新造"。

关（政企问的第一个问题）	它会怎么卡你	你该拿什么去核	判据来源（前篇立过的）
① 合规关	数据不许出域 → 任何托管 SaaS 直接出局；等保/密评没过 → 上不了线；关键操作没留审计 → 过不了验收	数据分级 + 部署形态 + 审计留存（谁调的/谁批的/走了哪条路）	第 6 篇安全边界 + 第 8 篇"Trace = 可回溯"+ 第 10 篇"放行/拒绝都可追"+ 第 12 篇"版本不可变"
② 信创关	组件进不了名录 → 整条链换血；LLM 软件组件没有统一名录 → 只能逐家看口径、逐项送测	原厂公开口径 + 送测报告（数据库/操作系统/芯片可对国测目录；LLM 软件组件只能逐家核）	第 11 篇国产向量库候选（GaussDB/BES）+ 第 15 篇的约束轴
③ 运维关	POC 跑通 ≠ 生产能养；原厂人一撤，半夜挂了没人修	组件运维负担 vs 团队实际人力 + 有没有原厂/驻场兜底	第 8 篇"自托管 Langfuse 要自己扛 ClickHouse 成本"
④ 适配关	国产芯片/OS 上推理引擎跑不动、向量库没有对应版本	芯片 × OS × 组件的适配清单 + 自测（不能只信厂商 PPT）	开篇《四大支柱》4.2 第⑤条推理引擎 + 第 15 篇"推理引擎"格（只给边界）
⑤ 支持关	出事原厂说"维保不含这一项"；被单一原厂锁死，换不动	维保范围 / 响应时限 / 边界条款 / 可迁移性	第 13 篇"模型是耗材、可迁移性第一天设计"

2.2 五关逐个说清"它会怎么卡你 + 你该拿什么去核"

① 合规关：不是"数据别跑出去"这一件事，是三层。 第一层是数据在不在边界内，第二层是系统过不过等保/密评，第三层是关键操作留不留可审计的痕 。我一开始只核了第一层------把所有组件私有化，就以为过了合规。结果甲方合规口一问"你这个 LLM 每天放行了哪些请求、拒绝了哪些、谁批的、依据是什么，有留痕吗"，我说有日志，拉出来一看：只有机器日志，没有"谁、凭什么"的决策链。第 8 篇立过的"全链路 Trace = 谁调的、谁批的、走了哪条路可回溯"，在第 10 篇被推成"每一次放行/拒绝都能追到是谁、凭什么"------这两条合起来，就是合规关第三层的判据。数据那层的判据来自第 12 篇的"版本不可变"：你处理过的每一版数据都能对账到发布。合规关的判据，一句新话都没有，全是前面立过的。

② 信创关：全文最锋利的一刀------LLM 软件组件没有统一名录。 这里必须先纠正一个常见误解：信创目录的官方名称是《安全可靠测评结果公告》（俗称国测目录、安可测评、信创目录），由测评机构发布。截至 2026 年，它覆盖的是五类：CPU、人工智能训练推理芯片、操作系统、数据库、打印机主控芯片 （口径以官方公告为准，待核实）。所以那句最锋利的话要说得精确------数据库、操作系统、芯片（含 AI 芯片）都有国测目录兜底，LLM 软件组件（推理引擎 / 向量库 / Embedding / Agent 框架）没有统一名录。 注意别把这句说成"推理引擎不在目录里"就完事------"人工智能训练推理芯片"（昇腾 950 这类）是硬件 、在目录里；"推理引擎"这个软件不在。这个区别，懂行的人一眼就能拿"昇腾 950 进目录了"来反驳你，措辞得先站住。

更要命的是，"信创兼容"这个词根本没有统一官方定义，实际至少混着四类意思：① 进过某份目录；② 和国产 OS/CPU 做过厂商互认证（麒麟/统信的适配证书）；③ 能跑/能编译（第三方实测或开源社区跑通）；④ 采购招标里的"信创符合性测评"。同样一句"信创兼容"，A 家可能指进了目录、B 家是拿了互认证证书、C 家只是有人在国产卡上跑通过------三个不是一个意思。 第 11 篇我点过名的国产候选，这一篇逐家过一遍就露馅：openGauss/GaussDB 系是"数据库进国测目录 + 生态兼容"；BGE-M3 是"开源模型 + 有人在昇腾上跑通（第三方实测）"；而百度 BES 的适配认证口径，我从公开渠道核不到。三个候选、三种口径、还有一个核不到------这就是信创关最难受的地方。

③ 运维关：考的不是"装得上"，是"养得起"。 私有化最容易犯的错，是只算了"装"、没算"养"。第 8 篇我立过"自托管 Langfuse 要自己扛 ClickHouse 成本"------那还只是可观测这一块：Langfuse 自托管就要你扛 PostgreSQL + ClickHouse + Redis + 对象存储四样有状态依赖，缺一不可。到了政企私有化，你要扛的是一整套（推理集群 + 向量库 + 网关 + 数据流水线），每一件都是运维负担。所以运维关的判据换算成一句大白话：这套栈要几个人扛，你有几个人？ 量级上，地端私有化的最小可行运维编制大概 1--3 名专职工程师起步（首年人力成本、中型项目编制这些具体数字都是厂商/媒体测算、无权威统一口径，进附录 B 标待核实）。

④ 适配关：跑不跑得动是适配问题，跟发布纪律是两件事。 开篇《四大支柱》4.2 第⑤条点过推理引擎的名，第 15 篇给它划了边界格------这一篇沿用边界，只回答"这套东西能不能在国产芯片/OS 上跑起来"。公开事实是：主流推理引擎在国产硬件方向基本都有分支 而不是官方认证------昇腾有基于 vLLM/SGLang 的适配分支和自研引擎，寒武纪有开源的 vLLM-MLU 分支，海光走类 CUDA 的软件栈迁移。所以核适配关就一件事：芯片 × OS × 组件 的适配清单 + 自测，不能只信厂商 PPT。 量级上，国产卡单卡算力已经到"能用"区间，推理实测大概到主流卡七八成的量级（口径差异极大、随型号批次浮动，具体 benchmark 一律进附录 B 标待核实，正文不编死）。

⑤ 支持关：出事原厂兜到哪一层，以及你被锁死到什么程度。 第 13 篇我立过"模型是耗材、可迁移性第一天就要设计"------支持关就是这句话的反面：你被原厂 / 单一供应商锁死到什么程度，换掉这个组件要多大代价。 政企里有两件事必须白纸黑字核：一是维保范围（"含什么、不含什么"，响应时限多少），二是可迁移性（换掉它要多大代价）。这两件事都很不浪漫，但都真金白银：原厂维保的边界写得很细，"这一项不在范围内"是普遍现象不是个案；而"开源"也不等于"免费"------国产大模型的商业化支持边界正在被写进许可证条款，普通企业自用多半豁免、对外转售模型服务到一定规模就要重新谈判（具体门槛数字是媒体口径、待核实，进附录 B）。

2.3 判据复用表：这一篇的新话，一句都没有

这张表的信任来源就在这儿：上面每一关的判据，都是前面某一篇在真实场景里立过的，我不是临时编一套标准来评政企。

关	判据来源（前篇立过的）	一句话
合规关	第 6 篇《OWASP LLM 安全护栏》	合规关不只是"数据别出域"，还有"你这个 LLM 应用自己别成为攻击面"
合规关	第 8 篇《OTel + LangFuse 全链路 Trace》	Trace = 谁调的、谁批的、走了哪条路可回溯
合规关	第 10 篇《Human-in-the-Loop 反馈闭环》	每一次放行/拒绝都能追到是谁、凭什么
合规关	第 12 篇《数据工程底座》	版本不可变：你处理过的每一版数据都能对账到发布
信创关 / 适配关	第 11 篇《知识库防腐坏》	国产候选（GaussDB / BES）逐个过"有没有名录口径、国产 OS/芯片上有没有对应版本"
运维关	第 8 篇《OTel + LangFuse 全链路 Trace》	自托管 Langfuse 要自己扛 ClickHouse 成本 → 自建 = 自己半夜运维
支持关	第 13 篇《LLMOps 不完全指南》	模型是耗材、可迁移性第一天就要设计
五关顺序	第 15 篇《开源工具箱 30+ 选型地图》	硬约束先过滤、软权重后排序 → 先过五关、再谈性能
适配关	开篇《四大支柱》4.2 第⑤条	推理引擎只给边界：跑不跑得动跟发布纪律是两件事

2.4 三个取舍点（每个都有代价）

取舍一："先过边界、再谈性能"------政企选型的第一性是准入约束，不是技术指标。 代价我认三条：① 你会在合规边界内牺牲一截性能/体验（国产芯片/国产模型跟"顶配"的量级差距，这块我在正文只给量级、具体数字进附录待核实）；② 边界内候选少、选型自由度低，很多你心里的"最优解"直接出局，你得接受一个"不那么先进但能过审"的方案；③ 边界会动------名录/口径/等保要求会更新，你今天核过的结论，明天可能就得重核。因为边界外的方案，性能再高也是零分------它根本进不来。

取舍二：信创这关没有"统一名单"------LLM 软件组件只能逐家看口径。 代价：① 逐家核、逐项送测，工作量极大，且做完也不保证权威；② 口径不统一，导致你没法横向对齐（A 家说"兼容"和 B 家说"兼容"可能不是一个意思）；③ 有些条目就是核不到公开口径，只能自己承担判断风险。我认，因为编死一句"已信创认证"，比留一句"待核实"危险得多。 这也是我跟第 15 篇一以贯之的纪律：会烂的东西，宁留待核实，不编死。

取舍三：私有化之后，"运维谁来扛"比"装不装得上"更要命。 代价：① 自建运维要人，可政企的编制/预算恰恰是卡得最死的；② 原厂兜底要钱（维保/驻场/按年付），且边界常常写得很细；③ 有些组件你算下来就是养不起，只能放弃它、退回一个更土但有人养的方案。我认，因为一套没人运维的私有化集群，比一套"不够先进"的托管服务更危险。

2.5 边界：这篇不是什么

三层边界，缺一层就滑向清单文或软文：不是"政企国产化 20 个坑"的清单文 （罗列坑不给判定规则、不给可核依据------本篇给的是"每一关的判据 + 一个能核的落点"，坑只是判据的用例）；不是厂商软文 （不吹任何一家国产厂商，厂商支持口径一律进附录"待核实"列）；不是信创政策解读/目录复述 （不复述政策原文、不假装我有一份权威名录------恰恰相反，本篇点破"LLM 软件组件没有统一名录"这件事本身）。另外两条：不重讲前十五篇的细节 （每关判据只引用、各一句）；适配关里的推理引擎只给边界（沿用第 13 篇，跑不跑得动是适配问题、跟发布纪律两件事）。

三、代码实战：一个纯标准库的政企落地五关核对器

"能核、能对账、能老实说'核不到'"正是本篇区别于"避坑清单文"的唯一硬落点。所以这一篇的落点是一个离线可跑、纯标准库、无 API key、无第三方依赖的核对器：把五关的核对项编码成数据，输入"我的处境"，确定性地吐出一份"被哪几关卡住 + 带依据的结论 + 待人工确认清单"。一份"20 个坑"的清单文不用跑也能看，一个能核的核对器不跑就不知道结论------这就是清单和核对器的区别。

文件就两个，跟前几篇的 toolmap/、release/、multiagent/ 同级：

govcheck/
├── mini_govcheck.py        # 主代码：Gate/CheckItem/Component/Situation/VerdictItem/AuditReport
│                           #         + load_checkitems/applicable/judge/audit/explain_item/render_checklist
└── test_mini_govcheck.py   # 9 个断言，锁"处境一换结论就换 / 合规信创一票否决 / 信创对LLM只能PENDING /
                            #   运维是养得起 / 每条结论可对账 / 核不到标pending /
                            #   待人工确认清单完整 / 核对项一改结论就改 / 五关全覆盖"

正文只贴关键节选、原样摘出（没改动）。没露面的辅助函数------_num（数字归一）、load_checkitems（核对项数据源）、build_demo/build_demo_situation（构造示意处境）、find_verdict（按条目找判定）、RULES/LLM_KINDS（规则表与 LLM 软件组件类别）------都在 govcheck/mini_govcheck.py 里，别照抄正文片段去拼，直接跑整个文件（python govcheck/mini_govcheck.py）。

3.1 数据结构：核对项是数据，不是写死的 if-else

这是整份代码存在的前提------把"介绍"拆成"可查询的字段"。每个字段的"为什么"都写在 docstring 里：

@dataclass
class CheckItem:
    """一条核对项 = 一行数据（不是一段 if-else）。

    为什么核对项要做成数据：
    "国产化是一张永远在变的清单"------名录会更新、口径会变、等保要求会变。做成数据，
    清单变了你改数据就行；写成 if-else，明天目录一更新你就得重构。
      gate        关别（Gate 的五个常量之一）
      item_id     条目编号（人用来对账的稳定 id，如 CMP-1）
      clause      依据（合规条文 / 目录条目 / 适配清单条目 / 维保条款）------"凭什么这么判"
      applies_when 适用条件谓词：这条在什么处境下才适用（不适用要显式报出，不静默丢）
      rule        判定规则名（RULES 里的键）------判定逻辑本身也是数据引用，不是散落的 if
      source      依据的出处（哪份口径、哪一篇立过的判据）
      verified_at 核实日期；None 表示没核过（输出里显式标 pending）
    """
    gate: str
    item_id: str
    clause: str
    applies_when: object          # callable(Situation) -> bool
    rule: str
    source: str
    verified_at: str | None = None

五道关也焊进代码，顺序不是排版问题，是第一性约束：

class Gate:
    """五道关：常量 + 顺序 + 准入门/运行门的分组。

    为什么把"顺序"和"分组"也焊进代码而不是写在注释里：
    顺序不是排版问题，是第一性约束------准入关（合规/信创）一票否决，运行关（运维/适配/支持）
    只有在过了准入门之后才有意义。audit() 直接遍历 Gate.ORDER，顺序改不动、也不会被漏跑。
    """
    COMPLIANCE = "compliance"   # 合规关
    CATALOG = "catalog"         # 信创关
    OPS = "ops"                 # 运维关
    ADAPT = "adapt"             # 适配关
    SUPPORT = "support"         # 支持关

    ORDER = (COMPLIANCE, CATALOG, OPS, ADAPT, SUPPORT)   # 先准入、后运行，顺序不能反
    ADMISSION = (COMPLIANCE, CATALOG)                    # 准入门：一票否决
    RUNNING = (OPS, ADAPT, SUPPORT)                      # 运行门：过了准入门才有意义

判定是四态不是两态------政企的现实就是"很多项你核不到确定答案"，四态是为了让"我不知道"成为合法结论：

PASS = "PASS"                # 过了（且在核实的口径内）
FAIL = "FAIL"                # 卡住（一票否决级，或明确不达标）
PENDING = "PENDING"          # 核不到权威口径，只能标待核实/需送测
NEEDS_HUMAN = "NEEDS_HUMAN"  # 口径冲突/边界模糊，需人工判断
VERDICTS = (PASS, FAIL, PENDING, NEEDS_HUMAN)

3.2 信创关那一刀：命中 LLM 软件组件，强制返回 PENDING

这是本篇最硬的一条纪律，也是最容易被审稿盯的一条。规则本身写在数据里（RULES 表按名字引用），这里贴核心那句：

def rule_llm_catalog_pending(item, s):
    """信创关·LLM 软件组件无统一名录 ------ 本篇最硬的一条纪律。

    凡命中 LLM 软件组件（推理引擎/向量库/Embedding/Agent 框架），强制返回 PENDING：
    国测目录（官方名《安全可靠测评结果公告》）只覆盖 CPU / 人工智能训练推理芯片 /
    操作系统 / 数据库 / 打印机主控芯片------LLM 软件组件不在其中，只能逐家看原厂口径 + 送测。
    注意：芯片类是"人工智能训练推理芯片"这个硬件品类在目录里，不是"推理引擎"这个软件在目录里。
    为什么这里绝不返回 PASS：编死一句"已信创认证"，比留一句"待核实"危险得多------
    前者可能把一个不合规的东西带进生产，出事的是甲方；后者只是让甲方多问一句、多送一次测。
    """
    names = [c.name for c in s.components if c.kind in LLM_KINDS]
    return PENDING, [
        f"涉及 LLM 软件组件{names}：无统一名录（国测目录只覆盖 CPU / 人工智能训练推理芯片 / "
        f"操作系统 / 数据库 / 打印机主控芯片），需逐家看原厂口径 + 送测",
        "核不到权威口径，不许硬给 PASS------老实标待核实，交接给合规口/原厂补口径",
    ]

注意 LLM_KINDS = {"inference", "vector_db", "embedding", "agent"}------只有 LLM 软件组件进这个集合 ；数据库、操作系统、CPU 类是另外的路径（rule_db_catalog：可对国测目录）。这条边界，就是这一篇那把刀落在代码里的样子。

3.3 运维关：算的是"养得起养不起"

私有化最容易犯的错是只算"装"不算"养"。所以运维关把组件的运维负担求和，跟实际人力对账，不够就报 FAIL + "缺 N 人"，不是报"部署成功"：

def rule_ops_capacity(item, s):
    """运维关·养得起养不起（运维负担求和 vs 实际人力）。
    POC 能跑通 ≠ 生产能养。算不平就报 FAIL + "缺 N 人"，而不是报"部署成功"。
    """
    load = sum(c.ops_load for c in s.components)
    if s.ops_headcount < load:
        deficit = load - s.ops_headcount
        return FAIL, [f"运维负担合计 {_num(load)} 人，实际人力 {_num(s.ops_headcount)} 人"
                      f"------缺 {_num(deficit)} 人",
                      "私有化要算的是'养得起养不起'，不是'装得上装不上'（POC 跑通 ≠ 生产能养）"]
    return PASS, [f"运维负担合计 {_num(load)} 人 ≤ 实际人力 {_num(s.ops_headcount)} 人：养得起"]

3.4 主核对：先准入、后运行，全覆盖不含糊

def audit(situation, items=None):
    """主核对：先跑准入关（合规/信创，一票否决）→ 再跑运行关（运维/适配/支持）→ 汇总。

    顺序不能反：先过边界、再谈性能。反过来会得到"一个过不了合规的方案因为在国产卡上跑得
    快而'推荐'"这种荒谬结论。coverage 显式报出"哪几关跑了、哪几关因不适用未触发（含原因）"
    ------未触发 ≠ 静默忽略。manual_review = 所有 PENDING/NEEDS_HUMAN 的条目（一个诚实的核对器
    要把"我不确定的那部分"单独交出来，交接给合规口/原厂补口径，而不是混在结论里蒙混过去）。
    """
    items = list(load_checkitems() if items is None else items)
    kept, skipped = applicable(items, situation)

    verdicts = []
    for gate in Gate.ORDER:                                    # 顺序锁死在 Gate.ORDER 上
        for it in [x for x in kept if x.gate == gate]:
            verdicts.append(judge(it, situation))

    blocked = {v.item.gate for v in verdicts if v.verdict == FAIL}
    manual = [v for v in verdicts if v.verdict in (PENDING, NEEDS_HUMAN)]
    covered = [g for g in Gate.ORDER if any(v.item.gate == g for v in verdicts)]
    untouched = {}
    for g in Gate.ORDER:
        if g in covered:
            continue
        reasons = sorted({r for (it, r) in skipped if it.gate == g})
        untouched[g] = "；".join(reasons) if reasons else "该关没有定义任何核对项（清单未覆盖）"
    ...

跑 python govcheck/mini_govcheck.py（build_demo()），会打印 6 个确定性场景。注意：这里的数据全是【示意，待核实】，下面贴的是跑出来的输出（[...] 处省略了组件名），它是对示意数据的确定性结论，不是对真实政策/厂商的评价：

[场景 1] 示意处境（私有化 + 内部数据 + 2 人运维 + 昇腾 + 部分维保）
  [PASS ] 合规关·CMP-1  部署形态[private] + 数据分级[internal]：数据留在域内（示意口径，待核实）
  [PASS ] 合规关·CMP-2  有可观测组件承载审计链：谁调的/谁批的/走了哪条路可回溯（第 8 篇 Trace + 第 10 篇放行/拒绝可追）
  [PEND ] 信创关·CAT-1  涉及 LLM 软件组件[...]：无统一名录（国测目录只覆盖 CPU / 人工智能训练推理芯片 / 操作系统 / 数据库 / 打印机主控芯片），需逐家看原厂口径 + 送测
  [FAIL ] 运维关·OPS-1  运维负担合计 3 人，实际人力 2 人------缺 1 人
  [HUMAN] 适配关·ADP-1  推理组件[...]在国产芯片[ascend]方向有公开适配分支（各家分支，非官方认证），但跑不跑得动要你自测------标人工确认，不硬给 PASS
  [HUMAN] 支持关·SUP-1  维保边界写得很细------'这一项不在范围内'是普遍现象不是个案，需人工核哪些不在范围内、响应时限多少
  -> 五关核对：覆盖 5/5 关；被卡[运维关]；待人工确认 3 项；整体不通过
  -> 待人工确认清单：CAT-1、ADP-1、SUP-1

[场景 2] 同一套组件，只把数据分级从 internal 改成 secret（换处境结论就换）
  [FAIL ] 合规关·CMP-1  数据分级[secret]：通用私有化形态不够，需专用隔离域并过等保/密评
  -> 被卡[合规关、运维关]（合规关被卡 -> 整体不通过）

[场景 3] 只把运维人力从 2 人改成 1 人
  [FAIL ] 运维关·OPS-1  运维负担合计 3 人，实际人力 1 人------缺 2 人

[场景 4] 核不到口径的条目 + 待人工确认清单（核对器要把'我不确定的那部分'交出来）
  待人工确认清单 = ['CAT-1', 'ADP-1', 'SUP-1']

[场景 5] 核对项是数据：加一条新合规要求（示意）→ 结论随之变化，audit 一行不改
  加之前：待人工确认 3 项 ['CAT-1', 'ADP-1', 'SUP-1']
  加之后：待人工确认 4 项 ['CMP-9', 'CAT-1', 'ADP-1', 'SUP-1']

[场景 6] 每条结论可对账：explain_item() 逐条给依据/出处/核实日期
  关别[信创关] 条目[CAT-1] 判定[PENDING]
  依据[LLM 软件组件无统一名录（国测目录只覆盖 CPU/人工智能训练推理芯片/操作系统/数据库/打印机主控芯片）]
  出处[《安全可靠测评工作指南（V4.0）》五类清单（待核实）]
  核实[pending]

读一遍这个输出，主线就出来了：同一套国产组件 ，数据分级从"内部"改成"涉密"，合规关就从 PASS 翻 FAIL------处境一换，结论就换；信创关里凡命中 LLM 软件组件的，一律 PENDING、绝不硬给 PASS；运维关不是报"装好了"，是算"缺 1 人"；核不到的条目（LLM 软件组件的信创口径、模糊的维保边界）老实进"待人工确认清单"，不混在结论里蒙混过去。

3.5 9 个断言怎么把这些结论钉死

test_mini_govcheck.py 用纯标准库 unittest，两种跑法都行：

python govcheck/test_mini_govcheck.py        # 在仓库根目录下
python -m unittest test_mini_govcheck         # 在 govcheck/ 目录下

九个断言，对应本篇的九个命题句。挑三条说透：

断言①"处境一换结论就换"是本篇的命题句。 同一套国产组件，只把处境里的 data_level 从 internal 改成 secret------合规关那条从 PASS 翻 FAIL，整体结论随之改变。这是"国产化不是一次采购、处境变了结论就该变"的可断言化：

def test_01_situation_changes_conclusion(self):
    s_internal = build_demo_situation()                       # data_level=internal
    s_secret = build_demo_situation(data_level="secret")      # 只改这一个字段
    r1, r2 = audit(s_internal), audit(s_secret)
    self.assertEqual(find_verdict(r1, "CMP-1").verdict, PASS)
    self.assertEqual(find_verdict(r2, "CMP-1").verdict, FAIL)
    self.assertNotEqual(_conclusion(r1), _conclusion(r2))

断言③"信创对 LLM 软件组件只能 PENDING"是审稿最会盯的一条。 它不只断判定是非决定性的，还断理由里点名"无统一名录"和"送测"，并且断言理由里出现的是"软件组件"------把"是软件没有名录、不是芯片"这个精确措辞也钉进测试。想亲手验证这刀很容易：把 rule_llm_catalog_pending 的返回值改成 PASS 再跑，断言③当场就红。

断言⑦"待人工确认清单不多不少"是核对器诚实度的落点。 它断言 manual_review 的条目集合恰好等于所有 PENDING/NEEDS_HUMAN 的集合------一个诚实的核对器不只告诉你"过了哪些、卡在哪些"，还要把"我不确定的那部分"单独交出来。这一条同时是取舍点②的代码证据。其余六条------②合规/信创一票否决、④运维算"养得起"、⑤每条结论可对账、⑥核不到标 pending、⑧数据一改结论就改、⑨五关全覆盖------都在 test_mini_govcheck.py 里，命名和命题句一一对应，就不逐个展开了。

四、踩坑记录：这三个坑，每个都真付过费

4.1 我把"数据不出域"理解成了"服务器在我们机房"，漏了审计留痕，验收卡住

症状：合规这块我以为很简单------数据不出我的内网就完了，所以我把所有组件都私有化了，自认为过了合规关。结果甲方合规口一看：你这个 LLM 每天放行了哪些请求、拒绝了哪些、谁批的、依据是什么，有留痕吗？我说日志有，拉出来一看------只有机器日志，没有"谁、凭什么"的决策链。

排查：根因是我把合规关简化成了"数据在哪"。其实合规关有三层------数据在不在边界内、系统过不过等保/密评、关键操作留不留可审计的痕，我只看了一层。

修复：把审计链（第 8 篇的 Trace + 第 10 篇的"放行/拒绝可追"）当成合规关的必备项，接进核对器。教训：政企的"合规"不是"数据别跑出去"这一件事------它还要求你每一次决策都能被追溯、被复现。

4.2 我照着一份"信创兼容清单"选了个组件，交付时才发现那份清单根本不适用

症状：信创这块我找了份"信创兼容清单"，照着它选了个组件，省了一大圈核实功夫。交付时甲方一看：你这份清单是哪来的？我一查才尴尬------那是一家别的公司内部的清单，跟我们项目适用的目录/口径根本不是一套；更糟的是，就算口径对上了，LLM 软件组件（推理引擎/向量库/Embedding/Agent 框架）这类东西很多根本不在任何一张统一名录里，人家原厂说的"信创兼容"和我理解的还不是一个意思。

排查：根因是我把"信创有统一名单"当成了前提------数据库、操作系统、芯片有国测目录兜底，可 LLM 软件组件没有统一名录，只能逐家看口径。

修复：核对器里涉及 LLM 软件组件的信创项，一律只能返回"待核实/需送测"，绝不硬给 PASS；且每一条都标"依据是哪份口径、什么时候核的"。教训：没有统一名单的东西，别替它编一个名单------你编的那个，迟早会在交付现场被拆穿。

4.3 POC 时原厂工程师帮我架得漂漂亮亮，验收后人一撤，某天夜里集群挂了没人会修

症状：项目 POC 阶段，原厂派了工程师来帮我们把推理集群 + 向量库 + 网关一整套架起来了，演示流畅、领导满意、顺利验收。我们以为搞定了。结果某个夜里向量库集群挂了，值班的小伙子不会修，重启了三次没起来，只能等第二天；第二天一问原厂，回复是------"这套是你们自建的，维保合同里没包含这一项"。

排查：根因是我把"装得上"当成了终点，从没算过"装上之后谁养它"------POC 能跑通 ≠ 生产能养。这个坑在第 8 篇（自托管 Langfuse 要自己扛 ClickHouse）就埋下过伏笔，我在政企私有化里又踩了一遍、而且更严重（一整套、不是一件）。

修复：把运维关做成核对器里的硬项------算每个组件的运维负担、跟团队实际人力对账，算不平就老实报"缺人/缺维保"，而不是报"部署成功"。教训：私有化交付的终点不是"装好了"，是"有人能一直养着它"------这两件事之间，隔着一份维保合同和一支会值班的队伍。

五、选型对比：三种做法，你该抄哪一种

5.1 大表：政企国产化这条路的三种做法

选型这件事，我见过三种做法，值得摊开比：

做法	组织的维度	覆盖几关	结论能不能对账到依据	核不到的口径怎么处理	时效性怎么管	推荐指数
① 照抄别人的"信创兼容清单"	按别人定的口径	看着覆盖，实际未必	不能------清单没带依据链	清单怎么说就怎么说（可能是错的）	清单一年一变，没人标日期	⭐⭐
② 逐个组件问原厂"支不支持信创"	按提问的时机	只覆盖问到的那一关	答案随原厂口径变，带不走	原厂说兼容就兼容	无	⭐⭐
③ 按"五关"建自己的核对表（本篇 demo 就是最小实现）	按你的处境	五关全覆盖	能------每条结论带关别/依据/出处/核实日期	核不到的条目老实进"待人工确认清单"	每条标核实日期	⭐⭐⭐⭐⭐

结论：做法①抄来的答案不一定是你的；做法②问一次只能用一次；做法③可复用、可对账，还能标出我不确定的那部分。 小团队不用一上来就把五关全填满，先把你自己项目真实要过的关填上（每关给判据 + 依据出处），核对器就比任何"避坑清单"都有用；后面按需加项。

5.2 副表：典型组件的五关核对现状（2026，口径与条目待核实）

正文只给结论：这张副表的生产化 = 一张"组件 × 关 × 依据 × 口径 × 核实日期"的数据表 + 一个核对器；本篇 demo 的 CheckItem 数据类就是这张表的最小 schema，换成你们项目真实的口径数据，加个前端，它就是你们单位的"国产化落地核对平台"。 完整版（组件逐行、全标"待核实"）在附录 B。

5.3 可复用 checklist：政企国产化落地 8 问

这八问就是 demo 里 audit() 要覆盖的检查项，也是你能直接抄走的落地清单：

1. 你用的每个组件，数据在不在边界内（部署形态 + 数据分级）？
2. 系统要不要过等保/密评，过了吗？
3. 关键操作留没留可审计的痕（谁调的、谁批的、走了哪条路、能不能复现）？
4. 每个组件进没进适用的名录------数据库/操作系统/芯片能不能对国测目录，LLM 软件组件有没有统一口径（核不到就老实标待核实）？
5. 这套栈要几个人扛，你的团队有几个人（运维关是"养得起"不是"装得上"）？
6. 每个组件在国产芯片/OS 上有没有对应版本------你是信的 PPT 还是自己测过？
7. 出事了原厂兜到哪一层------维保范围、响应时限、哪些不在范围内？
8. 你被单一原厂/单一组件锁死到什么程度，换掉它的代价算过吗？

六、总结 + 下一篇预告

回到开篇那三句问话------"这几样在信创名录里吗"对应信创关，"上了之后大半夜挂了谁起来修"对应运维关，"跑在我们的国产卡上要是出问题原厂管不管"对应支持关，加上合规关和适配关，就是政企国产化的五道关。

一句话收口：政企国产化避的坑，八成不是技术坑------在实验室，选型是道技术题（哪个准、哪个快、哪个便宜）；到了政企，选型是道准入题（能不能进网、进不进名录、谁来扛、跑不跑得动、原厂认不认账）；技术指标在这五关面前，一个都排不进前三。 顺序更不能反：先过边界，再谈性能。

一句大实话收尾，也是本篇的信任来源：涉密的项目我只给公开口径、不假装跑过；我这篇里实打实跑过的，是一个省级和一个地市级的政企私有化交付，其余照实标"没实跑过"。

但注意：这一篇讲的五关，是政企通用 的一组约束------合不合规、进不进名录、谁运维、跑不跑得动、原厂认不认账；可有的行业，约束比这还狠一层：它不只要求你"能进来"，还要求你每一个决策事后都能被审计、被复现、被追到具体责任人 ------放行一笔、拒绝一笔，都得有据可查、有责可追，出了事得说得清"这个决定是谁、凭什么做出来的"。这套约束，政企那五关没覆盖全。下一篇《金融级 AI 落地》：政企国产化讲的是"东西能不能进来、谁来扛"；金融级讲的是"每个决策能不能被审计、能不能被追责"------同一套工程纪律，在金融行业要被逼到什么程度。

---

附录 B：典型组件的五关核对现状表（2026，全标"待核实"）

正文一个口径都不编死，这张表才是"会烂的那部分"。每一行的"依据出处 / 支持口径 / 是否需送测 / 核实日期"都标"待核实"------真实能不能过，取决于你项目适用的具体口径和你自己的送测结果。

组件	所在关	依据出处	支持口径（待核实）	是否需送测	核实日期
向量库·华为 GaussDB / openGauss 系	信创 / 适配	安全可靠测评结果公告（数据库类，待核实）	"数据库进国测目录 + 生态兼容"（厂商口径）	向量能力/国产 OS 上需自测	2026-09（待核实）
向量库·百度 BES	信创 / 适配	公开渠道核不到其适配认证口径	核不到（第三方版本口径少）	核不到，需向原厂核实 + 送测	2026-09（核不到）
Embedding·BGE-M3	信创 / 适配	开源 + 第三方在昇腾/麒麟上的部署验证（非权威）	"开源模型 + 有人跑通"（第三方实测，非官方认证）	需自测（不能把第三方实测当认证）	2026-09（待核实）
推理引擎·vLLM / SGLang 国产分支	适配	昇腾/寒武纪/海光公开适配公告（厂商 + 媒体）	各家分支（昇腾版 vLLM/SGLang、vLLM-MLU、DTK 迁移），非官方认证	具体型号/版本需自测	2026-09（待核实）
操作系统·麒麟 / 统信 UOS	信创 / 适配	安全可靠测评结果公告（操作系统类，待核实）	在目录类；具体版本待核实	OS×组件组合需自测	2026-09（待核实）
国产芯片·昇腾 / 海光 / 寒武纪 / 飞腾 / 鲲鹏	信创 / 适配	安全可靠测评结果公告（含"人工智能训练推理芯片"类，待核实）	芯片品类在目录；型号一律待核实（昇腾 950、昆仑芯 M100 等以公告原文为准）	推理引擎适配需自测	2026-09（待核实）
国产大模型·旗舰模型许可证门槛	支持	媒体口径（多家旗舰模型对 MaaS/高收入平台设门槛）	门槛数字为媒体口径、待核实；普通企业自用多半豁免	需逐家向原厂核实	2026-09（待核实）
运维人力·地端私有化最小编制	运维	厂商/媒体测算（无权威统一口径）	最小 1--3 名专职工程师起步；中型"推理集群+向量库+网关"约 1 名全职 + 兼职，首年人力成本六七十万量级	按项目自核	2026-09（待核实）
国产硬件·推理算力 benchmark	适配	各家公开 benchmark + 媒体口径（差异极大）	单卡算力"能用"区间，推理实测约主流卡七八成量级（随型号/批次浮动）	需自测（不能只信 PPT）	2026-09（待核实）
厂商自建平台·ModelHub XC"信创模盒"	信创	厂商 2025-09 发布（厂商自建，非政府名录）	厂商宣称适配认证模型若干（非官方统一名录）	不能替代官方名录核验	2026-09（待核实）

附录 C：权威源清单（口径与条目以官方原文为准）

• 《安全可靠测评工作指南（V4.0）》（中国信息安全测评中心）------测评对象五类：CPU、人工智能训练推理芯片、操作系统、数据库、打印机主控芯片。https://www.itsec.gov.cn/aqkkcp/ywjs/202307/t20230727_141347.html
• 安全可靠测评结果公告（官方名，俗称国测目录/安可测评）：https://www.itsec.gov.cn/aqkkcp/cpgg/
• 《生成式人工智能服务管理暂行办法》（网信办等七部门）
• 《网络数据安全管理条例》
• 《政务领域人工智能大模型部署应用指引》（"数据不出域、可用不可见"口径）
• 《关键信息基础设施商用密码使用管理规定》（密评依据）
• GB/T 22239-2019（等保 2.0 基本要求）、GB/T 39786-2021（密码应用基本要求）
• 财政部/工信部《政府采购需求标准（2023 年版）》（覆盖硬件+OS+数据库，不含 LLM 软件组件）
• 各地信创适配中心适配流程指引、政企招标中的等保/密评/软件测评验收条款

说明（口径统一性） ：上表中"数据不出域""等保/密评""测评对象五类""政府采购需求标准覆盖范围"有相对权威统一口径；而"审计留痕留存期限""信创兼容的定义""LLM 私有化专属维保边界""国产硬件 benchmark 数字"口径不统一或核不到统一口径------这几类正文一律写成"核不到/需送测"，不编死。

附录 D：核对器算法说明

demo 是纯标准库的确定性近似，不是真实合规审查、不是真实信创核验。

• 为什么核对项是数据、不是写死的 if-else ：CheckItem 把一条核对项拆成 (gate, item_id, clause, applies_when, rule, source, verified_at)；rule 是 RULES 表里的键。加一条新口径 = 加一行数据、引一个规则，不用改audit() 主流程（断言⑧：加一条核对项，结论随之变化）。
• 为什么准入关必须排在运行关前面 ：audit() 直接遍历 Gate.ORDER（合规→信创→运维→适配→支持），blocked_gates 取所有有 FAIL 的关、空集才算整体通过。顺序反了会算出"一个过不了合规的方案因为在国产卡上跑得快而推荐"------这就是取舍点①和踩坑①的代码落点（断言②）。
• 为什么判定是四态 ：PASS/FAIL/PENDING/NEEDS_HUMAN。只给两态会逼你对"核不到的东西"编一个答案；四态让"我不知道"成为合法结论，并让 manual_review 从非决定性判定里自然长出来（断言⑦）。
• 为什么信创关对 LLM 软件组件强制 PENDING ：rule_llm_catalog_pending 命中 LLM_KINDS（推理引擎/向量库/Embedding/Agent 框架）时只返回 PENDING------没有统一名单的东西，本分是老实说你核不到（断言③）。这是本篇最容易被审稿盯的一条，也是"宁留待核实、不编死"的代码化。
• 为什么运维关是"求和对账"不是"查表判过" ：rule_ops_capacity 把 components 的 ops_load 求和，跟 ops_headcount 对账，不够报 FAIL + 缺 N 人。为什么 ops_load 交给你填、不按类型查表：同一个组件，你团队熟悉和陌生，负担差很多------核对器只负责对账，不替你把负担拍死（断言④）。
• 为什么 coverage 要显式报"未触发" ：audit() 用 applicable() 把不满足 applies_when 的条目连同"为什么没跑"一起收进 coverage["untouched"]。政企验收最怕"有一关没人管"------把"哪关没覆盖"摆到明面上，比假装全过更负责（断言⑨）。
• 真实生产怎么替换 ：把 load_checkitems() 换成你们单位维护的真实口径数据、把 render_checklist() 换成内部平台/前端，audit() / judge() / explain_item() 的逻辑一行不改------同前几篇"生产换数据、骨架不动"的替换心智。

---

🎯 更多专栏系列文章可以查看博客主页📑 👍 若文章对你有所触动，恳请点赞 ⭐ 关注 ⭐ 收藏