Entity Resolution selbst bauen oder kaufen: Was Enterprise-Teams falsch machen (2026)

Kurzfassung: Entity Resolution selbst zu bauen gibt Ihnen mehr Kontrolle über die Matching-Logik, unterschätzt aber durchgängig die laufenden Kosten für Tuning, Survivorship-Regeln, Skalierung und Echtzeitanforderungen. Ein spezialisierter Dienst tauscht die Obergrenze der Anpassbarkeit gegen eine drastisch kürzere Time-to-Production und eine bekannte Wartungsfläche. Die richtige Wahl hängt davon ab, wie viel Ihr Team von diesem Kompromiss verträgt – nicht von einer Anbieter-Scorecard.

Lieber visuell? Unser interaktiver Build-vs-Buy-Rundgang lässt Sie jede Stufe eines Eigenbaus einzeln zu- und abschalten, um genau zu sehen, was Tilores ersetzt.

Warum enden so viele Build-Entscheidungen in Reue?

Die meisten Enterprise-Teams, die Entity Resolution selbst bauen, starten von einer vernünftigen Prämisse: Ihre Daten sind auf eine Weise unsauber, mit der ein Standardprodukt nicht umgehen kann, ihre Domäne hat besondere Matching-Regeln, und sie haben Entwickler, die Spark-Jobs schreiben können. Diese Argumentation ist nicht falsch. Das Problem ist, was in der ersten Schätzung fehlt.

Entity Resolution ist kein einzelner Algorithmus. Sie ist eine Pipeline, die deterministische Regeln (exakte Treffer auf Feldern wie Steuer-IDs oder Passnummern) mit probabilistischem Fuzzy Matching (phonetische Ähnlichkeit, Adressnormalisierung, Namenstransliteration) kombiniert – dazu eine Survivorship-Schicht, die entscheidet, welcher Wert „gewinnt”, wenn zwei Datensätze sich widersprechen, eine Blocking-Strategie, die den Vergleichsraum auf ein rechnerisch handhabbares Maß begrenzt, und eine kontinuierliche Feedbackschleife, die das Modell neu trainiert, wenn sich die Datenverteilung verschiebt. Jede dieser Komponenten braucht ihr eigenes Wartungsbudget.

Die Reue stellt sich meist im zweiten Jahr ein: Der ursprüngliche Entwickler ist weitergezogen, die Match-Schwellen, die im Pilotprojekt funktionierten, produzieren bei Produktionsvolumen False Positives, und jemand hat gemerkt, dass eine neue Datenquelle bedeutet, die Blocking-Logik von Grund auf neu zu bauen.

Was gehört wirklich zu einem Eigenbau?

Ein glaubwürdiger Eigenbau umfasst mehr technische Fläche, als die meisten Schätzungen anfangs erfassen. Die wichtigsten Komponenten sind:

• Parsing und Normalisierung. Namen, Adressen, Telefonnummern und Kennungen treffen quellenübergreifend in uneinheitlichen Formaten ein. Bevor irgendein Abgleich stattfinden kann, brauchen Sie kanonische Repräsentationen. Das ist mehr Arbeit, als es aussieht – besonders bei internationalen Daten.
• Deterministische Matching-Regeln. Harte Regeln für Kennungen mit hoher Konfidenz (Sozialversicherungsnummer, Steuernummer, Passnummer) sind der schnelle Pfad für einen Teil Ihrer Datensätze. Sie richtig hinzubekommen erfordert, die Ausnahmefälle sorgfältig durchzuarbeiten.
• Probabilistisches Fuzzy Matching. Für den restlichen Datenraum brauchen Sie Ähnlichkeitsfunktionen (Editierdistanz, tokenbasiert, phonetisch) und ein Scoring-Modell, das sie kombiniert. Open-Source-Bibliotheken wie Splink oder recordlinkage senken hier die Einstiegshürde, erfordern aber weiterhin fachliches Tuning. Und einen Splink-Prototyp in Produktion zu bringen legt die Arbeit an Survivorship, Ingestion und Monitoring offen, die diese Bibliotheken Ihnen überlassen.
• Blocking. Jedes Datensatzpaar zu vergleichen ist quadratisch und oberhalb bescheidener Größenordnungen nicht praktikabel. Blocking-Strategien (Indizierung über phonetische Schlüssel, LSH, Sorted Neighborhood) müssen so entworfen werden, dass sie genau die Paare nicht ausschließen, die Sie finden müssen.
• Survivorship-Regeln. Sobald zwei Datensätze verknüpft sind, brauchen Sie Regeln dafür, welche Werte in die aufgelöste Entität übernommen werden: die aktuellste Adresse, die vertrauenswürdigste Quelle für das Geburtsdatum, Vereinigung statt Neuestes bei Telefonnummern. Das ist am Anfang fast immer unterspezifiziert.
• Auflösung bei der Ingestion. Die Matching-Logik muss laufen, wenn ein Datensatz eintrifft, nicht wenn eine Abfrage gestellt wird. Der aufgelöste Entitätsgraph wird zur Ingestion-Zeit aufgebaut und gepflegt; Abfragen rufen den aktuellen aufgelösten Kontext dann ab, ohne ihn spontan neu zu berechnen.
• Monitoring und Retraining. Datenverteilungen ändern sich. Neue Quellen kommen hinzu. Die Match-Qualität driftet. Ein Eigenbau ohne Feedbackschleife verschlechtert sich still und leise.

Keine dieser Komponenten ist unüberwindbar, aber zusammen bedeuten sie eine erhebliche und dauerhafte Entwicklungsinvestition. Auch die Abwägung zwischen Precision und Recall erfordert sorgfältige Kalibrierung: Ein Schwellenwert, der bei der Betrugserkennung False Positives minimiert, kann für Customer 360 falsch sein – und womöglich brauchen Sie mehrere getunte Konfigurationen im Parallelbetrieb.

Wie sieht die Build-vs-Buy-Entscheidungsmatrix konkret aus?

Dimension	Eigenbau	Kaufen (spezialisierter Dienst)
Zeit bis zum ersten Match in Produktion	Meist Monate bis zu einem funktionierenden Piloten; deutlich länger bis zur produktionsreifen Lösung mit Monitoring	Tage bis Wochen für die erste Integration; API-native Dienste lösen Datensätze schon beim ersten Aufruf auf
Anfangskosten	Entwicklungsstunden (Normalisierung, Matching-Modell, Blocking, Survivorship); im ersten Jahr meist höher als die Anbieterkosten	Lizenz- oder verbrauchsbasiert; geringerer Entwicklungsaufwand für die Ersteinrichtung
Laufende Wartung	Hoch: Tuning, Retraining, Schemaänderungen, Anbindung neuer Quellen, Skalierung der Infrastruktur	Niedriger: Der Anbieter übernimmt die Modellpflege; Ihr Team verantwortet Integration und Konfiguration
Skalierung	Sie besitzen die Infrastruktur; sie lässt sich exakt auf Ihre Last optimieren, erfordert dafür aber Entwicklungsarbeit	Vom Anbieter verwaltete Skalierung; spezialisierte Dienste sind auf Ingestion in hohem Volumen ausgelegt
Echtzeitauflösung	Nachträglich schwer zu ergänzen; die meisten Eigenbauten werden von Batch-Pipelines dominiert	API-native Dienste lösen beim Ingest auf und liefern den aufgelösten Kontext zur Abfragezeit, ohne zusätzliche Infrastruktur
Erklärbarkeit	Voller Zugriff auf die Matching-Logik; den Audit-Trail müssen Sie selbst bauen	Je nach Anbieter unterschiedlich; auf regulierte Branchen zugeschnittene Dienste legen Match-Scores und Belege in der Regel offen
Obergrenze der Anpassbarkeit	Unbegrenzt: Sie besitzen die Matching-Logik von Anfang bis Ende	Begrenzt durch die API-Fläche und die Konfigurationsoptionen des Anbieters; die meisten Enterprise-Anforderungen passen hinein
Deterministisches UND probabilistisches Matching	Sie implementieren beides; die richtige Kombination zu finden erfordert Iteration	Spezialisierte Dienste implementieren beides und tunen die Kombination; prüfen Sie das in der Due Diligence
Passung zum bestehenden Stack (MDM, CDP, KYC/AML)	Integriert sich eng mit eigenen Systemen; kann zur Abhängigkeitslast werden	Steht als Auflösungsschicht neben MDM-, CDP- und KYC/AML-Systemen; ersetzt sie nicht

Wann ist ein Eigenbau sinnvoll?

Ein Eigenbau ist unter engeren Umständen die richtige Entscheidung, als die meisten Teams anfangs annehmen. Am stärksten sprechen dafür:

• Sie haben wirklich einzigartige fachliche Matching-Regeln, die kein Anbieter unterstützt und die einen verteidigungsfähigen Wettbewerbsvorteil darstellen. Das ist selten. Die meisten Matching-Anforderungen (Namen, Adressen, staatliche Ausweisnummern, Finanzkontonummern) decken spezialisierte Dienste gut ab.
• Sie unterliegen Anforderungen an die Datenresidenz, die es verbieten, Datensätze an einen externen Dienst zu senden, und Ihr Beschaffungsprozess kann einen Anbieter mit Self-Hosting-Option nicht abbilden.
• Ihre Auflösungslast ist rein Batch, klein und stabil. Eine einmalige Datenmigration oder ein vierteljährlicher Abgleich rechtfertigt möglicherweise keine Lizenzkosten, und der Wartungsaufwand bleibt beherrschbar, solange die Pipeline sich nicht weiterentwickeln muss.
• Sie haben bereits in eine ML-Plattform investiert und eigene Data-Engineering-Kapazität, die das Matching-Modell langfristig verantwortet. Ein Eigenbau ist eine schlechte Wahl, wenn er darauf angewiesen ist, Kapazität von einem Team zu borgen, dessen eigentlicher Auftrag ein anderer ist.

Wann ist Kaufen die bessere Wahl?

Einen spezialisierten Entity-Resolution-Dienst zu kaufen ist sinnvoll, wenn zu den Anforderungen Echtzeitauflösung, laufende Ingestion aus mehreren Quellen oder die Integration in KI- und RAG-Pipelines gehören. Die deutlichsten Signale sind:

• Sie brauchen Auflösung bei der Ingestion, nicht im Batch. Echtzeit-Anwendungsfälle (Betrugserkennung, Onboarding, AML- und KYC-Prüfungen) setzen voraus, dass eine aufgelöste Entitätssicht sofort verfügbar ist, wenn ein neuer Datensatz eintrifft. Das auf einer Batch-Pipeline aufzusetzen erfordert erheblich zusätzliche Infrastruktur.
• Ihre KI-Pipelines brauchen eine aufgelöste Entitätsschicht. IdentityRAG und ähnliche Ansätze setzen voraus, dass das Retrieval auf aufgelösten Entitäten arbeitet, nicht auf Rohdatensätzen. Eine spezialisierte API fügt sich reibungsärmer in solche Pipelines ein als ein selbstverwalteter Auflösungsdienst.
• Sie binden häufig neue Datenquellen an. Jede neue Quelle in einem Eigenbau kann Änderungen an der Blocking-Strategie, an der Normalisierung und ein erneutes Tuning der Schwellenwerte erfordern. Ein Dienst mit stabiler API-Fläche nimmt Ihnen einen größeren Teil dieser Arbeit ab.
• Sie brauchen Erklärbarkeit für Audit oder Compliance. Regulierte Branchen müssen belegen können, warum zwei Datensätze verknüpft wurden – oder eben nicht. Dienste, die für diesen Anwendungsfall gebaut sind, legen die Match-Belege in der Regel auf API-Ebene offen.
• Das Entwicklungsbudget Ihres Teams ist oberhalb der Auflösungsschicht besser angelegt. Auflösung ist Infrastruktur. Für die meisten Produkt- und Analytics-Teams liegt der Wert in dem, was sie ermöglicht, nicht im Besitz der Matching-Logik.

Tilores ist eine Option auf der Kaufseite, entwickelt für Teams, die eine API-native Entity-Resolution-Schicht mit Echtzeit-Ingestion, deterministischem und probabilistischem Matching sowie einem aufgelösten Entitätsgraphen brauchen, der sowohl operative Abfragen als auch KI-Retrieval bedienen kann. Sie steht neben Ihrem bestehenden MDM-, CDP- oder KYC/AML-Stack, statt ihn zu ersetzen. Der Vergleich der Entity-Resolution-Ansätze beschreibt ausführlicher, wie sich diese Optionen zueinander verhalten. Es ist eine Wahl unter mehreren, und welche die richtige ist, hängt von Ihren konkreten Anforderungen ab.

Welche versteckten Kosten übersehen Teams immer wieder?

Die sichtbaren Kosten eines Eigenbaus sind die Entwicklungszeit für die erste Pipeline. Die versteckten Kosten sind größer und schlechter vorhersehbar:

• Pflege der Schwellenwerte. Match-Schwellen, die bei einer Datenverteilung gut funktionieren, verschlechtern sich, wenn das Volumen wächst, wenn eine neue Quelle mit anderen Namenskonventionen hinzukommt oder wenn das Unternehmen ändert, was „dieselbe Entität” bedeutet (etwa eine Sicht auf Haushaltsebene statt auf Personenebene). Neu zu tunen erfordert gelabelte Daten und Entwicklungszeit.
• Wucherung der Survivorship-Regeln. Survivorship-Logik beginnt einfach und sammelt Ausnahmen an. Nach zwei Jahren ist der Regelsatz der fragilste Teil des Systems, weil er implizite Geschäftsentscheidungen kodiert, an deren Zustandekommen sich niemand mehr erinnert.
• Anbindung neuer Quellen. Jede neue Datenquelle erfordert Normalisierungsarbeit, Aktualisierungen der Blocking-Indizes und eine Qualitätsbewertung. Bei den ersten zwei, drei Quellen fällt das kaum auf; im großen Maßstab wird es zur laufenden Steuer.
• Bereitschaftsdienst und Incident-Kosten. Eine produktive Entity-Resolution-Pipeline, die nachgelagerte Betrugs-, Onboarding- oder Analytics-Systeme speist, liegt auf dem kritischen Pfad. Wenn sie schwächelt, wird jemand aus dem Bett geklingelt. Diese Kosten tauchen in anfänglichen Build-Schätzungen selten auf.
• Wissenskonzentration als Risiko. Eigenbausysteme werden typischerweise nur von wenigen Entwicklern verstanden. Wenn diese Entwickler gehen, geht das institutionelle Wissen mit. Ohne die Menschen, die es gebaut haben, wird das System schwerer zu warten.

Ein nützlicher Rahmen: Berechnen Sie vor der Entscheidung für einen Eigenbau nicht nur die anfänglichen Entwicklungskosten, sondern die erwarteten jährlichen Wartungskosten über drei Jahre – einschließlich der Wahrscheinlichkeit, dass Schlüsselentwickler wechseln. Diese Zahl bildet die tatsächlichen Build-Kosten realistischer ab als die ursprüngliche Projektschätzung.

Wie führt ein Team eine faire Evaluierung durch?

Eine brauchbare Evaluierung sollte für beide Wege an Ihren echten Daten und Anforderungen testen, nicht an den Demodaten des Anbieters. Beim Eigenbau lauten die relevanten Fragen: Wie lange dauert es, auf Ihren Daten produktionsreife Match-Qualität zu erreichen, und wer pflegt das System, wenn das ursprüngliche Team weiterzieht? Beim Kauf lauten sie: Unterstützt der Anbieter sowohl deterministisches als auch probabilistisches Matching, wie funktioniert die Auflösung bei der Ingestion im Vergleich zur Abfragezeit, und wie sieht die API aus, wenn Ihre KI-Pipelines sie aufrufen?

Ein praktikabler Ansatz ist ein paralleler Proof of Concept: Nehmen Sie eine gelabelte Stichprobe Ihrer Daten (Datensätze, von denen Sie wissen, dass sie dieselbe Entität betreffen, und solche, von denen Sie wissen, dass sie es nicht tun), lassen Sie sie durch einen Build-Prototyp und durch eine Anbieter-API laufen und vergleichen Sie Precision und Recall gegen die Schwellenwerte Ihres Anwendungsfalls. Das liefert echte Leistungsdaten statt Schätzungen; unser Benchmark Splink vs. Tilores zeigt, wie dieser Vergleich auf einem gelabelten Datensatz aussieht.

Die Übersicht der Entity-Resolution-Tools 2026 und der Vergleich der besten Identity-Resolution-Plattformen beleuchten die Anbieterlandschaft mit Detailtiefe auf Anwendungsfallebene, falls Sie die Kaufseite dieser Evaluierung abstecken.

FAQ

Wie lange dauert es, Entity Resolution selbst zu bauen?

Ein funktionierender Prototyp für eine einzelne Quelle und einen Anwendungsfall lässt sich in Wochen bauen. Ein produktionsreifes System mit deterministischem und probabilistischem Matching, Survivorship-Regeln, Blocking, Monitoring und Echtzeit-Ingestion braucht typischerweise mehrere Monate dedizierter Entwicklungsarbeit. Je länger der Zeitplan, desto größer der Abstand zu einem spezialisierten Dienst, der Datensätze schon beim ersten API-Aufruf auflösen kann.

Können Open-Source-Bibliotheken einen spezialisierten Entity-Resolution-Dienst ersetzen?

Open-Source-Bibliotheken wie Splink und recordlinkage sind nützliche Ausgangspunkte für probabilistische Matching-Modelle. Sie liefern keine verwaltete Auflösungs-API, keine Echtzeit-Ingestion, keine Survivorship-Verwaltung und keine Produktionsinfrastruktur. Sie senken den Bauaufwand, beseitigen ihn aber nicht, und die gesamte Pipeline drumherum müssen Sie selbst verantworten.

Ersetzt Entity Resolution MDM-, CDP- oder KYC/AML-Systeme?

Nein. Entity Resolution ist eine Auflösungsschicht, die neben diesen Systemen steht. Sie liefert die Matching- und Verknüpfungslogik, die MDM- und CDP-Systemen oft fehlt oder die dort nur eng umgesetzt ist, und speist aufgelösten Entitätskontext in KYC/AML-Workflows ein. Die Governance-, Lineage- und Workflow-Fähigkeiten dieser Systeme ersetzt sie nicht.

Was ist der Unterschied zwischen deterministischer und probabilistischer Entity Resolution?

Deterministisches Matching nutzt exakte oder regelbasierte Vergleiche auf Feldern mit hoher Konfidenz (Steuer-IDs, Passnummern, E-Mail-Adressen), um harte Verknüpfungsentscheidungen zu treffen. Probabilistisches Matching nutzt Ähnlichkeitswerte über mehrere Felder hinweg, um eine Konfidenz zuzuweisen und die Verknüpfungsentscheidung an einem Schwellenwert zu treffen. Produktionssysteme nutzen beides: Deterministische Regeln erledigen die einfachen Fälle schnell, probabilistisches Matching die schwierigen. Eine vollständige Erklärung der Entity-Resolution-Ansätze geht ausführlicher auf die Mechanik ein.

Was bedeutet „Auflösung bei der Ingestion” und warum ist das wichtig?

Auflösung bei der Ingestion bedeutet, dass Abgleich und Entitätsaufbau stattfinden, wenn ein Datensatz im System eintrifft – nicht erst, wenn eine nachgelagerte Abfrage gestellt wird. Das Ergebnis: Abfragen rufen immer eine aktuelle, aufgelöste Entitätssicht ab, ohne sie bei Bedarf neu aufzubauen. Für Echtzeit-Anwendungsfälle (Betrugsprüfung, Onboarding), bei denen die Latenz auf dem Abfragepfad begrenzt ist, ist das entscheidend. Reine Batch-Pipelines können diese Garantie nicht geben.

Wann ist ein Eigenbau von Entity Resolution die richtige Entscheidung?

Ein Eigenbau ist sinnvoll, wenn Sie einzigartige Matching-Regeln haben, die einen echten Wettbewerbsvorteil darstellen, wenn harte Anforderungen an die Datenresidenz externe Dienste ausschließen, wenn die Last rein Batch und stabil ist und sich nicht weiterentwickeln muss, und wenn Sie dedizierte Entwicklungskapazität haben, die das System langfristig verantwortet. Diese Bedingungen treffen auf einen kleineren Teil der Teams zu, als diese Teams zunächst annehmen.

Wie fügt sich Entity Resolution in KI- und RAG-Architekturen ein?

KI-Pipelines, die entitätsbezogenen Kontext abrufen, profitieren davon, wenn das Retrieval auf aufgelösten Entitäten statt auf Rohdatensätzen arbeitet. Ohne Auflösung taucht dieselbe reale Entität als mehrere unverbundene Datensätze im Retrieval-Index auf, und das Modell bekommt fragmentierten oder widersprüchlichen Kontext. IdentityRAG beschreibt im Detail, wie sich eine aufgelöste Entitätsschicht in Retrieval-Augmented Generation integriert.

Wie sollte ich Erklärbarkeit in der Entity Resolution bewerten?

Die Anforderungen an Erklärbarkeit unterscheiden sich je nach Anwendungsfall. Bei regulierten Anwendungsfällen (KYC, AML, Kreditvergabe) müssen Sie feldgenau belegen können, warum zwei Datensätze verknüpft wurden oder eben nicht. Für Customer 360 oder Analytics kann ein Konfidenzwert genügen. Prüfen Sie, ob ein Eigenbau oder ein Anbieterdienst die Belege in der Tiefe offenlegt, die Ihre Compliance- und Audit-Workflows verlangen.