August 2, 2026 — enforcement now open. EU AI Act Article 14 is no longer guidance. The accountability gap described in Part 1 is no longer a forward-looking risk — it is the question every regulator empowered under Article 22 can now ask. This essay proposes the affirmative framework that closes it.
From the Gap to the Framework
Part 1 of the Governance Framework Series named the problem. When AI acts autonomously in regulated workflows, the decision ledger a regulator asks for under Article 14(4) does not exist in any form that survives contact with enforcement. The provider's vendor logs, the deployer's integration logs, and the user's recollection of what happened do not converge on a single human-approved moment — because for autonomous systems there was no such moment.
The gap is not closed by policy. The August 2 enforcement opener makes that explicit: the question has shifted from "do you have an oversight policy?" to "show me the artifact for the consequential decision your system made last week." Policy PDFs answer the first question. They do not answer the second. The regulator that asks the second question and receives the first answer is, in the field's working terminology, looking at the exposure.
This essay proposes the affirmative framework. It is composed of four artifacts — chartered responsibility chains, decision logs, named accountable parties, and audit traces — that, together, replace the human veto with an observable one. Each artifact satisfies a specific Article 14(4) sub-test by construction. The artifacts are not new infrastructure. They are the connective tissue that turns logs and roles and rules into a governance surface a regulator can audit.
Artifact One: Chartered Responsibility Chains
A chartered responsibility chain is the pre-deployment specification of every consequential decision the AI system can make. For each decision, it lists four things: the decision point, the signals reviewed at it, the decision rule that converts signals into outcomes, and the accountable party that owns the decision. The chain is written before the system ships — not assembled after a regulator asks.
The chain has four columns, and the columns are non-negotiable:
- Decision Point. The specific branch the AI can take at this step in the workflow. Named, not generalised. "Approve credit" or "remove post" is a decision point. "Make a decision" is not.
- Signals Reviewed. The model inputs, retrieved facts, and prior-state references that inform the decision. Anything not on the list cannot influence the outcome — a property the chain enforces by construction.
- Decision Rule. The deterministic or threshold-based rule that converts signals into an outcome. If the rule is opaque, the chain is not chartered. A model that cannot articulate its rule is, in this framework, not deployable into a consequential workflow.
- Accountable Party. A named natural person or role that owns the decision. "The team" or "ops" is not a chartered party. Article 14(4)(c) requires a designated human, and that requirement is satisfied or not by this column alone.
A full worked example — a six-step chain for content-moderation takedown at an EU user-facing platform — is published at /responsibility-chains. The chain walks from inbound post through triage to human ruling to legal escalation to final action to audit-log closure, naming the accountable party at every step and the Article 14 hook it satisfies. It is the canonical artifact for what a chartered chain looks like when deployed.
Why "chartered": the chain is a charter in the legal sense — a binding instrument drafted and signed before the activity begins. Like any charter, it is invalidated by silence on the points it was meant to cover. An unsigned, undated, or vague responsibility chain has the same status as an unsigned contract: not enforced.
The chain closes the accountability gap from Part 1 because every decision the system can make has been named, the rule that decides it has been written, and the human who owns it has been recorded. When a regulator asks "show me the artifact," the chain is the artifact. The framework's first column answers the second question a regulator now gets to ask.
Artifact Two: Decision Logs
A chartered chain is the specification. A decision log is the runtime evidence that the specification was actually followed. For every agent action that takes a consequential outcome, the log captures five fields at minimum:
- Agent identifier. The specific model, version, and instance that produced the action. Not "the AI" — a name, a build hash, a deployment identifier.
- Timestamp. The moment the action was committed. UTC, monotonic where possible, signed if integrity matters.
- Governance flag. The classification of the action under the deployer's governance surface — HITL, HOTL, autonomous, emergency-stop — at the moment of execution.
- Intervention record. If a human intervened (override, halt, reversal), the record of who, when, and why. If no intervention occurred, that absence is itself logged.
- Overseer identifier. The natural person who held the oversight role at the moment of the action. Resolves to a real identity, not a shared mailbox.
Each of these five fields satisfies a specific Article 14(4) sub-test. The intervention record is the evidence of Article 14(4)(a) — intervention capability is demonstrated by the existence of the record, not by the claim that intervention was possible. The intervention-rate statistics derived from the log are the evidence of Article 14(4)(b) — automation-bias counteraction is shown by override rates that pass the test, not by a policy that says they will. The overseer identifier is the evidence of Article 14(4)(c) — the designated natural person is named in the log row, not in a separate org-chart document that may or may not be current.
The absence-of-intervention case. When an agent action proceeds without any human intervening, that fact must be logged too — as a deliberate non-action. A regulator that audits the log and finds autonomous actions with no intervention record can read either "the action was oversight-exempt under the charter" or "the action was oversight-required and unmonitored." The framework forces the deployer to choose which it is, in advance, and to be consistent.
The decision log is not optional metadata. It is the live compliance evidence base. The chain is the charter that says "this is the decision and this is how it should be made"; the log is the record that says "this is how it actually was made." The regulator's question — "what did your system do last Tuesday at 14:32?" — is answered by the log. Nothing else answers it.
Artifact Three: Named Accountable Parties
Article 14(4)(c) requires that oversight be assigned to natural persons with the necessary competence. The requirement is specific: a natural person, designated in advance, with the competence to intervene. The framework's third artifact is the named accountable party — the column in the chartered chain, the row in the decision log, the person on the org chart who can be summoned when the regulator asks.
The phrase "the team" fails the test. So does "the on-call rotation" without a named on-call, "the moderation lead" without a specific natural person behind it, and "the deployer's compliance function" without a human accountable for that function. The EU AI Act does not exempt organisations based on how few people work there, but it does require a name.
Three operational patterns work, and the choice between them depends on the organisation's structure:
- The solo founder. A single human owns the oversight function. Article 14 permits natural-person oversight at any organization size. A solo founder is, on the letter of the law, an effective overseer — provided the founder is competent, can intervene, and is recorded as the overseer on every consequential log row. This pattern works for one- and two-person teams and is the most legible answer a regulator can receive.
- The named employee. A specific employee is designated for oversight at each decision point, with a backup named for absence coverage. The chain names both. The log records which one was on duty for each action. This pattern works for organisations with enough headcount to dedicate a person to oversight without compromising throughput.
- The contractor or external auditor. An external party is contracted for oversight, named in the chain, recorded in the log. This pattern is permissible, but it raises its own automation-bias question: the contractor sees only what the system surfaces, and the system may be designed to make intervention rare. The framework treats this pattern as the highest-risk of the three and requires it to be chartered with the most explicit intervention mechanism.
The choice between patterns is not a strategic preference — it is a decision the charter records. The deployer who has not named a pattern has not chartered the decision, and the regulator's default in that case is provider/deployer liability under Recital 84 and Article 22.
Artifact Four: Audit Traces
An audit trace is the append-only log of every decision, every intervention, and every accountable party's signature — retained, queryable, and exportable on regulator request. It is the fourth artifact, and it is the one that the regulator's request will reach for first.
The trace differs from the decision log in scope and retention. The decision log records what happened at each decision point. The audit trace records the chain of decisions across the system, the version history of the chain itself, and the integrity evidence that connects a decision row to the charter that authorised it. Where a decision log answers "what did the system do at 14:32?", an audit trace answers "what was the system authorised to do at 14:32, and what did it actually do?"
Three architectural properties define a regulator-grade audit trace:
- Append-only. No row is modified or deleted after write. Corrections are added as new rows that reference the corrected ones. This property is what makes the trace defensible under Article 14(4) — a regulator can verify that the log they were shown in week one is the same log the system was running against in week twelve.
- Long retention. Six years is the working baseline for Article 14 obligations and matches the Article 26(c) deployer log-retention expectation. The trace must survive the full enforcement window in which a regulator may ask.
- Queryable on request. A regulator who asks "show me every autonomous action your system took in July 2026 that involved a credit decision for an EU resident" should be able to receive that subset within a regulator-defined response window. A trace that exists but cannot be queried is not an audit trace.
The PDF-vs-trace distinction. A policy PDF is a narrative. It says "this is what we intend to do." A regulator that asks for evidence is not asking for the narrative. The audit trace is the difference between "we have an oversight policy" and "here are the 14,832 autonomous actions our system took last month, with intervention records, accountable parties, and chain versions for each." The first answer is policy theater. The second answer is observable compliance.
Article 26(c) — the deployer's obligation to keep the logs generated by the system — points at the audit trace specifically. The regulator's reach here is not for an oversight narrative but for the operational record. The trace is what satisfies that reach.
How the Four Artifacts Compose
None of the four artifacts is sufficient alone. A chain without a log is a charter that proves nothing was followed. A log without a chain is a record of decisions with no specification to compare against. An audit trace without a charter and a log is a history of events with no authorising instrument and no intervention record. A named accountable party without the rest is a person on an org chart, not an oversight surface.
Together they compose into a single governance surface that closes the Part 1 accountability gap. The composition has a specific shape:
- Chain → Log: the chartered chain specifies what should happen at each decision point. The decision log records what actually happened. The chain is the contract; the log is the receipt.
- Log → Party: every consequential log row resolves to a named accountable party. The party is the human on the hook for that specific action.
- Party → Trace: the actions of every named party are accumulated into the audit trace. The trace is the regulator's view of what every accountable party did, and did not do, over the retention window.
- Trace → Charter (versioned): the audit trace carries the chain version that authorised each action. When the chain is updated, the trace records both the old and the new version. The version history is itself evidence that oversight is being exercised — the chain is alive.
Four artifacts compose into a single governance surface. The chain is the contract; the log is the receipt; the party is the name; the trace is the regulator's view.
This is the affirmative answer to the Part 1 question. The human veto is not preserved by keeping a human in the workflow — that path is closed for autonomous systems. The veto is preserved by turning the judgment step into an observable artifact, and that artifact is composed of these four pieces. An organisation deploying an AI system into a regulated workflow that has all four in place passes Article 14(4) by construction, not by policy claim.
An organisation that has none of the four — or that has the chain but not the log, or the log but not the party, or the party but not the trace — has a partial framework. Partial frameworks fail the audit. The composition is the framework. Skipping an artifact is the same as skipping the test.
This essay is the second installment in the Governance Framework Series. Part 1 mapped the accountability gap; Part 2 proposes the affirmative framework that closes it. The worked example of a chartered chain applied to a content-moderation workflow is published as a separate artifact at /responsibility-chains.
Read the framing essay: Part 1 — The Accountability Gap. Read the worked example: /responsibility-chains. Browse the canonical reference index: /blog/ai-governance-resources.
Open the series hub: /blog/governance-framework — canonical entry point with reading-order timeline, the AFFIRMATIVE-framework artifact, and links into the reference index.