通用目的 AI 提供商交了文档，下游团队还要证明什么？
提供商文档包只是下游证明的输入，不是合规结论。用“提供商—下游”双栏交接清单，找出采购签字前仍缺少的用途、集成、测试和责任证据。
重点监测信号
- 提供商文档已经收到，但没有负责人把其中的限制和集成说明对应到下游用途
- 采购或集成验收日期临近，测试证据、变更处理或责任人仍未说清
- 团队需要的是一张可用的证据映射表，而不是再转发一次提供商文档包
提供商交来的文档包，不是下游团队的合规证明，只是证明过程的一项输入。欧盟《人工智能法案》要求通用目的 AI（GPAI）模型提供商向下游 AI 系统提供商交付足以理解模型能力、限制并帮助其履行自身义务的信息。下游团队仍要说明：做了什么系统、预期用途是什么、如何集成模型、哪些限制会影响该用途、测试了什么、谁接受尚存风险，以及模型更新后怎么处理。
AI 治理咨询公司的商务拓展负责人，可能正在自己有权访问的模型开发者、集成商、采购和 AI 治理 Telegram 群里寻找需求。“附件 XII 文档已收到”本身不是项目。更值得看的组合是：验收或上线决定已经带日期，但提供商材料与下游证据之间仍断着。如果晚一天才看到，采购可能已经签字，证据缺口也会变成无人负责的合同假设。
定义：一次交接有两份记录，不是一个 PDF
Regulation (EU) 2024/1689 第 3(63) 条对 GPAI 模型的定义强调显著通用性、完成多种不同任务的能力，以及被集成进不同下游系统或应用的可能。“下游”首先描述一种集成关系，并不表示上游提供商会继承成品应用中的所有决定。
第 53 条与附件 XII 要求 GPAI 提供商准备并维护技术文档，同时向准备集成模型的 AI 系统提供商提供指定信息。内容包括任务与模态、可接受使用政策、发布方式、集成要求、输入输出格式、技术特征、能力和限制等。它让下游“有条件理解并履责”，却不会替成品系统发合规证书，也没有普遍要求提供源代码。
下游证据从文档包结束的地方开始：实际用途、系统边界、数据流、配置、人工监督、测试和组织决定。如果团队说成品系统属于高风险、并非高风险，或适用另一层规则，都要根据该系统的预期用途和适用条款留下理由。仅仅使用 GPAI 模型，不会让所有下游系统自动成为高风险系统。
读群消息前要核对的关键事实
- 第 53 条规定 GPAI 提供商的基础义务，包括技术文档、下游信息、版权合规政策，以及对训练内容作足够详细的公开摘要。
- 第 51 条处理“具有系统性风险的 GPAI 模型”分类，第 55 条为其提供商增加义务，不能把这些附加义务套给每个 GPAI 模型。
- 第 54 条在法规条件下处理欧盟境外提供商的授权代表；授权代表不会替代下游集成商自己的证据。
- 第 113 条设置分阶段适用日期。帖子引用某个日期，仍不能证明具体模型、系统或组织落在适用范围内。
- 欧盟委员会的GPAI 提供商义务指南 FAQ解释委员会的适用理解；自愿性的通用目的 AI 行为准则可以帮助合规，但不能取代有约束力的法规，也不能替下游记录自己的系统。
双栏交接清单：每项输入都要落到自己的证据
不要只问“文档有没有”。把提供商输入放左边，把必须由下游补齐的记录放右边。空格比绿色文件夹图标更能说明问题。
| 提供商侧：已经收到的材料 | 下游侧：仍由本地负责的证据 |
|---|---|
| 模型身份、版本、发布渠道和分发条件 | 实际部署版本、集成日期、系统边界和变更批准人 |
| 预定任务、模态、能力和已知限制 | 成品系统的预期用途、禁止用途，以及哪些限制会影响该用途的决定 |
| 可接受使用政策与受限用途 | 产品中实际执行的规则、访问控制、用户说明和配置证据 |
| 集成说明、输入输出格式和技术要求 | 提示词、检索数据、输出、日志与人工复核所在位置的数据流记录 |
| 提供商评估信息与性能边界 | 针对实际用途的测试计划、场景、结果、失败处理和验收标准 |
| 模型更新与支持信息 | 变更触发器、重大变更判断、回归计划，以及有权暂停或回滚的负责人 |
| 提供商的版权政策与训练内容摘要材料 | 下游对输入权利、输出处理以及实际服务所需额外控制的决定 |
这张表是本文提出的交接工具，不是新的法律标准。它只做一件实用的事：避免把提供商事实误当成下游决定。提供商可以准确说明模型接受文字和图片；只有集成商知道自己的产品允许哪些输入。提供商可以交付基准测试；只有下游团队能解释自己的测试场景为何符合预期用途。
示例：“包齐了”，右栏却还是空的
下面是为说明而写的复合 Telegram 消息，不对应任何客户或私有群：
“供应商昨天把 GPAI 技术包发来了，采购要周五验收。”
“里面有模型限制，但集成商只在工单贴了 PDF。”
“客服回答流程的测试归谁？我们上周刚改过检索。”
消息没有公司、模型、合同、系统分类、预算或测试结果，不能标成已确认商机。但它给出了一个明确决定——周五验收，也暴露了具体断点：模型限制确实存在，却没有人把它对应到刚改过的检索流程，更没有测试负责人。
第一句跟进应收得很窄：“周五验收前，谁负责把提供商限制对应到现在的检索配置和测试证据？”答案可能点出负责人和已安排的评审，也可能证明问题已经解决。无论哪种，都比把一次索取文档猜成完整治理项目更可靠。
最强反方：提供商已经做了大量评估
成熟提供商可能交付详细评估、集成说明和模型变更通知，确实能减少很多下游工作。但它无法描述自己并不运营的应用里，每一个数据来源、用户群、人工复核步骤、检索层和业务后果。
另一侧的边界同样重要：下游不该重复制作已经收到的提供商文档，不该为了填清单就索要源代码，也不能把所有未知都算成提供商失职。双栏清单按“谁有能力产出”分配证据。如果右栏每项都已有负责人、保持最新并对应实际用途，那可能根本没有咨询需求。
想看更大的时间背景，可对照AI 法案 2026 年 8 月需求信号；要核对训练政策讨论中的具体问法，可看AI 训练政策检查。如果团队随后询问获授权群消息发现如何计费，价格页列出了公开方案，但不会改变上面的证据判断。
TOP Prospect 只处理用户主动连接且有权访问的 Telegram 群，可筛选、合并、去重和排序相关片段，并保留原消息、来源和时间供人工复核。它不能认证法律适用范围、查看私有集成、把缺失证据补成事实、联系发帖人或决定下游系统是否合规。
常见问题
收到附件 XII 信息，就证明下游合规了吗？
不能。它帮助下游理解模型并履行自身适用义务；系统、预期用途、集成、测试、控制和决定仍要由下游记录。
GPAI 提供商必须向下游交付源代码吗？
附件 XII 指定的是能力、限制、集成和技术特征等信息，并未普遍要求交付源代码。
使用 GPAI 的 AI 系统都会成为高风险系统吗？
不会。GPAI 集成与高风险分类是两回事，分类取决于下游系统、预期用途和适用标准。
什么情况下值得做商务复核？
当集成、验收或上线决定有明确日期，而团队无法把提供商输入、下游证据和未决缺口交给具体负责人时，就值得复核。清单只能暴露这种状态，最终仍要由人跟进确认。
常见问题
收到附件 XII 所列信息，是否证明下游 AI 系统符合欧盟 AI 法案？
不能。这些信息用于帮助下游提供商理解 GPAI 模型并履行自身适用义务；下游仍要按实际情况记录系统、预期用途、集成、测试、控制和决定。
GPAI 提供商必须向下游交付源代码吗？
附件 XII 要求的是能力、限制、集成和技术特征等信息，并未普遍要求交付源代码。
使用 GPAI 模型的下游系统都会成为高风险 AI 系统吗？
不会。GPAI 集成与高风险分类是两个问题，后者取决于下游 AI 系统、预期用途以及法规中的适用标准。
什么情况下这次交接值得做商务复核？
当集成或采购决定有明确日期，而团队无法把提供商输入、下游证据和未决缺口分别交给负责人时，就值得复核。
资料来源与延伸阅读
值得关注的潜在线索 Signal 是怎样被发现的
了解 Top商业线索怎样发现和整理值得核实的 Signal、保留 Telegram 原始上下文、去掉重复消息并安排查看顺序。是否跟进以及下一步做什么，仍由用户决定。
