The second signer: why regulated AI workflows need two humans
One approval logs a decision. Two signatures make it defensible.
A second signer in a regulated AI workflow is a distinct human approval required before a proposed action executes. The first signer reviews and decides. The second confirms. The workflow stays a draft until both signatures exist in the record.
That is the definition. Every word in it matters.
Second signer vs human in the loop
"Human in the loop" now means at least four things: a human who receives alerts, a human who clicks approve, a human who can override, and a human whose signature is required for execution. Most vendor governance documents use all four meanings in the same paragraph without distinguishing between them.
The second signer names one of those four. Not the reviewer. Not the override. The signature required for execution, which is structurally distinct from the first approval.
In a system where a single reviewer approves a regulated action, one person stands between the model's recommendation and the downstream system that executes it. When that person approves under pressure or without enough context, the error executes. There is no second check.
Human in the loop, on its own, is a process requirement. One person reviews, and the institution depends on that person's judgment being correct and unconflicted each time the system proposes a regulated action. That is a high-variance assumption for decisions that carry regulatory weight.
The second signer is a structural control. Two people are required. Neither can act alone. The institution's exposure to any one person's error or pressure is cut by a layer that the single-reviewer design does not provide.
Second signer vs dual authorization
Dual authorization is not a new concept. Banks have run it on payments for decades. Any transaction above a defined threshold requires two officers to authenticate, sequentially. The first initiates. The second confirms. The transaction does not clear until both have acted.
The reason dual authorization exists in payments is not distrust of any individual officer. It exists because a single actor on a consequential decision is a single point of institutional failure. An officer who initiates a large transfer can be pressured, phished, or mistaken. A second actor does not eliminate all risk. It eliminates that one failure mode, which payments systems have designed around since long before software was involved.
AI systems that make recommendations at scale in regulated domains carry the same failure profile. A talent intelligence system proposing a workflow across an adverse-impact-monitored candidate cohort, touching hundreds of people in a single run, is making decisions at a volume no individual analyst ever reached. A single approval on that workflow is a single point of institutional failure, by exactly the same logic that makes a single-officer wire transfer an unacceptable control in banking.
The second signer borrows dual authorization from payments and applies it to AI. The logic is identical. The regulated industries are the same. The audit frameworks asking the questions are often the same frameworks.
There is one meaningful difference. A payments system does not identify which transfers need dual authorization; a compliance team defines the threshold and routes transactions accordingly. An AI system proposing a regulated workflow can surface its own categorization. A workflow touching a monitored screening category can flag itself as requiring the second-approval gate. The system routes itself. The humans confirm. Nothing executes until both have signed.
A dollar threshold catches transfers by size. Self-routing catches workflows by what they touch, which is the line a compliance team cares about. The categories that trigger it are still set by the customer. The system enforces whatever line the customer draws.
What auditors actually ask
Auditors in regulated enterprise do not ask whether a human was involved. They ask questions with specific answers: who approved this action, in what sequence, what did they see when they approved, and what is the permanent record of their decision?
Those questions come from audit playbooks that predate AI by decades. Model risk management frameworks in financial services, compliance requirements in regulated insurance markets, and procurement standards across the public sector all require institutions to demonstrate that no single actor could approve a consequential decision without an independent check. The second signer answers those questions for an AI workflow the same way dual authorization answers them for a wire transfer.
A single-reviewer system produces a log. It can show who approved and when. What it cannot show is independent confirmation from a second actor, because there was none. In an audit, that log is not evidence of a structural control. It is evidence that one person approved.
An approval log where no reviewer ever declines anything is itself a finding. It raises the question of whether any reviewer was reading the proposals carefully or whether the approval button was functioning as a ceremony. A second-signer log produces a different picture: two actors, two timestamps, and the record of what either changed or declined. When neither of two independent actors declines, the auditor is reading agreement between two people, not the silence of one.
How the mechanism works
The categories that require a second signer are specified during deployment, in the customer's own terms. A carrier defines the line where its compliance obligations sit: decisions subject to adverse-impact monitoring, compensation changes with regulatory exposure, any candidate action on a cohort where the institution has a standing audit obligation. The system enforces those specifications. It does not interpret or extend the definition.
When a cross-system workflow is drafted and identified as touching a defined category, it routes to the first signer with the full proposal attached: the model's inputs, its reasoning, the cost of action, the cost of inaction, and the scope of the cohort affected. The first signer reviews and decides. Approve means the workflow enters the second-signer queue. Edit means the workflow updates with the change logged, then enters the queue. Decline means the workflow does not proceed and the reason is captured.
The second signer sees the same proposal the first signer received, plus the first signer's decision including any edits. Until a second signature is in the record, nothing executes in any downstream system. Both approvals are timestamped. Both are permanently stored. Both are queryable on demand.
One constraint cannot be waived: the second signer cannot be the same person as the first. The routing enforces this. A system that permitted self-confirmation would produce a second signature that is not structurally independent, which is the one property the control is built around. Independence is enforced by the architecture, not by policy.
The production record
At a Fortune 500 insurance carrier, this control architecture has been in production for four years across 10,765 agents. Legal review completed in 17 days. Contract to production in 34 days. The carrier's compliance team was not reviewing a governance document. They were reviewing an architecture they would need to defend in future audits, including the second-signer requirement on regulated workflows.
What passed that review was an inspectable control structure: every action carries a signed Decision Trace, every regulated workflow requires a second signer before execution, and the complete record of who approved what, in what sequence, with what changes, and what anyone declined is queryable from the carrier's own environment. The methodology behind how those traces are created and audited is published on arXiv: Decision Traces.
The governance piece that covers the full control model from the vendor's perspective, including the approval log structure and the Decision Trace function, is What control model lets you move that fast?. This piece has the narrower job: defining the second signer as a specific mechanism and separating it from the broader category of "human in the loop" it is routinely grouped with.
The audit question that settles it
The distinction between human in the loop and the second signer resolves at one audit question.
An auditor pulls a decision from last year. A single reviewer approved a regulated workflow involving a monitored candidate category. That reviewer was the direct manager of the candidates being evaluated. The auditor's question: what structural control prevented a conflict of interest from determining this outcome?
In a single-reviewer system: nothing structural. Human review was required; a human reviewed; the system logged the approval.
In a second-signer system: a second actor, independent of the first, confirmed the workflow before anything executed. The record shows both approvals, both timestamps, and whatever either reviewer changed or declined. Neither actor could advance the workflow to execution alone.
That second answer is what AI governance in regulated enterprise will need to produce. The audit bodies reviewing AI adoption are using the same frameworks they applied to payments, automated underwriting, and model risk management before AI was involved. The second signer is not a novel concept. It is a decades-old control that AI systems are now inheriting.
Saad Bin Shafiq is the founder of Nodes. Anchor pilot: Fortune 500 insurance carrier, four years of production data, 10,765 agents. Methodology: Decision Traces.