How to Approve AI Decisions About People: A Review Log

The log is the artifact an auditor, regulator or employment tribunal will read. Design it for that reader, not for the reviewer's convenience. Seven fields carry almost all the evidentiary weight.

Who. The reviewer's full name and role, not a shared account or a team alias. Oversight claims should mean a named person authorized the action, not that a human was available to review outputs if they chose to Elementum. Record the reviewer's authority level alongside the name so an auditor can check whether that person was empowered to overturn the model.

What. The model's output as it stood before any human edit: the score, the classification, the recommendation and the threshold or rule that produced it. Keep the raw output and the final decision as separate fields. The difference between them is the human contribution, and it is the first thing an investigator will look for.

When. A timestamp from the approval system, not a handwritten note. If the decision took effect before the timestamp, the workflow has a control failure regardless of what the reviewer wrote.

Why. The reviewer's reason in their own words. This is the field that separates genuine authorization from rubber-stamping. A log that reads "reviewed, approved" on every row is evidence of a process, not of judgment. Train reviewers to write one or two sentences that name the piece of evidence that settled the question, for example "income verification dated 12 March contradicts the returned payment flag, so the affordability score is stale."

What evidence was seen. The log should list the specific items presented to the reviewer, not a generic description. Store either the evidence identifiers or the rendered packet. A reviewer who saw only the score cannot have evaluated the underlying facts, and the log needs to prove what was actually on screen.

Model and context. Which model or system produced the output, which version or configuration, and the inputs that fed it. This is your answer when someone asks whether the same decision would be reached again today.

Outcome and downstream effect. What was actually done: approved, modified, overturned, deferred. Link the approval record to the downstream action so a sampling exercise can follow the chain from score to consequence.

A minimal schema, in JSON, that satisfies all seven:

{
  "decision_id": "2025-04-1187",
  "person_or_entity_affected": "ref-88431",
  "decision_type": "credit_limit_change",
  "trigger_matched": ["access_change", "appeal_right"],
  "model_output": {"score": 0.38, "threshold": 0.42, "recommendation": "decline"},
  "evidence_shown": ["bank_statement_2024_03", "payment_history_24m", "affordability_model_v3"],
  "reviewer": {"name": "A. Okafor", "role": "credit operations lead", "authority": "can_approve_can_modify"},
  "reviewer_reason": "Two returned payments are explained by a payroll error confirmed in the evidence packet; affordability is within policy.",
  "reviewed_at": "2025-04-18T09:42:00Z",
  "outcome": "modified_to_approve",
  "downstream_action_id": "acct-update-55120"
}

Two practical rules keep the schema honest. First, make the reason field required and free text with a minimum length; a dropdown of canned reasons becomes another form of automation. Second, store the log append-only. If a reviewer changes their mind, they add a new entry, they do not edit the old one.

Most oversight failures happen in the interface, not the policy. Reviewers at volume click approve because the screen shows a score and an approve button. Fix this before you write the audit protocol, because an audit of a badly designed workflow can only confirm that people clicked.

Three interface requirements do most of the work.

Show the evidence, not just the conclusion. Present the specific inputs the model used, with the model's contribution marked. If a screening model down-ranks a candidate, show the fields it weighted and their values. This is the practical form of the principle that AI outputs are drafts requiring human verification and that people remain accountable for what they rely on centrexIT policy template. A reviewer can only exercise judgment over what they can see.

Make disagreement cheap. The reviewer needs an obvious modify and reject path, a short reason box, and a visible record that their decision overrides the model. If overriding requires a ticket to engineering, reviewers will stop doing it.

Block the action until the signature exists. The workflow engine should not release the downstream action until the approval record is complete. Human-in-the-loop workflows route the AI output to the reviewer, pause, and resume only on the human's decision Elementum. Enforcement at the workflow layer converts an instruction into a control.

There is a real cost to this. Reviewing every flagged decision at volume consumes capacity, and reviewers under time pressure produce nominal oversight. The honest way to handle that is triage. Reserve authorization for the four triggers, and use lower-cost monitoring for everything else. Databricks makes the same point: mature systems use confidence thresholds and risk scoring to route only a subset of decisions to human review, which is what makes the model scalable Databricks. Write the triage rule down and log which route each decision took, so an auditor can test whether your threshold is set for risk or for workload.

One more design decision that auditors care about: separate the reviewer from the model owner. A data scientist whose own model is under review should not be the approving authority for its outputs. Independence is easy to log and hard to retrofit.

When a person disputes an outcome, the audit question is narrow: was this decision genuinely authorized by a human who had the information, the authority and the time to change it? Nominal oversight is not compliant oversight, and a reviewer who lacks the information, authority or time to influence the decision does not satisfy human review requirements Kiteworks. Your audit protocol should test for exactly those three gaps.

Run four checks on each challenged record:

1. Completeness. All seven fields present, reason text is substantive, timestamp precedes the downstream action. Missing fields are a fail, not a nuance.
2. Evidence fit. Does the written reason reference something in the evidence packet? A reason that contradicts the evidence shown, or that cites facts not in the packet, is a fail.
3. Authority. Did the named reviewer hold a role authorized to overturn this decision type at that time? Check against the role map, not against the person's seniority.
4. Consistency. Did the model output and the final outcome differ in the way the reason claims? This catches approvals that were copied from a template.

Score each record pass or fail per check, and treat failures as control incidents with an owner and a fix. A single audit tells you about one decision. Sampling tells you whether the process works, so build a routine sample: every challenged decision in the last quarter, plus a random sample of approved decisions across trigger categories, weighted toward the highest-volume reviewer and the highest-impact decision type.

The audit output an investigator will actually want reads like this:

Decision 2025-04-1187 was flagged by a credit model at 0.38 against a 0.42 decline threshold. Reviewer A. Okafor, credit operations lead, was presented with the payment history, a bank statement and the affordability model. The reviewer's reason cites two returned payments explained by a confirmed payroll error. Outcome was modified to approve, applied at 09:44Z. Evidence supports the reason. Authority confirmed. Pass on all four checks.

Publish that format internally so reviewers know what "good" looks like when they write their reason. Reviewers write better logs when they have seen an audit.

The log is only as good as the policy behind it. Most organizations now expect a written AI policy; ISACA reports that only 28% of organizations say they have a formal, comprehensive policy in place for AI use ISACA. An approval log without a policy is a pile of records with no standard to test against.

Four policy provisions do the heavy lifting for human authorization of decisions about people.

The trigger list. Your four tests, in plain language, with named roles attached to each.

A prohibition on unapproved tools for decisions about people. This is the provision most often skipped. If an employee can run a candidate's file through a personal AI account and act on the output, the log will not see it. Sample policies address this directly by requiring that firm use of AI tools be restricted to approved tools with company accounts FRSecure, and by mandating that anything not explicitly approved is prohibited Littler.

The human review requirement stated as authorization. Not "human in the loop" as a slogan. State that the workflow cannot proceed without a signed approval record, and name the control that enforces it.

The disclosure and escalation path. Who a reviewer contacts when the model's output looks wrong or the evidence packet is incomplete, and what happens to the decision in the meantime. Policies that set out reporting procedures for concerns about AI output give reviewers a route that does not require them to approve first and complain later LexisNexis policy template.

One further provision is worth writing early: training. Requiring reviewers to complete a short course on the trigger list, the evidence packet and how to write a reason gives you a defensible answer when someone asks whether the reviewers knew what they were doing. The LexisNexis template conditions access to AI tools on training completion for exactly this reason LexisNexis policy template.

Treat these provisions as the source of truth and the log as the evidence that they were followed. When a decision is challenged, the first document you produce is the policy, the second is the approval record, and the third is the audit check.

The predictable decay path is well documented: reviewers approve at volume, reasons become one-liners, and the log stops proving anything. Three habits slow that decay.

Review a sample monthly and share the failure rate with the teams whose decisions are sampled. Keep a short library of good and bad reasons, updated from real audits, so reviewers calibrate against something concrete. And retire triggers that no longer match your systems: when a model is replaced or a decision moves from screening to advisory, the review requirement should be revisited.

There is also a feedback dividend. Every correction a reviewer makes is data about where the model is weak in your context. Human review is most valuable when corrections are captured and used to improve the system, not left in disconnected review workflows Databricks. Feed the reasons field into model review meetings. A cluster of "evidence contradicts the score" reasons in one decision type is a signal worth acting on.