Vendor Disclosure

The pain AI vendor disclosure is causing our customers

Buyers are demanding transparency from AI vendors. What model? What training data? What third-party components? What licenses? What vulnerabilities? Vendors who cannot answer clearly lose deals. Buyers who accept vendors without answers accept unmitigated risk. Both sides need standardized disclosure practices, and SBOM/AIBOM are the emerging standards.

What AI vendor disclosure covers

Two artifacts, each addressed in detail on its own page.

Why AI vendor disclosure matters to you

Federal contractors face SBOM requirements. Regulated industries face growing AIBOM expectations. Enterprise procurement questionnaires increasingly ask about both. Building disclosure practices now is table stakes for the AI vendor market.

What the research says about vendor disclosure

The academic literature on vendor disclosure is ahead of most corporate practice, and it is unusually blunt. Two findings are worth putting in front of any executive who thinks this is a compliance formality.

“Only 3.6% of approvals reported race/ethnicity, 99.1% provided no socioeconomic data.”

Muralidharan, Adewale, Huang et al., npj Digital Medicine (2024)

That is the gap between having AI and governing it. The second finding is the one that tends to change the room.

“it remains challenging for practitioners to identify the harmful repercussions of their own systems prior to deployment”

Raji, Smart, White, Mitchell, Gebru et al., ACM FAccT (2020)

Neither of these is a fringe position. Both come from peer-reviewed work, and both describe the condition most organisations are actually in when the question about vendor disclosure arrives from the board, the buyer, or the regulator.

How to get compliant with Vendor Disclosure: a 5-step path

This is the sequence that works, and it is not the sequence most organisations choose. They start with the framework and work backwards toward reality. Start with reality.

1. Inventory the AI in scope. List every AI system that could fall under vendor disclosure. Record what it does, what decision it influences, what data it touches, and who owns it. You cannot govern AI you cannot name, and almost every organisation we assess is running more AI than its leadership believes.
2. Determine whether you are actually in scope. Work out precisely which of your AI systems and activities vendor disclosure reaches, and write the determination down with its reasoning. Do this in writing. A documented scope determination, right or wrong, is defensible. An undocumented assumption is not.
3. Assign one accountable owner. Name a person, not a committee, with the authority to stop a deployment. Governance without someone who can say no is documentation, not control.
4. Build the evidence file. Assemble the documentation vendor disclosure expects: the scope, the risk assessment, the controls, the testing evidence, and the incident record. Assemble it before anyone asks. Reconstructing it under a regulator's deadline costs several times more and looks exactly like what it is.
5. Set a review cadence and hold it. Re-run the assessment on a schedule and after any material change to the model, the data, or the use case. Alignment decays. A control tested once is a snapshot, not a control.

Done in this order, vendor disclosure becomes tractable. Done out of order, it becomes a document nobody uses and a control nobody exercises.

Frequently asked questions about AI vendor disclosure

Are SBOM and AIBOM legally required?

SBOM is required for federal contractors under EO 14028 and derivative rules. AIBOM is emerging as a standard but not yet universally required. Contractual requirements are growing.

Where does AI vendor disclosure fit in SRJ's work?

The AI Vendor Risk Inventory™ from Volume III of The Operating Discipline for AI Library™ incorporates SBOM and AIBOM evaluation into vendor diligence.

What each area of vendor disclosure covers

The detail pages below each take one component of vendor disclosure and answer the same four questions: what it actually is, what it requires of you, why it matters commercially and legally, and what a defensible position looks like. Read the one that maps to your exposure first. The others become relevant as your AI footprint widens.

• Software Bill of Materials. What an SBOM is, what it contains, and what buyers now require in vendor contracts.
• AI Bill of Materials. What an AIBOM is, what it discloses about AI models and training data, and what buyers should require.

How to prioritise your work on vendor disclosure

Executives ask, reasonably, where to start. The sequence that works is the same one every time, and it is not the sequence most organisations choose. Start with an inventory: you cannot govern AI you cannot list, and almost every organisation we assess is using more AI than its leadership believes. Then rank by consequence, not by volume, because the tool that makes one high-stakes decision a week carries more exposure than the one that drafts a thousand emails.

Only then assign an owner. Not a committee, an owner, named, with the authority to stop a deployment. Governance without a person who can say no is documentation, not control. With those three steps done, the specific requirements of vendor disclosure become tractable, because you now know what you have, what matters, and who answers for it.

The organisations that struggle are the ones that begin with the framework and work backwards toward reality. The frameworks are the map. The inventory is the territory. Start with the territory.

Primary sources on vendor disclosure

The authoritative texts and agency pages behind this summary. We keep this page current, but where a compliance decision turns on exact wording, read the source. Anything concerning vendor disclosure that carries legal consequence should be confirmed against the enrolled text or the issuing body, not against a secondary summary, including this one.

• CISA, Software Bill of Materials