How do I show a customer or regulator that a human reviewed an AI decision before it went out?

What should I check, step by step?

1. Hash and timestamp the AI's draft decision when it's produced, with the model and inputs, before any human touches it. That's the baseline the review is measured against.

2. Show the reviewer the draft, the inputs it was based on and anything the person affected sent in. Record what was shown (hashes of the case file and the draft), not just that a screen opened.
3. Record the decision as a separate event: approve, change or reject, the reason, the reviewer's role and identity in your own system, and the time. If they changed it, hash the final version too, so the edit is visible as a different hash.
4. Bind the approval to the exact decision being sent: hash the final decision text or object and require the send step to match it. An approval of draft A shouldn't let draft B go out.
5. Log the send with its time and the final decision's hash. The approval time must come before it.
6. Measure whether review is real: share of drafts changed or rejected, time spent per case, cases per reviewer per day. A reviewer who approves every draft in seconds is the 'token gesture' the guidelines warn about.
7. Keep the records past the dispute window and the logging period your rules set. For high-risk systems, Article 26(6) of the EU AI Act requires deployers to keep the system's automatically generated logs for at least six months, unless other law provides otherwise.
8. Write down which decisions skip review, why, and who signed off on that rule. A gap you documented is easier to defend than one found in an audit.

What does human review of an AI decision have to involve under GDPR Article 22?

GDPR Article 22(1) gives people the right not to be subject to a decision based solely on automated processing that produces legal effects or similarly significantly affects them, with exceptions that come with safeguards such as the right to obtain human intervention and to contest the decision (Article 22(3)).

• The Article 29 Working Party's guidelines (WP251rev.01, endorsed by the EDPB) say a controller can't avoid Article 22 by fabricating human involvement: if someone routinely applies automated outputs without any actual influence on the result, it is still solely automated. The review must be meaningful, by someone with the authority and competence to change the decision, who considers all the relevant data. The CJEU's SCHUFA judgment (C-634/21, December 7, 2023) held that an automatically generated score can itself be an Article 22 decision when a third party relies on it decisively.
• Spain's data protection authority (AEPD) lists what to assess in a reviewer: competence to alter the outcome, training, independence, and the means to act, including information in time and enough time per case. Its example: 100 reports of 100 pages a day works out to about 21 pages a minute, which isn't feasible review.

What human oversight and logging does the EU AI Act require for high-risk AI decisions?

For high-risk AI systems, Article 14 requires that people assigned to oversight can understand the system's limits, stay aware of automation bias, correctly interpret its output, and decide to disregard, override or reverse it. Article 26 requires deployers to assign oversight to people with the necessary competence, training and authority, and to keep the system's logs. artificialintelligenceact.eu lists these high-risk rules as applying from December 2, 2027 for Annex III systems and August 2, 2028 for Annex I systems.

• For remote biometric identification systems (Annex III point 1(a)), Article 14(5) goes further: no action may be taken on an identification unless at least two people with the necessary competence, training and authority separately verified and confirmed it, with limited exceptions.
• Outside the EU the vocabulary differs, but a customer's complaint or a regulator's inquiry asks the same questions: who looked, what did they see, could they change it, and did they look before it went out?

How do I prove a human approved an AI decision before it was sent, and that it was the same decision?

Order: the AI run receipt and the decision receipt are timestamped by Rightshold's clock, not yours. Write the decision receipt id into your send log, so each send points at the approval it relied on. A send logged before its decision, or with no decision id, is visible as a failure, not a footnote.

• Content: the approval is bound to action_sha256, the hash of the canonical JSON of the decision to be sent. verify_human_approval checks a decision receipt and that the action you show matches what was approved, so a different decision can't ride on the same yes.
• Edits: when the reviewer changes the draft, the AI receipt's output hash and the approved action's hash differ, and that difference is the evidence that the human changed the outcome. Track the change rate over time; zero changes across thousands of cases is a finding in itself.