Does correcting an input always change the prediction?

No. The model may produce the same result, or a derived value may need separate refresh.

Is rectification identical to deleting all records?

No. It addresses accuracy and completeness; deletion is a distinct action with its own context.

Can AI-generated information be relevant to a correction request?

Yes. Inferences and profiles can concern individuals and may require review; their treatment depends on the facts and applicable framework.

AI Glossary / Governance, ethics and safety / Intermediate

Rectification

Definition

Rectification, in personal-data governance, means correcting inaccurate personal information or completing information that is incomplete for its relevant purpose. It matters for AI because errors in source records can influence profiles, predictions, and decisions. Rectification is more than changing what appears on a screen: the correction may need to reach the data and processes that continue to use the incorrect information.

What it means

A person's address may be outdated, an account may contain someone else's transaction, or an inferred profile may rely on a mistaken event. Correcting the relevant information helps prevent those errors from being repeated. The term here concerns data correction, not electrical rectification or rectified activation functions. In the EU GDPR context, rectification is a recognized data-subject right. Its application and related duties depend on the circumstances and applicable law. A practical AI system should distinguish a factual error, a disputed inference, and disagreement with a policy decision, because they can require different forms of review.

How it works

A correction process receives a request or detects an error, verifies the relevant facts and authority appropriately, locates affected records, and applies a justified update. It then identifies downstream copies, derived fields, indexes, or decisions that may need attention. Data lineage helps reveal these dependencies. A historical record may need to preserve what was originally recorded while clearly marking the correction, rather than silently rewriting the past. If training data or a learned model is affected, changing the source row does not necessarily change existing model parameters. The appropriate response requires technical and contextual assessment, not an automatic claim that every correction demands complete retraining.

Three practical examples

A customer corrects an outdated address that an AI-assisted service uses to suggest nearby locations.
A support team removes a wrongly attributed incident from an account and reviews a profile derived from that incident.
An organization corrects a mislabeled record in an evaluation dataset and recalculates the affected quality measure. The third example is general data-quality rectification; whether a personal-data right also applies depends on the record and context.

Think of it this way

Think of rectification as correcting a master address book and then checking the mailing lists copied from it. Fixing the first page helps only if later users receive the correction. The analogy is limited because AI systems can transform records into features or learned parameters, making the downstream relationship less direct than a copied address. Technical tracing and evaluation may be needed to determine what remains affected.

Worked example

Suppose a fictional service score is calculated as 100 minus 10 points for each unresolved incident. An account incorrectly shows three unresolved incidents, producing a score of 70. Investigation establishes that one incident belonged to another account, leaving two and a recalculated score of 80. Updating the source record but leaving a cached score of 70 would create an inconsistent system. The team should identify the relevant cache and decision workflow, refresh the derived score, and review whether the earlier error affected an action. The arithmetic is deliberately simple; real models may not have a transparent one-to-one correction effect. Correcting the input also does not guarantee a preferred final decision, because other valid factors may still apply.

Illustrative case study

Fictional case: Hazel Assistance receives a complaint that a user is repeatedly offered the wrong support plan. Staff find that a corrected account field never reached the personalization index. They repair the update path, refresh the affected record, and confirm the current recommendation uses the corrected information. They also record what happened so a later investigation can distinguish the old error from the new state. This invented case illustrates the importance of verifying a correction through the full workflow rather than closing a request after editing a database field.

Common misconceptions and mistakes

Rectification is not always the same as erasure. An inaccurate field may be corrected while a justified record remains. It is also different from guaranteeing that an automated outcome changes in the person's favor. A model inference can be contestable even when its inputs are accurate, but reviewing it may require more than replacing a factual value. A correction process should not treat an opinion as an unquestionable fact merely because a model produced it. Conversely, preserving an audit trail does not justify leaving inaccurate information active in ordinary decision-making without suitable handling.

Business use

Provide a clear route for reporting errors and assign responsibility for resolving them. Maintain enough lineage to find relevant stores and downstream uses, while limiting access to the personal data itself. Define how corrections interact with caches, search indexes, derived profiles, evaluation datasets, and model updates. Check that the update took effect and explain the outcome to the affected person in understandable language. In the EU context, EDPB guidance describes correction and completion rights and relevant notification duties to recipients, with stated exceptions. Operational procedures should be aligned with the actual applicable requirements rather than assuming one global rule.

Check your understanding

A source record is corrected, but the application still uses a stale derived profile. Is the operational problem resolved?

Answer: No. The team must identify and address the relevant downstream use, then verify that the active workflow reflects the justified correction.

Related terms

Personal data
Profiling
data accuracy
data subject rights
data lineage
erasure
correction request
cache invalidation
contestability
model update

Learn next

Trace one personal-data field from collection through its derived features and outputs. Design a correction request that exercises the whole path. Record how completion would be verified and which historical information needs a clear correction marker rather than an unexplained overwrite.

Personal data

Sources

EDPB, data-subject rights and rectification guidance: https://www.edpb.europa.eu/sme/be-compliant/respect-individuals-rights_en European Commission, information for individuals: https://commission.europa.eu/law/law-topic/data-protection/information-individuals_en EDPB, adopted virtual-voice-assistant guidelines, rectification discussion: https://www.edpb.europa.eu/system/files/2021-07/edpb_guidelines_202102_on_vva_v2.0_adopted_en.pdf

Previous: Rectangular grid Next: Rectified Gaussian distribution