Ugur Tarlig

28. Juni 2026 · 1.677 Wörter · 8 Min. Lesezeit

KI-Haftung ist ein Architekturproblem

Ein Chatbot erfand Facharzttitel.

Das klingt erst einmal wie ein typischer KI-Fehler: ein Modell halluziniert, ein System gibt eine falsche Antwort, irgendjemand ergänzt später einen Disclaimer. Das OLG Hamm hat den Fall anders behandelt.

Ein Anbieter ästhetischer Behandlungen hatte auf seiner Website einen Chatbot eingesetzt. Nutzer konnten Fragen stellen und Termine buchen. Auf konkrete Fragen stellte der Bot die beiden Geschäftsführer als Fachärzte für bestimmte Bereiche der ästhetischen Medizin dar. Diese Qualifikationen hatten sie nicht, und zwei der genannten Titel existierten in dieser Form nicht einmal.

Das Gericht wertete die Aussagen als irreführende geschäftliche Handlung. Entscheidend für die Architekturperspektive ist nicht nur das Ergebnis, sondern die Zurechnung: Der Chatbot wurde nicht als autonomer Dritter behandelt, die Aussagen wurden dem Betreiber zugerechnet. Das Urteil ist noch nicht rechtskräftig, die Revision zum BGH ist zugelassen. Es ist also kein endgültiger Schlusspunkt und schon gar kein neues allgemeines “KI-Haftungsgesetz”. Aber als Signal reicht es.

Wer KI in kundennahen oder regulierten Prozessen nach außen sprechen lässt, muss damit rechnen, dass dieser Output nicht als bloßer Modellfehler behandelt wird. Er wird Teil der Unternehmenskommunikation, Teil des Prozesses, Teil des Risikos. Genau hier wird Haftung von einer Rechtsfrage zu einer Architekturfrage.

Der falsche Reflex: Disclaimer

Der naheliegende Reflex ist ein Disclaimer.

Diese Antwort wurde von KI erzeugt.

Bitte prüfen Sie die Angaben.

Für die Richtigkeit übernehmen wir keine Gewähr.

Solche Hinweise können sinnvoll sein, aber sie lösen nicht das eigentliche Problem. Ein Disclaimer verhindert nicht, dass ein System eine falsche Qualifikation nennt. Er verhindert nicht, dass ein Nutzer die Aussage glaubt, dass ein Chatbot einen Termin, eine Empfehlung oder eine geschäftliche Aussage auslöst, und er macht einen schlechten Prozess nicht kontrollierbar.

Ein Disclaimer ist Kommunikation.

Ein Guardrail ist Architektur.

Der Unterschied ist wichtig. Kommunikation sagt dem Nutzer, dass etwas schiefgehen kann. Architektur reduziert die Wahrscheinlichkeit, begrenzt den Schaden und macht nachvollziehbar, was passiert ist. In produktiven KI-Systemen braucht man beides, aber wer den Disclaimer als Ersatz für System-Design behandelt, verschiebt Verantwortung an die falsche Stelle.

Output ist kein Nebeneffekt. Er ist Systemverhalten

Viele KI-Piloten behandeln Output wie ein UI-Detail. Das Modell antwortet, der Nutzer sieht eine Box, vielleicht justiert man nach. Im Pilot trägt diese Haltung, weil der Kreis klein ist und niemand ernsthaft von der Antwort abhängt.

In Produktion ändert sich die Rolle des Outputs. Er bereitet Entscheidungen vor, beeinflusst Kunden, erzeugt medizinische, rechtliche oder vertragliche Erwartungen, löst Aktionen aus. Je näher ein System an eine bindende Aussage oder folgenschwere Aktion rückt, desto weniger darf man sich auf “das Modell wird schon richtig antworten” verlassen. Dann ist Output kein Text mehr. Er ist Verhalten des Systems, und Systemverhalten gehört in die Architektur.

Damit verschiebt sich auch die zentrale Frage. Nicht: Welches Modell ist am besten? Sondern: Welcher Output darf in welchem Kontext das Haus verlassen? Aus dieser einen Frage folgen fast alle relevanten Architekturentscheidungen:

Das sind keine juristischen Randnotizen, sondern Designbedingungen.

Fünf Bausteine für zurechenbaren KI-Output

Wenn KI-Output einem Betreiber zugerechnet werden kann, muss die Architektur so gebaut sein, dass dieser Output kontrollierbar bleibt. Dafür braucht es keine perfekte, überkomplizierte Plattform, aber ein paar Bausteine sollten vor dem Go-live vorhanden sein.

1. Human-in-the-loop bei folgenreichen Aktionen

Nicht jede Antwort braucht einen Menschen. Wenn ein interner Assistent eine Richtlinie zusammenfasst oder einen Entwurf erstellt, kann direkte Ausgabe sinnvoll sein. Aber wenn eine Antwort bindend wirkt, eine Zusage enthält, einen medizinischen Kontext berührt oder einen Prozess auslöst, muss die Architektur anders aussehen.

Der Mensch sollte nicht überall in der Schleife hängen, sonst wird das System unbenutzbar. Bei folgenreichen Aktionen aber braucht es klare Schwellen:

Diese Übergänge müssen im System sichtbar sein. Sonst entscheidet das Modell implizit, wo eigentlich ein Prozessdesign entscheiden müsste.

2. Output-Guardrails vor dem Nutzer

Guardrails sind nicht nur Moderationsfilter. In produktiven Enterprise-Systemen prüfen sie, ob eine Antwort überhaupt die Regeln des Systems erfüllt:

Wichtig ist die Position im Ablauf: Guardrails müssen vor der Sichtbarkeit greifen, nicht erst nachträglich in einem Dashboard. Wenn der Nutzer die falsche Antwort schon gesehen hat, ist der Schaden nicht mehr nur technisch.

3. Quellenbindung statt freier Behauptung

Ein KI-System in einem regulierten Umfeld sollte nicht einfach “wissen”, sondern zeigen, worauf es sich stützt. Das klingt trivial, ist aber architektonisch anspruchsvoll. Eine Quellenangabe reicht nicht, wenn sie nur dekorativ ist. Die Antwort muss aus einem belastbaren Kontext kommen, und der Nutzer oder Prüfer muss nachvollziehen können, welcher Teil der Antwort durch welche Quelle gedeckt ist. Gerade bei RAG-Systemen ist das der Unterschied zwischen:

Das System klingt plausibel.

und:

Das System kann belegen, warum es das gesagt hat.

In der Praxis sehe ich zwei besonders tückische Fälle, beide gefährlicher als die offensichtliche Halluzination, gerade weil die Antwort belegt aussieht.

Der erste Fall: Die Antwort trägt echte Quell-Links, stützt sich aber auf ungeeignete Dokumente. Ein typisches Muster sind Tabellen-Exporte. Beim Embedding verlieren sie ihre Struktur, und über zufällige Stichwort-Überschneidungen erzeugen sie plausible, aber irreführende Treffer. Dazu kommen Dokumente, die thematisch gar nicht in die Wissensbasis gehören und trotzdem mitindexiert wurden. Die Quellenangabe ist dann kein Beleg mehr, sondern Dekoration.

Der zweite, subtilere Fall: Das System kombiniert Textstücke aus zwei realen Dokumenten zu einer Antwort, die wie ein drittes, in sich stimmiges Dokument klingt. Dieses Dokument hat es so nie gegeben. In einer Welt aus kontrollierten SOPs, in der genau eine Prozedur genau einem freigegebenen Dokument entspricht, ist das nicht nur ein Faktenfehler. Es ist eine Aussage, die im Dokumentenbestand gar nicht existiert und trotzdem zitierfähig aussieht.

Beide Fälle führen zur selben Konsequenz. Quellenbindung muss auf der Ebene der einzelnen Aussage nachvollziehbar sein: Welcher Satz stützt sich auf welche Quelle? Ein dekorativer Link am Ende reicht nicht. Für interne Wissenssysteme ist das wichtig, für kundennahen, medizinischen oder regulatorischen Output ist es zentral.

4. Audit-Traces statt Chatverlauf

Ein Chatverlauf ist keine Audit-Spur. Für produktive KI-Systeme reicht es nicht zu speichern, was der Nutzer gefragt und was das Modell geantwortet hat. Man muss rekonstruieren können, wie die Antwort entstanden ist:

Das klingt nach Betrieb und Compliance, und das ist es auch. Aber vor allem ist es Engineering. Ohne solche Traces kann man Fehler nicht sauber analysieren, Systeme nicht verbessern und Streitfälle nicht nachvollziehen.

5. Evals statt Hoffnung

Viele Teams testen KI-Systeme so, wie man Demos testet: ein paar Beispiele, ein paar gute Antworten, ein Gefühl von “funktioniert”. Das reicht nicht für Produktion. Evals sind keine akademische Übung, sondern die einzige belastbare Methode, um zu messen, wie oft ein System in relevanten Fällen falsch liegt. Besonders wichtig sind domänenspezifische Testfälle:

Ein gutes Eval-Set bildet nicht die einfachsten Fälle ab, sondern die, bei denen ein Fehler teuer wird. Wenn man das nicht selbst misst, misst es irgendwann jemand anderes: ein Kunde, ein Auditor, ein Gericht.

Warum das in regulierten Umfeldern ab Tag 1 dazugehört

Ich arbeite seit fast zwei Jahren an KI-/GenAI-Systemen in einem regulierten Healthcare-Umfeld. Dort merkt man schnell: Compliance ist kein Feature, das man später ergänzt, sondern eine Designbedingung. Nicht, weil regulierte Organisationen innovationsfeindlich wären, sondern weil dort die Folgen falscher Aussagen real sind. Ein System kann nicht nur falsch liegen. Es kann Vertrauen beschädigen, Prozesse verzerren oder Entscheidungen beeinflussen, die eigentlich kontrolliert bleiben müssen.

Deshalb ist die Reihenfolge wichtig. Nicht: erst den Chatbot bauen, später die Governance. Sondern: erst klären, welcher Output erlaubt ist, dann das System bauen. Das bedeutet nicht, dass alles langsam und bürokratisch werden muss. Im Gegenteil: Gute Architektur macht sichere Nutzung schneller, weil sie den Rahmen vorher klärt.

Ein Team muss nicht bei jeder Antwort diskutieren, wenn das System bereits weiß, was es sagen darf, was es belegen muss, was es blockieren muss, was es eskalieren muss und was es protokollieren muss. Das ist der Unterschied zwischen Governance als Bremse und Governance als Betriebssystem.

Die Modellfrage ist selten die wichtigste Frage

Viele KI-Diskussionen starten beim Modell. Claude oder GPT? Cloud oder Open Weights? Frontier-Modell oder günstigeres Modell? RAG oder Agent? Diese Fragen sind relevant, aber sie kommen zu früh, wenn die Output-Verantwortung nicht geklärt ist. Es ist dasselbe Muster, das ich an anderer Stelle beschrieben habe: Nicht das Modell ist der eigentliche Engpass, sondern Governance, Messbarkeit und kontrollierte Umsetzung.

Ein stärkeres Modell löst keine unklare Verantwortlichkeit. Es ersetzt keine Freigabegrenzen, erzeugt keine Audit-Spur und entscheidet nicht, welche Aussage ein Unternehmen gegenüber einem Kunden vertreten will. Das Modell erzeugt Möglichkeiten. Die Architektur entscheidet, welche davon das System tatsächlich nutzen darf.

Die Frage vor dem Go-live

Der wichtigste Satz vor dem Go-live eines KI-Agenten lautet nicht:

Wie gut ist das Modell?

Sondern:

Was passiert, wenn das System in einem kritischen Fall falsch liegt?

Wenn die Antwort darauf nur lautet “dann schreiben wir einen Disclaimer darunter”, ist das System nicht produktionsreif. Produktionsreif wird es erst, wenn Fehler erwartet, begrenzt, gemessen und nachvollziehbar gemacht werden.

KI-Haftung ist deshalb nicht nur ein Rechtsthema. Sie ist eine Architekturanforderung. Und je näher KI-Systeme an echte Kunden, Patienten und Geschäftsprozesse rücken, desto weniger ist diese Anforderung optional.

Quelle: OLG Hamm, Urteil vom 12.05.2026, Az. 4 UKl 3/25.