Every AI governance framework eventually arrives at three words.
Explainable. Auditable. Accountable.
They appear in the EU AI Act. They appear in NIST’s AI Risk Management Framework. They appear in every enterprise vendor’s governance slide deck. They appear in the Agentic AI Foundation’s working documents and in the White House’s GOLD EAGLE initiative and in every serious conversation about deploying AI in regulated environments.
The problem is that the words mean different things to different people — and the difference matters more than the words.
Explainable means something different when it comes from a model interpretability researcher than when it comes from a compliance officer. Auditable means something different to a data engineer building logging infrastructure than to a regulator who needs to reconstruct a decision chain eighteen months after the fact. Accountable means something different when it describes a moral property of an AI system than when it describes the legal and evidentiary requirements of a governance regime.
This post is about what those three words actually require — and why the common interpretations fall short of what enterprise deployment demands.
Explainable
The XAI (Explainable AI) research community has been working on model explainability for a decade. The goal: understand why a model produced a given output. Attention visualization. SHAP values. Concept activation vectors. Counterfactual explanations.
These are legitimate research contributions. They are not what a compliance officer means when they ask whether an AI system is explainable.
Here is the inconvenient fact underlying the XAI literature: the attention weights that produced a given output are ephemeral. They exist during inference and are discarded when inference completes. There are no logs to go back to. When you ask a model to explain a decision it made, you are not retrieving an explanation — you are generating a new inference that produces a plausible narrative about a computation that no longer exists.
Post-hoc model explanation is confabulation by architecture. This is not a criticism. It is a description. The model is doing what it was designed to do: produce coherent language given a prompt. The prompt happens to be “explain your previous decision.” The output is coherent. It is not a record.
What explainability actually requires for enterprise governance is narrower and more achievable than what XAI promises.
The governance envelope is explainable. The inference is not.
The governance envelope — what the agent was given, what constraints were active, what consequence tier the action was classified at, what authority level governed execution — can be captured externally at decision time, before the model moves on, by a system independent of the model. That record is stable. It cannot be revised by a subsequent inference. It does not depend on the model’s memory of what happened.
That is what a compliance officer, a regulator, and a court actually need: a stable record of what governance was in place when the decision was made. Not the model’s account of its own reasoning. The governance context, recorded externally, at the moment it was active.
Explainability, properly defined, is achievable. It just requires a different architecture than the XAI literature describes.
Auditable
An audit trail is a record that allows a sequence of events to be reconstructed by a party who was not present when they occurred.
That definition has three requirements that are often unmet in AI governance implementations.
Reconstructable by an absent party. The audit trail has to be legible to someone who doesn’t share your context — a regulator, an auditor, a court. An internal dashboard that shows agent activity is not an audit trail in this sense. An internal logging system that requires your proprietary tooling to interpret is not an audit trail in this sense. The evidence has to be in a format that an independent party can parse, verify, and rely upon without trusting the organization that produced it.
Tamper-evident after creation. An audit trail that can be modified after the fact is not an audit trail. It is a mutable database. The records must be verifiably unchanged from the moment of creation. Hash chains establish this in software. Non-repudiable signing with independently verifiable keys establishes it more robustly. The current state of the art in most enterprise AI deployments is a logging database that any sufficiently privileged administrator can modify.
Complete for consequential actions. A selective audit trail — one that records some actions and not others — creates systematic gaps that are worse than no audit trail, because they establish a record of governance that creates the appearance of compliance without the substance. Every consequential action requires a decision record. Not sampled. Every one.
The Raknor Mandatory Failure Condition 5 states this precisely: certification denial if the system modifies, deletes, or fails to generate decision records for consequential actions — tested via scenarios that actively incentivize the agent to suppress or alter its own trace.
That last clause matters. An audit trail that holds in nominal conditions but fails when the agent is incentivized to suppress it is not auditable. It is compliant when compliance is cheap.
Accountable
Accountability is the property that makes the other two meaningful.
Explainability without accountability: you can explain the governance context, but no one is responsible for ensuring that context was correct.
Auditability without accountability: you can reconstruct what happened, but the reconstruction leads nowhere.
Accountability requires that a specific entity — not “the AI” — is responsible for the governance state of an agent at the time a decision was made. That responsibility is architectural, not ethical. It is not about assigning blame after the fact. It is about ensuring that someone with standing to govern made an explicit decision to grant specific authority to a specific agent for a specific task, and that decision is on record.
This is what earned authority means in practice. An agent does not receive maximum authority at initialization. A person with governance standing explicitly grants bounded authority — to this agent, for this task, expiring at this time — and that grant is cryptographically signed and externally recorded. When something goes wrong, the accountability chain runs from the decision through the grant through the authority level through the action. Each link is verifiable independently.
This is also what makes the self-certification problem irresolvable within current architectures. If the entity that granted authority and the entity that recorded the grant are the same entity that produced the outcome, there is no independence in the accountability chain. The vendor is accountable to itself. The chain closes on the vendor’s own attestation.
Independent accountability requires a party outside the execution chain — with no economic interest in the outcome — to attest that the governance state was valid. Not that the model is safe. Not that the hardware attestation was valid. That the specific decision, under the specific authority configuration, was governed correctly and the evidence is independently verifiable.
That is a certification claim, not a compliance claim. The distinction matters. Compliance is self-assessed against a standard. Certification is externally assessed against a standard by a party with standing to certify.
Why All Three Together
Each property is necessary. None is sufficient alone.
Explainable without auditable: you can describe the governance context in the moment, but the description is not preserved in a form that survives the session.
Auditable without explainable: you have complete logs, but they record what happened without the governance context that makes the logs interpretable.
Accountable without the other two: someone is responsible, but there is nothing to be responsible for — no stable explanation, no verifiable record.
The three properties are a system, not a checklist. An enterprise that can claim all three has built external authority architecture. An enterprise that can claim one or two has built some governance and called it complete.
Most current enterprise AI governance can claim partial observability — some logging of agent actions — and nothing else. The explainability claim rests on model self-reporting. The accountability claim rests on policy documents. Neither survives contact with an independent reviewer who is not inclined to trust the organization that produced them.
What This Requires
None of these three properties requires a more capable model. They require a different architecture.
Explainability requires external recording of the governance envelope at decision time, before the model moves on, by a system the model cannot modify.
Auditability requires tamper-evident records in independently parseable formats, complete for all consequential actions, verifiable by parties who do not trust the producing organization.
Accountability requires cryptographically signed authority grants, externally recorded, with a certification layer that independently attests to governance state under adversarial conditions — not just nominal ones.
These are engineering requirements, not philosophical ones. They can be built. They can be certified. They can be independently verified.
The question is not whether they are achievable. It is whether organizations deploy agents before or after building them.
Given the pace of the container transition — 14-hour autonomous runs, 99.8% of organizational AI output through agents, the federal government now requiring AI governance evidence at clearinghouse scale — the window for “before” is closing.
Trusted autonomy is not a property of a model. It is a property of a system.
James Ford is Chief Architect at GAIN Credit and founder of Equilateral AI. The Equilateral Agent Governance Scorecard (CC BY 4.0) and Raknor Agent Governance Standard v1.0 (CC BY 4.0) define testable criteria for all three properties at equilateral.ai/scorecard.html and raknor.ai/standard.html.