The person who submits the change is accountable, whether a model or a human typed it. The Linux kernel's own guidance on tool-generated content puts it plainly: you are expected to understand and be able to defend everything you submit. Teams can adopt the same rule in a single sentence of policy.
What the kernel documentation says
The kernel's process documentation on generated content says submitters must understand and defend their work, and that if they cannot, they should not submit the resulting changes. It adds that maintainers may reject a series that does not meet this without detailed review.
On provenance, it points to the Developer's Certificate of Origin, which it says has been in place for a long time and has covered many tool-generated contributions. On transparency, it suggests telling reviewers which tools were used, their inputs, and for heavily generated code the prompts, plus which parts are affected and how the change was tested. Its summary advice is to choose transparency when in doubt.
Maintainers keep discretion. They may review such contributions normally, apply extra scrutiny or testing, or deprioritize them, with scrutiny in proportion to how much was generated.
This is one project's rule, not a legal standard. It is useful because it is short and specific.
Turning it into team policy
Here is wording you can adapt:
- The author of a pull request owns it, including any AI-written parts.
- Do not submit what you cannot explain in review.
- State in the description when AI wrote a substantial part, and what you did to verify it.
- Reviewers may ask for more tests in proportion to how much was generated.
- Approval does not transfer accountability to the reviewer.
Defense questions a reviewer can ask
| Question | What a good answer shows |
|---|---|
| Why this approach and not a simpler one? | The author understood alternatives |
| Which inputs does this trust? | Author considered attack surface |
| What happens on failure? | Error paths were thought through |
| How did you test it? | Evidence beyond "it ran" |
| Where did this dependency come from? | Package was checked, not assumed |
Common mistakes
Treating the assistant as an author with its own sign-off. A model cannot be called into a postmortem.
Letting reviewers become the only safeguard. A large generated diff overwhelms review; see reviewing large AI-generated pull requests.
Asking for disclosure without saying what happens next. Disclosure should change the depth of review, not trigger blame.
Where Safeguard fits
Safeguard can enforce policies and gates on pull requests, such as requiring scan results and approvals before merge, so the accountability rule has a mechanical backstop. Try a free scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Click through the gate and look at which checks must pass before the merge button unlocks.
Quick check
Do we have to tell reviewers when AI wrote the code?
No law in this article requires it. The kernel guidance recommends transparency, and it helps reviewers calibrate effort.
Can we blame the assistant vendor?
For your own engineering process, no. Contract terms are a legal question for counsel.
Sources
Last reviewed: 19 October 2026.
