Who runs an AI governance audit?

Audit responsibility splits across three parties depending on the regime. Internal audit runs against ISO 42001 and the deployer's internal policy. External certification bodies run against ISO 42001 certification scope. Regulators run inquiries against EU AI Act, Fannie Mae LL-2026-04, HIPAA, and equivalent regimes. The five-category evidence set covers all three audiences from one record schema.

How often does an AI governance audit happen?

The cadence varies by regime. ISO 42001 surveillance audits are annual once certification is granted. EU AI Act conformity assessments are tied to system changes and notified-body involvement. Fannie Mae and Freddie Mac compliance reviews happen on a disclosure-on-demand basis. The deployer should plan on one annual audit cycle with on-demand inquiries between cycles.

Can SOC 2 evidence be reused for an AI governance audit?

SOC 2 evidence covers security, availability, processing integrity, confidentiality, and privacy at the service-organization level. AI governance audits ask for AI-specific evidence at the decision level. SOC 2 evidence is reusable for the underlying infrastructure and security posture. AI-specific evidence requires the additional decision-record schema described above.

What does the auditor do with the signed decision record?

The auditor reads it as the system-of-record evidence for the five-category review. The signature lets the auditor verify the record set was not modified after creation. The append-only storage path lets the auditor verify no gaps in the timeline. The structured fields let the auditor run analytic queries against the record set instead of triangulating from application logs.

What is the minimum architecture for a deployer who has not yet built this?

The minimum architecture is an inline proxy at the AI request boundary that supplies identity context, runs prompt-level classification, evaluates policy state, and commits a signed decision record per call. The deployer can stand this up in weeks rather than the months a full ISO 42001 certification program requires. The audit-survivable evidence starts accumulating from the day the proxy goes live.

AI Governance Audit: What an Auditor Asks For and How Architecture Produces It

An AI governance audit asks a specific set of questions. Which AI systems are in production. Who initiated each request. What was in the prompt. What model handled it. What data classification applied. What policy governed the decision at the moment the decision was made. Can the records be produced, signed, and read by an external party. The questions look procedural. The answers require an architecture that committed every record before the response returned to the application. Application-controlled logs collapse under those questions because the system being audited is also the system producing the audit record.

I want to walk through what an AI governance auditor asks for in 2026, where the application-controlled audit record fails, and what an architecture that survives an external review looks like.

What an AI governance auditor asks for

The 2026 audit set has converged around five categories of evidence.

The first category is system inventory. The auditor asks for a list of AI systems in production, classified by risk level, with model identification, deployer responsibility, and operational owner. EU AI Act Article 11 and Annex IV codify this inventory at the technical-documentation level. ISO 42001 clause 5 expects the same artifact from the AI management system.

The second category is identity context per AI call. The auditor asks who initiated each AI request. Static service credentials and shared API keys produce a "the application called" answer that the auditor rejects. The expected answer is the natural-person identity (or the verified agent identity) behind each call. EU AI Act Article 19 specifies this explicitly for high-risk systems.

The third category is data classification on prompt content. The auditor asks what data was in the prompt. The expected answer is a classification label applied at the request boundary, not a document-level label inferred after the fact. HIPAA, GDPR, and the EU AI Act each impose this expectation in their respective scopes.

The fourth category is policy state at decision time. The auditor asks what policy governed the decision and what version of that policy was in effect. The expected answer is a machine-readable policy reference attached to each decision record. ISO 42001 clause 8.3 and NIST AI RMF's Manage function each expect this artifact.

The fifth category is the integrity of the evidence trail. The auditor asks whether the records can be modified after creation, who controls the write path, and what cryptographic mechanism prevents post-hoc alteration. The expected answer is a tamper-evident record committed by a system independent of the application that produced the AI decision.

Where application-controlled audit logs fail

Application-controlled logs collapse under the five-category review for the same architectural reason: self-attestation.

Self-attestation means the system under audit also produces the evidence the audit relies on. In every other regulated industry, the auditor rejects this pattern. The CFO does not sign the audit of the financial statements they prepared. The hospital does not adjudicate its own malpractice review. The AI deployment that records its own decisions produces evidence the regulator treats as the equivalent of the CFO-prepared audit.

Three concrete failure modes follow.

Selective logging. The application logs successful inference and "misses" edge-case failures. The auditor finds a gap in the timeline that the application has no record of. The application owner attributes the gap to a log rotation issue. The auditor moves the finding to the unresolved column.

Suppression. The application has the database privileges to modify or delete its own logs. The records the auditor receives are the records the application chose to keep. The auditor asks for a write-path integrity attestation. The application owner has none to offer.

Loss on crash. The application crashes after the AI model responds and before the log commits. The AI action took effect. The evidence is gone. The auditor asks for the records of the actions taken during the outage window. The application owner has the response from the model logged on the model side and no decision record on the application side.

I wrote about this self-attestation gap in detail in the vendor liability context. The same gap is what an AI governance audit surfaces.

The architecture that survives an external review

An architecture that survives the AI governance audit produces records the application never had custody over.

The pattern is a decoupled proxy at the AI request boundary. The proxy receives the request, attaches identity context the application supplies, runs prompt-level classification, evaluates the policy version in effect, and commits a structured decision record before the response returns to the application. The application never holds the audit record. The application receives the model response.

The structured decision record carries the five categories the audit asks for:

The record is committed by the proxy, signed at write time, and stored on an append-only path the application cannot reach. The auditor reads this record set as the system of record for AI decisions.

How the architecture maps to the audit categories

System inventory: the proxy sits in front of every model endpoint the enterprise routes through it. The audit reads the proxy configuration as the canonical inventory.

Identity context: the application supplies identity at the request layer (NIST Pillar 1). The proxy enforces policy against that identity (Pillar 2). The audit reads the actor field on the decision record.

Data classification: the proxy runs prompt-level classification at the boundary. The classification labels travel with the decision record.

Policy state: the policy version in effect at the moment of decision is attached to the record. Policy changes are tracked separately, and each decision record links back to the version that governed it.

Evidence integrity: the decision record is signed at write time and stored on an append-only path. The application never holds the write privilege. The auditor verifies the signature against a published public key.

Why the audit is now an annual rhythm

EU AI Act high-risk system requirements take effect August 2, 2026. Lender Letter LL-2026-04 takes effect August 6, 2026. ISO 42001 certifications are already moving through certification bodies in 2026 in advance of customer pre-procurement requests. Each regime expects evidence the audit reads at the same five-category level.

The AI governance audit is converging into an annual rhythm comparable to SOC 2 Type II or ISO 27001 surveillance audits. The deployer that built the inline enforcement architecture in advance walks the auditor through the structured record set. The deployer that left application logs as the audit artifact spends the audit window reconstructing evidence that the architecture should have produced automatically.

DeepInspect

This is the architecture DeepInspect was built to produce. DeepInspect sits at the AI request boundary as an external enforcement layer, deterministic and identity-aware, independent of the application that initiated the call. Every AI request and response generates a structured per-decision audit record that is committed before the response returns to the application and signed by the proxy.

The records the AI governance auditor expects already exist. The five-category review reads against one schema. The deployer does not retrofit application logs to look like audit records. The records are produced as a property of the enforcement architecture.

If your AI governance audit calendar is set for the second half of 2026, book a demo today.