AI 智能体治理在追踪记录中接受审计 | Focused Labs

New delays in the AI Act mean teams will be lazy in exactly the wrong place.

The date moved, but the work did not. For those of us building agents in a regulated environment, the work of runtime proof has not changed. It is boring and specific: model, tool, policy, human in the loop, trace for receipt.

The latest update of the EU Commission on the AI Act Overview (July 31) sets the following dates for rules and duties for the development and deployment of AI: transparency rules for AI systems apply from August 2, 2026 onwards (Annex II, AI Omnibus, Commission’s 31 July update in the Commission's 31 July update); Annex III high-risk obligations enter into force on December 2, 2027 (Annex III high-risk AI, under the AI Act definitions); embedded high-risk product obligations enter into force on August 2, 2028.

Fine. The panic date shifted.

The engineering problem got more concrete.

The delay changes the calendar. It does not change the evidence architecture. The deadline moved, the evidence burden stayed

A spreadsheet represents poor AI governance. It outlines all of the ‘agents’ i.e. processes that the AI is executing and attributes a policy owner to each of the ‘agents’ as well as outlines the associated risks. The board is told that there is a program of work going on in order to implement the required governance.

Just as a fire escape plan is useful as a map that accompanies the team on the run, not just as a document hung on a wall, a spreadsheet inventory of agents and their associated policies, risk, and board reporting ultimately becomes theater when there is no way to connect it to the actual run of business.

Connecting governance to execution path for AI systems (for providers and deployers of AI systems) is the whole game. By 2 August 2026 Article 50 obligations for transparency will apply to providers and deployers of AI systems. Public disclosure for chatbots, run-level reconstruction for agents.

What did the agent tell the person? What content did it generate? Which downstream system did it touch? Was the user aware that a machine was involved? Which runtime version made the decision?

Policy documents do not reconstruct a tool call.

A governance process that cannot see the execution path of a system cannot apply policy effectively. It is essentially applying policy blindfolded. This is why I keep coming back to the same governance shape: governance follows the execution path. The relevant policy layer is around identity, tools, state, approval, trace, and outcomes. Agents turn compliance into an execution problem

Software governance used to be made up of a comfortable fiction. The approved code path was the behavior of the service. It accepted input and ran through deterministic logic. It might hit a database or two, but in the end it produced output. The audit record for all that activity would sit at the edge as deploy tickets, access reviews, log lines and incident reports.

Agents make that fiction expensive.

In complexity, an agent uses tools, sets input arguments and possibly asks for a human intervention. In the process of generating output for the user, it can also potentially disclose information. The same prompt will travel through different trajectories in complex systems, because the context, which was retrieved, changed, a model provider changed behavior or a conversation state crossed a threshold.

A recent post by Honeycomb goes into more detail about how to monitor AI systems for reliability, and clearly outlines how request-level context, model versions, retrieval results, and tool calls influence whether an AI system will work, and how failures in AI systems are to be analyzed and debugged within a single request inside the actual request.

The compliance version of this also holds. A clean monthly report does not tell the team why one instance of running an agent revealed salary history to the wrong people. A policy committee cannot figure out if the proper data minimization checks were made. A risk taxonomy does not establish if a human had the appropriate authority to interrupt a process.

The trace has to carry that work.

Governance has to be captured at the moment of action. The trace is becoming the compliance surface

The record-keeping article of the AI Act matters here. Article 12 defines how high-risk AI systems shall technically allow automatic recording of events over the lifetime of the system. Such logs shall support risk identification, post-market monitoring and operation monitoring by means of traceability through traceability.

Article 12 reads like law but behaves like an architecture spec for live AI systems.

The live agent trace cannot be defined by prompt, completion and latency. The trace needs to follow the steps inside the AI agent's runtime: identity of the AI agent, delegated human user, tool used, resources touched, policy version, policy decision, evaluator result, human approval or rejection, output hash, model version, retrieval set and result status.

This turns the runtime state layer into a governance layer (as previously explored and mapped state layer where audit records accumulate) as audit records (including checkpoints, memory, trace IDs, policy decisions, and evaluator results) start to collect in an operational zone where said governance can either be searched evidence or become narrative archaeology.

C-Trace, a runtime compliance verification framework for AI agents, already looks at ways to transfer consent, purpose, data minimization and erasure as predicates over an execution trace for AI agent applications. The trace is generated by intercepting the tool invocations and model outputs of an AI application. Non-compliant actions are blocked. An audit log is created. Under perfect extraction, the system reports 0% attack success. Under 10% extractor noise, the system keeps attack success at or below 12%. The system keeps false positives at or below 16%. This is the result of an evaluation by the authors in the authors' evaluation.

The interesting part: the AI Act can be monitored in real time as the run happens. Human oversight is a runtime event

Teams treat human oversight, and the related implementation into policy, as if it were only to do with the required staffing for implementing that policy. Name a human and assign a control.

Article 14 is more operational than the staffing slide. The Service Desk says oversight measures should enable assigned individuals to understand system capabilities and limitations, monitor operations, interpret outputs, override or reverse outputs, and interrupt the system by way of a stop button or similar procedure that brings the system to a safe state.

So that's an agent runtime. An approval is a state transition. An override is a recorded decision with actor, authority, input, output, and consequence. An interrupt is control flow.

This is where policy before the tool call comes in. Human oversight after the tool has already mutated a record is cleanup activity. Human oversight before risky activity is governance. The trace should clearly show this.

A lending agent can draft a credit recommendation. A human reviewer can approve, edit, or reject it. A healthcare triage agent can summarize patient history. A supervisor can stop an escalation. A support agent can prepare a deletion workflow. A privacy owner can verify scope before execution.

These decisions should also be captured as first-class events in the audit trail and not as after-the-fact comments in a case-management system. Post-market monitoring is the part teams skip

The delayed high-risk dates will tempt executives to punt. Post-market monitoring has to become an operational habit before it becomes a compliance obligation.

Article 72 says providers of high-risk AI systems must establish and document a post-market monitoring system that actively and systematically collects, documents, and analyzes relevant performance data throughout the system lifetime to evaluate continuous compliance.

That phrase, throughout the system lifetime, carries the operational burden.

An agent changes after launch. A model changes after launch. A retrieval corpus changes after launch. A tool schema changes after launch. A permission boundary changes after launch (loosen up). A user cohort discovers a new path. The test cases never covered that new path. But one evaluator score means customer harm, the other score means no harm. The organization learns something new.

The important thing: post-market monitoring as a feedback loop. Trace samples from the field are used for evaluation. If the evaluation detects drift, then incidents are replayed and then used as test cases in release gates. The new runtime checks that are developed as part of the release gate process result in the agent getting safer and safer as more evidence is developed and flows in.

Runtime receipts are critical to financial workflows. A regulated workflow cannot be reduced to a summary of the overall performance of an agent. Rather, the review of such a workflow consists of a receipt containing a description of the action, the authority, the data, the approval, the outcome and the correction path. What an audit packet contains

A full trace is too much for a reviewer to go through and a log line is too little detail to go by. A useful artifact for a reviewer is an audit packet cut from the trace.

For one agent action, that packet should contain: · Agent identity and runtime version. · Delegated user or service principal. · Session ID, trace ID, and parent action. · Tool, resource, and operation requested. · Purpose and data categories involved. · Policy version, policy decision, and reason code. · Evaluator scores or guardrail outcomes. · Human approval, edit, rejection, or interrupt event. · Output hash, result status, and downstream side effect. · Retention rule, tombstone status, and export location.

That sounds like work until the first concrete question arrives.

Note that the IETF Agent Audit Trail draft is an Internet-Draft and thus not a settled standard. However, for those interested in audit trail records from IETF software agents, this named the shape of JSON records containing the agent's identity, action taken, result of action, trust level, etc. that would form tamper-evident SHA-256 hash chains and optionally be ECDSA signed. JSONL, Syslog and CSV export are discussed as potential output formats for such records as a proposed audit format.

There's no need to wait for the standard to finish. The field names will change, but the architectural boundary will not. So, for example, if an agent is doing work that could affect people, money, access to information, employment, health, credit or regulated data, that work should create a record that can withstand a hostile read of that record. The teams that start now get a boring advantage

The AI Act delay buys time for architecture, not time for governance-as-documentation theater.

The next year should be boring work. Firstly, put trace IDs on every run of the system. Secondly, start to version policy decisions. Thirdly, start to capture human interrupts as control-flow events, and then preserve evaluator scores. Finally, start to export action packets, write retention rules, and then above all else, keep raw sensitive data out of records unless a reviewer truly requires it to be in there. Rehearse the audit query before the audit exists.

This is the unglamorous side of ai agent governance. It will not demo well. Nobody claps for retention metadata.

But by then, the reason for the decision may have been forgotten. The team without runtime evidence has to interview the system after the fact.