LLM Governance Artifacts Required Before Go-Live

Artifacts that describe intent and evidence that proves behavior

Teams often treat every governance record as the same kind of thing. They are two kinds. Pre-launch artifacts state what the LLM is for, who is accountable, what it may do and what happens when it should not act alone. Runtime evidence shows what the system actually did once it was running. You cannot write evidence in advance, but you can and must define in advance what evidence will exist and how long it will be kept.

The common failure is a policy document that nothing enforces. At go-live, an auditor asks what the LLM was permitted to do and who approved it. The team can produce a PDF, but it cannot show that any given request was checked against it. A written control is defensible only when something in the execution path applies it and records the outcome.

That separation also settles sequencing. Everything in the next section must be complete and approved before launch. Runtime evidence starts accumulating on the first production request, and its usefulness depends on how well those earlier artifacts were written.

The pre-launch artifact inventory

Organized by lifecycle role, the inventory below is the minimum most regulated programs should expect to hold at launch. Each item names a purpose and the contents that make it usable by an auditor.

• Accountability and scope record: Purpose: establish who owns the system and what it is for. Minimum contents: intended purpose, in-scope and out-of-scope uses, named owners for risk, policy and operations, approvers and approval dates, and the applicability determination for any regulation that may classify the use case.
• Risk and impact assessment: Purpose: identify what could go wrong and for whom. Minimum contents: identified risks, affected parties, mitigations, significant decisions with their justification, acceptance criteria and test thresholds set before testing, test results against them, and a review cadence.
• Enforceable policy definitions: Purpose: turn acceptable use, access and data-handling rules into something a system can apply. Minimum contents: covered in the policy section below, including tool access and data handling across collection, storage, processing and disposal.
• Human escalation and approval criteria: Purpose: define when a person must decide. Minimum contents: the conditions that trigger review, who is authorized to approve, what the reviewer sees, the default if no one responds, and how decisions are recorded.
• Evidence and retention requirements: Purpose: fix in advance what will be recorded and kept. Minimum contents: events and fields to capture, retention periods set by legal and compliance, data residency, access controls on the evidence, and how it is produced for an auditor.
• Incident response plan: Purpose: make failure handling a decision made before launch. Minimum contents: what counts as an incident, severity levels, containment actions such as disabling a tool or tightening a policy, notification duties, and post-incident review feeding back into the risk assessment.

What makes a policy enforceable rather than advisory

An advisory policy says what people should do. An enforceable policy can be evaluated by a system against a specific request and produce a decision. The difference lies in how precisely the policy is written.

At minimum, an enforceable policy names the actor or application it applies to, the action or tool it governs, the data classes involved, and the conditions under which it applies. It states a deterministic outcome for each condition: allow, redact, block, rate limit or escalate for human approval. It also carries an owner, a version and an effective date, so that evidence can later be tied to the exact rule in force at the time.

Access and data-handling rules need the same treatment. Tool-access rules should list which tools and systems the LLM may call and with what permissions. Data-handling rules should cover each stage of the data lifecycle, from collection and storage through processing to disposal. Vague terms such as sensitive data or appropriate use cannot be evaluated at runtime until they are mapped to data classes and conditions.

This is where tooling matters. Trussed enforces policy in the execution path across models, agents, tools and MCP servers, applying allow, redact, block, rate limit or escalate decisions to individual interactions and tool calls. The policy is enforced at runtime, not reviewed after the fact. Whatever tooling a team uses, the test is the same: can the written rule be applied to a live request, and does the system record the result?

Regulatory anchors for the pre-launch set

Confirm applicability first. The EU AI Act requirements below concern high-risk AI systems, and whether a given LLM application is high-risk is a determination your organization has to make and record. As of October 2026, Regulation (EU) 2024/1689 is in force. Check the current consolidated text for application dates before committing to a timeline.

For high-risk systems, the regulation requires a risk management system that is established, implemented, documented and maintained. Testing must be carried out against metrics and probabilistic thresholds defined beforehand and appropriate to the intended purpose. Technical documentation must be drawn up before the system is placed on the market or put into service, and kept up to date. The recitals add that risk management is a continuous, iterative lifecycle process, that significant decisions should be justified and documented, and that transparency and human oversight measures are settled before market placement or service entry. In practice, the risk assessment is a maintained record, not a launch-day document, and acceptance criteria must be written before testing begins.

NYDFS guidance on AI-related cybersecurity risk points to third-party service provider policies and procedures as one of the most important requirements. These include due diligence before a provider accesses information systems or nonpublic information. It also expects data governance procedures covering collection, storage, processing and disposal. For an LLM that relies on an external model provider, that due diligence record belongs in the pre-launch set.

Runtime evidence and the gap it closes

Once the system is live, enforcement produces the evidence that no pre-launch document can. Each allowed, redacted, blocked, rate-limited or escalated action becomes a record tied to a policy version. That lets an auditor compare what the LLM was permitted to do with what it did, instead of relying on a description of intended controls.

Trussed produces continuous, audit-ready evidence from enforcement, mapped to HIPAA, NAIC, NYDFS, the EU AI Act and NIST. It can be deployed self-managed in the customer cloud, with configurable retention and data residency, which lets the retention decisions in your evidence artifact be implemented as written. The evidence requirements you define before launch determine whether that output answers an auditor's questions, so write them first.

The pre-launch set and runtime evidence work as a loop. Evidence from production feeds the scheduled risk review, and policy versions change when the review finds a gap. Teams that treat the artifacts as a one-time launch checklist usually find them out of date within the first review cycle.