Werkvertrag Dienstvertrag Abgrenzung in IT | IT-Medienrecht

Werkvertrag vs. Dienstvertrag: Der entscheidende Unterschied in IT-, KI- und Games-Projekten

Wer Software entwickelt, KI-Modelle trainiert oder ein Games-Projekt mit Milestones und Publisher-Abnahmen stemmt, braucht eine saubere Vertragsarchitektur. Der formale Unterschied zwischen Werkvertrag vs. Dienstvertrag ist kein akademisches Detail. Er entscheidet in der Praxis über Abnahme, Mängelrechte, Change-Requests, Haftungsumfang und Vergütungslogik.

Der rechtliche Kern lässt sich auf eine knappe Formel bringen: Der Dienstvertrag schuldet eine Tätigkeit (§ 611 BGB). Im Gegensatz dazu schuldet der Werkvertrag einen Erfolg (§ 631 BGB). Diese Differenz zieht sich durch den gesamten Projektlebenszyklus.

Sie reicht von der Leistungsbeschreibung über die Abnahme bis zur Frage, ob Nachbesserung, Minderung oder Schadensersatz verlangt werden kann. Zugleich ist stets die Abgrenzung zur Beschäftigung (§ 611a BGB) zu beachten. Falsch gestaltete Freiberufler-Setups bergen das Risiko der Scheinselbstständigkeit.

Dieser Beitrag ordnet die Dogmatik ein. Er übersetzt sie in belastbare Klauselmechaniken und zeigt an Beispielen aus Software-, KI- und Games-Projekten, wie eine rechtssichere und wirtschaftlich sinnvolle Vertragsgestaltung gelingt.

Erfolgsschuld vs. Tätigkeit

Der Dienstvertrag: Fokus auf die Tätigkeit

Der Dienstvertrag verlangt die Erbringung einer Dienstleistung. Es geht hierbei nicht um das Herbeiführen eines bestimmten Ergebnisses. Typische Beispiele im Digitalbereich sind:

• Betriebs- und Supportverträge
• SRE-Bereitschaften
• Content-Moderation
• SOC-Leistungen
• Penetration-Testing „as a Service“
• Laufende Admin-Tätigkeiten an Cloud-Stacks

Die Vergütung wird in der Regel nach Zeit oder nach Servicelevel erbracht. Die Leistungsstörung folgt den Regeln der allgemeinen Leistungsstörungsrechte. Mängelrechte im Sinne der §§ 634 ff. BGB existieren nicht. Dies liegt daran, dass der Dienst keinen abnahmefähigen Erfolg schuldet. Für weitere Details zu Kundenhotline und Support im SaaS finden Sie Informationen in unserem Blog.

Der Werkvertrag: Fokus auf den Erfolg

Demgegenüber steht der Werkvertrag. Er verlangt die Herstellung eines konkreten „Werks“, also eines abnahmefähigen Erfolgs. In der Softwarepraxis bedeutet dies beispielsweise:

• Implementierung eines definierten Featuresets nach Pflichtenheft
• Lieferung einer App-Version mit festgelegten User Stories
• Erreichen einer Spezifikationsreife („Feature Complete“)
• Erbringung messbarer Integrationsleistungen mit bestimmter Systemtiefe

• Vertical Slice
• Alpha
• Beta
• Gold Master
• Day-One-Patch

Die Fiktion der Abnahme greift, wenn die Abnahme ohne wesentliche Mängel verweigert wurde oder Fristen ungenutzt ablaufen. Diese Mechanik sollte vertraglich sauber eingelassen sein, damit Projekte nicht an einer Blockade-Taktik scheitern. Für die allgemeine Bedeutung von Verträgen im Projektmanagement, lesen Sie auch Warum sind Verträge wichtig?

Praxisfehler und hybride Lösungen

Ein häufiger Praxisfehler liegt in der Verwendung von „Werkvertragssprache“ bei einem faktisch dienstvertraglichen Setup. Wer beispielsweise für „Betrieb und Weiterentwicklung“ ein „Erfolgspaket“ verspricht, ohne einen messbaren Erfolg zu definieren, erzeugt Reibung. Auftraggeber erwarten Mängelbeseitigung, während Auftragnehmer auf bloße Tätigkeitspflichten hinweisen.

Abhilfe schafft hier eine zweigleisige Architektur: werkvertragliche Sprints oder Milestones auf der Entwicklungsschiene und dienstvertragliche SLA-Leistungen für Betrieb, Pflege und Incident-Management. Dadurch bleibt die Rechtsnatur trennscharf, die Vergütung stimmig und die Eskalation im Störungsfall kalkulierbar. Für eine detaillierte Betrachtung der Mangelhaftigkeit von SaaS-Lösungen und Vertragsanpassungen, siehe unseren Beitrag.

Leistungsbeschreibung, Abnahme und Mängelrechte

Die Leistungsbeschreibung als Herzstück

Im Werkvertragsregime ist die Leistungsbeschreibung das Herzstück. Ein gutes Pflichtenheft beschreibt nicht nur das „Was“, sondern auch das „Wie“. Es umfasst Funktionsumfang, Schnittstellen, Datenmodelle und Performance-Ziele sowie definierte Qualitätskriterien und Akzeptanztests.

Insbesondere in KI-Projekten genügt es nicht, lediglich „Modell-Training“ zu vereinbaren. Erforderlich sind detaillierte Angaben wie:

• Datenquellen
• Trainings- und Validierungsmetriken
• Budget- und Compute-Grenzen
• Zielkorridore für Accuracy, ROC-AUC, F-Score oder spezifische Fehlertoleranzen

Da KI-Ausgaben probabilistisch sind, muss juristisch klargestellt werden, was als „Erfolg“ gilt: beispielsweise das Erreichen eines validierten Zielbandes auf einem freigegebenen Testset, nicht die Perfektion im Einzelfall. Hier entscheidet sich, ob Abnahme und Fälligkeit tragfähig werden.

Zweistufige Abnahme und Mängelrechte

Die Abnahme erfolgt vorzugsweise zweistufig. Zunächst findet eine formelle Pre-Abnahme pro Teilleistung, beispielsweise pro Sprint-Increment, anhand der vereinbarten Akzeptanzkriterien statt. Anschließend folgt die Gesamtabnahme des Releases.

Teilabnahmen sind nicht nur ein Selbstzweck, sondern dienen als Beweislastinstrument und Liquiditätsanker. Wer Teilabnahmen ausdrücklich vorsieht, verschiebt die Gewährleistungszyklen nach vorne, glättet Cash-Flows und reduziert das Risiko einer „Alles-oder-Nichts“-Blockade am Ende des Projekts.

Die Mängelrechte folgen dann der Werkvertragslogik. Dazu gehören:

• Nacherfüllung (§ 635 BGB)
• Selbstvornahme (§ 637 BGB)
• Minderung (§ 638 BGB)
• Schadensersatz und Rücktritt unter den allgemeinen Voraussetzungen (§§ 280, 281, 323 BGB)

Der entscheidende Punkt ist die saubere Trennung zu Change-Requests. Was eine Abweichung vom Pflichtenheft ist, bleibt ein Mangel. Was hingegen neue Anforderungen sind, stellt eine vergütungspflichtige Änderung dar. Diese Unterscheidung sollte nicht im Fließtext versteckt, sondern durch klare Definitionen und eine eigenständige Nachtragsmechanik abgesichert werden.

Bedeutung der Mitwirkungspflichten

Ein weiterer wichtiger Hebel ist die Mitwirkung des Bestellers. Ohne Datenzugriff, eine geeignete Testumgebung, notwendige Credentials, Sample-Content oder die Verfügbarkeit eines Product-Owners kann ein geschuldeter Erfolg nicht herbeigeführt werden.

§ 642 BGB gibt dem Werkunternehmer einen Entschädigungsanspruch, wenn der Besteller erforderliche Mitwirkungshandlungen unterlässt. Die Integration dieser Norm in die Klauselmechanik verhindert, dass Projekte einseitig „auf Null“ laufen, nur weil auf Auftraggeberseite interne Freigaben fehlen.

Zudem ist der Annahmeverzug zu adressieren. Bleibt die Abnahme trotz Abnahmefähigkeit aus, muss die Vergütung fällig werden können. Abnahmefiktion und Verzugsregeln sichern in solchen Fällen die Planbarkeit eines Projekts.

Agile Modelle, Change-Requests und hybride Verträge

Agilität im Vertragsrecht

„Agil“ ist kein eigener Vertragstyp, sondern eine Methodik. Juristisch lässt sich Agilität als Folge klar definierter, abnahmefähiger Teilwerke strukturieren. Sprint-Backlogs mit konkreten „Definition of Done“ lassen sich in Werklogik fassen, sofern die User Stories hinreichend bestimmt sind.

Alternativ kann ein agiles Vorhaben dienstvertraglich mit „Best-Efforts“-Charakter gestaltet werden. Dies ist sinnvoll, wenn bewusst auf abnahmefähige Erfolge verzichtet wird, wie es oft bei Forschung und Vorentwicklung (Prototyping, Tech-Spike, Datenaufbereitung) der Fall ist.

Problematisch ist jedoch die unreflektierte Mischung. „Time & Material“ ohne Abnahme und gleichzeitig Mängelrechte nach Werkrecht passen nicht zusammen. Weitere Informationen zur Vertragsgestaltung in agilen Projekten finden Sie unter Agile-Entwicklungsverträge in der Praxis oder Vertragsgestaltung im Kontext agiler Arbeitsmethoden: Scrum und Co.

Management von Change-Requests

Change-Requests stellen den Nervenknoten in komplexen Projekten dar. Ohne eine belastbare Nachtragsmechanik drohen wirtschaftliche Verzerrungen. Ein sauberes Verfahren beginnt mit der schriftlichen Änderungsanzeige. Diese beschreibt die Auswirkungen auf Umfang, Kosten und Termine.

Das Verfahren sollte Bewertungsfristen für beide Seiten vorsehen und eine Interimsphase regeln. In dieser Phase gilt entweder die alte Spezifikation weiter oder die Umsetzung beginnt provisorisch. Besonders wichtig ist die Zurechnung: Handelt der Auftragnehmer auf Zuruf ohne Budgetfreigaben, wird das Projekt schnell zur Verlustfalle.

Die Prinzipien „No Work Without Order“ und ein eskalationsfähiger Freigabeprozess sind daher keine bloßen Formalismen, sondern essenzielle Instrumente der Risikosteuerung.

Hybride Modelle im Games-Co-Development

• Vertical Slice
• Combat-Loop-Prototyp
• Content-Drop
• Beta-Freeze
• Submission-Build
• Day-One-Patch

Auf Dienstvertragsseite laufen parallel Bugfix-SLA, Live-Ops-Support und Balancing-Support. Diese werden nach Tickets, Prioritäten und Reaktionszeiten vergütet. Dadurch wird aus einem „agilen“ Ansatz ein klarer Rechtsrahmen, der beiden Seiten Vorteile bietet. Auftraggeber erhalten verlässliche Liefergegenstände, und Auftragnehmer verfügen über eine faire Vergütungsgrundlage. Mehr über die rechtliche Gestaltung von Live-Service-Games finden Sie in unserem Beitrag.

Vergütung, Caps und Risikoallokation

Vergütung im Werkvertrag

Werklohn ohne Abnahme ist ein Widerspruch. Die Vergütung im Werkvertragsregime sollte deshalb an Meilensteine gebunden sein. Anzahl, Höhe und Fälligkeit der Zahlungen folgen der wirtschaftlichen Logik des Projekts. Frühe Zahlungen sichern den Cash-Flow, spätere Zahlungen koppeln die Liquidität an die tatsächliche Leistung.

In KI-Setups hat es sich bewährt, Vorprojekte mit kleinerem Volumen als werkvertragliche „Discovery & Data Readiness“ zu strukturieren. Dies reduziert das Risiko teurer Fehlannahmen und bereitet ein belastbares Hauptprojekt vor. Bei unklaren Datenlagen ist zudem ein dienstvertraglicher „Research & Feasibility“-Block sinnvoll. Dieser arbeitet ergebnisoffen und sieht bewusst keine Abnahme vor.

Preisänderungen und Risikobegrenzung durch Caps

Preisänderungen durch Änderungen des Leistungsumfangs sind nicht nur zulässig, sondern zwingend. Dies gilt insbesondere, wenn Leistungsumfang, Datenqualität oder Sicherheitsanforderungen wachsen. Ein Index aus Aufwands- und Terminwirkung schafft hier Transparenz. Jede Änderung erhält eine Einordnung in Aufwandspunkte, die direkt auf die Budgetplanung durchschlagen.

Preisgleitklauseln für erhebliche Drittkosten wie Compute, Hosting, Lizenzen oder DOOH-Slots sind ratsam. Sie müssen jedoch mit nachvollziehbaren Nachweisen hinterlegt werden. Plafonds, auch „Caps“ genannt, dämpfen das Gesamtrisiko. Sie passen in beide Vertragsarten, müssen aber mit Bedacht justiert werden.

Im Werkrecht betreffen Caps vor allem den Sekundär-Schadensersatz, während Kernerfüllung und Nacherfüllung naturgemäß nicht gekappt werden können. In Dienstleistungs-SLAs sind Caps ein zentrales Element des Risikopreises. Hier gilt: höheres Cap, höherer Preis – so einfach ist die Korrelation.

Bonus-Malus-Mechaniken

Bonus-Malus-Mechaniken funktionieren effektiv, wenn sie an messbare und beeinflussbare Parameter anknüpfen. Eine Games-Portierung mit klaren Performance-Zielen auf Ziel-Hardware lässt sich beispielsweise an Frame-Time, Crash-Rate und Compliance-Pass-Rate koppeln.

Ein KI-Support-Bot im Kundenservice sollte hingegen nicht an „Kundenzufriedenheit insgesamt“ gemessen werden. Stattdessen sind Parameter wie First-Contact-Resolution innerhalb definierter Domänen und Halluzinations-Quoten auf eng beschriebenen Knowledge-Bases relevanter.

Die juristische Einordnung ist hier entscheidend: Bleibt es bei Tätigkeitspflichten (Dienstvertrag), sind Bonus/Malus als Leistungsincentives zu verstehen. Wird jedoch ein konkreter Erfolg vergütungsrelevant, nähert man sich der werkvertraglichen Logik. In diesem Fall sollten Abnahme- und Mängelrechte konsequent mitgedacht werden.

Haftung, IP-Rechte und Compliance: Was im Streitfall wirklich zählt

Haftung nach Vertragsart

Die Haftung folgt der Natur des Vertrages. Im Werkvertrag führt ein Mangel zur Nacherfüllung und danach zu Minderung oder Schadensersatz. Der Auftragnehmer haftet für das Ausbleiben des geschuldeten Erfolgs. Dies gilt, solange nicht Mitwirkungsdefizite oder unmögliche Vorgaben die Kausalität durchbrechen.

In Dienstverhältnissen wird hingegen für sorgfältige Leistungserbringung gehaftet, nicht für den Erfolg. Eine SRE-Bereitschaft, die SLA-Reaktionszeiten einhält, haftet nicht dafür, dass eine nicht durch sie verursachte Überlastung niemals auftritt.

Beide Vertragsarten kennen Haftungsbegrenzungen. Grobe Fahrlässigkeit und Vorsatz sind typischerweise ausgenommen, ebenso wie Verletzungen von Leben, Körper und Gesundheit.

IP-Rechte und Lizenz-Compliance

Besonders heikel ist die Rechtekette in der Software- und Content-Produktion. Fehlen klare Rechteübertragungen oder hat der Dienstleister Subunternehmer eingebunden, die ihrerseits keine ausreichenden Rechte eingeräumt haben, drohen Sperren und Unterlassungsansprüche. Mehr zur Rechtekette im Game Development erfahren Sie in unserem Blogbeitrag.

Im Werkvertrag gehört eine umfassende, projektzweckbezogene Einräumung einfacher oder ausschließlicher Nutzungsrechte in den Vergütungskern. In dynamischen Umgebungen, etwa bei Toolchains mit Open-Source-Bibliotheken, muss die Lizenz-Compliance stets mitlaufen. Copyleft-Komponenten können im ungünstigsten Fall die Lizenzierung des Gesamtwerks beeinflussen. Wer die Open-Source-Policy zum Vertragsbestandteil macht, reduziert dieses Risiko. Hierzu auch unser Artikel Open Source in der Softwareentwicklung: Rechtliche Grundlagen und Praxis.

Bei KI-Projekten kommt die Frage der Trainingsdaten hinzu: Quellen, Lizenzen, Persönlichkeits- und Geheimnisschutz sowie die Verantwortlichkeit für generierte Ausgaben. Rein synthetische Ausgaben können urheberrechtlich schutzarm sein. Das ändert jedoch nichts daran, dass sie rechtswidrig sein können, wenn sie geschützte Vorlagen zu nahe nachzeichnen oder Persönlichkeitsrechte verletzen. Die Gewährleistungs- und Freistellungsklauseln müssen diese Realität abbilden. Interessante Einblicke zum Urheberrecht und KI-Training finden Sie unter diesem Link.

Für vertiefende Informationen zum Eigentum an Software und Code empfehlen wir unseren Artikel.

Abgrenzung zur Scheinselbstständigkeit

Schließlich ist die Grenze zur Beschäftigung relevant. § 611a BGB definiert das Arbeitsverhältnis. Wo Weisungsdichte, Eingliederung in die Organisation, einseitige Arbeitszeitvorgaben und Arbeitsplatzbindung dominieren, droht Scheinselbstständigkeit.

Besonders anfällig sind langfristige „Dienstleistungs-Retainer“ mit voller Integration in das Product-Team. Verträge sollten daher den unternehmerischen Zuschnitt freier Mitarbeit betonen. Dies umfasst eigenes Equipment, eigenständige Arbeitsorganisation, Ergebnisverantwortung, Vertretungsmöglichkeit und kalkulierte Projektrisiken.

In Werk-Setups spricht der erfolgsbezogene Zuschnitt zudem gegen eine Beschäftigung. Dennoch gilt: Entscheidend ist die gelebte Praxis, nicht das Papier. Für verwandte Themen siehe Kein Ausschluss von Sozialversicherungspflicht durch Vertragsbeziehung mit Ein-Personen-Kapitalgesellschaft!

Typische Szenarien aus der Praxis – und wie die Einordnung gelingt

Szenario 1: Connector-Entwicklung und Monitoring

Ein mittelständisches Unternehmen beauftragt die Entwicklung eines Connectors, der ein ERP-System mit einem PIM verbindet. Die Parteien definieren in einem Pflichtenheft detailliert Datenfelder, Sync-Rhythmen, Konfliktlogik, Fehlertoleranzen und Latenzbudgets. In diesem Fall drängt sich der Werkvertrag auf, da der Connector abnahmefähig ist und der Erfolgsmaßstab die Funktionsweise gemäß Spezifikation ist.

Parallel dazu schließt das Unternehmen einen Dienstvertrag für „Operations & Monitoring“ ab. Hierbei werden Logs überwacht, Störungen klassifiziert und SLA-Reaktionszeiten vereinbart. Tritt ein Bug auf, ist zu prüfen, ob es sich um einen Mangel an einem abgenommenen Werkbestandteil handelt oder um einen reinen Betriebszwischenfall. Die erste Kategorie triggert Nacherfüllung, während die zweite als Incident nach SLA abgearbeitet wird.

Szenario 2: KI-Modell Fine-Tuning

Ein KI-Anbieter fine-tuned ein Large-Language-Model auf der Wissensbasis eines Support-Portals. Dieses Vorhaben gliedert sich in Datenaufbereitung, Trainings- und Evaluationsphase, Prompt-Design und Integration. Solange die Parteien lediglich eine „Best-Efforts“-Verbesserung vereinbaren, ohne ein objektivierbares Zielband zu definieren, liegt ein Dienstvertrag nahe.

Vereinbaren sie dagegen ein validiertes Qualitätsband auf einem Testset, ergänzt durch Integrations-KPIs und Inferenzkosten-Budgets, entsteht ein abnahmefähiges Werk. Aus unserer Erfahrung empfiehlt sich hier eine Trennung: Ein kurzer, dienstvertraglicher Feasibility-Block prüft die Datenrealität. Darauf folgt ein werkvertragliches Hauptprojekt mit klaren Abnahmeparametern. Weitere rechtliche Überlegungen zu KI-generierten Inhalten finden Sie unter diesem Link.

Szenario 3: Games-Co-Development

In einem Games-Projekt soll ein externer Co-Dev-Partner das Combat-System optimieren und Plattform-Ports übernehmen. Für die Portierung sind Performance-Budgets, Memory-Limits, Load-Times und Compliance-Pass-Raten klar definierbar. Hier passt der Werkvertrag ideal.

Für Live-Ops-Aufgaben nach dem Launch, wie Balancing, Hotfixes oder Event-Betrieb, ist ein Dienstvertrag mit Incident- und Change-Regeln sinnvoll. Ein häufiger Fehler ist die undifferenzierte Bezeichnung „Entwicklungsvertrag“, bei der alle Komponenten vermischt werden.

Rechtlich klarer und wirtschaftlich fairer ist ein Dual-Modell: Ein klarer Werkvertragsteil mit Milestones und Abnahmen und daneben ein Dienstleistungs-SLA für den Live-Betrieb. Dies bietet eine solide Grundlage für die Zusammenarbeit.

Vertragsbausteine, die in der Praxis tragen

Klare Definitionen und Rollenverteilung

Ein überzeugender Vertrag beginnt mit klaren Definitionen, die nicht nur Begriffe ordnen, sondern auch präzise Grenzlinien ziehen. Zum Beispiel ist ein „Mangel“ jede Abweichung vom freigegebenen Pflichtenheft, nicht jede geschmackliche Präferenz. Ein „Change“ wiederum ist jede neue Anforderung außerhalb des ursprünglichen Scopes, unabhängig davon, wie „klein“ sie erscheinen mag.

Eine eindeutige Rollen- und Mitwirkungsbeschreibung legt fest, wer der Product-Owner ist, wer Release-Freigaben erteilt, wer den Zugang zu Drittsystemen organisiert und in welchen Fristen Feedback zu Entwürfen gegeben wird. Fristlogik und Eskalationsmechanismen verhindern Schwebezustände. Bleibt Feedback aus, gilt eine Stufe als vorläufig freigegeben. Bleibt die Abnahmeerklärung ohne gewichtigen Grund aus, greift die Abnahmefiktion.

Solche Regeln sind mehr als bloße Formalien; sie schützen Projekt-Zeitpläne und Budgets effektiv. Eine gute Vertragsgestaltung kann viel Ärger ersparen.

Gewährleistung, Haftung und Vergütung

Gewährleistung und Haftung greifen nur, wenn sie an die Vertragsnatur angebunden sind. Eine pauschale „Minderung bei SLA-Verstoß“ ist im Dienstvertrag zulässig, ersetzt aber nicht die Mängelrechte des Werkrechts.

Umgekehrt sind „Bugfixes innerhalb 48 Stunden“ im Werkrecht ohne SLA-Logik häufig unrealistisch. Vernünftig ist hier eine Kategorisierung nach Fehlerklassen, verknüpft mit angemessenen Reaktions- und Behebungsfristen.

Die Vergütung muss diesen Realitäten folgen:

• Im Werkteil: Meilenstein-Zahlungen mit klaren Abnahmeereignissen.
• Im Dienstleistungs-Teil: Monats- oder Quartalspauschalen mit Ticket-Deckelungen.

Wirtschaftliche Stabilität gewährleisten Anpassungsklauseln bei Drittkosten, Budget-Reserven für bekannte Risiken und transparent dokumentierte Changes. Caps und Freistellungen verhindern finanzielle Ausreißer, ohne den Kern der Leistung auszuhöhlen.

Bearbeitungsrechte in KI- und Games-Projekten

Besonders in KI- und Games-Projekten verdienen Bearbeitungsrechte besondere Aufmerksamkeit. Das Recht, gelieferten Code, Assets oder Modelle anzupassen, zu übersetzen, zu kompilieren, zu integrieren und in neue Umgebungen zu portieren, ist keine bloße Option, sondern eine grundlegende Nutzungsvoraussetzung.

Gleichzeitig schützt das Urheberpersönlichkeitsrecht vor entstellenden Bearbeitungen. Die vertragliche Balance liegt daher in einem umfangreichen Bearbeitungsrecht für sachlich erforderliche Transformationen, flankiert von einem Schutz vor entstellenden Veränderungen. Bei Teams mit mehreren Dienstleistern ist zudem zu klären, dass Bearbeitungsrechte auch untereinander gelten, um eine reibungslose Integration zu ermöglichen.

Stolpersteine und deren elegante Umgehung

Häufige Stolpersteine im Projektverlauf

Ein häufiger Stolperstein ist die „Abnahmevermeidung“ durch endlose Feedback-Schleifen. Abhilfe schaffen hier eine Kaskade aus definierten Feedback-Fenstern, die Fiktion der Zwischenfreigabe und ein klarer Eskalationspfad, der eine abschließende Entscheidung herbeiführt.

Ein weiterer Stolperstein ist der „Change-Creep“. Dies sind kleine, scheinbar harmlose Wünsche, die kumuliert das Projekt entgleisen lassen können. Gegenmittel sind eine disziplinierte Backlog-Pflege, transparente Burn-Down-Metriken und die vertragliche Pflicht, Auswirkungen in Zeit und Geld vor der Umsetzung zu bestätigen.

Drittens droht in verteilten Setups ein Rechte-Vakuum. Wer Subunternehmer ohne klare Rechtekette einbindet oder Open-Source-Compliance ignoriert, riskiert Sperren oder Nachlizenzierungen. Eine verpflichtende SBOM-Dokumentation (Software Bill of Materials) und ein schlanker Approval-Prozess für Lizenzen halten die Lage beherrschbar.

Falsche Erwartungen und Kündigungsrechte

Im Grenzbereich zwischen Dienst- und Werkvertrag lauert schließlich die Gefahr falscher Erwartungen. Auftraggeber rechnen oft mit „Fehlerbehebung inklusive“, obwohl lediglich „Time & Material“ für Tätigkeiten vereinbart ist. Auftragnehmer kalkulieren wiederum knapp, obwohl Abnahmelogik und Mängelbeseitigung gesetzlich vorgezeichnet sind. Transparenz auf den ersten Seiten des Vertrags, die klarstellt, welche Leistungen werkvertraglich und welche dienstvertraglich sind, reduziert solche Missverständnisse erheblich.

Wer zudem frühzeitig die Kündigungsrechte adressiert, vermeidet harte Brüche. Im Werkrecht existiert das freie Kündigungsrecht des Bestellers (§ 648 BGB). Hier sind die Vergütung bis dahin sowie die ersparten Aufwendungen zu saldieren.

Im Dienstvertrag greift die ordentliche Kündigung nach Frist. Diese ist ökonomisch besser steuerbar, wenn Mindestlaufzeiten und Kündigungsfenster klug gewählt sind. Ein passender Artikel ist Dienstvertrag und Vergütungsanspruch: Warum „schlechte Arbeit“ nicht zur Zahlungsverweigerung führt.

Unterschied Werk-/Dienstvertrag am Beispiel auf einen Blick

Der entscheidende Unterschied zwischen Werkvertrag und Dienstvertrag lässt sich anhand konkreter Beispiele exemplarisch fassen:

• Ein „Managed-Hosting & Support“-Vertrag ist ein Dienstvertrag. Hierbei werden Betriebsleistungen, Reaktionszeiten und Sorgfalt geschuldet.
• Die „Implementierung eines Zahlungsmoduls gemäß Spezifikation X mit Zertifizierung Y“ ist ein Werkvertrag. Geschuldet ist die funktionsfähige Implementierung inklusive Abnahme.
• Ein „Prompt-Engineering-Coaching“ oder „AI-Strategy-Sparring“ ist ein Dienstvertrag. Die Qualität bemisst sich an der Beratungsleistung, nicht an einem fixen KPI-Erfolg.
• Das „Fein-Tuning eines Modells auf Ziel-Metrik Z auf Testset T“ ist ein Werkvertrag. Hier steht der messbare Zielerfolg im Zentrum.
• Ein „Port auf Plattform P mit Performance-Budgets“ ist ein Werkvertrag.
• Ein „Post-Launch-Balancing-Support“ ist typischerweise ein Dienstvertrag.

Diese Lesart beantwortet die Suchintention präzise: Der Vergleich gelingt nicht über Schlagworte, sondern über das, was objektiv geprüft und abgenommen werden kann.

Fazit

Die klare Abgrenzung zwischen Werkvertrag und Dienstvertrag ist entscheidend für den Projekterfolg, da sie Fälligkeit, Abnahme, Mängelrechte, Haftung und Vergütung strukturiert. Insbesondere in Software-, KI- und Games-Vorhaben empfiehlt sich eine bewusste Hybrid-Architektur.

Werkvertragliche, abnahmefähige Deliverables sind dort sinnvoll, wo Spezifikation und Akzeptanzkriterien klar definiert sind. Dienstvertragliche SLAs eignen sich hingegen dort, wo Betrieb, Forschung, Coaching oder reaktive Leistungen im Vordergrund stehen.

Wer diese Unterscheidungen konsequent in Definitionen, Mitwirkung, Change-Verfahren, Vergütungslogik, IP-Rechten und Haftung berücksichtigt, vermeidet übliche Reibungsverluste und behält sowohl die wirtschaftliche als auch die rechtliche Kontrolle über seine Projekte.

Lassen Sie sich beraten!