The SEC's cease-and-desist against Presto Automation isn't about bad AI. The AI existed, it was running, and what got the company in trouble was the gap between what the marketing described and what the operations logs showed — 70% of orders still required human intervention when the disclosures said the AI handled them. I've read that filing enough times to cite the case number, and the enforcement logic is identical in every AI washing action that followed it.
That logic is what AI Verification & Anti-AI-Washing Compliance is built for. Not AI QA. Not a governance dashboard. The evidence chain that connects every public AI claim to the specific system component that delivers on it, in a form that holds up when an examiner asks.
The Question That Started This
My understanding of what this problem actually requires came from a meeting with a client's legal team. We were reviewing 10-K language that described their AI system's decision-making capabilities — language that was accurate in the broad sense, meaning the AI described in it existed and generally did what the filing said.
The GC, partway through, asked what we'd point the SEC to if they questioned those AI capability claims. Not "do we have policies" — we had those. Not "do we have governance" — there was a framework. The specific question was what document would an examiner find if they sent a CETU request, and would it map from each public AI claim to the model, data pipeline, and decision point that delivered on it.
We didn't have that document. The company had what most enterprises have: risk assessments, architecture diagrams, model cards that described the system at launch. None of those are what the SEC's Cybersecurity and Emerging Technologies Unit asks for in their first document request. What they ask for is a claim-to-system map. Every public AI claim — in the 10-K, on the website, in investor presentations — linked to the specific system component that delivers it, with operational evidence that it actually does. Their 2026 examination priorities state explicitly that examiners will "review for accuracy registrant representations regarding their AI capabilities."
That meeting is where I understood the difference between governance and substantiation.
What the AIBOM Work Actually Looked Like
I want to be concrete about this because the standard documents make it sound cleaner than it is in practice.
An AIBOM — AI Bill of Materials — is a machine-readable inventory of every component in an AI system: model versions, training data lineage, third-party dependencies, infrastructure specifications. The standards exist: SPDX 3.0 AI profile (released October 2024) covers models and datasets. CycloneDX 1.6 has ML-BOM support. The OWASP AIBOM Project has a formal working group, and tools like cdxgen can generate BOMs from existing ML pipelines. I've evaluated most of what's on the market, and the tooling works.
What the tooling doesn't solve is provenance currency. Our first AIBOM generation for a live client pipeline produced a technically correct output. The model had been retrained twice since the documentation was written, two third-party dependencies had been updated, and the provenance fields — training data sources, model lineage, chain of custody — reflected the system as it existed at launch, not as it existed the day we ran the generation. Several rounds of legal review later, we had something submittable as compliance evidence. The AIBOM at the time of filing is not the AIBOM at the time of examination, and the gap is exactly where stale documentation becomes a liability.
The governance platforms I spent time evaluating — Credo AI, IBM watsonx.governance, OneTrust, Fiddler AI — are good at what they do. Credo AI has audit-ready reporting that Forrester put at the top of their Wave. IBM watsonx.governance covers drift detection and model evaluation across both IBM and third-party models. None of them produce a claim-to-system map. None of them produce a submittable AIBOM with legal-reviewed provenance fields. They govern. That's the product. And governance is necessary — but the SEC examiner asking for the claim-to-system map is not asking for your governance dashboard.
The gap isn't between companies that have AI governance and companies that don't. It's between companies that can substantiate their AI claims on demand and companies that can't.
ISO 42001 certification — $90K-$200K+ in year one, four to nine months from scratch — tells auditors you have a process. Getting the certification is real work. It doesn't produce the AIBOM. It doesn't produce the claim-to-system map. Those have to be built in parallel.
The Connection I Didn't See Coming
When I started building the substantiation infrastructure, my mental model was capability claims: the 10-K language, the investor presentation, the product marketing. What your AI system says it does.
I wasn't initially thinking about what your AI system produces — and the enforcement trajectory has made those the same problem.
EU AI Act Article 50 takes effect in August 2026. Machine-readable labeling of AI-generated content becomes a mandatory transparency obligation for operators serving EU users. I've been following the Code of Practice on AI-Generated Content Labeling, with a final version expected June 2026, because that's where the technical requirements are being finalized. The C2PA standard — Coalition for Content Provenance and Authenticity — is what implementation looks like in practice: $1.63B market in 2025, projected to reach $2.06B in 2026, already supported natively by Samsung Galaxy S25, Google Pixel 10, and at the platform layer by LinkedIn, TikTok, and Cloudflare. By the time Article 50 enforcement begins, content provenance tracking is going to be expected infrastructure, not an edge capability.
What completed the connection for me was the FTC's liability chain. When the FTC tested Workado's AI detection tool — marketed at 98% accuracy — and found 53% in real-world conditions under Operation AI Comply, the enforcement theory made explicit was that accuracy claims you repeat from a vendor's marketing sheet are your accuracy claims. The Delphia ($225K) and Global Predictions ($175K) settlements in March 2024 applied the same logic to adviser AI marketing. The liability for what your AI says it can do extends upstream and downstream from the system.
The $67.4B in global losses attributed to AI hallucinations in 2024 — enterprises averaging 2.3 significant AI-driven errors per quarter at costs between $50K and $2.1M per incident — is the carrying cost of not tracking provenance. The $14,200 per employee per year organizations report spending on hallucination mitigation, roughly 4.3 hours per week of fact-checking, is the labor cost of the same gap.
The Multi-Agency Clock I Keep Explaining
The enforcement landscape I spend the most time explaining to clients isn't the SEC. Most GCs track SEC and FTC. The state AG trajectory is what catches people unprepared.
Colorado's SB 205 takes effect June 30, 2026 — high-risk AI systems require impact assessments, annual reviews, and consumer notification, at $20,000 per violation. What I walk clients through about Texas RAIGA, in effect since January 1, 2026, is the civil investigative demand mechanism specifically: the AG can deploy it based on a single consumer complaint, and the document request arrives before your GC knows the inquiry exists. New York's framework carries $15,000 per day per violation. The 36-state bipartisan AG coalition that formed in November 2025 to oppose federal preemption of state AI laws includes AGs from both parties — this enforcement environment is not going to resolve on federal preemption grounds in the near term.
53 AI-related securities class actions through H1 2025, per Stanford Law School's Securities Class Action Clearinghouse. Median settlement: $11.5M. Average, excluding a $189M outlier: $38.4M. The Nate Inc case — $42M+ raised on fabricated AI claims, SEC and DOJ filing parallel criminal actions against the founder with exposure up to 20 years — moved the criminal liability question from theoretical to documented precedent. That's what I cite when clients ask whether the enforcement risk is real.
Where to Actually Start
What I tell clients starting this work: the claim inventory doesn't exist yet at most enterprises. Marketing, investor relations, and engineering run on separate tracks and nobody maintains a master list of every public AI claim — what automation percentage was stated in the earnings call, what accuracy rate was claimed in the press release, what decision influence was described in the 10-K.
Build that inventory first. Build it across every channel, not just SEC filings. The operational validation against the highest-exposure claims follows, then the AIBOM generation for the systems those claims describe, then continuous monitoring so the documentation stays current through model updates and retraining cycles. The claim-to-system map accurate in Q1 can be invalidated by a model update in Q3. What we built at Veriprajna — https://veriprajna.com/solutions/ai-verification-anti-ai-washing — is the architecture for keeping that map current: claim inventory, AIBOM generation, operational validation, and continuous monitoring. That's the continuous monitoring discipline the Presto case makes obvious in hindsight: not just documenting the system at launch, but keeping that documentation current with what the system actually does.
The question I keep returning to after reading new enforcement actions is at what point the distance between a public AI claim and its operational reality crosses from defensible to exposed. There's no published threshold. Presto was at 70%. Nate was at essentially 100%. The claim-to-system map and the operational validation record are what give you the argument — and they're what give you the early warning when a model update has opened a gap that the filing didn't anticipate.