A wrongful death lawsuit, Raine v. OpenAI, has put a once-obscure governance document at the center of artificial intelligence litigation strategy. System cards, the structured disclosures AI developers publish to describe how their systems perform, are now being used by both plaintiffs and defendants to establish what a company knew, when it knew it, and whether its safeguards were adequate. For lawyers advising companies that build or deploy AI tools, understanding how these documents create legal exposure is key in a thoughtful risk mitigation strategy.
The risks are similar, but not exactly the same, across AI developers, companies that build tools on AI platforms, and companies that use AI tools. Take this for an example: The system card for OpenAI’s GPT-5.5 model, released in April 2026, reports lower scores than the immediately preceding model for not producing disallowed outputs when the input includes an image across all four categories evaluated—hate, extremism, self-harm, and erotic harms—though OpenAI describes the differences as minor and not statistically significant. It could mean, however, that GPT-5.5 was worse at identifying content in those categories. If a deployer of AI that developed a companion app used this new ChatGPT model, there might be a valid argument that the deployer should have known the selected model was not appropriate for this use case because of the information in the system card.
System cards function primarily as evidence rather than as an independent cause of action. They can nonetheless give rise to liability where the disclosure itself is false or misleading because AI capability representations are subject to Section 5 of the Federal Trade Commission Act and, in California, to civil penalties under the Transparency in Frontier Artificial Intelligence Act enacted in 2025.
Why Companies That Integrate AI into Their Products Should Care About System Cards
System cards are published by AI providers and describe how a deployed AI system performs in real-world conditions, including intended use cases, known limitations, testing methodology, and risk mitigation measures. The term is sometimes contrasted with model cards, which address underlying models rather than deployed systems, but developers use the labels inconsistently, and a single document often blends both. Counsel should read the methodology closely rather than assume a card describes production behavior, since results are frequently generated offline and may capture only the model’s own conduct without accounting for other layers of the safety stack.
Companies that integrate third-party AI systems into their products may also face claims that they should have known about risks disclosed in a provider’s card. If those materials identify known limitations, foreseeable misuse, or safety concerns, a downstream company may be expected to account for those risks in its own product design, user disclosures, contractual controls, and usage restrictions.
System Cards in Litigation: Raine v. OpenAI
Raine v. OpenAI, No. CGC-25-628528 (Cal. Super. filed Aug. 26, 2025) arose from the suicide of a sixteen-year-old who had used ChatGPT extensively in the months before his death. His parents allege that OpenAI’s system was defective, that the risks were foreseeable, and that the company failed to implement safety measures to reduce the foreseeable harms. A subsequent amended complaint added the allegation that OpenAI deliberately removed a “suicide guardrail” from its platform, framing the claim not just as a failure to warn, but as a conscious choice to deprioritize safety. As of this writing, the case remains in pretrial proceedings.
Plaintiffs rely on OpenAI’s own system documentation to argue the company had actual knowledge of the risk. OpenAI relies on the same materials to show it conducted structured testing and implemented safeguards. Both sides treat system cards as probative of the company’s knowledge, the foreseeability of harms, and the adequacy of the company’s response. However, the question is not whether adequate disclosures were made, but whether the disclosures aligned with what the system actually did.
The FTC, SEC, and California Now Treat AI Disclosures as Enforceable Representations
The FTC has made clear, through staff guidance and enforcement, that AI capability claims are subject to the same deception standards as any other product representation.
The Securities and Exchange Commission has taken the same posture for public companies. Its Division of Examinations, in priorities released in November 2025, said it will assess whether registered companies’ AI-related disclosures, supervisory frameworks, and controls align with actual practices. Those priorities reach investment advisers, broker-dealers, and investment companies, among others, rather than issuers generally. For issuers, the analogous exposure runs through the federal securities antifraud provisions, principally Section 17(a) of the Securities Act of 1933 (15 U.S.C. § 77q(a)) and Section 10(b) of the Securities Exchange Act of 1934 (15 U.S.C. § 78j(b)) and Rule 10b-5 (17 C.F.R. § 240.10b-5), where “AI washing” has already drawn enforcement attention.
California codified the same principle with penalties. The Transparency in Frontier Artificial Intelligence Act, effective January 1, 2026, requires frontier AI developers to publish safety frameworks, disclose catastrophic risk assessments, and report critical safety incidents within fifteen days to state regulators. Civil penalties of up to $1 million per violation, enforced by the California attorney general, attach to enumerated violations.
Practical Risks for Companies
As system cards are used in litigation and enforcement, the risks they create and the actions required to manage those risks are closely related.
- System card statements can function as admissions: Descriptions of known limitations or failure modes are often drafted to demonstrate responsible governance, but in litigation, those same statements become evidence that the company had actual knowledge of a specific risk before harm occurred. Every disclosure of a weakness should be accompanied by internal documentation showing how that weakness was evaluated and what was done about it.
- A documented risk with no documented response is a failure-to-warn claim waiting to be filed: If a system card identifies a limitation but the company does not translate that acknowledgment into user-facing warnings, usage restrictions, or design changes, plaintiffs will argue the company knew of the hazard and chose not to address it. The Raine amended complaint makes exactly this argument regarding the removed guardrail. A documented risk with no documented response is a failure-to-warn claim waiting to be filed.
- Outdated documentation creates independent exposure: AI systems change faster than the documents that describe them. A system card that no longer reflects current system behavior, particularly one that omits the removal of a previously disclosed safety feature, suggests the company stopped paying attention to its own disclosures. Companies should treat system card updates as a compliance obligation.
- Inconsistency between internal testing and external statements is discoverable: System cards will be reviewed alongside internal evaluations, safety logs, and communications. Where public summaries diverge from what engineers and safety teams actually found, that gap will be central to both litigation and regulatory inquiry. Internal records should be able to support every material statement in any external disclosure.
Final Takeaways
System cards are no longer just technical transparency documents; they are becoming evidence of what companies knew about AI risks and how they responded. Companies that develop or deploy AI tools should treat these disclosures as legal and compliance documents, ensuring that public statements align with internal testing, actual system behavior, and documented mitigation steps. The greatest exposure may arise not from identifying risks, but from failing to act on them, update disclosures, or explain why a particular safeguard was sufficient. As litigation and regulatory scrutiny increase, system cards should be reviewed with the same care as other material representations about product safety, performance, and risk.
