A wrongful death lawsuit, Raine v. OpenAI, has thrust a technical governance document into the spotlight of AI litigation. System cards, the structured disclosures that AI developers publish, are now central legal tools. They are 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 use AI, understanding how these documents create legal exposure is essential to managing risk.
The risks for companies vary depending on their role in the AI ecosystem. For developers, the risks are distinct from those of companies that simply use AI tools in their own products. For 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.
However, this data could suggest the model was less capable at detecting such content. A company that built an app using this ChatGPT model could face a legal argument that it should have known the model was unsuitable for its specific use, based on the information in the system card.
System Cards as Evidence and Legal Risk
System cards function primarily as evidence rather than as an independent cause of action. They can, however, create liability if the information they contain is false or misleading. AI capability statements are subject to Section 5 of the Federal Trade Commission Act, which prohibits deceptive practices. in California, to civil penalties under the Transparency in Frontier Artificial Intelligence Act enacted in 2025.
These documents describe how a deployed AI system performs in real-world conditions. This includes its intended uses, known limitations, testing methods, and risk mitigation steps. The term is sometimes confused with “model cards,” which focus on the underlying AI model rather than the deployed system. but developers use the labels inconsistently, and a single document often blends both. Lawyers should scrutinize the testing methodology closely, as results are frequently generated offline and may not reflect the full safety stack of a live product.
Companies that integrate third-party AI into their products face a different risk. If a provider’s system card identifies known limitations or foreseeable misuse, a downstream company may be expected to account for those risks. This means incorporating them into product design, user disclosures, contractual controls, and usage restrictions.
Raine v. OpenAI: A Case Study
The case of Raine v. OpenAI, filed in a California court in August 2025, illustrates how system cards are being used in litigation. The lawsuit was brought by the parents of a 16-year-old who died by suicide after extensive use of ChatGPT. They allege the system was defective, that the risks were foreseeable, and that OpenAI failed to implement adequate safety measures. An amended complaint added a new claim, stating that OpenAI deliberately removed a “suicide guardrail” from its platform. This frames the issue not just as a failure to warn, but as a conscious choice to deprioritize safety.
Both sides in the case are using OpenAI’s own system documentation to support their arguments. The plaintiffs rely on it to show the company had actual knowledge of the risks. OpenAI, in turn, uses the materials to demonstrate that it conducted structured testing and implemented safeguards. Both sides treat system cards as evidence of the company’s knowledge, the foreseeability of the harm, and the adequacy of its response. However, the question is not whether adequate disclosures were made, but whether the disclosures aligned with what the system actually did.
For companies developing or deploying AI, the stakes are high. Regulators now treat system cards as enforceable representations, not just voluntary disclosures. The Federal Trade Commission enforces Section 5 of the FTC Act against deceptive AI claims. In California, the Transparency in Frontier Artificial Intelligence Act imposes civil penalties of up to $1 million for violations. The Securities and Exchange Commission similarly monitors AI-related disclosures by public companies for alignment with actual practices.
Practical Risks and Compliance Obligations
Statements in system cards can function as admissions in court. Descriptions of known limitations may demonstrate responsible governance initially, but in litigation, they become evidence that the company had actual knowledge of a risk before harm occurred. Every disclosure of a weakness should be accompanied by internal documentation showing the evaluation process and the steps taken to address 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 act. The amended complaint in Raine v. OpenAI makes this exact argument regarding the removed guardrail.
Outdated documentation creates independent exposure. AI systems evolve faster than the documents that describe them. A system card that no longer reflects current system behavior, especially one that omits the removal of a previously disclosed safety feature, suggests the company stopped monitoring its own disclosures. Companies should treat system card updates as a compliance obligation.
Inconsistency between internal testing and public 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 must be able to support every material statement in any external disclosure.
Leave a Reply