Who can stop the rejection emails?

Conceptual illustration generated with AI: an approval key is within reach, while the control to stop outgoing messages is behind glass.

A fictional story about an AI hiring rollout. All people and companies are invented.

The demo had gone well until Eva asked about the people who weren’t on the screen.

Clara had shown her the shortlist, the review button, and the dashboard that tracked every approval. At Larkmere Systems, where Clara led product, this was the final customer review before the hiring software went live.

“Can I see the applications it left out?” Eva asked.

Clara clicked back to the shortlist.

“You review every recommendation before it goes through.”

“That wasn’t my question,” Eva said. “And can I stop the rejection emails?”

Eva’s recruiting team was struggling with hundreds of applications. Managers wanted interviews booked. Candidates were waiting for answers. The software promised to reduce the time spent sorting applications, and another delay would leave the team doing that work by hand.

Clara knew those pressures. She also knew that the customer’s legal team wanted to understand how human oversight would work for this European rollout. She had prepared for questions about accuracy, security and the approval record.

She had not prepared for this one.

In the test account, Eva could approve the shortlist. That approval would also queue rejection emails for everyone outside it. Opening those applications required a different permission. Pausing the email batch required an administrator.

“There’s an escalation route,” Clara said.

“How long does it take?”

Clara didn’t know.

She started explaining the team’s testing. Halfway through a sentence about validation, she noticed Eva was still looking at the disabled button.

Clara stopped.

“Let me check that I understand. You’re being asked to approve a decision that affects people you can’t review. And if something looks wrong, you don’t know whether you can stop the emails in time.”

“Yes,” Eva said. “I need to know what I’m taking responsibility for.”

The distinction was uncomfortable. Clara’s team had built an approval step. Eva was asking whether she could make a different decision.

Clara asked the engineer on the call to show the workflow using Eva’s actual permissions. They followed what happened after approval. The engineer confirmed that an administrator could hold the batch, but they hadn’t tested how that request would work during a busy hiring day.

This did not establish that the ranking was wrong. It did establish a gap between the responsibility Eva was being offered and the control available to her.

“I don’t think we should switch on automatic rejections for this vacancy yet,” Clara said. “We need to test whether your reviewer can inspect a decision and get it stopped before an email goes out.”

The engineer could investigate the permissions and pause control. Eva would need her head of recruitment to confirm who could halt a decision, who would cover an absence and how much review time the team could realistically provide. Neither side could settle the whole problem alone.

“We still have the backlog,” Eva said.

“I know. Let’s put the extra work beside the risk we haven’t resolved and take that choice to the people who can authorize it.”

They ended with a recommendation to keep automated rejections off for that vacancy while the review route was tested. The launch owner still had to decide what could proceed. Nobody could promise that the change would be quick, or that the next test would pass.

Before closing the call, Clara replaced “Human review included” in her meeting notes with a more useful question: “What can the reviewer actually see, change, and stop?”

What changed in that conversation

Clara initially answered the question she had rehearsed: can we defend the product? Eva needed an answer to a different question: can I responsibly use it?

When Clara put Eva’s concern into plain words and checked it with her, they could examine the actual workflow. The conversation became useful before anyone had a complete solution. It helped them discover which decisions belonged to engineering, which belonged to the employer and what was still unknown.

That is one practical use of Human Authority: connecting the responsibility a person carries with the information, judgment and power they need to act. Clear communication can expose a missing control. It cannot supply the control, grant permission or establish legal compliance.

For your next product review, consider the moment when someone approves the output. What happens next? What would they need to see if they disagreed? Who could pause the action, and would that person be reachable in time? The answers may reveal a design problem, a staffing problem or a question the team has yet to ask.

Read The Access Problem to explore why knowing what matters, explaining it and having the authority to act can come apart under pressure.

Sources and context

These public materials informed the hypothetical setting. The story is invented and does not reconstruct a named case.

AI Act Article 14: Human oversight · AI Act Article 26: Deployer responsibilities · ICO: AI recruitment audits (2024)

If you prefer to continue privately, write to karina@karinacarlos.com with “Clara” in the subject. Share the part of the situation you want to examine, without names, client details or confidential material. I’ll reply with a question or distinction that may help you think through it. I won’t publish your message or identifiable details without your permission. Privacy notice: karinacarlos.com/privacy-policy.