Explainable Scoring: 2026 SaaS Rules for PQL & Churn

In 2026 the scoring layer of a SaaS stack — the models and rulesets that turn behavioural data into a PQL score, a lead grade, or a churn-risk number — moved closer to being a regulated object. California's CCPA regulations on automated decision-making technology took effect on January 1, 2026, the EU AI Act's high-risk obligations land on August 2, 2026, and GDPR Article 22 has always constrained solely-automated decisions with legal or similarly significant effects. The headline in most vendor blogs is alarmist: "every SaaS that scores users is now in scope." That is not true, and believing it will send you building compliance machinery you do not need while missing the cases that genuinely matter.

This post draws the actual line. It explains when a SaaS score crosses from an internal prioritisation signal into a regulated decision, what "disclose the logic" really demands, and — the part no law-firm alert covers — how to instrument a scoring pipeline so its reasoning is recoverable months later. The punchline: for most B2B SaaS, an internal PQL or lead score is not a regulated decision, but the instrumentation you would build to make it compliant is the same instrumentation that makes any score trustworthy, debuggable, and drift-resistant. Build it anyway.

What actually changed in 2026

Three regimes tightened at once, and they do not overlap neatly. California's CCPA rules on automated decision-making technology (ADMT) took effect January 1, 2026, with substantive ADMT compliance required from January 1, 2027 — businesses must give pre-use notice, and let consumers access and opt out of ADMT used for qualifying decisions. The EU AI Act's high-risk system obligations under Regulation (EU) 2024/1689 apply from August 2, 2026, adding documentation, human-oversight, and transparency duties for AI in specific high-risk categories. GDPR Article 22, unchanged, restricts decisions "based solely on automated processing" that produce legal or similarly significant effects.

The critical detail is that each regime has a narrow trigger, not a broad one. California's ADMT rules attach to a "significant decision", which the regulations define as one resulting in "the provision or denial of financial or lending services, housing, education enrollment or opportunities, employment or independent contracting opportunities or compensation, or healthcare services". That list is deliberately about consequential decisions affecting individuals — not about a growth team ranking accounts by expansion potential. The EU AI Act likewise reserves its heavy obligations for enumerated high-risk uses. So the first question is never "do I use a score?" but "does this score make, or substantially drive, one of the decisions these rules name?" For the broader compliance context, our EU AI Act compliance guide for SaaS analytics maps which parts of a stack the August 2026 deadline touches.

When a SaaS score crosses into regulated territory

A SaaS score becomes a regulated decision when it stops informing a human and starts substituting for one — and when the outcome it drives is consequential for an individual. An internal PQL score that tells a sales rep which of 200 trials to call first is a prioritisation aid; a human still decides who to contact and what to offer. That is not a "solely automated" decision under GDPR Article 22, and it is not a "significant decision" under California's ADMT rules. The overwhelming majority of B2B PQL scoring setups sit safely on this side of the line.

The line is crossed in a handful of specific patterns. If a score automatically gates access — auto-suspending an account, auto-denying a feature, or setting a price with no human in the loop — it starts to look like an automated decision with a real effect. If the scored subjects are individual consumers rather than business accounts, the consumer-privacy regimes engage more readily. And if the score feeds a downstream decision the rules name explicitly — creditworthiness, employment, essential services — you can inherit obligations even indirectly, because, as one legal analysis notes, "generating a credit score through automated profiling can itself be an automated decision where third parties rely heavily on that score". Map your scores against these patterns before assuming any of them are exempt.

What "disclose the logic" really demands

Disclosing the logic of an automated decision means providing meaningful information about how it is reached — not handing over source code, model weights, or a training-data dump. Both GDPR Article 22 and the EU AI Act's transparency provisions frame the obligation around the data subject's comprehension: the main factors that drove the outcome, the general logic and weighting, the significance and likely consequences, and a route to human review. A regulator is not asking you to make your model open-source; they are asking whether the person affected could understand why, in broad terms, the system decided as it did.

For a scoring pipeline this is very achievable — if you captured the right data at scoring time. "Your account was flagged high-churn-risk mainly because logins dropped to zero for 21 days, no new seats were invited this quarter, and two support tickets were logged as unresolved" is a compliant, honest explanation. The failure mode is not refusing to explain; it is being unable to, because the score was produced by a model that logged only the final number. That is why the disclosure question is really an instrumentation question, and why the teams that struggle are the ones who treated the score as an output rather than a record. The same discipline underlies a good analytics data-quality audit: a number you cannot trace is a number you cannot trust.

Instrumenting a score so it stays explainable

The single most important practice is to persist the inputs, weights, and model version at the moment each score is generated — not just the score itself. Every time you compute a score for an entity, write a record containing a snapshot of the feature values that fed it, the identifier of the model or ruleset version in force, a small set of human-readable reason codes, and a timestamp. This turns an opaque number into a reconstructable decision. Months later, when a customer disputes a churn flag or a regulator asks how a score was formed, you replay the record rather than guessing at a model that has since been retrained.

Three implementation details make or break this. First, snapshot the features at scoring time, because the underlying values drift — an account's "30-day activity" today is not what it was when the score fired. Second, version everything: a score of 82 means nothing without knowing which model produced it, and models change quietly. Third, generate reason codes at inference, not retroactively — deriving "why" after the fact from a black-box model invites exactly the guesswork the record is meant to eliminate. This is the scoring-layer analogue of the event-logging rigour described in our event taxonomy and tracking-plan guide: capture the context at write time, because you cannot recover it later.

The human-review and contestability path

Where a score does drive a regulated decision, the rules require a genuine human-review route — and "genuine" is doing real work in that sentence. GDPR Article 22 permits solely-automated decisions with legal effect only under narrow conditions, and even then a data subject retains the right to obtain human intervention, express their point of view, and contest the decision. A rubber-stamp review, where a human clicks approve on whatever the model output, does not satisfy this; the reviewer must be able to see the reasoning and actually override it. That is impossible unless the reason codes and feature snapshots from the previous section exist.

Practically, build the contestability path as a first-class feature of the scoring system, not a support-ticket afterthought. That means a reviewer-facing view that shows the reason codes behind any score, the ability to flag a score as overridden with a logged justification, and a feedback loop that feeds overrides back into model evaluation. Even for scores that never touch a regulated decision, this override log is valuable: a cluster of manual overrides on high-churn flags is one of the earliest signals that a predictive churn model has drifted and is mislabelling healthy accounts.

Why explainable scoring pays off even when it is not required

The strongest reason to instrument scoring for explainability is not compliance — it is that unexplainable scores quietly corrode every decision built on them. When a sales team stops trusting a PQL score because no one can say why an account ranked high, they revert to gut feel and the score becomes shelfware. When a churn model starts firing false positives because an upstream event stopped logging, a team without feature snapshots discovers it weeks late, after acting on garbage. The reason-code-and-version discipline that a regulator would demand is the same discipline that keeps a score honest and actionable internally.

Treat the 2026 rules as a forcing function for hygiene you should already want. Inventory your scores and classify each as prioritisation-aid or potential-regulated-decision. For the regulated few, build notice, access, opt-out, and human review to the letter. For the many that are just internal signals, still capture inputs, weights, versions, and reason codes — because that record is what lets you detect drift, resolve disputes, and explain a number to the humans who have to act on it. The teams that come out ahead are the ones who stopped treating a score as a disposable output and started treating it as an auditable decision, which is exactly the mindset behind decision-first analytics: if a number changes what someone does, it deserves to be explainable.