Every AI system has two descriptions. One is the architecture diagram, which shows how the system is built. The other is the governance record, which shows who decided it should run, what it may do, and who answers for it.
In an ideal world the two are drawn together. In practice the blueprint usually comes first, and the ledger follows later, if it comes at all. This piece looks at what each one shows, how they map together layer by layer, why they so often drift apart, and why the ledger is still needed once the blueprint is built.
What a good architecture diagram shows
The AI architecture diagrams circulating today are getting better, and they deserve credit. A typical one names six parts: the channels where people and systems interact, the AI application and its agent runtime, the tools layer with MCP clients and servers, the external services the agent reaches, the model provider, and the knowledge layer for retrieval. That vocabulary is now shared across vendors and teams, which is real progress.
The best of these diagrams also carries sound advice. Not every AI application needs an agent, a tools layer or retrieval. The right architecture depends on the use case, and a fixed workflow is often the better choice.
What the diagram leaves between the boxes
A parts list tells you what exists. It does not tell you where trust changes, which way untrusted content flows, or who must approve an action. Those facts live between the boxes, and they are the ones a risk assessment needs.
- Trust boundaries. Retrieved documents, tool results and messages from outside services are untrusted input, even when they arrive through a trusted pipe.
- The return path. Content that flows back into the model is the main route for prompt injection.
- Credentials. Whose authority the agent acts under, how that authority is scoped, and where tokens are kept.
- The gateway. A control point between agents and the tool servers they call.
- Human approval. The points where a person must agree before an action leaves the system.
None of this is a shortcoming of the diagram. A component map was never meant to carry it.
Three bands: observe, control, govern
Around the architecture sit three kinds of capability, and they answer three different questions.
- Observability answers what did the agent do? Telemetry, logs and traces make the system visible after the fact.
- Controls answer what is the agent stopped from doing? Runtime AI security, guardrails, MCP gateways and the security operations center enforce limits in real time.
- Governance answers what was the agent permitted to do, and who agreed? It produces dated, owned records that a board, an auditor or an insurer can read.
The first two are engineering capabilities, and they are improving quickly. The third is a responsibility. One line puts the difference plainly: “The confidence score where an agent is allowed to act on its own is not a tuning setting. It is a permission. Like any other permission it needs to be written down somewhere an auditor can find it, with the name of the person who set it and the date it last changed.” (Lindsay Hiebert, Oct 2026)
Controls enforce that line. Observability shows whether it held. Governance is where it is written down and owned.
Approaches that help, and what each one still needs
Many good approaches surround AI governance, and each one adds real value. Most of them produce evidence. Governance is the step that turns evidence into a dated decision with a named owner.
| Approach | What it does well | What governance still needs |
|---|---|---|
| AI agents with built-in rules | Follows instructions and policies consistently at machine speed | A person who agreed to those rules and owns the outcome |
| Observability platforms | Shows what the system did, in detail, after the fact | A record of what it was permitted to do, and by whom |
| Runtime AI security and guardrails | Blocks unsafe inputs, outputs and actions in real time | The written decision that set those limits |
| MCP gateways | A control point for which tools an agent may reach | A named owner for each tool and its scope |
| SOC and SIEM | Detects and responds to incidents across the estate | Pre-agreed accountability for AI-specific decisions |
| Model evaluation and red teaming | Tests quality, safety and robustness before release | A sign-off that the residual risk is accepted, and by whom |
| Questionnaires and checklists | Gathers answers across teams quickly | Answers tied to each AI system, with an owner and a date |
| Policy templates | A fast, well-structured starting point | An assessment of the organization's actual AI use behind it |
| Training certificates | Confirms someone attended | Role-based training with a verifiable record of completion |
| Point-in-time assessments | Expert findings at a moment | A record that is kept current as the architecture changes |
An agent is worth a special note. It can follow a rule written in its prompt or in a policy file, and it can do so very well. It cannot agree to that rule on the organization’s behalf. Someone accountable has to.
Every layer has an owner
The simplest way to connect the blueprint to the ledger is to ask one governance question for each layer, then name one accountable owner and one record for the answer.
| Architecture layer | Governance question | SanctumShield record | Accountable owner |
|---|---|---|---|
| Users and channels | Who may use AI, for what, and with which data? | AI Acceptable Use Policy; role-based training record | CISO |
| AI application and agent | What may the agent decide alone, and where is that line written? | Executive Risk Report (decision boundary); Board Memo | Business owner of the use case |
| Tools and MCP | Which tools may the agent call, under whose authority? | Executive Risk Report (tool and gateway findings); AI Acceptable Use Policy | CISO |
| External services | Which outside parties receive our data, and on what terms? | Executive Risk Report (sub-processors); Verification URL | Legal counsel |
| LLM provider | Which models are approved, and who signs off on a change? | Executive Risk Report (model register); Board Memo | CTO or CIO |
| Knowledge and RAG | Which sources are trusted, and how is retrieved content handled? | Executive Risk Report (retrieval provenance) | Data owner |
| Whole system | Can we show all of this to a board, auditor or insurer? | All five records, dated and verifiable | CEO, with board oversight |
Every organization will adjust the owners to its own structure. The one rule worth keeping is that each decision has exactly one accountable person.
Why architecture and governance rarely evolve together
Teams want the blueprint and the ledger drawn together. Several ordinary forces pull them apart.
- Different clocks. Engineering ships weekly. Policy, legal and board reviews run quarterly. Each side moves at the pace its work requires.
- Different owners. The architecture belongs to engineering. The risk register belongs to security, legal or compliance. The board memo belongs to the executive team. No single person holds all three.
- Tools govern their own layer. Each runtime tool handles its own layer well. The question of who agreed to the whole system sits above every tool.
- Capability arrives through updates. A model upgrade, a new connector or an agent feature can add a capability overnight without a new design review.
- Budget follows the build. Spending is approved for the system, and the record of responsibility is often scheduled for later.
These forces are natural, and none of them reflects a lack of care. They do mean the ledger needs its own deliberate step.
Why governance is still needed after deployment
Responsibility cannot be deployed. A guardrail can block an action, and a log can record it, but neither can sign the decision to run the system. Boards, regulators, auditors and cyber insurers increasingly ask the same question: can the organization show how its AI is governed, and who is accountable? They are asking for records.
That is where SanctumShield fits. In a single guided session it produces five dated, verifiable records that tie the architecture to its owners:
- Executive Risk Report. The organization’s AI use, layer by layer, and the governance gaps that matter most.
- AI Acceptable Use Policy. What people and agents may do, written for the organization’s own tools.
- Board Memo. A plain-language summary the board can act on and record in its minutes.
- Verification URL. A link an auditor, insurer or customer can use to confirm the records and their dates.
- Role-based training record. Verifiable completion of AI literacy and governance training through the SanctumShield Academy.
To our knowledge, no other product produces all five records as one dated, verifiable set from a single session. Runtime tools and the SOC keep the system safe while it runs. SanctumShield records who agreed it should run, on what terms, and who answers for it. The two work best side by side.
Drawing them together
The ideal is simple to state. Every time the blueprint gains a layer, the ledger gains a line. Name one accountable owner for each layer. Write the decision boundary down before the agent acts alone. Run the risk assessment again when a model, connector or tool changes. Keep the record somewhere a person outside the team can verify.
Observability shows what the agent did, controls stop what it must not do, and governance records what it was permitted to do and who agreed. Architecture tells you how the system works. Governance tells you who stands behind it. A well-run AI program keeps both current.
Go further:
- The rubric and the worksheet: https://sanctumshield.com/blueprint-and-ledger
- Governance, security and observability compared: https://sanctumshield.com/governance-security-observability
- Role-based training in the SanctumShield Academy: https://academy.sanctumshield.com