FTC AI Investigation: What OpenAI and Anthropic Must Show
Learn what the FTC's demands for OpenAI and Anthropic mean for AI governance, incident response, privacy, and the controls every business should build.
The FTC Is Asking AI Labs for Their Safety Records. What Happens Next?
AI companies have spent years describing their safeguards in public. The harder question is what happens when those safeguards hit an incident - what the system detected, what the company did next, and what users were told along the way.
That question is now part of a Federal Trade Commission investigation. The FTC has sent OpenAI and Anthropic separate civil investigative demands seeking records on security incidents, safeguards, marketing materials, and privacy policies, according to reporting by Axios. Each demand reportedly runs about 50 pages. A civil investigative demand functions like a subpoena, but it doesn't mean either company has broken the law.
For AI companies, the immediate task is responding to regulators. For businesses that build or buy AI, the bigger takeaway is practical: safety claims only matter if they connect to real controls and a real incident-handling process. This article breaks down what the FTC's requests signal, how the wider AI market is shifting, and what operators can put in place before a regulator, customer, or board asks for the evidence.
What the FTC's demands mean
The FTC is seeking records from OpenAI and Anthropic across four connected areas: security incidents, safeguards, marketing materials, and privacy policies. Read together, those categories suggest something broader than a narrow technical review. Investigators can compare what a company says its systems do with the controls it actually runs and the events it has recorded.
The distinction matters. A request for information isn't a finding of misconduct. The demands open an investigation; they don't claim that either company violated the law. Still, once a regulator asks for records, internal documents often become the backbone of how decisions and risk were handled.
The gap between a safety claim and a safety process
An AI provider might describe safeguards in a product announcement, usage policy, or sales deck. Those materials only help if they match the real system.
A written promise that a model blocks certain harmful requests isn't the same thing as evidence that the company tests those cases, tracks failures, and updates its controls after changes to the system or how people use it.
That's why records about marketing and safeguards belong in the same conversation. Companies need to show what was promised, which model or product the promise applied to, what testing supported it, and whether the claim stayed accurate after a release or shift in use.
In many organizations, this is where things fall apart. Product, legal, security, and communications teams may each hold part of the timeline. If nobody owns the full record, it's hard to answer the basics - what did we know then, and what did we do about it?
What an investigation does - and does not - tell us
The public information described in the source reporting is limited. It doesn't name a specific incident as the trigger, map out the full scope of the FTC's inquiry, or confirm any conclusion about either company. Treating the demands as proof of a specific failure goes further than what's known.
A more useful read is that regulators are asking for evidence across the lifecycle of AI products: how systems are tested, how users are informed, how personal information is handled, and how the company responds when protections fail.
For businesses outside the AI lab world, the signal matters even before the outcome is known. Regulators and customers increasingly expect safety, privacy, and reliability claims to be supported by records - not just confident language. For more on operating practices, see our guide to AI governance and accountability.
Why AI safety records matter beyond the labs
AI incidents aren't just about a model giving the wrong answer. They can involve exposed data, unsafe outputs, unexpected tool use, security vulnerabilities, or a system being used in ways the operator didn't anticipate. The right response depends on what went wrong - but the first step is always the same: recognize the issue, preserve enough evidence to understand it, and be clear about who owns the next decision.
That sounds easy. In practice, it's messy. A customer-support team might use one model through an API, developers might use another through an editor, and employees might use a third through an enterprise assistant. If something goes wrong, it may not be obvious which provider, version, prompt, data source, or access permission was involved.
A record is useful only if it supports decisions
Incident documentation shouldn't turn into paperwork for paperwork's sake. The point is to help teams decide what to contain, who to notify, and what to change.
A record should capture:
- What happened: observed behavior, affected product, and approximate time.
- Where it happened: model and version, deployment, connected tools, and relevant data sources.
- Who was affected: customers, employees, or systems potentially exposed to harm.
- What the team did: containment, investigation, notification, and remediation steps.
- What remains uncertain: known evidence gaps and the next review date.
The uncertainty field matters. Early in an incident, teams rarely have the full picture. A good log separates confirmed facts from working assumptions instead of forcing people to write with "we know this" confidence.
It also helps to link the incident record to supporting evidence where possible: logs, test results, tickets, policy versions, and approvals. Don't copy sensitive information into the record just because it's convenient. Access controls and retention rules matter - an accountability record can become a security risk if it includes credentials or personal data without a reason.
The same discipline applies to marketing and privacy
A safety statement can turn into a liability when the product changes and the statement doesn't. The answer isn't to ban useful claims; it's to make them reviewable. Keep a record of what was said, which product or capability it covered, what evidence supported it, and who approved it.
Privacy needs the same kind of discipline. Teams should understand what information a model receives, whether a provider retains it, how it's used, and which settings or contract terms govern that use. These questions get harder when staff adopt tools independently or when product terms change.
One example from the week's reporting is Meta's business terms. Legal experts quoted by Nieman Lab said terms taking effect October 30 would allow Meta to crawl websites associated with certain business accounts and use that content to train its products. The terms reportedly apply to accounts that continue using Meta's business tools. That's not the same issue as the FTC demands, but it reinforces the same point: tool terms and data practices need ongoing review, not a one-time approval.
The business pressures underneath the headlines
Regulatory attention is only part of what companies are dealing with right now. They're also managing the real costs of model use, the cost of fixing vulnerabilities, and the trade-offs between buying external AI services versus running models in-house.
These pressures connect. A team that deploys AI without a clear view of usage can get hit with bills it didn't budget for. A team that uses models to find software flaws may discover that remediation takes real engineering capacity. And a company moving workloads to local models may gain more control over data location and costs - while taking on infrastructure and maintenance responsibilities.
AI use has a budget - and a limit
The source reports that Accenture will centrally fund $29 per month per employee for Claude usage, effective October 1. Some employees reportedly spent as much as $1,000 a month, with usage above the cap requiring a project budget.
The issue isn't whether $29 is the right number. It's that per-person usage can swing wildly, and an open-ended allowance isn't a cost strategy. In practice, companies should measure spend by team, task, and business outcome before setting controls. Otherwise, the first "real" budget decision might arrive as a surprise cap that disrupts work.
A good starting point is separating experimentation from production use. Experimentation needs clear limits and a short review cycle. Production use needs an owner, an expected volume, a fallback plan, and a reason the AI-enabled workflow is better than the alternative. Our guide to enterprise AI cost management goes deeper on budgeting.
Finding vulnerabilities creates remediation work
Bank of America CEO Brian Moynihan said the bank added 1,000 contractors in the second quarter to address software flaws exposed by AI models, on top of 3,000 people already working in that area. The company also reported that software remediation and anti-money-laundering compliance cost "a couple hundred million plus" in the third quarter, with an expectation that costs would decline after patching work was completed.
This is a useful counter to the idea that AI security tools automatically reduce costs. A model can shorten discovery time, but it doesn't patch the flaw, test the fix, or prove the change didn't introduce new problems. Detection creates a queue. If the organization can't triage and remediate that queue, faster discovery can expose an operational bottleneck instead of removing one.
The same logic applies to AI safety testing. A benchmark result or red-team finding only helps when it drives a decision - block a release, adjust permissions, add monitoring, or accept a documented risk. Without an owner and a response process, a growing pile of findings isn't a control.
Open models change the cost equation, not the whole problem
The week's reports also highlighted large open-weight models aimed at local or company-controlled deployment. Meta released Muse Spark Open, described as an 816-billion-parameter model with a one-million-token context window that requires at least one terabyte of memory and is intended for powerful Apple hardware. Nvidia announced Nemotron 3.5 Super VL, a 120-billion-parameter model for documents and visual inputs, plus a smaller model aimed at local coding and research.
The appeal is obvious: running a model on owned hardware can turn unpredictable API spending into a more stable infrastructure cost and give organizations more control over where data gets processed. But "local" doesn't automatically mean cheap, secure, or better. Hardware, power, deployment, monitoring, updates, and specialist support all have costs. Large models can also demand substantial resources, and vendor benchmark claims still need independent testing on the tasks that matter to your business.
The comparison shouldn't be API price versus hardware price. It's total cost, capability, latency, data handling, operational ownership, and how well the result performs on real work. Before moving a workload, test representative tasks and compare failure rates - not just polished demos. For more on operational controls, see AI security and deployment risks.
A practical framework for AI incident readiness
You don't need to copy the governance structure of a frontier AI lab to prepare for scrutiny. What you do need is a repeatable process that still works when the system builders are unavailable - or when key details are hard to reconstruct.
A lightweight approach has five parts.
-
Inventory the systems people actually use
List approved AI products, internal models, connected tools, and any known unsanctioned use. Record the business owner, provider, model or service, data categories involved, and whether the system can take actions or access internal resources.
Don't treat the inventory as a one-time spreadsheet. Tools change, employees adopt new workflows, and providers revise products. Assign someone to maintain it and set a review cadence that matches how fast things move.
-
Match controls to the risk of the use case
A writing assistant working with public material doesn't need the same review as an agent that can modify customer records or execute code. Define a few practical risk levels using factors like data sensitivity, user impact, degree of automation, and whether the action is reversible.
Then match controls to that risk. Higher-risk uses may require human approval, restricted access, extra testing, monitoring, or a documented fallback. The goal isn't to add a committee to every experiment. It's to stop a low-friction prototype from quietly turning into a high-impact production system.
-
Keep evidence close to the decision
For each meaningful deployment, retain the relevant policy, testing results, approvals, product claims, and vendor terms. Make it possible to identify which system version was in use at a given time. If a model or product changes, record what changed and whether the use case needs a reassessment.
This is more useful than stuffing every document into one big repository with no owner. Evidence should be findable, access-controlled, and tied to a specific system or decision.
-
Define the incident path before an incident
Decide who gets the report, who can disable or limit the system, who assesses user impact, and who handles legal, security, privacy, and communications questions. Set clear escalation thresholds. If personal data might have been exposed, it shouldn't sit in a general AI feedback queue for a week.
Run a short tabletop exercise using a plausible scenario: an AI assistant reveals information it shouldn't, or an automated tool takes an unintended action. This isn't a "test." It's a way to surface unclear ownership and missing access before it matters.
-
Review claims and terms when the product changes
Assign an owner to compare external statements with current system behavior. Review privacy terms when a provider changes its product, data retention, or training practices. Keep a record of the decision and the date - otherwise teams end up relying on old assumptions that nobody remembers making.
The process should be light enough to repeat. A perfect framework nobody maintains won't help. A modest one that captures the important facts each time will.
Conclusion
The FTC's requests to OpenAI and Anthropic don't amount to a finding against either company. What they do change - practically - is the expectation that AI safety, privacy, and security claims should be backed by evidence a company can retrieve and explain.
That expectation goes beyond AI labs. Businesses need to know which systems they use, what data they touch, what people have been told, and how failures are handled. At the same time, spending limits, remediation workload, and open-model infrastructure make one thing clear: adoption has real operating costs, not just subscription fees.
Start with one concrete step: pick a live AI workflow and see whether you can identify its owner, data inputs, provider terms, safety checks, and incident path. If you can't, fix that before scaling the workflow. Then repeat the same process for the next one.