LLM Governance Principles for Engineers: Writing Requirements You Can Enforce at Runtime

Why principles fail as engineering inputs

Statements such as "protect sensitive data" or "keep a human in the loop" are reasonable as organizational policy. NIST AI RMF places this kind of material in its GOVERN function, which covers organizational principles, policies and strategic priorities and is meant to inform the other functions. The EU AI Act lists seven principles, including human agency and oversight, privacy and data governance, and accountability, and says they should be translated, when possible, into the design and use of AI models.

The phrase "when possible" matters. Nothing in a principle tells an engineer which request to inspect, what counts as a violation, or what the system should do next. That interpretation has to be written down by the organization, and it has to stay traceable to the principle it came from.

The AI Act also says testing of high-risk AI systems should be carried out against prior defined metrics and probabilistic thresholds. Applied more broadly, this is a useful discipline: if you cannot state the metric or threshold, you cannot test the principle, and an untested principle cannot be enforced or evidenced.

The four-part method

Apply the same four steps to every principle. Keep one requirement per enforcement decision so that each can be tested and traced independently.

• 1. Define the principle as a testable statement: State the condition that must hold and how you will measure it. Include a pass/fail criterion or threshold, and the test set used to check it.
• 2. Scope it to an interaction or tool call: Name the specific event the rule applies to, such as a prompt to an external model or a write call to a production system. Broad scopes such as "all AI use" cannot be enforced.
• 3. Specify the enforcement action: Choose one action on failure: allow, redact, block, rate limit, or escalate for human approval. Define the fallback if an approval does not arrive.
• 4. Define the evidence record: List the fields written for every decision, including those where the action was allow. Link the record to the requirement and the originating principle.

Two worked examples, and a specificity test

Take "protect sensitive data." A requirement version reads: prompts containing government ID numbers or account numbers are redacted before reaching any externally hosted model. The scope is prompt input. The action is redact. The test is a seeded set of prompts with known identifiers, with a pass criterion of no unredacted matches against a threshold you define in advance. Where personal data is processed, the AI Act's data minimisation and data protection by design and by default give you a concrete anchor for choosing which data types to cover.

Take "keep a human in the loop." A requirement version reads: any tool call that modifies a production record is held until a named role approves it, and is denied if no approval arrives within a defined period. The scope is the tool call. The action is escalate for human approval, with block as the timeout outcome. The evidence names the requester, the approver, the decision, and the times.

To judge whether a principle is specific enough, ask five questions. Can you write a pass/fail test? Can you name the interaction or tool call? Is there exactly one action on failure? Can you say what record proves it ran? Can you name the principle it traces back to? A "no" to any of them means the statement needs more work before engineering starts.

Regulatory anchors, timelines, and where Trussed fits

Evidence design should be scoped against the obligations that actually apply to each system. Timelines are still moving. As of October 2026, the Commission's Digital Omnibus on AI proposal of 19 November 2025 would set fixed high-risk application dates of 2 December 2027 for stand-alone systems and 2 August 2028 for systems embedded in products. The European Parliament adopted its position on 26 March 2026. Because the final text may differ, check current status before committing to dates in a plan. Requirements written as testable, evidenced controls do not depend on those dates.

Trussed is one example of enforcing policy in the execution path. It enforces policy across models, agents, tools, MCP servers, AI sites and coding assistants, with the actions allow, redact, block, rate limit, and escalate for human approval, scoped to individual interactions and tool calls. Enforcement produces audit-ready evidence mapped to frameworks including the EU AI Act and NIST. It runs self-managed in the customer cloud, with configurable retention and data residency. In production, 100+ models operate under one policy plane.

The method above applies whatever you build or buy. Start with the one or two principles your auditors ask about most, write them through all four steps, and test the result before extending to the rest.