How AI Teams Can Prepare for China’s Copyright Policy Changes

China’s latest copyright-planning notice is not a compliance checklist for every model developer. It is still an important operating signal. The National Copyright Administration circulated its 15th Five-Year copyright plan on September 7, 2026, after issuing it on August 31. The plan places copyright services, enforcement, international cooperation and new technology on a shared policy agenda. For an AI team, that makes a familiar engineering task—knowing where content came from—part of a broader business readiness problem.

The useful response is neither to assume that every use of data is prohibited nor to wait for a final rule that answers every training-data question. Instead, teams can make their current decisions legible: record what they obtained, under which terms, for which use, who approved it, and what happens when someone raises a credible complaint. That evidence will be useful even if future rules take a different path than expected.

This is not legal advice. It is a practical framework for product, procurement, data and security leaders who need to turn a changing policy environment into work that can be inspected and improved.

Separate what is known from what remains open

The first discipline is to avoid turning broad policy language into a claim of certainty. The copyright plan is real policy direction, and the National Copyright Administration had already described AI and other emerging fields as areas requiring stronger copyright-system design. But the plan notice does not provide a universal answer to whether a particular corpus may be used for model training, how every output should be treated, or which contract will control a dispute.

The Supreme People’s Court’s September 7 explanation of its AI-dispute opinion is especially useful here. It describes how courts may approach claims involving AI-generated content: a rights holder must first support claims that the disputed content came from an AI service and is substantially similar to the protected work. Where an AI developer relies on a non-infringement defence, the explanation says training-data sources, training processes and operating methods can become relevant evidence.

The same explanation says that two foundational questions were left unresolved: the copyrightability of AI-generated content and the legal characterization of using copyrighted works without permission to train a large model. Those omissions are not a reason to ignore the guidance. They are a reason to keep an uncertainty register. A team should label a decision as supported by a contract, an applicable rule, a documented technical control or an unresolved assumption. Treating all four as the same thing is how avoidable risk becomes invisible.

Build a data-evidence map before a dispute forces one

A data inventory should answer more than “which dataset did we use?” Start with the asset or dataset, supplier, acquisition date, governing terms, geographic and product restrictions, and the intended technical use. Then capture the transformation chain: filtering, annotation, deduplication, synthetic augmentation, access controls and the model or evaluation for which the material was used. Keep a versioned record, because a later snapshot may not reproduce what the team actually trained on.

This is not bureaucracy for its own sake. A rights complaint often begins with a narrow question: where did this image, document, voice sample or code fragment come from? A system that can point to a source record, approval path and retention decision can investigate that question quickly. A system that only has a large unlabeled archive must reconstruct its own history under pressure.

The map should also expose gaps. Publicly accessible content, partner-supplied content, licensed datasets and internally created material are not interchangeable categories. Each has different evidence, conditions and failure modes. If a source lacks clear terms or provenance, label it as such rather than silently upgrading it to “cleared.” That allows a team to constrain its use, seek a replacement or make a documented risk decision.

Ask AI vendors questions that lead to usable answers

Buying a model API or embedding a third-party tool does not transfer all operational responsibility. The court guidance focuses attention on control, the role each party plays, the source of training data and measures taken to reduce harm. Those are practical procurement topics, not only litigation topics.

A useful vendor review asks for specific artifacts. Which use cases and content classes are covered by the service terms? What information can the vendor provide about the origin and governance of its training or retrieval data? How does it receive, assess and respond to rights complaints? Which logging is available to the customer? What controls exist for uploaded customer material, fine-tuning, retrieval indexes and generated output?

Avoid accepting vague assurances such as “responsible AI” as a substitute for a response process. A vendor may reasonably protect confidential technical details, but a customer can still ask for contact points, escalation times, notices, contractual commitments and a clear account of shared responsibilities. Record the answer with the procurement decision so a later team does not have to rediscover it.

Treat output controls and complaint handling as product features

Copyright risk does not stop at training. Product teams should define how users report suspected copying, what information they need to provide, how the report is triaged and when potentially harmful output is restricted. The Supreme People’s Court explanation notes factors such as the technology and business model, a party’s role in generation, training-data inputs, precautions and profit when considering responsibility. Those factors point to a simple product question: can the service explain what happened and take a proportionate action?

For a consumer product, that may mean a visible reporting route, a case identifier and a way to stop repeated generation from an abusive prompt pattern. For an enterprise system, it may also mean workspace-level audit logs, administrator controls, retention settings and a documented escalation path. The appropriate control depends on the product. What should not vary is the ability to preserve evidence without exposing private customer data unnecessarily.

Teams should test the process with a tabletop exercise. Choose a hypothetical complaint about a generated image or a retrieved passage. Measure how long it takes to identify the account, relevant logs, model version, source records and available actions. The exercise will often reveal that data, legal, support and engineering have incompatible identifiers or retention windows. Finding that before a real complaint is the point.

Make AI-assisted internal work reviewable

The new court guidance also speaks directly to people using AI to prepare materials for litigation: users remain responsible for checking the accuracy of AI-assisted submissions and for explaining that assistance where required. The broader lesson applies beyond court filings. AI output should not become a source merely because it is fluent.

Create an internal rule for consequential documents: the drafter identifies factual claims, preserves primary sources, records the model or tool used where relevant, and assigns a human reviewer with authority to correct or reject the result. This is particularly important for policy summaries, product claims, rights analyses and customer communications. A citation that the model invented, or a policy rule that changed after the draft was written, can create a much larger problem than an ordinary typo.

The goal is not to prohibit AI assistance. It is to preserve the distinction between an assistive draft and a verified statement. That distinction helps teams use automation without pretending that automated text has independently established a fact.

Use a recurring readiness review

A monthly or quarterly review can turn this framework into normal operations. Review new data sources, material vendor changes, open complaints, incident findings, logging coverage and unresolved legal assumptions. Track a small set of evidence-based measures: the proportion of active datasets with documented terms, time to assemble a complaint record, percentage of high-risk vendors with an escalation contact, and the age of unresolved provenance gaps.

Do not use the scorecard to claim legal compliance where the law is unsettled. Its purpose is more modest and more useful: show whether the organization can explain its current practices, correct a known weakness and make the next decision with better information.

China’s policy direction and court guidance make that capability increasingly valuable. They do not remove the difficult questions around AI training and ownership. They make it harder to justify having no answer at all when a customer, creator, regulator or court asks how a system was built and controlled.