Avoiding the Article 22 Trap in AI Agent Orchestration

You wire up an OpenAI API node in Make. You point it at your customer support inbox. You tell it to read incoming refund requests, check Stripe for the transaction, and issue the refund if the item is under £50.

It works beautifully. The tickets disappear. Your ops manager stops spending three hours a morning clicking "approve". You feel like you've finally built a self-driving business.

Then a customer complains that they were denied a refund because of their postcode. You check the logs. The LLM hallucinated a policy. You've just made an automated decision without human intervention.

The Information Commissioner's Office calls this a breach of UK GDPR. You call it an operational headache. Both of you are right.

The Article 22 trap

The Article 22 trap is the legal liability you trigger when an AI agent makes a final decision about a person without meaningful human review.

Under UK GDPR, individuals have the right not to be subject to a decision based solely on automated processing if it produces legal or similarly significant effects. This was easy to avoid when AI just drafted marketing copy. Now that we have agentic AI, the line is blurred.

You connect Claude to your Pipedrive CRM. You let it score inbound leads and automatically email rejections to the ones that don't fit. You've just built an automated decision engine.

The ICO recently investigated AI in recruitment and found widespread issues. Their outcomes report highlighted that many systems fail to provide meaningful human oversight. The ICO doesn't care how clever your prompt engineering is. They care about the locus of control.

If a system filters out a candidate or denies a service, the law requires a human to have real influence over that outcome. This means a human must have the authority and the context to overturn the machine.

This isn't a hypothetical risk for enterprise companies. It applies to a 30-person logistics firm using AI to filter driver applications. It applies to a SaaS company auto-suspending accounts based on usage patterns.

As Kaizen AI notes, building trust requires active governance, not just buying a tool and hoping for the best. You need a system that proves a human was involved.

If your system fires the final action without a human explicitly saying "yes", you're exposed. The Article 22 trap catches founders who mistake operational speed for legal compliance.

Why notification-only workflows fail

Notification-only workflows fail because sending a Slack message after an AI agent takes action provides visibility, not oversight.

Most SMEs try to solve the oversight problem by adding a notification step. They build a Zapier flow that lets ChatGPT evaluate a supplier application, update the status in HubSpot, and send the rejection email. Then they add a final step. They send a Slack message to the ops channel saying the supplier was rejected.

They think this covers them. It doesn't.

This is a false safety net. The ICO doesn't care if you knew the decision happened. They care if you authorised it.

The exact point of failure is the sequence of the API calls. In a standard Zapier setup, the action node executes before the human sees anything. By the time your ops manager reads the Slack message, the email is already in the applicant's inbox. The automated decision has been made. The webhook has fired. The damage is done.

I see this constantly in operations audits. Founders think they're compliant because they have a log of what the AI did. But a log is just a receipt of a compliance breach. You're watching the car crash in the rear-view mirror.

The popular advice is to let AI run autonomously to save time. Vendors push you to remove the human entirely. But autonomy is exactly what the law restricts when individual rights are involved. You can't fix a structural legal requirement with a read-only Slack alert.

If the AI is making a call that impacts a human being, the workflow must stop. It must wait. A notification isn't an authorisation.

The mandatory human-in-the-loop architecture

Replacing linear automation with two-stage webhooks creates a physical pause in the workflow, ensuring the human operator acts as a final circuit breaker.

The mandatory human-in-the-loop architecture pauses an automated workflow right before the final action, forcing a human to explicitly approve or reject the AI's recommendation.

Here is what this looks like in practice for a recruitment triage process. A candidate submits their CV via a web form. The webhook hits n8n. n8n passes the PDF to the Claude API with a strict JSON schema, asking it to extract five specific skills and score the candidate out of ten.

This is where the standard build goes wrong. The standard build maps the Claude output directly to a Gmail node to send a rejection. It assumes the AI is always right.

Instead, n8n updates an Airtable base with the candidate details, the AI score, and a short text explanation of the reasoning. Then, n8n uses the Slack API to send an interactive block kit message to your HR channel. The message contains the summary and two buttons. One says "Approve for Interview". The other says "Reject".

The workflow stops. It waits. It does nothing else until a human intervenes.

When your HR manager clicks "Reject", Slack sends a payload back to a secondary n8n webhook. That second workflow looks up the Airtable record, marks it as human-reviewed, and finally triggers the Gmail node to send the rejection email.

The human is the circuit breaker. The AI acts as an incredibly fast junior analyst, prepping the file and making a recommendation. The human makes the decision.

Building this takes about two to three weeks. Expect to spend £6k to £12k depending on how messy your existing applicant tracking system is.

The most common failure mode here is button fatigue. If you send 400 Slack alerts a day, your staff will start clicking "Approve" without reading. You catch this by tracking the time between the Slack message arriving and the button click. If they're approving in under three seconds, you don't have meaningful human oversight. You have a reflex.

You fix button fatigue by batching approvals. Instead of real-time pings, n8n compiles a daily digest in Notion. The ops manager reviews the table at 3 PM, checks a box next to each row, and a scheduled run processes the approved actions.

Where the circuit breaker breaks down

The circuit breaker breaks down when you apply human-in-the-loop workflows to high-volume, low-impact decisions that overwhelm your staff.

If you receive 2,000 basic customer support queries a day, forcing a human to click "approve" on every AI-drafted reply will destroy your SLA. Your team will drown in Slack notifications. You'll end up paying a full-time salary just to click a button.

You need to segment decisions by risk. The law applies to decisions with legal or similarly significant effects. Denying a refund, rejecting a job applicant, or cancelling a contract fits that description. Answering a question about opening hours doesn't.

Before you build an interactive approval flow, audit the impact of the action. If the AI is just tagging an email in Outlook or routing a ticket to the right department in Zendesk, let it run autonomously. If it alters a commercial relationship or denies a person a service, you need the pause.

Don't build the pause if the underlying data is garbage. If your supplier inputs are scanned TIFFs from legacy accounting software, you need OCR first. The error rate jumps from 1% to 12%. Your human reviewers will spend more time fixing bad AI extractions than they would have spent doing the work manually. Fix the data ingestion before you build the approval layer. Bad data in a fast pipe just means you make bad decisions quicker.

Three questions to sit with

1. When your AI tools make a choice that affects a customer or applicant, does a human actively approve the action before it executes, or do they just get a notification after the fact?
2. If the Information Commissioner's Office asked for proof that your automated rejections involved meaningful human oversight, could you produce a timestamped audit log of human approvals?
3. Are your staff blindly clicking "approve" on AI recommendations because the volume of alerts is too high, turning your human-in-the-loop into a rubber stamp?