AI Compliance Certification: What Customers Now Ask For in Procurement

AI compliance certification has moved from the "nice to have" column to the "blocker on the procurement form" column over the past two quarters. Customers in regulated industries are now asking vendors for an ISO/IEC 42001 certificate, alignment with the NIST AI Risk Management Framework, a SOC 2 report extended to cover AI processing, and per-decision audit evidence on demand. Each of those is a different artifact, produced by a different process, on a different timeline. Vendors that treat the question as a single line item discover during the security review that the customer wants four different things, and the deal slows down while the vendor figures out which one to prioritize.

I want to walk through what AI compliance certification actually means in procurement today, the order to prepare the artifacts in, and where the certifications meet the runtime evidence requirement that the regulators themselves are now asking for.

What customers actually ask for

The procurement questionnaires I see in regulated industries now group AI compliance questions into four buckets. Each bucket maps to a different certification or evidence type.

Institutional certification

The institutional certification bucket asks whether the vendor holds ISO/IEC 42001, has begun the certification process, or has aligned its AI management system with ISO/IEC 42001 without certification. Customers in financial services and healthcare increasingly distinguish between certified, in-progress, and self-attested. The certified status carries the most weight because it includes an accredited external audit. The self-attested status is the entry point most vendors start with.

Framework alignment

The framework alignment bucket asks whether the vendor aligns its AI risk management with NIST AI RMF. This is voluntary alignment, not certification. The vendor's response references the Govern, Map, Measure, and Manage functions and identifies which sub-categories the vendor implements. US federal procurement increasingly treats NIST AI RMF as a baseline expectation. The artifact the customer wants is a structured statement of alignment with cross-references to internal controls.

Trust service criteria extensions

The trust service criteria bucket asks whether the vendor's SOC 2 report covers AI-specific processing. Standard SOC 2 covers security, availability, processing integrity, confidentiality, and privacy. AI extensions cover the AI request path's controls: identity propagation, prompt classification, policy enforcement, audit-record integrity, and AI vendor management. The audit firm scopes the AI extensions during the engagement. Not all audit firms have built the AI-specific testing depth, so vendors sometimes have to switch audit firms to get the extensions.

Per-decision audit evidence

The per-decision audit evidence bucket asks whether the vendor can produce, on demand, the audit trail for a specific AI decision. This is the runtime evidence requirement that the EU AI Act Article 12 record-keeping mandate codifies and the Fannie Mae LL-2026-04 disclosure-on-demand requirement reinforces. The customer wants to know that if a regulator asks them to produce the records of a specific AI decision made on their data by the vendor's system, the vendor can produce them. Most vendors discover during the procurement review that this bucket is the one they have done the least preparation on.

The order to prepare the artifacts

A vendor that has to prepare for AI compliance procurement from scratch has a 12- to 18-month timeline if the work is sequenced well. The sequencing matters because the artifacts depend on each other.

Start with the per-decision audit evidence layer

The runtime evidence layer is the foundation. Without it, the SOC 2 extensions, the ISO/IEC 42001 audit, and the customer's per-decision request all fail. The runtime layer is also the most operationally demanding to deploy because it has to sit in the AI request path and produce records the application cannot tamper with. Vendors that start with this layer get the longest lead time on the deployment and have evidence to show the auditors and customers earlier.

Layer the AI management system on top

The AI management system that ISO/IEC 42001 certifies sits on top of the runtime evidence layer. The management system documents the policies, roles, risk assessments, and controls. The runtime layer is the operational control that produces the evidence the management system claims to enforce. The Stage 1 readiness audit examines the documentation. The Stage 2 audit examines whether the controls produce the evidence the documentation claims.

Align with NIST AI RMF in parallel

NIST AI RMF alignment is structured self-attestation, which can be drafted in parallel with the ISO/IEC 42001 work because the artifact is a statement of alignment rather than an audited report. The cross-references from NIST functions to internal controls overlap substantially with the ISO/IEC 42001 control framework, so the work feeds both customer-facing artifacts at once.

Extend SOC 2 once the runtime layer is operating

The SOC 2 extension for AI processing requires the runtime layer to have been operating for at least three months before the audit window. The extension covers the AI request path's controls and the audit-record integrity. Vendors that try to add the AI extensions to a SOC 2 audit without operational evidence from the runtime layer face an audit finding rather than an extension.

Where each certification meets the runtime evidence requirement

The certifications verify that the controls and management system exist. The runtime evidence layer produces what the controls and management system are supposed to produce.

ISO/IEC 42001 examines the AI management system. The auditor samples documentation. The runtime layer is the operational artifact the auditor confirms is in production. Without the runtime layer, the management system has no operational evidence to point at.

NIST AI RMF alignment is self-attested. The Measure function explicitly requires monitoring and measuring AI risks. The runtime layer is the system that produces the metrics. Self-attested alignment without a runtime layer fails when a customer asks the vendor to demonstrate the metrics.

SOC 2 with AI extensions examines the controls. The audit firm tests whether the controls operate as described. The runtime layer is the control. The audit firm tests whether the per-decision records exist, whether they are tamper-evident, and whether they are produced for every request.

The customer's per-decision request maps directly to the runtime layer's output. The vendor produces the record by querying the runtime audit store, applying the customer's reference identifier, and producing the signed, tamper-evident record. Without the runtime layer, the vendor cannot satisfy this request, regardless of which certifications it holds.

DeepInspect

This is the runtime evidence layer DeepInspect provides for vendors that need to satisfy AI compliance procurement requirements. DeepInspect sits at the AI request boundary as a stateless proxy between the application and any LLM. Every request is evaluated against per-route and per-role policies using the identity context the application supplies. Every decision produces a per-decision audit record containing identity, role, policy version, data classification, decision outcome, and timestamp. The record is signed and committed before the application receives the model's response.

For a vendor preparing for ISO/IEC 42001, NIST AI RMF alignment, SOC 2 with AI extensions, and customer per-decision requests, the proxy is the foundation layer that all four artifacts reference. The proxy is model-agnostic, which lets a single runtime layer cover OpenAI, Anthropic, Bedrock, Azure OpenAI, Vertex, and self-hosted endpoints under a single governance regime.