模型卡（Model Card）

章节结构（8）

1. 1. 一、模型标识与版本

   对应附件 XII 第 1 项与附件 XI 第 1 项：模型预期执行的任务以及可被集成进的 AI 系统类型与性质；适用的可接受使用政策；发布日期与分发方式；模型与自身之外硬件或软件的交互方式（如适用）；与使用该通用人工智能模型相关的软件版本（如适用）；架构与参数数量；输入输出的模态（如文本、图像）与格式；模型许可。写作要点：模型标识必须是外界可验证的公开名称并带版本号，与权重发布、API 端点名称、以及 GPAI 训练内容摘要中的"带版本的模型名称"保持一致。参数数量与架构若视为商业秘密而不披露，应当说明不披露的范围与理由，而不是留空——附件 XI 与附件 XII 都把这两项列为应提供的信息，完全留白会直接成为下游提供者的采购阻碍。

   需要附的证据

   • · 模型版本命名规范与内部版本台账
   • · 可接受使用政策全文与其公开位置
   • · 模型许可文本（含商用、再分发、微调、输出所有权条款）
   • · 发布记录与分发渠道清单（权重下载、API、私有化部署）
   • · 架构与参数数量的披露决定记录（如部分不披露，记录理由与范围）

   常见失分点

   • · 模型卡里的版本号与 API 返回的版本号、权重仓库的 tag 三者不一致；
   • · 架构与参数数量整片留空且无任何说明；
   • · 可接受使用政策与模型许可互相矛盾（一个允许、一个禁止某类用途）；
   • · 模型卡长期停留在首发版本，后续微调版本没有各自的模型卡。

2. 2. 二、预期用途、适用边界与禁止用途

   把"这个模型该用来做什么、不该用来做什么"写清楚，是模型卡对下游最有价值的一节，也是价值链责任划分的起点。三块内容。预期用途：具体任务、目标用户、典型集成方式与典型部署场景。适用边界：语言、领域、输入长度与格式、数据新鲜度截止、并发与延迟假设、以及在哪些分布下性能会显著下降。禁止与不建议用途：明确列出不得用于的场景，尤其要覆盖欧盟人工智能法案第 5 条禁止性实践所涉领域（如通过潜意识或操纵技术实质扭曲行为、利用弱势群体脆弱性、社会评分、基于画像的犯罪预测、无差别抓取人脸图像建库、工作与教育场所的情绪推断、基于生物特征推断受保护属性、公共场所实时远程生物识别等受限用途），以及高风险用例若未经下游提供者自行完成合格评定即不得投入使用的提示。注意第 25(1) 条：下游主体若以自身名义或商标投放系统、对高风险系统作出实质性修改、或改变 AI 系统的预期用途使其成为高风险，将被视为提供者；模型卡里的用途边界说明有助于让下游理解自己何时会跨过这条线。

   需要附的证据

   • · 预期用途与目标用户说明
   • · 适用边界表（语言、领域、输入规格、数据截止、性能下降区）
   • · 禁止用途清单（含第 5 条禁止性实践对照）
   • · 高风险用例提示与下游责任说明（第 25(1) 条）
   • · 用途限制在合同、许可与 API 条款中的落地条款

   常见失分点

   • · 禁止用途只写"不得用于违法目的"，对下游没有任何实际指引；
   • · 预期用途写得极宽以扩大市场，反而使自己无法主张下游超范围使用；
   • · 模型卡写了限制但合同与 API 条款里没有对应条款，限制不可执行；
   • · 未提示下游"改变预期用途可能使其成为提供者"，后续责任争议无依据。

3. 3. 三、训练数据与训练过程概览

   对应附件 XI 第 2(b)(c)(d)(e) 项与附件 XII 第 2(c) 项：模型与训练过程的设计规格，包括训练方法与技术、关键设计选择及其理由与假设、模型的优化目标与各参数的相关性（如适用）；训练、测试与验证所用数据的信息（如适用），包括数据的类型与来源、数据整理方法（如清洗、过滤等）、数据点数量、其范围与主要特征、数据如何获得与选择，以及为检测数据来源不适当性所采取的全部其他措施和检测可识别偏差的方法（如适用）；训练所用计算资源（如浮点运算次数）、训练时长及其他相关细节；模型的已知或估计能耗——若能耗未知，可基于所用计算资源的信息估算。本节与 GPAI 训练内容公开摘要、数据卡三者必须口径一致：公开摘要是面向公众的法定披露，数据卡是面向内部与审计的详细档案，模型卡本节是面向下游的概览。三份材料对同一事实给出不同数字，是尽调中最容易被发现的矛盾。

   需要附的证据

   • · 训练配置记录（数据配比、训练阶段、超参、检查点）
   • · 数据来源与整理方法说明（与数据卡交叉引用）
   • · 偏差检测方法与结果
   • · 算力与训练时长记录（FLOP 估算方法说明）
   • · 能耗数据或基于算力的估算方法与假设
   • · 与 GPAI 公开摘要的数字勾稽核对表

   常见失分点

   • · 模型卡里的训练数据规模与 GPAI 公开摘要 1.3 节勾选的区间对不上；
   • · 能耗一栏写"未知"却未按法条允许的方式基于算力给出估算；
   • · 偏差检测只写"已进行评估"，无方法与结果；
   • · 训练时长与算力用营销口径（"数千张卡训练数月"）而非可核查数据。

4. 4. 四、评测方法、结果与分组表现

   给出评测集、指标与结果三件套，并明确每一项的局限。评测集：来源、规模、构造方式、与训练集的隔离证据、是否公开可复现、覆盖的语言与人群。指标：能力指标（任务准确率、通过率）、安全指标（有害内容生成率、越狱成功率、拒答率与过度拒答率）、稳健性指标（对抗输入、分布外输入、提示注入）、以及事实性指标（幻觉率及其测量方法）。结果：给出置信区间或多次运行的方差，而不是单点数字；按语言、地域、人群分组报告，缺失的分组明确标注为未评测而非默认合格。对系统性风险模型，附件 XI 第 2 节还要求：评测策略的详细描述，包括基于可获得的公开评测协议与工具或其他评测方法的评测结果，评测策略应包括评测标准、指标与识别局限的方法；以及为进行内部和/或外部对抗性测试（如红队测试）、模型适配（含对齐与微调）所采取措施的详细描述（如适用）。把红队测试的范围、参与方、发现与处置一并写入，是欧盟与新加坡客户尽调中加分最明显的一节。

   需要附的证据

   • · 评测集说明与隔离证据（去重方法、污染检测结果）
   • · 评测报告全文（含指标定义、测量方法、运行次数与方差）
   • · 分组结果表（语言/地域/人群，含未评测标注）
   • · 红队测试计划、参与方、发现清单与处置记录
   • · 对齐与微调措施说明（系统性风险模型）
   • · 评测结果与上线阈值的对应关系

   常见失分点

   • · 只报公开榜单分数，不报安全与稳健性指标；
   • · 评测集与训练集存在污染，未做去重或污染检测；
   • · 分组结果只报表现好的语言，其余语言默认省略；
   • · 红队测试写了"已开展"但无发现清单，读者无法判断深度；
   • · 指标定义不清（如"幻觉率 3%"未说明如何判定幻觉）。

5. 5. 五、已知局限、失败模式与风险

   这一节的价值与其诚实程度成正比。分四类写：能力局限（做不了什么、在哪些任务上表现不稳定）、失败模式（会以什么方式出错——幻觉、过度自信、格式崩溃、长上下文遗忘、多轮漂移、工具调用错误）、安全风险（有害内容、越狱、提示注入、数据外泄、被用于自动化滥用）、以及社会技术风险（训练数据偏差导致的差别表现、刻板印象强化、对特定群体的表征不足）。每一类给出触发条件、观察到的频率或量级（有数据用数据，无数据说明为定性判断）、以及建议的下游缓解措施。把缓解措施写具体——输入长度限制、系统提示模板、输出过滤、人工复核门槛、限流与滥用检测——下游提供者据此才能完成自己的风险管理。值得注意的是，第 13 条对高风险系统使用说明的要求与本节高度重合：若模型将被集成进高风险系统，本节写得越扎实，下游完成第 13 条义务的成本越低，这本身就是商业竞争力。

   需要附的证据

   • · 局限与失败模式清单（触发条件、频率/量级、证据来源）
   • · 安全测试结果（越狱、提示注入、数据外泄）
   • · 分组表现差异的量化结果
   • · 建议缓解措施清单与其有效性验证
   • · 已知问题的跟踪台账（发现日期、状态、修复版本）

   常见失分点

   • · 局限一节写成免责声明（"模型输出仅供参考"），没有任何可操作信息；
   • · 只写通用大模型共有的局限，不写本模型特有的失败模式；
   • · 安全风险一栏回避越狱与提示注入，而客户安全问卷必问；
   • · 建议缓解措施写"建议人工复核"，未给出复核门槛与触发条件。

6. 6. 六、集成指引与下游义务提示

   对应附件 XII 第 2(a)(b) 项：将通用人工智能模型集成进 AI 系统所需的技术手段（如使用说明、基础设施、工具）；输入输出的模态与格式及其最大规模（如上下文窗口长度等）。除技术内容外，本节还应主动提示下游的法定义务，这既是第 25(2) 条与第 25(4) 条配合义务的体现，也是减少后续纠纷的有效方式：若下游把模型集成进高风险 AI 系统，其需要完成第三章第 2 节的要求与合格评定，并可能需要本模型提供者依第 25(4) 条提供必要信息、能力、技术访问与协助；若下游服务将与自然人直接交互，需履行第 50(1) 条告知义务；若输出为合成音频、图像、视频或文本，需按第 50(2) 条做机器可读标记；若涉及深度伪造或情绪识别，需履行第 50(3) 条披露。中国境内提供服务的下游还需注意生成合成内容标识与算法备案要求。建议同时给出一份"下游义务对照表"，列出常见集成场景与对应的义务清单，并说明本公司可提供哪些配合材料（技术文档节选、标识实现说明、评测数据、安全问卷标准答复）。

   需要附的证据

   • · 集成文档（API 规格、SDK、部署要求、上下文窗口与规模限制）
   • · 下游义务对照表（集成场景 → 适用义务 → 可提供的配合材料）
   • · 第 25(4) 条配合安排的书面说明与响应时限承诺
   • · 合成内容标记的技术实现说明（供下游继承或验证）
   • · 标准安全问卷答复包与其更新记录

   常见失分点

   • · 只给 API 文档，不提下游的法定义务，客户在集成后才发现自己成了提供者；
   • · 合成内容标记只在自有产品侧实现，未向下游提供可继承的实现或说明；
   • · 第 25(4) 条配合承诺写在模型卡里但合同中没有对应条款；
   • · 上下文窗口等规模限制未写明，下游在生产环境才遇到截断问题。

7. 7. 七、安全措施、治理与责任主体

   说明模型层面已内置的安全措施与其边界：训练阶段的数据过滤与对齐、推理阶段的输入输出过滤、拒答策略、速率限制与滥用检测、以及这些措施在何种情况下会失效。明确区分"模型自带"与"需要下游自行实现"的部分，避免下游误以为模型侧已经解决全部内容安全问题。治理部分写明：模型的责任主体（哪个法律实体）、内部审批与发布门禁（哪些评测必须通过才能发布）、安全事件的接收与响应渠道、漏洞披露政策（研究者如何报告问题、响应时限、是否有安全港条款）、以及模型下线或弃用的政策与提前通知期。对系统性风险模型，还应说明依第 55 条所采取的评测、系统性风险缓释、事件跟踪报告与网络安全保护安排的概要。责任主体与联系渠道必须真实可达——很多模型卡在这一栏填了一个从不查收的邮箱。

   需要附的证据

   • · 安全措施清单（模型侧 / 需下游实现，分别标注）
   • · 发布门禁配置与最近若干次发布的门禁通过记录
   • · 漏洞披露政策全文与历史响应记录
   • · 安全事件接收渠道与响应时限承诺
   • · 模型弃用政策与既往下线通知记录
   • · 责任主体的法律实体信息与联系人

   常见失分点

   • · 把模型侧过滤描述成完整的内容安全方案，下游因此未做任何输出侧防护；
   • · 漏洞披露邮箱无人查收，研究者转而公开披露；
   • · 发布门禁存在但可被业务压力绕过，且绕过无记录；
   • · 模型突然下线无提前通知，下游生产系统中断。

8. 8. 八、版本历史、变更记录与文档维护

   模型卡必须与在跑的模型同步，否则它的全部价值都会被质疑。写明：模型卡的版本与对应的模型版本区间；变更记录（每次模型版本变化带来的能力、局限、安全表现变化，以及模型卡相应更新的内容）；更新触发条件（模型权重更新、基座模型更换、评测结果显著变化、新增或移除能力、新增语言或模态、安全事件后的修订、适用法规变化）；以及文档负责人与复核周期。建议把"更新模型卡"作为模型发布流程中的一个硬性门禁，与评测报告、安全测试并列。对以 API 提供服务的模型，还要说明"静默更新"政策：是否会在不改变版本号的情况下更新模型，如果会，下游如何得知——这是企业客户在合同谈判中必问的一条，也是模型卡可信度的试金石。

   需要附的证据

   • · 模型卡版本历史与对应模型版本区间
   • · 变更记录（能力/局限/安全表现的变化与证据）
   • · 更新触发条件清单与发布门禁配置
   • · 静默更新政策与下游通知机制
   • · 文档负责人与复核周期安排
   • · 历史版本的可访问归档

   常见失分点

   • · 模型已迭代多版，模型卡仍是首发版本；
   • · API 侧静默更新且无任何通知，下游的评测结果一夜失效；
   • · 变更记录只写"性能提升"，不写局限与安全表现的变化；
   • · 历史版本不可访问，下游无法回溯自己当初基于哪一版做的风险评估。