You Can Delete a Row. Correcting a Prediction Is Harder.
Most privacy programmes built access and deletion first, because both map onto operations a database already supports. The right to correct is the one that does not — and when the contested value is an inference your model produced, "fix it" has no obvious implementation.
Why Inferences Are Squarely In Scope
The CCPA's definition of personal information is a list of categories, and one of those categories is inferences drawn from any of the others to create a profile reflecting a consumer's preferences, characteristics, behaviour, or aptitudes. That category was written for exactly the artefacts a modern AI stack produces: propensity scores, churn risk, predicted household income, lifestyle segments, intent signals, and fraud ratings.
The right to correct reaches inaccurate personal information that a business maintains. There is no carve-out for values that were computed rather than collected, and no exception for probabilistic outputs. If you store the inference and it is wrong about the consumer, it is correctable personal information.
The Four Places a "Corrected" Value Comes Back
The Source Record Was Never Fixed
CRITICAL RISKThe team overwrote the displayed inference but left the upstream field that produced it, so the next scheduled scoring run regenerates the identical wrong value
The Feature Store Holds a Snapshot
HIGH RISKModel features were materialised from an earlier extract; correcting the operational database does nothing to the frozen copy the model actually reads at inference time
Enrichment Vendors Re-Append
HIGH RISKA third-party data provider re-supplies the original wrong attribute on the next sync, quietly reverting the correction the consumer requested
Downstream Copies Drift
MEDIUM RISKAnalytics warehouse, CRM, marketing platform, and support tooling each hold their own copy, and only the system that received the request was updated
Correction Is Not Retraining
A common objection inside engineering is that honouring correction requests on inferences would mean retraining models on demand, which is neither required nor what the consumer is asking for. The obligation attaches to the personal information the business maintains about that consumer — the stored inference, the source attributes it was derived from, and the copies held by processors acting on your behalf. It does not require you to unwind a model's learned weights.
The practical unit of work is therefore an override that survives recomputation: correct the source attribute where it exists, re-derive the inference, and where re-derivation still produces the contested value, store an authoritative override the scoring pipeline respects rather than overwrites. Systems that lack any override concept are the ones where correction requests silently fail, and where the failure only surfaces when the same consumer complains a second time.
Documenting a Denial Properly
Not every contested inference has to be changed. A business may determine, on the totality of circumstances, that the information is more likely than not accurate, and decline — but it has to inform the consumer of that decision and explain the basis. The weak version of this is a template that says the request was reviewed and denied. The defensible version names what the inference is, what source data supports it, what documentation the consumer supplied, and why the source evidence was found more reliable. Write the second one; the first reads as a process that does not exist.
Implementation Checklist
Work through this against a real request before one arrives with a clock on it.
Audit your AI product's compliance exposure
RatedWithAI helps tech teams understand their compliance posture across accessibility, privacy, and AI regulation requirements. Start with a free scan.
Scan Your Product for Free →Frequently Asked Questions
Can we ask the consumer to prove the inference is wrong?
You can consider documentation the consumer provides, and you can weigh it against the source evidence you hold. What you should not do is build a workflow that treats consumer-supplied proof as a precondition for even reviewing the request. The obligation is to make a good-faith determination on the totality of circumstances, and a demand for documentation before review reads as a barrier rather than an assessment.
What if correcting an inference degrades our model's accuracy for everyone else?
It generally will not, because correcting one consumer's stored value is not retraining. If a single record materially moves aggregate performance you have a much larger data-quality problem than the correction request. Keep the correction at the record and pipeline layer, and keep model retraining decisions on their own separate track.
Do we need to correct inferences held only in logs or backups?
Archived and backup systems are typically treated differently from active systems — the practical standard is that the correction takes effect when the archived data is next accessed or used, rather than requiring you to rewrite immutable backups on demand. Document that position, and make sure a restore from backup does not quietly reintroduce the uncorrected value into production.
We're B2B and think we're out of scope. Are we?
Unlikely to be entirely. California removed the B2B and employee exemptions, so business contacts and personnel data now carry the same consumer rights, including correction. An enrichment score attached to a business contact is an inference about a natural person, and the fact that the relationship is commercial does not change that.