OLG Hamm 4 UKl 3/25 — was das KI-Chatbot-Haftungsurteil für die Architektur Ihres Dialogsystems bedeutet

TL;DR — 90 Sekunden

Das Urteil zementiert auf Plattform-Seite, was wir seit dem AI-Act-Trilog 2024 in jeder Architektur-Sitzung sagen: ein freischwebendes LLM auf der eigenen Webseite ist die teuerste Form der Kundendialog-Integration, weil die Halluzinations-Toleranz juristisch bei null liegt. Die Antwort ist nicht „kein KI-Dialog“, sondern die kontrollierte Architektur.

Was das Urteil sagt — und was es ausdrücklich nicht sagt

Eine Privatklinik aus dem Bereich der ästhetischen Medizin betrieb auf ihrer Webseite einen KI-Chatbot für Terminbuchung und Patientenanfragen. Auf Anfrage zu den Qualifikationen der beiden Geschäftsführer antwortete der Chatbot, diese seien Fachärzte für plastische und ästhetische Chirurgie beziehungsweise Fachärzte für ästhetische Medizin — beides Bezeichnungen, die es in der ärztlichen Weiterbildungsordnung nicht gibt. Die Verbraucherzentrale NRW klagte auf Unterlassung. Das OLG Hamm gab der Klage statt.

Die drei tragenden Erwägungen des Senats, übersetzt in Plattform-Sprache:

Erstens, Zurechnung. Der Chatbot ist Teil der geschäftlichen Organisation der Beklagten. Der oft im Markt vorgebrachte Verteidigungs-Reflex „das System ist autonom, wir haben darauf keinen Einfluss“ trägt nicht. Wer ein LLM-System auf die eigene Webseite stellt und es im eigenen Außenauftritt antworten lässt, handelt geschäftlich — auch wenn die einzelne Antwort generativ und damit nicht vorhersagbar ist.

Zweitens, Sorgfaltspflicht. Die sorgfältige Auswahl und Aufbereitung der Trainingsdaten entlastet nicht. Das ist die strategisch wichtigste Aussage des Urteils. In der Architektur-Diskussion wird häufig argumentiert, ein „mit korrekten Daten trainiertes Modell“ sei abgesichert. Das Urteil verneint diese Logik explizit: Generative Modelle produzieren auch aus korrekten Eingangsdaten falsche Ausgaben, Halluzination ist eine Eigenschaft des Generierungs-Prozesses, nicht ein Datenfehler. Eine Verkehrssicherungspflicht-Verteidigung, also der Verweis auf „angemessene Sorgfalt bei der Einrichtung“, greift damit nicht.

Drittens, UWG-Anker. Die Falschaussagen sind eine unzulässige geschäftliche Handlung nach § 5 Abs. 1, Abs. 2 Nr. 3 UWG (irreführende geschäftliche Handlung über die Person, Eigenschaften oder Rechte des Unternehmers). Das ist ein klassischer Wettbewerbsrechts-Anker, kein KI-spezifisches Neuland — der Senat hat das bestehende Lauterkeitsrecht auf KI-Outputs angewendet. Diese juristisch konservative Konstruktion ist der Grund, warum die Revision zum BGH zwar zugelassen wurde, eine vollständige Aufhebung aber wenig wahrscheinlich ist.

Was das Urteil nicht sagt, und was im Markt-Echo gelegentlich überlesen wird: Es untersagt nicht den Betrieb von KI-Chatbots. Es untersagt eine konkrete irreführende Aussage. Wer einen Chatbot so architektiert, dass solche Aussagen technisch nicht entstehen können, ist nicht Adressat des Urteils. Die Plattform-Seite hat damit eine klare Aufgabe: die generative Freiheit dort beschneiden, wo sie geschäftlich Schaden anrichten kann, und die Antwort-Pfade an verifizierte Quellen koppeln.

Die rechtliche Einordnung im Einzelfall (wer haftet wofür, welche Pflichten konkret bestehen, wie Verträge mit Modell-Anbietern zu lesen sind) gehört in die Hand Ihres Anwalts oder Datenschutzbeauftragten. Wir ordnen hier die Implikationen für die Plattform- und Architektur-Seite ein.

Wer auf der Plattform-Seite betroffen ist

Das Urteil adressiert KI-Chatbots im Kunden- oder Patientendialog. Die Plattform-Implikation reicht weiter, weil derselbe Mechanismus für jede generative Antwort-Schicht mit Außenwirkung gilt. Eine grobe Sortierung der Dialog-Schichten im DACH-Mittelstand, wie wir sie in der Bestandsarbeit antreffen.

Wer noch im obersten Quadrant arbeitet (Off-the-Shelf-Widget im iframe) und Aussagen über das eigene Unternehmen, Personen, Titel, Preise, Verfügbarkeiten oder Termine generieren lässt, hat nach dem Hammer Urteil das offensichtlichste Plattform-Problem. Die übrigen Muster sind handhabbar, brauchen aber jeweils einen Audit-Stand.

Auswirkungen für die Architektur

Drei Architektur-Konsequenzen, die wir nach dem 12. Mai in der Kunden-Arbeit unmittelbar adressieren.

Erstens, generative Antworten brauchen ein Grounding. Ein LLM, das frei aus seinem Foundation-Modell antwortet, ist nach dem Hammer Urteil im Außenauftritt nicht mehr tragbar. Die Architektur-Antwort heißt Retrieval-Augmented Generation (RAG): Das Modell darf nur antworten, was im verifizierten Korpus belegt ist. Im Klinik-Fall hätte das bedeutet: Wenn der Personen-Datensatz keine Facharzttitel enthält, kann das System auch keine erfinden — die generative Freiheit wird auf den Korpus eingeschränkt. Das ist keine Sales-Folklore, das ist die technische Antwort auf die Sorgfaltspflicht-Erwägung des Senats.

Zweitens, Tools schlagen Texte, wo immer möglich. Wer einen strukturierten Vorgang (Terminbuchung, Suche, Verfügbarkeitsabfrage, Formular-Submission) als generativen Text-Dialog abbildet, bezahlt mit Halluzinations-Risiko für eine Schicht, die er nicht braucht. Eine Tool-basierte Architektur, in der der Agent eine definierte API aufruft, eine strukturierte Antwort bekommt und sie strukturiert anzeigt, verlagert das Halluzinations-Risiko vom Anbieter zum Agent. Das ist genau der Pfad, den das Web Model Context Protocol (WebMCP) standardisiert: Webseiten exponieren Tools, Browser-Agents rufen sie auf, der Plattformbetreiber haftet für die Tool-Rückgaben (deterministisch), der Agent-Anbieter haftet für die Generierung (probabilistisch). Sauberer Schnitt, klare Verantwortlichkeiten.

Drittens, Audit-Trail ist nicht optional. Wenn ein Chatbot eine Aussage trifft, die später beanstandet wird, muss rekonstruierbar sein, was das System wann auf welcher Datengrundlage gesagt hat. Das ist nach Hammer Urteil nicht nur ein Compliance-Reflex, sondern eine reale Verteidigungsgrundlage: wer dokumentieren kann, dass der Korpus zum Antwort-Zeitpunkt die richtige Information enthielt und der Output sauber daraus abgeleitet war, steht in der Aufsichts-Konversation anders da als jemand, der nur sagen kann „das System hat eben das gesagt“. Content Provenance mit Ed25519-Signierung auf der Plattform-Seite, also der nachvollziehbare Beleg, was zu welchem Zeitpunkt im System stand, wird damit von einem AI-Act-Watermarking-Thema zu einem allgemeinen Sorgfalts-Thema.

Architektur-Antworten im Überblick

Vier Bausteine, in genau dieser Schichtung. Wir bauen diese in der Plattform-Arbeit unserer Kunden zusammen, sie ergeben aber auch einzeln Sinn — wer heute mit Schicht 1 anfängt, hat morgen die Grundlage für Schicht 2 bis 4.

Schicht 1: Korpus-Grounding (RAG)

Der generative Antwort-Pfad zieht aus einem verifizierten Korpus, nicht aus dem Foundation-Modell. Im Klinik-Fall wäre dieser Korpus die strukturierte Personen-Datenbank (Name, Position, tatsächliche Qualifikationen), und nichts, was nicht im Korpus steht, darf zitiert werden. Auf TYPO3-Plattformen lässt sich dieser Korpus aus den Personen-Records, Service-Beschreibungen, FAQ-Datensätzen und strukturierten Content-Blocks aufbauen. Die Schema.org-Person-Markup im Frontend ist dann auch gleich GEO-tauglich (Generative Engine Optimization) — die gleiche strukturierte Datenschicht, die das eigene RAG groundet, hilft externen Generativen, korrekt über Sie zu antworten.

Schicht 2: Access Classes und Sperrlisten

Manche Themen darf das Dialogsystem auch aus dem Korpus nicht beantworten: Preise im Verhandlungsstand, rechtliche Auskünfte, medizinische Beratung, individuelle Konditionen, sensible Personen-Daten. Eine Access-Class-Schicht definiert pro Themenbereich, ob das System antworten darf, eskalieren muss oder mit einem Standard-Verweis pausiert. Das ist die operative Antwort auf die Sorgfaltspflicht — das System gibt keine Aussage über Facharzttitel, wenn der Personen-Datensatz das Feld leer hat, und eskaliert stattdessen.

Schicht 3: Tool-basierte Architektur (WebMCP)

Strukturierte Vorgänge laufen über Tools, nicht über generative Texte. Eine Terminbuchung ist ein Form-Tool, eine Verfügbarkeitsabfrage ist ein Read-Tool, eine Adressänderung ist ein Mutation-Tool. Der Agent ruft das Tool auf, bekommt eine strukturierte Antwort und rendert diese; der generative Teil wird auf den Antwort-Stil reduziert, die Inhalte sind deterministisch. Diese Architektur ist auch dann tragfähig, wenn die KI-Lage in zwei Jahren wieder anders aussieht — Tools sind ein Plattform-Standard, kein KI-Trend.

Schicht 4: Audit-Trail und Provenance

Jede Antwort des Systems wird mit Quellenangabe, Korpus-Stand und Zeitstempel protokolliert. Bei sensiblen Themen kommt eine Ed25519-Signatur hinzu: das ist der Beleg, der vor Gericht oder gegenüber der Aufsicht trägt. Für KI-generierte Inhalte mit Außenwirkung kommt die C2PA-Manifest-Einbettung ergänzend ins Bild, die ohnehin ab 02.12.2026 für die Watermarking-Pflicht aus AI Act Artikel 50 vorgesehen ist. Beide Linien (Halluzinations-Verteidigung und Watermarking-Pflicht) laufen technisch auf demselben Provenance-Backbone.

Architektur-Prüfung Ihres Dialogsystems

Eine pragmatische Erste-Linien-Prüfung, die Sie mit dem oder der IT-Verantwortlichen in einer Sitzung durchgehen können.

1. Wir betreiben ein KI-Dialogsystem mit Außenwirkung auf unserer Webseite. Wenn ja: weiter. Wenn nein: das Urteil betrifft Sie auf der Plattform-Seite nicht akut, sondern höchstens präventiv.
2. Unser System kann Aussagen über Personen, Titel, Qualifikationen, Preise, Verfügbarkeiten oder Termine generieren. Wenn ja: die Halluzinations-Exposition ist die Plattform-Frage Nummer eins. Wenn nein: weiter zu 3.
3. Unser System antwortet ausschließlich aus einem verifizierten Korpus (RAG) und nicht frei aus dem Foundation-Modell. Wenn ja: Schicht 1 ist gelegt. Wenn nein: hier liegt die zentrale Architektur-Lücke.
4. Wir haben definierte Sperrlisten für Themen, die das System auch aus dem Korpus nicht beantworten darf (Preise im Verhandlungsstand, medizinische Beratung, rechtliche Auskünfte, individuelle Konditionen). Wenn nein: Schicht 2 fehlt.
5. Strukturierte Vorgänge laufen über Tools, nicht über generative Texte. Wenn nein: prüfen, wo eine Tool-basierte Architektur die generative Schicht ersetzen kann.
6. Wir können post-hoc rekonstruieren, was unser System zu einem konkreten Zeitpunkt gesagt hat, auf welcher Korpus-Grundlage, mit welchem Modell-Stand. Wenn nein: der Audit-Trail fehlt — und damit die Plattform-seitige Verteidigungsgrundlage.

Wer alle sechs Fragen klar mit Ja beantworten kann, hat die Plattform-Seite im Wesentlichen sortiert und die rechtliche Frage in eine handhabbare Form gebracht. Wer in zwei oder mehr Fragen unsicher ist, hat den Punkt, an dem eine Architektur-Inventur konkret lohnt.

Plattform-Empfehlung

Vorab eine Wenn/Dann-Übersicht für die häufigsten Konstellationen.

Jetzt aktiv werden, wenn Sie ein generatives Chatbot-Widget mit Außenwirkung auf Ihrer Webseite betreiben, das Aussagen über Personen, Titel, Preise oder Verfügbarkeiten erzeugen kann. Das ist die Konstellation, die das Urteil unmittelbar adressiert — Architektur-Inventur und Umbau auf gegroundete RAG-Pipeline.

Im Quartalsfenster planen, wenn Sie eine RAG-Pipeline ohne Access-Class-Schicht betreiben oder strukturierte Vorgänge generativ statt tool-basiert abbilden. Die Architektur ist tragfähig, aber die Lücken sind sichtbar.

Im Wochenrhythmus prüfen, wenn Sie eine Tool-basierte Architektur mit RAG-Fallback und Access Classes betreiben. Audit-Trail-Disziplin, Korpus-Hygiene und Brand-Voice-Pflege sind die laufenden Aufgaben.

Mittelstand mit Off-the-Shelf-Chatbot

Wenn Sie heute einen Foundation-Modell-Chatbot als Widget eingebunden haben (das übliche „in fünf Minuten installiert“-Muster), ist die Architektur-Antwort die Ablösung durch eine plattform-eigene RAG-Pipeline. Das ist weniger Aufwand, als der erste Eindruck nahelegt: der Korpus existiert in den meisten Fällen bereits als CMS-Content, Personen-Records und FAQ-Datensätze. Die generative Schicht wird gegen eine kontrollierte Antwort-Pipeline getauscht, die Außenwirkung bleibt vergleichbar, das Halluzinations-Risiko sinkt drastisch.

Mittelstand mit eigener RAG-Pipeline

Wenn Ihre Pipeline bereits aus einem verifizierten Korpus zieht, ist die nächste Frage die Access-Class-Schicht: gibt es Themen, die der Pipeline kategorisch verboten sind? Im Klinik-Fall wäre die Antwort „medizinische Qualifikationen werden ausschließlich aus dem strukturierten Personen-Datensatz beantwortet — und wenn das Feld leer ist, eskaliert die Pipeline an einen Menschen“. Diese Logik in die Pipeline einzuziehen ist ein eingrenzbares Projekt, kein Architektur-Neubau.

Mittelstand mit AI-Agents-Plattformbetrieb

Wenn Sie eine eigene Agent-Plattform betreiben oder planen, ist WebMCP der Weg, der die Architektur skalierbar macht. Tools statt Texte, Audit-Trail je Tool-Call, definierte Haftungsabgrenzung zwischen Plattformbetreiber und Agent-Anbieter. Das ist der Stand, an dem wir mit Bestandskunden im AI-Agents-Plattformbetrieb aktuell arbeiten.

Anbieter generativer AI-Anwendungen

Wenn Sie eigene Produkte auf Foundation-Modell-Schicht bauen (Customer-Support-Bot, AI-Suche, Voice-Assistent) und diese Ihren Kunden anbieten, wandert die Plattform-Haftung mit. Das Urteil ist hier nicht abschließend interpretiert, weil der Fall einen Plattform-Betrieb für Endkunden adressiert; die analoge Anwendung auf B2B-AI-Produkte ist aber wahrscheinlich. Architektur-seitig empfehlen wir den gleichen Stack wie für eigene Anwendungen: RAG, Access Classes, Audit-Trail, Tools wo möglich.

Fazit

Das OLG Hamm hat in 4 UKl 3/25 keine neue rechtliche Schwelle gesetzt, sondern eine bestehende klar tenoriert. Das macht das Urteil so wichtig: es ist keine technologiefeindliche Sondernorm, sondern eine konservative Anwendung des Wettbewerbsrechts auf KI-Outputs. Die UWG-Linie ist robust, die Revision wird die Konstruktion möglicherweise verfeinern, aber kaum aufheben.

Die Frage lautet nicht, ob das Urteil für Sie gilt — die Plattform-Implikationen sind größenunabhängig und gelten überall, wo ein generatives Modell Außenwirkung erzeugt. Sie lautet, ob Ihre Dialog-Architektur die Halluzinations-Frage in der Konstruktion adressiert oder ob sie auf den Disclaimer hofft. Aus unserer Sicht in der Plattform-Arbeit ist die Antwort eindeutig: kontrollierte Architektur, gegroundete Generierung, Tool-basierte Vorgänge wo möglich, Audit-Trail standardmäßig. Das ist die Architektur, mit der wir seit zwei Jahren bauen, und das ist die Architektur, die das Urteil jetzt für alle anderen explizit gemacht hat.

Dieser Beitrag ordnet die Plattform- und Architektur-Implikationen des OLG-Hamm-Urteils ein. Er ist keine Rechtsberatung und ersetzt die Prüfung Ihres konkreten Einzelfalls durch Rechtsanwalt oder Datenschutzbeauftragten nicht.