AI Regulatory Compliance: Controls and Evidence That Hold Up

Article 12 of the EU AI Act requires high-risk AI systems to automatically record events over the lifetime of the system, in enough detail to reconstruct what happened. Fannie Mae's Lender Letter LL-2026-04 requires an audit trail for AI-assisted decisions in mortgage origination. Texas TRAIGA, in force since January 1, 2026, requires disclosure and record-keeping. Three regulators use different vocabularies, while the implementation starts with a record of what an AI system did and the identity that triggered it. I want to map the legal obligations to the runtime controls that produce reviewable evidence.

TL;DR

• AI regulatory compliance needs evidence of the authenticated caller, the approved model endpoint, and the policy decision for every routed request.

Regulation (EU) 2026/1744 deferred standalone Annex III obligations to December 2, 2027, while Article 50 transparency obligations have applied since August 2, 2026.

The regulatory map

The regulations arriving through 2026 and 2027 fall into three groups.

The EU AI Act. Article 50 transparency obligations apply from August 2, 2026. Regulation (EU) 2026/1744 deferred standalone Annex III high-risk obligations to December 2, 2027. The official amending regulation preserves the requirements that must eventually be evidenced. Article 12 record-keeping and the Article 99 penalties reaching 15 million euro or 3% of global turnover define the stakes.

US state laws. Texas TRAIGA took effect January 1, 2026 with civil penalties and attorney-general enforcement. The California AI Transparency Act, effective the same day, mandates disclosure for AI systems with more than one million monthly users. Colorado's revised AI Act follows on January 1, 2027. Each adds vocabulary, and each rests on the same evidence.

Sector rules. Fannie Mae LL-2026-04, effective August 6, 2026, governs AI in mortgage origination and servicing. DORA, HIPAA applied to AI, and ISO 42001 as a certifiable standard extend the same requirements across regulated deployments.

The three controls underneath the map

Read the operative text of any of these and the same three controls appear.

Identity-bound access. Every regime assumes the organization can say which identity, human or agent, initiated an AI action. Audit-trail rules and access provisions rely on that connection.

Policy evaluation per request. Transparency, human-oversight, and prohibited-use provisions all require that some rule was applied to an AI request before it executed. A policy that is not evaluated at request time governs nothing a regulator can verify.

Reconstructable records. Article 12's logging, LL-2026-04's audit trail, and the state disclosure statutes all reduce to one artifact: a record detailed enough to reconstruct a specific decision, held independently of the application that made it. This is the substrate the AI audit trail requirements by regulation map out in detail.

Evidence an AI compliance system needs

An AI compliance system has to preserve evidence at the decision point, rather than assemble a story after an incident. For each routed model request, retain the authenticated user or agent identity, the application and approved model endpoint, the policy version, the data classification, the allow or deny decision, and a correlation ID that joins the request to the application trace. A district privacy officer, mortgage reviewer, or EU conformity assessor can then test a specific decision against the rule that applied on that date.

This is where I think compliance programs waste money: a policy register and a vendor questionnaire are useful governance artifacts, yet neither proves that a policy evaluated a live request on August 25, 2026. Keep those documents, but treat request-level evidence as the control that carries the argument through a review.

Build once, satisfy the map

The practical consequence is that compliance scales better than the regulation count implies. An organization that builds identity-bound access, per-request policy evaluation, and reconstructable records at the AI request layer has built the substrate every regulation on the map asks for. What differs across regimes is the reporting format.

Anchoring the build to NIST AI RMF gives auditors a recognized structure to test against. The AI audit trail requirements by regulation explain how the shared record maps to each law's terms.

DeepInspect

DeepInspect builds the three controls in one place. It sits at the AI request boundary as a stateless proxy between authenticated users or agents and any LLM, evaluating each request against identity-bound policy before the model receives it.

Identity-bound access is structural, because the proxy binds every call to the identity that made it. Policy evaluation runs on every request, inline, before the model responds. Each decision produces a signed record with identity, role, policy version, data classification, outcome, and timestamp, committed before the application sees the response. One control layer produces the evidence Article 12, LL-2026-04, TRAIGA, and the state disclosure laws each ask for in their own words.

If you are mapping controls to a growing list of AI regulations and building a separate answer for each, start with the request evidence. Let's talk today.