Who answers when AI wrote the code? Sign-off, attestation and accountability in generated software
This is the last article in the series, and it answers the question that sat beneath all the others. If AI generates more code than can be verified, if people move to scoping, specifying and auditing, and if automated controls cover the procedure but not the judgment, who answers when something fails?
The short answer: AI answers to no one, so someone has to, and it is best to know who before something fails. This article reviews what the law says today, what open source projects do, and the model we use ourselves, with what works and what does not.
A caveat before we start: this is not legal advice. We describe the state of the rules as of October 2026 as we found them in the sources; a specific case needs a lawyer.
What signing off means
In software, "signing off" on a change has a precise origin. In 2004, in the middle of a legal dispute
with the company SCO over the provenance of parts of the Linux code, the project adopted the
Developer Certificate of Origin (DCO). Every contribution carries a Signed-off-by line with a
person's name, and that line certifies that the signer has the right to contribute that code under
the project's license.
It is worth noting what the DCO certifies and what it does not: it certifies provenance and right, not quality. Signing off does not say "this works"; it says "I am allowed to hand this over."
With AI, a second certification is needed, the one we call attestation: a person declares that they reviewed and tested the change, that they can explain it, and that they answer for it. The sign-off answers "where does this come from?"; the attestation, "who answers for it?"
What the law says today
Three distinct areas touch the problem, and none of them shifts responsibility onto the tool.
| Area | What it says | What it means for AI-generated code |
|---|---|---|
| Copyright (US) | In January 2025 the Copyright Office concluded that AI-generated material is protected only when a person contributes sufficient expressive elements; giving instructions (prompts) is not enough | Code generated with little human involvement may have no protected author |
| Copyright (Mexico) | The Federal Copyright Law defines the author as the natural person who creates the work (article 12); the Supreme Court upheld in 2021 that only natural persons can be authors | The tool is not an author; the author, if any, is the person who contributes the creative work |
| Product liability (European Union) | Directive 2024/2853 treats software as a product, with strict liability (no need to prove fault), for products placed on the market from December 9, 2026. It excludes free software developed outside a commercial activity | Whoever puts software on the market answers for its defects, whether a person or an AI wrote it |
| AI regulation | The EU AI Act regulates AI systems by risk level, with phased obligations whose dates are being revised. Mexico has no general AI law in force, according to the sources consulted; there are bills in Congress | None of these rules makes the tool responsible for the code it generates for someone else |
The practical conclusion is the same everywhere: AI is a tool, and responsibility stays with the person or organization that puts the software in someone's hands. Whether a model wrote the code does not change who answers to a customer or a judge; it may change who the author is and what can be protected.
What open source projects do
Open source projects reached this discussion first, because they depend on provenance to be able to distribute. The responses range from prohibition to transparency:
- Gentoo banned contributions created with AI tools in April 2024, citing copyright, quality and ethical concerns, while leaving the door open to revisit it.
- NetBSD treats code generated by language models as "tainted" in its commit guidelines, and it cannot be committed without prior written approval.
- Other projects, and many companies, choose transparency: AI use is allowed, but it is disclosed, and a person signs off and answers for it.
Both approaches share one thing: they do not accept code that goes in without an identifiable person answering for it.
The model we use
In our repository the rule is short: AI does not sign off, attest, approve or merge. Each act has an owner and a mechanism that fails on its own:
| Act | Who | Mechanism |
|---|---|---|
| Generating code | The AI | Every commit records the AI's co-authorship |
| Signing off on commits | A person | Signed-off-by with their name; a hook prevents the agent from adding it |
| Attesting | A person | A box on the PR: "I reviewed and tested this change, I can explain every line and I answer for it"; the agent cannot tick it |
| Verifying it was done | The pipeline's Gate | Rejects deployment without sign-off or attestation |
| Approving the deployment | A person | Manual approval before production |
| Answering to customers and the law | The organization | Whoever offers the service |
It works for what a machine can verify. In the analysis of our 141 PRs, the Gate rejected two merges for missing sign-offs or attestation, and neither was deployed until it was fixed. It also works in what it prevents the agent from doing: in the sessions that produced this series, every sign-off, attestation, merge and approval was done by a person.
What a sign-off does not guarantee
Here is the model's limit, and it is worth stating plainly: the box verifies that someone ticked it, not that they reviewed.
- In our repository, the median time from opening a PR to merging it was 6 minutes. The attestation says there was a review; the data cannot confirm it.
- Romanchuk and Bondar (2026) describe a responsibility vacuum: beyond a certain volume, review turns into paperwork and everyone signs what nobody reviewed in depth.
- A signature without understanding is what our guide calls comprehension debt: someone formally answers for something they could not explain.
Sign-off and attestation ensure there is an identifiable person responsible. They do not ensure that person understood. That takes other things: time, a risk matrix that concentrates review where it matters, sampling audits, and people trained to audit.
What is measured and what is not
| Claim | Status |
|---|---|
| The rules reviewed do not shift responsibility onto the AI tool | Reviewed in the sources cited, as of October 2026 |
| The EU AI Act's application dates are under revision | Reviewed: sources disagree on the new dates |
| Our Gate rejected merges without sign-off or attestation | Measured: two cases |
| Attestation guarantees a review happened | Not shown: it verifies the box was ticked, not that review happened |
| The accountability model reduces defects | Not measured |
Risks and rival explanations
- Sign-off as theater. If signing becomes an automatic click, the model gives the appearance of accountability without the substance. It is the main risk, and more boxes do not solve it.
- Diffuse responsibility in large teams. With many people and many agents, everyone assumes someone else reviewed. Individual sign-off helps, but it is not enough if the actual review is not shared out.
- Rules that change. AI regulation and software liability are moving targets. What we describe here may soon be out of date.
What this article does not claim
- It is not legal advice. It describes general rules; a specific case requires a lawyer.
- It does not claim that using AI to program is risky in itself. It claims that responsibility is not delegated to the tool.
- It does not claim our model is sufficient. It ensures there is someone responsible, not that this person reviewed in depth.
- It does not claim that Gentoo's or NetBSD's ban is the right answer, nor that transparency is. They are two answers to the same problem.
Closing the series
The articles in this series tell a single story. AI generates faster than we can verify. Human work moves to scoping, specifying and auditing. Training people for that has to be designed, because entry-level work no longer trains anyone. Automated controls cover the procedure, human review has to concentrate where failure is costly, and at the end of the chain there is a person who signs off and an organization that answers.
What AI can do changes quickly. That someone has to answer for what gets delivered has not changed.
Sources
- Linux Foundation, Developer Certificate of Origin, version 1.1 (adopted by the Linux kernel in 2004).
- U.S. Copyright Office, Copyright and Artificial Intelligence, Part 2: Copyrightability (January 29, 2025).
- Mexico's Federal Copyright Law (Ley Federal del Derecho de Autor), article 12, and the Supreme Court's First Chamber ruling of June 2021.
- Directive (EU) 2024/2853 on liability for defective products.
- Regulation (EU) 2024/1689, the Artificial Intelligence Act, and its ongoing revision.
- Gentoo Council decision of April 14, 2024 on AI-generated contributions; NetBSD commit guidelines.
- Romanchuk and Bondar, The Responsibility Vacuum (2026).
- Dixi-Project: Verification debt, Scope, specify, audit, Do AI-written tests catch AI-written bugs?, One maintainer, one agent and 141 PRs with no human review, The broken pipeline and Classifying the risk of a change (2026).