Skip to main content
SparkSolutions

AI Risk & Security · SparkSolutions Editorial

What the FTC's AI-Washing Crackdown Means for the Software You're Buying

The FTC has spent the past two years suing companies for exaggerating what their AI actually does, and most of the recent cases involve claims made to other businesses, not consumers. That shifts the burden onto buyers to verify a vendor's AI claims before signing, not after something breaks.

By SparkSolutions Editorial · Published August 19, 2026 · 5 min read

Share

The Federal Trade Commission has been running a sustained enforcement effort against what it calls AI-washing since 2024, and the shape of it has shifted in a way most business owners have not noticed. The early cases read like consumer-protection basics — a company selling a supposed AI money-making tool that was mostly a template, a chatbot marketed as more capable than it was. The more recent cases are different. Of the last several actions the agency has brought, most involve claims made to other businesses rather than to end consumers: software sold on the promise of an AI capability that, on inspection, was thin, bolted-on, or simply not there. The FTC's own read is that AI marketing claims now require the same substantiation as any other product claim, and it is treating an unverified "AI-powered" label as a live compliance target rather than a growing pain the market will sort out on its own.

That enforcement pattern matters to a business well beyond whatever legal exposure the vendor itself is carrying. Every company buying software right now is fielding a flood of "AI-powered" pitches — added to CRMs, scheduling tools, accounting platforms, compliance software, and a dozen categories that had no AI angle two years ago. Some of that is real capability. A meaningful share of it is a thin wrapper around a general-purpose model API, a rules engine relabeled for the pitch deck, or a feature that works in the demo and falls apart on real, messy business data. The FTC's cases are a signal that this gap between claim and capability is now common enough, and consequential enough, to draw regulatory attention. A buyer who takes the marketing at face value is absorbing that gap directly.

The practical risk shows up downstream of the purchase, not at it. A business that adopts a tool marketed as doing AI-driven fraud screening, AI-verified compliance checks, or AI-assisted quality control is not just buying a feature — it is often building a process around the assumption that the feature works as described. If the underlying capability turns out to be a simple keyword filter or a static rule set with an AI label attached, the shortfall does not stay the vendor's problem. It surfaces as a missed fraud case, a compliance gap, or a bad decision made on the strength of an output the business trusted more than it should have. The vendor's marketing claim becomes the business's operational assumption, and the business is the one that answers for it when the assumption is wrong.

This is a harder problem to catch than an ordinary bad software purchase, because AI features resist the kind of specification a buyer would normally rely on. A traditional feature — generate this report, sync with that system — can be demoed precisely and verified against a written spec. "AI-powered" claims are vaguer by design, and a live demo tends to show the tool succeeding on a clean, favorable example rather than the harder cases a business will actually throw at it once it is in production. Few procurement processes have caught up to that difference; most still treat an AI feature the way they would treat any other checkbox on a vendor comparison sheet.

The fix is a short, specific set of questions asked before the contract is signed, not a general skepticism of AI vendors. Ask what the tool actually does in plain, mechanical terms — not "it uses AI to detect anomalies" but what data it looks at, what it flags, and what a false positive looks like. Ask to see it handle a case pulled from the business's own real, messy data rather than the vendor's curated demo set, and specifically ask to see it fail — a vendor confident in the tool will show a miss and explain it; one uncomfortable with the question usually has something to hide. Ask whether the "AI" is a proprietary model, a licensed third-party model, or a wrapper around a general-purpose API, since that answer affects reliability, pricing stability, and how customer data actually gets handled.

The other half of the fix belongs in the contract, not the sales call. Marketing claims that sound precise in a pitch tend to get vague fast once a lawyer is asked to put them in writing, which is itself useful information. Any specific performance or accuracy claim the vendor makes verbally or in marketing material is worth pushing into the contract as an actual representation, with a defined remedy if the tool does not perform as described. A vendor unwilling to commit language it was comfortable saying out loud is telling a buyer something about how much confidence it actually has in the claim.

None of this is a reason to treat every AI feature with suspicion, or to slow down adopting tools that genuinely work. It is a reason to extend ordinary purchasing discipline — verify the claim, test it against real conditions, put the specifics in writing — to a category of software claims that regulators have decided needed that discipline enforced from the outside. The businesses least exposed to an AI-washing surprise will not be the ones that avoided AI vendors. They will be the ones that asked the same plain, mechanical questions of an AI claim that they would already ask of any other vendor promising something specific for real money.

  • ai washing
  • vendor evaluation
  • procurement
  • ftc enforcement
  • due diligence

Keep reading

Let's discuss what's slowing your business down.

Every engagement starts with understanding your operational pain points. Talk to our team about where intelligent software and automation can deliver measurable results.