GDPR and Automated Decisions: Using Policy-as-Code to Stay Compliant

Category: Government & Regulated Industries | Reading time: 6 min

---

Article 22: The AI Clause Nobody Budgets For

Article 22 of GDPR gives individuals the right not to be subject to decisions based solely on automated processing that produce significant effects concerning them. This includes decisions that affect creditworthiness, employment screening, insurance pricing, content moderation, and access to services.

The compliance response to Article 22 usually involves one of three approaches: ensuring a human is meaningfully involved in automated decisions, offering individuals the right to challenge automated decisions, or obtaining explicit consent for fully automated processing.

What most organisations get wrong is treating these as policy commitments — documented in a privacy notice, described in a DPA, stated in a procedure. Policy commitments require enforcement to be meaningful. When your AI processes thousands of decisions per day, human involvement as a commitment means very little if the system doesn't enforce it.

---

The Article 22 Compliance Gap

Here's how Article 22 compliance typically breaks down in practice:

Intent: "We ensure a human reviews all automated decisions with significant effects."

Reality: The human review step is in the workflow. But:

• Reviewers approve 98% of AI recommendations without meaningful examination ("rubber stamping")
• High-volume periods create pressure to process faster, reducing review quality
• The review step can be bypassed if the reviewer marks a case "reviewed" without actually examining it
• The audit trail shows "reviewed by [name]" but doesn't show whether the review was substantive

GDPR DPA view: This is the form of human involvement without the substance.

Policy-as-code in the Taos kernel changes this by making human involvement a technical requirement, not a procedural one.

---

Encoding Article 22 Compliance as Policy

For a credit assessment workflow:

package taos.financial.credit_assessment

# Article 22 compliance — human review required for significant effects
require_human_review_article22 {
    input.decision_type == "credit_approval"
    input.significant_effect == true
}

require_human_review_article22 {
    input.decision_type == "credit_denial"
}

require_human_review_article22 {
    input.decision_type == "interest_rate_determination"
    input.rate_differential_pct > 2.0
}

# Substantive review — not just a checkbox
require_substantive_review {
    require_human_review_article22
    input.minimum_review_time_seconds < 30  # Less than 30 seconds = likely rubber stamp
}

action = "require_approval" { require_human_review_article22 }
required_role = "credit_officer" { require_human_review_article22 }

# Flag potential rubber-stamping for compliance monitoring
rule_fired = "substantive_review_flagged" { require_substantive_review }

The policy doesn't just require human review — it monitors review time as a proxy for substantive engagement and flags cases where the review may not have been meaningful.

---

The Right to Explanation: Audit Trail as Evidence

GDPR Article 22 also supports the right to explanation — when a decision is made by automated means, the individual has the right to understand the logic involved.

The Taos audit log for a credit assessment contains:

{
  "decision_type": "credit_denial",
  "policy_version": "credit_policy_v8",
  "rule_fired": "deny_insufficient_income_ratio",
  "policy_inputs": {
    "income_to_debt_ratio": 0.42,
    "threshold": 0.50,
    "employment_status": "contract"
  },
  "human_review": {
    "reviewer": "credit_officer.wu",
    "review_duration_seconds": 145,
    "decision": "upheld",
    "note": "Insufficient income ratio confirmed, contract employment increases risk"
  }
}

When the individual requests an explanation, you have the specific rule that fired, the exact values that triggered it, and the human reviewer's decision and rationale. This is a substantive explanation — not "an automated system assessed your application," but "your income-to-debt ratio was 0.42, below our threshold of 0.50, and the credit officer reviewed and upheld this assessment."

---

Data Minimisation in AI Workflows

GDPR Article 5(1)(c) requires data minimisation — personal data processed should be adequate, relevant, and limited to what is necessary. AI workflows are particularly prone to violating this principle: LLMs tend to process everything they can see, and agents may access more data than the specific task requires.

Taos addresses this through the allowed_tools and prohibited_data_sources fields in the ART token:

{
  "workflow": "credit_assessment",
  "allowed_data": [
    "income_records",
    "existing_debt_records",
    "employment_status"
  ],
  "prohibited_data": [
    "health_records",
    "political_affiliations",
    "social_media_profiles",
    "ethnic_origin_indicators"
  ]
}

The AI cannot access prohibited data sources, regardless of what the LLM might attempt to infer or request. Data minimisation is enforced at the kernel layer — not as a training constraint on the LLM, but as a hard tool-access limit.

---

Purpose Limitation: Preventing Model Drift

GDPR Article 5(1)(b) requires purpose limitation — data collected for one purpose cannot be used for a different, incompatible purpose. This is a significant risk with AI systems that can find patterns across data sources.

Policy-as-code enforces purpose limitation by scoping what data the AI can access in each workflow type:

# Credit assessment workflow: no access to marketing or targeting data
deny_purpose_violation {
    input.workflow_type == "credit_assessment"
    input.data_source_type == "marketing_profile"
}

deny_purpose_violation {
    input.workflow_type == "credit_assessment"
    input.data_source_type == "social_media"
}

action = "deny" { deny_purpose_violation }
rule_fired = "gdpr_purpose_limitation" { deny_purpose_violation }

If the AI attempts to access a data source outside its workflow's permitted scope, the kernel denies the access and records the attempt in the audit log. The purpose limitation isn't just documented — it's enforced.

---

The DPA Meeting: Demonstrating Technical Controls

When meeting with your Data Protection Authority to demonstrate GDPR compliance for AI systems, the Taos governance approach enables a concrete technical demonstration:

1. Show the policy bundle: "Here are the Article 22 rules encoded in Rego — this is what governs our automated decisions."
2. Show the audit log: "Here is the record of every automated decision, the rule that fired, and the human review."
3. Demonstrate a live test: change a policy threshold in the control plane, run a decision, show the new rule applying immediately.
4. Show the data access controls: "Here is what data sources the AI can access, and here is where access is prevented."

This is the difference between a compliance assertion ("we follow GDPR") and a compliance demonstration ("here is our technical implementation").

---

The Bottom Line

Article 22 compliance for AI is not a privacy notice update — it's an engineering requirement. Human involvement must be technically enforced, not just procedurally described. Data minimisation must be technically constrained, not just documented. Purpose limitation must be technically bounded, not just asserted.

Policy-as-code in the Taos governance kernel makes these requirements technically enforceable. Your GDPR compliance is as strong as your controls — make the controls real.

---

Tags: GDPR, Article 22, automated decisions, data minimisation, purpose limitation, AI governance, DPA, privacy law