When Profiling and Automated Decision-Making Applies and What to Do Next

Profiling and automated decision-making applies when a SaaS workflow uses personal data to evaluate people, predict behaviour, rank risk, influence treatment, or make decisions about individuals. The practical response is not to freeze every product idea. It is to classify the workflow, identify the human and business impact, assign an owner, and add safeguards that match the risk.

Under the GDPR, profiling is automated processing of personal data used to evaluate personal aspects of a natural person. Automated decision-making means a decision made by technological means without human involvement. Article 22 is narrower: it is most relevant when a decision is based solely on automated processing, including profiling, and produces legal effects or similarly significant effects for the person.

That distinction matters for SaaS teams. A score, flag, recommendation, queue, or rule can require privacy controls even when Article 22 does not apply. The team still needs a lawful basis, transparency, data minimisation, accuracy checks, security, retention limits, rights handling, and evidence. For mistakes to avoid, read common profiling and automated decision-making mistakes. For delivery mechanics, use the operational workflow guide.

The simplest trigger question

Start with one product question: does this workflow use personal data to evaluate, score, rank, predict, classify, recommend, approve, reject, suspend, prioritise, route, or price an individual?

If the answer is yes or maybe, open a profiling review. That review can be short for low-risk workflows. It should become deeper when the output affects access, eligibility, enforcement, pricing, employment-like evaluation, finance, education, health, safety, or another important opportunity.

Do not wait for the feature to be called "profiling." Teams usually use operational labels such as risk score, trust score, lead score, customer health, abuse signal, model output, AI recommendation, enrichment, moderation queue, priority logic, or eligibility rule.

When profiling usually applies

Profiling usually applies when the system evaluates a person or infers something about them. A SaaS platform may profile users, customer admins, end customers, employees, leads, applicants, fraud suspects, support requesters, or marketplace participants.

Common examples include fraud risk scoring, user trust scores, behavioural segmentation, churn prediction, lead scoring, productivity analytics, workplace monitoring, customer health scores tied to named contacts, identity verification risk levels, moderation risk, security risk ranking, personalised pricing, eligibility checks, and AI outputs that classify a person.

The system does not need to make the final decision for profiling to exist. A human can use the score as input and the workflow may still involve profiling. The key question is whether automated processing evaluates personal aspects of an individual.

When Article 22 may apply

Article 22 is the higher-risk subset. It may apply when three elements come together: the decision is based solely on automated processing, the decision concerns an individual, and the decision produces legal effects or similarly significant effects.

"Solely automated" means there is no meaningful human involvement. A human who only accepts the machine output without authority, time, context, or ability to change the outcome is weak evidence. Meaningful review requires a person who can understand the case, challenge the output, and change the decision.

Legal effects change legal rights or legal status. Similarly significant effects can materially affect a person's circumstances, behaviour, opportunities, access, or treatment. In SaaS, examples may include automatic account closure, denial of an important service, significant eligibility decisions, material pricing outcomes, severe moderation outcomes, employment-related decisions, credit-like decisions, or automated restrictions that seriously affect a user.

If Article 22 applies, the team needs a permitted route and suitable safeguards. Depending on the facts, safeguards may include human intervention, a route for the person to express their point of view, and a way to contest the decision.

Cases that may not be profiling

Some automation uses personal data but does not evaluate the person. A renewal reminder based on contract date, a language-based support route, a duplicate ticket check, a required-field validation, or a workload queue may involve personal data without assessing personal aspects of the individual.

That does not mean the workflow has no privacy obligations. It may still need lawful basis, access controls, retention limits, and transparency. It simply may not need the additional profiling or Article 22 analysis.

The useful test is purpose and effect. Is the system organising work, or is it evaluating the person? Is the output administrative, or does it shape how the person is treated?

What to document first

Start with a short operating record. Capture the purpose, data subjects, data inputs, system or vendor, owner, output, who uses the output, what could happen to the person, lawful basis, retention, security controls, and evidence location.

Then classify the workflow: ordinary automation, profiling with human use, automated decision support, or solely automated decision-making with legal or similarly significant effects. Add a short rationale. If the answer depends on how the output is used, say that explicitly.

The most important field is impact. A risk score that only opens a human review queue is different from a risk score that automatically suspends an account. A support priority score is different from an eligibility score. A recommendation shown to a human is different from an automatic rejection.

What to do next

For low-risk profiling, define the owner, data inputs, purpose, transparency language, retention period, and review trigger. Keep the record short but findable.

For medium-risk workflows, add privacy review, vendor review where relevant, data quality checks, support routing, complaint handling, and monitoring. Make sure users or customers receive information that matches the actual workflow.

For high-impact workflows, consider a DPIA or equivalent deeper assessment, legal review, bias and accuracy testing, stronger human review, documented override paths, escalation rules, executive risk acceptance where appropriate, and scheduled monitoring after launch.

For Article 22 cases, do not rely on a vague "human in the loop" statement. Design the intervention, contestation route, explanation, and decision record before the workflow goes live.

Vendor and AI workflows

Vendor tools deserve the same classification. CRM enrichment, fraud detection, identity verification, security monitoring, analytics, advertising, customer success, HR tools, moderation systems, and AI copilots can all introduce person-level scoring or classification.

Ask what personal data is used, what output is produced, whether the output influences treatment of a person, whether the vendor trains or changes models using customer data, how model changes are communicated, and how access, deletion, objection, and contestation requests are handled.

AI does not automatically mean Article 22 applies, and non-AI rules can still be profiling. The better question is what the system does to people. Does it evaluate them? Does it influence a meaningful decision? Can someone challenge the outcome?

Practical scenario

A SaaS product adds a model that predicts which users are likely to abuse the platform. In the first release, the score only prioritises an internal review queue. That is likely profiling, but it may be automated decision support rather than solely automated decision-making.

Three months later, the team connects high scores to automatic temporary restrictions. The compliance answer changes. The workflow now affects account access directly, and the team must review whether the decision is solely automated and whether the effect is similarly significant.

A stronger operating model records the first classification, names the boundary condition, and requires a reopened review when the output starts triggering restrictions. That is how teams keep product velocity without losing control of the compliance analysis.

FAQ

What is the practical purpose of profiling and automated decision-making?

The practical purpose is to identify when a system evaluates people or makes decisions about them, then apply controls that match the impact.

When does profiling and automated decision-making apply to SaaS teams?

It can apply whenever a SaaS product, internal workflow, or vendor tool scores, ranks, predicts, flags, recommends, approves, rejects, suspends, prioritises, or routes individuals using personal data.

What should teams document or change first?

Start with the workflow owner, data inputs, output, intended decision use, likely impact on the person, classification, human review path, transparency language, and evidence location.

Does a human reviewer remove the risk?

Only if the review is meaningful. The reviewer needs context, time, authority, and the ability to challenge or change the automated output.

Sources

• European Union, General Data Protection Regulation.
• European Data Protection Board, Automated decision-making and profiling guidance.
• Information Commissioner's Office, Automated decision-making and profiling guidance.
• Information Commissioner's Office, Rights related to automated decision making including profiling.