怎样证明一次 AI 操作是谁发起、用了什么数据、由谁批准？建立任务级审计链

先看结果：360个采购变更任务，旧日志只有92个能完整证明，任务级审计链提高到344个

澄岳精密让AI协助采购员处理缺料后的采购订单变更。系统读取原采购订单、供应商报价、库存与在途、生产缺口、预算和审批规则，生成变更建议；人决定接受、修改、拒绝或升级，批准后才由采购系统执行。AI没有采购批准权，也不能凭一句“已审批”直接改变订单。

团队从六周后台只读与沙箱运行中选出360个任务，要求独立审查者在30分钟内证明五件事：谁发起及代表谁、使用了哪些当时有效的数据、AI和人各生成哪个版本、谁依据什么权限批准哪个对象、企业资源计划系统最终执行或未执行什么。旧流程把登录、模型、办公自动化审批和业务系统日志分开，只有92/360=25.56%达到审计就绪；104个能拼出大致过程但缺一个关键证据，138个无法确定批准对象或数据版本，26个系统间记录相互矛盾。

改造不是把AI回复多存一份。每个任务建立不可变实体、活动、参与者和决策关系；数据访问引用当时版本与用途；AI产物、人工修改和最终执行各自有哈希与父版本；批准绑定准确产物、金额、动作、条件和到期时间；企业资源计划系统针对同一操作意图返回业务回执。审查者从任务编号生成最小证据包，不再依靠四个团队分别截图。

本文企业、采购任务、360个样本、金额、时间、指标和结果均为虚构教学案例，不是客户审计结果或行业基准。文章提供工程与治理设计，不构成法律、财务、采购、内控或合规意见；证据要求、电子签名、职责分离、保留期和可接受审批方式必须由组织根据适用规则确定。

本文解决“谁对哪个决定负责”：可观测追踪、业务审计和合规结论不能混成一件事

E23的追踪用来解释系统为何产生结果：哪个提示词、上下文、工具与渲染器参与。任务级审计则证明主体、权限、对象、决定和影响，强调责任链与证据完整性。同一个追踪编号可以成为审计链的技术关联键，但一个追踪片段成功不证明用户拥有采购授权，一段模型解释不证明人员实际批准，仪表盘截图也不证明企业资源计划系统已经执行。

“审计链”在本文是组织设计的可查询证据图，不宣称自动满足任何法规或外部审计。审计员仍要判断证据来源、完整性、例外和适用控制；系统只能让事实可复核，不能替审计员签结论。

AI也可在来源里作为软件智能体，表示它参与生成实体；这不把法律或管理责任转给模型。人、组织和服务账号分别记录，最终批准权落在组织政策指定的自然人/角色。界面写“AI 批准”应被禁止，正确词是AI 提议、规则通过或人工批准。

审计链以任务为边界：一次采购变更从发起到取消/执行/失败/过期。跨任务复用的来源与策略仍有自己的版本；一个审批不得因同供应商、同用户或同对话自动覆盖另一个任务。若范围太大到“本月所有采购”，应拆成明确授权计划与每次执行证据。

先写责任与权限表：没有权限图，记录再完整也只证明“有人点过按钮”

团队先把角色、允许动作、金额与数据范围、前置条件、冲突和最终责任写清。采购员可以发起与编辑，但不能批准自己超过阈值的变更；品类经理批准低风险范围；采购总监与财务控制人共同批准高金额；供应商主数据与银行信息另需专门负责人；AI只做建议、校验和路由；执行服务只能消费已经有效批准的操作意图。

权限来自策略与当前委派，不来自职位名称字符串。每个角色都要有权限依据编号、生效起止时间、范围、限制、冲突规则与撤销来源；决策记录当时采用的权限快照和哈希。员工后来调岗，历史批准仍按当时事实解释；若后来发现批准无效，就追加裁决，不能回写成仿佛从未发生。

职责分工表只能说明谁执行、谁最终负责、咨询谁、通知谁，不足以授权。真正可执行的审批策略还要写对象类型、金额、地区、品类、风险与组合规则。正文后续的规则引擎消费的是这些具体条件，而不是角色缩写。

职责分离不是“至少两个人点”。两次点击如果来自同一主体的两个账号、发起人的代理身份或共享账号，都不能满足独立批准。系统按个人、组织主体和委托链识别独立性，并对利益冲突、临时代理和紧急越权另行处理。

最后指定证据负责人：身份团队负责认证与委派，采购治理负责授权策略，数据负责人负责来源版本，AI产品负责产物谱系，业务系统负责人负责影响回执，内审与风险团队批准证据包规则。没有负责人的字段很快会失真。

用实体、活动、参与者和决策建图：一串按时间排列的文本还不是可查询的审计链

W3C PROV把溯源的基础概念分为实体、活动与参与者：活动使用或生成实体，参与者与活动或实体关联。团队借用这套关系思想，但在业务数据结构中另加授权决策和业务影响，因为“参与生成”不等于“批准执行”。

关系表达“已使用、已生成、源自、相关参与者、归属于、受何事件影响、批准用于什么、以什么方式执行”。AI提案v2源自v1并使用了新的运费报价；复核活动关联采购总监；批准针对v2的哈希；业务系统影响执行的是批准后的操作意图。每条关系都带事件编号、来源系统和数据结构版本。

有向图不允许偷偷覆盖。新报价生成新实体；人工修改生成新产物；撤销生成撤销决策；更正生成更正并指向原事件。原记录仍在，当前视图通过被替代/被撤销计算有效状态。若直接更新旧批准的金额，就无法证明当时批准了什么。

最小证据图既能回答正向问题“这张采购订单怎样形成”，也能反向回答“哪些执行使用了已撤销报价”“这个审批人当日批准了哪些高额动作”“模型配置c17产生的产物后来被多少次重大改写”。纯文本日志很难稳定完成这些关联查询。

建图不等于必须购买图数据库。关系型的事件表、实体表、关系表，加上对象存储和索引就可以；关键是编号、不可变版本、关系语义和约束统一。技术选型根据规模、查询与保留决定，不能用图形界面替代数据契约。

审计事件最少回答谁、什么、哪个对象、何时、何地、权限、结果和原因

NIST SP 800-53第五版的AU-3要求审计记录能够建立事件类型、时间、位置、来源、结果，以及相关个人、主体和对象身份；团队在此基础上加入AI任务需要的对象版本与哈希、权限与用途、人工与服务方参与者和关联编号。它只是控制设计参考，不表示本案例实现即通过NIST评估。

原因不是让审批人写一段空泛备注。原因代码对应政策锚点，例如停产风险、预算已确认、报价已过期、利益冲突；需要说明时附最小文本与证据引用。AI生成的理由标AI 提议，人的决定原因由人确认，不能自动复制后伪装成人写。

何地优先记录逻辑环境、租户、区域与源系统，不默认采集精确地理位置/知识产权全文。身份、设备和网络信息按风险/隐私政策最小化；能证明事件来自受控办公自动化生产服务，通常比长期保存员工位置更适当。

事件生产者不得自报超出其权威的事实。AI服务可以写“产物已生成”，不能写“人工已批准”；办公自动化系统可以写审批决定，企业资源计划系统可以写业务影响；聚合器把它们关联，但保留来源。这样，一个被攻陷的应用不能单方面伪造完整链。

数据结构验证拒绝未知参与者类型、缺对象哈希的批准、无来源的执行和倒退状态；写入失败的审计事件进入隔离流并报警，不能为了保持业务可用而静默丢弃坏事件。高风险动作在关键审计写入不可用时安全停止或排队，具体策略要事先批准。

发起事件要保存任务目的、范围和代表关系：登录用户不一定是业务请求者

采购员可能为工厂经理代办，计划系统也可能自动创建缺货案例。任务启动时要记录已认证主体、代表关系、触发来源、用途、范围、请求内容产物、当前策略和同意或业务依据；若是定时任务，执行者是服务，业务负责人和调度配置另列。

对话里的“帮我把所有订单都调整”不是范围。服务器把可读资源、可建议动作和禁止动作编译进任务合同；后续数据访问和工具调用必须引用任务/目的。范围扩展生成新范围请求与授权，不修改原任务。

共享账号会破坏“谁执行”的证据。若遗留业务系统只能使用共享服务凭证，审计链仍要在上游捕获真实主体，并让网关以委托令牌调用；业务系统回执指向服务执行者，同时链接被委托人员。无法建立映射的高风险写操作不能进入自动路径。

批量任务包含父任务与子操作意图。经理批准“这20项、总额不超过X、截止Y”时，包实体列明每项哈希；任何子项变化让包哈希变化并需重新批准。不能把模糊的“批量已批”应用到后来新增的第21项。

发起被取消、过期或源触发器撤回时追加终端。模型仍在后台完成的产物标孤立，不可进入审批队列；审计链保留为何未使用，避免把一次生成误认为业务决定。

数据使用记录要证明当时读了哪些版本、是否有权、用于什么目的，而不是复制全部正文

每次数据访问都要把任务、参与者或服务、用途、受控资源标识、修订版或截至时间、字段与分类、策略决策和结果关联起来。AI上下文包再列出最终选定的实体、转换过程和哈希。审计包通常只展示来源编号、版本、范围和访问决定；只有争议需要且调查者有权限时，才解封正文。

“系统具备权限”与“本次访问获得批准”要分开。每次访问保存策略决策编号和规则版本；权限变更后不能用当前查询解释过去。敏感字段被过滤时，也要记录字段类别与拒绝原因，但不在通用审计记录中保存被拒内容。

完整数据血缘从源实体→转换→上下文→提案。OCR、汇率转换、去重、摘要或人工上传均是活动；若AI金额错误，能判断原报价、汇率版本还是解析变换。只保存文件名“quote.pdf”无法区分同名覆盖。

访问列表可能很大，可以使用清单、树状校验哈希或不可变集合实体绑定成员；证据包按需展开，不在主事件中重复上千个编号。集合变化后生成新版本，哈希证明批准时使用的是哪一组；哈希本身不能证明内容真实，来源负责人和回执仍然重要。

数据负责人定义保留与显示规则。采购审查者未必有权看到员工个人信息或供应商银行字段；任务证据包按主张显示必要来源片段，其他字段经过脱敏，并保留脱敏事件。审计权不是无限的数据访问权。

AI产物必须有版本、父子关系和状态：对话最后一条消息不能代表被审核对象

AI生成提案时，要保存产物编号、内容哈希、结构化业务字段、模型、提示词、上下文与工具清单、软件创建者、父级和“提议中”状态。人工编辑生成新产物，而不是修改原文；提交审核的版本进入待审核；后续任何实质变化都会自动使旧审核请求与旧决定失效。

结构化字段包括采购订单、供应商、行项目变更、旧总计与新总计、货币、交付影响、风险、所需审批人策略和来源引用；渲染文字只是查看层。审批、阈值和执行比较结构化标准产物的哈希，既防止界面空格变化造成无意义重批，也防止隐藏字段变化却不触发重批。

次要与实质性修改由业务规则定义。标点、布局可生成演示修订版并保持业务产物；金额、币种、供应商、物料、数量、日期、条款、风险、来源或操作全部重大，生成新业务版本并使旧批准不适用。自由文本无法可靠区分时，默认重审。

AI 再生即使用户问法相同也生成新产物。不得因为同任务自动继承决策；可以显示前版批准供比较，但状态为需要重新审批。缓存命中仍引用原生成产物并创建本任务归属，不能把另一个任务的批准带过来。

人接受AI建议不是“AI决定”。人工编辑/请求审查记录操作者与差异，批准已决定记录授权者；若政策允许低风险一人接受即批准，也明确该人承担哪个动作，而不是用按钮名称模糊责任。

审批契约必须绑定批准人、权力依据、精确对象、范围、条件和有效期

有效决策是结构化契约，不是聊天中的“可以”、邮件截图或数据库里的“已批准=是”。审批服务在服务器端验证身份、权限、冲突与对象哈希，展示关键字段和差异，让人选择批准、拒绝、请求变更或附条件批准；决定后签发不可变的决策记录。

批准策略从提案字段计算审批人集合。总额、累计暴露、供应商风险或字段变化跨阈值时重新路由；不能让AI在提示词里决定“只需经理”。策略引擎输出所需审批与规则版本，人可提出例外但必须由例外权限单独批准。

展示页要防止盲签：同时显示原值与新值、变更、供应商、关键日期、来源时效性、AI标记、人工修改和未解决风险；长理由可以折叠，金额、对象和哈希不能隐藏。点击审批按钮前，再确认当前产物与页面加载时一致，避免“检查时还是旧对象、使用时已经被替换”的竞态问题。

数字签名或消息认证码可以把决策内容、主体或服务与时间绑定，并检测修改；具体签名强度、密钥托管、身份保证与法律效力由风险和适用规则决定。简单哈希只能检测内容变化，不能证明是谁签署；数据库账号也不自动代表自然人。

拒绝与条件同样是一等记录。拒绝不能被重新生成偷偷绕过，除非新产物和新复核明确关联；附条件批准在执行前逐条机检或人工确认。条件无法机器验证时，操作意图停在待人工确认。

完整走例：88,740元的第一版获批后变成97,080元，旧绿色标记不能跟到第二版

采购订单PO-4472原总额84,600元。09:04，采购员因停线风险发起只读分析；09:06，AI根据第三版报价建议增加4,140元运费，第一版方案总额88,740元，低于90,000元阈值。09:08，品类经理按政策P17批准第一版方案，决策d1绑定哈希H1、总额不超过88,740元、第三版报价和17:00前执行的条件。

09:13，供应商给出第四版报价，新增的加急与保险费用为8,340元；相对原采购订单总计增加12,480元，因此第二版方案总额为84,600+12,480=97,080元。AI生成第二版方案H2，并标记第一版已被取代。旧界面曾按任务保留绿色“已批准”，若执行端只检查任务“已批准=是”，就会错误执行。新执行网关发现决策d1绑定的对象哈希H1与当前H2不一致，而且97,080元超过90,000元，需要采购总监和财务控制人共同批准，因此返回缺少有效审批。

09:24与09:28，两位批准人都看到第一版到第二版的业务字段差异、预算回执和第四版报价，分别批准H2；网关再次验证哈希、两份权限、独立性、条件和到期时间，生成动作意图a7。企业资源计划系统以幂等键a7执行一次，返回影响e91、执行前84,600元、执行后97,080元。对账从业务系统独立查询同一修订版，并标记为已验证。

审计包能够证明AI只提出建议、没有批准；第一项批准没有被篡改，只是对H2不再适用；错误界面没有造成业务动作；新批准满足当时策略，执行结果也匹配。如果系统只是把第一项批准覆盖成“无效”或删除旧绿色标记，反而会失去未遂事件与控制有效性的证据。

反例验证：若报价 r4只修正拼写且业务规范哈希不变，可保留一阶；若金额从88,740降到87,900但供应商银行账户改变，即使仍低于阈值也必须供应商主数据复核。是否重批由物料字段/风险决定，不只看总额上升。

职责分离、代理与紧急越权必须在主体层判断，不能靠按钮数量

高风险任务要求发起、批准、执行分别由不同权力边界承担。AI服务不能同时伪装复核人；业务系统执行服务只接受受控、可验证的动作意图；管理员即使技术上能够修改数据库，也不因此获得采购权。系统要检测同一人、同一管理链、代理关系、共享凭证和冲突声明。

委派是实体：谁授予、给谁、哪些动作/金额/地区、起止、能否再委派、撤销状态。决策引用委托快照；代理人不能超出原授权者的范围，也不能用委派绕开自批冲突。委派到期后历史决策保留当时有效证据。

紧急越权不是隐藏后门。它只对预定的紧急类别开放，要求强认证、最小金额与时限、双人通知、立即记录原因和证据，并在例如24小时内由独立负责人复核。复核不通过时启动补偿与事件处置；不能事后补一个普通批准，伪装成前置授权。

服务间委托使用短期、受众与动作受限的凭证，审计保存凭证编号和声明摘要，而不是机密。AI调用工具时，参与者链是人工发起人→AI编排器→业务系统执行服务，各自行为分开；“由u118发起”不表示u118亲自执行了每个网络请求。

人员离职或权限撤销触发未执行决策复核。执行前再查授权/撤销，而不是认为签发时有效就永久有效；已执行动作保留历史并按需要对账/补偿。策略需明确哪些批准在人员离职后仍可生效。

执行前重新验证，执行后用业务回执与独立对账闭环

操作意图汇总精确产物、必需/已收集的决策、策略版本、影响范围、幂等键、截止日期与执行前的预期状态。网关在写前验证产物未取代、批准未过期/撤销、条件满足、职责分离、资源当前版本符合；任何差异拒绝或请求重新批准。

企业资源计划系统除了网络传输状态，还要返回业务回执：影响编号、已接受或已拒绝、对象修订版、执行前后、服务器时间和原因。超时时标记为“影响未知”，网关按幂等键查询，不重新生成批准，也不重复写入。执行失败不能把批准决策改成已拒绝；批准与实际影响是两类不同事实。

对账由独立读取路径确认采购订单修订版、金额与收货记录一致，再写入已验证、不同或未找到。差异可能来自并发人工更改或业务系统异步规则，此时要暂停并通知负责人；不能用AI期望覆盖业务系统事实。外部发送、付款或合同操作同样需要权威系统回执。

取消/补偿生成新的操作意图与审批，链接原始影响。数据库回滚不删除首次动作；审计需要看到先改后撤与影响窗口。若动作不可逆，任务合同与批准界面必须更高强度确认并明确补救方案。

执行服务只接受由审批服务签发、短期、单次、受众绑定的意图，不解析自然语言“经理同意了”。这样即使提示词被注入批准语句，也无法跨过验证；AI只能提交候选对象。

更正、撤销与政策变化一律追加事件：不要修改历史来制造一条完美链

错误执行者映射、时钟、原因或对象关联需要更正时，写更正事件，包含原事件、错误字段、正确值、依据、修正人/权限与时间；查询当前视图应用更正，原始视图仍保留原始。恶意/错误事件另标已争议，不物理删除，除非数据权利/法律要求有专门处置。

政策变化默认前瞻。90,000阈值改为80,000后，尚未执行的88,740 批准是否需重审由过渡策略明确；已执行历史按当时策略报告，同时可做回溯性风险评估。不能用新规则把旧记录界面染成“当时违规”而不注明时间语境。

审批撤销有范围：撤某决策、某审批人权限、某供应商或一批未执行意图。系统反向查询受影响的对象并冻结；执行中的状态进入未知/对账。撤销不能假装从未批准，尤其需要解释为何动作发生。

数据纠删与审计完整性冲突需隐私/法务设计。可删除正文/身份映射，保留合法必要的匿名事件、哈希/墓碑和处置证明；也可能依法必须删除更多。技术团队不自行宣布“审计日志永不删除”。

当前状态仪表板与证据导出都显示更正/撤销计数，防止只导出“清洁版本”。审查者能按截至时间重建当时状态，也能看今天裁决；两者不能混在一个布尔已批准。

完整性、时间与不可抵赖性要分开验证：一个哈希不能证明所有事实

审计证据需要防止未经授权的修改与删除，能够发现缺失事件，时间足够可靠，主体绑定强度也要符合风险。追加写入或一次写入多次读取存储、数字签名或消息认证码、事件序列、哈希链、可信时间戳、时钟健康状态、生产者身份和访问审计各自解决一部分问题，不存在一个字段包办全部。

NIST SP 800-53的AU 族包含记录内容、审查分析、时间戳、保护、不可抵赖、保留和系统级生成等控制主题；组织按风险选择并评估，而不是因使用某数据库就宣称全部实现。尤其不可否认性取决于身份、密钥、过程与争议处理，不等于“加SHA-256”。

每个事件生产者使用独立身份与密钥，采集器验证后写入接收回执；事件同时记录实际发生时间、来源系统记录时间、审计系统接收时间，以及时钟偏移与状态。异步事件按业务序列和链接解释，不能只靠毫秒排序。关键系统停止采集时，触发审计间隙，并阻断高风险操作或让它进入受控队列。

完整性清单列任务预期事件类型与实际状态。没有批准已决定可能表示正确拒绝进入审批、日志丢失或流程没完成；状态机决定哪项必需。终端任务生成密封包根哈希与计数，后来追加结果/修正建立新包版本。

密钥轮换、吊销、算法更新与长期可读性都要写入计划。多年后仍需验证的记录，要保留验证材料和格式迁移证明；把旧结构化格式迁移为新格式时，原哈希、转换工具及版本和新哈希共同形成迁移证据。

隐私、访问与保留按证据目的最小化：审计需要可问责，不需要让所有人看所有数据

任务链可能汇聚员工身份、绩效行为、供应商合同、银行资料、报价、生产缺口和模型输入。集中后风险更高。数据清单要为每个字段写明用途、分类、法律与合同依据、区域、负责人、查看者、保留与删除规则；通用仪表盘只显示令牌化主体、金额区间与状态，正文按案例解封。

身份系统把随机令牌映射到人员；普通查询只使用令牌，只有经过授权的调查才能按案例解封。不得记录访问令牌、密码、签名私钥或完整会话信息；策略与凭证只保存编号和必要声明。原因自由文本要做敏感信息扫描，避免批准人把秘密复制进记录。

保留按实体分层：高风险决策/效果可能长于模型原始文本，身份映射可能不同于聚合指标，未执行草稿可更短。本文不提供统一年限；采购、财务、隐私和法律负责人确定。法律保留有范围、批准、复核与解除，不能成为无限期全量保存借口。

证据导出是高风险事件：记录案例、用途、申请人、审批人、字段、删减、接收方、水印、加密与过期；临时文件自动删除。紧急访问要单独告警并在事后复核。审计日志的读取与导出本身也要被审计，防止内部滥用。

数据主体请求、合同终止或跨境限制触发既定工作流。若需移除内容，生成删除/墓碑与受影响包状态；报告诚实显示证据部分删除，不用残余哈希暗示仍可完整证明。

证据包必须从问题出发生成：把十万条日志导出给审查者不叫可审计

团队定义五类标准查询：谁发起、代表谁；使用了哪些数据实体和转换；AI和人员分别生成哪个产物；哪些权限与决策参与；产生了什么业务影响和后续更正。证据包按任务生成时间表、操作者与授权方表、实体血缘、审批矩阵、影响回执、缺口与冲突和验证结果，正文则按权限放在附录。

证据包生成器自身也要版本化，输出清单列出查询时间、截至时间、数据结构、包含事件、删减项和包根哈希；生成证据包不能改变原始证据。复核人点击任一结论都能回到来源记录，但权限不足时应显示“按策略遮蔽”，而不是“记录不存在”。

审查者使用类型化裁决：审计就绪、有界缺口、结论不明确、记录矛盾；列出缺失证据、对结论的影响、负责人和截止日期。系统不得自动把字段齐全判定为合规，机器只做数据结构、关系和签名验证；权限是否适用、原因是否充分、控制是否有效，仍需专业判断。

30分钟目标从审查者收到任务编号到提交裁决，等待批准解封的时间另计。它衡量证据可取得性，不奖励草率结论。测试中随机植入冲突或缺失事件，看审查者能否识别；只在完整案例上测速度，会制造过于乐观的指标。

证据包还支持受影响范围查询。发现报价 r4错误后，反查已使用该实体的提案、决策和影响，按执行/未执行分流；没有关系图只能全文搜索文件名，容易漏同内容不同名。

用完整率、矛盾率、抽查结果和取证时间验收，不能用“日志条数增长”证明控制有效

360个任务预注册9类关键事件，共3,240个任务 - 事件预期。新链满足3,204/3,240=98.89%；36个缺口集中在16个非审计就绪任务。344个审计就绪中关键批准/执行事件100%覆盖，允许的缺失只来自不适用事件，不以空记录填充。

旧必需事件按相同定义回填，不能因旧系统没某事件类型就缩分母。新 3,204并不意味着每任务都完整；任务终端按关键关系判，整体事件比例只看平台覆盖。344/360=95.5556%写95.56%。

96个高风险任务来自金额、银行与合同、紧急越权或外部影响切片；新系统的无效执行为0，只表示本样本未观察到，不能称未来风险为零。旧系统的7个无效执行包括3个旧批准复用、2个职责冲突、1个过期报价、1个外部影响未知后重复执行；全部发生在后台只读或沙箱环境，没有真实付款。

两项矛盾分别是业务系统回调与对账修订版不一致，以及身份目录与办公自动化代理记录冲突。它们不能被多数记录“投票”消除，状态要保持为矛盾，冻结后续动作，并由权威负责人裁决。

每月抽查全部高风险、所有异常/缺口/冲突，以及普通审计就绪分层10%；独立审查者不参与系统建设。发现一例严重漏判就扩查相同签名并暂停对应范围，不等比例超过阈值。

审计链的成本包括采集与存储、证据包、审查人时、权限管理和删除。取证时间下降如果来自把所有资料公开给审查者，就不可接受。指标必须与0个敏感标记泄露、访问异常和保留执行情况一起看。

处理离线、第三方、共享系统与人工口头决定：现实缺口要显式降级，不能补造记录

供应商门户可能没有版本接口，工厂可能离线，业务系统可能只有共享服务账号，经理也可能通过电话批准。系统要为每类情况定义证据强度与回退；无法满足高风险最小证据时就不自动执行，而是转入人工受控流程，并在链上标明外部证据或人工鉴证及其限制。

事后补录必须标记为迟到记录，并注明原发生时间的来源、记录人、证明材料与审批；它不等于实时系统记录。高风险前置批准不能依靠事后补录常态化，紧急越权有自己的正式流程。截图和邮件可以作为辅助实体，但要有哈希、来源与可信度，不能自动升级为权威决策。

第三方证据要写入合同预期：事件与回执字段、时间、编号、历史可取性、通知、数据驻留、保留和导出。做不到时就缩小第三方可执行范围，而不是在内部伪造一个“成功”。供应商更换时，要验证旧记录仍可长期读取。

离线节点使用本地受保护队列、序列与设备身份，联网后上传并生成摄入回执；冲突按业务版本处理。设备丢失或队列破坏显示差距，不能以服务器没收到推断动作未发生，需业务对账。

人工路径不是黑洞。系统可生成纸质/双人控制表单或受控离线审批，恢复后录入带原件参考；但其证据强度、延迟与访问另列。若适用规则不允许该方式，则直接停止，不让技术文章替组织放宽。

分阶段上线：先在后台只读运行中证明链完整，再把“无有效证据不执行”放到网关

第一阶段用两周统一任务、实体、活动、参与者、决策和影响的数据结构与编号，在后台只读运行中收集，不阻断业务。选30个保持历史形态的任务，让内审、采购、身份团队和业务系统负责人共同重建，寻找断点与权威来源；完成权限图、事件目录、数据清单和威胁模型。

第二阶段在沙箱启用绑定实体的审批、职责分离与业务系统回执，用120个案例测试版本变化、阈值跨越、委派、撤销、超时、重复、时钟漂移和审计写入中断。执行网关仍然指向沙箱；所有写入都可以清理和对账。

第三阶段在生产只读环境生成证据包，与现行人工审计并行，不改变批准流程。确认身份、数据、产物、办公自动化和业务系统的跨系统关联后，先在单一品类与低金额范围让网关做小范围验证；再从5%扩大到25%，最后覆盖已批准的全部范围，每一级都检查误阻断、队列、审查与成本。

网关故障关闭只用于事先定义的关键证据，如对象哈希、必需审批、权限、未知效果；低风险遥测字段缺失可继续但报警。所有阻断有用户可理解原因、负责人和人工安全路径，避免业务人员为绕开黑盒控制回到邮件。

上线演练包括伪造旧批准、同一人承担双角色、过期委派、报价被替换、业务系统超时、审计密钥吊销和证据导出越权；红队只要成功一次，就要修复后重测。审计平台管理员不能单独更改策略、事件和保留规则，变更本身也进入审批审计。

交付任务审计包：今天从一项真实变更证明五件事，不从购买“合规平台”开始

来源边界：W3C PROV-O用于实体、活动、智能体及已使用/已生成/已关联/已归因等来源关系；NIST SP 800-53 Rev.5/发布 5.2.0的AU 族用于审计记录内容、复核、时间、保护、不可抵赖、保留与系统级生成等控制参考；NIST AI 风险管理框架核心/手册用于清晰角色责任、人机配置、文档化、通过/不通过、覆盖/例外和组织问责。它们不提供本案例360、344、3,240、金额、阈值或流程，也不证明案例符合特定法规。来源核验于2026-07-21。

• W3C Recommendation：PROV-O
• NIST SP 800-53 Rev.5（含Release 5.2.0说明）
• NIST AI RMF Core
• NIST AI RMF Playbook：Measure

今天选一项最近发生的采购、客户承诺或业务系统变更，用任务编号回答：谁发起并代表谁、读取哪些版本、AI和人分别生成哪一版、批准人凭什么权力批准哪个哈希、权威系统最终做了什么。若任何答案只能靠聊天截图、当前数据库或某人的记忆，先把它标成缺口，不能补造历史。下一次同类任务先绑定产物与决策，再让网关只消费有效的操作意图；当旧批准、过期权限或未知执行影响能够在发生外部动作前被阻断，审计链才开始承担控制，而不只是事后记录。