Skip to main content

GDPR Article 22: Implementing Human Oversight for Automated Decisions

GDPR Article 22 is not a general requirement that every AI output receive human review. Article 22(1) of Regulation (EU) 2016/679 concerns decisions based solely on automated processing, including profiling, that produce legal effects concerning a person or similarly significantly affect them. Article 22(2) creates limited exceptions, and Article 22(3) requires suitable safeguards, at least the right to obtain human intervention, express a point of view, and contest the decision. Keeptrusts can help with one important part of that picture: it can enforce a hard review stop in the output path so a sensitive route does not deliver model output directly. The surrounding decision workflow, reviewer authority, and contestability process still have to exist outside the gateway.

Use this page when

  • You are using AI in credit, employment, benefits, fraud, insurance, or similar decision workflows.
  • You need an implementation pattern for routes that must not produce straight-through automated outcomes.
  • You want a precise explanation of what Keeptrusts human-oversight does today.

Primary audience

  • Primary: Privacy officers, compliance teams, platform engineers
  • Secondary: Product counsel, case-management owners, security teams

The problem

Many systems are described internally as "decision support" even when the operational reality is close to automated decision-making. A model ranks job candidates, scores fraud cases, or recommends account actions. Downstream software then turns that output into a denial, escalation, or intervention with little or no meaningful review.

That is where Article 22 risk appears. The legal question is not whether AI was involved at all. It is whether the person was subject to a decision based solely on automated processing and whether that decision had legal or similarly significant effects. A screen where a reviewer clicks approve after reading nothing but the model score is not strong human oversight.

The technical problem is that most applications do not have a hard boundary between "model output exists" and "business action occurs." If the assistant returns content normally, product teams often wire it straight into the next step. That makes governance depend on process discipline rather than system behavior.

The solution

Keeptrusts gives you a simple but useful control for Article 22-sensitive routes: human-oversight can prevent ordinary delivery of assistant content. In the current runtime, when action: escalate is configured, the gateway returns an escalated result with null assistant content and emits a decision event with reason code oversight.required. That is not the whole safeguard package Article 22 demands, but it is a clear technical stop.

This matters because it separates model generation from business decisioning. The review application, case queue, or adjudication workflow can consume the event, present the supporting material to a human reviewer, and record the final outcome. That creates room for actual human intervention rather than symbolic approval.

You should also pair the review stop with upstream quality and grounding checks. If a route is going to drive a human decision, the material sent for review should not be weak, ungrounded, or missing basic rationale. quality-scorer and citation-verifier are the natural companions here.

There is one more architectural point: Article 22-sensitive traffic should usually live on its own route. Because current human-oversight behavior escalates all outputs on that route, it should not be mixed with ordinary chat or drafting traffic that users expect to receive immediately.

Implementation

The following configuration is suitable for a dedicated route where all model outputs must be reviewed before a human decision-maker sees or uses them in an adverse or significant decision workflow.

pack:
name: gdpr-article-22-review-route
version: "1.0.0"
enabled: true

providers:
targets:
- id: reviewed-decision-provider
provider: openai
model: gpt-5.4-mini-mini
secret_key_ref:
env: OPENAI_API_KEY
data_policy:
zero_data_retention: true
training_opt_out: true
retention_days: 0

policies:
chain:
- pii-detector
- quality-scorer
- citation-verifier
- human-oversight
- audit-logger

policy:
pii-detector:
action: redact
redaction:
marker_format: label
include_metadata: true

quality-scorer:
min_output_chars: 120
min_sentences: 2
assertions:
- type: contains
name: includes-explanation-language
threshold: 1.0
mode: enforce
severity: critical
config:
value: "because"

citation-verifier:
require_sources: true
require_source_match: true
output_action:
unverified_action: block

human-oversight:
action: escalate

audit-logger: {}

This route produces three useful behaviors. First, personal data is reduced before upstream routing. Second, low-quality or unsupported outputs are blocked instead of being sent for human review. Third, any output that passes those checks still does not reach the caller as normal assistant text. The route escalates and generates an event that downstream review software can act on.

That is the right point to attach the rest of the Article 22 safeguard model. The reviewer must have authority to depart from the model output. The person affected must have a path to challenge the decision. The organization must preserve records of the human intervention. Those are application and process responsibilities, not fields inside the human-oversight block.

The most relevant reference pages for this pattern are Configuration & Policy Overview, PII Detector, Data Routing Policy, EU AI Act Compliance, Meet EU AI Act Requirements with Pre-Built Controls, and Compliance Officer Guide.

Results and impact

The immediate effect is that automated outputs stop flowing directly into consequential workflows. Teams cannot accidentally claim there is human oversight when the system still behaves like straight-through automation. The route design itself enforces a pause.

That also improves auditability. A compliance team can inspect whether the review route was used, whether unsupported outputs were blocked, and whether the final business process consumed escalation events rather than raw assistant responses.

Just as important, the organization gains a cleaner architectural story. Article 22-sensitive decisions do not share the same interaction contract as ordinary productivity tools. That reduces ambiguity for engineering, legal, and reviewers alike.

Key takeaways

  • Article 22 is about specific decision scenarios, not all AI usage.
  • Current Keeptrusts human-oversight behavior is a route-level output escalation control with action: escalate.
  • A technical review stop is valuable, but it is only one part of the Article 22 safeguard package.
  • Pair review stops with quality and groundedness checks so human reviewers are not asked to act on unsupported outputs.
  • Keep Article 22-sensitive routes separate from ordinary assistant traffic.

Next steps