The New Compliance Ask: An AI Bill of Materials

If your commerce platform shipped a feature last quarter, an AI coding assistant almost certainly wrote part of it β Copilot, Cursor, Claude Code, or something similar. That's not news to anyone running a US D2C brand or marketplace in 2026. What's new is what happens next. When your PCI DSS assessor, your SOC 2 auditor, or a technical due-diligence team ahead of a funding round sits down with your engineering lead, they've stopped asking "do you use AI to write code?" They're asking for the paperwork.
The question changed from βifβ to βprove itβ
An industry analysis published August 7, 2026 laid out five questions auditors are now bringing into SOC 2, ISO 27001, PCI DSS, and HIPAA reviews of software vendors:
- Do you have a written AI development policy β approved tools, restricted use cases, secrets handling, review requirements?
- Can you produce an inventory of AI usage across your repositories β which tools touched which code, and were they approved?
- Can you generate an AI Bill of Materials (AIBOM) β a per-file record of which model or tool generated or modified it, and its risk classification?
- How do you detect vulnerabilities, exposed secrets, and unsafe patterns specifically in AI-generated changes?
- Can you show enforcement built into your pull requests and CI/CD pipeline β not a spreadsheet someone updates once a quarter?
None of those five questions existed as standard audit language two years ago. They exist now because auditors have data to justify asking. Gartner found in February 2026 that organizations running a real AI-governance platform were 3.4 times more likely to reach high effectiveness in their overall AI governance. Auditors have learned that "we have a policy" and "we can prove the policy held" are different answers, and only one survives a review.
Why commerce platforms feel this first
A checkout flow, a payment integration, and a customer database are exactly the systems a PCI DSS or SOC 2 auditor scrutinizes hardest β and exactly the systems most likely to have been assembled fast, under launch pressure, with heavy AI assistance. Veracode's Spring 2026 GenAI Code Security Report tested AI-generated code across four vulnerability classes and found the failure rate isn't evenly spread: models pass security review 82β86% of the time on SQL injection and cryptography, but only 13β15% of the time on cross-site scripting and log injection β two categories that sit directly inside the logging and script-integrity requirements PCI DSS v4.0.1 already made mandatory. An AIBOM doesn't just satisfy a governance checkbox; it's the only way to show an auditor exactly which files carry that risk, and that someone senior actually looked at them before launch.
The evidence gap nobody priced in
Here's the part that changes vendor selection more than the audit itself. Producing an AI Bill of Materials on demand requires three things most fast, cheap builds don't have: a written policy that predates the audit, tool-level tracking wired into the repository itself, and a human review step that's actually enforced in the pull-request pipeline β not described in a slide deck after the fact. A store built by rotating freelancers, or an offshore team optimizing purely for the lowest hourly rate, typically has none of the three. The AI usage was never inventoried because nobody was tracking it, and the review step was whatever the timeline allowed.
That's the gap MnT Future was built to close, the same audit-style discipline behind our AI Cleanup Lab work. Every project runs through senior-engineer code review by default β not as a marketing line, but because it's the only way the audit trail exists when someone eventually asks for it. When we build or harden a commerce platform, the pull-request history, the review sign-offs, and the tool-usage record are already there, because that's how the work got made in the first place.
What to do before the question gets asked
You don't need to overhaul your stack to close this gap. Start with an honest inventory: which AI tools have touched your codebase in the last twelve months, and can anyone show which files they touched. If the honest answer is "we don't know," that's the finding an auditor β or a due-diligence team β will surface first. From there, the fix is process, not a rewrite: a written AI-use policy, tool tracking wired into your CI/CD (several code-scanning platforms now generate this automatically), and a review gate that a senior engineer actually signs, every time, no exceptions.
What is an AI Bill of Materials (AIBOM)?
An AI Bill of Materials (AIBOM) is a record β usually generated automatically in CI/CD β listing every file in a codebase touched by an AI coding tool, which tool or model produced the change, and its risk classification. SOC 2, PCI DSS, and ISO 27001 auditors began requesting AIBOMs in 2026 as evidence that AI-generated code received human security review before shipping.
The bigger shift
This is a small process change with a large downstream effect: audit readiness is quietly becoming a vendor-selection filter for US commerce brands, ahead of a PCI reassessment, a SOC 2 renewal, or a funding round's technical due diligence. The agencies and in-house teams who can produce this evidence without scrambling are the ones who built the discipline in from day one. The ones who can't are going to find out during the audit β the most expensive possible time to find out.
If you're not sure what your last twelve months of commits would show an auditor, that's worth twenty minutes to check before your next review does it for you. MnT Future offers a free agent-readiness and compliance strategy session β the same standard behind the compliance built into every commerce platform we ship β for US commerce brands who'd rather have that answer before an auditor asks the question first. Request a free strategy session.
