LLM Lifecycle Governance Controls: What Applies at Each Stage and Why Runtime Needs Enforcement

The lifecycle stages and how frameworks frame them

A practical LLM lifecycle has eight stages: data sourcing, model selection or training, fine-tuning, evaluation, deployment, runtime operation, monitoring and retirement. This is a practitioner framing, not framework text. NIST AI RMF uses different labels. It ties development tasks to an AI Model phase, deployment tasks to a Task and Output phase, and identifies a Monitor phase. The two vocabularies map only approximately, so treat the stage list as a working tool for assigning ownership.

Ownership is usually split. NIST names development actors such as ML experts, data scientists, developers, third-party entities, and legal and privacy governance experts. It names deployment actors such as system integrators, operators, evaluators, end users and domain experts. When a control spans several of these groups, no one owns the stage-level outcome unless accountability is documented per stage.

Three places a control can operate

It helps to classify every control by where and how it operates. Organizational process controls cover policy, roles, data governance practices and review cadence. Pre-deployment assurance covers evaluation and release checks completed before go-live. Runtime enforcement covers controls applied to each interaction and tool call while the system is live.

NIST AI RMF states that GOVERN applies to all stages, while MAP, MEASURE and MANAGE can be applied in system-specific contexts and at specific stages. For architects, the practical reading is that policy ownership is cross-stage while enforcement is stage-specific. Both NIST and the EU AI Act describe risk management as continuous. For high-risk systems, the EU AI Act requires a risk management system run as a continuous iterative process throughout the entire lifecycle, with regular systematic review and updating. A single pre-deployment review does not match that shape.

As of October 2026, the EU AI Act's governance rules and general-purpose AI obligations have applied since 2 August 2025. Following the Digital Omnibus, which entered into force on 27 July 2026, high-risk obligations apply from 2 December 2027 for stand-alone high-risk AI systems and 2 August 2028 for high-risk systems embedded in products. These obligations are stated for high-risk systems, so whether a given LLM use case falls in scope depends on its classification.

Stage-to-control mapping

Use this table as a starting point when assessing your own AI estate. Control types are editorial judgments, except where a framework requirement is named. Model provenance, lineage and dataset provenance are distinct disciplines with their own tooling, and this table does not attempt to cover them in depth.

• Data sourcing: Procedural and pre-deployment. Data governance and management practices appropriate to the intended purpose, which the EU AI Act requires for training, validation and testing data of high-risk systems. Documented sourcing approvals. Data poisoning is the threat to cross-check here.
• Model selection, training and fine-tuning: Procedural and pre-deployment. Documented selection rationale, review of third-party components, access control on training and tuning pipelines, change records.
• Evaluation: Pre-deployment. Testing against predefined metrics and probabilistic thresholds for accuracy, robustness and cybersecurity, plus adversarial input testing.
• Deployment: Procedural and pre-deployment. Release approval, configuration review, and a defined human oversight interface. This is also where the runtime policy to be enforced is specified.
• Runtime operation: Runtime. Allow, redact, block, rate limit or escalate for human approval on each interaction and tool call, with evidence generated at enforcement time.
• Monitoring and retirement: Procedural plus runtime. Continuous risk monitoring, including third-party components (NIST MANAGE 3.1), incident response, then decommissioning: revoking access and retaining evidence.

Why runtime controls belong in the execution path

A policy written upstream is a statement of intent. At runtime the questions are specific: this user, this prompt, this retrieved content, this tool call. A control that only reviews or records after the fact cannot change what happened. A control in the execution path can, because the interaction does not reach the model or the tool until the decision point has evaluated it. The available actions are allow, redact, block, rate limit, and escalate for human approval.

There are tradeoffs. The enforcement point adds latency, becomes a component whose availability matters, and requires policy design effort. Any route that lets an interaction or tool call bypass it weakens the whole arrangement. These costs are why placement deserves explicit architectural review.

The frameworks require human oversight capability and consistent accuracy, robustness and cybersecurity throughout the lifecycle, and NIST asks for regular monitoring with risk controls applied. They do not prescribe per-interaction enforcement. Treating runtime enforcement as the way to meet those expectations is an interpretation, and a reasonable one when policy must hold on individual interactions.

Trussed is one approach to this stage. It enforces policy in the execution path across models, agents, tools, MCP servers, AI sites and coding assistants, with allow, redact, block, rate limit and escalate for human approval applied to individual interactions and tool calls. It is deployed self-managed in the customer cloud, with configurable retention and data residency, and has run continuously in production at a regulated enterprise for more than 18 months. It does not cover model provenance, model lineage, dataset provenance or end-to-end tracing of agentic workflows, so those need separate controls.

Evidence produced by enforcement, not reconstructed

Evidence assembled later from application logs shows that something happened. It rarely shows which policy was evaluated and what action resulted. When enforcement produces the evidence, each record can capture the request context, the policy applied, the action taken and, where a human approved an escalation, the approver's decision alongside the request.

For a regulated enterprise, this changes the audit conversation. The auditor can test whether runtime behavior matched documented policy by examining records created at the decision point, rather than relying on a narrative. Retention period, data residency and the ability to verify records independently determine whether that evidence holds up. Trussed generates audit-ready evidence through enforcement and maps it to HIPAA, NAIC, NYDFS, the EU AI Act and NIST.