Summary: When AI-written code has a defect, the development company that signed your contract is still responsible, not the AI tool. What you should review is the contract itself: its type (請負 or 準委任), acceptance criteria, review and test records, rights to the source code, and how changes to requirements are handled.
Contents
- Who is responsible when AI-written code has a defect?
- How do 請負 and 準委任 contracts differ when something breaks?
- What is 契約不適合責任, and what if the defect comes from your own instructions?
- Which clauses should a contract add when the vendor uses AI?
- What does VAON record and keep on real projects?
- What can a contract not fix?
- FAQ
1. Who is responsible when AI-written code has a defect?
The development company that signed your contract is responsible. An AI tool is not a party to the contract, so nobody can point at Claude Code or GitHub Copilot and call it the tool's fault. The liability provisions of Japan's Civil Code (民法) do not ask whether a person or a machine typed the code. They ask whether what was delivered matches the contract.
One plain statement, once: this article is general information, not legal advice. Have a lawyer read your actual contract.
So what does AI change? Not who is liable. It changes what you need to be able to see: who read this code before release, whether there is test evidence, and which AI tools touched your data. Those three belong on paper, not in a promise.
2. How do 請負 and 準委任 contracts differ when something breaks?
Under a 請負 contract (a contract to complete a work product), you can demand a fix after delivery. Under a 準委任 contract (a mandate paid for effort), the vendor does not promise completion, so the route to a remedy is very different.
| 請負 | 準委任 (effort-based type) | |
|---|---|---|
| What the vendor promises | Completing the work (Art. 632) | Performing the work with the care of a prudent manager (Arts. 644, 656) |
| Defect after delivery | 契約不適合責任: demand repair, price reduction, damages, cancellation | No duty to complete. Usually you can claim only if the vendor lacked due care or breached the contract (Art. 415) |
| Fits when | Requirements are clear, scope is fixed | Requirements still move, work runs in short cycles |
| Main risk for you | Vague requirements make "complete" vague too | You pay for effort and may not get what you wanted |
There is a third form: 準委任 paid on delivered results (Art. 648-2). How defect liability applies to it is debated, so this is a point for your lawyer. And the label on the contract does not settle everything. What the parties actually agreed and did is what gets examined.
3. What is 契約不適合責任, and what if the defect comes from your own instructions?
契約不適合責任 (liability for non-conformity with the contract) is the vendor's responsibility when what it delivers does not match the contract in type or quality. For a 請負 contract you can demand supplementary performance, a price reduction, damages, or cancellation (Arts. 562 to 564, applied through Art. 559 to paid contracts). You must notify the vendor within one year of learning of the non-conformity (Art. 637). That limit does not apply if the vendor knew at delivery, or was unaware through gross negligence.
The part few people read is Article 636. If the non-conformity comes from materials you supplied or instructions you gave, you cannot use those remedies, unless the vendor knew the instruction was unsuitable and did not say so. In short: if the vendor did exactly what you said and what you said was wrong, it is no longer a product defect.
In an AI project this makes written requirements more important. AI executes what it is given very quickly. If the description is wrong, you receive the wrong thing faster. The contract should carry concrete acceptance criteria, and the vendor should have a duty to speak up when a requirement looks problematic.
4. Which clauses should a contract add when the vendor uses AI?
A contract with an AI-using vendor should add five groups of clauses: disclosure of AI use, review and test records, rights to the source code, data entered into AI tools, and change control.
| Clause | What to write | Why |
|---|---|---|
| Disclosure of AI use | The kind of AI tool, which stage it is used for (code generation, test generation, code reading), and a duty to tell you when that changes | You need to know who and what touches your product |
| Review and test records | Each release has a second person reading the code, test scenarios, and a checklist. Records are kept and you can see them | When a defect appears, records show where it slipped through |
| Rights to the code | Who owns delivered code; a transfer clause that names the rights in Arts. 27 and 28 of the Copyright Act; a duty to tell you about externally licensed code | See below |
| Data entered into AI | No code or data of yours goes into AI tools without your written permission | Control over data stays with you |
| Change control | Out-of-scope work: a change request, a written quote with schedule impact, your approval before work starts | Ends the "defect or new requirement" argument |
On rights to code: Japan's Agency for Cultural Affairs publishes "AIと著作権に関する考え方について" (March 15, 2024, prepared by a subcommittee of the Council for Cultural Affairs). It says whether AI output counts as a copyrighted work is judged case by case, based on the human's creative contribution, such as how concrete the instructions were or what a person added afterward. So do not assume AI-generated code has clear copyright, and the more specific the transfer clause, the safer for both sides. Article 61, paragraph 2 of the Copyright Act also presumes that rights under Arts. 27 and 28 stay with the transferor unless the transfer contract names them specifically.
Which clauses you need depends on the project. A small brochure site does not need five detailed lines the way an internal management system does.
5. What does VAON record and keep on real projects?
VAON keeps review and test records on every project, and customers can see them. "Who checks code that AI wrote?" was one of the three questions customers asked us most in 2026, so we answer with a process rather than a general promise.
VAON engineers use Claude Code and GitHub Copilot daily. Every change goes through seven steps: plan, challenge by a second person, confirm, build (AI assists, a person checks), cross-check and team lead approval, test in a separate environment, and release with notes and a tag. The main branch is locked, so nothing merges without a review.
On data, VAON does not put customer code or data into AI tools without permission. When a customer has not given it, the AI review step does not run; only the automated gates and a human reader remain. That is slower, and a cost we accept.
On requirements, VAON fixes them in writing before building and works in short slices of one to two weeks that produce something running. Out-of-scope work follows the change process above: no approval from you means no work and no charge. A project with no specification starts with a Spec Lock Phase (仕様確定フェーズ), and you may stop after it. More on this: how to spot a vendor with no surprise costs.
Specific warranty terms and liability limits are discussed project by project. We have no standard figure to publish here.
6. What can a contract not fix?
A contract does not replace quality. However tight the wording, a defect that slips out still costs you time.
Three more limits. First, a contract does not turn a vague requirement into a clear one: if nobody has written down what the system must do, acceptance can still be disputed. Second, review records are only worth something if they are real, and you need the right to see them, not just a promise that they exist. Third, this article relies on statutes read directly on e-Gov; case law and interpretation can differ case by case, so for a high-value contract, have a lawyer read the final draft.
One case where this is not a fit: a very small, short, low-risk project. Drafting all five groups of clauses may cost more than it protects.
7. FAQ
Can a vendor disclaim liability because "AI wrote it"? There is no basis for that in the Civil Code, which does not distinguish between a person and AI writing the code. The vendor is responsible for what it delivers under the contract. A contract may still contain a limitation of liability, so read that section carefully before signing.
Should I choose 請負 or 準委任 for a project that uses AI? It depends on how clear the requirements are. With fixed requirements and scope, 請負 gives you a clearer remedy. With requirements still moving, short-cycle 準委任 fits better. Using AI does not change that choice; it only means you also need review and test records.
Do I need to name specific AI tools in the contract? Name the kind of tool, the stage it is used for, and a duty to notify you of changes, rather than version names, because tools change fast. What matters is that you know where your data goes and can object.
Do I own code that AI generated? Whether AI-generated code is protected by copyright is judged case by case on the human's creative contribution. So the contract should have a clear transfer clause that names the rights in Arts. 27 and 28. Ask a lawyer for the specifics.
How can I tell whether a vendor really reviews AI-written code? Ask to see the records: pull requests with a named approver, test scenarios, and a checklist for each release. A vendor that does this can show them immediately. At VAON these are kept on every project and customers can see them.
Does your current development contract say anything about AI? Mark the rows in the table in section 4 that your contract is missing, then bring them to a free 60-minute consultation with VAON's CEO. No documents needed, no obligation. Book a free 60-minute consultation
Related: 12 checks before outsourcing AI-driven development · Technical limitations vendors tend to hide · Checking a vendor against the AI Guidelines for Business
Sources
- Civil Code (民法), e-Gov Law Search, read Oct 17, 2026: https://laws.e-gov.go.jp/law/129AC0000000089
- Copyright Act (著作権法), Art. 61, e-Gov Law Search, read Oct 17, 2026: https://laws.e-gov.go.jp/law/345AC0000000048
- Agency for Cultural Affairs, "AIと著作権に関する考え方について" (Mar 15, 2024): https://www.bunka.go.jp/seisaku/chosakuken/aiandcopyright.html
Author: Đặng Văn Luân, Founder & CEO, VAON. HEDSPI graduate (Hanoi University of Science and Technology). Worked at FPT Software, spent five years at Digital Plus in Tokyo on a system with 10 million users, then eight years as COO of a 120-person IT outsourcing company, building its ISO 9001 and ISO 27001 management system. 15 years in the industry.
