The First Five LLM Governance Policies a Regulated Enterprise Needs, and How Each Is Enforced at Runtime

What separates a written policy from an enforced one

A written policy states intent. An enforced policy is evaluated in the execution path, before a prompt reaches a model or a tool call runs, and it changes the outcome. The EU AI Act expects the risk management system for high-risk AI to be documented as written policies, procedures and instructions. That documentation matters. A document, however, does not apply itself to an individual prompt, response or tool call.

Two common substitutes fall short for the same reason. Pre-deployment review assesses a system as designed, not each interaction in production. After-the-fact log analysis can show that a violation happened, but it cannot stop one. Neither produces a decision made at the moment of the interaction.

For each of the five policies below, define the same elements: the scope (which identities, applications, models and tasks), the decision rule, the enforcement action, an owner, and the evidence produced. Also state which role the organization occupies under each law that applies. The EU AI Act, for example, sets separate obligations for deployers and for providers of general-purpose AI models. Whether a given LLM use is high-risk needs its own classification step.

Policies 1 and 2: data handling, and acceptable use and access

Policy 1, sensitive data handling, addresses regulated or confidential data leaving the organization in prompts or returning in responses. To be enforceable it must define data classes (for example personal identifiers, health information, credentials, proprietary code), the detection rules for each, the direction it applies to (prompt, response or both), and which destinations are permitted for which class. The runtime action is redact when the content can proceed safely with the sensitive value removed, block when it cannot, and allow when the destination is approved for that class. The evidence is an event recording the data class detected, the action taken, the policy version and the time, ideally without storing the sensitive value itself.

Policy 2, acceptable use and access, addresses who may use which models, AI sites and coding assistants, and for what purpose. It must name roles or identities, approved models and applications, prohibited uses, and usage limits. The runtime actions are allow, block, and rate limit. Rate limits are useful for bounding bulk extraction and runaway automation. The evidence is a decision record containing the identity, the resource requested, the rule applied and the outcome. Written acceptable use statements that no system checks are the most common gap here, so the test is whether a prohibited request is actually stopped.

Policies 3 and 4: action authorization, and human approval

Policy 3, tool and agent action authorization, matters once models can call tools, query MCP servers or change systems. NIST has proposed design tenets for agent identity that bound access to the minimum scope a task requires (least privilege) and apply separation of duties, so an agent cannot assume conflicting privileges that bypass controls. These tenets are a proposal in a NIST blog post, not a binding standard, but they translate directly into policy content. Specify which tools each agent may call, which operations (read versus write), what parameter constraints apply, and which credentials are used per agent or task rather than shared. The runtime actions are allow, block and rate limit on each tool call. The evidence is a record of the agent identity, the tool and operation requested, the decision and the rule that produced it.

Policy 4, human approval and escalation, defines when a person must decide. The same NIST tenets describe organizations setting risk thresholds and tolerances that, when reached, trigger human review, with escalation to the correct authority. The EU AI Act requires high-risk systems to be designed so people can effectively oversee them while in use, including through appropriate human-machine interface tools. An enforceable version names the thresholds (for example action type, data class or monetary or system impact), the approver role, what the reviewer sees, and the default when no one responds, which should normally be deny. The runtime action is escalate for human approval, holding the action until a decision arrives. The evidence is an approval record: the request, the approver, the decision and the timestamps.

Policy 5: evidence and retention

Policy 5 governs the records the other four produce. The EU AI Act refers to deployer duties of monitoring the functioning of AI systems and record-keeping, and it requires technical documentation to be kept up to date. As of October 2026, some rules of the Act have applied since 2 August 2025, covering governance structure, penalties and obligations for providers of general-purpose AI models. Confirm current application dates for the obligations that affect your use cases.

To be enforceable, the policy must specify the contents of a decision record (identity, resource, rule, policy version, action, timestamp), the retention period set with legal and compliance, where records reside, who may read them, and how they are protected from alteration. It should also require versioned policy history, so a reviewer can see which rule was in force when a given decision was made. Because policy decisions must be machine-evaluable to scale, the same structure makes evidence queryable by framework requirement. Retention periods and record formats vary by framework and sector, so set them against the primary text that applies to you.

The five policies at a glance

Use this summary to check that each policy has a defined action and a defined evidence artifact. A policy missing either one is still a document.

• Sensitive data handling: Action: redact or block, otherwise allow. Evidence: data class detected, action, policy version, time.
• Acceptable use and access: Action: allow, block or rate limit. Evidence: identity, resource, rule applied, outcome.
• Tool and agent action authorization: Action: allow, block or rate limit per tool call. Evidence: agent identity, tool and operation, decision, rule.
• Human approval and escalation: Action: escalate for human approval. Evidence: request, approver, decision, timestamps.
• Evidence and retention: Action: retain, protect and version records. Evidence: record schema, retention settings, policy version history.