GDPR Article 22 and Automated Decision-Making with Claude

Table of Contents

1. What GDPR Article 22 Actually Means
2. The Legal Threshold: When Article 22 Applies
3. Claude and Automated Decision-Making: The Risk Surface
4. Exceptions That Keep You Compliant
5. Building Audit-Ready Controls
6. Evidence Patterns and Documentation
7. Implementation Roadmap: What We Deploy
8. Common Failures and How to Avoid Them
9. Audit Preparation and Vanta Integration

---

What GDPR Article 22 Actually Means

GDPR Article 22 is straightforward in principle but devilishly complex in practice. The rule says: individuals have the right not to be subject to a decision based solely on automated processing—including profiling—that produces legal or similarly significant effects concerning them.

That’s the headline. The substance is narrower and broader at once.

Narrower: The decision must be “solely” automated. Human review exists, the rule doesn’t apply (though you still need to document what the human actually does). The effects must be “legal” or “similarly significant”—rejecting a loan application, denying insurance, flagging someone for fraud investigation, or removing account access all qualify. Sending a marketing email doesn’t.

Broader: Article 22 catches profiling—the automated analysis of personal data to predict or assess characteristics about a person. If Claude is scoring applicants, predicting churn risk, categorising customers for differential pricing, or flagging behaviour as suspicious, you’re profiling. If that profile feeds into a decision with legal or significant effect, and no human meaningfully reviews it, you’ve breached Article 22.

The UK ICO’s guidance on rights related to automated decision-making including profiling is the clearest statement of what triggers the rule. The European Data Protection Board’s guidelines on automated individual decision-making and profiling goes deeper into profiling scope and the definition of “legal or similarly significant effects.”

At PADISO, we see founders and operators misread Article 22 in two ways:

1. Overestimating scope: “We use Claude to draft emails, so we’re compliant.” No—that’s not automated decision-making. You’re using Claude as a tool; a human drafts and sends the email.
2. Underestimating scope: “We have a human review, so we’re fine.” Maybe not—if the human review is rubber-stamping, it’s not meaningful. Article 22 requires genuine human agency, not theatre.

The legal test is whether the human’s review is substantive enough to influence the outcome. If Claude recommends “reject,” and your human reviewer rejects 98% of Claude’s recommendations without reading the case, you’re still in breach. The human must be capable of, and actually does, override the system.

---

The Legal Threshold: When Article 22 Applies

Article 22 applies when three conditions are met:

1. Automated processing exists: Claude (or any AI model) processes personal data without human involvement at the decision point.
2. Profiling or decision-making occurs: The system scores, ranks, categorises, or predicts something about the individual.
3. Legal or similarly significant effects result: The decision causes material harm—rejection, denial, differential treatment, or reputation damage.

The GDPR text on Article 22 is worth reading in full. The practical threshold, though, comes down to: would a reasonable person feel this decision materially affects them?

Examples where Article 22 applies:

• Lending: Claude scores creditworthiness; the bank auto-rejects applications below a threshold. Legal effect: denial of credit.
• Insurance: Claude predicts claim frequency; underwriters price policies automatically based on Claude’s risk score. Significant effect: differential pricing.
• Hiring: Claude screens CVs and auto-rejects candidates scoring below percentile 30. Legal effect: exclusion from employment opportunity.
• Fraud detection: Claude flags transactions as suspicious; the system auto-freezes accounts. Significant effect: access denial and reputational harm.
• Content moderation: Claude auto-removes user posts without human review. Significant effect: exclusion from platform, reputational harm.

Examples where Article 22 does NOT apply:

• Claude drafts a customer service response; a human reviews and sends it.
• Claude ranks search results; users see them and choose whether to click.
• Claude suggests next steps in a workflow; a human decides whether to execute.
• Claude generates analytics; a human interprets and acts on them.
• Claude identifies data quality issues; a human decides whether to remediate.

The distinction hinges on whether the decision is automated, not whether the input is. If a human makes the decision—even if Claude informed it—Article 22 doesn’t apply. If Claude makes the decision and a human merely logs it, Article 22 does.

The Irish Data Protection Commission’s guidance on your rights in relation to automated decision-making clarifies this distinction with practical examples. The GDPR Local overview of Article 22 exceptions and safeguards explains the human oversight requirement in operational terms.

---

Claude and Automated Decision-Making: The Risk Surface

Claude is a large language model—a statistical pattern-matching engine trained on text. It’s not a database, not a rules engine, and not a workflow orchestrator. But it’s increasingly deployed in contexts where it acts like a decision-maker, and that’s where Article 22 risk emerges.

Why Claude specifically?

Claude has three traits that make it useful for decision-support but risky for Article 22 compliance:

1. Instruction-following: You can prompt Claude to score, rank, or categorise. “Rate this applicant 1–10 on cultural fit. Return only the score.” Claude will do it. The output looks authoritative, even if it’s probabilistic.
2. Reasoning transparency: Claude can explain its reasoning. That looks like accountability—but explanation isn’t the same as human review. A human reading Claude’s explanation and accepting it isn’t meaningful oversight; it’s deferral.
3. Scale: Claude can process thousands of cases in minutes. That speed tempts organisations to auto-execute on Claude’s output, skipping human review to save cost and time.

At PADISO, we’ve seen this pattern repeatedly: a founder builds a Claude-powered screening system, runs 500 applications through it overnight, and implements the top-ranked decisions without human review. That’s Article 22 breach, full stop.

The risk is highest in use cases with legal or significant effects:

• Credit and lending: Claude scoring creditworthiness or fraud risk.
• Insurance underwriting: Claude assessing claim likelihood or pricing.
• Employment: Claude screening candidates or flagging performance issues.
• Fraud and compliance: Claude flagging accounts, transactions, or users for investigation or action.
• Access control: Claude deciding whether to grant or revoke platform access, account privileges, or service eligibility.

Claude is not inherently Article 22-risky. Used as a tool—to draft, to suggest, to inform—it’s fine. Used as a decision-maker, it’s a compliance problem.

---

Exceptions That Keep You Compliant

Article 22 has three explicit exceptions. If you fall within one, you can use Claude for automated decisions without breaching the rule. If you don’t, you need human review.

Exception 1: Necessary for Contract Performance

You can make a solely automated decision if it’s necessary for entering or performing a contract with the data subject, and you provide safeguards.

What this means: If the individual consents to automated processing for a specific purpose (e.g., “I want instant account opening”), and you provide a right to human review, you’re compliant.

Example: A fintech uses Claude to instantly approve low-risk accounts for users who’ve opted in to automated onboarding. The system:

• Clearly informs users upfront that decisions are automated.
• Sets a threshold (e.g., only auto-approve if fraud risk < 5%).
• Provides a human review path for borderline cases.
• Allows users to request human review of any decision.

This is compliant because users consented, the decision is necessary for the contract (instant account opening), and safeguards exist.

What this does NOT mean: You can’t auto-reject someone without their consent. Rejection is not necessary for contract performance; it’s a denial of service. You’d need explicit consent or a different exception.

Exception 2: Authorised by Law

You can make a solely automated decision if it’s required or permitted by EU or member-state law, and the law provides safeguards.

What this means: If a regulator (e.g., ASIC in Australia, the FCA in the UK) has published rules requiring or permitting automated decisions in a specific context, and those rules include human review or appeal rights, you can rely on this exception.

Example: In Australia, ASIC RG 271 on credit licensing doesn’t explicitly require human review of credit decisions. But if ASIC published guidance saying “automated credit decisions are permitted if the lender provides a dispute mechanism,” you’d have cover.

Reality check: This exception is narrow. Most regulators don’t explicitly permit or require automated decisions. They’re often silent. Silence doesn’t grant permission.

At PADISO, when we work with financial services teams in Sydney on APRA, ASIC, and AUSTRAC compliance, we don’t rely on this exception. We assume it’s not available unless the regulator has explicitly published guidance.

Exception 3: Explicit Consent

You can make a solely automated decision if the individual has given explicit consent to the processing for that specific purpose.

What this means: The individual must affirmatively opt in to automated decision-making. Consent must be informed (they know what they’re agreeing to), specific (tied to a particular decision or use case), and freely given (no coercion).

Example: An insurance company offers a discount for customers who opt into automated underwriting. The consent form says: “We will use automated analysis to assess your claim. You can request human review at any time. If you don’t opt in, we’ll use standard underwriting (slower, no discount).” This is explicit consent.

What this does NOT mean: You can’t bury consent in terms and conditions. You can’t say “by using our service, you consent to automated decisions.” That’s not explicit. You need a separate, affirmative action.

The EDRi guide to automated decision-making under the GDPR walks through the consent requirement in detail. The Future of Privacy Forum’s research on Article 22 analyses how consent interacts with other safeguards.

---

Building Audit-Ready Controls

If you don’t fall within an exception, you need human review. But “human review” isn’t a checkbox. It’s a control with teeth. Here’s what audit-ready human review looks like.

Control 1: Decision Logging and Audit Trail

Every automated decision must be logged with:

• Input data: What personal data Claude processed.
• Claude’s output: The score, ranking, or recommendation.
• Human reviewer identity: Who reviewed the decision.
• Human review timestamp: When the review occurred.
• Human decision: What the human actually decided (approved, rejected, modified, escalated).
• Reason for human decision: Why the human agreed or disagreed with Claude.

This isn’t optional. Auditors (and regulators) will ask for this. If you can’t produce it, you’re non-compliant.

Implementation: Store this in a database with immutable audit logs. Don’t overwrite or delete records. Ensure logs are tamper-evident (hash-chained or digitally signed).

Control 2: Meaningful Human Review

Human review must be substantive, not rubber-stamping. This means:

• The human must have capability: They understand the decision domain and can interpret Claude’s output.
• The human must have authority: They can override Claude’s recommendation without escalation or penalty.
• The human must actually review: They read the case, consider the data, and make an independent judgment.
• The human must document reasoning: They record why they agreed or disagreed with Claude.

Red flags for non-compliance:

• Humans override Claude in < 1% of cases (suggests rubber-stamping).
• Humans never disagree with Claude’s recommendation (suggests deference, not review).
• No documented reason for human decisions (suggests no real review occurred).
• Humans review 1,000+ cases per day (insufficient time for substantive review).

Implementation: Set review workload caps. For high-stakes decisions (credit, employment, fraud), aim for 50–100 cases per human per day. For lower-stakes decisions, you can go higher. Train reviewers on the decision criteria and Claude’s limitations. Audit override rates monthly.

Control 3: Right to Human Review on Request

Individuals have the right to request human review of any automated decision. You must:

• Inform them of the right: At the point of decision, tell the individual they can request human review.
• Provide a mechanism: Email, form, phone line—make it easy to request.
• Deliver within timeframe: Respond within 30 days (or sooner if the decision is time-sensitive, e.g., job application).
• Assign a human: Not the same person who reviewed initially, if possible.
• Document the outcome: Log the request, review, and decision.

Implementation: Build a request form into your product. Trigger a workflow that assigns the case to a senior human reviewer. Set a 30-day SLA and monitor compliance.

Control 4: Transparency and Information Rights

When you make an automated decision, you must provide the individual with:

• Meaningful information about the logic: What data did Claude use? How did it weigh factors? (You don’t need to disclose the model weights, but you do need to explain the decision logic in plain language.)
• Significance of the decision: Why does this matter to them?
• Consequences: What happens if they disagree?
• Right to human review: How to request it.
• Right to contest: How to lodge a complaint with the regulator.

Implementation: Create a template notification that explains the decision in plain language. Include a link to a FAQ or help page. Send it to the individual at the time of decision, not buried in a confirmation email.

Control 5: Data Subject Rights Support

Individuals have the right to:

• Access: Get a copy of personal data Claude processed and the decision.
• Rectification: Correct inaccurate data.
• Erasure: Request deletion (with exceptions).
• Portability: Get data in machine-readable format.
• Object: Opt out of profiling or automated decision-making.

Implementation: Build these into your data subject request process. When someone requests access, include the data Claude processed, the decision, and the reasoning. When someone objects to automated processing, disable Claude for their account and revert to manual processing.

At PADISO, we embed these controls into security audit and compliance readiness engagements. We work with Vanta to document controls and generate audit evidence that satisfies SOC 2, ISO 27001, and GDPR auditors.

---

Evidence Patterns and Documentation

Compliance is evidence. Auditors don’t care what you say you do. They care what you can prove you did.

For Article 22, the evidence patterns are:

Evidence Pattern 1: Decision Records

What to collect:

• Database exports of automated decisions (with timestamps, inputs, outputs).
• Human review logs (reviewer identity, timestamp, decision, reason).
• Override rates by reviewer, by month, by decision type.
• Time-to-review metrics (to show reviews aren’t instantaneous rubber-stamps).

Format: CSV or JSON exports from your decision-logging system. Auditors will load these into their own tools to analyse patterns.

Red flags auditors look for:

• 0% override rate (suggests no real review).
• Average review time < 30 seconds (suggests no time to read the case).
• Same reviewer approving 95%+ of cases (suggests bias or deference).
• No documented reasoning (suggests review was procedural, not substantive).

Evidence Pattern 2: Process Documentation

What to write:

• Decision Policy: “We use Claude to score applicants. A human reviews all scores > 70. Humans can override scores < 70 if they have evidence.” (Be specific about thresholds and conditions.)
• Human Review SOP: Step-by-step instructions for reviewers. What data do they see? What criteria do they apply? When do they escalate?
• Training Records: Who trained reviewers? When? What did they learn? (Keep attendance sheets, quiz results, or certification records.)
• Approval Authority: Who has the authority to approve decisions? At what level? (This shows governance, not just process.)

Format: Documented in your policy management system (Confluence, SharePoint, etc.). Auditors will read these to understand your control design.

Evidence Pattern 3: Consent and Transparency Records

What to keep:

• Consent forms: Screenshots or PDFs of the consent language users saw. Timestamp when they consented.
• Notification templates: The exact text you send when you make an automated decision. Include the plain-language explanation of Claude’s logic.
• Right-to-review requests: Log of individuals who requested human review. Timestamp of request, timestamp of completion, outcome.
• Data subject requests: Log of access requests. What data was provided? When?

Format: Store in a data subject rights management system or spreadsheet. Auditors will sample these to verify you’re actually informing people and honouring their rights.

Evidence Pattern 4: Exception Documentation

If you’re relying on an exception (contract necessity, legal authorisation, explicit consent), document it:

• Contract necessity: The contract clause that requires automated processing. Evidence that users agreed to it.
• Legal authorisation: The regulation or guidance that permits automated decisions. Citation and date.
• Explicit consent: The consent form, timestamp, and user ID. Evidence that consent was specific and freely given.

Format: Attach to your decision policy or store in your consent management system.

---

Implementation Roadmap: What We Deploy

At PADISO, when we help operators implement Article 22 controls for Claude-powered decisions, we follow a phased roadmap. Here’s the sequence:

Phase 1: Decision Inventory (Week 1–2)

Goal: Understand where Claude is making decisions.

Steps:

1. Audit your codebase and product. Where does Claude output feed into a decision?
2. For each use case, assess: Does it trigger Article 22? (Automated + profiling + legal/significant effect?)
3. Categorise by risk: High (credit, employment, fraud), Medium (pricing, content), Low (suggestions, drafts).
4. Document in a spreadsheet: Use case, decision type, current human review (yes/no), risk level.

Deliverable: A decision inventory and risk map.

Phase 2: Control Design (Week 3–4)

Goal: Design controls for high- and medium-risk decisions.

Steps:

1. For high-risk decisions, design mandatory human review. Define thresholds, reviewer qualifications, SLA.
2. For medium-risk decisions, design risk-based review (e.g., review if Claude confidence < 80%).
3. Design the audit trail: What data do we log? Where? How long do we retain?
4. Design the transparency notification: What do we tell users when we make a decision?
5. Design the right-to-review process: How do users request human review? What’s the SLA?

Deliverable: Control design document, audit trail schema, notification template, right-to-review SOP.

Phase 3: Implementation (Week 5–8)

Goal: Build the controls into your product and operations.

Steps:

1. Audit logging: Integrate decision logging into your application. Log input, output, reviewer, decision, timestamp, reason.
2. Human review workflow: Build a dashboard for reviewers. Show Claude’s recommendation, supporting data, and a form to approve/reject/escalate.
3. Notification system: Trigger notifications when you make a decision. Include plain-language explanation and right-to-review link.
4. Right-to-review intake: Build a form or email inbox. Trigger workflow to assign to reviewer and set SLA.
5. Data subject rights: Integrate with your access-request process. When someone requests data, include Claude’s decision and reasoning.

Deliverable: Working controls in production.

Phase 4: Training and Process (Week 9–10)

Goal: Ensure humans actually review substantively.

Steps:

1. Train reviewers on the decision domain, Claude’s limitations, and the review criteria.
2. Document the SOP: What data do they see? What criteria do they apply? When do they escalate?
3. Set workload caps: 50–100 cases per day for high-risk, 200–300 for medium-risk.
4. Establish metrics: Override rate, average review time, escalation rate. Monitor monthly.
5. Conduct spot checks: Sample 5–10% of reviews. Did the human actually review? Is the reasoning documented?

Deliverable: Trained team, documented SOP, baseline metrics.

Phase 5: Audit Readiness (Week 11–12)

Goal: Prepare evidence for auditors.

Steps:

1. Export decision records for the past 3 months. Analyse: override rates, review times, reviewer distribution.
2. Compile process documentation: Decision policy, human review SOP, training records, approval authority matrix.
3. Compile consent and transparency records: Consent forms, notification templates, right-to-review requests.
4. If relying on exceptions, document the basis: Contract clause, regulation citation, consent form.
5. Conduct a self-audit: Walk through your controls. Are they working as designed? Are there gaps?

Deliverable: Audit evidence package ready for SOC 2 or ISO 27001 audit.

When we work with security audit and compliance teams, this roadmap is embedded into a broader SOC 2 or ISO 27001 engagement. We use Vanta to automate evidence collection and audit-readiness monitoring, so you’re not manually exporting CSVs and compiling spreadsheets every quarter.

---

Common Failures and How to Avoid Them

We’ve seen dozens of Article 22 failures. Here are the most common.

Failure 1: Rubber-Stamping Human Review

The pattern: A company logs human review in the database but doesn’t actually review. The “human” approves 99% of Claude’s recommendations in < 10 seconds per case.

Why it happens: Pressure to ship fast. The human review is treated as a compliance checkbox, not a real control.

How to avoid it:

• Set workload caps. If a reviewer processes > 200 cases per day, they’re not reviewing; they’re rubber-stamping.
• Monitor override rates. If a reviewer overrides < 5% of Claude’s recommendations, they’re likely deferring to the system.
• Spot-check reasoning. Sample 10% of reviews. Read the documented reason. Does it show independent judgment?
• Rotate reviewers. If the same person reviews 95%+ of cases, they become a bottleneck and a liability.
• Audit review time. If average review time is < 30 seconds, it’s too fast for meaningful review.

Failure 2: No Audit Trail

The pattern: A company uses Claude to make decisions but doesn’t log them. There’s no record of what Claude said, who reviewed it, or why the human decided what they decided.

Why it happens: Oversight or cost-cutting. Building audit logging feels like overhead.

How to avoid it:

• Design audit logging from day one. Don’t retrofit it later.
• Use immutable logs: hash-chained or digitally signed so they can’t be altered.
• Log at the point of decision, not retroactively. Retroactive logging is unreliable.
• Retain logs for at least 3 years (to cover audit cycles and potential disputes).
• Export and analyse logs monthly. Look for patterns that suggest rubber-stamping or bias.

Failure 3: No Transparency

The pattern: A company makes an automated decision but doesn’t tell the individual. They find out weeks later when they try to appeal.

Why it happens: Product teams don’t think about compliance. They focus on user experience, not legal requirements.

How to avoid it:

• Notify at the point of decision. Don’t wait for a confirmation email or statement.
• Include plain-language explanation. Don’t just say “Decision: Rejected.” Say why: “We analysed your application using automated tools. We assessed creditworthiness based on income, employment history, and credit history. Our system recommended rejection. A human reviewed this and agreed.”
• Include the right-to-review link. Make it obvious how to request human review.
• Test the notification with non-technical users. Can they understand what happened and why?

Failure 4: No Right-to-Review Process

The pattern: A company claims individuals can request human review, but there’s no actual mechanism. Requests go to /dev/null.

Why it happens: Compliance teams design the policy but don’t build the process.

How to avoid it:

• Build a real intake mechanism: form, email address, or phone line.
• Route requests to a queue. Assign to a human (ideally not the original reviewer).
• Set an SLA: 30 days for standard cases, 5 days for time-sensitive cases (e.g., job applications).
• Document the outcome: what was reviewed, what decision was made, why.
• Send a response to the individual. Tell them what happened and how to escalate if they disagree.
• Monitor SLA compliance monthly. If you’re missing deadlines, you’re not honouring the right.

Failure 5: Relying on Exceptions Without Documentation

The pattern: A company claims they’re exempt from Article 22 (contract necessity, legal authorisation, explicit consent) but can’t prove it.

Why it happens: Misunderstanding of the exceptions or assumption that intent is enough.

How to avoid it:

• For contract necessity: Document the contract clause that requires automated processing. Get legal sign-off that it’s truly necessary (not just convenient). Ensure the individual agreed to it.
• For legal authorisation: Cite the specific regulation or guidance. If it’s a European directive, include the official reference. If it’s a national law, cite the statute. Don’t assume silence = permission.
• For explicit consent: Keep the consent form, timestamp, and user ID. Ensure consent was separate (not buried in T&Cs), specific (tied to a particular use case), and freely given (no coercion). Be prepared to prove all three.

---

Audit Preparation and Vanta Integration

Article 22 compliance is one pillar of broader data protection and security audits. When you’re pursuing SOC 2 Type II or ISO 27001 certification, Article 22 controls are part of the evidence package.

How Article 22 Fits Into SOC 2

SOC 2 audits focus on five trust principles: security, availability, processing integrity, confidentiality, and privacy. Article 22 controls fall under privacy (CC6.1: The entity obtains or generates, uses, and communicates relevant, quality information regarding the objectives of processing personal data to support the functioning of internal controls) and processing integrity (PI1.1: The entity obtains or generates, uses, and communicates relevant, quality information regarding the objectives of processing to support the functioning of internal controls).

Auditors will ask:

• How do you identify automated decisions that trigger Article 22?
• How do you ensure meaningful human review?
• What audit trail do you maintain?
• How do you inform individuals of their rights?
• How do you respond to right-to-review requests?

How Article 22 Fits Into ISO 27001

ISO 27001 audits focus on information security. Article 22 controls fall under A.32.2: Rights of data subjects and A.32.1: Responsibilities and procedures. Auditors will ask:

• What processes do you have for honouring data subject rights?
• How do you manage right-to-review requests?
• What evidence do you retain of your decision-making?
• How do you ensure decisions are documented and auditable?

Vanta Integration

Vanta is a compliance automation platform that integrates with your systems to collect evidence and monitor control compliance in real-time.

For Article 22, Vanta can:

1. Ingest decision logs: Connect to your database and pull decision records (input, output, reviewer, decision, timestamp).
2. Monitor metrics: Track override rates, review times, and reviewer distribution. Flag anomalies (e.g., 0% override rate).
3. Automate evidence: Generate monthly reports of decision records and metrics. Auditors can download these directly from Vanta.
4. Track right-to-review requests: Integrate with your intake system (email, form, ticketing). Track request volume, response time, and outcomes.
5. Document policies: Store your decision policy, human review SOP, and consent templates. Auditors can review these in Vanta’s policy library.

When we work with clients on security audit and compliance readiness via Vanta, we design the Article 22 control architecture to be Vanta-native from day one. This means:

• Decision logging is structured for Vanta ingestion (specific fields, consistent timestamps).
• Metrics are calculated automatically (override rates, review times).
• Evidence is exported monthly without manual effort.
• Auditors can access evidence in Vanta’s portal, not via email and spreadsheets.

This reduces audit friction and keeps you audit-ready year-round, not just during the 2-week audit window.

We also work with CTO advisory teams across multiple locations to embed Article 22 controls into architecture decisions from the start. A fractional CTO in Sydney, Boston, Atlanta, or Washington DC can help you design systems that are compliant by default, not retrofitted later.

---

Summary and Next Steps

GDPR Article 22 is a real constraint on automated decision-making with Claude. It’s not a checkbox; it’s a control with teeth. But it’s not insurmountable.

The core principle: If Claude is making a decision with legal or significant effects on an individual, a human must meaningfully review it. That review must be documented, substantive, and auditable. The individual must be informed and have the right to request human review.

The three paths to compliance:

1. Human review: For most use cases, this is the path. Design a control where humans review Claude’s recommendations, have the authority to override, and document their reasoning.
2. Exceptions: If you fall within contract necessity, legal authorisation, or explicit consent, you can use exceptions. But you must document the basis.
3. Risk-based review: For low-risk decisions (e.g., Claude confidence > 95%), you can review a sample or set automated thresholds. For high-risk decisions, review all.

The implementation sequence:

1. Week 1–2: Audit where Claude is making decisions. Assess risk.
2. Week 3–4: Design controls. Document policies and processes.
3. Week 5–8: Build controls into your product and operations.
4. Week 9–10: Train your team. Establish metrics and monitoring.
5. Week 11–12: Compile audit evidence. Prepare for SOC 2 or ISO 27001 audit.

The evidence you’ll need:

• Decision records (input, output, reviewer, decision, timestamp, reason).
• Process documentation (decision policy, human review SOP, training records).
• Consent and transparency records (consent forms, notification templates, right-to-review requests).
• Exception documentation (contract clause, regulation citation, or consent form).

If you’re building AI products or modernising your tech stack with Claude, Article 22 should be a design requirement, not an afterthought. The cost of retrofitting compliance is 3–5x the cost of building it in.

At PADISO, we help founders, operators, and engineering leaders design compliant AI systems from day one. Whether you’re pursuing AI strategy and readiness in Sydney, working with a fractional CTO on architecture, or preparing for a security audit via Vanta, we embed Article 22 controls into your decision-making systems as a core requirement.

If you’re using Claude for automated decisions and aren’t sure whether you’re compliant, we recommend starting with an AI Quickstart Audit. In two weeks, we’ll tell you where you are, what you need to fix, and what 90 days of work could unlock. Fixed scope, fixed fee, delivered by operators who’ve shipped this before.

The regulation is clear. The controls are proven. The path forward is defined. What’s left is execution.