责任缺口：当AI智能体造成伤害时，谁来负责？

AI智能体正在采取具有实质影响的行动：执行照护协议、批准金融交易、在关键基础设施中路由资源。当这些行动造成伤害时——这早晚会发生——必须有人承担责任。但智能化AI的架构将因果链分散到多个参与方，而现有的责任框架并非为此而设计。责任缺口不是留待未来监管机构解决的理论问题，而是智能体构建者现在就在解决——或推迟到更糟糕时刻才面对——的实际工程问题。

分散行动的问题

传统责任法假设存在一个可识别的责任主体。当人类专业人员造成伤害时，问责路径是清晰的：专业人员本人、其所在机构、其所受的职业训练标准。但当AI智能体造成伤害时，因果链同时分散于：训练模型并塑造其行为倾向的开发者；在特定环境中配置并部署它的运营方；其指令触发行动的用户或机构；以及智能体所遵循的监管框架或机构政策。每一方都作出了贡献，但没有一方像专业人员行动时那样是直接的行动者。哪一方应承担责任、以何种比例、依据何种法律理论——这些问题无法套用为人类行动者构建的框架来干净地回答。

这不是抽象难题。在照护环境中，如果智能体对临床警报进行了升级处理或降低优先级，且由此造成了伤害，那么模型训练、运营方配置、用户情境与机构协议各自的因果贡献是相互交织的。事后尝试分配责任的法院或监管机构，将面对不完整的信息——除非智能体的架构本就被设计为记录发生了什么、以及在谁的权威下发生的。

"我遵循了配置"的局限

大多数已部署智能体的隐式责任立场是：运营方配置了系统，因此运营方对结果负责。这作为初步近似是合理的，但在最重要的案例中会失效。配置是提前写就的，基于的假设在智能体实际行动时可能已不成立。一个正确执行了配置行为、但忽视了理性人在相同处境下本应采取行动的可用情境信息的智能体——如恶化的患者指标、异常的交易模式——可能因判断失误而造成了开发者和运营方都未曾明确授权、也未曾预期的伤害。

开发者和运营方都无法直接说"这在我们设定的参数范围内"；智能体也无法说"我运用了判断"，它只能说"我遵循了参数"。两种归因都是不完整的。责任缺口就存在于两者之间的空白处。

审计追踪作为责任锚点

能够（部分）弥合这一缺口的，是完整且可信的记录。如果智能体为每一个具有实质影响的行动生成：一条带时间戳的日志——记录其收到的指令、来自哪位委托人、它所解析的权威链、行动时刻可访问的上下文输入，以及它采取的行动——那么责任就可以凭证据而非推断来分配。这就是为什么覆写日志不仅仅是产品护城河：它是一份法律文件。其缺失使责任分配沦为事后以降解信息进行的猜谜游戏；其存在则为分散因果链中的四个参与方创造了问责界面，使各方能够理解并展示自己所扮演的角色。

关于覆写日志的文章论证了，每一次人工覆写的校准记录会复利为竞争优势。责任论证是其镜像：每一个智能体行动的校准记录——在可识别的权威下采取、以可恢复的上下文记录——同样是受监管运营最终可以依托的基础。这不是对同一记录的两种不同动机——而是相互强化的动机。

硬件证明与证据链

审计追踪之下还有一个更难的问题：追踪记录本身的来源可靠性。由软件生成的日志条目可能遭到质疑——被篡改、选择性省略，或由被入侵的系统伪造。审计记录的责任价值完全取决于该记录的完整性，而纯软件日志无法提供能够经受严肃证据质疑的完整性保证。

这正是硬件关键领域与问责架构关键领域交汇之处。在可信执行环境内生成、并由硬件根密钥签名的智能体日志——硬件本身可以证明该密钥的存在与完整性——具备纯软件日志所不具备的证据效力。智能体的行动不仅被记录；记录方式使其无法在事后被悄然篡改。这一区别在任何严肃的责任争议中都将举足轻重，在监管审计、机构审查和保险评估中亦然。硬件证明的审计追踪是证据；纯软件日志是主张。为前者而设计，是在那些迟早会检验这一差异的领域运营的前提条件。

从一开始就构建具备责任能力的架构

具备责任能力的架构无法在部署被证明具有实质影响后再行补加。问责基础设施必须在第一个具有现实影响的行动发生之前就已就位——因为将受到最严格审视的，恰恰是那些早期事件、边缘案例、智能体以无人预见的方式行动的时刻。如果记录未从一开始就内置于系统中，那些时刻便无法事后重建。

具备责任能力的架构所需要的，不是一份新的合规清单，而是本系列文章反复审视的那些原语：显式的委托人层级而非隐式的优先规则；结构化的同意与授权记录而非配置注释；硬件证明的审计日志而非纯软件事件记录；在智能体边界处使用能够经受后量子转型的密钥材料对行动进行密码学签名。这些要素各自都有独立的信任与安全理由，合在一起则构成了监管机构、机构合作伙伴和法律程序在审查智能体行动时所需的证据基底。

携带这一基础设施进入受监管领域的智能体，才能随时间获得扩展的操作权限。没有这一基础设施的智能体，将在最糟糕的时刻、以最不利于补救的条件，将责任风险作为驱动力来面对。责任缺口是真实存在的，也是可以弥合的——但只有将问责架构视为首要部署要求而非事后补救的构建者，才能做到这一点。