When a team adds AI to a workflow — triage, recommendations, routing — two questions immediately follow. The first: "Is this AI change approved?" The second: "What did the AI actually do on this specific case?"
Most teams conflate these into one problem. They are not the same. The first is about approving changes before they go live. The second is about recording what happened during a live decision. Treating them as interchangeable creates paper assurance where teams need operational proof.
This distinction matters whether you are a 10-person fintech or a regulated enterprise. A startup processing refunds through AI-assisted triage needs to prove what happened on a specific case just as much as a bank does — the scale is different, but the question ("who approved what and why?") is the same.
For teams operating in regulated industries or selling to enterprise customers, the frameworks make this explicit. ISO 42001 Clause 8, NIST AI RMF Govern and Map functions, and EU AI Act Article 9 all require pre-deployment approval for AI systems. ISO 42001 Clause 9, NIST AI RMF Measure and Manage functions, and EU AI Act Articles 12 and 26 require post-deployment monitoring. The frameworks are clear that both layers are necessary. The architectural gap is in connecting them at the case level — knowing that the approval record and the live decision are about the same thing. None of the frameworks prescribe how to do it.
For a detailed comparison of how each framework handles this distinction, see How Four AI Governance Frameworks Handle Approval vs. Runtime Evidence.
The Short Version
| Aspect | Governance-first approval system |
|---|---|
| What it is | The approval control plane for AI systems and AI changes |
| What it proves well | Who approved what, under which policy, with what evidence |
| What it does not address | What actually happened on a specific runtime decision |
| Best fit | Regulated or multi-stakeholder deployments with AI in production |
| Core artifacts | Inventory, policy, risk assessment, release packet, exception record, review log |
| Must be paired with | Runtime decision records and a case-level evidence trail |
What a Governance-First Approval System Actually Is
A governance-first approval system is the layer above the model runtime that decides whether an AI system or AI change is allowed into production, under what conditions, with whose sign-off, and with what review cadence.
In practice, it answers concrete questions. Can we switch the model behind AI triage for this queue? Can we change the prompt bundle? Can we add a new retrieval source? Can we expose a new plugin? Can we broaden the set of cases where AI is allowed to recommend execution?
Think of it as the AI equivalent of change control, model risk governance, and release management combined. It sits in a different layer than runtime control. The runtime control layer decides what an operator can see, approve, or execute on a live case. The governance-first layer decides whether that runtime behavior is allowed to exist in production at all. An operator who can see a recommendation is operating within a runtime control boundary. But that runtime boundary itself had to be approved by the governance layer before the system ever touched a live case.
What Usually Sits Inside It
A serious deployment typically contains six objects.
1. AI system registry. Every AI capability in scope: owner, intended use, queue or workflow, user population, risk tier, model or provider, retrieval dependencies, tool integrations, operational status. The registry should distinguish between triage classification, summary generation, suggested next steps, and any workflow that can surface or trigger a plugin action. ISO 42001 Annex A controls on AI system inventory define this layer.
2. Policy and risk layer. AI policy, acceptable-use rules, impact assessments, risk assessments, treatment decisions. This documents which workflows can use AI, what data can be exposed to the model, which outputs are advisory only, which require human review, which must never execute without a second control. The NIST AI RMF Map function requires organizations to establish this context. EU AI Act Article 9 requires a documented risk management system that operates throughout the AI system's lifecycle.
3. Approval workflow. The sign-off machinery. Who reviews, in what order, for which type of release. A prompt tweak for low-risk categorization should not follow the same path as a new model plus a new action provider in a finance exception workflow. Route changes differently based on blast radius.
4. Release packet. The evidence bundle attached to the approval decision. You do not approve "the model" in the abstract. You approve a release bundle: model, provider, and version; prompt bundle or system-instruction set; tool allowlist or action-provider scope; retrieval configuration or corpus snapshot; guardrail settings and policy thresholds; evaluation results and known limitations; rollback plan and operator guidance. The release packet is the unit of approval. It stays with the system until the next release.
5. Exception and waiver management. Emergency releases, temporary bypasses, compensating controls, expiry dates. If this object does not exist, the real approval process moves into side channels. Someone gives approval in chat, nobody can tell later whether the bypass was temporary or still in effect. Organizations with weak exception management end up with permanent emergency configurations and no record of when they started.
6. Periodic review and corrective action. Regular review of system ownership, model drift, incident patterns, override rates, denied paths, exception expiry, and whether approved controls still match how the workflow is actually being used. ISO 42001 Clause 10 and the NIST AI RMF Manage function both require this. It keeps the approval layer honest.
What Governance-First Systems Prove Well
Governance-first systems are strong at proving ex ante control.
Who owns this AI workflow? Who approved the prompt change? Which policy and risk treatment were in force? What evidence supported release? Which exception was granted, by whom, and until when? When was the last formal review?
These are the questions that governance-first systems answer crisply. An auditor can ask: "Show me who approved this AI change." A strong governance-first system responds with a complete record — owner, reviewers, policy applied, risk assessment, evidence bundle, approval date, sign-off.
That is why governance-first systems work well in regulated, multi-stakeholder, and audit-sensitive deployments. They create ownership. They reduce undocumented changes. They give legal, compliance, privacy, security, and operations teams a common approval structure. For organizations running sensitive workflows — finance exceptions, medical triage, benefit determinations — approval records and release packets make it much easier to show that a workflow was reviewed before it touched customers, funds, or regulated processes.
What They Do Not Address
Used alone, governance-first systems do not prove runtime reality.
They do not tell you: the exact prompt used on ticket T-48192, which retrieved documents influenced that recommendation, whether a tool was shown or blocked or unavailable on that case, whether a human overrode the AI recommendation, what plugin action ran, what the downstream system returned, whether the outcome matched the approved intent.
The limitation is architectural. An approval record describes what was allowed into production at release time. It does not describe what happened during one live decision. Approval records without runtime evidence are incomplete — they prove governance, not operations. Runtime logs without approval records are also incomplete — they prove what happened, but not whether what happened was allowed. Both are required. Neither is sufficient alone.
EU AI Act Article 12 is the most prescriptive existing requirement for runtime logging, mandating tamper-resistant automatic event recording for high-risk systems with a minimum six-month retention period. But even Article 12 focuses on system-level event logs, not case-level decision records. The case-level gap remains.
When Governance-First Alone Is Sufficient
There are deployments where governance-first approval may be sufficient on its own.
For stable pipelines with well-defined inputs and outputs — classic document processing, limited OCR extraction, batch classification — the approval layer can carry most of the control weight. The approval unit is clearer. The runtime behavior is more predictable. The change velocity is lower. When the system's behavior can be fully characterized by its configuration at deploy time, the release packet IS the primary evidence of what the system will do.
The need for runtime decision records grows with: the pace of AI capability changes, the involvement of retrieval or external tools, the presence of human-in-the-loop decision points, the sensitivity of downstream actions, and the regulatory exposure of the workflow. Conversely, if AI is purely advisory with no downstream action execution, or the workflow is internal-only with no customer, regulatory, or financial exposure, governance-first alone may carry the full weight. A quarterly-reviewed document classifier may need only approval governance. A daily-updated triage system handling payment exceptions does not.
When It Breaks Down
For fast-changing AI workflows inside operations, support, or finance exception handling, approval without runtime evidence ages badly.
Prompt bundles change. Retrieval sources change. External tools change. Provider behavior changes. If the ticket-level trail is weak, the organization ends up with a strong review packet created three months ago and a weak explanation of the actual decision made yesterday.
As AI moves from advisory to autonomous execution within guardrails, the gap between what was approved and what actually happened on a given case becomes more dangerous, not less. An advisory recommendation that an operator ignores has limited blast radius. An autonomous action that executes within approved boundaries but produces an unexpected outcome needs a complete decision record — was the action within the approved scope? Did the guardrails execute as expected? What external system returned an unexpected result?
The market for governance tooling is beginning to address this gap. Some platforms now offer continuous agent trace evaluation, runtime policy violation monitoring, and active enforcement through guardian agents. The gap between approval governance and runtime evidence is narrowing. But for most organizations, the integration between their governance platform and their operational systems does not yet exist in practice.
A Concrete Example: Two Scenarios
Scenario 1: Where governance-first is sufficient.
A team runs a document classification pipeline. The model receives a PDF, classifies it into one of twelve categories, and routes it to the appropriate queue. The model is updated quarterly. The prompt is versioned and stable. The classification taxonomy does not change.
The release packet — model version, prompt, taxonomy, evaluation results, routing rules — is the primary evidence. Runtime monitoring matters for drift detection and queue distribution, but the approval record substantially describes the system's behavior. A case-level decision record is nice-to-have for auditing, not essential for proving control. The approval system can stand alone.
Scenario 2: Where it breaks down.
A team handles payment exceptions and wants AI to help with failed-transaction reprocessing. They switch to a new model for issue summarization, revise the prompt that recommends the next best action, expose a reprocess action provider for a narrow ticket class, and require human review before execution.
The governance-first approval system captures the release packet correctly. But that does not answer the manager's question later: "What happened when the operator handled this reprocess case?"
The runtime decision record needs to show: the original ticket context, the AI recommendation shown to the operator, whether the reprocess action was visible or blocked or unavailable, who reviewed the case, who executed the action, what the downstream payment system returned, how the ticket changed afterward, whether the reprocess succeeded or failed.
The approved release record says the workflow was allowed. The ticket-level runtime record says what actually happened. Both are required for a complete control model.
This is also why what to log for external actions matters so much. Once a workflow crosses a system boundary, a governance packet alone is not enough.
The Right Rollout Order
For LLM, retrieval, and agentic workflows, the better sequence is usually:
- Instrument runtime decisions first.
- Create a decision ledger tied to the case record.
- Wrap releases in a governance-first approval system.
- Review exceptions, overrides, denied paths, and drift on a cadence.
This is a more defensible order than starting with approval paperwork alone. Runtime evidence tells you what is actually happening. Approval governance tells you what should be happening. You need both, but evidence first means the governance layer has something real to review.
For narrower workflows — document processing, OCR, batch classification — governance-first can come earlier because the runtime behavior is more stable and the approval unit is clearer.
The Design Rule
Three layers:
- Approved release record = what was allowed into production.
- Runtime decision record = what happened on a specific case.
- Immutable evidence archive = what you can still prove later.
The third layer is the one most teams skip. Immutability means append-only writes — once evidence is recorded, it cannot be modified or deleted by the actors involved in the decision. In practice, this usually means write-once storage for action records, cryptographic timestamping or hash chains for integrity verification, and separation of the evidence store from the operational runtime so that a system failure or a bad actor cannot alter the record after the fact.
EU AI Act Article 12 moves in this direction with its requirement for tamper-resistant logs. ISO 42001 Clause 9 requires that monitoring evidence be preserved for management review. But neither prescribes the full architecture. That is still an implementation decision — and one worth making early rather than retrofitting later.
Where Latch Fits
Latch is a runtime control layer — the operational system where approved AI capabilities meet live decisions and evidence survives. For a full definition of this emerging category, see The Runtime Control Layer: What This Category of Software Is and Why It Exists.
The approval control plane sits above Latch: AI registry, policy, approval workflows, release packets. What Latch preserves is the runtime decision record, built on five capabilities: unified intake that keeps case context on one record, AI recommendations bounded by policy, approval and role enforcement attached to the case, plugin action execution with structured result capture, and an immutable case-linked audit trail.
Latch does not replace an enterprise AI management system. It means the approval control plane has somewhere real to land. The governance shell sits above, but the proof of the live decision stays with the case.
If you read The Case Record as a System of Action, this is the same argument from an AI-governance angle. The case is not just where someone types notes. It is where operational memory has to survive.
Continue Reading
- How Four AI Governance Frameworks Handle Approval vs. Runtime Evidence
- The Runtime Control Layer: What This Category of Software Is and Why It Exists
- AI Triage Needs a Control Plane, Not Just Better Prompts
- Why Approval, Auth, and Audit Logic Must Stay in the Core
- What to Log When Operators Trigger External Actions
- What Auditors Need to See in a High-Risk Approval Workflow