模型调用审计平台里日志很多，事故发生后仍查不到具体人员，常见原因不是采集量不够，而是日志无法关联。网关记录了API密钥，应用记录了会话，模型服务记录了模型版本，知识库记录了查询，工具系统记录了动作，审批系统又在另一条链上。任何一段缺少统一事件ID、主体、时间或策略快照，最终都只能看到若干技术账号，无法说明谁代表谁做了什么。

适用场景：企业已经有模型网关、应用日志、模型服务、知识库或工具审计，但事故复盘仍依赖人工猜测、截图拼接和团队口头说明。

事故定责需要证据链，而不是日志堆积

技术审计能支持事实还原和管理追溯，但不能自动完成法律或组织责任认定。平台第一时间要回答的是：哪个主体顺利获得哪个应用和凭据发起请求，当时使用哪版策略、模型和数据，是否触发工具或外发动作，谁批准例外，最终产生什么结果。责任认定仍由企业制度和授权角色完成。

下图把主体、凭据、请求、策略、模型、数据、工具动作和审批串成八段证据链。阅读时从事故结果反向追溯，并检查每一段的真源、时间与完整性。

共享API密钥是常见断点：它能证明某个应用或技术主体调用了服务，却不能单独证明具体人员。请求ID若只在网关存在，进入模型、知识库和工具后被替换，也会让跨系统关联失效。审计平台的核心任务是管理关联和证据边界，而不是简单增加存储。

八段证据分别回答什么问题

主体：谁发起，谁代理

主体包括用户、服务主体、应用、租户、项目和代理关系。审计要区分真实用户和执行账号，记录认证方式、生效时间和组织归属。异步任务还要保存任务创建者、执行者和触发方式，避免批处理只剩一个后台账号。

凭据：用什么身份进入系统

API密钥、令牌或临时凭据应关联应用、主体、权限范围、创建和失效状态。日志不能保存明文密钥，但要有稳定的凭据标识用于追溯。凭据轮换后，历史事件仍应能回到当时的有效身份，而不是只看当前配置。

请求：哪一次调用形成事件

请求需要统一事件ID、父子调用关系、会话、时间、来源和状态。一个用户请求可能拆成多次模型调用、检索和工具动作，审计平台要保存调用树，不能把每个子调用当成互不相关的事件。

策略：当时为什么允许或拒绝

策略证据包括权限、配额、安全、路由和例外审批的版本与结果。只记录“允许”不足以解释原因，至少要知道决策点、策略版本和主体/资源范围。策略后来修改，不能覆盖历史判断。

模型：实际使用了什么

记录模型标识、版本或发布、路由结果、配置和调用状态。模型别名可能在不同时间指向不同版本，事故复盘要能回到当时的路由，而不是用现在的别名解释过去。

数据：读取了哪些来源

知识库、文档、数据域、检索片段和工具返回都属于数据证据。应记录资源标识、权限判断和来源，不一定保存完整内容。若内容含敏感信息，采用最小必要摘要和受控取证，避免审计平台成为新的数据泄露源。

工具动作：最终做了什么

模型提出Function Call不代表已经执行。需要记录工具、参数摘要、主体、目标资源、授权结果、执行状态、幂等标识和最终业务结果。超时和未知状态必须区别于成功，避免把“已提交”误写成“已完成”。

审批与例外：谁承担了偏离标准流程的决定

人工确认、临时放行、策略例外和事故处置要关联审批人、理由、范围、有效期和结果。例外到期后是否恢复、执行前策略是否变化，也应有记录。审批不是免责证明，而是说明当时的决策链。

为什么日志齐全仍然会断链

每个系统使用自己的ID

网关、应用、模型、知识库和工具各自生成请求ID，没有父子关系或跨系统透传。事后只能用时间和账号模糊匹配，容易把并发事件拼错。应定义统一事件ID或可验证的映射，并在异步任务中保留父事件。

时间不一致

不同系统时钟、时区、写入延迟和批量上报会让事件顺序错位。审计要记录事件时间和采集时间，明确时区，并监测时间偏差。不能只按日志文件顺序判断谁先发生。

共享凭据覆盖真实主体

应用统一使用一个密钥，后端看不到用户和代理关系。即使应用日志保存用户ID，如果没有与模型和工具事件关联，仍无法完成技术追溯。需要将主体、应用和凭据的关系写入事件或授权快照。

策略只保存当前版本

事故发生后策略已经修改，审计只能看到现在的配置。应保留策略版本、生效时间、变更人和当时决策结果，不一定保存全部内部实现，但要能解释历史。

日志只有成功/失败，没有业务结果

模型接口返回成功，不代表工具动作或下游业务成功。审计需要区分接受、执行中、成功、失败、取消和未知，并尽可能获取最终结果。否则定责会停留在“接口调用过”。

选型时要验证关联能力，而不是导出能力

审计平台演示常展示搜索和报表，但真正的POC应还原一条跨系统事件。选一个脱敏场景，让用户顺利获得应用调用模型、检索数据并触发一个受控工具，再从结果反向追到主体、凭据、策略和审批。检查每个字段来自哪里、是否完整、能否证明时间关系。

POC至少覆盖：

• 同一用户顺利获得两个应用发起相似请求，能否区分代理关系；
• 同一共享密钥代表不同用户时，能否回到具体主体；
• 一个请求拆成模型、检索和工具子调用，能否还原调用树；
• 策略在会话中途变化，历史和后续事件能否分别解释；
• 工具超时或重复执行，审计能否区分最终结果；
• 数据或日志敏感时，能否在最小化和取证之间切换。

如果平台只能把各系统日志集中存储，却不能管理事件映射、真源、策略版本和完整性，应把它定位为日志检索工具，而不是完整事故归因能力。

证据保全要兼顾完整性和最小必要

事故追溯需要证据，但不等于保存所有Prompt、响应、密钥和数据原文。审计字段应优先保存主体、应用、事件ID、资源、策略、模型、动作、结果和必要摘要。需要保全内容时，使用授权流程、受控存储、访问审计和明确期限，避免普通运维人员能够随意查看敏感信息。

完整性可以顺利获得真源引用、校验值、只追加事件、变更记录和访问日志等方式增强，具体实现按企业系统能力选择。导出证据也应记录导出者、范围、用途和后续处理，避免审计数据在下载后失控。

能定责的证据链不是内容越多越好，而是每段关系都能被验证且没有被后续变更覆盖。缺少某一段时，应明确“证据不足”，不要依据组织习惯推断具体人员。

用责任矩阵避免审计平台成为孤岛

身份团队负责主体和凭据真源，应用团队负责用户到应用的代理关系，模型平台负责请求、模型和路由，数据团队负责知识库和资源标识，工具系统负责动作与结果，安全审计团队负责关联、保全和复盘。平台可以统一查询，但不能凭空替代各系统的事实责任。

每个字段要有所有者、采集方式、质量检查、访问范围和故障处理。若应用没有传主体，审计平台无法在事后自动恢复；若工具不返回最终结果，模型平台不能证明业务动作完成。责任矩阵应进入POC和上线验收，而不是事故后才讨论。

相关治理内容可以查看 AI基础设施分类。若需要把模型调用、身份、工具和平台运营统一评估，可查看 AI解决方案，正式发布前核验链接状态。

下一步用一个脱敏事件反向追人

选择一个不含真实敏感内容的完整场景，从工具或业务结果反向追到模型、策略、请求、凭据和主体。为每一段标记真源、事件时间、采集时间、完整性、访问者和缺口，再修复最早的断链。完成后重复测试共享密钥、异步任务、策略变更和工具超时。

模型调用审计平台的选型结论应说明一次事故能追到什么粒度、哪些证据仍依赖其他系统、哪些内容因最小化而不保存，以及最终责任由谁认定。日志存在只是起点，证据可关联才是事故追溯的基础。

常见问题

模型调用日志至少要记录哪些关联字段？

至少应覆盖主体、应用、凭据标识、统一事件ID、父子调用关系、会话、时间、模型与版本、策略版本、资源或数据来源、工具动作、授权结果和最终状态。字段不一定全部由模型服务生成，但必须明确真源和关联方式。事件时间与采集时间应区分，异步任务要保留创建者和执行者，模型别名要能回到当时实际版本。

日志内容还要遵循最小必要，不默认保存完整Prompt、响应、密钥或敏感数据。普通请求可以保留必要摘要和状态，高风险事件在授权流程下增加证据。字段质量比数量重要：主体为空、事件ID断链、策略只有当前版本或工具只有“成功”状态，都会削弱追溯。POC应拿一条跨网关、模型、知识库和工具的事件验证，而不是只检查字段列表。

共享API密钥还能否追溯到具体人员？

仅凭共享API密钥通常不能可靠追到具体人员，因为它只能证明某个应用或技术主体使用了凭据。要进一步追溯，需要应用在调用时带入经过认证的真实主体、代理关系、会话和统一事件ID，并让后端模型、知识库和工具事件继续保留这些关联。应用日志中的用户ID如果没有与后端动作绑定，只能作为旁证，不能自动证明具体人员完成了动作。

改进可以从短生命周期或按应用细分的凭据、代理身份字段、请求签名、资源授权快照和工具结果开始。历史事件若没有这些证据，应明确记录定责粒度不足，不顺利获得时间猜测人员。共享密钥还要有最小权限、轮换、失效和使用审计；即使后续能关联用户，也不能让一个过宽凭据绕过资源授权。

审计证据链是否意味着保存完整Prompt和响应？

不意味着。证据链的目标是证明主体、凭据、请求、策略、模型、数据、动作和结果之间的关系，很多情况下可以顺利获得事件ID、资源标识、版本、状态和必要摘要完成。完整Prompt和响应可能包含个人信息、商业数据、系统指令和凭据，长期集中保存会扩大访问面，让审计平台成为新的高风险数据源。

可以采用分层保全：普通事件保存最小关联字段，高风险动作保存脱敏后的参数与结果摘要，事故发生时顺利获得审批保全必要原文，并限制访问、导出和期限。还要记录谁查看和导出了证据。若内容不保存导致某类复盘无法完成，应在审计边界中说明；若决定保存，也要有数据分类、加密、删除和备份处理。具体策略应由企业制度和适用要求决定。