LLM Governance Questions Regulators Ask in 2026, and the Evidence That Answers Them

Why policy documents no longer answer the question

Most regulated organizations can produce an AI policy, a risk assessment and pre-deployment documentation. Examination questions increasingly go one step further: show that the policy was applied to this interaction, this agent action, this tool call.

That is the difference between policy documentation and runtime evidence. Documentation describes intended behavior. Runtime evidence records what a control decided at the moment a request or action occurred. A control reviewed after the fact can tell you what a sample of traffic looked like. Policy enforced in the execution path produces a record for every decision it makes.

The EU AI Act illustrates why both matter. It requires a risk management system for high-risk AI systems to be established, implemented, documented and maintained. The recitals also tie deployer duties to monitoring the functioning of those systems and to record-keeping, as appropriate. Documentation is necessary. A monitoring and record-keeping duty points toward records generated by the system in operation. As of October 2026, teams should confirm directly which provisions apply to their systems and when.

Seven question categories and what a defensible answer looks like

These categories are an organizing device, not any single regulator's checklist. They are consistent with the requirement areas the EU AI Act lists for high-risk systems: risk management, documentation and record-keeping, transparency, human oversight, and robustness and cybersecurity. Map each one to the framework you are actually subject to, whether the EU AI Act, NIST AI RMF, NYDFS, NAIC or HIPAA.

• Permitted use: Question: what was this system allowed to do, and for whom? Defensible answer: a documented policy plus a record showing that policy was applied to a given request.
• Data handling: Question: what sensitive data reached the model or left it? Defensible answer: records of which data was redacted, blocked or allowed, per interaction.
• Tool and agent actions: Question: which tools could an agent call, and what did it do? Defensible answer: per-call decisions showing the action, the policy applied and the outcome.
• Human oversight: Question: who is assigned oversight, and who approved this action? Defensible answer: named people with competence, training and authority, plus a recorded approval for each escalated action.
• Code provenance: Question: where did AI-generated or AI-assisted code come from? Defensible answer: origin, licence and security context recorded for the code.
• Retention, residency and incident reconstruction: Question: can you rebuild what happened, from records stored where and for as long as required? Defensible answer: retrievable records of individual interactions, held under defined retention and residency settings.

Oversight, roles and who is asking

Human oversight is the category where documentation most often stands in for evidence. The AI Act recitals say the people assigned to implement instructions for use and human oversight should have the necessary competence, including an adequate level of AI literacy, training and authority. A policy statement that oversight exists does not meet that description. Named individuals, training records and a trail of approvals do.

Roles also shape the questions. The recitals assign specific duties to deployers, such as using high-risk systems according to instructions for use, monitoring their functioning and keeping records. Obligations for general-purpose AI models fall to providers, and those obligations have applied since 2 August 2025. Determine whether you act as a deployer, a provider or both before you build the answer set.

The contact may vary as well. The AI Act uses a two-tiered governance system. National competent authorities oversee and enforce rules for AI systems, while the AI Office governs and enforces obligations for providers of general-purpose AI models and for a subset of AI systems. The European Data Protection Supervisor also has an enforcement role. Elsewhere, NYDFS has published an industry letter on cybersecurity risks arising from AI, and NIST has published a Generative AI Profile of its AI RMF. Treat both as inputs to your question set and review them directly for the expectations that apply to you.

What runtime enforcement evidence contains

Evidence is most defensible when it is produced by the same mechanism that enforces the policy. If a separate process reconstructs events later, the record is an interpretation. If the enforcement point writes the record, it is a statement of what the control decided.

For each interaction or tool call, a usable record shows the request context, the policy that applied, and the outcome: allowed, redacted, blocked, rate limited or escalated for human approval. For escalations, it also shows who approved or declined and when. For incident reconstruction, records need to be retrievable by interaction or tool call, not only available as bulk archives.

Two design decisions deserve early attention. The first is retention and residency. The right periods and locations depend on the obligations that apply to your organization, so they should be configurable and set by compliance rather than fixed by default. The second is coverage. Evidence from the main chat application does not answer questions about agents, tool connections or coding assistants. Gaps in coverage become the first thing an examiner finds.

There is a tradeoff. Enforcing policy in the execution path puts a control in the request flow, so it must be reliable and its policy changes must be managed with the same care as any production dependency. The benefit is that the answer to "what actually happened" exists before anyone asks.

Where Trussed fits

Trussed enforces policy in the execution path across models, agents, tools, MCP servers, AI sites and coding assistants. Decisions are allow, redact, block, rate limit and escalate for human approval, applied to individual interactions and tool calls. Enforcement is at runtime, not reviewed after the fact, and it generates continuous audit-ready evidence mapped to HIPAA, NAIC, NYDFS, the EU AI Act and NIST. Trussed also records code provenance: origin, licence and security context of code.

Deployment is self-managed in the customer cloud, with configurable retention and data residency. The scope is interaction and tool-call enforcement. It does not cover model lineage or dataset provenance.

Trussed has run continuously in production in a regulated enterprise for more than 18 months at 99.95% uptime on live traffic, with 100+ models under one policy plane and 30+ GB of audit evidence generated per day. Customers span insurance, pharma, healthcare and education. Trussed holds SOC 2 Type II, HIPAA, GDPR, FERPA, ISO 27001 and NIST AI RMF credentials.