The second signer: why regulated AI needs two humans on one decision
Human-in-the-loop is a phrase every AI vendor uses. A second signer is the mechanism that makes the phrase mean something an auditor can test.
A second signer is a distinct, named human who must countersign a regulated AI workflow before it executes in any downstream system. Not a reviewer. A signer. One specific person whose approval is the second of two required, with a timestamp and a permanent record.
Every AI vendor says their system puts humans in the loop. A second signer is what that claim looks like when it can actually block a workflow.
The definition matters because the phrase does not. 'Human in the loop' can describe anything from a notification email with an approve button to a governance committee that meets once a quarter. It tells you almost nothing about what a human must do, when they must do it, or what the system does if they do not show up. An audit cannot test a phrase. An audit can test a mechanism.
The second signer is a mechanism. It has a structural definition, a banking precedent that auditors already know, a scope the customer draws (the vendor does not), a workflow in talent where it runs today, and a record format that proves it is working.
Second signer vs human-in-the-loop
'Human in the loop' has no architectural content. A vendor can satisfy the phrase while running a system where every workflow auto-approves if no reviewer responds. Another can satisfy it with a compliance committee that receives a weekly digest. Both are, technically, humans in the loop.
A second signer differs in three structural ways.
First, it is a blocking condition. The workflow does not execute until the second signature exists. No fallback path, no escalation to auto-approve. The workflow holds, in draft, until two humans have signed.
Second, it applies to a specific set of workflows. The gate does not cover every recommendation. It covers the ones where a single judgment should not be enough, and the customer decides which ones those are.
Third, the second signer leaves a record. Who signed, when, what they saw when they signed, and whether they changed anything before signing. The record is created at decision time, signed, and permanently attached to the workflow.
A vendor who answers 'humans are in the loop' has nowhere to go when the auditor asks the follow-up. A second-signer architecture has the names, the timestamps, and the records sitting in the system, ready before the question lands.
Second signer vs dual authorization
Banks have run dual authorization on payments for decades. Any transaction above a defined threshold, or touching a regulated category, requires two people before the instruction moves. One initiates. A second confirms. Both act before any funds flow.
This is auditor vocabulary. Internal audit teams at large enterprises test dual-authorization controls every year. When you describe a second signer in an AI system using that framing, the auditor maps it onto a control they already know. No new framework to learn.
The AI application is structurally the same as the payments application, with one difference: the first actor is an AI agent proposing a workflow, not a human initiating a transaction. The first signer is the human who reviews the proposal and approves it. The second signer confirms before the workflow executes in any downstream system.
Both signatures are required. Both leave records. The asymmetry in downside determines the scope. On a workflow where a wrong decision costs a bad week, one signature is enough. On a workflow where a wrong decision costs a regulatory finding, the same logic applies as in payments: two people, two records, before anything moves.
Describing it this way in a vendor conversation is accurate, and the accuracy matters because internal audit is often the team that must sign off on a new AI system. Giving them a mechanism they recognize shortens that review considerably.
Where the line gets drawn
The workflows that require a second signer are defined by the customer, during deployment, in the customer's own compliance terms.
A carrier draws the line where its regulatory exposure sits: decisions subject to adverse-impact monitoring, compensation changes with compliance exposure, any workflow that has been audited before or sits under a consent decree. The system enforces whatever line the customer draws and does not argue with it.
The placement of that authority matters for two reasons.
The first is accuracy. Different regulated industries have different high-stakes categories. A financial services firm and an insurance carrier run regulated AI in environments where the compliance exposure does not overlap completely. A vendor who ships a fixed list of regulated categories is substituting their judgment for the enterprise's compliance team's. That substitution creates a liability the vendor did not intend to take on.
The second reason is accountability. When the scope comes from the customer's own compliance vocabulary, the second-signer requirement integrates into the existing governance framework without translation. The internal audit team does not need a new rubric. The risk committee does not need to evaluate a vendor-defined control model. The mechanism reads as an AI implementation of a control the enterprise already owns.
The practical question at any deployment: which workflows in this organization carry asymmetric downside, where the cost of a wrong decision is a finding rather than a recoverable outcome? That list, produced by the customer's compliance team in their own language, is the second-signer scope. If the vendor is producing it for you, ask why.
What a second signer sees
A regulated talent workflow, walked through once.
The system has processed four years of applicant data, performance records, and outcome history. It surfaces a hiring recommendation: a candidate, a role, a proposed workflow covering outreach and intake. The workflow carries the cost of action and the cost of inaction. A hiring manager reads the proposal, reviews the trace behind it, and approves.
That is the first signature.
The workflow falls within the categories the customer's compliance team has flagged: this decision is subject to adverse-impact monitoring. The system holds. It does not execute. A second reviewer, the HR legal team member whose scope covers adverse-impact exposure at this organization, receives the same recommendation with the full trace attached. What data the model weighed. What the first reviewer approved. Whether they changed anything before signing. The cost calculation behind the proposal.
The second reviewer is not re-evaluating the candidate. The second reviewer is looking for what the first reviewer cannot see from inside the hiring process: does this recommendation carry exposure this organization has flagged? Is the trace complete? Does anything in the record require a different path?
If the second signer approves, the workflow executes. If they decline, the workflow stops. The decline is logged, with the reason, and the first reviewer receives it. Nothing in any downstream system moved while the decision was open.
The candidate never sees two signatures. The record has both. A year from now, when an auditor asks what happened with this hire, both names, both timestamps, and both decision records are in the system. No one has to remember the meeting.
The record that proves the gate is real
A second signer who never declines anything is not a control.
The record that proves the gate is load-bearing is the decline log. When a second signer reviews a recommendation and stops it, the stop is logged: who stopped it, when, and the reason they gave. That log is auditable evidence that someone is reading the proposals and the system is preserving the disagreement.
In any audit conversation, an approval log with a 100% approval rate is itself a finding. It tells the auditor either that every recommendation was correct or that nobody is reviewing them. Both explanations get followed up.
A system designed for governance produces declines. The model is not failing constantly. The second signer simply sits where the first signer cannot, outside the hiring process, and now and then catches what that vantage point exists to catch. Whatever the decline rate turns out to be, its existence is the audit evidence that the control is functioning.
What control model lets you move that fast? treats the approval log as one of the three mechanisms in the governance model because a log that records only approvals tells one half of the story.
Why naming it matters in contracts
'Human in the loop' is a phrase an auditor cannot test. It describes a property of the system without specifying the mechanism. Two vendors can both say humans are in the loop while building architectures that would not survive the same governance review.
A second signer is a control an auditor can test. The test is straightforward: pull any five decisions from the regulated category. Who signed them? Who signed second? What did the second signer change or decline? The record either answers those questions or it does not.
When an enterprise is selecting an AI vendor for a regulated workflow, the review will eventually reach the governance stack. What an AI council should ask every vendor covers the questions that separate architecture from compliance theater. The second-signer mechanism is the specific answer to the approval question: who approves a regulated action, and what happens to the record?
Naming the mechanism in a vendor contract converts a policy statement into a testable commitment. A sentence that names the mechanism, defines who sets the regulated scope, and commits to a permanent signed record on every second-signer decision is auditable. A sentence that says the system supports human oversight is not.
A vendor who cannot write that sentence has not built the mechanism. The control model for regulated AI is the floor, and the enterprises that will run AI in regulated environments for the next decade are already writing procurement rubrics that assume it. What separates the systems that stay is the trace record behind every signed decision, and the second signer who confirmed the high-stakes ones.
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.