Automated decision-making used to sound like something that happened in banks, insurers and large public-sector systems. That is no longer a sensible assumption.
Modern SaaS products make small automated judgements all the time. They score risk, route support tickets, flag unusual behaviour, prioritise leads, recommend next actions, approve or block account changes, rank candidates, detect abuse and personalise what users see next. Most of those decisions will not be legally significant. Some will be commercially significant. A few may affect people in ways that feel very real to them.
That is why the UK’s current data reform work matters for product teams, not just lawyers. The Data (Use and Access) Act 2025 received Royal Assent on 19 June 2025 and changes parts of the UK data protection framework. GOV.UK describes the automated decision-making shift as a more permissive framework, but one that still requires safeguards where decisions have legal or similarly significant effects.
At the same time, the ICO has been updating its approach. Its consultation on draft automated decision-making guidance opened on 31 March 2026 and closed on 29 May 2026. A new statutory instrument, The Data Protection Act 2018 (Code of Practice on Artificial Intelligence and Automated Decision-Making) Regulations 2026, came into force on 12 May 2026 and requires the Information Commissioner to prepare a code of practice covering AI and automated decision-making.
For UK SaaS teams, the practical message is straightforward: do not bolt an appeal inbox onto an automated decision after the product is already live. Design the decision as a user journey from the start.
The product problem hiding inside the compliance wording
The legal language talks about safeguards. Product teams should translate that into interface, workflow and evidence.
If a product makes a significant decision automatically, users may need to understand that a decision has happened, see useful information about it, make representations, challenge the outcome and obtain human intervention. Those are not policy documents. They are product interactions.
That means the question is not simply, “Are we allowed to use this model?” It is also:
- where does the user first learn that automation is involved?
- what does the user see when the decision affects them?
- how do they ask for human review?
- who inside the business receives that request?
- what information does the reviewer see?
- how is the outcome recorded?
- how does the product team spot patterns where the decision flow is producing unfair, confusing or commercially damaging results?
If those questions are left until the end, the answer usually becomes a fragile mix of support tickets, manual exports and someone in operations trying to reconstruct what happened. That is bad for users, bad for teams and bad for evidence.
Automation is not the risky bit on its own
The uncomfortable bit is often not the algorithm. It is the business process around it.
A simple rules engine can cause harm if it blocks an account with no explanation and no clear route to review. A sophisticated model can be manageable if it is used as decision support, checked by trained staff and wrapped in a decent audit trail. The practical distinction is not whether the software looks exciting. It is whether the product can show how the decision is made, reviewed and corrected.
That is especially important for SaaS companies adding AI features quickly. A model that starts as a productivity assistant can quietly become decision infrastructure. The product might move from “suggested response” to “auto-close this case”, or from “rank these records” to “only show the top-ranked records to the reviewer”. That shift changes the operational risk even if the user interface barely changes.
The sensible move is to identify decision points before they become invisible.
Treat decision points like product surfaces
Most teams already map user journeys for onboarding, billing and support. Automated decisions deserve the same treatment.
Start with an inventory of decision points, but do not stop there. For each point, map the visible and invisible parts of the journey:
- input: what data is used, where it came from and whether the user reasonably expects it to be used that way
- decision: whether the outcome is fully automated, human-assisted or merely a recommendation
- impact: what changes for the user, customer or third party
- explanation: what the product can say clearly without dumping technical noise on the user
- challenge: how the user asks for review or correction
- review: what a human reviewer needs to make a meaningful intervention
- evidence: what gets logged so the team can understand the decision later
This is product work because each of those points creates design choices. A vague banner saying “AI may be used” is unlikely to help anyone. A clear decision receipt, tied to the exact outcome and the next available action, is much more useful.
Build the review path before the first complaint
The weakest part of many automated decision flows is the review path.
It is easy to add a button labelled “appeal”. It is harder to make sure the appeal lands with the right person, includes enough context, pauses the right downstream actions and produces a response the user can understand. That is the difference between a decorative safeguard and a working one.
For a SaaS product, a review path may need:
- a structured reason field rather than a blank support message
- a way to attach evidence or correct input data
- an internal queue with priority, ownership and service levels
- access to the data and model or rule output that shaped the decision
- a decision log showing who reviewed it and why the outcome changed or stayed the same
- notifications that keep the user informed without exposing sensitive internal detail
This is not glamorous work, but it is where trust is won. Users rarely care whether a decision came from a model, a rules engine or a workflow automation tool. They care whether the outcome makes sense and whether they can get a meaningful answer when it does not.
Human intervention needs to be meaningful
Human review is not automatically meaningful because a person clicks approve.
If the reviewer is shown a preselected outcome, given no real discretion, measured only on throughput and denied the information needed to challenge the system, the product has not created a serious safeguard. It has created a rubber stamp with a nicer label.
That has product implications. Reviewer tools need to show the relevant inputs, confidence, policy basis, previous user history where appropriate, and a clear route to override or escalate. They also need to make it easy to record the reasoning. If writing a good review note takes three times longer than approving the automated outcome, the interface is quietly pushing the business towards shallow review.
Good internal tools are part of the customer experience here. The user may never see them, but they determine whether the promise of human intervention is real.
Design for explainability at the right level
Explainability is often discussed as though every user needs a technical account of model behaviour. Most do not.
What users usually need is a clear explanation of the decision that affects them, the main categories of information involved, what they can do next and how to challenge incorrect data or context. Technical detail may matter for auditors, enterprise buyers, legal teams or internal reviewers, but the product should not confuse more disclosure with better communication.
A good pattern is layered explanation:
- a short, plain-language message at the point of impact
- a more detailed help or policy page for users who want context
- an internal decision record for support, compliance and product teams
- deeper technical documentation for audit, procurement and governance conversations
This keeps the user journey usable while still giving the organisation proper evidence.
Why this is commercially useful, not just defensive
Enterprise buyers increasingly ask how vendors use AI, profiling and automation. They are not only worried about headline legal risk. They are worried about operational mess: unexplained decisions, angry users, biased outcomes, weak support processes and vendors who cannot answer basic questions about how their own product behaves.
A SaaS team with a clear decision map, review workflow and audit trail can respond differently. It can show that automation is controlled, observable and designed into the product. That helps sales, support, product governance and engineering at the same time.
It also improves product quality. Decision logs reveal where rules are too blunt, where model outputs drift, where users misunderstand a workflow and where internal teams keep overriding the system. That is valuable product feedback. If the only record of challenge is scattered across support tickets, the team loses the learning.
What to do next
Teams do not need to wait for the final ICO code of practice before doing useful work. The direction of travel is already clear enough.
Start with the highest-impact automated decisions in the product. Map them as journeys. Check whether the user is told enough at the right moment. Add a challenge route that a real person can operate. Give reviewers the tools and authority to make a meaningful intervention. Log outcomes in a way product, support and compliance teams can actually use.
Then make it part of normal delivery. New AI-assisted workflows, scoring systems and rule-based automations should have the same design review as onboarding, payments or permissions. If the decision affects someone materially, the surrounding journey matters as much as the model.
The products that handle this well will not feel like compliance projects. They will feel calmer, more trustworthy and easier to support. That is exactly the sort of boring advantage that compounds.