Fehlerhafte Software, verspätete Releases oder ungeklärte Zuständigkeiten können in IT-Projekten erhebliche wirtschaftliche Folgen haben. Unter dem Begriff Entwicklerhaftung werden Ansprüche und Verantwortlichkeiten zusammengefasst, die entstehen können, wenn Entwickler, Agenturen, IT-Dienstleister oder interne Entwicklungsteams vertragliche oder gesetzliche Pflichten verletzen. Gemeint ist jedoch kein einheitliches Sondergesetz, sondern ein Zusammenspiel aus Vertragsrecht, Gewährleistungsrecht, Schadensersatzrecht, Datenschutz, Urheberrecht und teilweise Produktsicherheits- oder Compliance-Fragen.
Für Auftraggeber stellt sich häufig die Frage, ob ein Programmierfehler bereits einen Mangel begründet und welche Schäden ersetzt verlangt werden können. Entwickler wiederum müssen wissen, wann sie nur eine fachgerechte Tätigkeit schulden und wann ein konkreter Erfolg vereinbart wurde. Entscheidend sind fast immer Vertragstyp, Leistungsbeschreibung, Abnahme, Dokumentation und die tatsächliche Projektkommunikation. Pauschale Aussagen sind daher riskant. Der Beitrag ordnet die Entwicklerhaftung rechtlich ein, zeigt typische Streitfälle und gibt praktische Hinweise für Beweise, Fristen und das weitere Vorgehen.
Inhaltsverzeichnis
- Was bedeutet Entwicklerhaftung im IT-Projekt?
- Gesetzliche Grundlagen: Vertrag, Pflichtverletzung und Verschulden
- Vertragsart entscheidet: Werkvertrag, Dienstvertrag oder digitales Produkt?
- Abgrenzung zu Betreiberhaftung, Produkthaftung und Arbeitnehmerhaftung
- Typische Praxisfälle: Wann Streit über Entwicklerleistungen entsteht
- Risiken, Haftung und typische Fehler
- Fristen, Gewährleistung und Verjährung
- Beweis und Dokumentation: Was im Streitfall zählt
- Handlungsschritte: Wie Betroffene strukturiert vorgehen
- Besondere Themen: Datenschutz, Open Source und IT-Sicherheit
- FAQ zur Entwicklerhaftung
- Fazit: Entwicklerhaftung rechtlich und technisch sauber prüfen
Was bedeutet Entwicklerhaftung im IT-Projekt?
Entwicklerhaftung beschreibt die rechtliche Verantwortlichkeit für Fehler, Pflichtverletzungen oder Schäden im Zusammenhang mit der Entwicklung, Anpassung, Wartung oder Integration von Software. Betroffen sein können einzelne Freelancer, Softwareagenturen, Systemhäuser, Plattformbetreiber, interne Entwickler oder Unternehmen, die Software als Bestandteil eines Produkts anbieten. Der Begriff ist praxisnah, aber gesetzlich nicht als eigener Haftungstatbestand geregelt.
Im Mittelpunkt steht regelmäßig die Frage, welche Pflicht konkret verletzt wurde. Ein bloßer Bug reicht nicht in jedem Fall aus. Software ist komplex, und nicht jede Abweichung führt automatisch zu Schadensersatz. Maßgeblich ist, ob eine vereinbarte Beschaffenheit, eine zugesagte Funktion, ein Sicherheitsstandard, ein Termin oder eine Nebenpflicht verletzt wurde. Auch die Frage, ob der Auftraggeber Anforderungen rechtzeitig und eindeutig formuliert hat, spielt eine erhebliche Rolle.
Die wichtigsten gesetzlichen Grundlagen finden sich im Bürgerlichen Gesetzbuch. Je nach Projekt können insbesondere Werkvertragsrecht, Dienstvertragsrecht, Kaufrecht, die Regelungen über digitale Produkte, allgemeines Leistungsstörungsrecht und deliktische Haftung relevant sein. Hinzu kommen Spezialthemen wie Datenschutz nach der DSGVO, Urheberrechte an Quellcode, Open-Source-Lizenzen, Geheimnisschutz, IT-Sicherheitsanforderungen und vertragliche Haftungsbegrenzungen.
Typisch ist ein abgestuftes Prüfprogramm: Zunächst wird ermittelt, was geschuldet war. Danach wird geprüft, ob die Leistung davon abweicht, ob eine Pflichtverletzung vorliegt, ob diese dem Entwickler zurechenbar ist und welcher Schaden kausal entstanden ist. Gerade Kausalität und Schadenshöhe sind in IT-Streitigkeiten häufig umstritten.
Gesetzliche Grundlagen: Vertrag, Pflichtverletzung und Verschulden
Die Entwicklerhaftung beginnt in den meisten Fällen beim Vertrag. Er legt fest, ob ein bestimmtes Arbeitsergebnis geschuldet ist, welche Funktionen umgesetzt werden müssen, welche Mitwirkungspflichten der Auftraggeber hat und welche Qualitätsmaßstäbe gelten. Fehlt eine klare Leistungsbeschreibung, wird später häufig darüber gestritten, ob eine Funktion überhaupt beauftragt war oder nur als Erwartung im Raum stand.
Bei einer Pflichtverletzung kommen unterschiedliche Anspruchsgrundlagen in Betracht. Im Werkvertragsrecht kann der Auftraggeber bei Mängeln zunächst Nacherfüllung verlangen. Unter weiteren Voraussetzungen können Selbstvornahme, Rücktritt, Minderung oder Schadensersatz hinzukommen. Im Dienstvertragsrecht stehen dagegen nicht klassische Mängelrechte im Vordergrund, sondern Schadensersatz wegen schuldhafter Pflichtverletzung, wenn der Dienstleister nicht fachgerecht gearbeitet hat.
Schadensersatz setzt grundsätzlich eine Pflichtverletzung, Vertretenmüssen, Kausalität und einen ersatzfähigen Schaden voraus. Vertretenmüssen bedeutet in der Praxis meist Vorsatz oder Fahrlässigkeit. Ein Entwickler haftet daher nicht schon deshalb, weil ein Projekt wirtschaftlich hinter den Erwartungen zurückbleibt. Er kann aber haften, wenn er anerkannte technische Standards missachtet, Sicherheitsrisiken ignoriert, vereinbarte Tests unterlässt oder trotz erkennbarer Probleme eine fehlerhafte Freigabe empfiehlt.
Daneben können vorvertragliche Pflichten relevant sein. Wer etwa bei der Angebotserstellung bestimmte Fähigkeiten, Kompatibilitäten oder Fertigstellungstermine zusichert, obwohl dafür keine belastbare Grundlage besteht, kann sich später nicht ohne Weiteres darauf berufen, es habe sich nur um eine unverbindliche Einschätzung gehandelt. Gleichwohl bleibt entscheidend, ob eine rechtsverbindliche Zusage nachweisbar ist.
Haftungsbeschränkungen in Verträgen oder AGB sind möglich, aber nicht beliebig. Eine Haftung für Vorsatz kann nicht im Voraus ausgeschlossen werden. Bei grober Fahrlässigkeit, Schäden an Leben, Körper oder Gesundheit sowie wesentlichen Vertragspflichten gelten enge Grenzen. Im unternehmerischen Verkehr bestehen größere Gestaltungsspielräume als gegenüber Verbrauchern, dennoch müssen Klauseln transparent und wirksam einbezogen sein.
Vertragsart entscheidet: Werkvertrag, Dienstvertrag oder digitales Produkt?
Eine der wichtigsten Weichenstellungen bei der Entwicklerhaftung ist die Einordnung des Vertrags. Viele IT-Projekte enthalten Mischformen: Beratung, Konzeption, Programmierung, Lizenzierung, Hosting, Wartung und Support werden in einem Paket angeboten. Rechtlich kann dennoch für einzelne Leistungsbestandteile unterschiedlich zu prüfen sein. Wird ein funktionsfähiges Modul mit definierten Eigenschaften versprochen, spricht vieles für werkvertragliche Elemente. Wird dagegen laufende Entwicklungsunterstützung ohne festen Erfolg erbracht, kann ein Dienstvertrag näherliegen.
Die folgende Gegenüberstellung zeigt typische Unterschiede. Sie ersetzt keine Prüfung des konkreten Vertrags, hilft aber, die Haftungsrisiken realistisch einzuordnen. Besonders wichtig sind Abnahme, Änderungswünsche, Mitwirkungspflichten und die Frage, ob die Leistung für Verbraucher oder Unternehmen erbracht wird.
| Einordnung | Typischer Inhalt | Relevanz für Haftung |
|---|---|---|
| Werkvertrag | Entwicklung einer Website, App oder Schnittstelle mit vereinbartem Funktionsumfang | Erfolg wird geschuldet; Mängelrechte und Abnahme sind zentral |
| Dienstvertrag | Agile Entwicklungsunterstützung, Beratung, laufende Mitarbeit im Team | Tätigkeit wird geschuldet; Haftung eher bei Verletzung fachlicher Sorgfalt |
| Kauf oder digitale Produkte | Standardsoftware, SaaS-Zugang, Apps oder digitale Inhalte | Gewährleistung, Aktualisierungspflichten und Verbraucherregeln können eingreifen |
| Wartung und Support | Updates, Fehlerbehebung, Monitoring, Service-Level | Haftung hängt von SLA, Reaktionszeiten und Priorisierung ab |
In der Praxis ist die Bezeichnung im Vertrag nicht allein entscheidend. Ein Dokument kann „Dienstleistungsvertrag“ heißen und dennoch werkvertragliche Pflichten enthalten, wenn ein konkreter Erfolg vereinbart ist. Umgekehrt führt ein agiles Projekt nicht automatisch zum Dienstvertrag, wenn ein klar definierter Release-Stand abnahmefähig geliefert werden soll.
Besonders streitanfällig sind Change Requests. Neue Anforderungen, geänderte Schnittstellen oder zusätzliche Sicherheitsvorgaben können den ursprünglichen Leistungsumfang verändern. Ohne geordnetes Änderungsmanagement entsteht später häufig die Frage, ob ein Problem ein Mangel oder eine unbezahlte Zusatzanforderung ist. Deshalb sollten Projektbeteiligte Änderungen dokumentieren, Aufwand und Auswirkungen festhalten und Freigaben nachvollziehbar archivieren.
Abgrenzung zu Betreiberhaftung, Produkthaftung und Arbeitnehmerhaftung
Entwicklerhaftung wird häufig mit anderen Haftungsbereichen vermischt. Das ist verständlich, führt aber zu falschen Erwartungen. Nicht jede Störung eines digitalen Angebots ist automatisch dem Entwickler zuzurechnen. Ebenso kann ein Betreiber für den Einsatz einer fehlerhaften Software verantwortlich sein, obwohl der technische Fehler ursprünglich von einem Dritten stammt.
Die Betreiberhaftung betrifft typischerweise Unternehmen, die eine Website, Plattform, App oder ein IT-System gegenüber Nutzern einsetzen. Sie müssen etwa Datenschutzpflichten, Informationspflichten, Sicherheitsmaßnahmen und vertragliche Pflichten gegenüber Kunden beachten. Wenn der Betreiber eine fehlerhafte Software nutzt, kann er gegenüber seinen Kunden haften und intern Rückgriff beim Entwickler prüfen. Ob dieser Rückgriff gelingt, hängt vom Entwicklungsvertrag und der Nachweisbarkeit des Fehlers ab.
Produkthaftung und Produzentenhaftung betreffen vor allem Schäden durch fehlerhafte Produkte. Bei rein wirtschaftlichen Schäden durch Softwaremängel ist das Produkthaftungsgesetz häufig nicht der passende Ausgangspunkt. Anders kann es aussehen, wenn Software Teil eines körperlichen Produkts ist, etwa bei Maschinensteuerungen, Medizintechnik, Fahrzeugkomponenten oder Smart-Home-Geräten. Dann können technische Fehler auch sicherheitsrechtliche und deliktische Fragen auslösen.
Bei angestellten Entwicklern ist zudem die Arbeitnehmerhaftung zu beachten. Arbeitnehmer haften gegenüber ihrem Arbeitgeber nicht in gleicher Weise wie externe Dienstleister. Bei betrieblich veranlasster Tätigkeit gelten abgestufte Haftungsprivilegien: leichte Fahrlässigkeit führt regelmäßig nicht zur persönlichen Haftung, mittlere Fahrlässigkeit kann geteilt werden, grobe Fahrlässigkeit oder Vorsatz können stärker belasten. Gegenüber Dritten bleibt die Situation gesondert zu prüfen.
Auch die Haftung von Geschäftsführern, Projektleitern oder IT-Sicherheitsbeauftragten ist abzugrenzen. Sie entwickeln möglicherweise nicht selbst, treffen aber organisatorische Entscheidungen. Werden Warnungen ignoriert, Sicherheitsbudgets ohne sachlichen Grund gestrichen oder Compliance-Anforderungen nicht umgesetzt, kann neben der Entwicklerhaftung eine Organisationshaftung des Unternehmens im Raum stehen.
Typische Praxisfälle: Wann Streit über Entwicklerleistungen entsteht
In Mandantengesprächen zeigt sich häufig, dass der Konflikt nicht erst beim Fehler beginnt, sondern bereits bei unklaren Erwartungen. Ein Auftraggeber erwartet eine skalierbare Plattform, während der Entwickler nur einen Prototyp kalkuliert hat. Eine Agentur liefert eine funktionierende Website, aber die Schnittstelle zum Warenwirtschaftssystem verarbeitet Bestellungen fehlerhaft. Ein Startup übernimmt Open-Source-Komponenten, ohne Lizenzpflichten zu prüfen. Solche Situationen können rechtlich sehr unterschiedlich bewertet werden.
Ein häufiger Fall ist die verspätete Fertigstellung. Ein Termin begründet nur dann klare Verzugsfolgen, wenn er verbindlich vereinbart wurde oder nach Mahnung fällig ist. In agilen Projekten sind Zeitpläne oft Planungsinstrumente, aber nicht ohne Weiteres fixe Leistungsfristen. Anders ist es, wenn ein Launch zu einer Messe, einer gesetzlichen Umstellung oder einem vertraglich fixierten Stichtag ausdrücklich zugesagt wurde.
Auch Sicherheitslücken führen zu Streit. Hat der Entwickler veraltete Bibliotheken eingesetzt, Eingaben nicht validiert oder bekannte Schutzmaßnahmen gegen typische Angriffe unterlassen, kann eine Pflichtverletzung naheliegen. Allerdings muss geprüft werden, welche Sicherheitsstandards vereinbart waren, ob der Auftraggeber Budget und Zeit für Security-Maßnahmen bereitgestellt hat und ob spätere Änderungen Dritter den Fehler verursacht haben.
Weitere typische Konstellationen sind Datenverluste bei Migrationen, fehlerhafte Zahlungsprozesse in Webshops, unzureichende Rechteübertragung am Quellcode, fehlende Dokumentation, mangelhafte Performance unter realer Last, unklare Verantwortlichkeiten beim Hosting oder Konflikte über Quellcode-Herausgabe nach Projektende.
Praxisbeispiel: Ein Unternehmen beauftragt eine Individualsoftware zur Angebotskalkulation. Nach dem Go-live stellt sich heraus, dass Rabatte in bestimmten Kombinationen falsch berechnet werden. Rechtlich ist zu prüfen, ob diese Kalkulationslogik spezifiziert war, ob Testfälle vorlagen, ob der Auftraggeber die Abnahme trotz erkennbarer Abweichungen erklärt hat und welcher Schaden tatsächlich aus den falschen Angeboten entstanden ist. Der Fehler allein beantwortet die Haftungsfrage noch nicht.
Risiken, Haftung und typische Fehler
Die wirtschaftlichen Risiken der Entwicklerhaftung reichen von Nachbesserungskosten über Nutzungsausfälle bis zu Datenverlusten, Vertragsstrafen, Rückabwicklung oder Reputationsschäden. Nicht jeder dieser Posten ist automatisch ersatzfähig. Erforderlich ist ein rechtlicher Zurechnungszusammenhang zwischen Pflichtverletzung und Schaden. Außerdem muss der Geschädigte den Schaden nachvollziehbar darlegen und darf eigene Schadensminderungspflichten nicht missachten.
Für Entwickler besteht ein besonderes Risiko, wenn sie ohne klare Spezifikation arbeiten, aber dennoch konkrete Ergebnisse zusagen. Auftraggeber gehen Risiken ein, wenn sie Anforderungen nur mündlich formulieren, Tests nicht dokumentieren oder Abnahmen leichtfertig erklären. Beide Seiten unterschätzen häufig die Bedeutung von Projektprotokollen, Ticketsystemen und Versionsständen.
Typische Fehler, die in Haftungsfällen regelmäßig relevant werden, sind:
- unklare oder veraltete Leistungsbeschreibungen ohne Priorisierung der Kernfunktionen,
- fehlende Regelungen zu Abnahme, Testverfahren, Change Requests und Mitwirkungspflichten,
- mündliche Zusagen zu Terminen, Budgets oder Funktionen ohne schriftliche Bestätigung,
- Produktivsetzung ohne belastbare Tests, Backup-Konzept oder Rollback-Plan,
- unvollständige Dokumentation von Sicherheitsentscheidungen und technischen Abhängigkeiten,
- unwirksame oder zu weit gefasste Haftungsbeschränkungen in AGB,
- fehlende Klärung von Nutzungsrechten an Quellcode, Designs, Datenbanken und Bibliotheken,
- keine Prüfung von Open-Source-Lizenzen, Datenschutzfolgen oder branchenspezifischen Vorgaben.
Haftungsbegrenzungen können sinnvoll sein, müssen aber sorgfältig formuliert werden. Eine pauschale Begrenzung auf den Auftragswert kann bei wesentlichen Vertragspflichten problematisch sein, wenn sie den Vertragspartner unangemessen benachteiligt. Andererseits kann eine transparente Begrenzung für leichte Fahrlässigkeit im B2B-Bereich zulässig sein, sofern Kardinalpflichten, Personenschäden und zwingende gesetzliche Haftung angemessen berücksichtigt werden.
Zu beachten ist außerdem das Mitverschulden. Wenn ein Auftraggeber erforderliche Testdaten nicht liefert, Freigaben verzögert, Sicherheitsupdates ablehnt oder Warnhinweise ignoriert, kann dies Ansprüche mindern oder ausschließen. Umgekehrt kann sich ein Entwickler nicht darauf verlassen, dass der Auftraggeber jeden technischen Fehler erkennt. Fachliche Warn- und Hinweispflichten bleiben bestehen, wenn Risiken für einen professionellen Entwickler erkennbar sind.
Fristen, Gewährleistung und Verjährung
Fristen sind in IT-Projekten oft entscheidend, werden aber uneinheitlich behandelt. Zunächst ist zwischen Projektfristen, Mängelrüge, Nacherfüllungsfrist und Verjährung zu unterscheiden. Eine Projektfrist bestimmt, wann geliefert werden soll. Eine Nacherfüllungsfrist gibt dem Entwickler Gelegenheit, einen gerügten Mangel zu beheben. Die Verjährung legt fest, wie lange Ansprüche gerichtlich durchsetzbar bleiben.
Im Werkvertragsrecht spielt die Abnahme eine zentrale Rolle. Mit der Abnahme bestätigt der Auftraggeber grundsätzlich, dass die Leistung im Wesentlichen vertragsgemäß ist. Erkannte Mängel sollten bei der Abnahme ausdrücklich vorbehalten werden, weil sonst Rechte verloren gehen können. Die Abnahme kann ausdrücklich, durch schlüssiges Verhalten oder unter bestimmten Voraussetzungen auch fiktiv erfolgen. Gerade bei produktiver Nutzung einer Software ist daher Vorsicht geboten.
Die Verjährungsfristen hängen von der rechtlichen Einordnung ab. Für allgemeine Schadensersatzansprüche gilt regelmäßig die dreijährige Verjährungsfrist, beginnend mit dem Schluss des Jahres, in dem Anspruch und Kenntnis der maßgeblichen Umstände vorliegen. Bei Mängelrechten können je nach Vertrag andere Fristen gelten. Bei werkvertraglichen IT-Leistungen, Standardsoftware, digitalen Produkten oder Wartungsverträgen muss jeweils gesondert geprüft werden, welche Regelung einschlägig ist und ab welchem Zeitpunkt die Frist läuft.
Bei Verträgen zwischen Kaufleuten kann zusätzlich eine Untersuchungs- und Rügeobliegenheit relevant werden, insbesondere wenn kaufrechtliche Elemente überwiegen. Wer offensichtliche Mängel nicht zeitnah rügt, riskiert Rechtsnachteile. Für Verbraucher gelten dagegen zwingende Schutzvorschriften, insbesondere bei digitalen Produkten und Aktualisierungspflichten. Verkürzungen von Gewährleistungsrechten sind dort nur eingeschränkt möglich.
Praktisch empfiehlt sich, Mängel nicht nur allgemein zu beanstanden, sondern konkret zu beschreiben: betroffene Funktion, Umgebung, Zeitpunkt, Fehlermeldung, erwartetes Verhalten, tatsächliches Verhalten und wirtschaftliche Auswirkung. Wird eine Frist zur Nacherfüllung gesetzt, sollte sie angemessen sein. Was angemessen ist, hängt von Dringlichkeit, Komplexität, Sicherheitsrelevanz und bisherigen Nachbesserungsversuchen ab.
Beweis und Dokumentation: Was im Streitfall zählt
In Streitigkeiten über Entwicklerhaftung entscheidet häufig nicht allein die technische Wahrheit, sondern deren Nachweisbarkeit. Ein Fehler muss nachvollziehbar beschrieben, reproduzierbar oder zumindest plausibel dokumentiert und dem Verantwortungsbereich des Entwicklers zugeordnet werden. Ebenso wichtig ist der Nachweis, welche Anforderungen vereinbart waren und ob der Auftraggeber seinen Mitwirkungspflichten nachgekommen ist.
Technische Beweise sollten möglichst früh gesichert werden. Nachträgliche Änderungen am System, Updates oder manuelle Reparaturen können Spuren verwischen. Das bedeutet nicht, dass ein produktives System aus Beweisgründen stillstehen muss. Es sollte aber dokumentiert werden, welche Sicherungen erstellt, welche Logs exportiert und welche Änderungen wann vorgenommen wurden. Bei größeren Schäden kann ein unabhängiges technisches Gutachten sinnvoll sein.
Wichtige Nachweise sind insbesondere:
- Vertrag, Angebot, Leistungsbeschreibung, Pflichtenheft, User Stories und Akzeptanzkriterien,
- Projektpläne, Sprint-Protokolle, Tickets, Change Requests und Freigaben,
- E-Mails, Chat-Verläufe, Meetingnotizen und Entscheidungsdokumentationen,
- Quellcode-Stände, Commit-Historie, Release Notes und Deployment-Protokolle,
- Testprotokolle, Bugreports, Screenshots, Logdateien und Monitoring-Daten,
- Abnahmeerklärungen, Mängelvorbehalte und Fristsetzungen,
- Nachweise zu Schäden wie Rechnungen, Umsatzausfälle, Vertragsstrafen oder Mehrkosten,
- Backups, Datenbankstände und Dokumentation von Wiederherstellungsmaßnahmen.
Auch Entwickler sollten dokumentieren, wenn Anforderungen fehlen, Risiken angezeigt oder Entscheidungen des Auftraggebers technisch problematisch sind. Eine sachliche Warnung per E-Mail kann später erheblich sein. Auftraggeber sollten wiederum Mängelrügen strukturiert formulieren und nicht nur pauschal erklären, die Software funktioniere nicht. Je präziser die Dokumentation, desto eher lässt sich eine außergerichtliche Lösung finden.
Handlungsschritte: Wie Betroffene strukturiert vorgehen
Wenn ein IT-Projekt scheitert oder ein erheblicher Softwarefehler auftritt, ist ein geordnetes Vorgehen wichtiger als schnelle Schuldzuweisungen. Unkoordinierte Nachbesserungen, vorschnelle Kündigungen oder unklare Fristsetzungen können die eigene Position schwächen. Sinnvoll ist zunächst eine rechtliche und technische Bestandsaufnahme. Dabei sollten wirtschaftliche Risiken begrenzt, Beweise gesichert und Kommunikationswege geordnet werden.
Für Auftraggeber und Entwickler sind folgende Schritte in vielen Fällen zweckmäßig:
- Vertrag und Leistungsumfang prüfen: Klären Sie, welche Funktionen, Termine, Service-Level, Sicherheitsanforderungen und Mitwirkungspflichten tatsächlich vereinbart wurden.
- Fehler technisch eingrenzen: Erfassen Sie betroffene Module, Nutzergruppen, Systemumgebung, Zeitpunkt, Wiederholbarkeit und mögliche Fremdeinflüsse.
- Beweise sofort sichern: Exportieren Sie Logs, Screenshots, Tickets, Datenbankstände und relevante Kommunikation, bevor Updates oder Reparaturen Spuren verändern.
- Mängel präzise rügen: Beschreiben Sie Soll-Zustand, Ist-Zustand und Auswirkungen. Pauschale Vorwürfe erschweren die rechtliche Bewertung.
- Angemessene Fristen setzen: Wenn Nacherfüllung verlangt wird, sollte die Frist nach Dringlichkeit und Komplexität bemessen und nachweisbar zugestellt werden.
- Schadensminderung beachten: Prüfen Sie Übergangslösungen, Backups, manuelle Kontrollen oder temporäre Abschaltungen, wenn dadurch größere Schäden vermieden werden.
- Change Requests trennen: Unterscheiden Sie echte Mängelbeseitigung von neuen Anforderungen, damit Kosten und Verantwortlichkeiten nicht vermischt werden.
- Abnahme und Vorbehalte kontrollieren: Prüfen Sie, ob eine Abnahme bereits erklärt wurde und ob bekannte Mängel vorbehalten wurden.
- Verjährung und Ausschlussfristen notieren: Halten Sie relevante Daten wie Lieferung, Abnahme, Kenntnis des Mangels, Rüge und Fristablauf kalendarisch fest.
- Technische und rechtliche Bewertung verbinden: Bei erheblichen Schäden sollte ein technischer Befund mit einer rechtlichen Anspruchsprüfung abgestimmt werden.
Entwickler sollten auf Mängelrügen nicht rein defensiv reagieren. Sinnvoll ist eine strukturierte Rückmeldung: Welche Punkte sind nachvollziehbar, welche Informationen fehlen, welche Maßnahmen werden vorgeschlagen und welche Leistungen gelten als Zusatzaufwand? Auftraggeber sollten eine Eskalation vermeiden, solange eine realistische Nachbesserung möglich ist und keine dringenden Sicherheits- oder Compliance-Gründe entgegenstehen.
Kommt keine Lösung zustande, können außergerichtliche Vergleichsverhandlungen, Mediation, Schiedsgutachten oder ein gerichtliches Verfahren in Betracht kommen. Welcher Weg sachgerecht ist, hängt von Schadenshöhe, Projektbeziehung, Beweislage und technischer Komplexität ab.
Besondere Themen: Datenschutz, Open Source und IT-Sicherheit
Die Entwicklerhaftung endet nicht beim klassischen Funktionsmangel. Moderne Softwareprojekte berühren regelmäßig Datenschutz, Lizenzrecht und IT-Sicherheit. Diese Bereiche können eigene Pflichten begründen und die Haftungsfolgen erheblich beeinflussen. Ein Projekt kann technisch funktionieren und dennoch rechtlich mangelhaft sein, wenn etwa personenbezogene Daten ohne ausreichende Rechtsgrundlage verarbeitet oder erforderliche Löschkonzepte nicht umgesetzt werden.
Beim Datenschutz stellt sich häufig die Frage, wer Verantwortlicher und wer Auftragsverarbeiter ist. Entwickler, die nur nach Weisung personenbezogene Daten im Kundensystem verarbeiten, benötigen regelmäßig einen Auftragsverarbeitungsvertrag. Entwickeln sie hingegen eigene Analyse- oder Trackingfunktionen mit Entscheidungsbefugnis, kann eine weitergehende Verantwortlichkeit entstehen. Schadensersatzansprüche nach Art. 82 DSGVO setzen einen Datenschutzverstoß und einen kausal verursachten Schaden voraus; auch hier bleibt der Einzelfall maßgeblich.
Open-Source-Komponenten sind wirtschaftlich sinnvoll, können aber Lizenzpflichten auslösen. Je nach Lizenz können Hinweise, Quellcodebereitstellung oder Weitergabebedingungen erforderlich sein. Wird dies nicht geprüft, drohen Unterlassungsansprüche, Nachlizenzierungen oder Konflikte mit Investoren und Kunden. Entwickler sollten daher dokumentieren, welche Komponenten verwendet werden und welche Lizenzbedingungen gelten.
IT-Sicherheit betrifft sowohl technische Standards als auch vertragliche Erwartungen. Werden allgemein bekannte Schutzmaßnahmen unterlassen, kann dies als Fahrlässigkeit bewertet werden. Gleichzeitig muss der Auftraggeber entscheiden, welches Sicherheitsniveau beauftragt und finanziert wird. Bei regulierten Branchen, kritischen Prozessen oder sensiblen Daten steigen die Anforderungen. Security-by-Design, Code Reviews, Penetrationstests und Updateprozesse sollten nicht nur technisch umgesetzt, sondern vertraglich eingeordnet werden.
FAQ zur Entwicklerhaftung
Haftet ein Softwareentwickler für jeden Fehler im Programm?▾
Nein. Softwarefehler begründen nicht automatisch eine Haftung. Entscheidend ist, ob der Fehler eine vertraglich vereinbarte Beschaffenheit verletzt, gegen fachliche Standards verstößt oder auf einer schuldhaften Pflichtverletzung beruht. Bei Individualsoftware kommt es stark auf Leistungsbeschreibung, Abnahme und vereinbarte Tests an. Bei laufender Entwicklungsunterstützung kann ein Dienstvertrag vorliegen, bei dem kein bestimmter Erfolg geschuldet ist. Auftraggeber sollten den Fehler konkret dokumentieren und prüfen, ob er im vereinbarten Leistungsumfang liegt.
Kann ein Auftraggeber Schadensersatz verlangen, wenn die Software verspätet fertig wird?▾
Grundsätzlich ja, aber nicht bei jeder Verzögerung. Erforderlich ist regelmäßig, dass eine fällige Leistung nicht rechtzeitig erbracht wurde, der Entwickler die Verzögerung zu vertreten hat und ein nachweisbarer Schaden entstanden ist. Häufig muss zuvor gemahnt oder eine angemessene Frist gesetzt werden, sofern kein verbindlicher Fixtermin vereinbart wurde. Praktisch sollten Auftraggeber Terminabsprachen, Warnhinweise, Mitwirkungsverzögerungen und wirtschaftliche Folgen dokumentieren, bevor sie Schadensersatz beziffern.
Wer haftet bei Sicherheitslücken oder Datenschutzverstößen in einer App?▾
Das hängt von Rollen, Vertrag und Ursache ab. Der App-Betreiber bleibt gegenüber Nutzern und Behörden häufig verantwortlich, kann aber intern Ansprüche gegen den Entwickler prüfen. Eine Entwicklerhaftung kommt in Betracht, wenn vereinbarte Sicherheitsanforderungen missachtet, bekannte Standards verletzt oder Datenschutzvorgaben fehlerhaft umgesetzt wurden. Betroffene sollten Logs sichern, die Schwachstelle technisch beschreiben, Datenflüsse dokumentieren und prüfen, ob Meldepflichten gegenüber Aufsichtsbehörden oder Betroffenen bestehen. Vorschnelle Änderungen ohne Beweissicherung können spätere Rückgriffsansprüche erschweren.
Was sollte ein Entwickler tun, wenn der Kunde unbegründete Mängel rügt?▾
Ein Entwickler sollte die Rüge nicht ignorieren, sondern strukturiert beantworten. Sinnvoll ist eine schriftliche Bitte um genaue Fehlerbeschreibung, Systemumgebung, Reproduktionsschritte, Screenshots und betroffene Daten. Danach sollte geprüft werden, ob der Punkt im Leistungsumfang liegt oder ein Change Request ist. Eigene Prüfungen, Testergebnisse und Hinweise auf fehlende Mitwirkung sollten dokumentiert werden. Bleibt die Rüge unbegründet, kann eine sachliche Zurückweisung mit technischer Begründung helfen, Eskalationen zu vermeiden.
Wann verjähren Ansprüche aus Entwicklerhaftung?▾
Die Verjährung hängt von Vertragstyp und Anspruch ab. Allgemeine Schadensersatzansprüche verjähren häufig in drei Jahren ab dem Schluss des Jahres, in dem Anspruch und Kenntnis der wesentlichen Umstände vorliegen. Bei Mängelrechten können andere Fristen und Startpunkte gelten, insbesondere ab Abnahme oder Lieferung. Verbraucherregeln für digitale Produkte, kaufmännische Rügepflichten und vertragliche Vereinbarungen können zusätzlich relevant sein. Betroffene sollten daher Lieferdatum, Abnahme, Mängelkenntnis, Rüge und gesetzte Fristen frühzeitig kalendarisch erfassen.
Fazit: Entwicklerhaftung rechtlich und technisch sauber prüfen
Entwicklerhaftung ist selten eine einfache Frage von „Fehler gleich Haftung“. Entscheidend sind Vertragsart, Leistungsumfang, Abnahme, Verschulden, Kausalität, Schaden und Beweisbarkeit. Auftraggeber sollten Mängel präzise dokumentieren, angemessene Fristen setzen und Verjährungsfragen frühzeitig klären. Entwickler sollten Anforderungen, Hinweise, Freigaben und technische Entscheidungen nachvollziehbar festhalten.
In der Priorität stehen zunächst Beweissicherung, Schadensbegrenzung und eine nüchterne Prüfung der vertraglichen Pflichten. Danach lässt sich entscheiden, ob Nachbesserung, Kostenbeteiligung, Rückabwicklung, Schadensersatz oder eine außergerichtliche Lösung realistisch ist. Wegen der vielen Mischformen im IT-Vertragsrecht hängt die Bewertung stark vom Einzelfall ab. Eine belastbare Einschätzung setzt regelmäßig voraus, Vertrag, Projektkommunikation, technische Befunde und wirtschaftliche Auswirkungen gemeinsam zu betrachten.