Strategische Gestaltung von Softwareverträgen – Ein anwaltlicher Deep-Dive für Inhouse-Juristen und Projektleiter

Zusammenfassung

Generative KI verändert die Softwareentwicklung grundlegend und erfordert neue Vertragsregelungen zu KI-Einsatz, Urheberschaft, Freistellung und Compliance.
Die Wahl des richtigen Vertragstyps (Werk-, Kauf- oder Dienstvertrag) und der passenden Projektmethode (Wasserfall oder Agile) entscheidet über die Risikoverteilung im Projekt.
Kommerzielle Modelle wie Time & Material, agiler Festpreis, Caps und Bonus-Malus-Systeme schützen das Budget; Mitwirkungspflichten und AÜG-Risiken sind präzise zu regeln.
Abnahme, Mängelklassen, Verjährung und Kündigungsfolgen müssen vertraglich eindeutig festgelegt werden, da die gesetzlichen Auffangregeln für IT-Projekte häufig unpassend sind.

1. Markttrends 2026: Die KI-Revolution und das Ende klassischer IT-Verträge

Generative KI hat die Softwareentwicklung fundamental verändert. IT-Dienstleister nutzen heute KI-Tools wie GitHub Copilot für Code-Generierung und Testing. Dies erfordert ein Umdenken in der Vertragsgestaltung:

Von manueller Codierung zu KI-Generierung: Die Effizienzgewinne sind erheblich, doch klassische Aufwandsabrechnungen (Time & Material) vergüten paradoxerweise Ineffizienz. Der Trend führt zu ergebnisorientierten Verträgen.
Das juristische Minenfeld (Urheberschaft von KI-Code): Rein KI-generierter Code genießt mangels menschlicher Schöpfungshöhe keinen Urheberschutz. Moderne Verträge müssen KI-Einsatz, Freistellungsklauseln und menschliche Endkontrolle ("Human-in-the-Loop") regeln.
Die neue Kostenfalle (Daten & Compliance): Während Programmierung durch KI günstiger wird, entstehen neue Kosten: Datenaufbereitung, Data Mapping, Feintuning auf Unternehmenskontext und Einhaltung des EU AI Act.

2. Die Gretchenfrage: Welchen Vertragstyp brauchen wir?

2.1 Der Werkvertrag (§ 631 BGB) – Ihr sicherer Hafen

Ein konkreter Erfolg ist geschuldet. Der Anbieter trägt Projektverantwortung; Zahlung erfolgt erst bei vertragsgemäßer Funktion. Der BGH ordnet die Entwicklung von Individualsoftware regelmäßig als Werkvertrag ein.

2.2 Abgrenzung zum Kaufrecht (§ 650 BGB Werklieferungsvertrag)

Anbieter drängen ihre Leistung oft ins Kaufrecht, da hier die werkvertragliche "Abnahme" entfällt. Das Kaufrecht gilt aber streng genommen nur für fertige "Ware von der Stange".

Sobald geistige Planungsleistungen, Konzeptionen oder tiefgreifende Anpassungen dominieren – typisch bei Softwareimplementierungen – überwiegen werkvertragliche Elemente.

2.3 Der Dienstvertrag (§ 611 BGB)

Hier schuldet der Anbieter keinen Erfolg, sondern nur qualifiziertes "Bemühen". Sie tragen das Scheiterrisiko vollumfänglich selbst. Dies liegt vor, wenn:

Die Parteien den Erfolg bewusst offenlassen (etwa bei T&M-Abrechnung)
Das Zielbild so unzureichend definiert ist, dass sich kein einklagbarer Erfolg ermitteln lässt

3. Methodik: Wasserfall oder Agile? (Die Stacey-Matrix)

Die Komplexität eines Projekts bestimmt die vertragliche Methode. Die Stacey-Matrix misst zwei Faktoren: die Bekanntheit der Anforderungen und die Bekanntheit der Umsetzung.

3.1 Einfache Projekte (Klassisch / Wasserfall)

Bei klarer Anforderung und klarem Umsetzungsweg eignen sich sequenzielle Methoden (Konzeption → Planung → Programmierung → Test). Basis ist das klassische Pflichtenheft.

Nachteil: Änderungen (Change Requests) sind schwerfällig. Bei jahrelanger Entwicklung ist die Software zum Go-Live oft veraltet.

3.2 Komplexe Projekte (Agil / Scrum)

Bei unklar definierten oder sich wandelnden Anforderungen und Umsetzungswegen scheitert der Wasserfall. Agile Methoden wie Scrum (von über 80 % der agilen Anwender genutzt) setzen auf Iteration und kurze Zyklen statt starrer Pflichtenhefte.

Die Scrum-Rollen im Vertrag:

Product Owner (Ihre Rolle): Verantwortlich für die Produktwertmaximierung, pflegt das Product Backlog (dynamische Anforderungsliste)
Scrum Master: Der "Trainer", räumt Hindernisse aus dem Weg
Developer: Die "Spieler", entscheiden autark über die Sprint-Aufgaben
Events & Artefakte: Daily Scrums (max. 15 Min.), Sprints (max. 1 Monat), funktionierendes Inkrement beim Sprint Review

Warnung: Sobald Sie den offiziellen Scrum Guide verlassen, müssen Sie exakt regeln, wer für Abweichungen haftet.

4. Was muss der Anbieter liefern? (Primärleistungspflichten)

4.1 Konzeption & Prüfpflichten

Der Anbieter als IT-Experte muss Ihre Vorgaben auf Sinnhaftigkeit, Vollständigkeit und technische Machbarkeit prüfen. Enthält das Pflichtenheft Widersprüche oder Fehler, trifft den Anbieter eine Prüf- und Hinweispflicht.

4.2 Nicht-funktionale Anforderungen (nfA)

Diese werden oft vernachlässigt, kosten aber massiv Arbeitszeit. Regeln Sie explizit:

Performance
Skalierbarkeit
Stabilität
IT-Sicherheit (z. B. BSI-Grundschutz, Penetrationstests)
Aufwärtskompatibilität (Updatefähigkeit)

Tipp: Vereinbaren Sie für nfA-Verletzungen gesonderte Vertragsstrafen, da sich Schäden schwer beziffern lassen.

4.3 Dokumentation

Fordern Sie nicht pauschal "eine Dokumentation". Regeln Sie die Details:

Anwenderdokumentation (Frontend)
Administrations-/Konfigurationsdokumentation (Customizing-Guide)
Testdokumentation (z. B. nach IEEE 829)
Quellcodedokumentation (sofern vereinbart)

Achtung: Dokumentationen sind rechtlich meist erst bei Projektabschluss fällig. Bei vorzeitigem Abbruch stehen Sie oft mit leeren Händen da.

4.4 Quellcode & Escrow

Das Urheberrecht hilft nicht weiter; es erlaubt nur die Fehlerberichtigung, nicht die Weiterentwicklung. Nach BGH-Entscheidung ist Code oft durch Auslegung geschuldet, wenn Sie die Software selbst pflegen sollen.

Praxis-Tipp: Regeln Sie die Herausgabe explizit. Verweigert der Anbieter dies, vereinbaren Sie ein Escrow: Der Code wird bei einem Dritten hinterlegt (z. B. für den Insolvenzfall). Nutzen Sie professionelle Escrow-Agenturen, da Notare Code technisch nicht prüfen können.

5. Kommerzielle Gestaltung: So schützen Sie Ihr Budget

5.1 Time & Material (T&M)

Die Abrechnung nach Aufwand verlagert das finanzielle Risiko auf Sie. Sie brauchen:

Granulare Timesheets und klare Zeiterfassungsintervalle
Caps (Obergrenzen)
Bonus-Malus-Systeme: Bleibt der Anbieter unter Budget, bekommt er einen Bonus (z. B. 50 % der Ersparnis); überschreitet er es, sinkt sein Tagessatz

5.2 Der agile Festpreis

Sie kennen den exakten Scope nicht. Ein starrer Festpreis ist unseriös. Die Lösung:

Definieren Sie exemplarische Referenzeinheiten (z. B. Referenz-User-Stories unterschiedlicher Komplexität)
Weisen Sie diesen Punktwerte zu (oft nach Fibonacci-Folge: 1, 2, 3, 5, 8, 13)
Hinterlegen Sie diesen Punkten einen festen Preis

Ihr Vorteil: Schätzungen werden objektivierbar. Ein Gutachter kann prüfen, ob ein Feature wirklich eine "13" ist oder nur eine "5".

5.3 Inflationsschutz & Benchmarking

Verlassen Sie sich nicht auf allgemeine Verbraucherpreisindizes. Verweisen Sie auf branchenspezifische Indizes (wie den DL-IT-03 für Softwareentwicklung). Nutzen Sie ein Benchmarking-Recht: Liegen die Preise weit über Marktniveau, kann durch einen Gutachter eine Preisanpassung erzwungen werden.

5.4 Zahlungsfristen

Im Werkvertrag darf die Zahlungsfrist gem. § 271a Abs. 3 BGB maximal 30 Tage nach Gegenleistungsempfang (Abnahme) betragen. Längere Fristen (bis 60 Tage) bedürfen einer ausdrücklichen, nicht grob unbilligen Vereinbarung.

6. Ihre Hausaufgaben: Mitwirkungen und Beistellungen

6.1 Gesetzliche Lage (§ 642 BGB)

Stellen Sie Daten, Testumgebungen oder Personal nicht rechtzeitig bereit, ist das gesetzlich meist eine Obliegenheit, keine einklagbare Pflicht. Der Anbieter kann nur eine angemessene Entschädigung (Personalstillstand zu Selbstkosten) verlangen, keinen entgangenen Gewinn oder Schadensersatz.

6.2 Vertragliche Steuerung

Anbieter versuchen oft, Mitwirkungen zur echten vertraglichen Hauptpflicht zu erheben, was eine volle Schadensersatzhaftung (§ 280 BGB) auslöst. Wehren Sie sich. Regeln Sie stattdessen den Umfang genau:

Sollen die Mitwirkungen abschließend sein?
Wie viel Vorlauf muss der Anbieter Ihnen für die Ressourcenabnahme geben?

Eine pauschale Pflicht zu allem "Erforderlichen" ist ein Freifahrtschein.

7. Personal & Compliance: Die AÜG-Falle

Ein massives und unterschätztes Risiko bei agilen Projekten (externe Entwickler sitzen eng mit Ihren Mitarbeitern im Scrum-Team) ist die verdeckte Arbeitnehmerüberlassung nach dem AÜG.

7.1 Das Risiko (§ 1 AÜG)

Wenn externe Entwickler in Ihre Arbeitsorganisation eingegliedert sind und Ihren Weisungen unterliegen, greift das AÜG. Es drohen: Bußgelder, Nachzahlungen von Sozialabgaben und die Fiktion eines Arbeitsverhältnisses zu Ihnen.

7.2 Schutzmaßnahmen

Eine Klausel "Dies ist keine Arbeitnehmerüberlassung" reicht nicht; die tatsächliche Vertragsumsetzung zählt.

Weisungsrecht: Nur Vorgaben zum Zielbild (Inhalt) machen, nicht zu Arbeitszeit, Urlaub oder Ort
Organisation: Strikt getrennte Arbeitssphären. Externe buchen Reisen selbst, nutzen eigenes IT-Equipment, sitzen in getrennten Büros und werden im E-Mail-Verkehr gekennzeichnet (z. B. max.mustermann[EXT]@unternehmen.de)

8. Abnahme und Gewährleistung: Wenn es ernst wird

Die Abnahme (§ 640 BGB) ist der Rubikon des Werkvertrags. Mit ihr wird die Restvergütung fällig, die Beweislast für Mängel geht auf Sie über, die Gefahr geht über, und die Verjährung beginnt.

8.1 Freigaben vs. Abnahme

Vorsicht: "Teilfreigaben" im Projekt stellen keine rechtliche Abnahme nach BGB dar.

8.2 Go-Live und Probebetrieb

Findet ein Probebetrieb vor Go-Live statt, ist das unproblematisch. Vereinbaren Sie die Abnahme erst nach Go-Live (in einer Hypercare-Phase unter Last). Wichtig: Die produktive Nutzung (Go-Live) stellt noch keine konkludente Abnahme dar!

8.3 Mängelklassen

Der Begriff "unwesentlicher Mangel" ist für IT zu unscharf. Definieren Sie Mängelklassen (meist 1 bis 4):

Klasse 1: Betriebsverhindernd (blockiert Abnahme)
Klasse 2: Betriebsbehindernd (bestimmte Anzahl blockiert Abnahme)

Vermeiden Sie AGB-Klauseln, die "Workarounds" als endgültige Mangelbeseitigung definieren.

8.4 Verjährungsfalle (§ 634a BGB)

Hochumstritten: Gilt die zweijährige Verjährungsfrist (für Werke an "Sachen") oder die dreijährige (für immaterielle Werke)? Regeln Sie dies eindeutig vertraglich – überlassen Sie es nicht den Gerichten!

9. Projektende: Kündigung und Beendigung

9.1 Die ordentliche Kündigung (§ 648 BGB)

Sie können jederzeit und ohne Angabe von Gründen kündigen.

Kostenfalle: Sie zahlen die vereinbarte Vergütung minus ersparte Aufwendungen. Das Gesetz vermutet pauschal, dass dem Anbieter 5 % der Restvergütung zustehen – gedacht für die Bauwirtschaft. In der Softwarebranche (Margen weit jenseits von 5 %) ist dies extrem unpassend. Regeln Sie diesen Punkt zwingend vertraglich ab!

9.2 Die außerordentliche Kündigung (§ 648a BGB)

Diese greift nur aus "wichtigem Grund": Nichteinhaltung essentieller Fristen (ohne Nachbesserung), schwere Kooperationsverweigerung oder endgültiger Vertrauensverlust. Sie schulden dem Anbieter nur die Vergütung für Leistungsteile, die fehlerfrei und nutzbar erbracht wurden.

10. Fazit

Ein detaillierter, streng verhandelter IT-Vertrag ist kein Zeichen von Misstrauen. Er übersetzt die technische und organisatorische Komplexität moderner Softwareprojekte in berechenbare, steuerbare Bahnen und ist die beste Versicherung für Ihr IT-Budget und Ihre Digitalisierungsstrategie.