AI Misidentified a Person. Fix the Record, Not Just the Result

Consider an account-recovery screen that asks for a selfie and identity document. A face matcher converts the images into numerical representations, called embeddings, and compares them; an identity-resolution service then links the applicant to phone numbers, email addresses and device records before a fraud model assigns a risk score.

In this workflow, the face match is weak, an old phone number connects the applicant to another account, and the combined score crosses the organization’s rejection threshold. The account is frozen. A support agent later reviews the documents and restores access, but the incorrect phone-account link remains in the identity graph, the structured record of relationships among people, accounts and devices.

The person has won an appeal while losing the correction. At the next recovery attempt, the same link can trigger the same result.

Separate the decision appeal from the data correction

A decision appeal asks whether this outcome should stand. A data correction asks which inputs, labels or relationships were wrong, where copies exist and what must change before the system runs again. Organizations need both paths under one case identifier, even when different teams own them.

Open the correction case as soon as a person disputes identity, association or fraud information. Capture the affected decision, the stated error and the systems that contributed material inputs. Do not make the person identify an internal database or model feature. They may know that an account was frozen after a selfie check; the organization must trace the rest.

The immediate safeguard should match the harm. For the failed account-recovery screen, place a scoped hold on further automated denials based on the disputed face comparison or phone link, then route another attempt to a trained reviewer. Disabling every fraud control would invite abuse, while allowing the same automation to keep acting would make the correction channel largely ceremonial.

That fallback costs staff time and adds review latency. It may also increase fraud exposure while the evidence remains unresolved. Those are operating costs of contestability, not reasons to omit it, and they should be budgeted alongside model inference, vendor fees and support queues.

Preserve the disputed run without treating it as truth

Before changing records, save a restricted snapshot of the failed run: submitted inputs, normalized values, candidate matches, model and ruleset identifiers, thresholds, timestamps, human actions and data provenance, meaning the record of where each input came from. Mark every contested field as disputed.

Preservation is not the same as leaving evidence active. The old phone link can remain in an audit store while being quarantined from production matching. A face image or biometric template requires tighter access, retention and deletion controls than an ordinary support note; preserve only what the organization can justify, and do not copy sensitive evidence into tickets, chat channels or analyst spreadsheets.

An append-only event log, where corrections create new entries instead of silently rewriting history, helps an auditor reconstruct what the system knew at decision time. The operational database can show the corrected state, while the evidence store records that a previous state existed, who challenged it and which authorized action superseded it.

This distinction matters when teams investigate recurring failures. If the original record disappears, they cannot test whether a parser, vendor feed or matching threshold caused the error. If it remains live, the system can injure the same person again.

Repair the source, then invalidate what it produced

Return to the phone-account edge in the identity graph. The correction team must determine whether the phone number was entered incorrectly, reassigned by a carrier, imported from a broker or inferred from shared-device activity. Each cause calls for a different repair. Replacing a typographical error is not equivalent to declaring that every historical use of a recycled number was false.

Correct the authoritative source first. Then follow its lineage into search indexes, caches, feature stores, fraud case tools and vendor exports. A feature store is a system that supplies prepared model inputs; if it still contains an account-link count derived from the bad edge, fixing the customer profile alone will not change the next score.

Derived data needs explicit invalidation. Remove or quarantine the bad graph edge, recompute affected features, expire cached scores and rebuild any lookup index that copied the association. If analysts labeled the rejected recovery attempt as confirmed fraud, amend that label before the next training dataset is assembled. Otherwise, the organization can convert its own mistake into training evidence.

Removing a record from future training does not prove that an existing model has forgotten it. Retraining may be warranted when the error is material or repeated, but rebuilding a model for every individual correction can be expensive and may change accuracy elsewhere. The minimum defensible action is narrower: stop using the disputed record in decisions, exclude the corrected label from new datasets and document whether the deployed model remains affected.

Block automatic reintroduction

The repaired phone link may return during the next nightly import. Prevention therefore needs a machine-readable suppression record, sometimes called a tombstone, keyed to the disputed assertion rather than a person’s entire profile. It should identify the source, corrected relationship, reason, approving actor and review conditions without exposing more personal data than downstream systems need.

Every ingestion job that can recreate the relationship must check that registry before publishing data. The broker feed can still deliver the old link, but the pipeline should route it to review rather than overwrite the correction. Vendor contracts and interfaces also need a return channel, because a local suppression cannot repair a supplier’s copy or protect another customer of that supplier.

Test this control with the original failure. Replay the account-recovery workflow using production-like data and verify that the corrected phone edge stays inactive, cached features change, the fraud score is recalculated and the case reaches the intended fallback. Then run the relevant import again. A correction is not complete if a routine synchronization restores the error.

Broad suppression carries its own accuracy cost. A rule that ignores every future association with the phone number could conceal genuine account takeover. Scope the block to the unsupported relationship, preserve new evidence separately and require human review before a previously rejected assertion becomes active again.

Give the affected person a usable receipt

A message saying that a ticket was resolved does not tell a person whether the next automated check will behave differently. The response should identify the challenged outcome, state whether it was overturned, describe the source record or relationship that changed in plain language, and explain which automated uses have been stopped.

For the account-recovery case, a useful receipt could say that access was restored, the disputed link between the phone number and another account was removed from identity matching, cached fraud features were recalculated, and named categories of downstream recipients were notified. It should also disclose any unresolved element, such as a vendor reviewing its own source record, plus a reference number and a route for further challenge.

Do not reveal fraud thresholds, other customers’ information or details that would enable evasion. That constraint does not justify a content-free answer. The organization can describe the categories of evidence considered, the action taken and the practical effect without publishing its detection rules.

Identity verification for the correction channel must not depend solely on the biometric or account link being disputed. Offer another route, such as document review or an established account credential, and separate the reviewer from the original automated outcome where feasible.

Turn the policy into enforced controls

Some laws already impose correction or dispute duties in defined contexts. Article 16 of the EU General Data Protection Regulation states:

“The data subject shall have the right to obtain from the controller without undue delay the rectification of inaccurate personal data concerning him or her.”

In the United States, the Fair Credit Reporting Act requires a “reasonable reinvestigation” when covered consumer-report information is disputed. Whether either rule applies depends on jurisdiction, organizational role and use case. These examples are requirements within their scopes, not a universal legal classification for every face matcher or fraud score, and this article is not legal advice.

An internal policy remains proposed behavior until systems enforce it. Make the case tool refuse closure unless an owner records the immediate decision, source-data disposition, derived-data invalidation, downstream notification and reintroduction test. Restrict who can reactivate suppressed evidence, log that action and require a reason.

Audit the path by measuring how long harmful automation remains paused, how often corrected records return, whether downstream acknowledgments arrive and how many cases reopen for the same assertion. Review samples against the underlying logs rather than relying on ticket status. A green “resolved” field is weak evidence when the identity graph still contains the bad edge.

Start with the workflow that can deny access, money, employment or physical entry. Map its inputs and owners before buying a generalized rights portal; without lineage and suppression controls behind it, the portal only creates a polished intake form for corrections the organization cannot execute.

Questions people ask

Should the original AI record be deleted after a correction?

Usually, the operational record should be corrected or quarantined while a restricted audit record preserves enough evidence to explain the original decision. Retention and deletion obligations vary, especially for biometric data, so teams should define purpose, access and retention with qualified counsel rather than keeping every submitted image indefinitely.

Does overturning the decision correct the AI model?

No. A reviewer can restore an account without changing the source link, cached feature, training label or deployed model. Teams must trace each material input, invalidate derived copies and decide whether exclusion from future training is sufficient or whether repeated errors justify model changes and broader testing.

How can an organization stop a vendor from sending the bad data again?

Send the correction through the vendor’s dispute channel and keep a local suppression record that intercepts the disputed assertion on reimport. The contract and interface should require correction acknowledgments, but the organization still needs its own gate because a promised upstream repair does not prove that every vendor copy changed.

What should a correction response tell the affected person?

It should state the challenged result, whether it changed, what source information or relationship was corrected, which automated uses were stopped and what remains unresolved. Include a case reference and another challenge route, while withholding other people’s data and security details that would expose fraud controls.