Entity Linking: How AI Works Out Who You Are

There's a precise name for the problem

For years, being found meant ranking among ten links on a results page. Today an AI system answers in a single shot, and before answering it has to make a decision traditional search never required: establishing who, or what, a name refers to. That decision has a name in the literature, and it is entity linking, also called named-entity disambiguation. It is the task of assigning a unique identity to entities mentioned in text. The textbook example is the sentence "Paris is the capital of France": the model has to understand that "Paris" is the city and not Paris Hilton.

It isn't a term I coined. It is a recognised discipline, with a Wikipedia article and a Wikidata node, studied for more than twenty years across information retrieval, natural language processing and the semantic web. Knowing the problem has a precise name changes how you approach it: it isn't the vague wish to "be more visible", it is a defined technical question, with known causes and concrete levers to act on.

Don't confuse it with deduplication

There is a near-homonym that leads people astray: entity resolution. Despite the similar name it means something else, namely deciding whether two separate records are the same entity and merging them, removing duplicates. That is data-engineering and master-data-management work, the world of anti-money-laundering and corporate registries. Entity linking goes the opposite way: it takes a mention and resolves it to the correct canonical entity, distinguishing it from namesakes.

The distinction matters, and not out of pedantry. Chase the wrong word and you end up in the wrong conversation, read by the wrong audience. The problem I work on isn't cleaning duplicates out of databases, it is making sure a name resolves to the right person or organisation, with the right facts.

How AI decides

The process has three moments. First the model recognises the name within the text. Then it generates candidates, the possible entities that name could map to, drawing on a knowledge base, usually Wikipedia or Wikidata. Finally it disambiguates, choosing the correct candidate.

The weak point, for you, is the second step. If your entity isn't in that knowledge base, or is there but described confusingly, the model picks someone else or invents. It isn't malice, it is the normal behaviour of a system filling gaps. The only way to control the outcome is to make the correct answer the easiest one to find.

Why it concerns you, not the engineers

Building the entity-linking system is the NLP engineers' job, and it is not mine. I sit on the other side of the table, on the side of the entity that has to be linkable. The lever you hold isn't the algorithm, it is the supply of clean, verifiable, structured data about yourself or your organisation. A stable identifier, references that hold up under checking, a description a machine can read without having to interpret.

It is exactly the half of the problem you can control, and also the half almost nobody works on. Everyone discusses how AI gets things wrong; few prepare their own entity so that AI can get them right.

Where entities live: knowledge graph and linked data

Two recognised concepts name the substrate you work on. A knowledge graph is the structure of entities and relationships that search engines and AI systems consult to know who is who. Linked data is the practice of publishing your data in a connected, machine-readable form, with unique identifiers and links to canonical nodes, on RDF foundations, and in daily practice through JSON-LD and Schema.org with sameAs links to Wikidata.

Making yourself linkable means two concrete things: existing as a clean node in that graph, and pointing to the right nodes beside you, the topic you work on, the organisations you belong to, the places where you operate. Those links tell the model where to place you, and stop it confusing you with a namesake.

What a Semantic Entity Architect actually does

Now I can say plainly what the title I carry means. I do not optimise keywords and I do not build artificial intelligence. I design how an entity is represented, so that when a model performs entity linking it resolves to the right node, with the right facts, distinct from namesakes, and so that entity can be cited as a source.

It is a craft that lives at the intersection of three recognised fields, entity linking, knowledge graph and linked data, applied to a single goal: being found and described correctly by generative systems, what the market calls GEO, Generative Engine Optimization. The name of the role is mine, but those nodes say what it contains. It is disambiguation applied to myself, before the clients.

Three applications of the same principle

Everything else on this site is this principle brought down to a specific subject. For a professional the problem takes the shape of namesakes, the AI merging you with someone who shares your name, which I address in the note on name disambiguation. For an SME it is the brand and the offer that have to appear correctly in answers about suppliers and solutions, the theme of how to make your business appear in AI responses. For a nonprofit it is a mission trapped in PDFs that no machine reads, which I cover in GEO for nonprofits.

Different audiences, identical underlying work: making the entity resolve correctly. The subject changes, not the principle.

Where to start

The first step is always the same, and you can take it today: ask ChatGPT, Gemini and Perplexity who you are, or what your organisation does, and observe what is correct, what is missing and what is invented. That snapshot tells you whether entity linking, on you, is working or not. From there you decide whether and how to act.