AI Transparency Is Not AI Accountability

AI transparency vs accountability is the governance question underneath the whole interpretability debate. The AI safety progress tracker records what the research has shown about reading a model from the inside. Suppose every row in that table moved tomorrow. Five questions would be exactly as open as they are today, and every one is a question about your organization, not about the model.

This post describes governance frameworks and names a few. It is not legal advice, it states no duty in RedHub's voice, and whether any framework applies to you is a question for counsel.

Transparency describes a system. Accountability names a person.

Transparency is a property of a thing. A model is more transparent when more of its workings can be seen and described, and the research in this series is about raising that property.

Accountability is a property of an arrangement between people. A decision is accountable when a named person answers for it, had the authority to change or stop it, and can produce the evidence of what happened. None of those is a fact about the model.

The two come apart in both directions. A fully legible model can run inside a company where nobody owns its decisions and the logs name a service account. A model nobody can read can run inside a company where every consequential decision has an owner, an exercised stop control, and a record a stranger could reconstruct. Only the second company can answer a regulator, a customer, or a court.

What the frameworks say, in their own structure

NIST's AI Risk Management Framework organizes its guidance into four functions and names Govern as the one that cuts across the other three. ISO/IEC 42001 is a management-system standard: its subject is how an organization runs its AI, not what is inside any model. Whether any law or standard applies to a specific system, and what it demands, is a determination for counsel. The structural point stands on its own: each framework treats legibility as one input to a governance function, and none treats it as a substitute for one. The first set's closing post, does interpretability make AI safe, makes the same argument from the research side.

Five questions a legible model leaves open

Each has an outside-view answer in verdict vocabulary that works on any model, including one you rent. The verdict words are the ones the named instruments return, copied from their pages.

1. Which failures matter?

A model's internals can tell you what it represents. They cannot tell you which of its mistakes your business can absorb. That is a judgment about reversibility and reach, and someone has to make it first. The free Decision Fit check asks eight questions about one task, with two gates that can only move a task toward human judgment and never away from it. A task you cannot grade is one you cannot measure, and the tool says so instead of blessing it.

2. What evidence is enough?

Legibility produces evidence of what a model does. It does not set the standard of evidence your organization accepts. The outside-view standard is the one the Stop-Authority Assay states for stop controls and that generalizes to everything else: shown, not claimed. For records, the question is whether somebody who was not there could assemble the account. The Audit Evidence Pack Assay grades that and returns ANSWERABLE, NEEDS A WITNESS or NO RECORD, and says nothing about whether the decision was right. Logs versus an audit trail and the audit evidence bus factor cover why a log is not yet evidence and why evidence in one person's head is not durable.

3. Who can authorize a change?

Interpretability may soon make it possible to edit a model's behavior precisely, and the previous post, the security risk of editing an AI's behavior, explains why that lever points both ways. The governance question is older than the technique: who, by name, may change the system, and does the record attach to that person at the moment they do it. The Override and Break-Glass Register grades each bypass path on that and returns ACCOUNTABLE, LOGGED ONLY or UNATTRIBUTABLE. The free AI Governance Gap Assessment (opens in a new tab), a free self-assessment you answer yourself, asks the organizational version: an inventory of the AI in use, a policy people follow, and a named human on each decision.

4. Who can contest a decision?

A person affected by an automated decision needs two things no model internals supply: to have been told, and somewhere to appeal that has authority to overturn. The Automated-Decision Transparency and Disclosure Scorecard grades those practices from your own marks, with a disclosure gate that forces UNDISCLOSED when the person was never told an automated system made the decision. It is a readiness aid, not legal advice, and it does not decide which regimes reach you. The consumer side of the same question is can you fix what the algorithm thinks about you.

5. When does deployment stop?

Most organizations have answered this on paper and never exercised it. A model that can be read can still not be halted. The Stop-Authority Assay grades what each stop control has been shown to do instead of what it claims, returning STOPS, SLOWS or NAMED ONLY per control, and reads each agent by its strongest control as CAN BE STOPPED, CAN ONLY BE SLOWED or CANNOT BE STOPPED. Halting an idle agent shows nothing about work already running, and its worked example turns on exactly that.

The order decides whether the answers mean anything

The five questions are not a checklist you can complete in any order. They run in sequence over the life of one decision, and an answer late in the sequence cannot repair a failure early in it.

The Who Authorized This bundle is built on that rule. It groups ten execution-layer instruments into three stages, read in order. Binding: does the decision bind anything at all. Containment: once it is running, can anybody intervene and be accountable for having done so. Account: afterwards, can you answer for it. A later stage can never read higher than the one before it. The layer returns HELD END TO END AS DESCRIBED, HELD IN PARTS or NOT HELD, and reads NOT RUN until every stage has a finding. In the page's own words, perfect audit evidence about a verdict that never bound a machine is evidence about nothing.

The AI governance operating system post lays out the same sequence at company level, and the second pillar, AI oversight without reviewing everything, puts the tiers of review around it.

Where a verdict meets a person

The most direct version of the distinction is one RedHub runs. The RedHub MCP connector connects Claude to the instruments a buyer owns, and nothing else: it can list them, explain any instrument's questions and scale, and run the ones that ship a runnable engine. Claude asks every question itself before it grades anything, and every result carries that instrument's own disclaimer. A person reads the verdict and decides. That step is not automated, on purpose. It is the accountability point, and no amount of transparency on either side of it moves it. The free diagrams at redhub.ai/visuals show the same rules, starting with the gate that overrides a good score.

Pairs well with

Two bundles cover the organizational layer. The AI Governance Starter Bundle groups an acceptable-use policy builder, a workforce literacy training kit, and an EU AI Act readiness kit, with a 90-day playbook. The AI Audit and Accountability Bundle groups a connector access auditor, an output audit-trail kit, a disclosure and labeling readiness kit, and a vendor data-flow register. Both describe themselves as working aids, not legal advice. Nothing in either reads a model, and the RedHub standard says every result is based solely on the inputs you supply, with no independent verification of the underlying facts.

For the vendor who says their model is transparent, the AI inspectability checklist has the ten questions. The running record of what interpretability has demonstrated is the AI safety progress pillar, which this post closes out.