On September 7, 2026, the Supreme People's Court issued《Opinions on the Lawful Adjudication of Cases Involving Artificial Intelligence Disputes》This document, consisting of 24 articles, addresses multiple areas including personality rights and interests, model training, intellectual property, technology contracts, and litigation evidence.
Having recently read this document, what I focus on most is its attitude toward innovation: the Opinions explicitly propose respecting the laws of scientific and technological innovation and the development practices of the artificial intelligence industry, balancing rights protection and industrial development with an inclusive and prudent approach, and fostering an environment that "encourages exploration and tolerates failureenvironment.
This is a positive signal for AI entrepreneurs. Technology is still being explored, products are constantly iterating, and many things simply cannot be guaranteed to succeed at the project initiation stage. The judiciary's willingness to take such uncertainty seriously helps give enterprises more confidence to experiment.
However, from the perspective of commercial dispute resolution, I am more concerned with how this signal provides guidance in specific cases.
When a project fails to meet expectations, how does an enterprise prove that it has made reasonable efforts? When generated content is accused of infringement, how does a developer explain the data sources and training process? When the parties each hold to their own account, on what basis does a judge reconstruct the facts? Guidance on responding to these questions is provided in these Opinions——
The judiciary preserves space for innovation, while also requiring enterprises to clearly explain and prove the key processes within their control. For startup companies, R&D, data, and compliance records are worth managing as important business assets from the very beginning.
I. Technical failure is permitted, but "reasonable efforts" require factual support
Article 15 of the Opinions requires that, when adjudicating disputes over artificial intelligence technology development, transfer, licensing, consulting, and service contracts, liability for breach of contract shall be determined in accordance with law based on the contract terms, with full consideration of circumstances such as the characteristics of R&D and whether the technology developer has made reasonable efforts.
In this sentence, “reasonable efforts” warrants attention, and “as agreed in the contract” likewise cannot be overlooked.
Imagine an AI company developing a defect-recognition system for a factory. After months of investment, the recognition performance still falls short of expectations, and the client demands a refund and compensation. The development team feels aggrieved: “We have been making changes all along; we truly encountered technical difficulties.”
Such an explanation is meaningful, but the court also needs to know: did the parties agree to jointly explore a technology yet to be validated, or to deliver a system meeting clear standards? Were the test samples, operating environment and acceptance methods agreed upon? How are technical risks to be allocated?
If the enterprise expressly promised a delivery result under specified conditions, it cannot automatically be exempted from liability for breach merely because “research and development is difficult” or “the team worked hard.” Whether liability is borne, and to what extent, must still be determined in light of the agreement, the performance circumstances and legal provisions.
Therefore, protection should begin at the time of contracting. Which functions are already mature, which indicators require further validation, what data and cooperation the counterparty should provide, and how schedule and fees should be adjusted after requirements change—all should be clarified as far as possible.
For projects with high uncertainty, consideration may also be given to conducting small-scale validation first before deciding whether to proceed to the next stage; at the same time, it should be agreed how fees are settled and how existing results are handled if stage objectives are not met. Discussing costs clearly in advance is often more conducive to the cooperation truly getting started.
The contract delineates the boundaries of liability, while process records help determine what the enterprise actually accomplished.
For another example, if the client added new defect categories, did the parties confirm the adjustment? If a certain round of testing performed poorly, what causes did the team analyze, and what improvements did it attempt? After discovering a major obstacle, did it promptly inform the client and discuss alternatives? Can the specific version delivered be matched to the test results at that time?
Modification records in version management systems such as Git, raw test data, issue lists, requirement confirmations, and phased delivery materials, may all provide a basis for these issues.
However, a large number of commit records and long overtime hours do not directly prove "reasonable efforts." What is more persuasive is that these inputs were indeed directed toward the agreed objectives, that the technical choices had a basis, and that upon discovering problems, handling appropriate to the conditions at the time was adopted. In addition, based on my experience representing several complex software development contract disputes, apart from the initial agreement, any requirement changes that arise in the course of performance should be confirmed in the manner agreed upon, to avoid possible subsequent disputes.
For entrepreneurs, to secure judicial understanding of technical failure, it is necessary to let the judge see the real R&D process. Technical setbacks can be explained, and only then is it more likely that the risk allocation in the contract will be accurately applied.
II. A model can be a black box, but a company cannot be a black box
Contract disputes require reconstructing the R&D process. In several infringement disputes this year, courts repeatedly required enterprises to further explain: how the model was formed, and how the disputed content was generated.
Article 12 of the Opinions makes clear that in disputes where AI-generated content is sued for copyright infringement, if the developer raises a non-infringement defense, it shall, as required by the court, providethe sources of training data, records of the training process, the model's operating mode, and the basis in scientific theoryand other materials in support.
In its answers to reporters' questions, the Supreme People's Court explained that the rights holder still bears the burden of adducing preliminary facts, such as that the disputed content was generated by the relevant AI and constitutes substantial similarity to its work. At the same time, developers who possess internal technical materials also need to provide a basis for their own defenses.
For enterprises, this means that "we did not copy" needs factual support.
Who provided the data, through what channels was it obtained, and what is the basis for its use? Does the license obtained cover the actual use? What processing did the data undergo, and for which training version was it used? What preventive and handling measures were taken with respect to potentially infringing content?
These questions cannot necessarily be answered by a procurement contract alone. A supplier's claim of “data compliance” still needs to be assessed in light of authorization documents, the actual content delivered, and the specific manner of use.
One boundary in particular requires attention here: the Supreme People's Court has expressly stated that the Opinions do not yet provide for how to characterize the use of another person's works without permission to train large models. Enterprises cannot infer from this that “training use has already obtained general permission”; specific projects still need to be analyzed in light of current law and the facts of use.
The point of record-keeping is to preserve a factual basis for this kind of analysis.
I am willing to compare it to an aircraft's black box: it cannot guarantee that a flight will never encounter problems, but after a problem occurs, it can help people know what happened at the time. AI enterprises preserve key processes for the same reason—so that disputes have a basis that can be verified.
There is no need to set the goal as fully explaining every model output. Enterprises can first manage well the links they are able to control: how data enters, how versions change, how risks are assessed, and how complaints are handled.
Teams that use external model interfaces to develop applications can start with supplier terms, model versions, the sources of knowledge bases they connect on their own, and call records; teams that train or fine-tune models themselves should preserve the corresponding data processing and training records. The specific scope should match the enterprise's role, business risks, and actual capacity for control.
Although the technology is complex, an enterprise's explanation of its own conduct should be as clear as possible.
III. Compliance and Evidence Engineering
The preceding two questions ultimately come down to the same thing: the existence of records does not mean they are already sufficient to prove the enterprise's assertions.
Article 18 of the Opinions requires focused review of electronic data in the processes of generation, collection, storage, and transmission forauthenticity and integrityFor blockchain evidence preservation, it is also necessary to reviewAuthenticity of data before it is recorded on-chainas well asthe reliability of the platform。
Therefore, the fact that a document has been preserved as evidence does not mean that the matters recorded in the document are necessarily true.
In judicial practice, when faced with project disputes, courts usually require the provision of original results and testing conditions, and cross-verification with delivery records, before it is easier to determine whether they conform to the contract. Therefore, records should also truthfully present relevant failed tests, anomalies and corrections. They can explain how problems were discovered and why solutions were adjusted, and sometimes they are precisely important bases for determining whether an enterprise has exercised reasonable efforts.
From this perspective, R&D management, data compliance and litigation preparation can in fact be accomplished within the same set of daily work. R&D records can prove contract performance, data source materials can support infringement defenses, and operation logs may also help identify the causes of anomalies and the scope of liability.
This is what I understand as "evidence engineering": centering on key facts around which disputes may arise in the future, enabling daily records to form verifiable and mutually corroborating connections.
Small teams can also start from a few nodes. At project initiation, implement technical objectives and risk allocation in the contract; when accessing data, preserve the source, license and processing basis; at delivery, correspond requirements, versions, tests and customer feedback; after discovering anomalies or receiving complaints, promptly record the handling process and preserve relevant materials.
At the same time, it is necessary to clarify who preserves them, where they are stored, who can modify them, and how they are backed up, so as to avoid key materials becoming irretrievable after personnel departures or system updates. The scope, duration and access permissions for retention should also take into account both personal information protection and trade secrets.
The value of experts participating in advance lies in judging together with business and technical teams: which facts will affect liability, how the contract should express these facts, and whether existing systems can leave corresponding bases. Enterprises need not wait until they receive a complaint before translating the technical process into issues that the law can adjudicate for the first time.
Good compliance should help enterprises smoothly advance their business, and also ensure that key business conduct can be verified when needed.
This Opinion reflects the judiciary's attitude of supporting innovation, and also provides guidance for enterprises to safeguard their rights in accordance with the law on specific issues such as contract performance, tort liability and evidence review.
This kind of protection benefits entrepreneurs who are genuinely committed: when a project encounters difficulties, R&D records can help clarify the status of performance; when facing infringement allegations, data and technical materials can provide a basis for defense; and when entering into new cooperation, clear responsibility arrangements also help both parties build trust.
AI entrepreneurship is still worth pursuing boldly. Enterprises can explore the future while clearly documenting the path they have already taken, so that genuine investment, prudent judgment, and responsible action become the confidence to keep moving forward.
