Building an Automated Decision Register: Governing the Decisions AI Actually Makes (2026)

Table of Contents

Summarize and analyze this article with
ChatGPT

Chat GPT

ChatGPT

Perplexity

 
ChatGPT

Grok

 
ChatGPT

Google AI

ChatGPT

Claude

 

Why a complete AI inventory still misses decisions

Here is a question supervisors keep surfacing: our AI inventory is complete and signed off, so why are we still finding automated decisions we did not know we were making? The answer is structural. An AI inventory is organized around a technology. The rule that bites is organized around a decision. Article 22 of the General Data Protection Regulation, which has applied since 25 May 2018, asks two questions, and neither is about sophistication: was the decision based solely on automated processing, and did it produce legal effects or similarly significantly affect the person. A rules engine nobody has touched in a decade satisfies the first limb as easily as a model does, and it is almost certainly absent from your AI register. The fix is a second register, organized around decisions rather than systems.
This guide sets out what goes in a decision register, how to use it, and where teams get it wrong. It is a practical method, not legal advice.

What goes in the register

One row per decision, not per system. A single fraud platform may produce a soft flag, a temporary hold, an account restriction, and a permanent offboarding. Those are four decisions with four different effects on a person, and they cannot share a row. Start from the effect and work back to the system, never the reverse.
Field What to record Why it matters
The decision One row per decision, not per system A single platform makes many decisions with different effects
The effect Language of consequence: “cannot access funds”, “claim denied”, “account closed” This field decides whether the significant-effect limb is met at all
Two-part scope Solely automated: yes/no. Legal or significant effect: yes/no A decision failing the second limb is out of scope; record that explicitly
Article 22(2) route Contract necessity, Union or Member State law, or explicit consent If nobody can name the route in one sentence, you have found a gap
Human assessment position Before or after the effect, plus the queue, service level, and median time Whether a human is involved, and whether they act before the consequence lands
Reviewer and authority The role, what they are shown, what they can override, their authority Someone shown a score and two buttons is performing an approval step
Model or rules Last, and deliberately last It matters for model risk and the AI Act, but does not decide scope here
The model-or-rules field is last for a reason. It matters for model risk management and for the EU AI Act, where high-risk obligations covering credit scoring (which expressly excludes fraud detection) and pricing for life and health insurance now apply from 2 December 2027, after the Digital Omnibus (Regulation (EU) 2026/1744, in force 27 July 2026) deferred the original 2 August 2026 date. It does not decide whether a decision is in scope for Article 22.

How to use it once you have it

Sort by effect severity, then look at the rows where no human is in the process at all. That is the first remediation queue, and it is usually short enough to clear in a quarter. Then look at the rows where a human is involved only after the consequence has landed, and ask whether that design survives being described out loud to a supervisor. For each row there are three honest outcomes: move the assessment in front of the effect; convert the automated action into a genuinely time-bounded interim measure with the durable decision reserved to a person; or record the Article 22(2) route and the safeguards that go with it. Guessing is not on the list.

Then audit the review path itself, including the identity checks bolted onto the front of it. On 11 August 2026 the California Privacy Protection Agency Board issued a decision requiring a data broker to pay 116,490 dollars, alleging among other things that it required Californians to provide the last four digits of their Social Security number before they could opt out of the sale of their personal information, which the agency treated as a data-minimization violation. The identity proofing in front of a review queue is regulated too.

What usually goes wrong

  • The register is built by the AI governance function alone. Staffed from the AI inventory, it never captures the rules-based decisions. The people who know where those live sit in operations and financial crime, not in model risk.
  • The before-or-after column is filled from policy, not data. Policy says review precedes action. The queue metrics say the median wait is nine days and the override rate is under one percent. Pull the numbers before you fill in the column, because someone else eventually will.

Where PiTech fits

PiTech Solutions builds decision registers and the review controls behind them for organizations in regulated industries: the decision inventory across models and rules engines, the effect and scope analysis, the human-review workflows and service levels, and the audit trail that answers the question a supervisor actually asks, what happened to this person and who decided it. It works across operations, financial crime, and model risk, which is where the decisions actually live. Delivery runs under CMMI Level 3 and ISO 27001, 9001, and 42001 certifications. See AI, GenAI and ML, Process Solutions, and Data Solutions. PiTech Solutions Inc. is headquartered in Durham, North Carolina (UEI GNLRY5LNNVH6, CAGE 530K4) and is distinct from similarly named companies.

The bottom line

A register like this takes a few weeks and answers what a supervisor asks: what happened to this person, and who decided it. Build it around decisions and effects, place human assessment relative to the consequence, and pull the numbers before you fill in the columns.

Frequently Asked Questions (FAQs)

What is an automated decision register?

An automated decision register is a record organized around decisions that affect people, with one row per decision rather than per system. For each decision it records the effect in the language of consequence, whether the decision is based solely on automated processing, whether it produces a legal or similarly significant effect, the lawful route under Article 22(2) where one is needed, where human assessment sits relative to the effect, who the reviewer is and what authority they hold, and finally whether the decision is driven by a model or by rules. It complements, rather than replaces, an AI inventory, capturing the rules-based decisions an AI inventory misses.

An AI inventory is organized around technology: it lists the models and AI systems an organization runs. A decision register is organized around decisions and their effects on people. The distinction matters because the rules that bite, such as GDPR Article 22, are triggered by a decision being solely automated and significantly affecting a person, not by how sophisticated the technology is. A rules engine that has not changed in a decade can trigger Article 22 while being absent from the AI inventory entirely. The register catches those decisions by starting from the effect and working back to the system, which an inventory never does.

Article 22 of the GDPR, in force since 25 May 2018, gives people the right not to be subject to a decision based solely on automated processing that produces legal effects concerning them or similarly significantly affects them. Whether it applies turns on two questions: was the decision based solely on automated processing, and did it produce a legal or similarly significant effect. Where a solely automated decision does significantly affect a person, it must rest on one of three routes: necessity for a contract with the person, authorization under Union or Member State law, or the person’s explicit consent, with safeguards including a right to human intervention. Sophistication is not part of the test.

Start from the effect, not the system. For each decision, write the effect in the language of consequence, for example “customer cannot access funds”, “application declined”, or “account closed”, then answer two questions: was it based solely on automated processing, and does that effect count as legal or similarly significant. A decision that is solely automated and significantly affects a person is in scope, and you then need to name the lawful route. Rules-based decisions matter here as much as model-driven ones, so involve operations and financial crime, who know where those decisions live, rather than relying on the AI inventory.

Where a solely automated decision significantly affects a person, one of three routes must carry it. The first is necessity for entering into or performing a contract between the person and your organization. The second is authorization by Union or Member State law that lays down suitable safeguards. The third is the person’s explicit consent. For each in-scope decision, name the route in a single sentence. If nobody can name a route, that is a gap to close rather than a paperwork exercise, and closing it usually means redesigning where human assessment sits or reserving the durable decision to a person.

There are two separate questions. Whether a human is in the process at all decides whether the decision is solely automated. Whether the human review arrives before or after the consequence lands decides how defensible the design looks. Record the position as a binary, before or after, and record the evidence behind it: the review queue, the service level, and the median time between the automated outcome and the human review. A review that arrives days after funds are frozen is very different from one that precedes the freeze, even though both may be described in policy as human oversight.

The AI Act matters for the model-or-rules field and for high-risk obligations, but it does not decide whether a decision is in scope for Article 22. Under the AI Act, high-risk obligations covering credit scoring, which expressly excludes fraud detection, and pricing for life and health insurance now apply from 2 December 2027, after the Digital Omnibus (Regulation (EU) 2026/1744, in force 27 July 2026) deferred the original 2 August 2026 date; Article 50 transparency duties were not deferred. A decision register helps you see which decisions will attract those high-risk obligations, but the register’s core purpose, catching significant automated decisions, stands on Article 22 regardless of AI Act timing.

Not the AI governance function alone. When the register is staffed only from the AI inventory, the rules-based decisions never arrive, because the people who know where those live sit in operations and financial crime, not in model risk. Ownership should span those functions, with governance coordinating. Equally important, the before-or-after column should be filled from queue data, not from policy documents: policy may say review precedes action while the metrics show a median wait of days and an override rate near zero. Cross-functional ownership and evidence from real numbers are what make the register accurate rather than aspirational.

A workable register can be built in a few weeks, because its value comes from structure and honesty rather than from exhaustive tooling. The work is inventorying decisions across models and rules engines, writing each effect in the language of consequence, answering the two-part scope question, naming the Article 22(2) route where needed, and recording where human review sits with the queue evidence behind it. The output is a prioritized remediation list: the decisions with no human in the loop, then the ones where the human arrives after the effect. Starting narrow, around the highest-severity effects, produces a usable register quickly.

Yes. PiTech Solutions builds decision registers and the review controls behind them for organizations in regulated industries: the decision inventory across models and rules engines, the effect and scope analysis, the human-review workflows and service levels, and the audit trail that answers what happened to a person and who decided it. It works across operations, financial crime, and model risk, which is where the decisions actually live, rather than treating this as an AI-inventory exercise. Delivery runs under CMMI Level 3 and ISO 27001, 9001, and 42001 certifications. PiTech is positioned as a specialist partner for decision governance in regulated industries at a mid-market price.