How Four AI Governance Frameworks Handle Approval vs. Runtime Evidence

Most teams ask the wrong question first.

They ask: "Are we compliant?" That question leads to a document review. Someone checks whether a policy exists, whether a risk assessment was completed, whether an approval record is on file. If yes, the team moves on.

The harder question — the one that matters during an incident, a customer complaint, or even a manager asking "what happened with that refund?" — is different: "Can we prove what happened on this specific decision, for this specific case, at this specific time?"

That question requires a different kind of evidence. It requires runtime proof, not just an approval artifact. This matters for every team that uses AI in a workflow with real consequences — not just regulated enterprises, but any team where a wrong decision costs money or trust.

Every major AI governance framework published in the last three years recognizes this. ISO 42001, the NIST AI Risk Management Framework, the NIST Generative AI Profile (AI 600-1), and the EU AI Act all require both pre-deployment controls and post-deployment monitoring. Even if your team is not subject to these frameworks today, understanding them is useful — especially if you sell to enterprise customers or plan to operate in regulated markets.

Understanding where each framework is strong and where each stops helps teams design systems that actually satisfy all four — rather than optimizing for one and leaving gaps in the others.

ISO 42001: The Management System Approach

ISO/IEC 42001:2023 is the first international standard for AI management systems. It follows the same Annex SL structure as ISO 27001, which means organizations familiar with information security management systems will recognize the pattern: context, leadership, planning, support, operation, performance evaluation, improvement.

The standard defines 38 controls in Annex A, specifically targeting AI-unique risks: bias, transparency, accountability, data quality, and lifecycle governance.

Where it is strong on pre-deployment approval:

ISO 42001 Clause 8 (Operation) requires organizations to establish gated approval stages for AI systems. Models must pass defined criteria — bias tests, security assessments, ethical reviews — before advancing to production. Clause 5 (Leadership) requires top management to assign accountability for AI decision-making and integrate governance into business strategy. Clause 6 (Planning) requires documented risk assessments, mitigation strategies, and incident response procedures before deployment.

The practical effect is that ISO 42001 creates a formal approval control plane. Every AI system in scope must have an owner, a risk tier, a documented intended use, and a review history. Changes require evidence of evaluation before release. This is governance-first in the clearest sense.

Where it is strong on runtime monitoring:

Clause 9 (Performance Evaluation) mandates continuous monitoring, measurement, analysis, and evaluation of AI system performance. This includes internal audits, management reviews, and ongoing assessment of whether deployed systems still meet their stated objectives. The standard expects organizations to dedicate meaningful effort — industry guidance suggests roughly 30 percent of AI risk management resources — to post-deployment monitoring for model drift, emerging risks, and performance degradation.

Clause 10 (Improvement) requires corrective action when monitoring reveals problems, closing the loop between runtime observation and governance response.

Where it stops:

ISO 42001 does not prescribe what runtime evidence should look like at the case level. It requires that monitoring happen and that results feed into management reviews, but it does not define a logging schema, a retention period, or a mechanism for linking a specific runtime decision to the approval record that authorized the system's behavior. That implementation gap is left to the organization.

This matters because two organizations can both be ISO 42001 certified and have very different abilities to answer the question: "What happened on this specific case?" One might have a rich decision ledger tied to each ticket. The other might have system-level performance dashboards with no case-level drill-down. The standard permits both.

NIST AI RMF: The Risk-Based Feedback Loop

The NIST AI Risk Management Framework (AI 100-1), published in January 2023, organizes AI governance around four core functions: Govern, Map, Measure, and Manage. Unlike ISO 42001, it is not a certifiable standard. It is a voluntary framework designed to help organizations identify, assess, and mitigate AI risks through a continuous feedback loop.

Where it is strong on pre-deployment approval:

The Govern function establishes organizational culture and processes for AI risk management. It defines accountability structures, risk appetite, and the policies that determine whether an AI system can proceed to deployment. Map contextualizes the system: its intended use, its risk profile, its stakeholders, its deployment environment. Together, Govern and Map create the pre-deployment approval infrastructure — the documentation, the sign-offs, the risk tiers that determine what scrutiny a system receives before going live.

NIST recommends establishing approval workflows for high-risk AI applications as part of governance policies, with risk-tiered review cadences and an AI Risk Committee operating on a defined schedule.

Where it is strong on runtime monitoring:

The Measure and Manage functions address post-deployment. Measure applies quantitative, qualitative, or mixed-method tools to analyze, benchmark, and monitor AI risk over time. Manage allocates resources to respond to identified risks: updating controls, triggering incident recovery, communicating with stakeholders.

The framework treats AI systems as living systems. Point-in-time testing at deployment is explicitly positioned as insufficient. Controls must adapt as risks evolve. Monitoring signals — performance metrics, drift detection, policy violations — are expected to feed back into governance reviews, creating a continuous loop rather than a gate-and-forget model.

Where it stops:

The NIST AI RMF does not architecturally distinguish between pre-deployment approval and post-deployment evidence as separate systems. It treats them as integrated components of a single risk management lifecycle. Approval gates feed policy constraints into operational systems. Runtime signals feed back into governance reviews. The framework assumes this integration happens, but does not prescribe how.

This is a strength philosophically — it avoids the trap of building siloed approval and monitoring systems. But it is a weakness practically, because most organizations implement approval workflows in one system (a GRC platform, a change management tool, a review board) and runtime monitoring in another (an observability platform, a model registry, an operations dashboard). The integration the framework assumes often does not exist in practice. NIST describes the feedback loop; it does not provide the plumbing.

NIST AI 600-1: The Generative AI Profile

NIST AI 600-1, published in July 2024, is a profile — an implementation guide that adapts the broader AI RMF specifically for generative AI systems. It was developed by the Public Working Group on Generative AI and focuses on four considerations: governance, content provenance, pre-deployment testing, and incident disclosure.

What it adds for pre-deployment:

The profile addresses risks that the base RMF handles generically but that generative AI makes acute. It requires organizations to document roles, responsibilities, and communication lines specific to generative AI risk. It requires pre-deployment validation criteria — not just "does the model work?" but "does it meet content safety, provenance, and integrity requirements?" It addresses RAG (retrieval-augmented generation) as both a risk mitigation technique and a governance concern, recognizing that retrieval mechanisms introduce new risk vectors around data quality and source poisoning.

What it adds for runtime:

AI 600-1 explicitly recommends content logging, metadata annotation, watermarking, and source attribution where technically feasible. It calls for consolidated activity logging that captures data interactions including third-party exchanges, with user IDs, timestamps, and metadata. The Govern 1.5 subcategory requires ongoing monitoring and periodic review of the risk management process itself, with frequencies and responsible roles defined.

For prompt-related risks, the profile addresses input validation, output safety monitoring, and content filtering — guardrails at both input and output boundaries. It does not provide a detailed "prompt governance" framework, but it establishes that prompt-related risks must be assessed, monitored, and mitigated as part of the overall risk profile.

Where it stops:

AI 600-1 operates at the guidance level. It recommends logging but does not prescribe a schema. It recommends provenance tracking but does not define retention requirements. It recommends monitoring but does not specify what constitutes sufficient runtime evidence for a regulatory inquiry. Organizations following AI 600-1 faithfully will have better generative AI governance than those that do not — but two faithful implementations can still differ dramatically in their ability to produce case-level evidence of a specific runtime decision.

EU AI Act: The Regulatory Enforcement Approach

The EU AI Act, which entered into force in August 2024 with phased enforcement through 2027, is the most prescriptive framework of the four on runtime evidence requirements. It is also the only one with enforcement teeth — non-compliance for high-risk AI systems can result in fines up to 3 percent of annual worldwide turnover or EUR 15 million, whichever is higher.

Where it is strong on pre-deployment approval:

The Act classifies AI systems by risk tier. High-risk systems (Annex III) must meet extensive requirements before deployment: conformity assessments, technical documentation, quality management systems, and registration in the EU database. Providers must establish risk management systems that operate throughout the AI system's lifecycle.

For deployers, Article 26 requires assigning competent personnel for human oversight, verifying that input data is relevant, and maintaining documented evidence of compliance measures.

Where it is strong on runtime evidence:

This is where the EU AI Act goes further than any other framework.

Article 12 mandates that high-risk AI systems must technically allow for automatic recording of events (logs) over the system's lifetime. These logs must be tamper-resistant and maintained for a period appropriate to the intended purpose — at minimum six months, unless EU or member state law specifies otherwise.

Logs must capture events relevant to identifying when the system may present a risk, facilitating post-market monitoring, and detecting anomalies, dysfunctions, or unexpected performance.

Article 26 requires deployers to monitor system operation based on provider instructions, detect anomalies and dysfunctions, and assess performance continuously. If a deployer suspects the system presents a risk, they must inform the provider, importer, distributor, and relevant market surveillance authorities without undue delay. Serious incidents must be reported immediately.

For biometric identification systems, logging requirements are even more specific: usage periods, reference databases, input data characteristics, identities of individuals verifying results, and annual reports to surveillance authorities.

Where it stops:

The EU AI Act mandates system-level logging and monitoring, but its requirements are oriented around the system as a whole rather than individual case-level decisions. Article 12 requires that logs capture events that help identify risks and support monitoring — but it does not explicitly require that each individual decision or recommendation be traceable to a specific case record with full context.

This means an organization can be technically compliant with Article 12 by maintaining detailed system-level event logs — model inputs, outputs, performance metrics, anomaly flags — without necessarily preserving the operational context of each decision: who reviewed it, what actions were available, what was blocked, what the downstream system returned, how the case resolved.

The Act also introduces significant tension with GDPR's right to erasure. Tamper-resistant logs that must be retained for six months or longer may contain personal data that a data subject has the right to have deleted. The Act does not fully resolve this tension, leaving organizations to design retention architectures that satisfy both requirements.

The Comparison Matrix

The Gap All Four Share

Every framework requires both pre-deployment approval and post-deployment monitoring. None of them are naive about this. ISO 42001 Clause 9 explicitly requires continuous evaluation. NIST AI RMF builds a four-function feedback loop. NIST 600-1 adds generative-AI-specific logging guidance. The EU AI Act mandates tamper-resistant event logs.

But none of them prescribe how to connect the approval record to the runtime decision at the case level.

The approval record lives in the governance system — a GRC platform, a review board, a release management tool. It says: this system was approved, under this policy, by this person, with this evidence, on this date.

The runtime log lives in the operations system — an observability platform, a model registry, an application database. It says: the system received this input, produced this output, at this time.

The case record — where an operator reviewed a recommendation, an action was approved or blocked, an external system was called, a result was captured, a ticket was resolved — often lives in a third system entirely. Or it lives in no system at all, reconstructed after the fact from screenshots, chat messages, and memory.

The bridge between these three layers is an implementation problem, not a standards problem. The frameworks tell you that you need approval, monitoring, and evidence. They do not tell you how to keep them connected on a single operational record.

That is the architectural gap this series addresses.

Where Latch Fits

Latch is designed to sit at the case level — where the approved AI capability meets a live decision.

The governance-first layer (the AI registry, the policy framework, the approval workflows, the release packets) sits above Latch. Latch does not replace that layer. It does not manage model inventories, run conformity assessments, or store risk treatment documents.

What Latch does is act as the runtime control layer — the system where AI-assisted intake, policy-bounded recommendations, approval-gated execution, plugin action capture, and immutable audit trails converge on a single case record. It preserves the runtime decision record: what was recommended, what was available or blocked, what was approved or overridden, what executed, what came back, and what survived after the case closed.

The thesis is that compliance with any of these four frameworks requires both the approval control plane and the runtime control layer — and that the connection between them must be deliberate, not assumed.

Continue Reading

• Governance-First Approval Systems for AI: What They Prove, What They Miss, and Where Runtime Evidence Fills the Gap
• The Runtime Control Layer: What This Category of Software Is and Why It Exists
• What to Log When Operators Trigger External Actions
• What Auditors Need to See in a High-Risk Approval Workflow