What is the difference between an AI compliance program and an AI governance program?

A compliance program produces evidence sufficient to satisfy regulators that the organization is meeting its obligations under specific named regulations. A governance program produces the architectural controls that constrain AI behavior at runtime and produce the evidence the compliance program needs. Compliance is the reporting layer. Governance is the enforcement layer. A program that has compliance without governance produces documentation but cannot answer a regulator's reconstruction request with specifics. A program that has governance without compliance can answer the request but has not mapped the evidence to the regulatory regimes that apply.

How does the August 2, 2026 deadline change what compliance officers prioritize?

The EU AI Act high-risk requirements take effect on August 2, 2026. Penalties under Article 99 reach €15 million or 3% of global annual turnover. The architectural changes Article 12 requires cannot be implemented in the application layer in the time remaining. The window favors an external enforcement layer that produces the records independent of application changes. Compliance officers should prioritize identifying high-risk AI systems under Annex III, inventorying current logging coverage, and identifying the gap between current logs and Article 19 requirements. The gap is usually substantial.

Can existing GDPR records of processing activities satisfy Article 12?

GDPR records describe what data the organization processes, for what purpose, by whom, under what legal basis, and for how long. Article 12 records describe what an AI system did with a specific request at a specific moment, including the identity of the natural person involved. The two operate at different granularities. GDPR records leave the Article 12 obligation unmet. The Article 12 records are a per-event evidence layer that GDPR never required.

What is the right retention period for AI decision records?

Article 19 sets a minimum of six months. In practice, the operational retention is the longer of six months and any other applicable record-keeping law. Financial institutions face five to ten years under existing financial regulation. Healthcare deployers face HIPAA-style retention obligations that depend on the data type. Architectures should support seven-year retention as a working upper bound, with the option to extend. The cost of long retention is small relative to the cost of being unable to produce a record when asked.

How do we audit our vendors' AI usage?

Vendor AI usage is the hardest disclosure gap to close because the deployer does not see the prompts or responses. The contractual mechanism is to require vendor-side audit records the deployer can request on demand. The architectural mechanism is to route AI traffic that the deployer originates through an enforcement layer the deployer controls, so embedded AI usage by vendors that runs on the deployer's data has an independent record. Procurement contracts should specify vendor logging granularity, retention, and on-demand disclosure. Compliance officers should review the contractual terms against the regulatory disclosure obligations they expect to face.

DeepInspect for AI Compliance Officers: Audit-Ready Evidence by Construction

The AI compliance officer's job has changed in the last twelve months. Five years ago the role meant maintaining policy documents and running annual training. Today it means producing per-decision audit records of AI activity sufficient to survive a regulatory inquiry. EU AI Act Article 12 takes effect for high-risk systems on August 2, 2026. Fannie Mae LL-2026-04 takes effect August 6. NIST's AI agent framework makes per-request action lineage a named control. The compliance officer has to produce the evidence on demand and defend it in writing to an auditor. I want to walk through the architecture that produces that evidence by construction.

The compliance officer's evidence test

The test a regulator applies is reconstruction. Given a specific request, on a specific date, against a specific resource, can you produce a record that identifies the natural person behind it, the role and authorization context in effect, the policy version that governed the decision, the data classification of the prompt, the outcome, and the timestamp. The record must be admissible. The record must be independent of the application that made the decision.

Most enterprise AI deployments today fail this test. The application logs identify the service account that called the model. They do not identify the human. They do not record the policy version. They do not classify the prompt. The reconstruction request comes back with the orchestrator's view of the chain and not much else.

What the regulations actually require

EU AI Act Article 12 and Article 19

Article 12 requires "automatic recording of events (logs) over the lifetime of the system." Article 19 gets specific about what the logs contain: period of use, input data, reference databases checked, and identification of the natural persons involved in result verification. Retention is six months minimum, often longer under other applicable law. Article 99 sets the penalty for high-risk non-compliance at €15 million or 3% of global annual turnover.

Fannie Mae LL-2026-04

LL-2026-04 requires lenders to maintain inventory of AI tools, governance of approved use, audit trails for AI-assisted decisions, and disclosure of tools, providers, and safeguards on demand. The mandate extends to subcontractors and vendors. The disclosure obligation does not pause when the AI ran inside a vendor's product.

NIST AI RMF and the three-pillar framework

The NIST AI Risk Management Framework names per-request authorization and action lineage as required controls for production AI deployments. Pillar 2 (delegated authority) and Pillar 3 (action lineage) describe the runtime evidence the deployer has to produce. Pillar 1 (verified agent identity) is upstream application architecture.

HIPAA, DORA, NIS2, ISO 42001, US state laws

The regulatory landscape converges. The vocabulary differs. The architectural requirements that satisfy each one are the same: identity-bound records, per-decision evaluation, independent audit trail. The infrastructure that satisfies Article 12 also satisfies LL-2026-04, NIST AI RMF Pillar 3, HIPAA audit requirements as applied to AI, and the disclosure obligations under Texas TRAIGA and California's AI Transparency Act.

The self-attestation problem

The compliance officer's biggest architectural risk is the self-attestation problem. When the application that generates the AI decision also writes the audit log, the record fails three production conditions: selective logging where successes are recorded and failures are missed, suppression where logs can be modified by the same system that failed, and loss on crash where the action commits but the evidence does not. The CFO does not sign the audit of financial statements they prepared. The same standard applies to AI decision logs.

I walked through this in detail in the vendor liability context. The implication for compliance officers is direct. Any audit architecture where the application writes its own AI logs fails the independence test at the regulatory layer. The auditor will note it.

What an architecture that satisfies the regulator looks like

An external enforcement layer at the AI request boundary records, for every AI decision, the identity context, the role and authorization, the policy version, the data classification, the resource, the outcome, and the timestamp. The record is signed and tamper-evident. The record is committed before the response returns to the application. The application that made the request does not have custody of the write path.

From those records, regulatory disclosure is a query. The compliance officer pulls the records for the date range, the user or agent identity, or the resource the regulator asked about. The reconstruction the regulator wants is available from the records alone. No interpretation, no inference, no missing pieces.

The vendor and embedded AI question

A material share of enterprise AI usage flows through vendor products that embed model calls under the hood. The compliance officer's environment does not see the prompts, the responses, or the data classification. The regulator holds the deployer accountable regardless of where the AI ran. Procurement contracts have to require vendor-side audit records the deployer can request on demand. In the absence of that, the disclosure gap is direct. This is the due care vs due diligence distinction the Fannie Mae mandate makes explicit.

DeepInspect

This is the architecture DeepInspect provides for the compliance officer's program. DeepInspect sits at the AI request boundary as an external enforcement layer between authenticated users and agents and any LLM. Every AI request is evaluated against per-route, per-role policies using the identity context the application supplies. Every decision produces a signed audit record bound to the natural person on whose behalf the request was made, with policy version, data classification, and outcome captured.

The compliance officer's evidence is structural to the architecture. The records are written by the proxy, signed at the layer that made the decision, and independent of the application. Disclosure to a regulator is a query against the records, not a reconstruction from incomplete application logs.