A supplier requests a change to its payment details. An AI assistant extracts the account information and produces a summary for review. Two staff members approve the change, each working from the same summary. The process records an automated check and two human approvals.
The original request contains an inconsistency that the summary omits. Neither reviewer opens the attachment in which it appears. Three recorded stages have accepted the case, but the extra approvals have not created another route for noticing that particular problem.
This is the redundancy paradox considered here: adding decision-makers can create the appearance of additional protection while leaving an important failure shared across the stages. The phrase describes a design problem, not a formal theorem that human oversight is ineffective. The question is which failures each stage can actually detect and what happens when it finds one.
Redundancy depends on the failure being considered
Two reviewers can provide useful protection against some mistakes. One may notice a transposed digit or a missing approval that the other overlooked. That benefit does not establish protection against a source omission neither reviewer can see.
Safety engineering examines common-cause failures because separate protective channels can depend on the same power supply, environment, component, or management process. HSE’s control systems guidance describes the need to consider those dependencies when establishing independence. That guidance concerns industrial protection systems; it is not a certification rule for a business AI workflow.
The analytical connection is useful nonetheless. For human–AI review, a shared dependency may be an incomplete source extract, an outdated policy, a common interface, or a case selection rule. Separate people can be organisationally distinct while relying on the same mistaken representation.
Shared information is not inherently a defect. Reviewers need access to the relevant facts and agreed policy. The concern is whether a failure in that shared input defeats every stage that is being counted as protection against it.
Ask what the reviewer sees when the model is wrong
A reviewer might be highly accurate on ordinary cases and much less effective on the unusual cases that cause model errors. Overall human accuracy does not reveal the probability of catching the model’s mistakes. The cases arriving at the second stage need their own examination.
Consider an illustrative set of 1,000 cases in which the automated stage makes 100 errors. If review identifies and corrects 70 of those errors, 30 remain from that group. Calculating the final result also requires examining whether reviewers introduce errors into cases the system handled correctly. These numbers describe a hypothetical example, not measured human reliability.
The important quantity for the safeguard is how often it misses an error given that the earlier stage made that error. Multiplying two overall error rates would require assumptions about their relationship that this example does not establish. Dependency reliability raises the same need to state assumptions before combining component figures.
For the payment-detail change, examine the cases in which extraction omitted or misrepresented something important. Does the review path reveal the original material? Does the checklist require comparison with an authoritative record? Can the reviewer recognise a missing verification step? Those questions are more informative than the percentage of all cases approved.
Map shared dependencies before adding another approval
Follow the information used by each stage. Start with the original request, identify what the model extracts or summarises, and record which representation each reviewer receives. Then inspect the policy and tools used to make the decision.
| Shared dependency | Failure it could conceal | A check to consider |
|---|---|---|
| Generated summary | Important detail omitted | Compare decisive facts with the source |
| Policy extract | Obsolete or incomplete rule | Verify the applicable policy version |
| Case routing | Problem never enters review | Sample outside the flagged queue |
| Approval interface | Correction does not reach execution | Trace a rejected case through downstream processing |
| Review capacity | Both reviewers rush during peaks | Test workload and escalation arrangements |
Assign a purpose to each check. If two people both verify that the summary contains an account number, the second check may add little protection against an incorrect account number. A more useful division might separate source comparison from an independently established confirmation procedure, where the organisation’s payment controls require one.
The exact procedure needs to follow the organisation’s risk assessment and operating rules. The general design task is to identify which evidence could contradict the first stage and ensure that someone actually uses it before the relevant consequence occurs.
Different methods can expose different mistakes
Diversity can mean checking through another method or representation, not simply appointing another person. A deterministic reconciliation may identify a total that does not balance, while a reviewer examines whether the underlying transaction belongs in the account at all. A source-level check may reveal an omission that another generated explanation repeats.
Using another model is also a design choice to evaluate, not automatic independence. Two systems may receive the same incomplete extract, use similar assumptions, or be asked a question that excludes the decisive evidence. Agreement between them does not reveal whether their failure sources differ.
Likewise, hiding the recommendation until a human records an initial view can reduce one route of influence while leaving a shared data problem untouched. The illusion of independent judgment examines the sequencing question. Here, the concern is what remains shared even when the initial judgments are formed separately.
Detection must connect to intervention
A safeguard that identifies a discrepancy after the operation has already completed may support recovery but cannot be counted as preventing that operation. Separate pre-action checks from later reconciliation and document the consequences each is intended to reduce.
For the supplier change, an unresolved discrepancy should have a defined effect on the update path. If the reviewer records a concern but the automated workflow still releases the change, the detection stage and the execution stage are not connected as the process description implies.
Test that connection with a controlled case. Introduce a discrepancy, have the reviewer identify it, and follow the resulting hold, escalation, or rejection through to the component that would otherwise act. Check that notifications and work queues preserve the unresolved state rather than presenting it as completed.
Responsibility also needs to continue after escalation. NIST’s AI Risk Management Framework discusses defining human roles in human–AI configurations. In practice, name the owner who resolves the discrepancy, the authority needed to release it, and the evidence retained for a later investigation.
Evaluate the added protection under realistic conditions
Measure the second stage on the failures it is meant to catch. Include known omission cases, misleading summaries, outdated policy references, and corrections that must reach downstream systems. Keep clean cases in the evaluation as well, so additional checking does not receive credit for finding errors while its new mistakes remain uncounted.
Use an appropriate reference assessment and record ambiguity. A reviewer disagreeing with the model is not necessarily detecting an error. Where the policy is unclear or the source is incomplete, the correct response may be to request more evidence rather than force a binary label.
Test the operating conditions too. A process may work when reviewers have time and direct access to source records, but weaken when a queue grows or a key system is unavailable. HSE’s guidance on human failures identifies workload and design conditions as factors influencing performance. Include those conditions in the evaluation instead of treating reviewer effectiveness as a fixed personal attribute.
Keep records of escapes as well as catches. A later-discovered error should be traced through every stage that approved it, identifying what each saw and what could have revealed the problem. That investigation may show that another approval would have repeated the same failure, while a different source check would have been useful.
State what the additional review protects
Describe the safeguard precisely in approval papers and operational procedures. For example, a second reviewer might compare extracted payment details with an authorised source before release, while a separate process resolves discrepancies. That description can be checked against what staff actually do. The phrase two-person approval leaves the evidence, timing, and intervention route unspecified.
Retain the assumptions behind the claim. If the source comparison depends on access to a particular record, define what happens when that record is unavailable. If the check requires specialist knowledge, account for coverage during leave and demand peaks. An exception that quietly bypasses the second stage can remove the protection exactly when the process is under strain.
Reassess the safeguard when the interface, model, policy, or source changes. A source link removed during a redesign can alter the independence of review without changing the number of required approvals. Treat that as a change to the control, with corresponding evidence needed before relying on it again.
The value of oversight lies in the additional protection demonstrated for the relevant cases. A second reviewer can contribute expertise, independent evidence, authority, or recovery capacity. Name which contribution is expected and test that it survives the shared failures the organisation is concerned about. The number of people in the workflow is then a design detail supported by evidence, rather than the evidence itself.
