Does AI-generated content count as a work? Who owns it? Who is liable when it infringes?

After two years of argument, judicial practice and published prosecutorial analysis are moving from blanket answers to layered ones.

Originality: two standards

A simplistic view took hold early on: if a tool was involved, originality is negated. That is being corrected.

The emerging approach uses two standards together.

Process: was there continuous intellectual input? Did the person conceive, adjust, select and iterate — rather than press a button once?

Result: was there substantive expressive transformation? Does the output contain identifiable expression attributable to the author, beyond what pre-existed?

The accompanying review method is described as a three-stage slice: front-end conception, mid-stage generation, back-end orchestration. It converts an abstract originality judgment into evidence that can be checked.

Infringement: three layers of proof

In disputes, the allocation of proof matters more than the doctrine.

Input stage (training). The plaintiff establishes ownership and substantial similarity between output and prior work. A defendant claiming fair use must explain data sources and usage.

Generation stage (service provision). The provider must explain how output was produced, supply prompt logs and generation records, and demonstrate that due care was taken and takedown requests handled promptly.

Output stage (user use). Beyond ownership and similarity, the plaintiff supplies indirect evidence such as commercial use or continued infringement after notice. The defendant must show absence of knowledge.

One rule carries real weight: if a service provider refuses to produce prompts and training logs, burden shifting can apply, and the provider can be held jointly liable with the direct infringer.

In effect, the "black box" becomes a liability rather than a shield. Whoever controls the data carries the evidentiary duty.

Open source: where liability stops

Most Chinese foundation models ship as open source. Applying downstream risk directly to open-source developers without regard to control would damage the ecosystem.

Judicial guidance (Article 13) establishes an exemption: where an open-source developer or provider supplies code modules free of charge for AI R&D, publicly documents functionality and safety risks, and a third party's use of those modules causes infringement, a court may find the developer not liable.

Practical steps for teams

First, keep process records. Prompts, revision history, selection rationale — these are the direct evidence of intellectual input in a dispute.

Second, maintain a source ledger. Training data, reference images, fonts, audio: record the licensing status of each.

Third, review high-risk outputs. Especially anything involving celebrity likeness, known IP or a distinctive artistic style.

Fourth, respond to notices fast. The timing of takedown and reply directly affects liability findings.

The rules are still forming and courts will differ at the margins. The direction, though, is consistent: the law does not deny the value of AI-assisted creation, and it does not excuse users from due care because "AI made it." Whoever contributes the intellect and carries the duty of care gets the rights and the responsibility.