Identity Reviewer: An AI Agent That Proposes Merges With Reason Codes

The Identity Reviewer is an AI agent that works through the identity-resolution review queue of a customer data platform (CDP) and proposes merges or splits with reason codes. Identity stewards review its output at propose level (L2). It never merges or splits a profile itself, because a false merge can expose one person's data to another, and it never combines consent scopes.

Rail level: L2 · Risk: high · Function: data and analytics

By Art Kukharenko · Published 2026-11-02 · Updated 2026-11-02

All AI agent rails

The rules around it follow the AI agent rails method. The matching mechanics are in identity resolution explained, and the process is in identity resolution review with an AI agent.

Rail at a glance

The Identity Reviewer's rail contains no merge tool at all, so neither a prompt nor a hijacked session can produce a merge. The identity engine applies a change only under a steward's own credential.

Field	Value
Job	Propose identity merges and splits with reason codes for a person to apply.
Trigger	A review queue from the identity engine.
Data scope	Pseudonymised match features, match scores and review history, with no sensitive attributes as match features.
Tool scope	Read: candidate pairs, match features, merge history; propose: a merge or split with reason codes; execute: none.
Output contract	Proposal, reason codes, confidence, and the effect on consent state.
Gate	An identity steward applies or rejects every proposal.
Limits	A queue size per run, and no access to raw contact details.
Ledger	Candidate IDs by reference, reason codes, decision, steward, model version.
Evaluation	Labelled pairs, including known false merges.
Owner and kill switch	Head of data or identity steward; an Orchestrator pause returns the queue to manual review.

What it does and who uses it

The Identity Reviewer handles the middle band of matching, where a score is too weak to link and too strong to ignore. Tools such as Splink output a match probability per pair 4, and stewards review the uncertain ones. The model sees comparison results, such as "mobile token: same; date of birth: different", and never the values themselves.

Illustrative run: a health insurer's queue holds two member records with the same surname, postcode and mobile token, but different first names and dates of birth. The reviewer proposes keeping them apart and notes that one record has withdrawn email consent. The steward confirms a parent and an adult child sharing a phone, and rejects any merge. Had the pair merged, a claims letter for one could have appeared in the other's portal.

An illustrative proposal follows. Its field names and codes are invented and are not a PrivyCDP API.

{
  "candidates": ["ref_71c2", "ref_a04e"],
  "proposal": "keep_separate",
  "reason_codes": ["SHARED_CONTACT_POINT", "DOB_CONFLICT", "GIVEN_NAME_CONFLICT"],
  "confidence": "medium",
  "consent_effect": "scopes differ; a merge would apply the stricter state to both"
}

Why this level

Identity decisions stay at L2 permanently because a false merge is hard to undo and quick to spread. Segments, journeys and syncs may act on a merged profile before anyone looks. Repair means recomputing both profiles from identifier history and telling downstream systems to re-key, and vendors differ on how far they support that. One bad link can also chain: Adobe describes shared devices, such as family tablets, kiosks and call-centre workstations, collapsing several people into one graph 5.

The Rule of Two 1 points the same way. Pseudonymised features are still personal data, so the session reaches private data. Source values behind those features can be junk or deliberately wrong, so treat them as untrustworthy input. A session with both properties must not also change state.

A team wanting a shorter queue should clean match keys and tune thresholds on labelled data. A merge tool for the agent is not on the ladder of rail levels.

Three ways it fails, and the control for each

Identity review can fail while looking like success, since a cleared queue says nothing about who was wrongly joined.

Failure	What it looks like	Control
Confident false merge	Twins, spouses, or a parent and child share a phone and address, so the features look strong.	Conflict codes on date of birth or first name force the steward to open both records. Known false merges stay in the evaluation set.
Consent scopes blended	A merged profile inherits an opt-in only one person gave, or loses a withdrawal.	Each proposal states the consent effect. The engine applies the stricter state per purpose and channel and keeps suppression on the identifier. The agent holds no consent tool.
Agreeing by habit	Acceptance climbs towards 100% as the queue shrinks, and proposals stop being read.	Some pairs reach the steward with the proposal hidden until they record their own view. Seeded false merges sit in the live queue.

Report these checks by rail and role, not by steward. Annex III point 4(b) of the EU AI Act lists monitoring workers' performance among high-risk uses 3, so take advice before using review data about individuals.

How to evaluate it

Measure the Identity Reviewer by error type, because a false merge and a missed merge do different harm. Use labelled pairs from past steward decisions, and hold known false merges as a separate slice.

Merge proposals on the known-bad slice. Each one is a serious failure, however good the overall score looks.
Precision on labelled pairs, split by purpose, since a newsletter audience and a claims process tolerate different risks.
Missed merges. A false split leaves one person on two records, so an opt-out may not reach both.
Merge reversal rate after stewards apply proposals, the most useful signal from production.

Add two seeded people who share a device and one email, and confirm that no consent leaks across a merge or an unmerge.

Where it runs

Match features and merge history describe real people, so this agent runs on a private model inside the customer environment, with no external model for this data. The on-premise LLM guide covers that placement. PrivyCDP supports bringing your own model into that environment, though the agent itself is yours to define.

Identity resolution review with an AI agent: the full process and its checklist.
AI agents for data and analytics teams: why "propose, never merge" anchors this function.
Consent withdrawal across channels: how suppression survives merges.
Rail card template: the form for writing this rail.

Return to the AI agent rails hub for the other agents. The rail card template is free to download, with a field for your own identity steward.

Browse use cases Function playbooks Agent roster

FAQ

Should an AI agent merge customer profiles automatically?

No. It can rank and explain candidate pairs, but a steward applies each change. A false merge can show one person's data to another, and the damage spreads before anyone notices.

What is a reason code in identity review?

A short label for the evidence behind a proposal, such as a shared contact point or a conflict on date of birth. Reason codes let a steward check the logic quickly and give auditors a record of why a pair was linked or kept apart.

Why does a privacy team care about false merges?

A false merge creates inaccurate data about two people and may put one person's details in front of the other. Article 5(1)(d) of the General Data Protection Regulation (GDPR) sets an accuracy principle 2. Whether a given incident is a reportable breach is a question for your DPO.

Sources

This article is general information, not legal advice.