Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

01.03.1991 - 

Diagnostische Expertensysteme auf dem juristischen Prüfstand

Rechtsunsicherheit bei der Haftung für Expertensysteme

Von Roman R. Laczkovich*

Bei Software herrscht derzeit erhebliche Rechtsunsicherheit bezüglich der Haftung für fehlerhafte Software und daraus resultierenden Schäden. Einen Präzedenzfall stellen hier Expertensysteme (XPS) zur technischen Fehlerdiagnose dar, deren Aufgabe darin besteht, Fehler erkennen und beheben zu helfen. Die haftungsrechtliche Situation bei einem Fehlverhalten eines derartigen Systems soll im folgenden näher beleuchtet werden.

Etwas überspitzt formuliert stellen Expertensysteme (XPS) nach der Automatisierung der körperlichen menschlichen Arbeit erste Ansätze zur Automatisierung geistiger menschlicher Arbeit dar. Konventionelle Datenverarbeitung sei in diesem Zusammenhang ausgeklammert, da sie sich primär mit einer algorithmischen Verarbeitung von Massendaten beschäftigt. Bei Expertensystemen hingegen wird versucht, Problemlösungsverhalten zu implementieren, was bislang ausschließliche Domäne menschlicher Betätigung war. Die nachfolgenden Ausführungen stützen sich vornehmlich auf Diagnostikexpertensysteme (DXPS), da haftungsrechtliche Problemstellungen hierbei in besonderem Maße erkennbar sind.

Ergebnis der Arbeit von DXPS können Expertisen oder, bei Zubilligung einer gewissen Entscheidungskompetenz, sogar selbständige Entscheidungen sein. Im Rahmen der Systemsicherheit führt die potentielle Gefahr von fehlerhaften Expertisen oder Fehlentscheidungen durch ein DXPS zu Fragen der Art "Wer haftet für Expertensysteme?" [1], [2], [3]. Diese Fragestellung an sich ist irreführend. Anknüpfend mittelalterlichen Homunculus-Gedanken suggeriert sie als Antwort: der Ersteller des DXPS oder das System selbst. Da nun das DXPS nicht für sich selbst haften kann, folgt daraus, daß der Ersteller haftet. Solche Vorstellungen sind naiv.

Eine eingehendere Betrachtung der Umstände bei praktischen Einsätzen von DXPS zeigt, daß die in der eingangs erwähnten Fragestellung angesprochene Problematik anders gelagert ist. Aus juristischer Sicht sind vielmehr folgende Fragen von Interesse:

- Welche Anspruchsgrundlagen bestehen für eine Haftung bei Schäden aus dein Einsatz von DXPS?

- Wer kann diese Ansprüche gegen wen geltend machen?

- Mit welchen Strategien kann diesen Ansprüchen begegnet werden?

Die Jurisprudenz hängt vom zugehörenden politischen System und dem entsprechenden Kulturkreis ab. Darum können auch haftungsrechtliche Grundsätze nicht allgemein diskutiert werden. Die nachfolgenden Ausführungen stützen sich deshalb, soweit nicht gesondert darauf hingewiesen wird, auf die in der Bundesrepublik Deutschland geltende Rechtsprechung. Dabei sollen Denkanstöße gegeben werden, wie dieser diffuse Problembereich betrachtet werden könnte.

Dem Verfasser ist bisher nicht bekannt, ob ein Fall rechtshängig wurde, bei dem Haftungsansprüche aus der Schädigung eines Rechtsgutes durch den Betrieb eines XPS gestellt wurden. Überlegungen zu Haftungsfragen fanden sich bisher zwar in erster Linie im Zusammenhang mit konventioneller Software; die bei XPS entstehenden Probleme sind aber ähnlich. Es soll daher geprüft werden, inwiefern es statthaft ist, diese Überlegungen auf DXPS zu übertragen. Sofern sich Unterschiede ergeben, sollen diese herausgestellt werden.

Fehlerhafte Expertisen und darauf aufbauende Fehlentscheidungen eines DXPS lassen sich als Fehler des Systems interpretieren. In der Literatur findet sich bezüglich der Fehler von konventioneller Software ein breites Spektrum an Definitionsversuchen [4]. Ihnen allen ist gemeinsam, daß die betrachtete Software im Umfang und Art der Funktionserfüllung von einerseits spezifizierten und andererseits vorauszusetzenden Sollvorgaben abweicht. Die Ursachen dafür können in der Konzeption, der Kodierung oder der Bedienung der betrachteten Software liegen [5].

Die Übertragung dieses Fehlerbegriffs auf XPS ist aber in mehrfacher Hinsicht problematisch. Diese Systeme sind vorwiegend zur Lösung schwach- oder teilstrukturierter Probleme konzipiert, gehen im allgemeinen heuristisch vor und sollen menschlichen Experten vergleichbare Ergebnisse erbringen. Da es aber keine Grundsätze zur ordnungsgemäßen Problemlösung durch menschliche Experten gibt, gerade diese Fähigkeit auch nicht formalisierbar ist, können Sollvorgaben nur auf recht abstrakter Ebene erfolgen, was wiederum die Kontrollmöglichkeiten einschränkt. Dies äußert sich sowohl bei der Wissensbasis als auch bei der XPS-Shell.

Wesentlicher Teil der XPS-Shell ist die Inferenzkomponente, deren Aufgabe darin besteht, aus dem Wissen der Wissensbasis und fallspezifischen Fakten zu Schlußfolgerungen zu kommen. Da es eine besondere Eigenschaft von XPS ist, "weiches" Wissen [6] zu verarbeiten, sind dazu auch besondere Inferenzverfahren nötig, die unter Stichworten wie nichtmonotone Logik, unscharfes Schließen etc. firmieren. Das wiederum bedeutet, daß sich Ergebnisse von derartigen Schlußfolgerungen auch nicht immer im Sinne eines 0-1-Denkens als richtig oder falsch beurteilen lassen. Bei der Wissensbasis ist das Problem ähnlich gelagert. In ihr manifestiert sich das spezielle Expertenwissen, das aber bei unterschiedlichen Expertenmeinungen zum gleichen Diagnostikproblem subjektiv unterschiedlich sein kann, und insofern ebenfalls eine Beurteilung nach den Kategorien "richtig" oder "falsch" erschwert.

Bei den Fehlerursachen sind die Analogien von XPS und konventioneller Software allerdings deutlicher. So läßt sich auch bei einem DXPS danach fragen, ob es grundsätzlich für die vorgesehene Aufgabe geeignet ist. Kodierungsfehler können ebenfalls auftreten, da sowohl XPS-Shell und Wissensbasis in definierten Sprachen formuliert werden [7]. Schließlich können Fehler auch bei XPS durch den Benutzer provoziert werden.

Des weiteren läßt sich auch die in der gesichteten Literatur einhellig vertretene Meinung übertragen, daß es illusorisch ist, völlig fehlerfreie Software zu erwarten [8]. Die Umsetzung realer Probleme in Softwaresysteme führt zu einer Komplexität, die trotz leistungsfähiger Design- und Testmethoden vom Menschen nicht vollständig beherrscht wird [9].

Als Fazit ist daher festzuhalten, daß Fehler bei XPS grundsätzlich nicht ausgeschlossen werden können und Fehler teilweise auch nur schwer nachzuweisen sind. Es gibt daher eine große Grauzone, in der der Fehlerbegriff bei XPS äußerst diffus ist. Rechtliche Regelungen, die Haftungsansprüche begründen könnten, sind folglich allenfalls in dem relativ kleinen Spektrum eindeutig identifizierbarer Fehler anwendbar.

Als Voraussetzung möglicher Anspruchsgrundlagen ist es zunächst erforderlich, die durch eventuelle Schäden Betroffenen nach dem Grad der Betroffenheit zu unterscheiden. Hierbei lassen sich prinzipiell zwei Parteien ausmachen: der durch das DXPS Geschädigte und der Betreiber des DXPS.

Bei genauerer Betrachtung kann noch weiter differenziert werden. So läßt sich noch der Ersteller des DXPS ausmachen, der unter Umständen identisch mit dem Betreiber des DXPS sein kann.

Werden Ersteller und Betreiber als Unternehmen betrachtet, so lassen sich in diesem Bereich noch Angestellte und freie Mitarbeiter unterscheiden, die für das Unternehmen tätig werden. Geschädigt können sowohl der Betreiber des DXPS oder ein Dritter sein. Daraus folgend läßt sich durch bloße Kombination ein breites Spektrum denkbarer Anspruchsfälle konstruieren.

Grundlagen für Rechtsansprüche

Unter der Voraussetzung, daß der mit einem DXPS in Verbindung gebrachte Schaden möglicherweise erheblich ist und daher gravierende wirtschaftliche Auswirkungen haben kann, konzentrieren sich die weiteren Ausführungen auf Fragen des Schadensersatzes. Aufgrund des erwähnten breiten Spektrums werden in diesem Zusammenhang nur einige mögliche Anspruchsgrundlagen auf Schadensersatz untersucht. Der Schadensersatz soll sich dabei nur auf unmittelbare Schäden beziehen, das heißt auf Schäden, die Personen oder Gegenständen zugefügt wurden. Haftungsbegründende Anspruchsgrundlagen lassen sich dazu aus der vertraglichen, der deliktischen oder der Gefährdungshaftung ableiten.

Die Vertragsgestaltung ist den Vertragspartnern im Rahmen der Vertragsfreiheit freigestellt. Entsprechend den unterschiedlichen Vertragsinhalten: Überlassung, Erstellung oder Pflege eines DXPS lassen sich die Verträge stets auf die Grundformen des Kauf-, Pacht- oder Werkvertrags zurückführen [10]. je nach Grundform können sich bezüglich der Haftung Unterschiede in den Voraussetzungen ergeben:

- Kaufvertrag: Zusicherung von Eigenschaften oder arglistiges Verschweigen von Fehlern (° 463 BGB)

- Pachtvertrag: Zusicherung von Eigenschaften, beziehungsweise keine oder geminderte Tauglichkeit zum im Vertrag bestimmten Gebrauch (°° 537, 538 BGB)

- Werkvertrag: Zusicherung von Eigenschaften, beziehungsweise keine oder geminderte Tauglichkeit zum im Vertrag bestimmten Gebrauch und Verschulden des Erstellers des DXPS (° 635 BGB)

Grundsätzlich können Schadensersatzansprüche wegen Nichterfüllung gestellt werden. Als Grundlage dafür dient bei allen Vertragstypen ein Fehler, der sich als Nichtvorhandensein von vom Schuldner zugesicherten Eigenschaften interpretieren läßt. Abgesehen von Vertragsauslegungsproblemen läßt sich auch eine nicht vorhandene oder geminderte Tauglichkeit zum im Vertrag bestimmten Gebrauch, wie sie beim Pacht- und Werkvertrag gefordert wird, inhaltlich ähnlich wie zugesicherte Eigenschaften behandeln. Eine weitere Grundlage stellt die schuldhafte Verletzung von vertraglichen Nebenpflichten durch den Schuldner dar. Dabei handelt es sich um Aufklärungs-, Auskunfts-, Warn-, Schutz-, Mitwirkungs- und ähnliche Pflichten, bei deren Verletzung die Regeln der positiven Vertragsverletzung zur Anwendung kommen [1].

Bei DXPS wären zugesicherte Eigenschaften die Spezifikationen von Schnittstellen, zum Beispiel zur Integration des DXPS in das bestehende Hard- und Softwaresystem des Betreibers oder zur korrekten Dateninterpretation von angeschlossenen Sensoren. XPS beanspruchen, auf eng begrenztem Gebiet Expertenniveau zu bieten. In den Randgebieten fällt ihre Kompetenz steil ab. Deshalb ist die Erfüllung von vertraglichen Nebenpflichten durch den Schuldner von besonderer Bedeutung, wie zum Beispiel die Information des Betreibers über die Grenzen des Anwendungsgebietes.

Ansprüche aus vertraglicher Haftung können nur vom Gläubiger an den Schuldner gestellt werden. Die Bestimmung des Haftungsumfanges kann bei DXPS allerdings schwierig sein. Da Software und damit auch DXPS prinzipiell und auch allgemein anerkannt fehlerbehaftet sind, besteht beim Einsatz von DXPS ein Restrisiko. Es kann verlangt werden, daß das den Vertragspartnern bewußt ist. Folglich wäre es unbillig, Haftungsansprüche, die aus einem Schaden resultieren, der letztlich durch ein DXPS verursacht wurde, nur von einer Vertragspartei verantworten zu lassen.

Diese Ansicht wird noch dadurch gestützt, daß ein Schaden,

je nach Entscheidungsbefugnis des DXPS erst durch eine Handlung des Benutzers entsteht, der sich auf das Resultat einer Konsultation des DXPS verläßt. Eine weitere Unterstützung erfährt diese Ansicht noch in dem Falle, daß das DXPS zusammen mit dem späteren Betreiber entwickelt wurde, und dieser somit Gelegenheit hatte, auf die Gestaltung des DXPS Einfluß zu nehmen.

Aus diesen Gründen wäre es zu erwägen, eine Risikoverteilung vorzunehmen. Allerdings ist diesbezüglich keine pauschale Beurteilung möglich.

Bei der deliktischen Haftung lassen sich mehrere Tatbestände feststellen. Grundlage bildet die schuldhafte Verletzung eines geschätzten Rechtsgutes (° 823 Abs. 1 BGB) oder Schutzrechtes (° 823 Abs. 2 BGB). Schuldhaft, bedeutet in diesem Zusammenhang die Verletzung von Sorgfaltspflichten, um die eingangs erwähnten Fehlerursachen auszuschließen [12]. Problematisch ist dabei für den Geschädigten allerdings der Nachweis, daß der schadenverursachende Fehler vom Ersteller des DXPS verschuldet wurde.

Eine Erleichterung beim Verschuldensnachweis ergibt sich unter Umständen, wenn das DXPS als Kombination von Hard- und Software oder als Produktbestandteil des Diagnoseobjekts betrachtet wird. Dann sind eventuell Ansprüche nach dem "Gesetz über technische Arbeitsmittel (GtA)" von 1979 möglich [13]. Danach hat der Hersteller bestimmte Sicherheitsbestimmungen zu erfüllen, wie zum Beispiel Hinweise auf Gefahren (° 3 Abs. 3 Satz 1 GtA) oder die Beigabe von Gebrauchsanweisungen mit Hinweisen auf Handhabung, Ersatzteileinbau und Instandhaltung (° 3 Abs. 3 Satz 2 GtA). Verletzt er diese pflichten, so wird sein Verschulden vermutet. Die vom GtA nicht erfaßten Objekte, wie zum Beispiel überwachungsbedürftige Anlagen, können eventuell über eine Verletzung der Vorschriften des ° 24 GewO [14] oder anderer spezieller Rechtsvorschriften wie zum Beispiel des Bau- [15] oder Eichrechts [16] miteinbezogen und in analoger Weise behandelt werden.

Explizit zum Ausdruck kommt diese Vorgehensweise im Konstrukt der Produzentenhaftung, die mittlerweile unter der Bezeichnung Produkthaftung im neuen Produkthaftungsgesetz auch gesetzlich verankert ist. Für sie ist die Beweislastumkehr bezeichnend. Die Ursache dafür ist, daß Produktionsprozesse und Organisationsstrukturen von Unternehmen für Außenstehende im allgemeinen nicht einsichtig und nachvollziehbar sind. Das bedeutet, wie oben bereits erwähnt, daß ein geschädigter Dritter nicht den Nachweis erbringen kann, daß sein Schaden durch einen Fehler im Verantwortungsbereich des Unternehmens verursacht wurde. Die hierfür erforderliche Produkteigenschaft wird in der Literatur für Software weitgehend bejaht [17], [18], [19], [20]. Diese Aussage kann auch auf XPS übertragen werden, da sich diese Systeme als datenträgergebundenes, immaterielles Wirtschaftsgut unter dem Begriff Software subsummieren läßt.

Serienprodukt oder Einzelauftrag

Ansprüche ans deliktischer Haftung können sowohl geschädigte Dritte an den Ersteller oder den Betreiber des DXPS stellen, als auch geschädigte Gläubiger, deren Ansprüche über die vertragliche Haftung hinausgehen. Für geschädigte Dritte ist sogar die Schutzfunktion der Beweislastumkehr bei der Produzentenhaftung gerechtfertigt, wenn dem Geschädigten der Verschuldensnachweis nicht zugemutet werden kann.

Bei den geschädigten Gläubigern muß dabei aber danach unterschieden werden, ob die geschuldete Leistung, ein Serienprodukt ist, wie zum Beispiel eine serienmäßige Verbindung von DXPS mit einer CNC-Maschine als intelligentes Handbuch oder ein in Auftrag gegebenes Einzelprodukt, bei dessen Erstellung der Gläubiger mitbeteiligt ist [21]. Dieser letzte Fall erlangt besondere Bedeutung, da die Konzeption von DXPS gerade dann als zweckmäßig erscheint, wenn keine Standardlösung zu speziellen Diagnostikproblemen existiert. Hierbei wäre die Rechtfertigung für eine Beweislastumkehr in Frage zu stellen, da der Gläubiger durch die zwangsläufig enge Zusammenarbeit mit dem Ersteller des DXPS sehr wohl Einblick in den Prozeß der DXPS-Erstellung erhält.

Die am weitesten gehende Haftungsgrundlage stellt die Gefährdungshaftung dar. Der Grundgedanke bei ihr ist, daß jemand, der potentielle Gefahrenquellen in den Verkehr bringt, unabhängig von Verschulden und Rechtswidrigkeit der Handlung für schädigende Folgen seines Produktes zu haften hat. Die prinzipiell nicht auszuschließende Fehlerhaftigkeit des DXPS, gepaart mit Anwendungsbereichen mit hohem Gefährdungspotential, wie zum Beispiel Kernkraftwerke oder chemische Anlagen, lassen DXPS in diesen Fällen durchaus als risikobehaftet und damit als potentielle Gefahrenquelle erscheinen [22]. Speziell auf XPS oder sogar auf DXPS ausgerichtete Gesetze sind noch nicht verabschiedet worden. Ansprüche könnten aber aus Spezialgesetzen zum Einsatzbereich abgeleitet werden [23].

Abgesehen von den Alternativen, sich aus dem Markt zurückzuziehen oder haftungsrechtliche Konsequenzen aus dem DXPS-Einsatz zu ignorieren, gibt es eine Vielzahl differenzierter Möglichkeiten, um eventuellen Haftungsansprüchen zu begegnen. Grundsätzlich lassen sich fehlervermeidende und schadenminimierende Strategien unterscheiden.

Als schadenminimierende Strategie kommt primär die Vertragsgestaltung in Betracht. Prinzipiell ist die Vertragsgestaltung in hohem Maße freizügig. Spezielle Klauseln über den Haftungsumfang können bis auf den Ausschluß von Vorsatzhaftung nach ° 276 Abs. 2 BGB und einer Inhaltskontrolle nach ° 242 BGB ohne Einschränkung

in den Vertrag aufgenommen werden [24], [25]. Generelle Haftungsausschlüsse in den Allgemeinen Geschäftsbedingungen können nach ° 11 Ziffer 7 AGBG allerdings zur Unwirksamkeit der betreffenden Klausel führen, ohne den restlichen Vertragsinhalt zu berühren (° 6 Abs. 1 AGBW), mit der Folge, daß in vollem Umfang gehaftet wird (° 6 Abs. 1 AGBG). Weitere Möglichkeiten bestehen in einer genauen Spezifikation der geschuldeten Leistung im Sinne von zusicherbaren Eigenschaften des DXPS sowie der Verlagerung von Nebenpflichten auf den Vertragspartner.

Ferner können präventive Maßnahmen ergriffen werden, um Entlastungsbeweise zu vereinfachen. Möglichkeiten beständen hier in der Dokumentation der DXPS-Erstellung [26] sowie der Verwendung von "Logdateien" über Benutzer- und Systemaktivitäten zum Nachweis von nicht zu vertretenden Benutzerfehlern.

Schließlich gibt es noch die Möglichkeit, Versicherungen gegen Folgeschäden abzuschließen. Nicht versicherbar sind allerdings Schäden, die die vertragliche Sachmängelhaftung betreffen [27]. Die aus den übrigen Anspruchsgrundlagen resultierende Haftung ist prinzipiell versicherbar [28].

Fehlervermeidende Strategien lassen sich entsprechend den Fehlerarten: Konzeptions-, Kodierungs- und Betriebsfehler unterscheiden [29]. Um Konzeptionsfehler zu vermeiden, ist es erforderlich, den Anwendungsbereich möglichst umfangreich und sorgfältig zu analysieren. In diesem Zusammenhang wird auf den Berufsstand der Knowledge-Engineers verwiesen, die speziell auf die dabei anfallenden Probleme hin ausgebildet werden. Ein auf dieser Analyse basierendes Pflichtenheft sollte vom Benutzer validiert werden, um eventuelle Kommunikationsprobleme zwischen Benutzer und Ersteller schon in diesem frühen, aber richtungsweisenden Stadium der DXPS-Erstellung auszuschließen.

Mittlerweile werden spezielle DXPS-Shells, mit recht unterschiedlichen Leistungsmerkmalen und Hardwareanforderungen angeboten. Daher ist es sinnvoll, die im Pflichtenheft formulierten Anforderungen auch bei der Auswahl der XPS-Shell zu berücksichtigen.

Durch die Verwendung von Konfidenzfaktoren in der Wissensbasis in Verbindung mit geringen Schwellwerten zur Etablierung von Hypothesen kann eine risikovermeidende Strategie bei der Verdachtsgenerierung verfolgt werden [30]. Dadurch kann auf der einen Seite ein Folgeschaden durch eine nicht erkannte Störung vermieden werden, auf der anderen Seite führt diese Strategie allerdings zu einer Übersensibilität des DXPS mit häufigen Fehlalarmen.

Um Kodierungsfehler zu vermeiden, haben sich im Bereich der konventionellen Software Standards zur Erstellung und zum Testen herausgebildet, wie zum Beispiel die Güte- und Prüfbedingungen der Gütegemeinschaft Software [31], die sich auch auf den DXPS-Bereich übertragen lassen. Darüber hinaus können spezielle Entwicklungswerkzeuge, zum Beispiel zur Wissensakquisition oder zur Validierung der Wissensbasis, genutzt werden, um Fehler durch mangelnde Komplexitätsbeherrschung zu minimieren.

Betriebsfehler stehen in enger Verbindung mit dem Benutzer. Sie können durch mangelnde Information oder durch ein systemimmanentes Gefährdungspotential bedingt sein. Zu ihrer Vermeidung bieten sich eine ausführliche Dokumentation sowie Benutzerschulungen an. Bei DXPS mit hohem Gefährdungspotential kann eventuell ein Qualifikationsnachweis [32] des Benutzers sinnvoll sein.

Eine benutzerfreundliche Ausgestaltung der Erklärungskomponente kann die Transparenz des DXPS erhöhen um dem Benutzer damit Kontrollmöglichkeiten über die Aktivitäten des DXPS zu geben. Bislang wurden Erklärungskomponenten allerdings in der Mehrzahl nur in Form eines Traces über die letzten Folgerungen des XPS implementiert, die für einen Nichtexperten nur schwer nachzuvollziehen sind [33].

Fehlerhaften Eingaben kann durch die Gestaltung der Dialogkomponente vorgebeugt werden. Standardisierbare Eingaben können über Menüs, eventuell in Verbindung mit Mausbedienung erfolgen. Nichtstandardisierbare Eingaben legen Entwicklungen zum

natürlichsprachlichen Verstehen nahe. In diesem Zusammenhang ist auch auf das Stichwort Software-Ergonomie zu verweisen. So kann zum Beispiel eine visuelle Unterstützung des Benutzers durch die Verwendung von Grafikelementen und Fenstertechniken erfolgen.

Auch Akzeptanzprobleme können zu Betriebsfehlern führen [34]. Weitere Fehlermöglichkeiten ergeben sich durch eine Manipulation der Wissensbasis. Diesem Umstand könnte durch eine Trennung von Entwicklungs- und Benutzerumgebung Rechnung getragen werden [35]. Auf diese Weise wird dem Benutzer möglicherweise systembedingt der Zugang zur Wissensbasis verwehrt und dadurch deren Manipulation verhindert.

Ferner können Fehler aus allen Kategorien zum Zeitpunkt der DXPS-Erstellung zwar objektiv vorhanden, aber nicht erkennbar gewesen sein. Je nach Gefährdungspotential des DXPS bestehen daher Sorgfaltspflichten des Erstellers, das DXPS im Einsatz zu beobachten und neue Entwicklungen in Wissenschaft und Technik zu verfolgen, um eventuelle Schäden zu vermeiden, die aus den oben erwähnten Fehlern resultieren können.