此前我们在《外挂AI vs AI原生QMS：制药合规场景下，二者真正的区别》一文中，从数据打通、流程嵌入、审计追踪、模型迭代、合规验证五个维度，拆解了两种技术路线的本质差异。不少药企数字化负责人、IT选型决策者和质量管理者看完后，都问了同一个问题：两边不都能写偏差、搜文件、出质量回顾吗？功能都覆盖了，凭什么说不是同一代产品？

答案是：凭架构。功能可以后装，架构里关于「谁在操作系统」的底层假设，后装不进去。

2026年的QMS路演，各家的AI功能表已经长得越来越像。但拉开真正差距的，从来不是功能清单的长短，而是这些AI能力长在哪一代架构上。坐在传统QMS架构上，AI就是插件；坐在按「AI会参与业务」重新设计的架构上，AI是系统的一种属性。插件和属性可以出现在同一份标书里，打分却不该放在同一列——这是架构竞争，不是功能竞争。

「代际」不是口号，是底层假设的更替

药企的质量记录其实经历过一次代际更替，很多从业者还有体感。

早年无纸化起步时，有一种做法是把纸质记录扫描进系统，附件一挂，流程就算走完。从功能上看，「记录在系统里」这件事确实完成了；但从架构上看，系统本质还是个电子档案柜。真正的电子记录是另一代产品：记录在系统内原生产生，修改留痕，签名绑定身份，版本受控。扫描件解决了「有一份文件」的问题，却把「这条记录如何产生」的全过程留在了系统之外。等到检查问到原始数据与操作链路，档案柜式的方案就答不上来。

今天QMS的AI化，正在重演完全一样的分岔。

传统叠加式AI的做法，是在一套已经跑顺的QMS旁边接一个对话框。偏差描述、SOP问答、回顾报告初稿，这些场景确实能做，我们也从不否认它带来的效率价值。但这套QMS在设计的时候，底层默认坐在屏幕前的操作者只有人：人填字段，人点审批，人的操作进审计追踪，验证包的预期用途也只围绕人来设计。AI是后来接上去的「外来者」，站在流程旁边，不进入系统的核心规则体系。

AI原生架构更换的，正是这个底层假设。

最终结论与责任仍由人承担，电子签名也始终归属人，但系统里同时多了一类受控的参与者：它读取业务对象，嵌入流程节点，它的每一次调用本身就是电子记录，它的版本升级走变更控制流程，它从启用到停用都落在同一套治理体系内。它始终运行在平台既有的安全模型之内，与业务权限、审计体系同源，不会在系统旁边再长出一套独立的规则。

这个假设写死在数据模型、流程引擎、权限体系的最底层。菜单上加一个「AI助手」入口，改的只是表面；底层假设的更替，才是代际的分界。

所以「代际」的定义可以很明确：一代QMS的边界，取决于它的数据、流程、审计、验证和治理体系，在设计时把谁算作系统参与者。 只把人算进去的，是上一代；把人和受控的AI共同纳入，且AI的全部行为仍受原有权限、审计、合规规则约束的，是下一代。中间再多的功能叠加，都还在上一代的框架里。

上一期我们提出了五个对比维度，这一期我们把它落到架构层面，拆解成五层架构代际差，看清楚为什么「加功能」跨不过代际门槛。

五层架构，看懂真正的代际差

1. 数据架构：外挂读取 vs 底座直读·权限受控

数据是AI能力的起点，也是两代架构最根源的分歧。

外挂式AI的数据逻辑，本质是「数据出域」：哪怕做了定时同步、自动向量转换，数据也还是要从业务主库里搬出来，拼成文本片段再喂给模型。这个过程里，结构化的业务数据被降维成了纯文本，字段值还在，但批次与物料、物料与供应商、供应商与历史偏差之间的关系网络消失了。接口能传值，传不了一张关系网；值可以后接，关系必须在底座设计时就埋进去。

更隐蔽的风险在权限层面。很多方案的数据同步只看内容，不看身份：数据进了向量库之后，召回只看相似度，不再校验是谁在提问。业务系统里按岗位、按车间、按产品严格管控的数据权限，到了AI对话框里就成了旁路——QA在表单里看不到的批次、文件，在问答里却能被检索出来。权限停在了页面层，向量数据已经走出了合规边界。

AI原生架构采用的是底座直读+权限全程透传的模式。

一方面，QMS、DMS、TMS共享同一套企业本体，对象、关系、规则落在同一张语义网络上。AI直接在底座内读取业务对象，不用把数据搬出系统、降成文本，引用的始终是现行有效版本的数据与文件，能沿着关系链完成关联推理，而不是只基于单条文本做回答。

另一方面，数据读取从源头就受控。Agent沿用当前登录用户的身份与数据权限，不另建平行授权体系；上下文装配阶段就完成数据过滤，向量召回也严格遵循用户可见范围，登录人只能召回自己数据权限内的向量数据。从入口鉴权到取数过滤，全程复用平台既有权限规则，不存在数据旁路。

同一个QA账号，在QMS里看不到的批次，在AI问答里也绝对看不到。看得到，向量通道就是合规漏洞。

2. 流程架构：独立对话框 vs 流程节点·人机协同

判断AI在流程里还是流程外，标准很简单：AI的产出，是不是一个能进流程的业务对象。

外挂式AI的产出是一段字符串。字符串没有类型，进不了状态机，不能被退回，不能挂电子签名，也不能成为下游CAPA的触发源。完整的路径是：AI输出文字→人读→人判断→人打开QMS→人新建单据→人粘贴→人提交。AI替代的只有「打字」和「搜索」，判断、关联、负责的仍然是人。文字粘贴进表单的那一刻，AI就已经从流程里彻底退出了。

AI原生架构里，AI是流程的内置节点，不是旁边的助手。

它产出的是带类型的业务对象——偏差调查草稿、CAPA建议、变更影响评估，自带状态，能直接进入审批流，自动关联上下游批次、物料、SOP，下游动作可以基于它继续触发。在偏差上报、原因调查、措施制定、效果验证的每个节点，AI自动提供对应能力，用户全程不用跳出流程。

同时，架构从设计上就明确了人机协同的边界：AI负责起草、推荐、关联，偏差分级、CAPA审批、批记录放行、变更确认等高影响决策，始终保留人工确认环节，由质量人员最终负责。AI不替代人工职责，只承接流程中可标准化、可复用的部分。

一个简单的检验标准：把AI停掉，流程还能由人完整走完；把AI打开，它能出现在流程图上，而不是浮在流程图旁边。

3. 审计架构：游离日志 vs 全链贯通·可追溯

21 CFR Part 11与EU GMP Annex 11的核心要求始终没变：谁做的、什么时候做的、能不能复现。AI参与之后，只多了一个问题：依据是什么。

外挂式AI的审计追踪是「游离」的。QMS里记着「张三15:32提交了偏差报告」，AI侧存着一段聊天记录，两者分属两个系统，靠人工回忆对齐。检查员问起这张偏差单的生成过程，要从两边捞数据，时间、版本、引用的SOP章节常常对不齐。更关键的是，系统只能记下「模型返回了这段文字」，给不出指向具体业务对象的证据链。聊天记录可以存档，当不了合规证据。

AI原生架构的做法，是把AI的每一次调用都当作一条电子记录来管理。

会话、模型调用、工具执行全程留痕，落在同一条审计追踪链路上，完整记录模型标识与版本、输入数据快照、输出内容、推理路径、人工确认环节。AI生成的内容与人工审核、修改、签署的内容明确区分，所有推荐均返回依据来源，可解释、可复现，完全满足ALCOA+要求。

这里要特别说明：推理路径不是日志里多写一段话就能实现的。没有底座里的本体关系网络，结论就无法直接指回具体的历史偏差、SOP章节、供应商记录。只有在底座内直读、且召回范围受权限约束的架构，才能给出完整可查的证据链。

监管关心的从来不是「你用不用AI」，而是「你能不能说清楚AI干了什么」。说得清，靠的是记录边界，不是事后补一份说明。

4. 验证架构：事后补验证 vs 设计即合规·变更可控

「设计即合规」听上去像口号，拆成验证包里的三行内容，就非常具体：

1. 预期用途写明AI参与哪些活动、不承担哪些决策；

2. 模型版本、技能、允许引用的知识范围，是受控配置项，有编号、有生效记录；

3. 变更分级事先定义：换模型大版本触发什么测试，调技能数据范围触发什么测试，哪些变更不触发再验证。

外挂式AI的问题，在于它从一开始就在验证边界之外。

传统QMS的验证包做完了，再接上AI模块，相当于关键行为发生在已验证范围之外。上线后要补风险评估、补验证文档，模型每升级一次，就相当于一次关键组件变更，验证状态就要重新评估，验证负债持续累积。这不是文档写得全不全的问题，是变更发生的位置，系统当初根本没给它留位置。

AI原生架构遵循的是「设计即合规」的思路：AI功能从设计之初就纳入系统预期用途，属于已验证软件系统的一部分，随产品整体完成计算机化系统验证（CSV）。模型版本、能力更新均遵循变更控制流程，随产品版本受控发布。

由于大量能力迭代发生在0代码配置层，对应GAMP 5的类别4可配置产品，变更粒度更细，影响范围可提前圈定，可基于风险执行增量验证，已验证状态可延续，无需每次推倒重来。

这不等于原生架构不需要验证。它的核心价值是：把AI迭代从「每次都是计划外变更」，变成了「受控的常规变更」。长期验证成本的差距，会在上线两三年后彻底拉开。

5. 治理架构：手动台账 vs 生命周期内置·体系同源

POC阶段几乎看不出治理的差别。一个场景、一个机器人、一个项目经理盯着，Excel台账就够用。

但当场景扩展到五六个、基地覆盖到两三个、模型按月迭代时，问题就会全部冒出来：谁有权启用新技能？技能的数据读取范围和岗位权限一致吗？供应商换模型，要不要在客户侧留变更记录？旧模型停用后，两年前的偏差单还能不能按当时的版本复现？

外挂式AI的治理，基本靠手动台账和邮件审批。QMS一套治理规则，AI模块另一套，权限、版本、技能启用两边分别维护。场景越少越省心，场景越多越混乱，很容易出现权限不对齐、版本失控、数据范围越界的问题。模型迭代是项目级事件，不是系统内置的常态化流程。

AI原生架构则把AI的全生命周期治理，完全内置到了平台治理体系中。

AI技能、模型版本、数据范围、人工确认策略本身就是系统内的受控对象，有责任人、有生效停用状态、有审计留痕，和业务系统共用同一套权限、角色、变更流程。人员调岗离职，AI权限同步变更；新技能启用，走同一套审批链路；模型升级，按预设的变更分级执行。全部流程在系统内闭环，不靠人工台账兜底。

模型迭代是最高频的变更，但不是治理的全部。治理的核心是：AI的规则和业务的规则，是不是同一套体系。

代际是五层一体，不是单点叠加

这五层架构，单独拎出任何一层做外挂，演示都能做得很漂亮。

只补审计日志，数据仍是文本，日志里没有关系可指；只把输出写进流程，验证包没改，下一次模型升级照样是计划外变更；只做一份AI验证方案，技能启用和数据范围仍靠人记，第二个基地就要再接一套。

代际差的核心，是五层同时成立。

数据层决定AI看见什么、谁有权看；流程层决定产物进不进记录、谁来负责；审计层决定检查时拿不拿得出证据；验证层决定明年的合规状态还作不作数；治理层决定下一个场景是复用底座还是再开一条数据通道。

少了任何一层，成本曲线都是向上的：每加一个场景多一条数据链路，每升一次模型多一轮验证工作。这也是为什么很多AI功能上线初期惊艳，越用越重、越用合规风险越高。原生架构的长期成本向下，靠的是底座、知识、能力、验证体系一次建设、持续复用，不是第一年更便宜。

选型启示：从「打功能分」到「判架构代」

今天药企做QMS选型，如果评分表还只停留在「支不支持偏差撰写、文件问答、质量回顾」，打出来的只是功能分。功能分拉不开代际差距，真正决定三年后好不好用、过不过得了审计、扛不扛得住迭代的，是架构分。

这里有五个可以直接带进选型会的问题，对应五层架构，供应商的答案会自己归位：

1. 数据层：当前用户在业务系统里无权查看的记录，AI问答能否返回？向量召回是否严格限定在登录人的数据权限范围内？引用的SOP是业务对象的现行有效版本，还是索引里的历史文本片段？

2. 流程层：请在流程图上指出AI所在的节点、产出的业务对象类型，以及人工确认与电子签名的环节。关键决策最终由谁负责？

3. 审计层：请从一张已完成的偏差单中，导出对应的模型版本、输入对象、推理路径、人工修改与签名记录。AI生成与人工内容能否明确区分？

4. 验证层：系统预期用途中是否明确了AI的定位？AI功能是否随产品整体完成CSV？下一次升级的变更等级与再验证范围能否明确给出？

5. 治理层：启用新技能、停用旧模型在系统内由谁审批、留痕在哪里？数据读取范围是否与业务系统权限一致？

五个问题里有三个落在系统之外，这份方案本质就是「上一代QMS+外挂AI功能」；五个都落在系统之内，才是真正的AI原生架构。

行业的共识正在形成：AI-native QMS会成为新一代QMS的架构标准。

这不是因为监管要求「原生」，而是因为AI已经深度进入了受控记录的产生过程，监管对数据完整性、记录可追溯、变更可控的核心要求，必然会穿透到AI的全链路。外挂式的方案，或许能解决一时的效率问题，但在合规与长期迭代上，始终绕不开架构层面的先天缺陷。

加AI功能，比的是旧系统还能多做几件事；AI原生架构，比的是下一套QMS能不能把AI真正纳入受控体系，能不能撑过持续的模型升级、多基地复制和一次次监管检查。

两件事可以同时出现在选型候选名单里，但它们不该放进同一列打分。

质量数字化的竞争，早已从功能竞争进入了架构竞争。看清代际差，选对底层架构，才能避免三年后再走一次换代迁移的弯路。