AI Controls and Governance
Who is responsible when an AI agent makes a wrong decision?
An agent approves an exception it wasn't supposed to approve. It sends a recommendation to the wrong customer segment. It produces an output that is technically within policy but wrong for the situation in a way nobody can immediately articulate.
The first instinct, sometimes voiced out loud, is to say the agent is responsible. That isn't an answer. Agents aren't legal persons. They don't hold accountability. The decision about who in the organisation is responsible, and on what basis, still has to be made by humans — and in most cases it hasn't been made clearly in advance.
The Legal Reality
In most jurisdictions, deploying an AI agent doesn't transfer liability to the model provider. The terms of service for every major model provider make this explicit: the organisation using the model is responsible for how it's deployed and what it produces. That won't change with regulation — if anything, EU AI Act implementation is moving toward requiring organisations to demonstrate they exercised appropriate oversight, not just that they used a compliant model.
This means accountability sits with the organisation. Within the organisation, it has to land somewhere specific. Diffuse responsibility — "the whole team is accountable" — functions as no accountability at all when a decision needs explaining to a board or a regulator.
The Difference between Accountability and Blame
These are worth separating, because conflating them is what makes the question feel harder than it is.
Blame is retrospective and punitive. It looks for fault after something has gone wrong. Accountability is structural and prospective. It asks: who can explain this decision — what the agent was given, what it was permitted to do, what context shaped its output — before anything goes wrong, as a matter of how the system is designed.
The person accountable for an agent's decision doesn't have to be the person who built the agent, or the person who approved the deployment, or the person whose workflow it operates in. It's whoever the organisation has designated to own what that agent knows and does. That designation should exist before the agent acts. In practice, it usually doesn't — the accountability owner is discovered rather than appointed, at the moment the question arrives.
What Explaining a Decision Actually Requires
This is where most governance thinking stops short.
Explaining what the agent did is relatively straightforward. Logs record the outputs. Monitoring captures the sequence. If the question is "what did the agent produce and in what order," existing infrastructure answers it reasonably well for most deployments.
The harder question is what the agent was working from. The goals it was given before the task began. The constraints it was operating under. The decisions it was briefed on that shaped how it interpreted the situation. That isn't in the output logs. It's in whatever record exists of what the agent was given before execution started — if that record exists at all.
Two organisations can have identical monitoring infrastructure and face this question very differently. One has a coherent record of what each agent was briefed with before deployment. The other has system prompts in version control, configuration files spread across repositories, and a set of decisions that were made in conversations nobody thought to record. The first organisation retrieves. The second reconstructs — and reconstruction, under scrutiny, is a different thing from a record.
Where the Accountability Gap Actually Sits
The gap isn't usually in governance policy. Most organisations deploying agents have policies in place — acceptable use frameworks, approval processes, risk thresholds. The gap is between policy and the agent's actual operating context: what the agent was concretely given, for this task, before it acted.
Policy governance sets rules for agents in general. It doesn't record what this agent, for this decision, was working from. Monitoring observes what the agent produced. It doesn't record what it was given. The record that sits between policy and output — the agent's operating brief at the moment it acted — is what most organisations are missing. And it's exactly what accountability requires when a specific decision needs explaining.
The Role that Makes Accountability Workable
Accountability for AI decisions in practice lands on whoever the organisation has pointed at the problem. The title varies: Head of AI, Chief Digital Officer, Chief of Staff, platform engineer, compliance lead. The industry hasn't agreed a name for the role. What the role requires doesn't change with the name.
The person in that role needs to be able to answer four questions about any agent decision: what was the agent permitted to know, what was it permitted to do, who authorised those parameters, and where is the record. If the answer to the last question is "it would take us a few days to piece together," the accountability structure is weaker than it appears.
Engramic's approach
How Engramic Approaches it
There are multiple ways to address the input record problem. This is one approach.
Engramic is designed to make the agent's operating brief retrievable before a decision needs explaining. Before an agent acts, the knowledge it works from — the goals, constraints, and decisions relevant to its task — is authored in Engramic and packaged as a coherent record before execution begins. That record is what the agent was given. When a constraint changes, the change is recorded alongside what it replaced and why.
The practical consequence is that the question "what was the agent working from?" has an answer that predates the incident, not one assembled from whatever evidence survived it.