Your Outsourcing Vendor Is Using AI to Write Code. Who Owns the Risk?

When AI-generated code ships a bug or a security flaw into production, the question of who pays for it was decided months earlier, in the contract, not in the pull request.

Most clients evaluating an outsourcing partner in 2026 ask whether the team uses AI. Fewer ask what happens when it gets something wrong. That second question is the one with financial consequences, and it has answers that are knowable before you sign anything.

Who is on the hook when AI-generated code fails

Every AI coding tool's terms of service draws the same line: the tool is provided "as is," and the vendor selling it disclaims warranties on the code it generates. That is not a loophole; it is standard software-licensing practice, and it means the tool maker was never going to be the party you'd pursue over a production bug. The real question is what your outsourcing vendor's contract says about a defect that originated in AI-generated code versus one a person typed by hand.

Most master service agreements were written before agentic tools were part of daily delivery, and they treat "code" as a single category regardless of how it was produced. That silence is not neutral. It usually defaults to whatever standard of care and liability cap already governs the engagement, which may or may not have anticipated that a meaningful share of the codebase was drafted by a model and reviewed, rather than drafted by a person from scratch. Ask your vendor directly: does a defect traced to AI-generated code get treated any differently than one in code a senior developer wrote unassisted? If the answer is a shrug, that is useful information on its own, because it means the question has not been decided, and an undecided question becomes a negotiation the day something actually breaks.

The practical fix is not exotic. It is naming the scenario in the contract before it happens: who is responsible for catching a defect before release, what happens if one ships anyway, and whether the vendor's existing liability terms already cover AI-assisted work or need an amendment to say so explicitly.

The IP question AI-assisted code raises on its own

Intellectual property assignment in a typical outsourcing agreement is built for one scenario: a developer writes code, and ownership of that code transfers to the client on delivery or payment. AI-assisted output complicates that in ways worth naming rather than assuming away.

First, confirm the assignment clause actually covers AI-generated portions of the work, not just code a person typed. Most agreements were drafted with language like "all work product created by vendor in performance of the services," which is broad enough to include AI-assisted code in most readings, but "in most readings" is not the same as "explicitly stated," and explicit is what you want in a document that matters.

Second, ask what happens to your code on the other end. Some coding tools' terms reserve rights to use submitted code and prompts to improve their models unless an enterprise or opt-out tier is configured. If your vendor is feeding proprietary logic, credentials, or client data into a tool with default training-data terms, that is a real exposure, independent of who owns the resulting output. A vendor with a mature process can tell you which tools they use, what tier they're licensed under, and whether your code is excluded from training. A vendor without an answer has not asked the question either.

Review is the actual control, not the tool

It is tempting to treat "which AI tool does the vendor use" as the safety question, but the tool is the least informative variable here. Every serious agentic coding tool can write a plausible, subtly wrong function; that is a known property of the category, not a defect in one product over another — the same judgment gap outsourcing was always selling against, since a model can draft the function but someone still has to own what it does in production. What determines whether that wrong function reaches production is whether a person with the authority to reject it actually looked at it, understood what it does, and signed off.

That means the control worth verifying is process, not tooling. Ask how code moves from an agent's output to a merged pull request: is there a mandatory human review step, does the reviewer have to actually run and reason about the change rather than skim a diff, and is that review documented anywhere a client could audit it later if something goes wrong. A vendor that treats AI output the same as any other pull request, subject to the same review bar, is telling you something real about their engineering discipline. A vendor that treats AI-generated code as pre-approved because a test suite passed is describing a gap, whether or not they'd call it one.

What belongs in the contract or SOW

Once the risk is named, putting it in writing is straightforward. A few specific asks, raised before work starts, do most of the work:

• Code review requirements. A line stating that all code, regardless of how it was drafted, goes through a named human review step before merge, and that the reviewer is qualified to evaluate it.
• Indemnification language that explicitly does not carve out AI-assisted work, so a defect traced to AI-generated code is covered the same as any other defect under the existing liability terms.
• Incident response ownership. Who is responsible for detecting, disclosing, and remediating a production issue, and on what timeline, regardless of which part of the pipeline produced the faulty code.
• IP assignment that names AI-assisted output explicitly, rather than leaving it to a broad "all work product" clause to be read generously after the fact.

None of this is a reason to avoid AI-assisted delivery. It is faster and, done well, it is not less careful than the alternative. It is a reason to put the same discipline into the contract that a mature vendor already puts into their review process, so the two match instead of one assuming the other.

If you want to see how we structure review and accountability for AI-assisted work before it ships, get in touch or read more about how we work.