When an “AI case” is really many cases at once
A reader sees a headline like “AI system discriminated” or “AI defamed someone,” and it sounds like a single dispute with a single culprit. In court, it usually splits into several smaller cases that overlap: a product case about design and warnings, a data case about what went into training or prompts, a workflow case about how humans reviewed (or didn’t), and often a contract case about who promised what to whom. Each slice has different facts, legal tests, and evidence problems. That fragmentation is why early motions can look scattered and why outcomes often turn on mundane details like logging, vendor terms, and who had the last meaningful chance to catch the error.
What exactly happened: model, data, or human workflow?
A common moment in these disputes is the defendant saying, “The model did it,” and the plaintiff replying, “No, your process did.” Courts then have to separate three possibilities that can look identical on the surface: the model’s behavior (what it tends to produce), the data fed into it (training data, retrieval sources, prompts, or fine-tuning), and the human workflow wrapped around it (review, escalation, overrides, and how outputs were used).
That sorting exercise matters because it changes what “reasonable care” even means. If the harm traces to a bad retrieval source, the fix might be basic data hygiene and monitoring. If it traces to prompt templates or guardrails, the issue looks more like negligent configuration. If a human was supposed to verify but treated the output as authoritative, the case can turn on staffing, training, and incentives. Proving any of this can require expensive expert work, access to logs that may not exist, and a reconstruction of decisions made across multiple tools and teams.
Proving reliability when the system won’t explain itself
In a typical AI dispute, one side wants to treat the output like a faulty instrument reading: wrong result, therefore unreliable system. The other side points out that many models don’t produce stable, repeatable answers, and they can’t provide a neat “because X” explanation that maps onto a human chain of reasoning. That leaves courts using workarounds that feel more like product testing than mind-reading: show the same prompt repeatedly, vary inputs in controlled ways, compare versions before and after an update, and measure error rates against a reference set that approximates the real-world task.
Even that approach runs into practical limits. The most informative evidence may be in internal evaluation reports, A/B test results, and incident tickets that companies treat as confidential, or in logs that were never kept. If the model or safety layer changed after the incident—as often happens—each side fights over whether later behavior proves anything about what happened on the specific date at issue.
Hidden bias claims: discrimination without a “smoking gun”
A hiring tool rejects more older applicants, a lending model offers worse terms in certain ZIP codes, or a tenant-screening system flags more people with disabilities. The pattern can be obvious to the people affected, yet hard to translate into courtroom-proof discrimination. Unlike a manager’s email or a written policy, the “reason” for a decision may be a tangle of proxies—employment gaps, school names, browser settings, address history—that correlate with protected traits without explicitly naming them.
That pushes cases into statistical and process evidence: disparate impact analyses, audit studies, and comparisons between similarly situated applicants. Defendants often respond that the features reflect legitimate risk signals, that the model is only one input, or that downstream reviewers made the real decision. Plaintiffs then need access to decision logs, feature definitions, and override records to show the model meaningfully drove outcomes. Many organizations never captured this evidence at the time, and recreating it later can be expensive, incomplete, and contested.
Who’s responsible: developer, deployer, vendor, or user?
Responsibility gets messy because the “AI system” in a complaint is usually a supply chain. The model developer controls training choices and core behavior. A platform vendor may add safety layers, hosting, and monitoring. The deployer picks the use case, tunes settings, connects data sources, and decides whether outputs are advisory or binding. Users supply prompts and may bypass review steps. Courts then ask practical control questions: who selected the model, who set the thresholds, who chose the training or retrieval data for this domain, who saw the output before it was acted on, and who could have prevented the harm at the lowest cost?
Contracts often try to pre-answer that with disclaimers, usage restrictions, audit rights, and indemnities, but those terms don’t automatically map onto tort duties or statutory obligations to customers, employees, tenants, or the public. A deployer may be “responsible” even if the vendor’s tool behaved badly, especially where the deployer marketed it as reliable or removed human checks. Sorting this out can require pulling technical and business records from multiple companies that have every incentive to point the finger elsewhere.
Discovery fights: proprietary code, privacy, and missing logs
Discovery is where many AI cases stall, because the most probative materials are also the most contested. Plaintiffs ask for training data sources, system prompts, fine-tuning records, evaluation results, incident reports, and the exact model version that ran on the date of harm. Defendants often respond that this is protected trade secret, that disclosure would expose security controls, or that they can satisfy the request with high-level descriptions and a limited “black box” test instead of handing over code or weights.
Privacy adds another layer. Logs may contain other users’ prompts, personal data, medical or employment details, or internal notes that trigger privilege fights, redaction costs, and arguments about whether anonymization is even feasible at scale. Then there’s the simplest problem: the logs may not exist, may have been overwritten under routine retention policies, or may be fragmented across vendors. When the record is incomplete, courts end up litigating not just what the system did, but what anyone can prove it did.
What courts can actually order when AI causes harm
A court can’t usually “fix the model” in any direct sense. What it can do is order remedies that look like familiar product, contract, and civil-rights outcomes: money damages for proven losses, injunctions to stop a particular use, and corrective steps that make a workflow less risky. In practice that might mean requiring human review for certain decisions, disabling an automated rejection path, adding notices when outputs are generated, or preserving and producing logs going forward so the next dispute isn’t fought in the dark.
The hard part is tailoring an order to a moving target. Models are updated, vendors change terms, and a deployer may swap components while litigation is pending, raising fights over whether an injunction is too broad or already moot. Courts also run into enforcement limits: “be less biased” is not an operational instruction. Orders tend to land on concrete, auditable commitments—retention schedules, audit rights, reporting obligations, and narrow restrictions on where and how the tool may be used—because those are things a judge can later measure and sanction.
A practical way to think about AI disputes going forward
The useful way to forecast how an AI dispute will play out is to track four concrete questions that cut across legal theories: provenance (what data, prompts, and versions were in play on the specific date), control (who configured, reviewed, and had the last realistic chance to prevent harm), reliability (what error rates and testing evidence exist for this task, not AI in general), and record (what logs and retention practices make any of that provable). Cases tend to turn less on abstract “AI risk” and more on whether someone can produce time-stamped artifacts that connect an output to a decision. The practical constraint is cost: audits, experts, and privacy-compliant discovery are expensive, so many cases settle around what can be shown, not what might have happened.
