Outsourcing Software Development
AI-Generated Code Vendor Accountability: 5 Clauses
Table of Contents
- Quick answer: vendor AI code accountability
- Why “Does Your Vendor Use AI?” Is the Wrong Question
- Provenance Is a Record of a Decision, Not a Property of the Code
- Question One: Disclosure
- Question Two: The Review Standard
- Question Three: License and Provenance
- Question Four: IP Assignability
- Question Five: Warranty and Liability
- Two Fixes That Do Not Work
- What AI-Generated Code Vendor Accountability Looks Like in Practice
- Ask the Five Questions Before the Next Statement of Work
Your vendor’s AI-generated code is only as accountable as the agreement that governs it. Five contract questions decide whether you can hold anyone to account: what the vendor discloses, what review the code passes, what licenses it carries, who owns it, and who pays when it fails. Most development agreements answer none of them.
Picture a quarter-end close at a 200-person distributor. A pricing module your contractor shipped in the spring starts rounding wrong on one tax path. Your engineers open the history and find a commit, an author name, a timestamp. What the history will not give them is which lines a model drafted, who read them, or what “reviewed” was supposed to mean. Nobody hid anything. The contract never asked anyone to write it down.
The gap is in the drafting, and you can close it before your next statement of work. AI-generated code vendor accountability is a records problem, and this post walks through the five questions that build the record, then hands you a one-page ask to send a vendor this week.
Quick answer: vendor AI code accountability
- A vendor answers for AI-generated code only if the agreement requires five written answers: disclosure, review standard, license provenance, IP assignment, and warranty with indemnity.
- Banning AI tools backfires, because a ban hides the disclosure rather than the AI.
- Scanners find flaws but cannot record who decided the code was acceptable.
- A vendor that answers all five in writing has already passed the evaluation.
Five questions a development agreement has to answer about code a model helped write
Why “Does Your Vendor Use AI?” Is the Wrong Question
Yes, your vendor uses AI. Competent ones do, and a buyer who insists on zero AI is asking to pay more for slower delivery. Ask something narrower instead. Can your agreement tell you what the model wrote and who approved it?
Roughly Half of What Ships Is Model-Authored
Veracode’s 2026 GenAI Code Security Report found that in organizations that have adopted AI coding tools, AI now authors roughly half of all committed code. Read the scope carefully. The figure covers adopters, not every company. And Veracode sells application security testing, so treat the report as first-party research from a publisher with a commercial interest in the findings, not as a neutral industry average.
If your vendor is a competent shop, assume it sits on the adopter side of that line. A contract written as though humans typed every line describes a delivery process your vendor probably doesn’t run.
It Compiles, It Reads Fine, and the Flaw Is Still There
Model output looks right, and that is the harder problem. The Veracode data shows modern models generate syntactically correct code nearly 100% of the time. The code compiles, follows your conventions, and reads like a competent colleague wrote it. A skim review has nothing to snag on.
Our argument, not Veracode’s: that fluency is exactly why a skim misses what’s inside. The defect, when there is one, looks like everything around it. Which makes this less a question of bad AI code than of missing records. A flaw that survives review means nobody can show who looked, how closely, or against what standard.
A model working inside your vendor’s pipeline is one more layer, and your agreement does not mention it.
Provenance Is a Record of a Decision, Not a Property of the Code
Who decided this code was acceptable, and on what basis? Provenance is the answer to that question, and no scanner can detect it. A process has to produce it, and the agreement has to require the process.
Go back to the distributor’s rounding bug. Nobody there is evasive or careless. The record you need was never created, because nothing in the agreement made anyone create it. Everything after this point is about what your contract should make someone write down.
The Limits of Git History
Git tells you who committed a change, when, and what the diff was. It doesn’t tell you whether a model drafted the block, whether the person who committed it read it line by line, or what standard they held it to. Committer, author, and reviewer are three different roles, and a default repository history collapses them into one name.
Security numbers show why the gap matters. Veracode’s Fall 2026 update reports the average security pass rate rising from 56% to 62%, with the vulnerability rate falling from roughly 44% to about 38%. Progress, yes. But close to two in five generation tasks still produce vulnerable code. For perspective, a peer-reviewed evaluation of 2021-era GitHub Copilot by Pearce and coauthors found approximately 40% of 1,689 generated programs were vulnerable. Treat that one as a historical baseline only.
Who Decided This Was Acceptable
What you want is a small artifact naming a human, a standard, and a point in time. Open-source projects have used a version of this for years. The Developer Certificate of Origin asks each contributor to sign off that they have the right to submit what they’re submitting. It’s a one-line record, and it makes a person answerable.
Pull request approvals already come close. What’s missing is the contract term that says an approval means something specific. The five questions below supply it.
One note before they start. Nexa isn’t a law firm. This is how we answer these questions, and your counsel owns the wording of anything that goes into your agreement.
A repository records who committed code. A provenance record also shows who approved it and against what standard
Question One: Disclosure
Ask for tool-level disclosure, in writing, on request, covering which AI coding tools touch your codebase and which model provider sits behind each one. Nothing more than that is needed. A vendor AI disclosure clause fits in about two sentences.
A useful scope stays short. It covers tool names, the model provider behind each, whether your code or data leaves the vendor’s environment to reach a third-party service, and notice when the list changes. An illustrative sentence your counsel can adapt: “Vendor will identify in writing, within ten business days of Client’s request, each AI code-generation tool used on Client’s codebase and the model provider behind it.”
Don’t ask for per-asset prompt logs. They generate volume nobody reads, they slow the team that’s supposed to be shipping, and requesting them tells a good vendor you don’t know what you’re buying. You want a tool inventory you can audit, not an archive you’ll never open.
Do vendors have to volunteer any of this? Only if the agreement says so, or a law that applies to you does. Your counsel can say which. In a vendor relationship, you can make it a contract requirement.
Question Two: The Review Standard
Every vendor says its code is reviewed. Almost none will say what “reviewed” means, who does it, or what happens when the reviewer is also the person who prompted the model. A contract term that sets the AI code review standard answers all three.
What “Reviewed” Has to Mean in Writing
A workable standard is short. Every change that includes AI-generated code is read and approved by a named human engineer before merge. The approver is qualified in the language and the system. Approval is recorded in the repository, with tests attached. Written that way, mandatory human oversight becomes a term you can check.
Name the role, too. Many teams already assign a code owner whose sign-off a change needs, and GitHub’s CODEOWNERS mechanism enforces exactly that at merge time. Your agreement can require the vendor to maintain one for your repositories.
Test whether a standard is real by asking one question. Could someone be asked about the approval six months later? If the answer is no, you wrote an intention.
Where That Standard Usually Lives
Usually in the vendor’s internal engineering handbook, in a sales call, or nowhere. A handbook can change next quarter without telling you. A salesperson’s assurance doesn’t survive the salesperson. Only the contract holds still.
Moving the standard into the agreement costs the vendor almost nothing if they already follow it. If they don’t, you’ve learned that before the incident instead of after it.
Question Three: License and Provenance
A fragment of copyleft-licensed code sits inside a module your vendor shipped in March. Nobody noticed. Two years on, your acquirer’s diligence team finds it. That scenario is the reason AI code license provenance belongs in the agreement.
Training-Data-Derived Snippets
Models can reproduce fragments that resemble code they were trained on, and some of that code carries license obligations. The vendor can’t see this by reading the output, because the output looks like any other function. You can still require a process: scan generated code for license matches, use whatever code-reference or filtering features the tools offer, and set a written rule for what happens when a match turns up.
A Bill of Materials Has to Cover Generated Code
You’ve probably seen dependency lists. Formats like SPDX and CycloneDX exist so a software bill of materials can state what’s inside a build. Extend the ask so it covers dependencies with their licenses plus the scan results for generated code, delivered with each release.
The case for covering third-party code specifically comes from Veracode’s 2026 State of Software Security report, which the company’s Fall 2026 post cites: 66% of the most dangerous, long-lived vulnerabilities come from third-party code. The code you didn’t write is where unresolved exposure concentrates. An agreement that makes the vendor list what’s in the build is how you find out what you’re carrying.
A bill of materials that lists dependencies and generated-code scan results in one release artifact
Question Four: IP Assignability
Your agreement says the vendor assigns all rights in the deliverables. For the parts a model wrote with no meaningful human authorship, there may be no rights to assign. So who owns AI generated code a vendor delivers? You may own less than the contract implies.
An Assignment Clause Cannot Convey Rights That Never Arose
The U.S. Copyright Office’s January 2025 report, Copyright and Artificial Intelligence, Part 2: Copyrightability, states that copyright does not extend to purely AI-generated material and that protection requires human authorship. It adds that prompts alone don’t give a user sufficient control to count as the author of the output. Human authors keep copyright in their own perceptible contributions, including creative selection, coordination or arrangement of outputs and creative modifications. The Office also notes it may revisit the prompt question if technology gives users more control.
The step from that doctrine to your assignment clause is our own reasoning, not the Office’s finding. An assignment conveys what exists, and where nothing arose, nothing conveys. So AI-generated code copyright assignment is a real gap in the clause your CEO signs.
Ask for This Instead
Three things, in plain terms. First, assignment of the human-authored portions. Second, an unrestricted license to the AI-generated portions. Third, a specification of the human-contributed design work that is protectable: architecture, the selection and arrangement of components, hand-written business logic, and documentation.
That third item matters more than it looks. Architecture decision records and design documents are human authorship you can point to. They’re also the artifacts a vendor should be handing you anyway.
If you want to see how Nexa structures a delivery engagement around those artifacts, our services overview lays it out.
Question Five: Warranty and Liability
Don’t ask your vendor to warrant that code is “original.” Ask for a promise of “not knowingly infringing,” backed by an indemnity capped at a number the vendor can actually pay. A broader promise looks stronger and collects worse.
“Not Knowingly Infringing” Beats “Original”
A vendor who warrants “original” is either not using AI or not reading their own contract. A non-infringement warranty worded around knowledge is honest about what a vendor can know. Better still, tie the warranty to process, so the vendor warrants that it followed the disclosure, review, and license-scanning steps in questions one through three.
Now the warranty carries evidence. If the process was followed, the vendor has records. If it wasn’t, the breach is plain.
Cap the Indemnity, Then Carve It Out
Unlimited indemnity for AI-related IP claims is a promise no mid-market vendor can fund. Cap it at what the vendor could actually pay, and you get an indemnity you can collect. The third-party IP indemnification should exclude claims arising from your specifications, your supplied data, and your own modifications.
How rare is any of this? Stanford Law School’s CodeX published an analysis of AI vendor contracts, using TermScout’s data, that found only 33% of AI vendors provide indemnification for third-party IP claims, while 88% cap their own liability versus 81% in broader SaaS agreements. Scope matters here: those are AI product and SaaS contracts, not software development agreements. They show the warranty and indemnity gap is real and widespread. They don’t describe your vendor.
Who Pays When Neither Party Wrote the Line
Who is liable when AI generated code fails? The party that accepted it. Your vendor chose the tool, set the process, and approved the output into your repository. Models don’t sign contracts or carry insurance. Someone made the acceptance decision, and the agreement should say it was the vendor.
A warranty and indemnity clause tied to the review standard matters for that reason. Liability follows the decision, and the decision has to be recorded for the clause to work.
A capped indemnity sized to what the vendor can pay, with named carve-outs
Two Fixes That Do Not Work
Two responses sound sensible and fail. One bans AI tooling in the contract, the other buys another scanner, and both leave the provenance question where it was.
Banning AI Tooling in the Contract
An anti-AI clause is unenforceable in practice. You can’t audit what tools an engineer’s editor calls. It also destroys the delivery velocity you’re paying for. Worst, it converts disclosed AI use into undisclosed AI use, because the vendor who uses AI anyway now has a reason to hide it.
A ban doesn’t remove AI from your codebase. It removes your ability to ask about it.
Buying Another Scanner
Scanners are useful, and we run them. But a scanner only reports what it found, never who decided the finding was acceptable.
Waiting for better models doesn’t solve it either. Veracode’s Fall 2026 post notes that the best model still fails on more than one in four security tasks. Even if that number reaches zero, someone still has to have accepted the code, and the agreement still has to say who.
What AI-Generated Code Vendor Accountability Looks Like in Practice
A vendor that can answer all five questions will do it in writing, in a day or two, without escalating to legal. Willingness to answer is itself the result of the evaluation.
How Provenance Becomes Answerable
Nexa doesn’t write every line by hand. We build with Claude Code and MCP-based integrations as core engineering tooling across the codebase, and we say so up front. Each of the five questions maps to something already standard in an engagement:
- Disclosure: the tool inventory above is our actual workflow, stated plainly on request.
- Review standard: code reviews run regularly throughout the lifecycle, and the approval standard goes into your agreement in writing.
- License and provenance: AI-assisted unit and integration tests are generated alongside code inside every sprint, not saved for an end phase, so every change arrives with tests attached.
- IP assignability: architecture decision records name why a design choice was made and by whom, which is the human-authored record the assignment ask depends on.
- Warranty and liability: the full documentation package (UML diagrams, system design documents, user story libraries, Swagger/Postman API references, and test coverage reports) is transferred unconditionally and owned by you.
We’d rather you read the answers in the contract than take our word for them.
Standard delivery artifacts that make each of the five questions answerable
The One-Page Ask You Can Send This Week
Send your vendor these five requests. Ask for written answers, not a call.
- List every AI code-generation tool used on our codebase and the model provider behind each, and tell us when the list changes.
- State the review every AI-assisted change passes before merge, who approves it, and where the approval is recorded.
- Describe your license scanning for generated code, and deliver a bill of materials with each release.
- Confirm assignment of human-authored work and an unrestricted license to AI-generated portions, and name the human-contributed design work.
- Provide a non-infringement warranty tied to questions one through three, and a capped indemnity with stated carve-outs.
A good vendor answers in days. A vendor who stalls has told you something, and a vendor who answers well has handed you the first page of your provenance record.
Ask the Five Questions Before the Next Statement of Work
The distributor’s rounding bug will happen somewhere. What decides your outcome is whether the agreement made someone record who accepted the code. Your CTO can check the contract against the five questions tonight, and your CEO can approve the clause language tomorrow.
If you want a vendor that answers all five in writing, schedule a call with Nexa Devs and bring the one-page ask.