AI API服务合同审查清单：服务范围、责任与合规边界

当企业完成模型能力试用、准备将AI API纳入正式业务系统时，采购难点通常不再是“接口能不能调用”，而是“服务是否可采购、可结算、可验收、可追责”。对于技术、采购、法务、财务和业务部门而言，AI API服务合同应被视为一份覆盖产品交付、数据治理、资金结算与持续运营的协作文件。

本清单面向处于供应商评估阶段的企业团队，帮助将技术验证、合同签署、企业结算、发票申请和正式上线串联为可执行的采购工作流。若需要先梳理全流程，可阅读企业采购AI API完整流程：从技术试用到正式上线。

一、签约前：确认采购主体、需求边界与审批材料

在审查AI API服务合同前，企业应先统一内部采购口径。许多合同争议并非由条款本身造成，而是因为技术团队试用时的需求描述，无法直接转换为采购订单、预算申请或验收标准。

采购立项核对清单

[ ] 明确签约主体、付款主体、实际使用主体是否一致。
[ ] 明确服务用途：内部效率工具、面向客户的产品功能、营销内容生成，或其他业务场景。
[ ] 列出拟采购的模型、API能力、调用区域、账户数量和预计使用周期。
[ ] 明确预计调用量、并发需求、峰值时段、响应时延及可接受的服务波动范围。
[ ] 确认试用账户、测试额度、沙箱环境与正式生产环境是否区分。
[ ] 确认采购预算的计价单位，例如按调用量、字符量、Token、图片数量、套餐额度或预付余额。
[ ] 准备内部立项、供应商准入、信息安全评估、法务审查及财务付款所需材料。
[ ] 明确业务负责人、技术接口人、采购经办人、法务审核人和财务对账人的职责。

建议在合同谈判前形成一份“需求与验收附件”。这份附件应避免仅写“采购大模型接口”或“支持智能问答”，而应写清可交付的接口能力、账户配置方式、调用限制、计费规则和验收条件。可结合采购AI API前需要准备哪些需求、预算与验收材料完善内部材料。

二、服务范围：把“能调用”写成可验收的合同交付

AI API服务合同的服务范围不应仅列出产品名称。对企业采购而言，服务范围需要能够回答三个问题：供应商具体提供什么、企业能够如何使用、服务未覆盖什么。

服务范围审查清单

[ ] 合同是否明确列出所采购的API名称、版本、模型能力和产品套餐。
[ ] 是否说明接口文档、SDK、管理控制台、密钥管理、调用日志等配套能力是否属于交付范围。
[ ] 是否明确测试环境、生产环境及正式账户的开通条件与时间。
[ ] 是否约定账户数量、子账户、项目空间或组织权限的配置规则。
[ ] 是否说明调用频率、并发上限、单次请求限制、内容长度限制及额度限制。
[ ] 是否明确服务地域、网络接入要求和可能影响调用的网络条件。
[ ] 是否约定模型版本更新、接口升级、旧版本下线时的通知期限和迁移安排。
[ ] 是否明确供应商有权调整的事项，以及价格、模型能力、计费规则等重大变化的处理机制。
[ ] 是否列明不包含的服务，例如定制开发、业务效果承诺、私有化部署、人工标注或系统集成。
[ ] 是否将宣传页面、销售承诺、技术方案中关键内容纳入合同正文或附件。

尤其需要避免将“模型效果”与“服务可用性”混为一谈。供应商可承诺接口可访问、计费规则清晰、平台功能按约提供，但通常不宜承诺生成结果在所有业务场景中的准确率、合规性或商业结果。企业应自行建立业务侧审核与人工复核机制。

三、费用、结算与发票：避免试用转采购后的对账返工

AI API采购常见问题是：技术团队按照试用方式充值或调用，财务部门却需要合同、订单、付款主体、结算周期与发票信息完整对应。因此，费用条款必须覆盖从额度购买到发票申请的完整闭环。

商务与结算审查清单

[ ] 明确合同金额是预付款、后付费、固定套餐还是按量结算。
[ ] 明确币种、含税或未税价格、税率、付款期限及付款账户信息。
[ ] 约定额度有效期、余额处理、过期规则及是否支持跨周期使用。
[ ] 明确超出套餐额度后的计费方式、扣费顺序和预警机制。
[ ] 确认调用明细、账单周期、对账口径和异议提出期限。
[ ] 明确退款、退费、服务中断补偿或未使用额度处理的适用条件。
[ ] 明确发票类型、开票内容、开票金额、申请路径和开票时间。
[ ] 核对合同主体、付款主体、发票抬头与企业实际报销主体是否一致。
[ ] 确认企业结算所需的营业执照、联系人、银行信息及采购订单材料。
[ ] 为财务留存合同、订单、付款凭证、对账单、发票和验收材料的归档路径。

对于从试用账户切换至正式服务的团队，应提前确认账户是否可以迁移、余额是否可继承、历史调用记录是否保留，以及正式合同生效前后的费用边界。可参考企业采购AI API常见问题：试用账户能否直接转正式服务，并通过企业AI API结算与开票流程：财务对账如何减少返工核对财务流程。

四、责任边界：区分平台责任、客户责任与业务责任

AI API服务具有“基础能力由供应商提供、业务输入和应用决策由客户控制”的特点。合同审查的重点不是要求一方承担所有风险，而是将不同风险放在实际可控制的一方。

责任分配审查清单

[ ] 明确供应商对平台运营、接口可用性、账户管理和计费准确性的责任。
[ ] 明确企业对输入内容来源、用户授权、业务流程设计和输出结果使用的责任。
[ ] 明确谁负责终端用户告知、投诉处理、人工复核和业务风险控制。
[ ] 明确密钥泄露、账户共享、异常调用和越权访问的通知与处置责任。
[ ] 明确服务中断、接口故障、数据传输异常时的工单、响应和恢复机制。
[ ] 审查责任限制条款是否清晰，包括赔偿范围、责任上限和免责情形。
[ ] 审查违约认定是否可操作，避免使用“严重影响”“合理期限”等无法判断的表述。
[ ] 明确第三方索赔、知识产权争议、违法内容和用户损失的处理流程。
[ ] 明确企业是否可以暂停调用、关闭密钥或终止账户，以控制业务风险。
[ ] 明确合同终止后账户、余额、日志、密钥和数据的处置安排。

企业尤其应防止业务部门将模型输出直接作为医疗、金融、法律、人事决策或其他高风险事项的最终依据。即使API服务稳定可用，具体业务决策责任通常仍应由企业根据场景建立审批、复核和留痕机制。

五、数据与合规：明确输入、输出、日志与跨部门权限

数据条款是AI API合同审查中最容易被泛化处理的部分。企业不能仅关注“供应商是否保密”，还应确认数据如何进入接口、是否被保存、谁能访问、日志保留多久，以及输出内容如何在企业内部使用。

数据与合规审查清单

[ ] 梳理接口输入中是否包含个人信息、敏感个人信息、商业秘密或受监管数据。
[ ] 明确企业提交数据的合法来源、处理目的和必要授权。
[ ] 确认供应商对输入、输出、调用日志和账户信息的处理范围。
[ ] 审查是否存在使用客户数据进行模型训练、优化或分析的约定，以及是否可选择退出。
[ ] 明确保留期限、删除机制、备份规则和合同终止后的数据处理方式。
[ ] 确认数据访问权限，包括企业管理员、开发人员、供应商运维人员和第三方支持人员。
[ ] 明确安全事件、数据泄露或异常访问的通知机制与协作义务。
[ ] 确认跨境传输、境外访问或第三方处理安排是否与企业内部制度匹配。
[ ] 对输出内容建立版权、事实准确性、歧视性表达和违规内容的业务审核机制。
[ ] 将数据分类分级、脱敏、最小化传输和密钥轮换要求落实到上线方案。

供应商资讯通常侧重模型能力、开发工具和行业动态，例如Source · news.qiniu.com提供了相关技术内容；但企业采购还需要补足合同、结算、验收和责任归属等执行层问题。对于WisGate的采购评估，应将这些非技术环节与API能力一并纳入供应商比较表。

六、上线验收与持续治理：让合同在生产环境中可执行

合同签署不是采购流程的终点。企业应将正式上线前的技术核验、权限配置、费用预警和运行留痕纳入验收机制，避免“合同已签、生产不可控”的情况。

上线验收清单

[ ] 核验正式账户、企业主体、套餐额度和生产环境配置是否正确。
[ ] 核验API密钥创建、保管、轮换、禁用和离职交接流程。
[ ] 核验调用权限是否遵循最小权限原则，测试密钥不得直接用于生产。
[ ] 核验额度预警、异常调用告警、预算阈值和停用策略。
[ ] 核验调用日志、错误日志、账单明细是否满足排障与对账需要。
[ ] 核验接口异常时的降级方案、人工接管流程和业务通知机制。
[ ] 核验合同附件、订单、验收单、付款材料和发票信息是否可追溯。
[ ] 明确月度或季度复盘责任人，持续检查费用、权限、数据及模型变更。

正式验收时，可使用AI API正式上线验收清单：密钥、额度、日志与权限核验作为技术与运营协同依据。

结论：将合同审查纳入AI API采购工作流

企业审查AI API服务合同，不应只关注价格和接口可用性，而应围绕服务范围、结算开票、责任边界、数据合规和上线验收建立统一清单。技术团队负责验证能力与集成可行性，采购团队负责商务条件与供应商材料，法务团队负责责任及合规边界，财务团队负责结算与发票闭环，业务团队则负责实际使用场景与输出治理。

当上述事项在试用转正式服务之前被明确，企业才能将AI API从一次技术实验，转化为可持续、可审计、可管理的生产能力。