FTC AI Enforcement: What Operation AI Comply Puts on Notice

FTC AI enforcement is concrete. In September 2024, the Federal Trade Commission announced Operation AI Comply. The sweep covered five actions involving an advertised AI lawyer and a review-generation service, along with business-opportunity schemes that invoked AI while promising earnings. The mechanism is familiar: a company makes a specific capability or outcome claim, buyers act on it, and the evidence behind the claim fails under inspection. Security and governance teams need a claim record tied to the product version that customers actually use.

TL;DR

• Operation AI Comply announced five FTC actions involving AI capability claims and review generation, plus business-opportunity earnings claims.
• A model demonstration supports only the conditions actually tested. The same limit applies to a vendor slide or internal benchmark. Marketing needs evidence for the deployed product and the words customers will read.
• Treat each AI claim as a controlled record with an owner, source, test date, product scope, limitations, and approval history.
• Runtime logs can prove which policy and model route handled a request. They cannot prove every advertising claim about accuracy, earnings, professional equivalence, or legal outcomes.

FTC AI enforcement starts with the advertised claim

The FTC's Operation AI Comply announcement grouped five law-enforcement actions around deceptive or unfair conduct involving AI. The subjects differed, but the evidence question is practical. What did the seller tell a consumer? What basis existed when the statement was made? Did the product delivered to the buyer match the system that was tested?

That sequence should shape an enterprise review. Copy the exact statement into a claim register before debating broad terms such as responsible AI. Record the audience, channel, date, and product edition. Then record the model, prompt or workflow, and any qualification shown beside it. A claim in a sales deck can create the same evidence problem as wording on a public webpage. Procurement questionnaires matter too, especially when an answer moves into a customer's contract file.

The SEC AI-washing evidence guide covers a parallel disclosure problem in financial markets. The FTC examples focus the same discipline on claims presented to consumers and buyers.

Operation AI Comply shows three evidence failures

The sweep included the FTC's case against DoNotPay over claims for an automated legal service. The review question is narrower than a debate about AI replacing lawyers. A seller that promises professional-level legal capability needs substantiation for that promised capability and the product delivered under the claim. The FTC's earlier AI advertising guidance tells businesses to examine exaggerated capability claims and comparative performance, as well as foreseeable risks and whether a product actually uses AI.

Rytr presented another pattern. The FTC challenged a service that generated consumer reviews and testimonials, including material that could be false or deceptive. Here the risk is in the workflow itself. The product can manufacture text that appears to describe a real person's experience. Review provenance and approval are therefore part of the control design, rather than in a general content policy buried elsewhere.

Three other actions addressed e-commerce business opportunities promoted with AI. They also addressed earnings representations. The useful lesson is blunt: adding AI to a revenue promise increases the number of technical dependencies, but it never supplies evidence for the promised income. Keep the earnings substantiation separate from evidence that the automation is in the product.

Build a claim-to-evidence register before release

A working register gives legal and product teams one object to review with security and marketing. I would block a launch if the approved claim lives in a slide deck while the test result sits in an engineer's private notebook. A green cell on page 47 has no value when nobody can reconstruct the tested route.

Each record should contain:

• Exact claim: Preserve the sentence and nearby qualification. Record the audience and publication channel.
• Product boundary: Name the edition, model, and workflow, including which flags are enabled. Add the data source and integration path covered by the evidence.
• Test method: Record the dataset or scenario and acceptance criteria. Identify the reviewer, date, environment, and known exclusions.
• Result and limitations: Keep the measured result beside failure cases and operating conditions.
• Approval: Identify the legal or product owner who approved the wording, along with any security or compliance owner involved.
• Change trigger: Reopen review after a model swap, prompt revision, retrieval change, or new data source. A release or material wording change should also reopen it.

The AI risk register template can hold the wider use-case risk. The claim register should link to that record while preserving the exact public statement and its evidence.

Runtime records answer a smaller question

An AI request log can identify the authenticated user or agent and the model route. It can also preserve the policy version and resulting allow or block decision. That record is valuable when a claim concerns a deployed control. For example, a statement that a named route blocks a defined data class can be tested against policy and request records.

Other claims need different evidence. A statement about legal quality requires an appropriate evaluation and review method. An earnings claim requires substantiation tied to the represented outcome. A consumer testimonial needs provenance. A broad accuracy figure needs a defined task and dataset, plus a metric, sample, and version. One audit stream cannot carry all four.

Use the AI audit log format guide for request-level fields. Link those records to the claim register by product version and test identifier. That connection lets a reviewer trace a statement to the configuration that produced the evidence without pretending the runtime log proves the whole advertisement.

DeepInspect

DeepInspect can supply evidence for claims about policy enforcement on authenticated HTTP requests sent by users or agents to LLM endpoints. It evaluates application-supplied identity and request content against policy. Before traffic proceeds, it records the route, policy version, decision, and timestamp.

That evidence is part of the approved claim and its test record. Product evaluations and consumer-review provenance are separate workstreams. Professional-quality assessments and earnings substantiation are separate too, with their own owners. A clean architecture keeps those evidence classes linked without merging them into one vague assurance statement.

Book a technical deep dive at deepinspect.ai.