Automated decision making is a legal category before it is a technology category. The phrase has a specific meaning under GDPR Article 22, additional meanings in U.S. sectoral law (ECOA, FCRA), and a looser meaning in vendor marketing. The three readings come apart fast under audit. This guide gives you the operational definition, the three contexts where automation works, the three where the system must refuse, and the four artefacts that make a deployment defensible to a regulator.
Key takeaways
- **It is a legal category first:** GDPR Article 22, ECOA, and FCRA all impose specific obligations when a decision is made solely by automation and produces a legal or similarly significant effect on a person.
- **Three contexts where automation works:** repetitive rule-bound decisions, recoverable outcomes, and high-volume screening that includes refusal. All three keep a person reachable when needed.
- **Three contexts where the system must refuse:** irreversible legal effects, unverifiable inputs, and decisions that fall under GDPR Article 22 without a lawful basis or safeguards.
- **Four artefacts make it defensible:** scope statement, constraint set, refusal contract, audit trail. Each is short, current, and reviewable.
- **Refusal is the regulatory hinge:** Regulators do not require zero automation. They require that the system can refuse, route, and explain, with the audit trail to prove it.
A working definition of automated decision making
Automated decision making is the production of a binding outcome by software, without a human in the decision path at the moment of commitment. The outcome can be a credit approval, a price adjustment, a claim payout, a routing instruction, or a refusal. The defining clause is "without a human in the decision path", not the presence of AI. Many fully automated decisions involve no machine learning at all, and some AI deployments keep a person in the path and therefore fall outside the regulatory category.
The two clauses that matter operationally are solely automated and significant effect. GDPR Article 22 (EU GDPR Article 22) prohibits "a decision based solely on automated processing, including profiling, which produces legal effects concerning him or her or similarly significantly affects him or her", except under three lawful bases: contract necessity, explicit consent, or authorising EU/Member State law. Each lawful basis requires specific safeguards, including the right to obtain human intervention.
For the broader anatomy of how this fits into a system, our pillar on what a decision system actually is describes the five components that surround the automation.
ADM under regulation: GDPR Article 22 and beyond
The GDPR Article 22 obligation is the most cited but not the only one. Sectoral laws in the United States impose comparable obligations through different mechanisms.
The Equal Credit Opportunity Act and Regulation B require an adverse-action notice with specific reasons whenever credit is denied, automated or not. The Fair Credit Reporting Act requires similar disclosure when consumer reports are used. New York City Local Law 144 imposes bias-audit and notice requirements on automated employment-decision tools. California's CPRA grants comparable rights to opt out of ADM in some contexts. None of these regimes prohibit automation outright. Each requires that the automation be defensible: scoped, explainable, and reversible by request.
The common thread is that the regulator does not care whether a model was involved. It cares whether the person affected can request human review, obtain reasons, and challenge the outcome. The four artefacts below are how a deployment proves it can.
Where automation works, and where it refuses
Three operational contexts hold up well under both audit and production. Three do not.
Works: repetitive, rule-bound, low-variance decisions. Credit-limit increments within an approved ceiling, claim triage routing, transaction categorisation, scheduling within a published policy. The decisions are made hundreds of times an hour. The variance between them is small. A person does not add information beyond what the rule already encodes. Automate freely with audit.
Works: recoverable outcomes. Price updates inside published ranges, content moderation actions a user can appeal, routing decisions a downstream agent can re-route, content surfacing that the reader can dismiss. The cost of a wrong commitment is bounded because the commitment can be undone. Audit logs and an appeal path are the safeguards.
Works: high-volume screening that includes refusal. Sanctions screening, anomaly detection, fraud screening. The system makes a decision on most cases automatically and refuses on a small share, surfacing those for human review. The work is in tuning the refusal threshold so reviewers focus on the cases where their judgement is load-bearing, a pattern our guide on human oversight in the loop describes in detail.
Refuses: irreversible legal effect. Contract execution, prescription, release-on-recognisance, capital allocation above a threshold. The cost of a wrong commitment exceeds the cost of a slower commitment. The system refuses and routes to a person with authority.
Refuses: unverifiable inputs. A KYC record that exists somewhere in the organisation but cannot be produced at the point of decision. A self-attested claim that cannot be corroborated. Treat missing-but-claimed as missing.
Refuses: GDPR Article 22 territory without lawful basis or safeguards. A solely-automated decision with significant effect, where the lawful basis is unclear or the safeguards (right to human intervention, right to obtain reasons, right to contest) are not wired in. The system refuses to commit and routes to the human path.
The four artefacts of defensible automation
A deployment that holds up under regulator scrutiny carries four artefacts. Each is short. Each is current. Each is reviewable by someone in your organisation in an afternoon.
The scope statement. One page. Lists the decisions the system is authorised to make and the decisions it is not. Updated by the same change-control that governs other policy artefacts.
The constraint set. The rules the gate evaluates. Written as code or configuration, not as a slide deck. Reviewable by a compliance reader with no machine-learning background.
The refusal contract. An enumerable list of conditions under which the system refuses to act, in plain language. The list should be short, ideally fewer than ten items. The reason this list is the most important artefact is the same reason refusal sits at the centre of our approach: a deployment that cannot say what it will not do cannot be held accountable for what it does. The companion guide on decision intelligence platforms walks through the same refusal-first evaluation lens.
The audit trail. Append-only log of every commitment and every refusal, including inputs, evidence consulted, rule applied, model output (if any), and actor identity. Built into the platform, not stitched together at incident time.
When these four artefacts exist and are kept current, the deployment is defensible against most regulator inquiries. When any one is absent, the deployment is exposed regardless of how often it produces a correct outcome.
A practical closing
Automation under regulation is not a question of how much to automate. It is a question of where automation must stop, what the system says when it stops, and how the stop is logged. Regulators do not require zero automation. They require that the system can refuse, route, explain, and be replayed afterward. The four artefacts above are how a deployment proves that to a regulator. They are also how an internal auditor proves it to themselves before the regulator asks.