Data & Society Trains State Enforcers on Questions to Ask AI Companies

A workshop series built for litigators

Data & Society's Public Technology Leadership Collaborative and Tech Justice Law co-organized the series this summer. Becca Ricks, project director of the collaborative, and Tiffany Gillis Brown, litigation counsel at Tech Justice Law, wrote up the findings in a post published on November 4, 2026.

The organizers say litigators and enforcers want to understand how tech companies make safety decisions about generative AI products, but are not necessarily equipped with technical knowledge about how the products are built, how safety evaluations are conducted, and where responsibility lies across the companies involved. To pursue accountability for harms, they need to know which questions to ask.

The first session introduced a technical map of the AI supply chain and key AI safety concepts. The second covered where safety evaluations happen in the AI product lifecycle. The third was a hands-on exercise built on hypothetical scenarios based on real cases. Six guest experts presented across the series.

A concentrated stack spreads responsibility

The organizers describe one common version of the generative AI tech stack as four layers: chips, cloud computing, foundation models and applications. The application layer is what consumers and businesses use, while the layers below are the infrastructure needed to build and run AI.

According to the authors, a small number of companies dominate each infrastructure layer. NVIDIA makes the vast majority of chips used to build AI. Amazon, Microsoft and Google control most of the cloud computing power. OpenAI, Anthropic and Google make most of the AI models behind chatbots and tools.

Because infrastructure is so costly, the authors point to circular financing and vertical integration. They cite NVIDIA investing tens of billions of dollars into AI companies like OpenAI, as well as into neocloud companies that run AI systems. The result is a web in which the same few companies supply, invest in and depend on each other. For accountability, this means responsibility for a specific harm rarely lies with a single company, so enforcers need to understand the full stack to see who made key decisions and who could have prevented harm.

Safety decisions and the limits of benchmarks

Safety decisions are spread across the product lifecycle, and the panel provided a checklist of questions for auditors and litigators. On data and training, the examples include:

• What is the source of the training data, and why were sources selected or excluded?
• Which third-party vendors were involved in acquiring or processing the data?
• What automated or human review screened the training corpus for harmful, illegal or biased content?
• Were bias audits conducted, and by whom, when, and with what findings?
• What documentation describes the dataset's composition, provenance and licensing status?

The authors stress that the science of AI evaluation is immature. Benchmarks are standardized tests that measure specific characteristics of an AI system, but there is little consensus on how evaluations should be done or which benchmarks are most valid. Citing a Center for Democracy & Technology report, they note that most AI labs design and validate their own safety tests in-house and report results selectively. A high score does not necessarily correlate with real-world harm.

Litigators should therefore question what it means when a company says its models passed safety evaluations. But a single failed benchmark might not be evidence of negligence. In the authors' words, a company's choice and justification for a benchmark often tells us more than the result of the testing.

Upstream and downstream discovery

The organizers say courts increasingly let technology cases move past motion-to-dismiss stages into full fact-finding, which makes discovery an important tool. Based on Tech Justice Law's analysis of recent tech litigation, companies tend to oppose data requests broadly, citing undue burden, trade secret protection and legal privilege. AI companies also invoke Section 230 or First Amendment protections to argue that certain products or features are shielded from discovery.

The authors propose an upstream-downstream framework. Upstream discovery looks at internal company behavior such as internal testing, source code and design rationale. Downstream discovery focuses on users, including dependence, behavior and data. They say understanding the basic functionality of the technology and engaging technologists early is key to drafting effective requests for production and interrogatories.

What it means for enforcers

Participants told the organizers they left with a stronger technical grounding and a clearer view of where AI safety decisions are made. The authors read the turnout as a signal that enforcers are looking for this kind of technical expertise.

They also say much work remains: AI benchmarking science is still young, the field has not settled on a shared technical vocabulary, and legal frameworks are catching up. That, they conclude, leaves an opening for further exploration.