Governance that travels with the Transformation. Not governance that chases it.
Most organisations are governing the transformation they designed. Not the one that is actually running.
We asked a senior leader recently what would happen if one of their AI systems made a decision that caused commercial harm tomorrow.
She knew the answer immediately.
"We would find out who approved the system. And that person would be accountable."
We asked a second question.
"Does that person currently have visibility into how the system is making decisions?"
The pause that followed told me more about where the governance actually sits in that organisation than any framework document would have.
This is the gap most governance structures don't close. Not the absence of rules. The distance between the person named as accountable and the system they are supposed to be accountable for.
In most organisations, that distance is significant. And as the systems making decisions inside enterprises scale faster than the structures designed to oversee them, the distance is growing - not closing.
What governance was built for - and what it isn't
Most governance frameworks were designed for a specific kind of decision: the one that happens at a fixed point in time.
Approve the programme. Set the risk parameters. Review quarterly. The governance sits above the system — defining what should happen, and trusting that the people and processes below it will interpret correctly.
That model worked when the system below it was relatively stable and the pace of change allowed for periodic review.
Neither condition holds now. Only 33% of organisations have embedded responsible AI into core operations. The gap between claiming governance and running governance is not a compliance failure. It is a structural one. The governance was written for a world where policy and execution could safely sit in different places. That world has narrowed considerably.
The alternative — and the approach beginning to separate the organisations scaling AI from those accumulating risk — is governance that travels with the system. Guardrails embedded in the architecture. Controls that move with the technology as it scales, interacts externally, and encounters conditions the original framework never anticipated.
This is the technical response to the pace problem. And it is necessary.
But it does not close the accountability gap.
The gap that the technical layer cannot close
54% of COOs are concerned about regulatory and compliance uncertainty related to agentic AI - compared with just 20% of CIOs and CTOs. That gap in concern is not a personality difference. It is a visibility gap. The people deploying the technology are not worried about what the people running operations are worried about. When those two groups are not looking at the same risk, control breaks down - not dramatically, but gradually, through the accumulation of decisions that were technically within the governance parameters and still produced outcomes nobody designed.
This is the accountability gap that sits above the governance architecture. And it is structurally unowned in most organisations.
The governance layer can surface a deviation from defined parameters. It cannot hold accountability for the outcome of a decision made within those parameters that nonetheless produced something the organisation didn't intend. It can flag an anomaly. It cannot decide what the organisation's response to that anomaly means strategically, commercially, or ethically. It can enforce the rules as written. It cannot determine when the rules themselves need to change.
Those decisions require a named human. And that human requires the proximity, the authority, and the information to act.
What only the C-suite can hold
The C-suite role in this environment is not to build the governance layer. It is to hold accountability for what the governance layer cannot automate.
Three things that require the named seat — and that no architecture, platform, or policy framework can substitute for.
The definition of the edge cases. Every governance system has a boundary. The decisions about where that boundary sits - what the system can decide autonomously, what it must escalate, and what cannot be delegated to a system at all - are strategic decisions. They require leadership judgment about risk tolerance, commercial priority, and what the organisation is willing to own when things go wrong. These cannot be outsourced to a working group. They require a named executive who holds them and revisits them as the system evolves.
Outcome accountability when the system produces something unintended. Embedded governance can catch deviations from defined parameters. It cannot hold accountability for the outcome of a decision made within those parameters that nonetheless produced a result the organisation did not design for. That accountability has to sit with a person. And that person has to have enough proximity to the system - and enough authority - to understand what happened, why, and what the organisation does next.
The signal that the governance itself needs to change. The governance layer is only as good as the assumptions it was built on. When an incident reveals a gap, when a regulatory requirement shifts, when a new capability arrives that the current framework didn't anticipate — someone has to be close enough to the system and senior enough to act to say: the governance needs to change. That is not a technical decision. It is a leadership one. And in most organisations, nobody is formally accountable for making it.
Three questions worth sitting with
When your systems hit an edge case - a situation the governance framework wasn't designed for -— who is accountable for the decision? Is that person named? Do they have the authority and the information to act?
What is the gap between what your governance framework says is happening and what the people actually running operations experience? And who in your organisation knows the honest answer to that question?
Is there a mechanism in your current governance that can trigger a change to the governance itself — without requiring a board resolution or a full programme restart?
The accountability moment - the one where a leader discovers they were responsible for something they had no visibility into - is not going to become less frequent as systems scale and autonomy grows.
The organisations that navigate this well are not the ones with the most comprehensive governance documents. They are the ones that have paired the technical governance layer with clear human accountability above it - named, structured, and connected to the real operating state of the systems it is supposed to oversee.
Governance that travels with the system addresses the technical layer.
Accountability that travels with the governance is the leadership decision.
ECC works with C-suite leaders in pharma, financial services, and complex regulated environments to design the operating model conditions that make both possible. If this is the conversation you are navigating, I would welcome continuing it.




Comments