How does the schema handle the difference between EU and US data residency expectations?

The audit store is deployed in the region the deployer's data residency posture requires. An EU deployer runs the audit store in EU regions; a US deployer runs it in US regions; a regulated industry deployer runs it in the regions the regulatory regime expects. The schema does not change with the data residency. The query interface the regulator uses respects the residency: the EU regulator queries against the EU audit store, the US regulator queries against the US audit store. The deployer's compliance program documents which regulator reads which store.

Can the records be exported into other systems for analysis?

The audit store exposes a read API the deployer's analytics tooling consumes. The records export in their schema-conformant JSON form, which the deployer's BI tool, GRC platform, or SIEM ingests. The signature on each record validates after export, which lets the downstream tool preserve the integrity property. The export does not modify the record; the records in the destination system are byte-identical to the records in the audit store.

Does the record schema cover agentic AI deployments?

Yes. The identity field supports the agent identity claim alongside the delegating principal. A record produced under an agent operation carries both the agent identity and the human or service account that delegated the task. The records produced across a multi-step agent task reconcile on the task identifier, which the system field supports as part of the tenant-specific extension. The per-decision record covers each LLM call inside the agent's loop; the tool boundary records (which the agent runtime produces) reconcile on the same task identifier.

What if a regulator asks for evidence in a format the schema does not produce?

The audit store's read API produces the records in the schema-conformant JSON. The deployer's compliance team translates the records into the format the regulator's portal expects (a CSV upload, a structured form, a PDF report). The translation operates on the structured records, which preserves the integrity of the underlying evidence. The signature on the source records remains the anchor for the regulator's challenge to the translated submission.

How do the records interact with our existing SIEM and GRC stack?

The records feed the SIEM as a high-volume structured event stream that the SIEM correlates against other security events. The records feed the GRC platform as evidence the compliance team attaches to controls in the GRC's control library. The two paths operate alongside the audit store's primary read API and do not modify the records. The SIEM correlation and the GRC attachment preserve the integrity property by referencing the source records in the audit store rather than copying them into separate

AI Decision Records: The Structured Evidence Layer the Compliance Set Reads Across Regimes

AI decision records are the structured evidence layer that captures who acted, what model handled the request, what policy governed it, what data classifications applied, and what the outcome was. The 2026 regulatory set reads decision records as the primary evidence for AI system operation. EU AI Act Article 12 mandates them automatically over the lifetime of every high-risk system. NIST AI RMF Manage function expects them for incident response. ISO 42001 clause 8.3 expects them as operational control evidence. Fannie Mae LL-2026-04 expects them on disclosure-on-demand. Texas TRAIGA expects them in consequential-decision contexts. The architectural answer is one portable schema the inspection point writes per decision, which each regime reads from.

I want to walk through what the portable schema looks like, what each regime reads from it, and how the same record satisfies multiple regimes at once.

The portable decision record schema

The schema captures the inputs to the decision, the decision itself, and the integrity property that lets the regulator trust the record.

The schema is the same shape regardless of which provider the request targeted, which use case the deployment serves, or which regulatory regime the deployer operates under. Each regime reads different fields. The same record satisfies the EU AI Act reviewer, the NIST AI RMF auditor, the ISO 42001 certifier, the Fannie Mae quality-control examiner, and the state attorney general investigator without producing a separate evidence stream for each.

What EU AI Act Article 12 reads

EU AI Act Article 12 requires automatic recording of events over the system lifetime. Article 19 specifies the content: timestamps, input data, identification of natural persons, retention of at least six months. The August 2, 2026 deadline applies.

The reviewer reads the timestamp field, the identity.subject field, the request.prompt_classifications field, and the response fields. The reviewer also reads the policy fields to understand what governed the decision and the signature fields to verify the record was not tampered with.

The reviewer's archetypal question is "produce the records covering this specific subject's AI interactions over the past six months." The audit store query against identity.subject and the timestamp range returns the records. The reviewer reads them as the input data the obligation requires.

The Article 99 penalty for high-risk non-compliance reaches 15 million EUR or 3% of global annual turnover, whichever is higher. The exposure the record mitigates is in that range.

What Fannie Mae LL-2026-04 reads

Fannie Mae LL-2026-04, effective August 6, 2026 per the Cooley legal analysis, mandates a governance framework for AI and ML in mortgage origination and servicing. The lender has to inventory AI tools, maintain governance, and produce audit trails for AI-assisted decisions.

The reviewer reads the system.name field, the system.deployer field, the request.use_case field, and the policy.decision field. The reviewer correlates the record to the loan file the AI decision affected, which the deployer attaches as a tenant-specific extension to the schema.

The reviewer's archetypal question is "produce the records covering AI-assisted decisions on this loan file." The query against the tenant extension that ties the decision to the loan identifier returns the records.

The lender's exposure is liability for AI mistakes by subcontractors and vendors. The record covers the subcontractor traffic when the subcontractor's AI calls also route through the inspection point. The architectural answer for vendor AI that does not route through the inspection point is the procurement contract pattern that requires the vendor to produce its own records on demand.

What NIST AI RMF reads

NIST AI RMF Govern function expects accountability for AI use. The reviewer reads the policy fields and the system fields to understand the governance framework that produced the decision. The records feed the Govern documentation across the lifecycle.

Map function expects context understanding. The reviewer reads the request.use_case field and the system fields to understand the deployment context. The aggregate across records produces the use case inventory.

Measure function expects measurable evidence of system performance. The reviewer reads the policy.decision field, the response.response_classifications field, and the request.prompt_classifications field across records to compute the per-rule decision rates, the classification distribution, and the system-level performance metrics.

Manage function expects incident response evidence. The reviewer reads the records produced during the incident window, traces the decisions back to the policy version in effect, and reconstructs the incident.

What ISO 42001 reads

ISO 42001 clause 8.2 expects operational controls. The reviewer reads the policy fields and the inspection point's role in the system architecture documentation to verify that the operational controls exist and operate.

Clause 8.3 expects evidence on demand. The reviewer reads any record at any time, validates the signature, and confirms that the record was produced at the time it claims and against the policy version it references. The signature property is what lets the certifier accept the records as evidence.

Clause 10 expects continuous improvement evidence. The reviewer reads the policy version history alongside the records produced under each version to understand how the operational controls have evolved.

What Texas TRAIGA and the US state laws read

Texas TRAIGA took effect January 1, 2026. The law expects operators and developers of AI systems used in consequential decisions to maintain records of AI system operation. The reviewer reads the system fields, the identity fields, and the policy fields to verify that the operator's records cover the operations the law expects.

The California AI Transparency Act took effect the same day. The reviewer reads the system fields and the policy fields to verify that the disclosures the law requires were applied at the moments the operations affected the disclosure-eligible user populations.

The Colorado AI Act takes effect February 1, 2027. The records are the operational evidence the operator produces on inquiry.

How the same record satisfies multiple regimes

The schema is intentionally over-specified relative to any single regime. Each regime reads a subset. The overlap across regimes is large because the regimes converge on the same questions: who acted, what was done, what governed it, what was the outcome, when was it done, can the record be trusted.

The architectural property the convergence carries is that the deployer produces one record per decision and uses it across regimes. A US-based deployer subject to Texas TRAIGA, California AI Transparency, and SR 11-7 reads the same records the EU deployer reads for Article 12 compliance. A healthcare deployer subject to HIPAA reads the same records the financial deployer reads for SR 11-7 and Fannie Mae LL-2026-04.

The convergence does not eliminate regime-specific documentation. The EU AI Act conformity assessment, the NIST AI RMF self-assessment, the ISO 42001 audit, and the Fannie Mae self-attestation each require additional documentation beyond the per-decision records. The records are the operational evidence layer; the regime-specific documentation describes the framework around the records.

Where the schema needs deployer-specific extensions

The schema's tenant-specific extension field carries deployer-specific data the regimes expect at a specific granularity. The Fannie Mae case ties the decision to a loan identifier. The healthcare case ties the decision to a patient MRN or an encounter identifier. The financial case ties the decision to a customer or an account. The legal case ties the decision to a matter identifier.

The extensions live in a namespaced field the inspection point passes through from the application's request context. The application attaches the extension on the call, the inspection point includes it in the record, and the audit store indexes it for the deployer-specific query. The extensions do not modify the core schema.

The architectural property the extensions preserve is that the core schema remains portable across deployers, while the deployer-specific extensions carry the data that the deployer-specific regulatory reviewer needs. The compliance reviewer for Acme Financial reads the loan identifier extension. The compliance reviewer for Acme Health reads the patient MRN extension. The core fields are common.

The signature property and what it lets the regulator do

The signature on each record is the property that makes the records admissible as evidence. The signature anchors at a key the audit store holds. The corporate operator does not have direct access to the key. The records the operator produces sign under the key, and the regulator can verify the signature against the public key the audit store publishes.

The signature lets the regulator distinguish three states. A signed record that validates is evidence. A signed record that does not validate is evidence of tampering. A record without a signature is not evidence.

The records sit at the center of the evidence the deployment produces, and they are the evidence the regulatory regimes anchor against. The conformity assessment, the policy documentation, the system architecture write-up, and the training records sit alongside the per-decision records as the broader compliance package.

DeepInspect

This is what DeepInspect produces at the AI request boundary. DeepInspect writes a per-decision record on every request. The record uses the portable schema. The fields cover the inputs to the decision, the decision itself, and the integrity property the regulator trusts.

The record commits to a write path the application has no access to. The signature anchors at a key the audit store holds in the corporate KMS or HSM. The audit store retains the records for the operational retention period the deployer configured.

The deployer-specific extensions pass through from the application's request context. The inspection point includes them in the record without modification to the core schema. The compliance reviewer for each regime reads the subset of fields the regime expects.

Enforcement overhead runs under 50 milliseconds end-to-end in internal DeepInspect testing. The record commit happens in the request hot path. The proxy operates in front of any HTTP-accessible LLM endpoint, which means the same record format applies whether the caller targeted OpenAI, Anthropic, Bedrock, Azure OpenAI, Vertex, or a self-hosted model.

If your compliance program produces a separate evidence stream for each regime and the streams do not reconcile, let's talk today.