EU-Produkthaftung für Software: Checkliste für Engineering-Evidenz
Die neue EU-Produkthaftungsrichtlinie behandelt Software, einschließlich KI-Systemen und als Service bereitgestellter Software, ausdrücklich als Produkt. Sie gilt für Produkte, die nach dem 9. 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 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.
Sinnvolle Service-Wege:
FAQ zur EU-Produkthaftung für Software
Erfasst die Richtlinie SaaS?
Wann gelten die neuen Regeln?
Ist freie Open-Source-Software ausgenommen?
Verhindert Dokumentation Haftung?
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
- EU-Kommission zu fehlerhaften Produkten. Offizieller Überblick