Updated June 19, 2026
TL;DR: A defensible AI audit log requires system-level runtime enforcement that generates structured, SIEM-ready evidence inside your own infrastructure. This article shows what evidence AIUC-1 assessors and procurement reviewers expect, and how runtime enforcement generates it inside your perimeter. Self-hosted deployments keep audit logs inside your perimeter and under your control. External gateways store logs outside your infrastructure, where you cannot verify integrity or control retention. That distinction determines whether your evidence package survives assessor, underwriter, and procurement scrutiny.
This article covers Scope A deployments: AI governance you run inside your own infrastructure, where audit logs are generated, retained, and queried entirely inside your own infrastructure perimeter. Scope B (external SaaS gateway) architectures are out of scope.
A policy that exists in a document but is not enforced at the system level is not a control: it is a liability waiting to surface in your next regulatory examination.
96% of CISOs now carry AI governance responsibility alongside their existing security obligations, and the gap between documented policies and system-level enforcement has become the primary source of AI audit findings.
This guide covers how to architect an examination-ready AI audit log that captures runtime enforcement decisions, shows what AIUC-1 assessors and procurement reviewers expect to see, and feeds structured logs to your existing SIEM (Security Information and Event Management), all inside your own infrastructure.
Each framework, whether a certification, regulation, or voluntary standard, demands specific, structured evidence types, and understanding what each requires before building the audit architecture prevents rework during examination.
An evidence package for an AI system is a structured collection of artifacts proving to security teams, end customers, and examiners that the system was registered, governed, and operating under documented policy at every interaction. Building that package starts with AI System registration: cataloging every model, MCP server, dataset, and external API dependency in a central inventory. Once you register your systems, you export an AIBOM in CycloneDX format as the machine-readable inventory artifact, built on the OWASP AIBOM project. CycloneDX is an open-source software bill of materials standard that supports AI component tracking. This produces a verifiable inventory without manual assembly, which is the foundation security teams, end customers, and examiners will require before reviewing interaction-level evidence.
AIUC-1 is the primary certification framework driving AI governance investment in 2025–2026, built on SOC 2's trust services model and extended for AI-specific risk. An AIUC-1 assessor reviewing your AI systems will expect to
see three categories of evidence: that every AI system is registered and inventoried, that governance policy was active and enforced at runtime during the examination period, and that a structured, queryable log record exists for each governed interaction.
Runtime enforcement satisfies all three. Every interaction processed by the control plane produces a timestamped record that captures the model or agent ID, policy ID, enforcement action, and reason code, providing the monitoring, logging, and traceability evidence AIUC-1 requires without manual assembly. The AIUC-1 crosswalks incorporate NIST AI RMF controls and OWASP Agentic Top 10 risks as technical references within the AIUC-1 control inventory, so runtime enforcement logs that satisfy AIUC-1 simultaneously address the underlying NIST and OWASP items. Compliance teams do not need to maintain separate evidence packages for each reference: the AIUC-1 crosswalk provides the bidirectional mapping. Logs are hashed at generation using SHA-256 and written to WORM (write-once-read-many) storage to satisfy the tamper-evidence requirements AIUC-1 assessors and procurement reviewers expect when validating log integrity.
For organizations with European deployment or European end users, the EU AI Act imposes two binding documentation obligations on high-risk AI systems. Article 11 requires technical documentation demonstrating that the system was designed and operates in accordance with the Act's requirements: this is satisfied by AI System registration records and the CycloneDX AIBOM export, which together constitute the machine-readable technical documentation the Act describes. Article 12 requires that high-risk AI systems automatically generate event logs throughout their
operation, enabling post-market monitoring and supervisory review. Runtime enforcement logs satisfy Article 12 directly: every governed interaction produces an event record at the moment the enforcement decision executes, with no post-hoc reconstruction.
The EU AI Act frames these as regulatory obligations, not voluntary alignment exercises. Failure to maintain Article 12-compliant logs is a compliance deficiency, not a gap in a voluntary standard. For evidence requirements specific to the Act's risk tiers, the AI Act compliance guide covers how structured evidence generation differs across prohibited, high-risk, and limited-risk classifications.
Two sector-specific regulatory regimes impose AI audit log requirements that go beyond certification and voluntary standards. Under HIPAA 45 CFR 164.312(b), covered entities and business associates must implement audit controls for all systems that create, receive, store, or transmit protected health information. AI systems that accept PHI (Protected Health Information) in prompts or return PHI in responses fall within this requirement: the audit log must capture AI inputs and outputs, and PII masking must be applied at runtime before log storage to prevent the log record itself from becoming a regulated PHI asset.
For defense-adjacent workloads, CMMC (Cybersecurity Maturity Model Certification) and ITAR (International Traffic in Arms Regulations) impose access logging requirements for systems handling CUI (Controlled Unclassified Information) and controlled technical data. These frameworks require logs to remain inside a defined perimeter under the organization's direct control. External SaaS AI gateways are not viable for CMMC or ITAR-covered workloads: the audit log must be generated and retained inside the controlled environment from the moment of deployment.
Traditional application logging captures HTTP status codes and response times. AI audit logs must capture the full interaction context, including the model's reasoning environment and policy state.
|
Element |
Traditional audit log |
AI audit log |
|---|---|---|
|
Input captured |
HTTP request body |
Prompt, retrieved documents, tool call parameters |
|
System state logged |
Endpoint, HTTP method |
Model or Agent ID, system prompt version, policy ID |
|
Output captured |
HTTP status code |
Model or Agent response, grounding verification result |
|
Decision record |
Access granted/denied |
Allow/block/rewrite with enforcement reason |
|
Agentic context |
Not applicable |
Tool call chain, agent reasoning steps, memory state |
Where logs are generated is as consequential as what they contain, and the architectural decisions made at deployment determine whether evidence is under your control when an examiner asks for it.
External gateways generate audit logs outside your perimeter, subject to the vendor's retention policies, breach posture, and contract terms. Self-hosted deployments ensure governance logic and audit logs are generated inside your own environment, a non-negotiable requirement for defense-adjacent workloads handling CUI (Controlled Unclassified Information) and ITAR (International Traffic in Arms Regulations)-controlled data, and a practical necessity for HIPAA and GDPR-covered workloads where external AI APIs are routinely non-viable. The Prediction Guard self-hosted sovereignty episode walks through this architecture in detail. Design log schemas so content fields are hashed or tokenized before storage while metadata fields such as model or agent ID, policy ID, and enforcement action remain in plaintext for query, keeping the audit log complete without turning the log into a secondary exposure vector.
An audit program requires more than isolated log files. Forwarding runtime policy events to your SIEM closes the gap between enforcement and investigation. Effective SIEM integration for audit logs requires per-tenant configuration covering destination, event filter, output schema, and delivery window. Prediction Guard formats audit log output to match the field structure Splunk, Datadog, and generic syslog collectors expect natively. Delivery is handled by your existing SIEM ingestion pipeline under your own controls, placing AI governance events inside the workflows your security operations team already uses.
The control plane generates a structured JSON log entry at the exact moment each enforcement decision execute, before the response reaches the caller, capturing timestamp, request_id, model_id, policy_id, action (ALLOW/BLOCK/REWRITE), and reason as indexed fields your SIEM can query without transformation. PII fields are masked at runtime before the policy_idactionmodel_idtimestamppolicy_id record is written, so the log remains complete and queryable without becoming a regulated data asset under HIPAA, GDPR, or CCPA. Developers connect existing OpenAI- or Anthropic-compatible SDK calls by repointing base_url to the control plane endpoint, no additional instrumentation is required for log generation to begin. The Practical AI's audits and benchmark limits episode covers AIUC-1 certification requirements and how runtime enforcement produces the evidence record assessors expect.
Individual log files and policy snapshots only become a defensible evidence package when assembled, versioned, and mapped to the specific controls each regulatory framework requires.
Package these artifacts into a single, versioned archive for each AI system under examination:
|
Framework |
Type |
Key AI audit requirement |
Control plane evidence |
|---|---|---|---|
|
AIUC-1 |
Certification |
Monitoring, logging, and traceability |
Structured audit log consumed by SIEM |
|
EU AI Act (Articles 11 and 12) |
Regulation |
Technical documentation (Art. 11) and automatic event logging (Art. 12) |
AI System registration plus runtime event log |
|
HIPAA (45 CFR 164.312(b)) |
Regulation |
Audit controls for systems touching PHI (Protected Health Information) |
Log of AI inputs and outputs with PII masking |
|
CMMC (Cybersecurity Maturity Model Certification) / ITAR |
Certification |
CUI (Controlled Unclassified Information) access logging and audit log |
Perimeter-aware logs in self-hosted environment |
|
NIST AI RMF (Manage) |
Voluntary standard |
Documented risk responses and audit log |
Runtime enforcement log with policy ID and action |
|
OWASP Top 10 for Agentic Applications |
Community guidance |
Log tool calls, agent goal state, memory access |
Structured event log per agentic interaction |
Use the AIUC-1 crosswalks to map your control inventory across NIST AI RMF, ISO/IEC 42001, EU AI Act, MITRE ATLAS, and the OWASP LLM and Agentic Top 10s simultaneously. AIUC-1 is positioned as a parallel standard built on SOC 2's trust model rather than an extension of SOC 2 controls, and it does not publish a HIPAA crosswalk. For EU AI Act-specific evidence requirements, the AI Act compliance guide covers how structured evidence generation differs across the act's risk tiers.
Translate enforcement metrics into three board-level indicators: the percentage of AI interactions governed by active AI governance policy, the count of policy violations by category, and the mean time to remediate flagged interactions. These connect the technical audit log to the business risk narrative a board can evaluate without a technical background.
Tokenize PII fields at runtime before they enter the log record. Store the tokenization mapping in a separate, access-controlled secrets store, never inside the log itself. This keeps the audit log complete and queryable while preventing the evidence package from triggering a secondary data exposure review under GDPR (General Data Protection Regulation), CCPA (California Consumer Privacy Act), or state-level privacy requirements.
Audit readiness is a continuous operational state, not a pre-examination sprint, and regular internal validation is the only way to confirm evidence chains are intact before an examiner requests them.
Run a mock examination against each production AI system quarterly. Select a random sample of interactions from the prior 90 days and verify that the full evidence chain, from the original request through the policy decision to the SIEM record, is complete and retrievable. Document any breaks as control deficiencies requiring remediation before the next AIUC-1 assessment or regulatory examination, using the scaling agentic AI governance guide to prioritize gaps by regulatory exposure.
Before any regulatory examination, verify:
The golden path for AI deployment integrates this checklist into a repeatable workflow so new AI systems enter production already audit-ready.
If the checklist reveals AI systems operating outside the governed control plane, developers redirect base_url to the control plane endpoint in their existing SDK configuration with no other code changes required. The self-hosted AI deployment episode covers integration patterns for environments where legacy applications need governed AI access without codebase rewrites.
Implementation barriers, including retention costs, legacy SIEM constraints, and gaps in ungoverned systems, are addressable with defined approaches, and each of the following sections provides a concrete resolution path.
Retain AI audit logs for a minimum of seven years to align with major financial and federal frameworks. Cold storage at Glacier Deep Archive pricing costs approximately $1.01 per TB per month in 2026, making long-term retention of high-volume AI logs economically practical. Glacier Deep Archive offers standard retrieval at approximately $20 per TB with a 12-hour SLA, and bulk retrieval at approximately $2.50 per TB with a 48-hour SLA. Expedited retrieval is not available on this tier, so build retrieval SLAs into your examination response plan accordingly.
When your audit log lives on a SaaS gateway vendor's infrastructure, three compounding risks emerge: the vendor's security posture becomes part of your attack surface, your evidence trail sits outside your perimeter control, and switching vendors requires migrating or recreating your historical evidence record. The Microsoft Copilot security risks analysis illustrates exactly how external AI architectures create evidence gaps that internal teams cannot control or remediate after the fact.
Retroactive logging for systems deployed without runtime governance is not a viable compliance strategy. Standard application logs do not contain prompt payloads, model or agent identifiers, policy state, or enforcement decisions. Bring ungoverned systems under active governance going forward and document the governance start date as the beginning of the auditable record.
As corporate AI policies evolve, maintain a versioned mapping between each policy document version and the log records generated under that version. Store policy snapshots with the same retention schedule as the logs they govern so security teams, end customers, or examiners can verify not just what the system did, but which approved policy was active at the time.
Legacy SIEMs often cannot parse deeply nested JSON without field-size errors or cardinality overflows. Flatten nested AI log fields using a processing pipeline such as Logstash or Fluentd before forwarding to the SIEM, and map complex fields like tool call chains to indexed string representations. The AI document processing episode covers schema design patterns for AI workflows that produce high log cardinality, directly applicable to parser configuration for legacy SIEM targets.
The organizations that clear AI governance reviews without remediation sprints are the ones that treated enforcement as the source of evidence from day one, not a documentation exercise performed after the fact. The audit log your security teams, end customers, and examiners see tomorrow is being written by the architecture decisions you make today. Is your evidence being generated inside your perimeter, or assembled after the fact from systems you don't control?
Book a deployment scoping call to assess how Prediction Guard's self-hosted sovereign AI control plane fits your infrastructure, security operations, and examination requirements.
Retain AI audit logs for a minimum of seven years to align with major financial and federal frameworks, with cold storage costing approximately $1.01 per TB per month at current Glacier Deep Archive pricing. Glacier Deep Archive offers standard retrieval at approximately $20 per TB (12-hour SLA) and bulk retrieval at approximately $2.50 per TB (48-hour SLA). Expedited retrieval is not available on this tier, so factor retrieval windows into your examination response planning.
No. The control plane generates structured logs inside your perimeter, which are immediately consumed and stored by your existing SIEM. Prediction Guard generates the logs and you retain them.
Yes. Registering your AI assets in the Admin Console lets you export a CycloneDX-formatted AIBOM, providing a complete, versioned inventory for third-party auditors.
Runtime enforcement means the control plane checks every agent call against governance policy before execution and produces a log as evidence that the check happened. Retrospective log analysis reviews records after interactions have already completed, meaning violations have already occurred before detection.
Prediction Guard formats audit log output to match the field structure that Splunk, Datadog, and generic syslog collectors expect natively. Your existing SIEM ingestion pipeline (HEC endpoint, Datadog agent, syslog collector) handles delivery under your own controls, with no additional middleware required.
Sovereign AI control plane: A self-hosted software system that runs inside an organization's infrastructure to secure, govern, and compose AI systems without transiting external vendor networks.
Agentic AI exposure: The security and compliance risk associated with deploying autonomous AI agents that make unmonitored outbound tool calls or model requests without governance enforcement.
Grounding verification: The process of probabilistically verifying that an AI model's output is consistent with and supported by a provided reference dataset, used as a runtime enforcement check before the response reaches the user.
System-level policy enforcement: The active interception and validation of AI inputs and outputs at the API level, ensuring governance rules are applied regardless of which SDK or framework the developer chose.
AIBOM (AI Bill of Materials): A structured inventory of all AI assets in a system, including models, datasets, MCP servers, and dependencies, exported in CycloneDX (an open-source software bill of materials standard that supports AI component tracking) format as an auditable artifact for third-party examiners.
WORM storage: Write-once-read-many storage that creates immutable log records which cannot be altered or deleted after writing, satisfying tamper-evidence requirements for SEC (Securities and Exchange Commission), FINRA (Financial Industry Regulatory Authority), and other regulatory examinations.
SIEM (Security Information and Event Management): A centralized platform that collects, analyzes, and retains security event logs from across an organization's infrastructure, enabling real-time threat detection, compliance reporting, and forensic investigation of security incidents.