Vendor AI Asset Inventory as a Pre-Procurement Security Requirement

Before any AI vendor gets anywhere near a signature, a buyer needs to know what that vendor is actually running: which models, which agents, which plugins, which sub-processors sit inside the product. Skip that step, and every security decision that follows rests on a picture that's missing pieces. Vendor AI asset inventory needs to happen before the contract is signed, ahead of the audit stage. It's the thing that has to happen first, or the rest of due diligence doesn't mean much.

The old playbook doesn't hold up anymore. Traditional vendor security questionnaires were built for a world of code, packages, containers, and release pipelines: things you could see, count, and check once because they didn't change much between releases. AI doesn't work that way. Model files, training data, prompts, agents, vector databases, and third-party AI services are all in scope now, and they shift constantly, often with no software release to flag the change.

That creates a real gap. A vendor can add AI features to its product without disclosing them clearly, which means a buyer can run a full, good-faith review and still end up accepting risks nobody ever pointed out. According to the GLACIS vendor diligence guide, more than 66% of B2B buyers require SOC 2 certification before signing with a SaaS vendor, yet even SOC 2-certified AI vendors routinely lack transparency around model behavior, training data provenance, and bias mitigation, which is exactly where AI-specific risk tends to concentrate. SOC 2 tells a buyer the vendor's operational controls are sound. It says nothing about what the model does when it fails, what's actually in the training data, or whether some fourth-party model provider is quietly processing enterprise data behind the scenes.

So the question buyers need to be asking has changed. The question now runs deeper than "what does this vendor do with our data." It's which AI components live inside their product stack, and who actually controls them. Answering that requires a name for every asset first, which raises an obvious follow-up: what actually happens when procurement skips that step and moves straight to the questionnaire?

What happens when procurement skips the inventory step

The scale of the disclosure gap is larger than most buyers assume. Research from May 2026 found that 63.6% of vendors failed to disclose additional AI subprocessors, leaving most buyers with no real idea what AI is running inside the software they've procured. That's a majority. It's the majority.

And the consequences of that gap appear in breach data, not projections. Verizon's 2025 report found third-party involvement in breaches doubled year over year, reaching 30%, which puts vendors and software supply chains squarely in the primary attack path rather than some edge case worth a footnote. IBM's Cost of a Data Breach Report had already found shadow AI behind 20% of enterprise breaches. Secureframe's data shows supply chain attacks accounted for 47% of total affected individuals in the first half of 2025, with third-party vendor compromise averaging $4.91 million per incident.

Insufficient visibility is the root cause: it produces the gaps documented below. Optro's AI Oversight Gap research found 73% of organizations lack full visibility into their vendors' AI supply chains, with 53% reporting only partial visibility into how their own employees use AI and 21% reporting limited visibility at best. Picture what that looks like in practice: in May 2026, a malicious Hugging Face repository impersonating an official OpenAI release climbed to the platform's number-one trending spot before anyone flagged it. That's precisely the kind of supply chain path a pre-procurement inventory requirement exists to catch.

Then there's the risk that a fourth party is involved, which traditional questionnaires almost never surface. A SaaS provider can route customer data through a third-party LLM the buyer never contracted with, never even heard of, and the standard due diligence process won't catch it. IBM research found that 97% of organizations that suffered an AI-related security incident lacked basic AI access controls. None of this is hypothetical. Every figure above is a documented outcome.

What a vendor AI asset inventory contains

An AI bill of materials, or AIBOM, gives buyers visibility: it is a documented inventory of the datasets, models, and dependencies that make up an AI system, laid out so the supply chain behind it stops being a black box.

What goes into it? Start with the model layer: name, version, architecture, supplier, license, plus checksums on the model weights so a team can actually verify whether a model was trained on data that's been tampered with. From there, training data lineage matters just as much: where the data came from, its licensing status, and whether the vendor used it for fine-tuning. Dataset provenance is what decides copyright exposure, discrimination liability, and privacy risk down the line, and the GLACIS guide notes this is exactly the field vendors most often leave blank in their disclosures.

Inference dependencies round out the technical layer: API gateways, vector databases, retrieval-augmented generation corpora, and any sub-processor, defined as any foundation model API or outside AI service the vendor calls on to serve the buyer. Agents, plugins, and tool permissions need tracking too, along with where each asset actually runs and which team or provider owns it. Beyond that, a good inventory flags the security-relevant details directly: vulnerable packages, exposed secrets, unsafe model artifacts, third-party components caught before they ever reach production.

This is precise about what it is and is not. An AIBOM is a starting point for a security assessment. It's the prerequisite that makes a security assessment possible in the first place, since nobody can assess an asset that's never been named. NIST requires organizations to maintain an inventory of their AI systems with a named individual or team responsible for keeping it current, the AI equivalent of a CMDB.

The two AIBOM formats that have reached procurement maturity

Back in 2024, procurement teams that tried requiring an AIBOM in a contract ran into a real chicken-and-egg problem: there was no standard format to actually write into the contract language. That problem is solved now, and two formats have emerged as the practical options.

CycloneDX ML-BOM v1.7, maintained by OWASP, is the format built for engineering teams. The OWASP AIBOM Generator can output CycloneDX directly from Hugging Face model metadata, which makes it a natural fit for teams wiring AIBOM generation straight into their CI/CD pipelines.

SPDX 3.0's AI Profile takes a different angle. Its lineage traces back to ISO/IEC 5962, which gives it real weight in regulatory and legal contexts, and it lines up with the NIST AI Risk Management Framework. Legal and compliance teams drafting contractual deliverables tend to reach for SPDX; engineering teams building automation tend to reach for CycloneDX. Neither is the wrong choice; it depends on what the document needs to do.

Provenance verification is what makes an AIBOM trustworthy rather than just self-reported. CoSAI's November 2025 paper, "Building Trust in AI Supply Chains: Why Model Signing Is Critical for Enterprise Security," established Sigstore-backed model signing as the standard provenance mechanism now appearing in vendor RFPs. Checksum verification and signed model artifacts are what turn an AIBOM into something auditable, rather than a document a vendor filled out and handed over on trust.

Standards bodies are converging on this too. CISA published draft SBOM Minimum Elements in August 2025, applying general minimum elements across all software including AI, though it deferred AI-specific elements to later guidance. That later guidance arrived in May 2026, when cybersecurity agencies from every G7 member state plus the EU published joint guidance defining seven clusters of potential elements for AI SBOMs. International alignment is moving fast on this front.

The regulatory environment that is converting inventory from good practice to legal requirement

The EU AI Act is the clearest example of inventory moving from best practice to legal obligation. Article 11 codifies a technical documentation requirement for high-risk AI systems, with the specific fields laid out in Annex IV. Those fields map closely onto what an AIBOM already contains: the model, its data, its training process, its known limitations. Auditors are going to ask for exactly this. Transparency and documentation obligations for general-purpose AI models have applied since August 2, 2025, and under the Digital Omnibus agreement reached in May 2026 and formally adopted by the European Parliament on June 16, 2026, and the Council on June 29, 2026, the timeline now runs to December 2, 2027, for high-risk Annex III stand-alone systems and August 2, 2028, for Annex I product-embedded systems. Providers without something AIBOM-shaped already built will need to produce one, or they'll fail conformity assessment for high-risk Annex III use cases like employment screening, credit scoring, law enforcement tools, and critical infrastructure.

The US federal government is building its own version of the same requirement. OMB M-24-18 pushes that further into contracts themselves: transparency, incident reporting, data management, and alignment with M-24-10 now have to appear in agency contracts with AI vendors. A GAO audit reviewed 13 AI acquisitions across four agencies and found six recurring problem categories, covering requirements definition, pricing opacity, IP rights, testing, timelines, and access to subject-matter experts, against roughly $1.7 billion in federal AI funding. GSA's draft clause GSAR 552.239-7001 would go further still, imposing disclosure, data-rights, and risk-documentation requirements on any AI contractor across the federal schedule. And NIST's concept note on an AI RMF Profile on Trustworthy AI in Critical Infrastructure is guiding critical infrastructure operators toward specific risk management practices when they engage AI-enabled capabilities.

States are moving in parallel. California's Executive Order N-5-26, signed March 30, 2026, directs state agencies to submit recommendations within 120 days for a certification framework covering AI vendors seeking state contracts. California's SB 53, the Transparency in Frontier AI Act, took effect January 1, 2026, and applies to developers training models above a set compute threshold, requiring safety-incident reporting and catastrophic-risk assessments, with civil penalties up to $1 million per violation. Any organization not asking AI vendors for compliance documentation during onboarding is working from an incomplete risk picture. Colorado's Automated Decision-Making Technology Act, effective January 1, 2027, replaces the state's original AI Act and regulates ADMT used in consequential decisions like employment, dropping the earlier "high-risk AI system" classification. New York City's Local Law 144 requires bias audits and public disclosure for automated employment decision tools, and Illinois now requires disclosure whenever AI plays a role in employment decisions.

Financial services regulators are landing on the same conclusion from a different direction. Fannie Mae's LL-2026-04 requires lenders to maintain an inventory of AI used across origination and servicing, including AI used by subcontractors and vendors, and an AIBOM is the natural format for that inventory to take. Treasury's Financial Services AI Risk Management Framework, released February 19, 2026, built on NIST's structure in partnership with the Cyber Risk Institute, lays out 230 control objectives across the AI lifecycle, with a section dedicated specifically to third-party risk. Look across all of it, and the pattern holds: regulators across jurisdictions and sectors, working independently, are converging on the same requirement, a documented, structured inventory of AI assets. The AIBOM is turning into a baseline expectation buyers require of a vendor. It's turning into the document regulators will ask for directly. Under OMB M-24-10, issued in March 2024, agencies must designate Chief AI Officers, maintain AI use case inventories, and implement AI RMF-aligned risk management.

The questionnaire frameworks that operationalize inventory requirements in vendor selection

Once a buyer has an inventory in hand, the next question is how to score it, and a handful of frameworks have emerged in the past year to do exactly that. AI-CAIQ v1.0.2, released October 16, 2025, extends the long-standing CAIQ framework into a self-assessment and validation tool built specifically for AI systems, covering governance, security, privacy, and operational resilience. That release marked a real shift: AI procurement diligence got its own named instrument, distinct from the generic SaaS security review.

STAR for AI, launched October 23, 2025, gives buyers a tiered structure: request Level 1 self-assessment as the floor for every AI vendor, and push tier-one vendors toward a full Level 2 audit. NIST's AI RMF 1.0, from January 2023, paired with the Generative AI Profile (NIST AI 600-1) from July 2024, lays out more than 200 actions specific to LLM and generative AI risk, and current best practice for 2026 starts with a posture assessment that inventories every AI system across production, development, and pilot stages, third-party tools included. ISO 42001's Annex A.10 requires organizations to build a real process for identifying AI suppliers, put responsibilities in writing, and bake AI-specific considerations into supplier selection and contract terms. FAIR-AIR, from the FAIR Institute, adds the quantitative loss-exposure angle that CFOs and procurement legal teams tend to find persuasive, and it pairs naturally with AICM controls when scoring vendor risk.

But none of these frameworks work in isolation. Every one of them presupposes the buyer already knows which AI assets to ask about, and that's precisely what the AIBOM supplies. The two artifacts run in sequence, not side by side: inventory first, questionnaire second. Skip the sequence and the cost rises fast. Filling out these instruments manually runs 10 to 40 hours of combined effort per vendor, and a regulated buyer in healthcare or financial services can spend two to four months on the process. That's a real incentive for vendors to keep standing AIBOM documentation on hand rather than scrambling to assemble one every time a buyer asks. The CSA AI Controls Matrix (AICM) v1.0, released July 10, 2025, comprises 243 control objectives across 18 domains, with mappings to NIST AI 600-1, ISO/IEC 42001, and the EU AI Act, making it the canonical AI vendor questionnaire. The Shared Assessments SIG 2025 release offers three tiers (SIG Lite at 128 questions, SIG Core at 627 questions, and SIG Detail at 1,936 questions), spanning 21 risk domains that include governance, information protection, IT operations, and incident management.

How to sequence inventory collection as a pre-procurement gate

So where does inventory collection actually sit in the process? Not inside the security review, but before it. Inventory precedes and enables the review; without knowing what AI assets exist, the questionnaire ends up asking the wrong questions about the wrong scope entirely.

That means the trigger point has to move earlier than most procurement teams currently place it, back to the RFP stage or the first vendor conversation. Concretely, that looks like making AIBOM delivery, in CycloneDX or SPDX format, a mandatory RFP response element alongside the SOC 2 report and penetration test results buyers already ask for. And the AIBOM requirement needs to be specific about scope: model layer, training data lineage, inference dependencies, sub-processors, agents, and plugins, covering more than a summary of the vendor's primary product. Ask for less than that, and the inventory misses exactly the assets most likely to carry risk nobody's named yet.