Six Frameworks Answer the Question. None of Them Ask Yours.
TOGAF, COBIT, ITIL, SAFe, programme management and enterprise risk each answer a real question about the enterprise. So do the AI management standards, and so do the vendor agent platforms. None of them answers the one that decides whether an agent should have acted.
Written as at 26 September 2026. It reflects sources, products, standards and regulation at that date; later developments may change the analysis.
enterprise-architectureai-governancetogafcobitagentic-ailetters
There is a point in most enterprise AI programmes where the prototype stops being the difficult part.
The model works. It summarises the ticket, finds the clause, drafts the response, maybe calls a tool. Stakeholders have seen it and they like it. And then a different set of questions arrives, usually from someone who was not in the demo. Which version of the policy did it use? Could it see another customer’s data? Who authorised that tool call? What happens after a timeout? Can a document tell the model to ignore its instructions? How do we reproduce a decision made three months ago, when the person who made it has left and the model has been replaced twice?
Those questions are not about the model. They are about the enterprise the model is now inside.
The reasonable objection at this point is: we already have frameworks for that. And you do. That objection deserves a straight answer rather than a brochure, so here is mine.
What the frameworks you already run are for
TOGAF develops and governs the enterprise architecture: what the architecture is, how it changes, who stewards it. COBIT sets governance and management objectives: who is accountable, against which control. ITIL organises service management: how the thing runs once it is live, and who owns it. SAFe and its relatives coordinate delivery at scale: how the work is built. Programme methods carry the business case and the benefits: whether it paid. Enterprise risk management asks what could go wrong and what the appetite is.
Every one of those is a real question. Every one of them is answered better by the framework built for it than by anything I could offer. None of this is a criticism, and none of it is a gap in their design. They were all shaped before software could decide.
The AI-specific layer, and where it stops
The answer I usually get next is that the AI-specific standards cover the rest. They cover a great deal. NIST’s AI Risk Management Framework gives you a way to reason about AI risk across a lifecycle. ISO/IEC 42001 gives you a management system you can certify against. The EU AI Act gives you obligations that attach to particular uses.
What they were built for, though, is a system whose behaviour can be characterised before deployment and reviewed by a person afterwards. The Cloud Security Alliance made this point directly in April 2026, in a research note on what it called the AI agent governance framework gap: NIST’s framework assumes behaviour that can be characterised at deployment; ISO/IEC 42001 was not written for real-time policy enforcement inside an agentic architecture; and the EU AI Act contains no definition of an agentic system at all, its provisions assuming that behaviour is known, documentable and stable when the thing ships. The same note reports that the missing elements across every framework it reviewed were human oversight mechanisms and evidence-quality audit trails — and that only a small minority of organisations surveyed could say they effectively govern AI access to their core business systems.
I am citing someone else’s research on purpose. This is the part of my argument where I would least like you to take my word for it.
The platforms do govern — inside their own boundary
The other fair objection is that the model vendors have solved this. Through 2026 the major agent platforms shipped real governance capability: agent identity, policy enforcement, tool permissioning, audit and observability. That work is serious and it is not marketing.
But a platform governs what happens inside the platform. Your consequential decisions do not stay there. A refund crosses from an agent runtime into a payments system. An access grant crosses into an identity provider. A contract position crosses into a document store, a CRM and eventually a court. The trajectory that matters runs across products, across vendors and across years — and it has to survive the day you change one of them.
If your enterprise architecture is defined by the agent platform you bought, you have not chosen an architecture. You have chosen a supplier.
The category errors
It is worth being blunt about the specific failures, because they are the ones I watch organisations walk into:
- A TOGAF architecture vision does not grant an agent authority.
- A COBIT objective does not, by itself, enforce an approval bound to a particular payload.
- An ITIL practice does not determine which version of an ontology was valid for an event that happened last March.
- A sprint review does not prove that a consequential automated action was lawful.
- A model evaluation does not show that the path taken to a correct answer was permitted.
And the reverse holds just as firmly. None of what I work on replaces portfolio prioritisation, architecture development, service ownership, programme control or regulatory interpretation. An organisation that dropped those in favour of an agent architecture would deserve everything that followed.
What actually changes
The difference is not that there are more boxes. It is that the unit of governance moves.
Traditional architecture governs systems, capabilities and change initiatives. Service and delivery frameworks govern practices and value streams. AI platforms govern model and agent execution within their product boundary. What none of them governs is the thing that decides whether an action should have happened: the runtime trajectory in which context is assembled, evidence is gathered, authority is evaluated, an action occurs or is refused, and an outcome is later observed — reconstructable afterwards by someone who was not there.
That trajectory is the unit. Four constructs carry it, and they are the whole of what I am proposing:
- The Context Contract. What an agent is permitted to know for this purpose, with provenance and time bounds. Not a prompt: a contract that can be enforced and shown.
- The evidence-first decision record. The record is produced by the act of deciding, not reconstructed afterwards from logs by someone motivated to be reassuring.
- Authority attenuation. Delegated authority that narrows as it passes, so no agent holds more than the task requires, and no chain of agents accumulates more than any link was granted.
- Agentic Flow Mining. Mining the real trajectories against the intended ones, because a system can reach an acceptable answer along an unacceptable path.
What I would do on Monday
Take one AI use case that is already in flight, and answer three questions about it in writing.
What may it change? Not what does it do — what state can it alter, and what is the worst version of that within its current permissions? Most teams discover the answer is wider than anyone intended, because nobody deliberately narrowed a credential that was provisioned for a pilot.
On whose authority? Name the person or the role, not the system. If the answer is “it has API access”, you have described a capability, not an authority.
What evidence would let someone reconstruct the decision in a year? If the honest answer is the application logs, and the logs do not record which policy version was in force, you already know the first thing to build.
Those three answers do not need a framework, a licence or my book. They need an afternoon. What they tend to produce is a much clearer view of whether the fourth question — do we need something for this — answers itself.
References
- Karimi, H. (forthcoming) The Contextual Agentic Enterprise, Preface and Chapter 24, §24.22.
- Cloud Security Alliance (2026) Research Note: The AI Agent Governance Framework Gap. 3 April 2026. https://labs.cloudsecurityalliance.org/research/csa-research-note-ai-agent-governance-framework-gap-20260403/
- Cloud Security Alliance (2026) Agentic AI Governance: NIST Standards for Autonomous Systems, v1. March 2026. https://labs.cloudsecurityalliance.org/wp-content/uploads/2026/03/governance-nist-ai-agent-standards-agentic-governance-v1-csa-styled.pdf
- NIST (2023) Artificial Intelligence Risk Management Framework (AI RMF 1.0). NIST AI 100-1, January 2023. https://www.nist.gov/itl/ai-risk-management-framework
- ISO/IEC 42001:2023 Information technology — Artificial intelligence — Management system. https://www.iso.org/standard/81230.html
Related
From Assistance to Agency: Why Enterprise AI Creates a New Architectural Problem
Letting a service desk assistant reset MFA is not phase two of the same programme. Once an agent can change state, the question becomes what it may change, and on whose authority.
A Model Can Recommend an Action. It Does Not Acquire Authority to Perform It
Directors ask whether their AI is safe. The better question is on whose authority it acts, because accuracy, confidence and technical access are not a delegation.
Evaluation Is Not a Test Phase
Most agentic programmes pick a model, write a prompt, add retrieval, and write the evaluations last — by which point the evaluations can no longer change the design. Reversing the order gives an architect something better than an opinion: gates that show whether a model swap, a prompt change or a new retrieval strategy measurably improved the system.