EU-Produkthaftung für Software: Checkliste für Engineering-Evidenz

9 Min Lesezeit · 24. August 2026
Zuletzt geprüft 11. November 2026

Die neue EU-Produkthaftungsrichtlinie behandelt Software, einschließlich KI-Systemen und als Service bereitgestellter Software, ausdrücklich als Produkt. Nach dem Korrigendum vom Mai 2026 gilt sie für Produkte, die nach dem 8. Dezember 2026 in Verkehr gebracht oder in Betrieb genommen werden. Teams sollten Nachweise zu Nutzung, Fehlgebrauch, Security, Tests, Releases, Incidents und Updates bewahren.

Haftung wird rechtlich beurteilt. Nutzt für Einzelfälle Rechtsberatung. Engineering sorgt dafür, dass die Produkthistorie erklärbar und auffindbar bleibt.

Was ändert sich für Softwareteams?

Bereich	Signal der Richtlinie	Zu bewahrende Evidenz
Produktscope	Software ist ausdrücklich erfasst	Version, Anbieter, Deployment und Markt
Fehlerbewertung	Sicherheit umfasst Cybersecurity und Updates	Threat Models, Tests, Advisories und Update-Entscheidungen
Offenlegung	Gerichte können relevante Belege anordnen	Durchsuchbare, verhältnismäßige Records

Was bereitet Österreich für Dezember 2026 vor?

Der Entwurf für das PHG 2026 ist am 23. Oktober eingelangt. Die Begutachtung läuft bis 12. November 2026. Der Entwurf sieht den 9. Dezember als Inkrafttreten vor und erfasst Produkte, die nach dem 8. Dezember in Verkehr gebracht oder in Betrieb genommen werden. Prüft die endgültige Umsetzung im jeweils betroffenen Markt.

Paragraf 6 des Entwurfs sieht eine erforderliche und verhältnismäßige Offenlegung vor. Das Gericht kann eine leicht zugängliche und verständliche Form verlangen. Der Entwurf regelt auch den Schutz von Geschäftsgeheimnissen. Erprobt mit der Rechtsberatung eine lesbare Release-Historie und einen begrenzten Export. Bewahrt die geschützten Originale auf und dokumentiert die Ableitung.

Was gehört in die Evidenzkette?

Verknüpft sicherheitsrelevante Anforderung, Implementierung, Verifikation, Release, Telemetrie und Korrektur. Die Belege zeigen, was das Team wusste, entschied, freigab und kommunizierte.

Datierte Annahmen zu Zweck, Nutzern, Umgebung und Fehlgebrauch.
Architekturentscheidungen, Threat Models, Hazard-Analyse, Rechte und Dependencies.
Reproduzierbare Tests, Reviews, Limits, Restrisiken und Freigaben.
Incidents, Tickets, Updates, Rollout, Hinweise und Supportende.

Wie viel Evidenz ist genug?

Mehr Logs sind nicht automatisch besser. Bewahrt entscheidungsfähige Evidenz mit Herkunft, Zugriff, Retention und Bezug zur ausgelieferten Version. Ein Data Lake aus Screenshots und veränderlichen Dashboards ist schwach und datenschutzriskant.

Immutable Build-IDs mit Source, Artifact, Dependencies, Config und Tests verknüpfen.
Begründung und Freigabe für Test-Waiver dokumentieren.
Eine Release-Rekonstruktion ohne Stammeswissen testen.

Welche Praxis senkt das Risiko?

Behandelt Wartung als Teil der Produktsicherheit: Fehler und Schwachstellen überwachen, betroffene Versionen bestimmen, Updates ausrollen, Adoption prüfen und Restrisiken kommunizieren.

Security- und Safety-Ownership über den Supportzeitraum festlegen.
Rollback-, Disable-, Kommunikations- und Preservation-Runbooks pflegen.
Dieselben Kontrollen auf relevante Modell-, Prompt-, Policy- und Datenänderungen anwenden.

30 Tage bis zur Evidenzbereitschaft

Relevante Produkte, Deployments, Akteure und Releases erfassen.
Für ein Release die Kette bis Produktion rekonstruieren.
Lücken in Provenance, Tests, Freigaben, Incidents und Updates schließen.
Retention, Legal Hold, Privacy und Export mit Legal definieren.
Evidenz in CI/CD und Betrieb automatisch erfassen.
Mock-Anfrage durchführen und personenabhängige Antworten beseitigen.

Produkt bauen, nicht nur Backlog

Wenn dieser Artikel auf eine echte Produktentscheidung einzahlt, hilft Wavect dir beim Scoping, Bauen, Härten oder Führen der Softwarearbeit mit Senior-Founder-Urteil.

Produkt besprechen

Sinnvolle Service-Wege:

Software-QA

FAQ zur EU-Produkthaftung für Software

Ist das österreichische PHG 2026 schon beschlossen?

Bei der Prüfung am 11. November führte das Parlament es als Ministerialentwurf in Begutachtung. Prüft den Verfahrensstand für den beschlossenen Text und den Zeitpunkt des Inkrafttretens.

Erfasst die Richtlinie SaaS?

Die Produktdefinition umfasst Software. Die Erwägungsgründe nennen auch über Cloud-Dienste bereitgestellte Software wie SaaS.

Wann gelten die neuen Regeln?

Nach dem Korrigendum vom Mai 2026 gilt die Richtlinie für Produkte, die nach dem 8. Dezember 2026 in Verkehr gebracht oder in Betrieb genommen werden.

Ist freie Open-Source-Software ausgenommen?

Außerhalb kommerzieller Tätigkeit entwickelte oder gelieferte Software ist ausgenommen. Das konkrete Vertriebsmodell sollte rechtlich geprüft werden.

Verhindert Dokumentation Haftung?

Nein. Evidenz macht kein unsicheres Produkt sicher. Sie unterstützt diszipliniertes Engineering und eine korrekte Rekonstruktion.

Fazit

Die Antwort ist kein Legal-Memo neben dem Repository, sondern eine versionierte Evidenzkette aus normalem Delivery- und Wartungsbetrieb.

Primärquellen

Richtlinie (EU) 2024/2853. Offizieller Text
Korrigendum vom Mai 2026. Offizielle Korrektur des Stichtags auf nach dem 8. Dezember 2026
EU-Kommission zu fehlerhaften Produkten. Offizieller Überblick
Verfahrensstand im österreichischen Parlament. Begutachtung und parlamentarischer Status des PHG 2026
Gesetzestext des PHG-2026-Entwurfs. Vorgeschlagene Offenlegung, Schutz von Geschäftsgeheimnissen und Inkrafttreten