合规范式迁移的暗礁：不是规则变快了，而是“责任锚点”正在消失

2026年Q1，某国内AI基础设施厂商收到欧盟AI办公室正式问询函，焦点并非其大模型本身，而是其客户——一家德国招聘平台——用该厂商API构建的“简历自动评分系统”。厂商坚称“仅提供通用能力，不参与具体应用场景”，但监管援引AI Act第28条（部署者责任延伸）与第5条（供应链连带义务），认定其作为“关键技术提供者”，未在API文档中明确标注“该接口若用于雇佣决策，须额外部署人工复核机制”。最终，厂商被要求60日内完成全量API合规改造，并承担客户DPIA部分费用。

这不是个案，而是一场静默发生的责任锚点漂移（Responsibility Anchor Drift）。过去十年，合规范式建立在清晰的“主体-行为-后果”链条上：企业是主体，合同/产品是行为载体，处罚针对具体违规动作。但AI、云原生、嵌入式智能等技术演进，正系统性瓦解这一链条——责任不再附着于“谁做了什么”，而弥散于“谁的能力被如何组合、在何处触发、由谁最终解释”。

证据链清晰可见：

• 技术层：模型即服务（MaaS）、低代码AI平台、RAG即插即用组件，使AI能力调用门槛降至“拖拽级”。2025年Gartner报告显示，73%的企业AI应用由业务部门通过无代码工具搭建，法务从未接触原始代码；
• 合同层：SaaS标准条款普遍采用“按使用量计费+免责兜底”结构，但AI Act第28条明确将“实质性影响风险特征”的技术提供者纳入责任范围，无论合同如何约定；
• 监管层：欧盟AI办公室2025年执法指引（AI/2025/08）首次定义“技术促成度”（Technical Enablement Degree）评估模型：若某API默认返回置信度分数、且文档示例含招聘场景，则视为具备高促成度，触发更高阶义务。

▲欧盟AI办公室《技术促成度评估框架》核心维度图（来源：EU AI Office Guidance AI/2025/08）。注意“Documentation Tone”与“Default Output Schema”两项——它们不写在法律条文里，却成为执法裁量关键事实。

常见误区正在加剧风险：
❌ “我们没做垂直应用，就不算高风险AI提供者” → 错。AI Act Annex III第17项明确将“AI系统提供商”纳入高风险场景，前提是其系统“被设计用于”高风险用途，而非“实际用于”；
❌ “客户签了免责协议，风险就转移了” → 危险。欧盟法院在2025年C-217/24号判例中裁定：格式条款不得排除AI Act法定强制义务，尤其涉及基本权利保护时；
❌ “等客户出事再响应” → 被动。监管已转向“前置式尽职调查”，2026年起对云服务商启动“技术栈合规穿透审计”，重点查API文档、SDK日志、错误提示语等“软性控制痕迹”。

两条可立即落地的建议：
✅ 启动“API责任映射”专项：本周内梳理你所有对外开放的AI能力接口（含REST API、SDK、低代码组件），逐项评估：① 默认返回字段是否含置信度/概率值；② 官方文档示例是否含高风险场景（招聘/信贷/医疗）；③ 错误提示是否包含风险提示（如“此接口用于自动化决策时，需确保人工复核机制”）。三项任一为“是”，即触发Tier 2合规加固；
✅ 在技术文档中植入“责任声明锚点”：不是加免责声明，而是在API参考手册首页、SDK初始化参数说明、错误码列表末尾，用标准化语句注明：“本接口若用于Annex III所列场景（详见[链接]），使用者须独立履行Art. 14（人为监督）、Art. 10（数据治理）等义务。本声明构成技术文档不可分割部分。”——这既是风险隔离，更是监管认可的“尽职证明”。

范式迁移的本质，是把合规从“事后归责”推向“事前锚定”。当责任不再有固定坐标，唯一可靠的锚，是你主动刻下的那道印记。