Who is accountable when AI helps write and review production code?

Who owns the decision when AI helps write code?

AI assistance can speed up coding and review, but it does not move accountability away from the organisation or the human decision-maker. In practice, the question is less “did the model produce the code?” and more “who approved it, on what basis, and with what evidence that the release was a human-accepted change?”

The core governance issue is that machine assistance expands who can influence a change without automatically creating who is authorised to ship it. If the workflow does not make approval explicit, the organisation can end up with code that is technically traceable but operationally unowned, which is exactly where production risk starts to grow.

That is why accountable AI-assisted delivery needs named approvers, clear delegation boundaries, and records that show the change was reviewed and accepted by a human with the right authority. The model may draft, suggest, or even refactor, but production release remains a governed decision, not an inference from tool output.

Where AI assistance changes the accountability model

AI changes the workflow, not the fundamental duty of care. A developer may use an AI coding assistant, a reviewer may use AI to summarize diffs, or an engineering team may let agents generate test cases, but each step still needs a designated owner. The useful distinction is between authorship support and acceptance authority: assistance can be delegated, acceptance usually cannot.

That distinction matters most when code reaches production. If AI generated part of the implementation, the team still needs to know who validated correctness, who checked security impact, and who had the authority to release. In other words, responsibility follows the approval path, not the tool path.

Organisations that already treat human sign-off as a release control generally adapt well here, because the AI becomes another input into review rather than a substitute for review. The failure mode appears when teams rely on implicit trust in the model or assume that “someone on the team saw it” is enough. It is not enough if the organisation cannot prove who accepted the risk.

What explicit accountability looks like in a production workflow

Explicit accountability means the workflow can answer three questions for any production change: who proposed it, who reviewed it, and who approved it. That is true whether the change was written manually, partially assisted, or heavily generated. The approval record should identify the human approver, the scope of delegated AI assistance, and the evidence used to support the decision.

• Named approver, not a generic team queue.
• Defined delegation boundary, for example drafting code, suggesting fixes, or reviewing diffs.
• Audit trail that ties the merged change to the person who accepted release responsibility.
• Exception handling for cases where AI output was used but not fully trusted.

This is also where governance and identity controls intersect. The organisation should be able to show which human identity exercised approval authority and which non-human tool or assistant was acting under that authority. For broader AI governance, NIST AI Risk Management Framework is useful for structuring accountability, while ISO/IEC 42001:2023 AI Management System Standard helps formalise AI governance and responsibility across the organisation.

What breaks when accountability is vague

The risk is not that AI writes code, it is that AI makes ownership feel diffuse. When responsibility is unclear, teams may over-trust generated output, reviewers may skim because “the model already checked it,” and release managers may assume another function has validated the change. That creates a gap between technical activity and decision accountability.

There is also a control-quality problem. If the organisation cannot show who accepted the code into production, it cannot reliably investigate defects, regressions, or security incidents later. That undermines both operational response and post-incident learning, because the approval decision is part of the evidence chain.

For code-security and AI-assisted development concerns, AI Coding Agents Security Guide is a useful internal reference point, and the broader agentic risk framing in the OWASP Agentic AI Top 10 helps explain why identity and privilege boundaries matter when AI influences production changes. Where AI-assisted changes could expose secrets, over-scoped access, or unsafe release paths, the issue becomes not just code quality but controlled authority.

Risk and Threat Considerations

When AI-assisted code review or generation is deployed without clear approval boundaries, the main risk is authority drift, the organisation may believe a human reviewed and accepted a change when the actual decision path is ambiguous. That makes it easier for bad code, unsafe configuration, or over-permissive change actions to slip into production without clear ownership.

Failure mechanism: The workflow records that AI participated in the work, but not which human exercised final judgment, so review becomes traceable in theory and ambiguous in practice.

Impact: Incident response, defect attribution, and compliance evidence all weaken because the organisation cannot prove who accepted the production risk or whether the right approver actually exercised authority.

Practitioner Guidance

What to verify: Before trusting an AI-assisted release process, verify that every production change has a named human approver and that the approval record is separate from the AI tool log. The control should survive audit even if the model vendor, prompt history, or review assistant changes.

Decision rule: If the AI output can materially affect production behaviour, treat the human approver as the accountable party and require explicit evidence that they reviewed the relevant diff, not just the AI summary. If the change is high-risk, require a second human check or a narrower deployment path.

Practitioner takeaway: AI can assist with coding and review, but accountability must stay tied to a human release decision, otherwise the organisation loses both control and provability.

Related resources from NHI Mgmt Group

• What breaks when an AI agent can still write to production during a code freeze?
• Who is accountable when an AI coding tool introduces insecure code into production?
• How should security teams govern agentic development when AI systems can write code and provision infrastructure with limited human review?
• Who should be accountable when a high-risk code change reaches production without review?