SEC AI Washing: Build Evidence Before You Make the Claim

SEC AI washing enforcement starts with a plain comparison: what the firm said about AI against what the system and its records can prove. On March 18, 2024, the Securities and Exchange Commission announced settled actions against Delphia (USA) Inc. and Global Predictions Inc. over false and misleading statements about their claimed use of artificial intelligence.

That comparison should happen before a filing or website update goes live. Check investor decks and social posts too. The evidence has to survive after the engineering team changes a model or data source. Production routes change too.

TL;DR

• Put every public AI statement in a claim register. Record its owner and approval date, then add the evidence source and review trigger.
• Require technical evidence that matches the exact wording. It must identify the system and data, then the deployment state and capability claimed.
• Give legal and communications separate sign-off duties from product and engineering. Preserve the final language and supporting record together.
• Monitor production changes because an accurate statement can be stale after a model or data source changes. A workflow change can do the same.

SEC AI washing begins with the exact claim

The SEC's March 18, 2024 enforcement announcement says the two investment advisers made false and misleading statements about purported AI use. Delphia's claims appeared across regulatory filings and its website. A press release carried them too. Global Predictions used its website and social media. The channels differed. The evidence question is the same: could the firm substantiate the representation it put in front of clients or investors?

Create one register that captures the quoted statement and public channel. Record the intended audience and publishing owner, plus the legal basis and technical owner. Add the date approved and the date it must be reviewed. Record if the statement concerns model use or proprietary capability. Add customer data and forecasts, then automation and a service delivered to clients.

I would block the phrase "proprietary AI" unless the technical owner can point to the component that makes the claim true. The adjective often arrives in a deck before the architecture exists. A compliance program should make unsupported ambition harder to publish than a precise description of the current system.

Technical substantiation must match the wording

The Delphia order states that the adviser represented that it used AI and machine learning to analyze retail clients' spending and social media data in its investment process. The order found that no such data was being used in that process. A general model inventory would have missed the defect because the disputed language connected the capability to named data inside an investment process.

For each claim, preserve a short substantiation packet. Name the production system. Record the model route. Identify the data sources actually used and the workflow stage where the capability runs. Include a dated architecture record and release identifier. Add the test result and technical owner attestation. When the claim concerns an outcome, document the method used to measure it and the limits on that measurement.

A screenshot of a chatbot window proves that somebody opened a chatbot. It cannot prove that client data trained a model or that a forecast came from AI. It also cannot show that a production investment process used the claimed capability. The AI governance audit framework provides a broader structure for testing ownership and operating evidence.

Approval needs independent functions

Product or engineering should confirm what the deployed system does. Legal should evaluate the wording under applicable securities law and other disclosure duties. Communications should ensure that an approved sentence is intact across the website and deck, as well as filing and social channels. Compliance should retain the claim and supporting packet, then schedule the next review.

The Global Predictions order found false and misleading AI claims along with other marketing violations. It also records an inability to substantiate performance claims on demand and failures involving required marketing policies and procedures. That combination shows why a review workflow needs evidence custody as well as copy approval.

Use separate sign-offs with dates and named reviewers. A technical approval should identify the release examined. Legal approval should attach to exact language. The publishing record should identify where the statement appeared. If communications edits the wording after approval, the claim returns to review. This is slower than letting one executive approve the deck in a late-night message, which is precisely why it works.

Production drift can turn a true claim stale

An AI statement may be accurate on approval day and misleading after a system change. A team can replace a model and remove a data source. It may turn off a feature or move a workflow from production back into testing. The public language then describes an architecture that no longer exists.

Tie each claim to change triggers. Reopen review when the named model or data source changes. A changed workflow or user population also triggers review, as does a changed output. Do the same after a feature is disabled or a vendor changes the underlying service. A quarterly review catches slow drift, while release and incident triggers catch material changes between scheduled reviews.

The claim register should preserve old versions rather than overwrite them. An examiner may need to reconstruct what the company said on a particular date and what system existed then. The AI audit trail requirements guide explains why contemporaneous records are stronger than a narrative assembled after scrutiny begins.

Public-company disclosure needs a materiality path

The 2024 actions involved registered investment advisers under the Advisers Act and the Marketing Rule. The SEC announcement also warned public issuers to remain vigilant about AI-related misstatements that may be material to investors. That warning deserves a defined escalation path without turning every product sentence into a securities filing decision.

Route potentially material AI claims to the disclosure committee or the issuer's established materiality process. Supply the exact language and technical substantiation packet. Add the revenue and strategy context the committee needs. Include the risk or operational context too, while keeping the technical team out of the legal materiality judgment.

The AI vendor risk assessment helps procurement establish what a vendor service does. Public statements still require issuer-owned verification. A vendor page or sales presentation can support diligence. So can a contract description. The company making the investor-facing statement owns the accuracy of that statement and the record behind it.

Test the record before publication

Run a short evidence test on every significant AI claim:

• Read the public sentence aloud and identify every factual assertion inside it.
• Ask the technical owner to produce the production system and data source that support those assertions. Require the release and test too.
• Confirm that legal reviewed the exact final wording and the channel where it will appear.
• Verify that the record has a review date and change triggers tied to the system.
• Preserve the published version and its substantiation packet under the same claim identifier.

This test can happen in a thirty-minute review with the claim on the left side of a conference-room screen and the evidence links on the right. Empty cells force a choice. Narrow the wording or gather the missing proof. Otherwise, stop publication. Vague enthusiasm should lose to a sentence an engineer and lawyer can both defend.

DeepInspect

DeepInspect can support a narrow part of the substantiation record when the claim concerns authenticated HTTP traffic sent to an LLM. For deliberately routed requests, it evaluates identity-aware policy and writes a per-decision record containing the supplied context and model route. It also records the policy version and action, plus the timestamp.

Those records can help prove that a named route operated under a particular policy during a stated period. They cannot prove a model was trained on particular data or establish investment performance. They also cannot approve disclosure wording or decide materiality. The claim register must keep those responsibilities with engineering and legal. Compliance and the disclosure committee retain their responsibilities too.

Let's talk today.