A few years ago, a production bug meant a quick scan of the commit log and a shrug. The team shipped it, the team would fix it, and nobody at the board level asked for a name. Now they do. When a release largely drafted by a model takes a payment path down for an afternoon, the audit committee wants to know which human signed the merge, which human read the diff, and which human carried the risk into main.
That demand is not a mood. It tracks the law, the standards, and the insurers, all moving the same direction, and it is reshaping how engineering orgs document AI-assisted work. The useful way to look at it is case by case: here are the situations where the board now wants a signature, and what that signature should attach to.
The routine merge where a model wrote most of the diff
Most AI-assisted code in production is boring. A ticket, a draft from the assistant, a human review, a merge. The board’s question is simple: whose name is on the merge, and did that person read what shipped?
The emerging consensus in engineering governance is that the merging engineer owns the change regardless of what produced the draft. The model proposes; a human reviews, decides, and signs. For boards, that single sentence does a lot of work, because it closes the “the tool did it” defence before it can be raised. An engineering org that pretends it has no AI-written code in main is holding the worst of both positions: the exposure is there, the audit trail is not.
The security-sensitive change that touches a payment path
Not every merge carries the same weight. A change that touches secrets handling, authentication, or a payment flow is where boards want a second signature, and a documented one. Working with a serious AI software development company should mean exactly this: dual sign-off on anything with real blast radius, provenance tags that record which assistant drafted which hunk, and a review gate an engineering lead signs by name.
The NIST secure development framework is where most of this language is being standardized, including the companion profile for generative AI. Boards citing it want evidence the team is following a recognized practice when the next incident lands in front of a regulator.
The feature your vendor shipped with a model inside
Buying software does not transfer accountability away from your company. If a third-party feature powered by a model misprices an order or leaks a record, the company running it in production answers for the outcome. Boards have started asking which internal owner signed off on the vendor, what the contract says about model behaviour, and whether the integration was reviewed as if the code were your own.
The practical move is a named workflow owner on your side for every embedded AI feature, with the authority to pause the integration if its behaviour drifts. A procurement signature is not an engineering signature. The board wants both.
The outage where the agent shipped itself
Autonomous merges are the scenario that most alarms directors, and for good reason. The moment a pipeline lets an agent push to production without a human in the loop, the signature line goes blank, and so does the defence. Keep the human in the merge. If the agent authored the change, a named engineer still accepts it.
- Provenance at commit time. Record which assistant drafted the change and under what prompt. This is cheap to capture now and much harder to reconstruct after an incident.
- Scoped permissions. Agents get the minimum access their task requires, not standing credentials. The access model should fail closed.
- Rollback a named owner can execute. If the undo lives in a runbook nobody has rehearsed, the board will treat it as missing.
What the signature should actually attach to
Legal exposure for defective software is tightening on multiple fronts, and boards reading their fiduciary briefings are being told AI oversight is part of their duty of care. A name on a merge is only useful if the person had the information, the authority, and the time to decide. Boards that stop at “who signed it?” miss the follow-up questions that make the signature mean anything.
- The diff the signer saw. Preserved in the record, with the AI-authored portions marked. A reviewer cannot own what they could not identify.
- The checks that ran. Security scan, test suite, policy evaluator. The pipeline enforces what prose policies forget.
- The decision rights. The signer must have had the authority to say no, including under deadline pressure, without career cost.
- The post-merge review. For high-risk changes, a scheduled look-back by someone other than the signer, with findings recorded.
Done well, this is not bureaucracy. It is what lets a team keep using AI aggressively in production without the board quietly throttling what engineering is allowed to ship.
Leave a Comment