The AI writes the code. Who is liable for it?

By 2026, artificial intelligence will be writing an ever-growing slice of corporate code-industry surveys put the figure at up to 40 percent. When that code breaks in production or opens a security hole, an awkward finger-pointing contest erupts in the boardroom: who’s actually responsible? The answer, surprisingly often, is nobody.

Related:Four stumbling blocks: why AI projects fail to reach steady state  /  When an AI model vanishes overnight: why CIOs need a Plan B

How much code AI really writes

Estimates vary by source, but the trend is unmistakable. Industry surveys project that in 2026 roughly 40 percent of newly written code will be AI-assisted, with the share still climbing. In many dev teams the AI assistant is no longer an experiment-it’s part of daily workflow.

What counts as AI-generated code? It’s source code produced by an AI assistant-Copilot, Cursor, or an agentic tool-on the basis of a prompt, then adopted, tweaked, or shipped verbatim by a human. Formal responsibility stays with the company, but the chain of authorship blurs.

As the volume rises, so does a second, rarely discussed metric: studies from the software industry show AI-assisted code carries more vulnerabilities, and without rigorous controls technical debt balloons. Speed creates volume, and volume without inspection creates risk.

The Liability Vacuum: When No One Is Accountable

The real explosive issue isn’t the error rate-it’s the question of responsibility. Ask companies who bears the blame for damage caused by AI-generated code, and you’ll get three different answers. Development points to the tool, security points to development, and both look to the vendor whose contract usually limits liability.

For any C-level executive, this is a familiar pattern in new packaging. A responsibility shared by all ultimately rests on none. As long as it remains unclear who approves an AI commit and answers for its consequences, the chain of accountability is broken. The gap stays open, and when trouble hits, the board fills it-willingly or not.

Then there’s the practical headache seasoned IT leaders know from every legacy system. AI code is often harder to maintain than handwritten code because the implicit understanding that comes from writing it yourself is missing. When the original prompt is forgotten and the developer has moved on, you’re left with software that works-until it doesn’t.

A typical scenario makes it real. An AI assistant suggests a library function, a developer adopts it under deadline pressure, and the review stamps it as standard code. Weeks later, that same function opens a breach because the AI recommended an outdated, vulnerable version. In the post-mortem, everyone points at someone else, and the CIO explains an incident nobody deliberately caused to the supervisory board. This cycle repeats as long as approval has no face.

What’s at Stake Without Governance

Without control rules, three risks that could each be managed pile up into one expensive problem. A simple side-by-side shows the difference between unchecked and vetted AI code.

The table looks simple, but the impact isn’t. A gate demands an organizational decision, not a new tool. That’s exactly where many initiatives stall-because they hand the issue to tool selection while it’s really a leadership call.

The Gates a CIO Must Set Now

The path out of the void begins with a handful of hard-and-fast rules embedded in the development process. Four of them deserve immediate attention.

1. Mandatory review for AI-generated code. Every AI-produced commit undergoes the same human review as hand-written code, plus an automated security scan before merging.
2. One owner per commit. Whoever accepts AI-generated code also accepts responsibility for it. Approval carries a name, not a tool logo.
3. Keep provenance traceable. Which part came from which assistant, using what prompt? This audit trail can cut damage-control time from weeks to hours.
4. Clarify supplier contracts. Before rolling any tool company-wide, legal must verify what the vendor actually guarantees. Promises are often limited and must be read case by case.

None of these four points requires extra budget-only a decision. That’s where intention parts ways with execution. A gate that lives inside the build pipeline works. A gate that only lives in a policy manual nobody reads is just wasted paper. Seasoned IT leaders therefore bake the rule into the code so it’s still enforced at 3 a.m., when deadline pressure peaks and the temptation to rubber-stamp is strongest.

Who Bears Responsibility Inside the Company

Rules without owners vanish. Every gate therefore needs a role that enforces it. In practice, a lean split works best: one executive with overall AI accountability, named owners per tool who carry results accountability, a security representative for risk assessment, and engineering managers for day-to-day oversight.

Crucially, these roles must be in place before the next incident-not after. A board that green-lights AI-generated code without assigning clear responsibility simply postpones the reckoning until the first serious breach. Companies that now draw a chain of accountability are buying the very ability to run AI in code responsibly. Those that skip it are merely postponing the next incident.

Frequently Asked Questions

More from the MBF Media Network

Image source: AI-generated (Juni 2026)