TL;DR

“AI identity resolution” is mostly a label — in 2026, the major CDPs still match identity with deterministic rules, and only Salesforce uses ML in the match step (fenced to fuzzy names). That’s correct: keep the identity graph deterministic and auditable, and use ML only to propose matches behind a gate or for downstream prediction — never to auto-merge profiles.

Every CDP is selling “AI identity resolution” in 2026. Open the documentation, and the AI usually isn’t in the part that decides who’s who.

Here’s the reality across the major platforms. The matching — the step that says these two records are the same person — is almost always deterministic: exact matches on emails, phone numbers, and customer IDs. The “AI” sits downstream, scoring churn and building audiences on top of profiles that were already stitched together by plain rules. Segment says it outright in its own docs: all profile matching is deterministic, and it doesn’t support probabilistic matching.

That’s not a gap. It’s the right architecture. Keep your identity spine deterministic and explainable. Use machine learning only in tightly bounded ways — to suggest fuzzy matches a rule or a human confirms, or for prediction after identities are resolved. Never let a model merge profiles on its own. This post shows what four major CDPs actually do, and why the ones being cautious have it right.

“Traditional” identity resolution is already two different techniques

Before you can judge what AI adds, you need to know what it’s being compared against. Traditional resolution isn’t one method — it’s two:

• Deterministic matching. If two records share the same email, phone, or customer ID, they’re the same person. High precision, low recall. It’s confident when it fires, but it misses anyone with two emails, a privacy-relay address, a name change, or a guest checkout.
• Classic probabilistic matching. Fuzzy scoring on name, address, and device signals, formalised decades ago by the Fellegi-Sunter model (the open-source Splink library is the clean reference). Each field gets a weight; the weights add up to a match probability. It’s “fuzzy,” but it’s still statistics and rules — no neural network in sight.

Most “traditional” CDPs run the first, some add the second. Both are auditable: you can point at why two records merged.

“AI identity resolution” means the machine learns the match instead of you writing it

The honest definition: in AI-based resolution, a model learns what a match looks like from data, rather than you hand-writing the rules.

In practice that covers a few things:

• Learned matching models — classifiers trained to predict whether two records are the same, often with active learning to cut the labelling cost (Zingg, Databricks’ ARC).
• Embeddings and graph ML — representing records as vectors and finding neighbours, or running graph algorithms over an identity graph.
• LLM-assisted entity matching — using language models to judge messy, free-text matches.

What ML buys you is recall: it catches matches on anonymous, cross-device, and messy-PII data that exact keys miss. That’s real, and for some problems it’s worth a lot.

What it costs you is harder to see:

• False merges. A model that’s wrong stitches two different people into one profile. Now someone gets another customer’s order confirmation, or their support history. False merges are expensive to unwind and worse to explain.
• Black-box decisions. “The model was 0.87 confident” is not an answer your compliance team will accept.
• Consent and residency risk. Merge two records across a border you shouldn’t, and you’ve created a GDPR problem, not a marketing win.
• Labelling and upkeep. Supervised models need labelled pairs and drift over time.

The trade is simple to state: ML raises recall and lowers precision. Whether that’s a good deal depends entirely on where you let it run.

What four major CDPs actually do — and only one puts ML in the match step

We checked the primary documentation for four platforms. The pattern is stark.

• Twilio Segment — deterministic, full stop. Matching runs on first-party external IDs (user_id, email, device IDs) with configured priority and merge rules. Its docs state plainly that it “doesn’t support probabilistic matching.” The AI — CustomerAI predictions, predictive and generative audiences (GA June 2025) — writes traits onto profiles that deterministic rules already resolved.
• mParticle (now Rokt) — deterministic. IDSync resolves each request by walking an ordered identity-priority list until it lands on a single profile. No scoring, no model. mParticle’s own material calls these “deterministic customer profiles” and puts probabilistic modelling “on the periphery.” Its AI — Cortex, and the June 2026 Audience Agent — runs on audiences and predictions, with identity resolution named as the foundation underneath.
• RudderStack — deterministic, and warehouse-native. Identity resolution runs as SQL/dbt models inside your warehouse: a connected-components graph that links IDs until it converges. RudderStack’s engineers describe it as purely deterministic and list probabilistic methods as something they’ve “yet to explore.” Their pitch is the opposite of a black box — “SQL in your warehouse, not a black box.” ML (Predictions, the RudderAI agent) sits downstream on top of the graph.
• Salesforce Data 360 — the exception, and even it fences the ML. Salesforce is the one platform with real ML in the match step. Its “Fuzzy” match method uses a BERT language model — trained, per its docs, on data from over 150 countries, 3 billion English words, and 20 million names — to match nicknames, misspellings, and cross-cultural name variants. But look at the boundaries:
  • Fuzzy is opt-in, one method among exact and normalized options.
  • Addresses stay deterministic — matched by exact-normalized rules, not the model.
  • Account (company) matching can’t use Fuzzy at all.

So even the vendor that shipped ML matching pointed it at low-stakes fuzzy name variants and kept it away from the fields where a false merge really hurts.

The pattern is deliberate: deterministic spine, fenced ML

Three of four platforms are fully deterministic. The fourth uses ML only where a wrong call is cheap and reversible. That’s not caution for its own sake — it’s the correct reading of the trade-off:

• The identity graph is load-bearing. Everything downstream — audiences, suppression, personalisation, billing — trusts it. A false merge here poisons all of it.
• You have to explain merges. Regulators, auditors, and your own team need to know why two records are one person. Deterministic rules answer that. A confidence score doesn’t.
• Precision beats recall here. Missing a match costs you one un-linked profile. A wrong match creates a live incident. When the downside is asymmetric, you optimise for precision — and deterministic is precision.

None of this means ML has no place. It means you fence it:

• Use ML to propose candidate matches, then gate them behind a deterministic rule or a human review before they commit. Salesforce’s opt-in Fuzzy method is exactly this pattern.
• Use ML for recall on the hard edges — anonymous and cross-device stitching — where deterministic keys genuinely can’t reach, and accept lower precision there because the alternative is nothing.
• Use ML downstream, after resolution, for what it’s actually good at: propensity, LTV, next-best-action.

The honest concession: if your business runs on messy third-party data with no clean keys — some ad-tech and data-broker use cases — probabilistic and ML matching may be the only way to get usable reach. Just don’t call that your customer system of record.

Warehouse-native is what makes the deterministic spine auditable

If the argument is “keep identity deterministic and explainable,” warehouse-native is the cleanest way to actually do it.

When resolution runs as SQL models in your own warehouse — RudderStack’s approach, and the composable pattern generally — you get:

• Readable logic. The match rules are SQL you can open, not a vendor’s opaque engine.
• Auditable merges. You can query the edges and answer “why are these one person?” directly.
• Re-runnable history. Change a rule, rebuild the graph, see what moved.

That’s the practical payoff of the whole thesis. A deterministic spine is only worth having if you can inspect it — and you can’t inspect a black box you rent. Warehouse-native turns “explainable identity” from a claim into something you can actually run a query against.

The bottom line

“AI identity resolution” in 2026 is mostly a label. Underneath, the serious platforms resolve identity deterministically and save the AI for downstream prediction — and the one that put ML in the match step fenced it to fuzzy names and kept it off addresses and company records. That’s not vendors being slow. That’s them being right.

On Monday, pressure-test any “AI-powered identity resolution” pitch with four questions:

1. Is the AI in the match step, or downstream? If it’s scoring churn, that’s not AI matching.
2. Which fields does the model touch? Fuzzy names is reasonable. Fuzzy on addresses or account IDs is a red flag.
3. Is there a deterministic or human gate before a merge commits? Autonomous ML merging is the thing to avoid.
4. Can you audit why two records merged? If the answer is a confidence score, you can’t.

If a vendor’s answers make you nervous, that’s the post working.

Take the next step

If you’re evaluating how identity resolution should work in your stack, start with our identity resolution pillar — it lays out the deterministic-first approach end to end, and where each technique earns its place. Read that before you take any “AI identity resolution” claim at face value.

Frequently Asked Questions

Is AI identity resolution better than deterministic matching?

Not for the core matching step. Deterministic matching is higher precision and fully auditable, which is what an identity graph needs. AI/ML raises recall on messy or anonymous data but lowers precision, so it’s best used to propose candidates behind a deterministic gate — not to run resolution on its own.

Does Salesforce Data Cloud / Data 360 use AI for identity resolution?

Partly. Its “Fuzzy” match method uses a BERT model to match nicknames, misspellings, and name variants. But it’s opt-in, addresses are matched deterministically, and Account (company) matching can’t use it at all. The broader identity graph is still a rules-based ruleset engine.

Do Segment and RudderStack use probabilistic or AI matching?

No. Both are deterministic. Segment’s docs state it doesn’t support probabilistic matching. RudderStack runs a deterministic connected-components graph as SQL in your warehouse. Their AI features (predictions, agents) operate downstream of the resolved identity graph.

When should you actually use ML in identity resolution?

When deterministic keys can’t reach — anonymous traffic, cross-device stitching, messy third-party data with no clean identifiers. Even then, use it to suggest matches for review or to expand reach at the activation layer, not to auto-merge your system-of-record profiles.

What’s the difference between probabilistic and AI-based identity resolution?

Classic probabilistic matching uses fixed, human-defined weights on fields like name and address (the Fellegi-Sunter model). AI-based resolution learns the matching function from data using machine learning. Both are “fuzzy,” but only the second adapts on its own — and both trade precision for recall compared to deterministic matching.