Recourse

Recourse is a path a person or system can take to change an undesirable decision outcome. In explainable AI, good recourse must be actionable, feasible, and consistent with policy, otherwise it becomes a theoretical suggestion rather than a usable governance control.

Expanded Definition

Recourse is more than an explanation of why a decision happened. In governance and security contexts, it is the practical route available to a person, operator, or automated process to change the outcome through a permitted action, appeal, correction, or re-evaluation. In explainable AI, recourse is valuable only when it is actionable, feasible, and aligned with policy, because a suggestion that cannot be carried out does not improve accountability. Industry usage is still evolving, so definitions vary across vendors and research communities, especially where recourse overlaps with fairness, appeal rights, or human override. NHI Management Group treats recourse as a control-oriented concept: the decision subject must be able to understand what can change, what cannot change, and which governance path applies.

This makes recourse distinct from a plain explanation, and also distinct from model interpretability. Interpretability helps describe system behaviour, while recourse helps determine what can be done next. In operational settings, recourse may involve a manual review, a policy exception, a corrected identity assertion, or a second-pass decision after additional evidence is provided. The most common misapplication is treating recourse as a generic explanation, which occurs when organisations publish reasons for a decision but provide no valid path to challenge or reverse it.

Examples and Use Cases

Implementing recourse rigorously often introduces workflow and policy complexity, requiring organisations to weigh better governance against slower decision handling.

• A customer denied access due to a mismatched attribute is given a documented appeal path, including which evidence can be submitted for reconsideration.
• An AI-assisted fraud score triggers a manual review when the subject provides corroborating documentation, creating a feasible recourse path rather than a static rejection.
• A privileged access request rejected by policy is rerouted through exception handling, where approval criteria are explicit and auditable under NIST Cybersecurity Framework 2.0.
• A non-human identity workflow that blocks token issuance can surface the specific registration field or ownership record that must be corrected before re-approval.
• An agentic AI decision that affects a downstream action is paused until a human operator can confirm the input data or override the result within policy bounds.

In each case, recourse only works when the next step is realistically available. If the required evidence cannot be produced, the appeal channel is hidden, or the policy disallows any exception, the process offers no genuine recourse at all.

Why It Matters for Security Teams

Security teams need to understand recourse because it is where decision governance becomes operational. When recourse is absent, users and administrators may bypass controls, open informal support escalations, or pressure staff into undocumented exceptions. That creates audit gaps, inconsistent enforcement, and brittle incident handling. For AI systems, weak recourse can also mask model errors, biased inputs, or false positives that keep affecting access, fraud, or case-management outcomes. For identity-heavy environments, recourse is especially important when a legitimate identity, credential, or NHI registration is blocked by faulty data or overstrict policy, because the recovery path must preserve assurance rather than weaken it.

Recourse also aligns with broader control thinking in the NIST Cybersecurity Framework 2.0, where governance, access control, and response processes need to be documented and repeatable. In practice, a recourse path should define who can trigger it, what evidence is accepted, how exceptions are reviewed, and how decisions are recorded. Organisations typically encounter the operational cost of weak recourse only after users contest a decision, at which point a clear and auditable recourse process becomes unavoidable to resolve the issue.