Short answer: on October 15, 2026, Reuters, citing Axios, reported that the U.S. Federal Trade Commission (FTC) had issued civil subpoenas to OpenAI and Anthropic seeking information on safety incidents, safeguards, privacy policies and representations made to consumers. These are reported investigative actions, not findings of wrongdoing. For enterprises the takeaway is practical: assess AI providers on their actual access, controls and responsibilities, using the same discipline you apply to any critical vendor, with extra questions that generative AI and AI agents introduce.
This article sets out what was reported, what it does and does not imply, and a seven-point checklist for AI vendor due diligence. It is analysis for risk and compliance teams, not legal advice.
What Was Reported
Axios first reported the subpoenas, and Reuters carried the report on October 15, 2026. According to Engadget’s summary, an Axios source said the FTC sought documents on security incidents and safeguards and on marketing and privacy-policy materials, that it plans to seek testimony from top executives, and that it may later send investigative demands to other AI companies. The FTC was described as exploring possible consumer protection violations.
Watch: What This Means for Enterprise AI Vendors
The video below walks through what the development means for enterprises using ChatGPT, Claude and other AI platforms, and how to assess AI vendors before giving them sensitive business information.
Why This Matters for Enterprise AI Vendor Risk
AI vendor due diligence is the process of assessing the security, privacy, governance, operational and regulatory risks of an external AI provider. As organisations bring AI into customer service, finance, compliance, internal audit, procurement and risk management, those providers become critical technology dependencies. Regulatory attention on a provider, whatever its outcome, is one more signal your continuous monitoring should be able to pick up.
Traditional questionnaires often miss what generative AI adds: what happens to prompts and files, how reliable the model is, which model and cloud suppliers sit behind the service, and what an autonomous agent is allowed to do. Our earlier pieces on AI vendor due diligence as its own risk assessment and AI governance and vendor due diligence cover the framework. This article applies it to a live news event.
Seven Checks Before Onboarding an AI Vendor
Data Privacy and Confidentiality
Establish what business and customer information the provider can access, retain, or use. Check whether prompts and files are used for training, how long they are kept, and who at the provider can read them.
AI Model Risk
Ask about known limitations, reliability, testing procedures and safeguards. Request evidence of testing rather than marketing claims, and find out how the provider handles harmful or incorrect outputs.
Cybersecurity and Incident History
Review security controls, independent assurance reports, and how incidents are detected, reported and managed. Agree notification timelines in the contract.
Fourth-Party Risk
Identify the cloud providers, model developers, subprocessors and other technology partners behind the service. Your data may sit with a company you never contracted with.
Regulatory and Compliance Risk
Map the legal, contractual and jurisdiction-specific obligations that apply to your use, including data protection law, sector rules and any regulatory attention the provider is under.
AI Agent Permissions
If the system can act, ask what it can reach: databases, payments, records, business actions. Apply least privilege, and require human approval for consequential actions.
Continuous Monitoring
Decide how you will spot changes in the vendor’s security posture, regulatory exposure or risk profile after onboarding. A one-time assessment goes stale quickly.
Two of these deserve extra emphasis. On fourth parties, see the AI model you never contracted with. On agents, see AI agent third-party access as a board risk and AI agent identity and access governance.
An illustrative example
This is a hypothetical scenario, not a customer case study. A finance team pilots an AI assistant that reads supplier invoices and drafts payment proposals. The assessment finds that the tool can read the vendor master, that retention of uploaded files is unclear, and that the provider relies on a cloud host and a separate model supplier. The team limits access to read-only, requires human approval for any payment action, asks for retention terms in writing, records the fourth parties in its register, and adds the provider to monitoring. Each decision is logged with an owner and a review date.
Could Your AI Vendor Face the Same Scrutiny? An Assessment Path
The question for CIOs, CISOs, procurement leaders, legal teams, data protection officers and AI adoption teams is not whether one provider is in the news. It is whether you could answer regulator-style questions about any AI vendor you use: what it can access, how it is tested, what has gone wrong, and what it has promised you. A simple path keeps the answers in one place, from vendor to approval.
AI Vendor
Identify the provider, the product and version, and the business sponsor. Register it as a vendor with a named owner, so nothing is used outside the programme.
Data Access
Classify the data it will see. Confirm retention, any use for training, storage location, and which provider staff can access it.
Model Risk
Match the intended use to the model’s documented limitations. Ask for testing evidence and require human review for high-impact decisions.
Security Controls
Review independent assurance reports, access controls and, for agents, the systems and actions they can reach.
Incident History
Ask for safety and security incidents, how they were handled, and notification terms. Check the public record, and treat a reported regulatory inquiry as an input to review, not a verdict.
Contractual Safeguards
Write down data-use limits, breach notice timelines, subprocessor disclosure, audit rights, change notification and exit terms.
Approval
The accountable owner approves, approves with conditions, or declines, and records the reasoning. Schedule reassessment and ongoing monitoring.
Run the path for every AI vendor, scaled to risk. A summarisation tool with no access to confidential data needs a lighter pass than an agent that can touch financial systems. Keep the output as a record you could show an auditor or a regulator: the evidence you collected, the gaps you found and the conditions you set.
Why Banks, GCCs and Large Enterprises Should Care
Banks and global capability centres (GCCs) handle customer, financial and client data under strict contractual and regulatory duties, and often run AI across many teams at once. AI vendor risk should therefore sit inside the existing third-party risk management programme, alongside information security assessments, privacy reviews, approval workflows and ongoing monitoring, rather than being handled as a separate technology experiment. Our guide to governing vendor AI exposure shows how to bring it together.
AI can also help run that programme. It can review vendor documents, interpret questionnaire responses, summarise adverse media, flag risk indicators and support ongoing monitoring, as described in AI across the TPRM lifecycle. The condition is human oversight, defined approval authorities and auditable decisions, as set out in why AI agents need audit trails.
Crest.Digital’s third-party risk management platform supports vendor onboarding, due diligence, regulatory screening, adverse media intelligence, risk assessments, configurable workflows and continuous monitoring.
The Question for Your Organisation
- Inventory: Do you know every AI platform and agent operating inside your business, and who approved it?
- Access: Do you know what data and actions each one can reach?
- Monitoring: Would you notice if a provider’s risk profile changed tomorrow?
Frequently Asked Questions
It is possible for any AI provider, because regulators are asking about safety incidents, safeguards, privacy practices and what vendors tell customers. You cannot predict an inquiry, but you can prepare: know what data each vendor touches, hold testing and incident evidence, and have contract terms that require prompt notice of material events.
No. Reported subpoenas are investigative information requests. They do not establish that either company committed a violation, and neither company’s response was included in the coverage we reviewed. The enterprise lesson is about how to assess any AI provider, not a judgement on these two.
It is the process of assessing the security, privacy, governance, operational and regulatory risks of an external AI provider before and after you give it access to business data or systems. It extends third-party risk management to generative AI, large language models and autonomous agents.
A standard review covers security, financial and compliance posture. AI adds questions about training and retention of your data, model reliability and testing, the provider’s own model and cloud suppliers, and what actions an agent may take inside your systems. Those areas are often missing from existing questionnaires.
There is no basis in the reports for that conclusion. A better response is to confirm what data and permissions each tool has, bring AI providers into your existing third-party risk programme, set approval and monitoring rules, and keep a record of the decisions.
Yes, for reviewing vendor documents, interpreting questionnaire answers, summarising adverse media and flagging risk indicators. Defined approval authorities and human review should remain, and the reasoning behind each assessment should be recorded so it can be audited.
Sources: Reuters, October 15, 2026 (via U.S. News); Engadget, summarising Axios reporting.
