A Brief Analysis of Key Highlights in the 'Opinions on the Lawful Adjudication of AI-Related Dispute Cases'
An interpretation of the Supreme People's Court's 'Opinions on the Lawful Adjudication of AI-Related Dispute Cases', analyzing its impact from the perspectives of developer liability, personal data training, burden of proof for training data, open-source software liability, review of generation processes, and AI-assisted litigation documents.
On September 7, the Supreme People’s Court (SPC) released the Opinions on the Lawful Adjudication of AI-Related Dispute Cases (hereinafter referred to as the Opinions).
Covering everything from AI face-swapping and voice cloning to training data, open-source software, autonomous driving, and litigants using AI to draft legal documents, it essentially touches upon almost every common legal controversy surrounding AI today.
Reading through the full text, what I appreciate most—and what finally feels grounded in reality—is its repeated insistence on considering technical feasibility, the control capabilities of different parties, and the specific generation process.
Compared to previous regulatory frameworks, it is worlds apart.
Under previous rules, developers were practically expected to ensure AI never produced errors while simultaneously being held liable for every conceivable downstream misuse. In the end, the most “compliant” small product was reduced to:
“What’s the weather tomorrow?”
“Sorry, I cannot answer this question.”
However, how certain provisions will be implemented in practice still warrants discussion.
Below, I have selected several key highlights closely tied to our daily AI development and usage, analyzed through both a technical and practical lens.
(Looking for a full-text breakdown? Just feed the original document to an AI or read someone else’s AI-generated summary.)
* Disclaimer: This article reflects only the author’s personal views and does not constitute legal advice.
1. An AI Glitch Does Not Automatically Mean the Developer Pays
Article 3 explicitly clarifies that unless specific statutory provisions apply strict liability (liability without fault) or presumed fault liability, liability shall be determined according to the fault liability principle pursuant to Paragraph 1, Article 1165 of the Civil Code.
Crucially, determining fault must take into account:
The measures taken to prevent and mitigate AI infringements, as well as technical feasibility.
“Technical feasibility”—superb. The policymakers are finally paying attention to how AI technology actually works in practice.
The output of typical Generative AI—whether text-based like Yuanbao, Doubao, or DeepSeek, or image/video generators—is influenced by an intricate web of variables: the underlying model, context window, prompts, and sampling parameters. The exact same query framed in a slightly different context can yield an entirely different answer.
Developers can mitigate risks through fine-tuning, filtering, and functional guardrails, but that is fundamentally different from being able to control every single output beforehand.
Generative AI operates as a black box. No matter how many restrictions are layered on, no provider can promise 100% infringement-free output.
Not to mention the countless users tirelessly attempting “jailbreaks” and prompt injections every single day.
If liability is retroactively imposed on developers simply because an infringing result occurred—deducing that they “failed to audit properly”—it essentially demands an “outcome-based guarantee”, placing an insurmountable burden on developers.
The Opinions at least establish that courts must weigh what developers can realistically do and the degree of effort reasonably expected of them.
However, this doesn’t mean developers can simply slap a disclaimer on their UI saying “Model outputs are stochastic” and wash their hands of all responsibility.
Deeper measures (such as latent space interventions that lower the generation probability of prohibited content, akin to digital watermarking) or surface-level checks (like real-time JavaScript stream monitoring or client-side content moderation) are still necessary.
You must at least do something tangible before you can present evidence that “reasonable care was exercised.”
2. Publicly Available Personal Data Can Now Be Used for Training
Article 6 states that within a reasonable scope, processing personal information that an individual has publicly disclosed or that has otherwise been lawfully disclosed for model training generally does not constitute an infringement on personal information rights, provided the individual has not explicitly refused.
Note: This applies to “personal information”, not copyright. The Opinions do not include explicit safe harbors for web scraping regarding copyright infringement; that remains a topic for another day.
The fact that the legality of training on personal information was validated first suggests that AI companies have collectively realized: data anonymization during pre-training is notoriously difficult.
To legally process such personal information, four conditions must be met:
Lawful public disclosure, reasonable scope, absence of explicit refusal by the individual, and obtaining explicit consent if the processing significantly affects the individual’s rights and interests.
Simply put: whether through an AI web app or an autonomous Agent, as long as you accepted the Terms of Service and didn’t manually toggle off the “Allow my data to be used for training” switch, the personal information you divulge while interacting with the AI can legally be collected for model training.
From a practical perspective:
- Entering information into a chat implies “lawful disclosure.”
- Users typically provide personal data to obtain an answer (hardly anyone inputs personal data purely for fun), which aligns with the purpose and operating scope of the AI application, satisfying “reasonable scope.”
- Not opting out means “the individual has not explicitly refused.”
- The remaining task is for developers to introduce a “secondary confirmation” prompt whenever sensitive/high-impact data is detected, satisfying the requirement to “obtain statutory consent.”
Naturally, contextual readings of this clause confirm that using recorded conversation audio to train voice models or using captured faces to generate video avatar bases remains prohibited without explicit authorization.
The core intent of this rule is to protect model providers from being cornered whenever they inevitably encounter fringe personal data that defies conventional anonymization pipelines.
3. Pre-training Copyright Isn’t Directly Addressed, but Litigation Rules Are Clarified
While the Opinions bypass the core copyright debates surrounding data scraping and pre-training, they lay down clear rules for litigation during the inference phase:
Where an AI developer presents a non-infringement defense, the court shall order them to provide evidence including training data sources, training process logs, model operating mechanisms, and scientific rationales.
Historically, when accused of infringement, developers often argued (or made excuses): “The model merely learns statistical patterns; it does not retrieve and copy images directly from a database.”
This argument is technically sound and accurately describes the core mechanism of generative models. But it is not sufficient.
This theoretical explanation alone cannot prove that a specific model run or output did not infringe upon a specific work.
Did the model overfit and memorize a particular piece? Was a fine-tuned adapter (e.g., LoRA) trained specifically on that copyrighted character? Were external assets pulled during runtime (e.g., Image-to-Image workflows)?
All of this must be judged against the specific execution environment.
“Our system generates outputs algorithmically” does not automatically mean “Our outputs do not infringe copyright.”
Conversely, plaintiffs cannot file lawsuits based on mere speculation:
Where a rights holder claims that an AI provider has infringed their copyright via algorithmic technology, they must provide corresponding evidence.
This means plaintiffs must first present sufficient evidence proving their ownership and the actual occurrence of the alleged infringement. You cannot simply claim: “You trained on massive amounts of text and images, so my work must be in there,” and force the defendant to prove their innocence.
This framework strengthens the developer’s burden of technical production without going as far as presuming infringement simply because an algorithm cannot be exhaustively deciphered.
In practice, however, defining what constitutes “sufficient evidence of infringement” without turning lawsuits into fishing expeditions designed to extract proprietary trade secrets will give judges plenty of headaches.
Furthermore, not every “developer” is a “full-stack model developer.”
It is reasonable to require the party holding the technical documentation to provide it; otherwise, the plaintiff cannot inspect the model’s internals, and the court cannot ascertain the facts.
Yet real-world architectures complicate this.
A modern AI application might run a third-party foundation model, stack proprietary or open-source fine-tuned adapters, integrate a private vector database for Retrieval-Augmented Generation (RAG), and steer outputs via system prompts.
The application developer may only possess the RAG data and API invocation logs, remaining completely oblivious to what the foundational model ingested or its exact internal weightings. (Even if regulatory filings exist, filing does not grant access to a third-party supplier’s proprietary weights or full dataset.)
Courts will need to first dissect who built what and pinpoint where the alleged infringement occurred before ordering specific documents to be submitted.
Developers cannot simply be compelled to surrender training logs they never possessed in the first place—especially since Article 17 warns that courts may make adverse inferences if a party refuses to submit materials without justification.
What isn’t there isn’t there; technical reality must prevail.
4. Open-Source Software Used for Illegal Acts Is No Longer Painted with a Broad Brush
Article 13 suggests granting appropriate liability exemptions to open-source software developers and providers, taking into account license agreements, security measures, and disclosures.
It specifies a concrete safe harbor:
Where an open-source developer or provider offers modular code free of charge and publicly discloses its functions and security risks, and another party’s subsequent use results in infringement, the court may determine that the module developer or provider bears no tort liability.
This is fantastic news!
Especially for those of us who maintain open-source repositories.
The vast majority of open-source components are released for legitimate utility. Technology is neutral; liability should depend on what the downstream user does with it.
A speech synthesis model can be used to generate multilingual voice tracks for global communication, or it can be abused for impersonation fraud. An image model can restore vintage photographs, or it can be used to generate counterfeit content.
One cannot hold the original author liable for every downstream misuse simply because a tool can be abused. Once code is cloned and modified locally, the original author has no visibility over who is executing it, let alone the power to shut it down remotely.
Unfortunately, the industry has seen far too many cases where open-source authors were unfairly penalized.
The Opinions also provide a necessary safety net for the booming wave of “Vibe Coding” tools—where even the creators themselves might not fully understand every edge case their code can produce.
Still, this clause should not be mechanically interpreted as:
“Just push to GitHub and claim instant immunity.”
The rule refers specifically to “open-source components.” If a maintainer deliberately packages components into a turnkey infringement tool, runs an operational service around it, drives traffic toward infringing use-cases, or suggests actionable infringing methods in the README, liability will still be assessed based on those specific actions.
5. AI Infringement Requires Digging into the Underlying Process
Article 18 states that when examining AI-generated content as evidence of infringement, courts must evaluate the influence of user prompts, degree of similarity, reproducibility across iterative tests, model training data, algorithmic design, and filtering mechanisms.
I could not agree more with this approach.
When adjudicating AI infringement, the generation process itself must be the focus of judicial review.
For instance, two users might both generate an image strikingly similar to a protected gaming character, but through entirely different workflows:
- User A simply typed a generic character description.
- User B entered an exhaustive, multi-paragraph prompt detailing every iconic design element of that specific character (forcing the probability space to converge).
- User C explicitly instructed the prompt to replicate that trademarked character.
- User D uploaded the original artwork via an Image-to-Image pipeline, requesting to keep the character intact while only swapping the background.
While the resulting outputs may all meet the threshold of being “substantially similar,” who provided the infringing features and who controlled the generative direction fundamentally alters the allocation of liability across the developer, platform, and user.
When advanced features like Image-to-Image, ControlNet, or custom LoRA adapters enter the mix, evaluating the final image in isolation makes it impossible to determine where the infringement originated.
Retaining user generation logs will become vital for platforms.
6. Everyone Is the Primary Responsible Party for Their AI Output
Finally, Article 19 explicitly addresses the use of AI in drafting litigation documents, case research briefs, and legal filings.
If AI is used to draft court submissions, the filer must verify the authenticity and accuracy of cited laws, judicial interpretations, and case precedents prior to filing. Furthermore, the filer must disclose the extent of AI assistance and assume legal responsibility accordingly.
A very welcome rule.
Note that this restriction applies to “litigation participants” (诉讼参与人), meaning it binds not only licensed attorneys, but also pro se litigants representing themselves.
If an AI hallucinates a non-existent statute, attaches a fabricated case docket number, wraps it in the most “blunt, punchy, aggressive, and authoritative-sounding” legal rhetoric, and hands it straight to the judge—you are looking at direct sanctions.
Users must exercise vigilance, cross-check model outputs, or rely on more capable models.
That being said, how the “extent of AI assistance” should be disclosed in practice needs further operational refinement.
Drafting an entire complaint from scratch via an LLM is vastly different from using AI merely to polish phrasing or catch typos. Disclosure formats should genuinely help the court assess the document’s reliability, rather than adding redundant procedural bureaucracy.
After all, AI has already become ubiquitous.
Before long, everyone will be using it.
Who adds a disclaimer saying, “This document was prepared using Microsoft Word”?
