Inventory and tiering tell the second line where to look. This article is about what happens when it looks: the act of independent challenge, the decision that follows, and the escalation path when that decision is contested.
This is where an AI risk function either establishes itself or quietly becomes ceremonial. Everything upstream is infrastructure. Effective challenge is the function actually functioning.
What Effective Challenge Actually Means
Effective challenge is often described as reviewing the first line's work. That description is too weak. Challenge is effective when the reviewer is competent enough to find what is wrong, independent enough to say so, and empowered enough that saying so changes the outcome. Remove any of the three and the review is theatre.
Competence deserves particular emphasis in an AI context.A reviewer who cannot interrogate an evaluation methodology, reason about what a retrieval pipeline will do with an ambiguous query or read a tool permission set and understand its blast radius is dependent on the first line's summary of its own work. They will be briefed courteously and told what the builder believes to be true. The gap between that and independent assurance is the entire value of the function.
Challenge should concentrate on the questions the first line is least well positioned to answer about itself.
Challenge Questions Examples
1. How does this fail, not whether it works?
Where are the errors concentrated, and are the hardest cases the ones the system handles worst?
2. Does it fail loudly or fluently?
A system that produces confident, well-formed, wrong output is far more dangerous than one that visibly breaks, because the downstream human has no signal.
3. What is the evaluation actually measuring, and against what baseline?
An accuracy figure without a defined test set, a threshold, and a rationale for the threshold is a number, not evidence.
4. What can this system do that it is not supposed to do?
Tool permissions, data access, and downstream reach frequently exceed the stated purpose.
5. What happens at the human checkpoint?
A checkpoint where the reviewer approves in seconds without meaningful information is a control on paper only.
6. What breaks this?
Adversarial inputs, prompt injection through retrieved content, unusual or out-of-distribution cases, and the boundaries of the intended population.
The Discipline of Yes, If
The instinctive framing of a review is binary: approve or reject. Both extremes damage the function. A second line that approves everything provides no assurance. A second line that rejects readily is routed around, and its perimeter shrinks to cover only the work that could not avoid it.
The productive outcome in most cases is conditional approval:yes, if. The system proceeds because the business value is real, and it proceeds with specific, tracked conditions that address the specific risks identified. Each condition should map to an identified risk rather than being drawn from a generic checklist, because conditions that appear arbitrary are complied with formally and evaded substantively.
Examples of Conditions to Approve
1. Step down the action ladder
Approve at recommend or act-with-approval rather than fully autonomous. This is the single most useful condition available for agentic systems.
2. Insert a human checkpoint at the point of irreversibility
Not uniformly throughout the workflow, but precisely where an effect becomes impossible to retract.
3. Narrow the scope
Internal use before client-facing use; one product line before all; a defined population before general release.
4. Set an evidence threshold for expansion
The system may progress to greater autonomy once monitoring demonstrates it clears a defined accuracy or groundedness bar for a given category of work. This converts autonomy from a negotiation into an earned outcome.
5. Require logging and traceability
Sufficient to reconstruct any decision after the fact.
6. Remove runtime self-modification
So that changes to rules or objectives pass through a governed release rather than occurring while the system operates.
Conditions must be recorded as tracked obligations with owners and dates, and their status must be visible in the inventory. A condition that is agreed in a meeting and never verified is not a control; it is a hope.
Escalation as a Control, Not a Failure
Conditional approval is frequently contested. In the case above the sponsor pushed back hard: the manual approval, they argued, defeated the point, and there was deadline pressure to ship. This is the ordinary condition of the work, not an exception.
The mistake at this moment is to try to win the argument locally, by seniority or persistence. The better move is to place the decision where the independence and authority actually sit:a model risk function, a risk committee, or the executive body with the mandate to accept risk on the organization's behalf. Escalation is not an admission that the second line has failed to persuade. It is the control operating as designed.
Escalation Form Attributes
The specific risk:stated concretely rather than categorically: what could go wrong, to whom, and with what consequence.
The evidence:including evaluation data and the failure profile.
The options:genuinely stated, including the one the sponsor wants, with the trade-offs of each.
A clear recommendation owned by the second line rather than left implicit.
The decision deadline:so, the committee decides rather than the calendar deciding for it.
Two disciplines make escalation sustainable: Escalate early, so that a decision remains possible rather than the deadline foreclosing it. And escalate selectively: a function that escalates routinely trains the committee to discount it. Escalation is a strong instrument, and it is weakened by frequent use.
When to Use the Veto
Outright refusal should be rare, and it should be reserved for a small number of situations where conditions cannot close the gap:
The system crosses a mandatory bright line and cannot be redesigned around it
The evidence to assess it does not exist and cannot be produced
The risk is irreversible and the control depends on a human review that is not realistically performable
A prior condition has been breached, and the response is to seek a waiver rather than remediate.
A function that has never used the veto has not been tested. A function that uses it often has usually failed earlier, at the point where a redesign was still available.
Resolving Disagreement Without Authority
Much second-line work involves stakeholders who do not report to the function and are not obliged to agree with it. The reliable technique is to establish the decision criteria before debating the decision.When both sides agree in advance on what matters, risk tier, reversibility, evidence threshold, time to value, control feasibility, and options are then scored openly against those criteria, the outcome is produced by the rubric rather than by the personalities.Agreement on process buys acceptance of outcome even from the party that loses the point.
This is also why the tiering rubric matters beyond its analytical function. It depersonalizes objection.Saying that a system triggers a top-tier criterion is a categorically different act from saying that one is uncomfortable with it, and it is far harder to dismiss as obstruction.
Documentation as the Durable Output
The lasting product of effective challenge is not the meeting but the record: what was reviewed, what evidence was examined, what was questioned, what was decided, on what conditions, and by whom. This record serves the audit function, answers client diligence, and, when something eventually goes wrong, as it will, demonstrates that the risk was identified, assessed, and consciously accepted by a body with the authority to accept it.
The alternative is an organization that made reasonable decisions it cannot evidence. In a contested review after an incident, an undocumented good decision is very difficult to distinguish from no decision at all.
Challenge and conditional approval govern a system at a moment in time. But AI systems drift, models change beneath applications, and conditions decay. The next article turns to the discipline that most programs are weakest on: Measuring whether the controls are actually working
Explore more: Start Here · Topics · Archive · About