What is the difference between an AI governance audit and a SOC 2 audit?

A SOC 2 audit examines the security, availability, processing integrity, confidentiality, and privacy controls of a service organization at the organizational level. It is a controls audit, run annually, that asks whether the organization has the right processes in place. An AI governance audit is per-decision. It asks the organization to reconstruct specific AI decisions, including who initiated each one, what data was involved, and what policy applied. SOC 2 evidence does not satisfy an AI governance audit. The two audits operate at different layers and require different evidence primitives.

How long do AI governance records need to be retained?

Article 19 of the EU AI Act sets the minimum at six months unless other Union or national law requires longer. Financial institutions in most EU jurisdictions face record-keeping obligations of five to ten years under existing financial regulation. Healthcare deployers face HIPAA-style retention obligations that depend on the data type. The practical answer for most regulated organizations is that six months is the floor and the operational retention period is much longer. Architectures should be designed to support retention of seven years as a reasonable upper bound, with the option to extend.

Can a SOC 2 report substitute for AI governance audit evidence?

SOC 2 attestation on a vendor is due diligence at the procurement boundary. It does not satisfy the operational obligation to supervise how that vendor's AI tools handle your data on an ongoing basis. The Fannie Mae mandate explicitly holds lenders liable for AI mistakes by subcontractors and vendors. Due diligence happens once. Due care happens continuously. Vendor AI tools running on your data create ongoing supervisory obligations that procurement attestations fail to discharge.

Who inside the organization should own AI governance audit readiness?

The Chief Risk Officer and the CISO own audit readiness jointly. The CRO owns the regulatory exposure and the operational risk tied to AI decisions. The CISO owns the controls and the audit-trail infrastructure that produces evidence. The General Counsel typically owns the regulatory interpretation and the disclosure decisions. Platform engineering owns the integration of the enforcement and audit layer into the AI request path. In practice, the failure mode is that no single owner exists, and the audit readiness work falls through the cracks until a regulator shows up.

What gets reviewed in an AI governance audit beyond the per-decision records?

Beyond the per-decision audit records, the audit examines the AI inventory (every system using AI, with model providers, use cases, and data classifications), the governance policy and its version history, the access controls on the AI request path, the vendor management documentation for AI-using subcontractors, the human-in-the-loop and escalation procedures, and the incident response plan for AI-related events. The per-decision records are the core evidence. The surrounding documentation is what the auditor uses to validate that the records reflect the policy the organization claims to enforce.

AI Governance Auditing: What an Auditor Actually Asks For

When a regulator opens an AI governance audit, the first questions are not about your policy document. They are about specific decisions the system made. Which model touched this customer record? Who initiated the request? What data classification applied? What policy version was in effect at the moment of the decision? Can you produce, in writing, an immutable record that shows all of the above? Most enterprise AI deployments cannot answer those questions today, because the systems that made the decisions also wrote the logs.

I want to walk through what an AI governance auditor actually asks for, where most organizations fail the test, and the architecture that survives a regulatory inquiry.

What an AI governance audit examines

An AI governance audit is a per-decision examination of how the AI system handled specific requests. It is not a review of your governance policy document. The auditor reads the policy once, then spends the rest of the engagement asking the system to reconstruct individual events.

EU AI Act Article 12 codifies this expectation. High-risk AI systems must "technically allow for the automatic recording of events (logs) over the lifetime of the system" to ensure traceability. Article 19 specifies the contents: period of use, input data, reference databases checked, and the identity of natural persons involved in result verification. Fannie Mae Lender Letter LL-2026-04, effective August 6, 2026, requires audit trails for AI-assisted mortgage decisions and disclosure on demand. The regulations converge on the same evidentiary primitive: per-decision records the deployer can produce on request.

The four sample-and-trace questions

Auditors do not read every log. They sample specific decisions and trace each one to its evidence. The standard sampling pattern produces four question shapes.

Who initiated this specific request

The auditor selects a flagged decision and asks the deployer to identify the natural person on whose behalf the AI system acted. The credential that the application used to call the model identifies the application, not the human. Without identity context attached at the request layer, the deployer either omits the natural person from the record or fabricates one from session heuristics that fail under scrutiny.

What data was in the prompt

The auditor asks for the input that the model received. The application log shows "request processed" or "completion generated." The actual prompt content is rarely captured at the application layer because logging it raises retention and privacy concerns the engineering team did not want to solve. The prompt is the input data the regulation requires.

What policy was in effect at the moment of the decision

The auditor wants to know which version of the organization's AI usage policy governed the request. Most application logs capture the request and the response. They do not capture the policy version, the role evaluation, or the classification rules that applied. The policy state lives in a different system, was likely updated several times since the decision, and cannot be reconstructed retroactively.

Can the record be modified after the fact

The auditor asks whether the record could have been changed since it was written. If the application that made the decision also writes the log, the answer is yes. The same system that failed can suppress, modify, or rotate the log. The record fails the integrity test required for admissibility.

Compliance gap

Most AI deployments fail audits on the same three architectural conditions. The gap is structural.

The self-attestation problem

When the application that generates the AI decision also writes the compliance log, the audit record has three failure modes. Selective logging: the application logs successes and misses edge-case failures. Suppression: logs can be wiped or modified by the same system that failed. Loss on crash: the application crashes after the model responds but before the log commits, so the action was taken but the evidence is gone. I walked through this in detail in the context of vendor liability. The same principle governs AI governance audits.

Identity context is missing at the request layer

The audit asks for the natural person behind each decision. Most enterprise AI deployments call model APIs using static service credentials or API keys issued to the application. The credential identifies the calling service. Without identity context propagated to the request layer, the audit record either omits the person or reconstructs them from session cookies, which auditors reject as evidence.

Vendor and embedded-AI usage is invisible

A material share of enterprise AI usage flows through SaaS tools that embed model calls under the hood. The lender's quality-control vendor uses ML to flag loan defects. The customer-service platform uses an LLM to summarize tickets. The pricing engine scores risk through a model. The deployer's environment never sees the prompt, the response, or the classification. The audit obligation applies regardless of where the AI ran.

What surviving a review actually requires

An architecture that survives an AI governance audit produces, for every AI request, a record containing a verified identity for the natural person, the role and authorization context, the data classification applied to the prompt, the policy version that governed the decision, the decision outcome, a timestamp with sufficient precision to correlate across systems, and a cryptographic signature or equivalent integrity mechanism that prevents post-hoc modification.

That record is independent of the application that made the request. It is committed before the model response returns to the application. It persists regardless of the application's runtime state.

This is the architectural pattern the regulations require. The regulations do not name the pattern. The pattern emerges from the questions auditors actually ask.

DeepInspect

This is the architecture DeepInspect provides. DeepInspect sits at the AI request boundary as a stateless proxy between the application and any LLM. Every request is evaluated against per-route and per-role policies using the identity context the application supplies. Every decision produces a per-decision audit record containing identity, role, policy version, data sensitivity, decision outcome, and timestamp. The record is signed and tamper-evident. The record is committed before the application receives the model's response, which removes the application's ability to suppress it.

For an AI governance auditor, this is the evidentiary primitive that answers all four sample-and-trace questions on demand. If you are running AI in a regulated environment and your audit readiness depends on application logs that the application controls, that readiness is incomplete.