Preventing accountability from being assigned where control does not exist

What this artifact is

A pre-deployment and post-incident audit tool for organizations adopting or operating AI systems, designed to test whether responsibility and authority are aligned at every point where harm might occur.

This tool is meant to be used by:

  • public institutions,
  • platform governance teams,
  • procurement offices,
  • and oversight bodies.

It formalizes a question that otherwise remains rhetorical:

Who is responsible — and what power do they actually have?

Why this artifact is necessary

Across the Guardian corpus, the same inversion recurs:

  • Users are told to verify.
  • Professionals are told to exercise judgment.
  • Moderators are told to respond.

Yet none of these actors:

  • authorized deployment,
  • designed the interface,
  • controlled system scope,
  • or could pause the system.

Responsibility is distributed downward; authority is retained upstream or nowhere at all.

This audit exists to make that inversion visible, documentable, and contestable.

Core Principle

Responsibility must follow authority.
If authority cannot be identified, responsibility cannot be legitimately assigned.

The Audit Tool

The audit is run at three stages:

  1. Pre-deployment
  2. Ongoing operation
  3. Post-incident review

Failure at any stage triggers escalation or suspension.

Stage I — Authority Mapping

For each AI-mediated function, answer the following:

1. Who authorized this system to be deployed in this context?

  • Named individual
  • Named role
  • Named institution
  • ☐ No clear authority

If authority is diffuse or absent, deployment fails audit.

2. Who can modify or withdraw the system?

  • Product team
  • Executive authority
  • External regulator
  • ☐ No one clearly empowered
Red flag: Responsibility assigned without withdrawal power.

3. Who defines the system’s scope of use?

  • Fixed by policy
  • Adjustable by design
  • Emergent / undefined

Undefined scope constitutes a governance failure.

Stage II — Responsibility Assignment

For each group exposed to harm (users, professionals, moderators):

4. What responsibility is assigned to them?

  • Verification
  • Oversight
  • Final decision-making
  • Reporting / moderation

5. What authority do they have to discharge that responsibility?

  • Can they see underlying data?
  • Can they contest outputs?
  • Can they alter system behavior?
  • Can they pause use?

If answers are mostly “no,” responsibility is misassigned.

Stage III — Enforcement & Escalation

6. What happens when the system causes harm?

  • Automatic pause
  • Review without pause
  • Statement issued
  • No defined response

Only the first constitutes binding governance.

7. Who bears consequences if harm recurs?

  • System owner
  • Deploying institution
  • Downstream actors
  • No one
Red flag: Consequences assigned to those without authority.

Stage IV — Audit Outcome

After completion, auditors must assign one:

  • ☐ Authority and responsibility aligned
  • ☐ Partial misalignment — remediation required
  • ☐ Structural misalignment — deployment blocked
  • ☐ Authority absent — governance failure

This classification must be recorded and reviewable.

What This Audit Changes

Without it:

  • Accountability is rhetorical
  • Harm is individualized
  • Institutions deflect blame

With it:

  • Power is mapped
  • Gaps are documented
  • Responsibility cannot be displaced invisibly

What This Artifact Is Not

  • Not a legal liability tool
  • Not an ethics assessment
  • Not a compliance checklist

It does not determine who should be responsible.
It reveals who already is — without authority.

Intended Users

  • Public-sector procurement teams
  • Platform governance & policy teams
  • Regulators
  • External auditors