AI And Code Ownership: Who Is Responsible For Generated Code?
Imagine your AI assistant just produced 200 lines of code. Legally, you may not own a single line of it but legally, you're still on the hook for every bug it ships. Here's the gap between those two sentences, and what it means for the code you merge tomorrow.
That's the gap this whole topic lives in. The tool that produced the code can't be sued. The model can't be held accountable. The vendor's contract has already made it clear, in language most developers never read, that responsibility flows downhill, to the human who pressed Tab.
The interesting part isn't that this gap exists. It's that almost nobody in engineering treats it like it does. We've spent two years celebrating the productivity, and a much smaller fraction of that time figuring out what to do when the velocity meets a copyright claim, a compliance audit, or a production incident. Let's break it down: what courts have actually said, what your tool's contract actually says, where the legal cliffs are, and how a sane engineering team handles the whole thing without either banning AI or pretending the question doesn't exist.
The Handoff That Nobody Signed
Software ownership used to be a settled question. You wrote the code, your employer paid you to write it, your employment contract assigned the copyright to them, the company shipped it under whatever license they preferred. Three parties (you, your employer, the user) and the lines between them were clean. If something broke, the user complained to the company, the company looked at the commit history, and someone got a quiet conversation in a one-on-one.
AI assistants slide a fourth party into that picture, and the contract for that party doesn't look like any of the others. The model didn't sign your employment agreement. The vendor isn't part of your release process. Their EULA isn't shaped like a hiring contract; it's shaped like a disclaimer. You get the suggestion, you keep the suggestion, and you also keep everything that comes attached to it: the bugs, the license obligations, the security holes, and whatever future regulator decides to inspect how the suggestion got there.
That handoff happens silently. There's no checkbox in your IDE that says "I accept legal responsibility for this completion." You just hit Tab. The interface is designed to feel like autocomplete, and most developers extend the mental model of autocomplete to it: the editor is helping me type faster, the code is still mine, my ownership of the codebase is unchanged. That mental model is almost right and almost completely wrong, depending on which question you're asking.
What Courts Have Actually Decided
Two things sit at the heart of the legal picture in the United States right now, and both of them surprise developers when they hear them.
The first: in the U.S., copyright protection requires a human author. That isn't a new rule. It's the same rule that decided a monkey couldn't claim copyright on a selfie back in 2018, but it got freshly stress-tested in Thaler v. Perlmutter, a case about an image generated by an AI system without meaningful human input. In March 2025, the D.C. Circuit affirmed the lower court's ruling: the Copyright Act of 1976 "requires all eligible work to be authored in the first instance by a human being." No human author, no copyright. The output sits in the public domain.
The second, which is where developers actually live: the U.S. Copyright Office spent 2024 and early 2025 trying to draw a line for AI-assisted work that does involve a human. In January 2025, the Office published guidance saying that AI outputs are eligible for copyright only when a human contributes "sufficient expressive elements." Prompting alone, even sophisticated, iterative prompting, isn't enough. One comment quoted in the Office's report reached for a metaphor that hit developers harder than they expected: repetitive prompting is like spinning a roulette wheel. The human chose, but the human did not control the expressive elements of the output with enough specificity to be considered the author.
That metaphor matters more than the wording around it. "Tab to accept" is, in copyright terms, spinning a wheel. "Tab to accept, then rewrite four lines, restructure the function, add a guard clause, and integrate it into a class you already designed" is something else. That's where the human contribution starts becoming the kind of expressive control the Office is looking for.
The practical fallout: code that comes out of your AI tool more or less untouched may not be your company's property the way the code your senior engineer wrote last week is. It isn't stolen, but it also isn't copyrightable to your employer in any way that gives them the usual enforcement options. They can't sue someone who copies it. They can't claim it as a defendable asset. They can publish it, ship it, modify it, but the legal moat around it is thinner than they think.
The picture changes once you cross a border. The United Kingdom has had Section 9(3) of the Copyright, Designs and Patents Act 1988 on the books since the late 1980s, and it explicitly addresses "computer-generated works," assigning authorship to "the person by whom the arrangements necessary for the creation of the work are undertaken." India follows a similar approach. The EU is in the middle of a more ambitious reframing through the AI Act, which we'll come back to. The point: there is no single global answer right now. The code your team writes from a London office may have a clearer ownership story than the same code written from San Francisco, on the same model, in the same week.
What Your Tool's Contract Actually Says
Here is the sentence in GitHub's Copilot Product Specific Terms that does most of the work, and the sentence nobody quotes at AI adoption meetings:
"You retain all responsibility for your Code, including Suggestions you include in your Code or reference to develop your Code."
That sentence is doing two things at once. It hands you something: GitHub says it doesn't claim ownership of the suggestions, so they don't show up as a competing claim against your codebase. And it hands you something else: every legal risk that travels with those suggestions. Open-source license obligations from training data. Copyright claims from other developers whose code looked similar. Defects in the suggestion itself. The vendor's terms are explicit that you are responsible for determining whether your use of an output requires a third-party license and for complying with any such license.
If you read GitHub's Customer Agreement the way developers read README files, skimming for the install instructions, you miss that line. If you read it the way a lawyer reads it, that line is the whole document.
This shape isn't unique to Copilot. The same pattern shows up in nearly every AI coding assistant's terms: vendor disclaims ownership of outputs, customer accepts responsibility for outputs. The reason it's the same pattern is that it's the only shape that lets the vendor operate. Imagine the alternative, where the vendor warrants that every suggestion is clean of license obligations, free of bugs, and immune to copyright challenge. They can't make that promise about a model trained on the entire public corpus of GitHub. So the contract pushes the risk to the only party who can plausibly evaluate it: the human merging the code.
The model can't read your codebase's license terms. The vendor doesn't know what regulator your industry answers to. The IDE doesn't know whether the project you're working on is a hobby site or a payments processor. The only place to anchor responsibility is where the merge button lives.
The Indemnification Gap Nobody Mentions In Onboarding
Here's where the contract gets uncomfortable, and where most engineering org charts have a blind spot.
GitHub does offer IP indemnification for suggestions, if you're on a Business or Enterprise plan. If you get sued for copyright infringement because Copilot reproduced a snippet of someone's code, Microsoft will step in to defend you and pay damages under its Customer Copyright Commitment. The same pattern holds across the industry: most major AI coding tools offer some form of indemnification at the enterprise tier.
If you're on the Individual plan, none of that applies. You get the same model, the same suggestions, the same risk surface, and zero legal cover. If a court eventually rules that a snippet Copilot suggested to you was a substantial reproduction of someone else's GPL-licensed code, you, personally, are the one with the problem.
The reason this matters beyond the lawyer's office: a lot of professional software still ships from teams where engineers use their personal Copilot subscriptions, either because the company hasn't standardized yet, or because someone signed up six months before the company adopted an enterprise tier, or because they like their personal account's settings better. The code those engineers produce flows into the company codebase, and the indemnification that the company assumes it has, because the company is paying for Enterprise, doesn't actually cover suggestions that were made through the personal subscription.
Engineering leaders almost never audit this. The procurement team thinks the Enterprise contract covers everything. The developers don't know the contract draws a line at which subscription emitted the suggestion. The CISO finds out only if a lawsuit lands.
A clean accountability story requires every IDE, every developer machine, and every shared environment to be running the indemnified tier. "We bought Enterprise" is not the same as "every suggestion that touches our repo came from Enterprise."
The 65-Lexeme Filter And What It Doesn't Catch
If you read GitHub's safety documentation, you'll find a feature called the duplicate detection filter. The filter checks suggestions against public code on GitHub, and if a suggestion contains a code segment of about 65 lexemes or more (roughly 150 characters, the length of one or two paragraphs of dense code) and matches public code closely enough, the suggestion is suppressed. Administrators can enable this filter at the enterprise level, and most reasonable adoption guidelines tell you to keep it on.
The filter is the single most-cited mitigation when teams talk about Copilot license risk. It's also a great example of the gap between "a feature exists" and "the feature solves the problem."
The 65-lexeme threshold isn't arbitrary. It's a tradeoff between recall and usefulness. A filter that suppressed any three-token match against public code would suppress almost every Copilot suggestion, because three-token sequences appear in nearly all open-source projects. So the threshold sits well above that, in a band where matches are likely to be intentionally similar rather than accidentally similar. Reasonable design. The cost is that anything under that threshold flows through unfiltered.
A 30-lexeme function body that exactly matches a snippet from a GPL-licensed repository can land in your codebase, and the filter never sees it. A 50-lexeme idiom, a common algorithm implementation, a parser fragment, a serialization helper, can land identical to dozens of repositories without ever crossing the line. The filter isn't claiming to catch everything. It's claiming to catch the long-form near-duplicates that are most likely to support a copyright claim. The short-form stuff lives in a grey zone where the law itself hasn't decided what "substantially similar" means.
This is the part where you make a defensible call instead of a perfect one. The filter helps. Treating it as a complete solution doesn't. Treat it like the spam filter in your inbox: useful, often quietly correct, but not a substitute for not opening attachments from strangers.
The Regulators Don't Care Who Wrote It
The U.S. copyright conversation focuses on ownership. The European regulatory conversation focuses on responsibility for outcomes, and the framing is genuinely different.
Three pieces of EU legislation are converging into what some practitioners are calling the "Compliance Trinity": the AI Act, the Cyber Resilience Act (CRA), and the Product Liability Directive (PLD). Each one approaches AI from a different angle. The AI Act regulates AI systems by risk class, the CRA imposes cybersecurity obligations on connected products, the PLD attaches liability for defective products including software. They all share a common assumption: regulators do not care whether your code was written by a human, an AI tool, a contractor, or a small team of trained ferrets. They care about the product that reaches the market.
August 2, 2026 is the milestone most developers will hear about. It's when many of the AI Act's substantive obligations kick in, including transparency requirements for AI-generated content and active enforcement powers. Plain developer-assistance AI use generally doesn't drag a system into the high-risk category by itself, but AI used for things like worker evaluation or critical-component generation absolutely can. The classification depends on what the system does in the world, not on what tool helped write it.
The harder shift is the cultural one this implies. Before AI assistants, the was-it-written-carefully question and the is-the-product-safe question pointed at roughly the same thing: the people who wrote the code were also the people responsible for it. With AI assistants involved, the two questions can drift apart. The product can be unsafe even if everyone who reviewed the diff would swear they read it carefully. The regulator doesn't accept "the AI suggested it" as an explanation any more than they would accept "the contractor wrote it." You shipped it; you're responsible for it.
That's a clean framing, once you accept it. The discomfort comes from a half-formed expectation that AI tools come with a kind of distributed responsibility, that the vendor shares the blame because they trained the model. They don't. They explicitly don't, contractually. And the regulators have politely declined to invent that kind of shared responsibility either.
The Cultural Problem Nobody Warns You About
Outside the legal text, there's a softer pattern that quietly erodes accountability inside engineering teams, and it has nothing to do with contracts.
Researchers studying AI-assisted development have started to document something most senior engineers already feel: code that comes out of an AI assistant tends to get less careful review than code a human typed. Reviewers spend less time on it. They flag fewer issues. They're more likely to wave through a function that compiles and looks reasonable. Part of this is fatigue, because there's more code to review now than ever, now that the typing constraint that used to throttle output is gone. Part of it is implicit trust: the model has read more code than any reviewer alive, so its output gets a small unconscious authority bump. Part of it is just the design of the interface, which makes acceptance the default and rejection the friction.
The problem isn't that any of those reactions is unreasonable on its own. It's that they compound in the direction of less accountability, not more. The diff is twice as long, the review is half as careful, and the person who would normally have asked a sharp question about a defensive null check is busy scrolling through the next three suggestions. The unit of human attention per line of merged code drops, and so does the chance of catching the bug, the license issue, or the subtle authorization mistake that the model didn't realize it was making.
This isn't an argument against AI tools. It's the missing line on the dashboard that most teams haven't drawn yet: if we're producing more code, are we proportionally reviewing more carefully, or are we relaxing review because the volume forced us to? Nobody asks that question out loud. It would slow things down. And nothing about the regulatory framework above will save you from the answer.
What A Working Accountability Model Looks Like
You can't solve any of this with a Slack post. You can't solve it with a policy document either, unless the policy actually changes how code lands in your repo. The teams that handle this well do four mundane things, none of them clever.
They make tier ownership boring. Every developer, every shared environment, every CI runner that uses an AI assistant is on the indemnified tier. There is no personal-subscription escape hatch for company work. This is the procurement-level boring decision that closes most of the gap in one motion.
They make duplicate filtering on by default and verifiable. The filter is enabled in the admin console, and it's part of the periodic security review the same way SSO enforcement is. It's not a setting someone might have flipped on a Tuesday; it's an audited control.
They treat AI-generated code in code review the same as third-party dependencies. New code from a model is treated, mentally, the way a senior engineer would treat a copy-paste from a Stack Overflow answer in 2014. You ask: do I understand what this does, do I know the license shape it came from, would I sign my name to this if the model wasn't here to point at? That question is the entire ethical and legal apparatus, compressed into a sentence the reviewer can actually internalize.
They name an owner. Every PR has a human who is responsible for the code in it. Not the model. Not the vendor. Not "the team." A person, with a name, who will pick up the phone if the code breaks. If your tooling makes it hard to remember who that person is for AI-heavy PRs, that's a process problem worth fixing, because every other framework above only works if there's a name at the end of it.
Note
None of this requires a legal team or a compliance officer. The first three steps are admin-console settings and a review-checklist sentence. The fourth is a cultural norm that good teams already have for human-written code. The only new thing AI introduces is that you can't skip any of these because the volume increased.
The Sentence That Holds The Whole Thing
If you remember one thing from this post, make it this: every AI suggestion is a contribution from an anonymous third party who has read every open-source project on the internet, who you have no way to interview, and who your contract has explicitly placed outside the chain of responsibility.
That isn't a reason to stop using AI assistants. It's not even a reason to slow down. It's the actual shape of the relationship, and the friction in software engineering keeps coming back to it because that shape isn't going to dissolve on its own. Courts are converging on it. Vendors have already built their contracts around it. Regulators are about to enforce it.
The good news, if you can call it that, is that the answer was never in the model. It's in the part of the workflow that was already supposed to be the most boring and the most rigorous, the part where a human looks at a diff and decides whether to merge. That part has never been more important than it is now, and the cheapest thing your team can do to handle the whole ownership question is to make sure that part still happens, with the same care it had before the suggestions started arriving twice a minute.
You wrote the merge commit. You own it.
P.S. Thanks for taking the time to read this article! The ideas and opinions expressed here are my own. English is not my first language, so I use AI to help correct grammar and make my writing clearer and easier to read. If anything still sounds a little awkward, I appreciate your understanding!
Originally published at nazarboyko.com.