Enterprise AI Governance: What the Operational Layer Actually Has to Produce

Enterprise AI governance gets framed in vendor materials as a policy program. Write the AI usage policy. Stand up an AI risk committee. Update the procurement checklist. That work is necessary. It is not the part that satisfies a regulator, an auditor, or a board director asking for evidence after an incident.

The operational layer of an enterprise AI governance program produces four artifacts that the policy layer references. The artifacts are concrete. They can be inspected. They can be produced on demand. They are also the artifacts most enterprises are currently missing.

I want to walk through each of the four, the regulatory regime that asks for it, and the architectural decisions that determine whether the artifact exists in a useful form.

Artifact 1: the AI system inventory

The first thing a regulator asks for is the list of AI systems in the deployment. Not the list of approved AI systems. The list of all AI systems actually running.

The distinction matters. Fannie Mae Lender Letter LL-2026-04, which takes effect August 6, 2026, holds lenders responsible for AI used by subcontractors and vendors. The lender's inventory must include vendor-embedded AI, not just AI the lender procured directly. The EU AI Act's Article 11 documentation obligation requires a technical file per high-risk system, which implies the inventory exists.

The operational inventory has fields most policy documents do not anticipate. Per system: the model provider, the model version, the deployment location, the data classifications the system processes, the human and agent identities authorized to call it, the policy version in effect, the audit retention period, and the responsible owner.

Standard procurement records do not produce this inventory. The procurement record names the vendor and the contract terms. It does not name the model version running in production this morning. The inventory has to be sourced from the deployment layer.

The architectural choice that makes this inventory tractable is to route AI traffic through a single enforcement layer that records every distinct model endpoint, every distinct caller, and every distinct policy version it sees. The inventory is then a query against the audit store, not a manually maintained spreadsheet.

Artifact 2: the per-decision audit record

EU AI Act Article 12 requires high-risk AI systems to automatically record events over the lifetime of the system. Article 19 specifies that the records must include the period of use, the input data, and the identification of natural persons involved.

The Article 19 phrasing maps to specific fields in the audit record. The period of use is a timestamp range. The input data is the prompt content or its hash. The identification of natural persons is the identity assertion that traveled with the request.

The audit record cannot be produced by the application that made the AI decision. The application is the system under audit. Self-attestation by the audited system fails the traceability test, which I walked through in detail in the context of Article 12 specifically.

The audit record gets produced by a decoupled enforcement layer that sits on the AI request path and writes the record before the response returns to the application. The record is signed so it is tamper-evident. The record is retained for the regulatory window, which is at least six months under Article 19 and often longer for financial services.

The audit record is also the system of record for incidents. When a board asks "what did our AI do during the outage?", the answer comes from this artifact, not from the application logs.

Artifact 3: the policy enforcement record

A governance program with policies but no enforcement evidence is policy theater. The enforcement record shows that the policy was actually evaluated against real traffic.

For each AI request, the enforcement record contains the policy version that was in effect at the time of evaluation, the identity context used as input, the classification of the prompt content, the tools or models the request was permitted to invoke, and the enforcement decision. The record links to the audit record from Artifact 2 by a shared request identifier.

The enforcement record is what answers the question "how do we know our policy is working?" A policy document that is published but never evaluated against real requests is documentation. A policy decision recorded per request is evidence.

The NIST AI RMF MEASURE function maps directly to this artifact. MEASURE-2.7 asks for processes to track and document AI system performance against benchmarks and policy. The enforcement record is the documented track.

ISO 42001's Annex A.6 controls around AI risk management and operational planning also reference this evidence layer. ISO 42001 auditors look for the record that ties stated policy to executed decisions.

Artifact 4: the incident reconstruction artifact

When an AI-related incident happens, the response team has to reconstruct what occurred. The reconstruction has three layers: what the AI was asked, what the AI returned, and what downstream actions followed.

CloudTrail and similar service-layer logs cover the downstream actions in cloud environments. They do not cover what the AI was asked or what it returned. The CVE-2026-39987 incident in May 2026, where attackers used an LLM agent as their post-exploitation tool, is the canonical illustration: the AWS-side logs showed the API calls but not the prompts that drove them.

The reconstruction artifact is built from the audit records of Artifacts 2 and 3. The team queries the audit store for the time window, filters by the affected identities and resources, and produces a reconstruction that shows the full request-response chain with policy decisions inline.

The artifact has regulatory weight. Under most US state breach notification statutes and under GDPR Article 33, the deployer must report what data was accessed and what was disclosed. The reconstruction artifact bounds the notification scope to what actually happened, not to a conservative worst-case read.

The artifact also has insurance weight. Cyber insurance carriers have started asking for prompt-and-response transcripts of LLM sessions during incident review. A deployer who cannot produce one defaults to reservation-of-rights conversations.

How the four artifacts relate to the policy layer

The policy layer specifies what should happen. The four operational artifacts demonstrate what did happen and provide the evidence that the should-have-happened was actually enforced. A governance program that has the policy without the operational artifacts cannot answer the questions that regulators, auditors, boards, and incident response teams will ask.

The relationship is structural. A regulator's inquiry continues past the policy document into the evidence. The auditor's evidence request reaches past the procurement record into operational records. The board's question after an incident reaches past the AI risk committee charter into the reconstruction artifact.

Implementation sequencing

Standing up the four artifacts in a real environment has a natural sequence.

Inventory first, because nothing else is tractable until the population of AI systems is known. The operational inventory is built by routing AI traffic through an enforcement layer that produces a real-time discovery side effect.

Per-decision audit second, because the audit record is the substrate for the next two artifacts. The decoupled enforcement layer that produces the audit record also produces the policy enforcement record as the same primitive.

Policy enforcement record third, because it requires a policy to evaluate. The policy can start narrow (a single high-risk system, a single sensitive data class) and expand. The record is produced from the first day the policy is active.

Incident reconstruction fourth, because it is the assembled view of the prior three. The reconstruction is a query, not a separate system. Standing up the prior three correctly produces the reconstruction capability as a derived artifact.

Most enterprises starting an AI governance program try to write the policy first and the operational layer after. That ordering produces a policy without enforcement evidence. The recommended ordering inverts it: build the artifact-producing layer first and write the policy against artifacts that already exist.

DeepInspect

This is what DeepInspect produces. DeepInspect is an inline enforcement layer at the AI request boundary. The four artifacts above are not features layered on top of the product. They are the literal outputs of running DeepInspect in front of any HTTP-based LLM endpoint. The AI system inventory is the set of endpoints DeepInspect sees in production. The per-decision audit record is the primary write the product produces. The policy enforcement record is a projection of the audit record by policy version. The incident reconstruction artifact is a query against the same store.

If you are starting an enterprise AI governance program and want to see what the operational layer looks like before you finalize the policy layer, book a technical deep dive at deepinspect.ai.