The blueprint and the ledger: how AI architecture maps to AI governance.
Every AI system has two descriptions. The architecture shows how it is built. The governance record shows who agreed it should run, what it may do, and who answers for it.
1. What an architecture diagram shows
Users and channels. The people and systems that interact with the AI, and the channels they use: chat, email, a web form, an API.
The AI application and agent. The application logic and the agent runtime that plans, decides and acts within it.
Tools and MCP. The tools layer, with the MCP clients and servers through which the agent reaches other systems.
External services. The outside services the agent calls and the data that leaves the organization to reach them.
The LLM provider. The model or models the application depends on, and the provider that runs them.
Knowledge and RAG. The retrieval layer that feeds the model company documents and other knowledge at answer time.
2. What it leaves between the boxes
- 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.
3. The architecture-to-records rubric
One governance question per layer, the runtime capabilities that observe and control it, the SanctumShield record that answers it, and the person accountable for the answer.
| Architecture layer | Governance question | Observe and control (by category) | SanctumShield record | Accountable owner |
|---|---|---|---|---|
| Users and channels | Who may use AI, for what, and with which data? | Identity and access, usage telemetry | 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? | Guardrails, execution monitoring | 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? | MCP gateway, runtime AI security | Executive Risk Report (tool and gateway findings); AI Acceptable Use Policy | CISO |
| External services | Which outside parties receive our data, and on what terms? | Data loss prevention, egress monitoring | Executive Risk Report (sub-processors); Verification URL | Legal counsel |
| LLM provider | Which models are approved, and who signs off on a change? | Model inventory, usage telemetry | Executive Risk Report (model register); Board Memo | CTO or CIO |
| Knowledge and RAG | Which sources are trusted, and how is retrieved content handled? | Retrieval logging, content filtering | Executive Risk Report (retrieval provenance) | Data owner |
| Whole system | Can we show all of this to a board, auditor or insurer? | SOC dashboards and audit logs | All five records, dated and verifiable | CEO, with board oversight |
4. Every layer has an owner
R = responsible, A = accountable, C = consulted, I = informed. Adjust the roles to your organization. Every row keeps exactly one Accountable owner.
| Decision | Board | CEO | CISO | Legal | Engineering lead | Business owner |
|---|---|---|---|---|---|---|
| Approve an AI use case to run | I | A | C | C | R | R |
| Set an agent's decision boundary | I | C | C | C | R | A |
| Approve a new tool or MCP server | I | A | C | R | C | |
| Approve an outside data recipient | I | C | A | R | C | |
| Approve a model change | I | C | I | R | A | |
| Publish the AI Acceptable Use Policy | I | C | A | R | C | C |
| Accept the Executive Risk Report | A | R | R | C | C | C |
| Confirm role-based training completion | I | I | A | I | R | R |
5. Why the two drift 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.
6. Download the worksheet
The rubric and the starter RACI as an editable spreadsheet and a printable PDF, with empty columns for your system, owner name, record and date, and next review. Free, no sign-up.
7. In one sentence
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.
Read the three capabilities compared, approach by approach, at AI governance, AI security and AI observability. Learn it in depth, role by role, in the paid SanctumShield Academy module From Blueprint to Ledger. The essay behind this page: The Blueprint and the Ledger.