The Dissolution of Responsibility
When harm emerges from suppliers, routers, adapters, evaluators, operators, and release rules, accountability can fragment.
Control requirement
The control must live outside the candidate’s ordinary write boundary. It should be versioned, auditable, recoverable, and testable under failure. A policy expressed only as a prompt is not a hard control.
Failure mode
The governance layer becomes part of the attack surface when it controls identity, success definitions, release permissions, hidden evidence, memory retention, aliases, and rollback.
Practical review
Ask who owns the control, who can change it, which evidence would reveal failure, how it is rolled back, and what organizational pressure could bypass it.
<!-- expanded-release-content -->
When harm has no single obvious owner
Distributed AI systems can produce outcomes through many individually reasonable decisions: a supplier ships an adapter, a team approves a prompt, a router sends a task to a specialist, an evaluator rewards an output, a memory system preserves a precedent, and an operator promotes a release. After harm occurs, no one component may look like the sole cause.
This is responsibility diffusion. It is not a reason to avoid accountability. It is a reason to design accountability into the system before incidents happen.
Required ownership map
Every safety-relevant component should have an owner with authority, not only a contact name. The ownership map should cover base models, adapters, datasets, prompts, memory, routers, tools, evaluators, registries, release controllers, runtime operations, and affected-user channels. It should also name who can stop promotion and who can accept a no-op.
Incident review
An incident review should reconstruct the composition, the transition graph, the evidence available at the time, the human approvals, the evaluator decisions, and the missing accountability links. Blame should not stop at the final model response if upstream components created the conditions.