Why AI Mistakes You for Someone Else: Disambiguation Explained

What happens when an AI searches for your name

When someone asks an AI assistant who you are, the model doesn't open a card with your identity: it collects scattered signals from across the web and reassembles them into a response. If those signals are coherent and linked, the answer is accurate. If your name is shared with other people, or your presence is fragmented, the model does the only thing it knows how to do: it guesses the most probable version, mixing together whatever it finds.

The result is that your first impression — for someone who doesn't know you — is written by a system that's making its best guess. And you often don't even find out, because that response reaches a client or a recruiter, not you.

A concrete example

Two people share the same name: one is a solicitor, the other a musician with a reasonable online presence. I ask an AI assistant who that person is: the model, finding more material on the musician, describes the solicitor as if they performed, or builds a hybrid profile that corresponds to neither.

It doesn't matter much whether the namesake is well-known or not. What matters is who leaves more structured traces. Without a way to separate the two identities, the model treats them as one — and whoever hasn't built their own anchors loses out.

Another common case: a consultant with the same name as a public figure in a different field. Someone searching for the consultant gets the public figure's biography back, and the actual professional stays hidden in their shadow. Not because they're less competent, but because the other is more present and better connected.

Why a name is not an identifier

A name is not unique, and never has been. In a paper archive, disambiguation came from context: city, profession, date of birth. On the web that context is often missing, or scattered across sources that don't talk to each other.

People reading naturally reconstruct context on their own. A model can't: it needs the distinction to be explicit and linked. As long as your identity is just a name without anchors, to a machine you're indistinguishable from anyone else who shares it.

Three ways a namesake harms you

The damage isn't theoretical, and it takes three forms.

• Misattribution. You're assigned roles, titles, or work that aren't yours — or your own work gets attributed to someone else. Your professional story blends with one that doesn't belong to you.
• Invisibility. When a namesake is more prominent, the model picks them. You're not contradicted; you simply don't appear. The opportunity vanishes without a visible cause.
• Reputational contamination. If someone who shares your name has negative associations, those can land on you through simple proximity. It's the most insidious risk, because it doesn't depend on anything you did.

Who's most at risk

Certain situations make the problem more likely. People with common names start at a statistical disadvantage. But risk also rises for anyone who has changed fields, because the old professional identity continues to coexist with the new one and models struggle to determine which is current.

The same applies to people who have changed their name, those working in sectors crowded with similar profiles, or those with a recent and still-thin online presence relative to an established namesake. In all these cases, simply being there isn't enough: you need to declare clearly who you are now, and tie that declaration to evidence that confirms it.

When the namesake is a company or a brand

The problem isn't limited to other people. Your name may coincide with that of a company, a product, or a brand that's more visible. In that case, an AI system tends to favour the commercial entity — it's almost always more structured and more cited — and the person ends up secondary or absorbed into it.

The logic of the fix doesn't change: you need a clear, anchored personal entity that explicitly declares itself as a person, with a distinct professional trajectory and its own references. Without that, the brand wins by default.

Why LinkedIn and Google aren't enough

The instinctive response is to maintain a polished LinkedIn profile and hope Google does the rest. But these tools operate on a different plane. LinkedIn is a page that a model has to interpret, not an entity it can read without ambiguity. And a Google search, faced with a shared name, returns several different people — useful for a human who can choose, useless for a model that has to decide on its own.

Maintaining those channels matters, but it doesn't solve the underlying problem: neither tells an AI system which of those people you are, or which verifiable facts are tied to you. It's the same reason that appearing in a model's responses requires structured data, not just content.

What an entity is, and why it solves the problem

The solution isn't a better bio — it's building an entity. An entity is a structured representation of who you are: a stable identifier that stays consistent everywhere, with explicit links to the sources that are about you.

It's the difference between saying your name in a crowded room and wearing a badge that points to a verifiable document. Once that fixed point exists, the model has a way to anchor you: it no longer has to choose between you and your namesakes, because you've become a unique reference instead of an ambiguous string of text.

Disambiguation in practice: the anchors that matter

In concrete terms, disambiguation is built through links. The more verifiable they are, the sharper the separation.

• The official profiles you control, declared as yours via the sameAs property: website, LinkedIn, GitHub, and for those who publish, ORCID or Google Scholar.
• Affiliations: the universities, organisations, and networks you belong to, linked to their existing entries. You are the person connected to those entities, not someone else.
• Work and achievements: publications, projects, talks, with dates and context, that fix a trajectory no namesake can claim.

Each of these links is a coordinate. Alone, it says little; together, they locate a unique point — which is you.

Schema.org for people: the properties that disambiguate

There's a technical level worth making explicit. Schema.org, the vocabulary AI systems use to recognise entities, provides a Person type with properties designed precisely to fix an identity and distinguish it from another.

The sameAs property links the entity to the official profiles that confirm it; identifier holds unique references such as an ORCID; worksFor and affiliation tie it to organisations; alumniOf to universities; knowsAbout qualifies areas of expertise; hasOccupation describes the role; award and publications fix achievements. Each of these properties, filled with a verifiable reference, is a wall that separates your identity from a namesake's.

The point isn't to fill every field, but to choose the ones that genuinely distinguish you and link them to sources that hold up. It's a judgement call, not a task to automate: which evidence matters for you, and where it lives.

The case of researchers and authors

For those who publish, the problem is more acute and the solution more mature. A researcher with a common surname finds their citations split across multiple profiles, or mixed with those of a namesake in another field. Identifiers like ORCID exist precisely for this: giving every author a unique reference point to tie their output to.

ORCID has now issued over 20 million identifiers to researchers in every country and discipline; from July 2025, the NIH requires an ORCID for all senior researchers applying for federal funding (source: Scholarly Kitchen). That's the clearest signal that the disambiguation problem is now systemic — and that the solution is no longer an academic eccentricity.

Connecting an entity to an ORCID, to publications, and to research institutions transforms an ambiguous name into a traceable academic identity. It's one of the cases where semantic disambiguation has the most immediate and measurable effect.

Wikidata: do you need an entry?

The inevitable question: do I need a Wikidata entry? Almost certainly not. Wikidata requires notability, and an entry created for a person who doesn't meet that bar gets deleted — with a counterproductive effect.

The value, again, lies in connection rather than creation. You can anchor your entity to entries that already exist: your university, the organisations you belong to, the topics you work on. A dedicated entry for you only makes sense if and when genuine, verifiable notability exists. Until then, forcing one is wasted effort.

The mistake of relying on a plugin

At this point the temptation is to automate: a plugin that generates a Person markup, done. The markup will come out, and it will be formally correct. But a plugin doesn't know which of your namesakes you are, doesn't choose which sources prove what, doesn't find the authoritative links that set you apart.

Disambiguation is a work of judgement: deciding what needs to be said, retrieving the evidence, choosing which entities to connect to. If a tool could do that work, it would mean the work didn't need doing. The value lies in the decisions that precede the syntax, not in the syntax itself.

How to measure it

Checking whether it worked is straightforward, and you can do it yourself. Before the intervention, ask the main AI systems who you are, what you do, and what you've produced — and note the responses. That's your baseline.

After the intervention, repeat the same questions. What you observe is concrete: does the model separate you from your namesakes? Are the roles and work cited genuinely yours? Have you appeared where you were previously ignored? It's a verifiable comparison, worth repeating periodically as models update.

Disambiguation is not personal branding

It's worth clarifying what this work is not. It's not personal branding: it's not about building an image or a tone of voice. It's not reputation management in the sense of pushing positive content to bury unwanted results. And it's not optimising your name for Google.

It's a colder, more structural operation: giving a machine the coordinates to recognise you as a unique entity. Branding decides how you appear; disambiguation decides whether the system knows that appearance is you. You can have the best personal brand in the world and still be indistinguishable, for a model, from a namesake.

Reputation: declared or documented?

Underlying all of this is a simple principle. Saying you are something is an assertion; linking it to verifiable sources is evidence. AI systems, like competent people, weight the second more.

Disambiguation isn't a question of better words — it's a question of connected evidence. Your reputation stops being a story you tell and becomes a network of facts that hold up on their own, independent of anyone who shares your name.

Why it makes sense to act now

A reasonable question is whether this is worth doing now. The answer is that a poorly defined identity doesn't correct itself: the longer it goes, the more models consolidate the confused version, and the more ambiguous material accumulates around your name.

Building the correct entity early gives systems a clean reference before confusion sets in. And verifiable anchors don't wear out: once placed, they keep separating you from your namesakes at every new query. It's an investment that works over time, and the best moment to make it is before it becomes urgent.

Where to start

Three concrete steps, in order:

• Test your visibility. Ask ChatGPT, Perplexity, and Gemini your name — alone and with professional context. Note who appears, what's attributed to you, and whether there's confusion with a namesake.
• Identify your real anchors. Which profiles, affiliations, and pieces of work can you cite as verifiable evidence? Are they reachable via a stable URL? Start with what already exists.
• Structure a minimum entity. A Person markup with sameAs links to your official profiles is often enough to begin the disambiguation. Everything else is built on top.