高风险AI出厂前，质量管理体系要验收什么

一家向银行交付信贷辅助评分模块的软件公司，准备做上线前验收。业务方只关心“坏账预测提升了几个点”，法务突然问：“如果这套系统日后被认定为高风险，你们有没有按欧盟规则建过质量管理体系？技术文档能不能给监管看？”现场只有测试报告和演示录像，没有成体系的书面程序。

以上是假设场景。它指向的生产侧问题是：当高风险AI进入产品放行，质量管理体系与技术文档如何从法规条文变成可核对的验收项。

已经发生的事

【适用时间】AI Omnibus已成为Regulation (EU) 2026/1744，并于2026年7月27日生效，不再只是提案。但“修法已生效”不等于本文高风险义务已开始适用：按修订后的第113条，第III章第1至3节（第6条第5款除外），对第6条第2款及附件III系统自2027年12月2日起适用，对第6条第1款及附件I系统自2028年8月2日起适用。第11、17条在上述范围内；存量系统另须核对第111条过渡安排。本文讨论的是提前准备放行材料，不能据此称企业截至2026年11月已违反这些尚未开始适用的义务。

【事实】AI Act Service Desk展示的《人工智能法案》第17条（基于截至2026年7月27日的EUR-Lex合并文本）规定：高风险AI系统的提供者须建立质量管理体系，以确保符合本条例；该体系须以书面政策、程序与指示的形式系统、有序地记录，并至少包括下列方面：（a）监管合规策略，含符合性评估程序及高风险AI系统变更管理程序；（b）设计、设计控制与设计验证的技术、程序与系统行动；（c）开发、质量控制与质量保证的技术、程序与系统行动；（d）开发前、开发中与开发后须开展的检查、测试与验证程序及其频次；（e）拟适用的技术规范（含标准），以及在未充分适用相关协调标准或标准未覆盖第2节全部要求时，用以确保符合性的手段；（f）数据管理的系统与程序，含获取、采集、分析、标注、存储、过滤、挖掘、聚合、留存等为投放市场或投入使用之目的而进行的操作；（g）第9条所指风险管理系统；（h）按第72条建立、实施并维护上市后监测系统；（i）按第73条报告严重事件的程序；（j）与国家主管机关、其他相关机关、公告机构、其他经营者、客户或利害关系方的沟通处理；（k）相关文件与信息的记录保存系统与程序；（l）资源管理，含供应安全相关措施；（m）规定管理层及其他员工对上述各方面职责的问责框架。

【事实】同条第2款写明：第1款各方面的实施应与提供者组织规模相称，尤其当提供者为中小企业（含初创）或小型中等规模企业（SMC）时；但提供者无论如何须尊重确保高风险AI系统符合本条例所需的严格程度与保护水平。第3款允许已受相关行业欧盟法质量管理体系义务约束的提供者，将第1款所列方面纳入该行业体系。第4款对受欧盟金融服务法内部治理要求约束的金融机构，除第1款(g)(h)(i)点外，可通过遵守相关金融服务法的内部治理安排视为履行质量管理体系义务。

【事实】本次复核EUR-Lex截至2026年7月27日的官方合并文本，第11条写明：高风险AI系统的技术文档须在该系统投放市场或投入使用之前编制，并保持更新；编制方式应能证明系统符合本节要求，并以清晰、全面的形式向国家主管机关与公告机构提供评估符合性所需信息；技术文档至少应包含附件IV所列要素。中小企业（含初创）与小型中等规模企业（SMC）可以简化方式提供附件IV要素，委员会应制定面向其需求的简化技术文档表格；若选择简化方式，须使用该表格，公告机构应接受该表格用于符合性评估。与附件I第A节所列欧盟协调立法相关产品挂钩的高风险AI系统，应编制单一套技术文档，同时包含第11条第1款与相关法律行为要求的信息。

【事实】欧盟委员会《Navigating the AI Act》官方问答写明：在欧盟市场投放或投入使用高风险AI系统前，提供者须进行符合性评估，以证明系统符合可信AI的强制性要求（如风险管理、数据质量、文档与可追溯、透明、人工监督、准确性、网络安全与稳健性）；系统或其目的发生实质性修改时须重复评估；提供者还须实施质量管理体系，以确保持续符合新要求并在生命周期内最小化对用户与受影响人的风险；FAQ概述了数据库登记；准确范围须回到第49条：附件III系统原则上登记，但第2点系统在国家层面登记，执法、移民等特定用途使用欧盟数据库非公开部分，不能把所有高风险系统都写成必须公开登记。

【核验限制】已复核欧委会Service Desk第17条、EUR-Lex官方合并文本第11、17、49、111、113条及修法2026/1744。附件IV全文虽已随官方合并文件保存，本次未逐项审阅，故仍以第11条“至少包含附件IV要素”为边界，不提供未经核实的附件细目。某具体产品是否构成高风险及适用哪些过渡安排，须个案判断。

变化的机制：从“能跑通演示”到“放行前能证明过程可控”

许多团队习惯用样例集准确率、延迟和销售演示当作“出厂标准”。第17条把设计控制、测试频次、数据操作、上市后监测与严重事件报告写进同一套书面体系；第11条则要求在投放前就备好可供监管与公告机构审阅的技术文档。生产侧验收因此从“看一次结果”转向“看过程是否可追溯、变更是否有程序、出事是否有报告链”。

【推演】采购方与自研放行可能出现标准化的“高风险AI放行包”：要求供应商或内部产品线同时提交质量管理体系目录（对照第17条a–m）与技术文档索引（对照第11条/附件IV结构），并标明版本与变更管理入口。成立条件是企业确实可能提供或采购落入高风险范围的系统，且合规把放行门与合同验收挂钩。受益方是需要向客户或监管证明“不是临时拼凑”的产品与质量团队；承担成本的是须补齐程序文件与证据链的工程与文档岗位。可能失败的环节：把ISO证书封面当成第17条全覆盖；技术文档只写营销白皮书，缺少可评估符合性的信息；规模相称被误解为“初创可以不做测试与监测”。

对生产的影响

• 能力测评表不能替代质量管理体系；验收至少要能指出设计验证、测试频次、数据管理与上市后监测各自写在哪份程序里。
• 技术文档须在投放前存在并可更新；若产品同时受医疗器械等协调立法约束，应确认是否采用“单一套技术文档”策略，避免两套材料互相打架。
• 符合第17条第4款条件的金融机构，可通过相关欧盟金融服务法内部治理规则被视为履行部分质量管理体系义务；但(g)(h)(i)风险管理、上市后监测、严重事件报告不在该“视为履行”的范围内，仍须落实对应AI Act要求，不能仅以行业规则已有安排代替核对。

建议试验：用一页对照表做“放行预演”

【建议试验】选一个最接近高风险用途的在研或在售AI系统，由质量与产品各1人，用同一张表对照第17条(a)–(m)十三项：每项是否有书面程序、责任人、最近一次执行记录；再对照第11条问：技术文档是否在拟投放日前已有可审阅草稿、是否声明覆盖附件IV结构、版本号如何随模型或数据变更更新。投入：约两天桌面整理，不改代码。判断指标：十三项中有几项只能回答“在脑子里/在聊天记录里”；技术文档是否能在30分钟内定位到测试与数据相关章节。失败条件：无人能指出变更管理程序，或技术文档只有演示幻灯片。结果用于补放行检查表，不构成对是否违法的认定。

边界

本文不提供法律意见，不判断具体系统是否高风险，也不讨论中国境内产品强制认证规则。符合性评估是否须第三方、登记库填报细节，以适用时主管机关与正式文本为准。

参考资料

• AI Act Service Desk, Article 17: Quality management system. https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-17 （核验日期：2026-11-07）
• AcquisLaw, AI Act Article 11 — Technical documentation（转载合并文本，可对照EUR-Lex）. https://acquislaw.com/law/ai-act/11 （核验日期：2026-11-07）
• European Commission, Navigating the AI Act（高风险系统提供者义务问答）. https://digital-strategy.ec.europa.eu/en/faqs/navigating-ai-act （核验日期：2026-11-07）

• EUR-Lex，《人工智能法案》2026-07-27合并文本（合并文本供查阅，法律效力以正式公报法令为准）. https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX%3A02024R1689-20260727 （复核日期：2026-11-07）
• Regulation (EU) 2026/1744，Digital Omnibus on AI，2026-07-24刊于正式公报，2026-07-27生效. https://eur-lex.europa.eu/eli/reg/2026/1744/oj/eng （复核日期：2026-11-07）