AI governance audit readiness checklist: 70+ evidence types regulators request

Updated June 19, 2026

TL;DR: Passing an AI audit requires moving from static policies to runtime enforcement that automatically generates verifiable evidence inside your infrastructure. This guide maps 70+ evidence artifacts across the EU AI Act, AIUC-1, ISO/IEC 42001, and OWASP in a comprehensive checklist organized by framework, showing which evidence types prove compliance and how a self-hosted sovereign AI control plane automates continuous generation of runtime enforcement artifacts, keeping governance logic, enforcement records, and audit logs within your own environment.

When an enterprise customer's procurement team requests AIUC-1 certification evidence before contract renewal, or an AI insurance underwriter asks for a complete, verified inventory of every AI model processing regulated data along with enforcement logs showing that your governance policies executed on every interaction, how long would it take your team to compile that evidence? These requests are already arriving. The gap between how quickly organizations deploy AI and how thoroughly they document governance is exactly what AIUC-1 assessors, underwriters, and procurement reviewers measure.

AI-specific regulatory audits are still emerging rather than ubiquitous. For most organizations today, the realistic drivers of AI governance evidence requests are AIUC-1 certification (increasingly required as part of enterprise vendor due diligence), AI insurance underwriting (where governance posture directly affects coverage terms and premiums), and enterprise procurement reviews (where a single large customer or partner can require governance attestation before contract renewal). EU AI Act notified body review is the relevant regulatory trigger for organizations with high-risk system deployments in European markets. What follows is written in that spirit, as a CISO advising a peer on what is already being requested and what is coming next.

AIUC-1 assessors, insurance underwriters, and enterprise procurement reviewers base their findings on the gap between AI deployment speed and governance maturity. This guide closes that gap by mapping the exact artifacts these parties request, organized by framework so your team can benchmark current documentation and prioritize what to build next.

Key benchmarks for AI audit preparedness

Before working through the checklist, it helps to understand what "audit-ready" actually means to an AIUC-1 assessor, an insurance underwriter, or an enterprise procurement reviewer.

Top audit priorities for AI governance

AIUC-1 assessors, AI insurance underwriters, and enterprise procurement reviewers scrutinizing AI programs consistently focus on four areas:

1. System transparency: Can you show exactly what AI systems you operate and what they do?
2. Data lineage: Can you trace how data flows into and out of every AI system?
3. Risk mitigation: Can you prove controls are active, not just documented?
4. Accountability: Can you name the individuals responsible for each AI system's behavior and compliance outcomes?

A policy document stored in a wiki satisfies none of these. AIUC-1's accountability controls require named individuals assigned to each AI system's governance outcomes, not a general description of responsibilities. EU AI Act Articles 16 and 17 impose equivalent obligations on providers of high-risk systems, requiring documented responsibility assignments and a quality management system that names who owns each compliance obligation. Article 14 adds that human oversight must be assigned to identifiable, trained individuals with the authority to intervene. When an AIUC-1 assessor or EU AI Act notified body reviews your governance evidence, they will ask for a named matrix with specific owners. It's a policy paragraph that describes accountability in the abstract does not satisfy the requirement.

Documenting AI controls for assessors and reviewers

The discipline regulators call for is control mapping: taking an abstract policy statement and translating it into a testable, documented control with an owner, an enforcement mechanism, and evidence of operation. The AIUC-1 crosswalks provide a practical tool for this work, mapping a single documented control to NIST AI RMF, ISO/IEC 42001, the EU AI Act, and other frameworks simultaneously, so your team avoids rebuilding the same mapping for different assessors and certification bodies. For a detailed walkthrough of AIUC-1 certification in practice, see Practical AI episode 346.

Continuous monitoring vs. periodic audits

The most common failure mode in AI governance is control drift: a control that passed in the last audit period no longer reflects current operational behavior. Runtime AI enforcement addresses this directly by operating while agents are executing, capturing what actually happened rather than what policies say should happen. Static documentation defines intent. Runtime enforcement provides proof.

The complete audit evidence checklist

Before the framework-specific breakdowns, scan the full checklist below. Use this as your gap assessment baseline, then read the sections that follow for implementation detail on each category.

The 70+ evidence artifacts checklist

The sections below break down each category in detail, explaining what AIUC-1 assessors and procurement reviewers look for in each artifact type and how runtime enforcement automates evidence generation.

AIUC-1 governance evidence artifacts

The following governance artifacts are required by AIUC-1 accountability controls and ISO/IEC 42001. They are also consistent with voluntary guidance in NIST AI RMF, a widely referenced enterprise governance framework, but are listed here anchored to their certifiable requirements.

Governance documentation

1. AI Governance Charter: Formal charter establishing oversight committee, scope, and authority. Aligned with AIUC-1 governance controls and ISO/IEC 42001 Section 5.
2. Risk Tolerance Thresholds: Documented risk appetite statement for AI systems, approved at board or executive level. Aligned with AIUC-1 and ISO/IEC 42001 Section 6.1 (actions to address risks and opportunities).
3. Acceptable Use Policy: AI-specific policy covering prohibited uses, data handling, and user obligations. Aligned with AIUC-1 and ISO/IEC 42001 Section 5.
4. Roles and Responsibilities Matrix: Named individuals accountable for each AI system's governance, including data stewards and risk reviewers. Aligned with AIUC-1 governance controls and EU AI Act Articles 8–15.
5. Training and Competency Records: Evidence that AI decision-makers received role-appropriate governance training. Aligned with AIUC-1 and ISO/IEC 42001 Section 7.
6. Deployment Approval Records: Sign-off documentation for each AI system approved for production. Aligned with AIUC-1 and ISO/IEC 42001 Section 8.1 (operational planning and control).
7. Board-Level AI Risk Disclosure Documentation: Records showing how AI risk is reported to board or risk committee. Aligned with AIUC-1 and ISO/IEC 42001 Section 9.3 (management review).
8. Vendor Business Associate Agreement (BAA) / Data Processing Agreement (DPA) Matrix: Contract documentation for all third-party AI vendors, with gaps flagged and remediation tracked. Aligned with AIUC-1 and EU AI Act Article 28.

Asset inventory and impact documentation

1. AI System Inventory: Complete registry of all AI systems in production, with tier classification and rationale per system. Aligned with AIUC-1 and EU AI Act Annex IV Section 1.
2. Intended Use Case Descriptions: Business context and purpose statements for each AI system. Aligned with AIUC-1 and ISO/IEC 42001 Section 4.1 (understanding the organization and its context).
3. Stakeholder Impact Assessments: Documentation of populations affected by each AI system's outputs. Aligned with AIUC-1 and EU AI Act Article 9.
4. Data Lineage and Dependency Map: Traceable record of data sources, transformations, and third-party dependencies. Aligned with AIUC-1 and EU AI Act Annex IV Section 2.
5. Model Card Documentation: Per-model documentation of capabilities, limitations, known biases, and evaluation results. Aligned with AIUC-1 and ISO/IEC 42001 Section 8.2 (AI risk assessment documentation).
6. Fairness and Bias Impact Assessments: Pre-deployment analysis of potential discriminatory outcomes across demographic groups. Aligned with AIUC-1 and EU AI Act Annex IV Section 3.
7. AI System Classification Rationale: Documented reasoning for risk tier classification, including the criteria applied. Aligned with AIUC-1 and EU AI Act Annex III classification criteria.
8. Generative AI Risk Category Overlay: Per-system documentation addressing key generative AI risk categories: confabulation, dangerous recommendations, data privacy, harmful bias, misuse scenarios, Chemical, Biological, Radiological, and Nuclear (CBRN) information exposure, human-AI configuration, degrading content, information integrity, security, environmental impact, and intellectual property. Aligned with AIUC-1 and MITRE ATLAS (covering AML.T0048 Societal Harm, AML.T0051 LLM Prompt Injection, AML.T0054 LLM Jailbreak, and AML.T0019 Publish Poisoned Datasets for CBRN and information integrity risk scenarios).
9. Vulnerability Scan Records: Records documenting AI supply chain security evaluations, including model provenance evaluation and component integrity assessments. Aligned with AIUC-1 and MITRE ATLAS (adversarial ML threat modeling, particularly AML.T0010 ML Supply Chain Compromise).

Testing, evaluation, and operational monitoring

The following testing and operational artifacts are required by AIUC-1 assessors and EU AI Act notified bodies. They are also consistent with voluntary guidance in NIST AI RMF.

1. Bias Test Results: Disaggregated evaluation metrics across demographic groups, with methodology documented. Aligned with AIUC-1 and EU AI Act Annex IV Section 3.
2. Accuracy Metrics and Performance Baselines: Benchmark results with documented testing conditions and evaluation datasets. Aligned with AIUC-1 and ISO/IEC 42001 Section 9.1 (monitoring, measurement, analysis, and evaluation).
3. Adversarial Testing and Red Team Reports: Evidence of structured adversarial evaluation, including test scenarios, testers, and findings. Aligned with AIUC-1, EU AI Act Annex IV Section 3, and MITRE ATLAS (structured adversarial evaluation covering AML.T0043 Craft Adversarial Data and AML.T0040 ML Model Inference API Access).
4. Grounding Verification Records: Evidence that AI outputs were evaluated against reference documents before delivery, including probabilistic checks for confabulation risk. Aligned with AIUC-1 and OWASP LLM09.
5. Robustness Test Results: Evaluation under erroneous inputs, adversarial inputs, and out-of-distribution queries. Aligned with AIUC-1, EU AI Act Annex IV Section 3, and MITRE ATLAS (AML.T0015 Evade ML Model and AML.T0016 Obtain Capabilities).
6. Toxicity and Harmful Content Evaluation Reports: Content safety test results covering harmful output categories and mitigation effectiveness. Aligned with AIUC-1.
7. Prompt Injection Detection Test Records: Evidence that your team tested controls against prompt injection attack patterns and confirmed effectiveness. Aligned with AIUC-1, OWASP LLM01, and MITRE ATLAS (AML.T0051 LLM Prompt Injection).
8. Model Evaluation Harness Documentation: Description of the automated evaluation infrastructure used to generate reproducible test results. Aligned with AIUC-1 and ISO/IEC 42001 Section 8.4 (AI system operation).
9. Dangerous Content and CBRN Risk Documentation: Records documenting how your team evaluated content safety controls against dangerous content and CBRN risk scenarios. Aligned with AIUC-1 and MITRE ATLAS (AML.T0048 Societal Harm and AML.T0054 LLM Jailbreak).
10. Data Privacy Risk Documentation: Documentation assessing how each AI system handles personal data, including access control configurations, output redaction evidence, and data handling obligations. Aligned with AIUC-1, EU AI Act Article 10, and ISO/IEC 42001 Section 8.3 (AI risk treatment, including data-related controls).
11. Post-Deployment Monitoring Logs: Records of system behavior in production, structured for audit consumption. Aligned with AIUC-1 and EU AI Act Article 72.
12. Incident Response Logs: Timestamped records for every AI-related incident, including detection time, mitigation actions, and root cause. Aligned with AIUC-1 and EU AI Act Article 73.
13. Override and Disregard Mechanism Records: Documentation showing how humans can intervene in AI decisions and when that intervention has occurred. Aligned with AIUC-1 and EU AI Act Article 14.
14. Change Management Records: Version-controlled records of every material change to an AI system, including rationale and approvals. Aligned with AIUC-1 and ISO/IEC 42001 Section 8.4 (operational control, change management).
15. Decommissioning Records: Evidence that retired AI systems were formally decommissioned, with data handling documentation. Aligned with AIUC-1 and ISO/IEC 42001 Section 8.4 (end-of-life operational control).
16. Runtime AI Governance Policy Enforcement Logs: Structured audit logs showing every AI interaction, the governance policy the control plane applied, and whether the control plane allowed, blocked, or rewrote the call. Aligned with AIUC-1 and ISO/IEC 42001 Section 9.1 (monitoring and measurement of AI system performance).
17. Security Information and Event Management (SIEM)-Forwarded Enforcement Event Records: Evidence that runtime policy events flow into your organization's SIEM (Splunk, Datadog, or equivalent) in real time, creating an audit log that lives inside your own infrastructure.Aligned with AIUC-1 and ISO/IEC 42001 Section 9.1 (evidence of monitoring and measurement results).

When an AIUC-1 assessor or insurance underwriter asks "prove that Policy X was enforced on interaction Y," a runtime audit log generated inside your own infrastructure answers that question directly. An AI governance policy document answers a different question entirely.

Mapping controls to EU AI Act requirements

For organizations with European exposure or operating high-risk AI systems, the EU AI Act imposes precise, lifecycle-spanning documentation requirements. Article 9 mandates that the risk management system be a continuous iterative process, not a point-in-time assessment, so evidence must reflect ongoing operation rather than a pre-deployment snapshot.

For a detailed view of how these requirements translate to continuous evidence generation, see our post on EU AI Act compliance tools.

1. AI System Registration Records: Registration documentation for every AI system in production, capturing model family, version, data sources, access modes, known issues, and human oversight roles. Aligned with EU AI Act Annex IV Section 1 and AIUC-1 inventory requirements.
2. EU High-Risk AI System Registration: Entry in the EU database for high-risk AI systems, where applicable under the Act's classification criteria.
3. Risk Classification Rationale Documentation: Written justification for how each system was evaluated against the high-risk classification criteria in Annex III.
4. System Description and Architecture (Annex IV, Sections 1-2): Documentation of how the AI system interacts with other systems, the hardware it operates on, design specifications, data requirements, and development testing procedures.
5. Monitoring and Control Records (Annex IV, Section 3): Evidence of system capabilities, performance limitations, foreseeable unintended outcomes, and the human oversight measures your organization has implemented.
6. Risk Management System Records (Annex IV, Section 5): Complete documentation of the continuous risk management system required by Article 9.
7. Standards and Conformity Documentation (Annex IV, Sections 7-8): List of harmonized standards applied with Official Journal references, plus the EU Declaration of Conformity per Article 47.
8. Post-Market Monitoring Plan (Annex IV, Section 9): Detailed plan for evaluating AI system performance after deployment, per Article 72.
9. Escalation Chain Records: Documentation recording how AI-related incidents were escalated internally, including who received notification and what organizational response was authorized. Aligned with EU AI Act Article 73 and AIUC-1.
10. Incident Reporting Records (Article 73): Documentation of serious incidents and malfunctions your organization reported to national supervisory authorities, with a causal link established and reports filed within the deadlines set in Article 73. The Act sets three timelines: 2 days for widespread or severe incidents, 10 days for fatal incidents, and 15 days for other serious incidents.
11. User Notification Records: Evidence that the system informed users they were interacting with an AI system, satisfying EU AI Act transparency obligations.
12. Training Data Summary (Article 53): For general-purpose AI models, documentation of datasets, copyright compliance, and data governance.
13. Conformity Assessment Records: Evidence that your organization completed the conformity assessment process before market placement.

Mapping OWASP vulnerabilities to audit artifacts

AIUC-1 assessors and enterprise security reviewers increasingly reference OWASP frameworks when evaluating AI governance evidence, particularly for organizations running agentic AI workflows. We sponsor the OWASP AIBOM Project because OWASP standards are becoming embedded in regulatory and procurement requirements.

OWASP LLM Top Ten evidence artifacts: LLM01-LLM10

For single-model AI applications, the OWASP LLM Top Ten maps to these artifacts:

1. Runtime Prompt Injection Block Logs: Detected injection attempts, policy triggered, and outcome per interaction.
2. PII Redaction Logs: Evidence that detection and redaction operate on every response.
3. Vendor Risk Assessment Records: Third-party model provenance and vendor security evaluation records.
4. Training Data Integrity Logs: Records validating integrity of training and fine-tuning datasets.
5. Output Validation Test Records: Evidence that the system validates outputs before downstream delivery.
6. Tool Boundary Documents: Tool call scope limitations with enforcement evidence.
7. System Prompt Protection Logs: Evidence that your team tested protection controls and confirmed they are active.
8. Embedding Robustness Test Records: Evaluation records for embedding manipulation resistance.
9. Grounding Verification Logs: Output evaluation against reference documents.
10. Rate Limiting and Consumption Records: Enforcement logs and resource monitoring evidence.

OWASP Agentic Top Ten evidence artifacts: ASI01-ASI10

The OWASP Agentic Applications Top Ten, developed with more than 100 industry experts, maps to these artifacts for organizations running agentic AI workflows:

1. Constraint Enforcement Logs: Evidence that goal definition constraints are active and the system detected and logged anomalous deviations.
2. Permission Verification Records: Tool access permissions with unauthorized call detection evidence.
3. Identity Assertion Logs: Agent identity verification at every privileged operation.
4. Dependency Integrity Records: Third-party tool verification, version pinning, and integrity check evidence.
5. Execution Boundary Records: Sandbox configuration documentation and boundary enforcement logs.
6. Memory Audit Logs: Periodic memory integrity records and cryptographic integrity evidence for stored agent memory.
7. Protocol Enforcement Logs: Evidence that the system verifies message integrity and enforces protocols across agent-to-agent communications.
8. Blast-Radius Records: Replay test results from isolated production environment clones with documented blast-radius thresholds.
9. Human Oversight Logs: Records of human oversight interactions where humans reviewed or directed agent actions.
10. Behavioral Anomaly Detection Logs: Operational constraint monitoring showing agent behavior evaluated against defined boundaries.

For a walkthrough of how agentic threats translate into operational controls, see the Practical AI episode 360.

Synchronizing audit artifacts across global frameworks

Managing 70+ evidence artifacts across five frameworks does not require 70+ separate documentation efforts. The key is identifying where a single operational control satisfies multiple framework requirements simultaneously.

The AIUC-1 crosswalks provide bidirectional mappings to AI-specific frameworks including NIST AI RMF, ISO/IEC 42001, EU AI Act, MITRE ATLAS, and the OWASP LLM and Agentic Top Ten. A runtime AI governance policy enforcement event logged inside your own infrastructure can simultaneously satisfy AIUC-1 operational monitoring requirements, EU AI Act Article 9 continuous risk management evidence, ISO/IEC 42001 Section 9.1 monitoring obligations, OWASP LLM01 prompt injection detection, and OWASP ASI01 goal hijack constraint enforcement.

Cross-framework evidence mapping

Four additional artifacts round out the cross-framework picture:

1. CycloneDX AIBOM Export: Machine-readable AI System inventory in CycloneDX ML-BOM format, satisfying asset inventory requirements across AIUC-1, ISO/IEC 42001, and EU AI Act Annex IV simultaneously.
2. AIUC-1 Cross-Framework Control Mapping Table: A documented mapping of your organization's AI controls to EU AI Act, AIUC-1, ISO/IEC 42001, MITRE ATLAS, and OWASP, reducing duplicate effort across reporting cycles.
3. Third-Party Vendor AIBOM Attestations: Machine-readable inventory documents obtained from every AI model vendor, documenting model provenance, training data sources, evaluation metrics, and license terms.
4. SOC 2 Type II Certification from AI Vendors: Evidence of independent security attestation from every third-party AI model provider with access to regulated data. For how agentic AI governance scales across frameworks at enterprise scope, see our post on scaling agentic AI governance.

The methodology for consolidating evidence across frameworks:

1. Identify the operational control (for example: runtime enforcement of every AI interaction with a structured log).
2. Map it to every framework using the AIUC-1 crosswalk tables.
3. Generate a single artifact that satisfies all mapped requirements simultaneously.
4. Forward it once to your SIEM and reference the same log entry across every framework's evidence package.

Automating your AI compliance audit preparation

The 71 artifacts in this checklist describe a documentation program that spreadsheet-based evidence collection cannot sustain. Spreadsheet tracking cannot capture runtime interactions, cannot detect control drift between audit cycles, and cannot produce SIEM-integrated enforcement records.

Automating real-time audit logs

The critical architectural distinction for audit readiness is where your governance logic runs and where your audit logs are generated. External security point solutions, including cloud-hosted AI content filters and external gateway services, process your AI interactions outside your infrastructure. That means your audit logs transit a vendor-controlled environment, creating a chain-of-custody dependency on a third party to produce and attest the record when an AIUC-1 assessor, underwriter, or procurement reviewer requests it.

A self-hosted sovereign AI control plane solves this by running governance logic, AI governance policy enforcement, and audit log generation entirely inside your own environment. We deploy the control plane inside your own infrastructure, on-premises, cloud VPC, or air-gapped, so every AI governance policy enforcement event is generated within your perimeter and consumed directly by your SIEM. For context on how enterprise AI infrastructure connects identity, orchestration, and governance under one control plane, see the Practical AI episode 358: "Rebooting Enterprise AI with MCP and Kubernetes".

For a log to be defensible, it must be timestamped at the moment of enforcement, structured for machine-readable ingestion, stored within the organization's own SIEM (not a vendor's system), and traceable to the specific AI interaction that triggered it. We generate these structured records at runtime on every model interaction as a byproduct of active AI governance policy enforcement, forwarding them natively to Splunk, Datadog, or any SIEM target via generic syslog. The control plane does not store these logs, generating them inside your environment and routing them to your SIEM is the design.

Transparent developer integration

Engineering leaders often ask whether implementing a governed control plane will require rewriting codebases or blocking development workflows. With OpenAI- and Anthropic-compatible APIs, existing code works unchanged. Security and GRC teams configure AI governance policies on the Govern page of the Admin Console. The control plane enforces those AI governance policies transparently on every request regardless of which developer wrote the call or which framework they used. Engineers ship features. Compliance teams configure evidence generation.

Defining periodic evidence review cadence

Runtime artifacts generate continuously. Others require scheduled review to stay defensible:

• Continuous (automated): Runtime AI governance policy enforcement logs, SIEM-forwarded events, prompt injection block logs, grounding verification records.
• Monthly: Incident response log review, change management record reconciliation.
• Quarterly: AI System inventory reconciliation, bias and fairness evaluation re-run, training record updates.
• Annually: Full Annex IV technical documentation review, risk tolerance threshold re-approval, governance charter review, adversarial testing exercise.

To assess whether a self-hosted sovereign AI control plane fits your infrastructure and compliance requirements, book a deployment scoping call.

FAQs

How many evidence artifacts does AIUC-1 certification or EU AI Act conformity assessment require?

AIUC-1 certification requires documented evidence across four domains: governance controls, asset inventory, testing and evaluation, and operational monitoring. The exact artifact count depends on the number of AI systems in scope and their risk classification, but organizations should plan for a substantial evidence set, with testing and operational monitoring artifacts being the most documentation-intensive categories. EU AI Act conformity assessment for high-risk systems adds Annex IV technical documentation (nine sections), Article 9 continuous risk management records, and Article 73 incident reporting records. Using the AIUC-1 crosswalk tables, a single runtime enforcement log can satisfy evidence requirements across multiple framework categories simultaneously, reducing total artifact volume.

What format must an AI Bill of Materials (AIBOM) use for regulatory submissions?

Regulators and enterprise procurement teams increasingly require the AIBOM in machine-readable CycloneDX ML-BOM format. CycloneDX is the format auditors expect for both internal pipeline generation and regulatory submissions.

Does Prediction Guard store our AI system audit logs?

No. We generate structured audit logs at runtime inside your self-hosted environment, and those logs are immediately consumed by your own SIEM system such as Splunk or Datadog. Generation, structure, and SIEM-ready formatting are what the control plane produces.

Can a standard external API gateway collect adequate AI audit evidence?

External gateways log traffic, but they sit outside your infrastructure perimeter, meaning sensitive audit logs and potentially regulated data transit a vendor-controlled environment. When an AIUC-1 assessor or insurance underwriter asks for chain-of-custody evidence that a control operated at a specific time inside your infrastructure, an external gateway creates a dependency on that vendor to produce and attest the record. A self-hosted control plane generates audit evidence inside your own environment, keeping the full evidence chain within your trust boundary.

How do we map a single AI governance control to multiple framework requirements?

Use the AIUC-1 crosswalk tables, which provide bidirectional mappings to AI-specific frameworks including NIST AI RMF, ISO/IEC 42001, EU AI Act, MITRE ATLAS, and the OWASP LLM and Agentic Top Ten. A runtime AI governance policy enforcement log, for example, can satisfy AIUC-1 operational monitoring requirements, EU AI Act Article 9 continuous risk management evidence, ISO/IEC 42001 Section 9.1 monitoring obligations, and multiple OWASP categories simultaneously when documented against the crosswalk. Adversarial testing artifacts can additionally satisfy MITRE ATLAS threat coverage documentation for the same event.

What evidence must we collect from third-party AI vendors?

At minimum, demand: a CycloneDX AIBOM documenting model provenance (item 68), model card documentation (item 13), SOC 2 Type II certification (item 71), a Data Processing Agreement with explicit data handling obligations (item 8), and adversarial testing evidence (item 20). For vendors supplying models used in adversarial or security-sensitive contexts, also request MITRE ATLAS threat coverage documentation confirming evaluation against relevant adversarial ML techniques. For high-risk EU AI Act deployments, vendors without Annex IV compliance documentation will fail conformity assessment.

Key terms glossary

Sovereign AI control plane: An internal software system deployed within an organization's own infrastructure to compose, secure, and govern AI models and tools without data leaving the trust boundary.

Runtime AI governance policy enforcement: The active interception and evaluation of AI inputs and outputs against compliance rules in real time, allowing, blocking, or rewriting calls before execution completes.

AI Bill of Materials (AIBOM): A structured, machine-readable inventory documenting the models, datasets, tools, and dependencies that constitute an AI system, which the control plane exports in CycloneDX ML-BOM format.

Control drift: The divergence between documented compliance policies and the actual operational behavior of AI systems over time, typically occurring between formal audit cycles when continuous enforcement is absent. Runtime enforcement logs (items 33–34) are the reliable detection mechanism.

Grounding verification: The process of probabilistically evaluating whether an AI system's outputs are consistent with and supported by its provided reference documents.

CycloneDX ML-BOM: An OWASP-maintained, Ecma International-standardized machine-readable format for documenting AI system components, including model architecture, training data provenance, and dependency version information.

AIUC-1: A cross-framework AI governance standard that operationalizes the NIST AI RMF and provides bidirectional crosswalk mappings to AI-specific frameworks including ISO/IEC 42001, EU AI Act, MITRE ATLAS, and the OWASP LLM and Agentic Top Ten, enabling consolidated multi-framework compliance evidence.

Business Associate Agreement (BAA): A HIPAA-required contract between a covered entity and a vendor that handles protected health information, specifying data protection obligations and liability.

Data Processing Agreement (DPA): A contract required under GDPR and similar privacy regulations that defines how a vendor processes personal data on behalf of a controller organization.

Model Context Protocol (MCP): An open protocol that standardizes how AI applications connect to external data sources and tools, enabling composable agent architectures.

Chemical, Biological, Radiological, and Nuclear (CBRN): A category of high-consequence information that AI systems must be evaluated against to ensure they do not inadvertently expose dangerous instructional content.

Security Information and Event Management (SIEM): Enterprise security infrastructure that aggregates, correlates, and analyzes log data from across an organization's systems to detect threats and support compliance audits.

Generative AI: AI systems that create new content, including text, images, code, or other outputs, based on learned patterns from training data rather than simply classifying or predicting from existing data.