Werkvertrag vs. Dienstvertrag in Software-, 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, sondern 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), der Werkvertrag einen Erfolg (§ 631 BGB). Diese Differenz zieht sich durch den gesamten Projektlebenszyklus – von der Leistungsbeschreibung über die Abnahme bis zur Frage, ob Nachbesserung, Minderung oder Schadensersatz verlangt werden kann. Zugleich schwingt stets die Abgrenzung zur Beschäftigung mit (§ 611a BGB), denn falsch gestaltete Freiberufler-Setups bergen das Risiko der Scheinselbstständigkeit. Der Beitrag ordnet die Dogmatik ein, ü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 verlangt die Erbringung einer Dienstleistung, nicht 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“ sowie 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, weil der Dienst keinen abnahmefähigen Erfolg schuldet.

Demgegenüber steht der Werkvertrag. Er verlangt die Herstellung eines konkreten „Werks“ – also eines Erfolgs, der abnahmefähig ist. In der Softwarepraxis sind das etwa die Implementierung eines definierten Featuresets nach Pflichtenheft, die Lieferung einer App-Version mit festgelegten User Stories, das Erreichen einer Spezifikationsreife („Feature Complete“) oder das Erbringen messbarer Integrationsleistungen mit bestimmter Systemtiefe. Im Games-Bereich sind Vertical Slice, Alpha, Beta, Gold Master und Day-One-Patch typische, abnahmefähige Teilerfolge. Zentral ist die Abnahme (§ 640 BGB): Erst mit Abnahme wird die Vergütung fällig, laufen Gewährleistungsfristen an und verschiebt sich die Beweislast. 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.

Der Praxisfehler liegt häufig in „Werkvertragssprache“ bei faktisch dienstvertraglichem Setup. Wer etwa für „Betrieb und Weiterentwicklung“ ein „Erfolgspaket“ verspricht, ohne messbaren Erfolg zu definieren, erzeugt Reibung: Auftraggeber erwarten Mängelbeseitigung, Auftragnehmer weisen auf bloße Tätigkeitspflichten hin. Abhilfe schafft eine zweigleisige Architektur: Werkvertragliche Sprints oder Milestones auf der Entwicklungsschiene und dienstvertragliche SLA-Leistungen für Betrieb, Pflege und Incident-Management. So bleibt die Rechtsnatur trennscharf, die Vergütung stimmig und die Eskalation im Störungsfall kalkulierbar.

Leistungsbeschreibung, Abnahme und Mängelrechtet

Im Werkvertragsregime ist die Leistungsbeschreibung das Herzstück. Ein gutes Pflichtenheft beschreibt nicht nur „Was“ (Funktionsumfang, Schnittstellen, Datenmodelle, Performance-Ziele), sondern auch „Wie“ in dem Sinne, dass Qualitätskriterien und Akzeptanztests definiert sind. In KI-Projekten genügt es nicht, „Modell-Training“ zu vereinbaren; erforderlich sind Datenquellen, Trainings- und Validierungsmetriken, Budget- und Compute-Grenzen sowie Zielkorridore für Accuracy, ROC-AUC, F-Score oder spezifische Fehlertoleranzen. Da KI-Ausgaben probabilistisch sind, muss juristisch klargestellt werden, was als „Erfolg“ gilt: etwa 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.

Die Abnahme erfolgt vorzugsweise zweistufig. Zunächst die formelle Pre-Abnahme pro Teilleistung (z. B. pro Sprint-Increment) anhand der vereinbarten Akzeptanzkriterien, danach die Gesamtabnahme des Releases. Teilabnahmen sind kein Selbstzweck, sondern Beweislastinstrument und Liquiditätsanker. Wer Teilabnahmen ausdrücklich vorsieht, verschiebt die Gewährleistungszyklen nach vorne, glättet Cash-Flows und reduziert das Risiko der „Alles-oder-Nichts“-Blockade am Ende. Mängelrechte folgen dann der Werkvertragslogik: Nacherfüllung (§ 635 BGB), Selbstvornahme (§ 637 BGB), Minderung (§ 638 BGB), Schadensersatz und Rücktritt unter den allgemeinen Voraussetzungen (§§ 280, 281, 323 BGB). Der Clou liegt in der sauberen Trennung zu Change-Requests: Was Abweichung vom Pflichtenheft ist, bleibt Mangel; was neue Anforderungen sind, ist vergütungspflichtige Änderung. Diese Linie sollte textlich nicht im Fließtext versteckt, sondern über klare Definitionen und eine eigenständige Nachtragsmechanik abgesichert werden.

Ein zweiter Hebel ist die Mitwirkung. Ohne Datenzugriff, Testumgebung, Credentials, Sample-Content oder Product-Owner-Verfügbarkeit kann ein Erfolg nicht herbeigeführt werden. § 642 BGB gibt dem Werkunternehmer einen Entschädigungsanspruch, wenn der Besteller erforderliche Mitwirkungshandlungen unterlässt. Wer diese Norm in die Klauselmechanik integriert, verhindert, dass Projekte einseitig „auf Null“ laufen, obwohl auf Auftraggeberseite interne Freigaben fehlen. Zudem ist Annahmeverzug zu adressieren: Bleibt Abnahme trotz Abnahmefähigkeit aus, muss Vergütung fällig werden können; Abnahmefiktion und Verzugsregeln sichern hier die Planbarkeit.

Agile Modelle, Change-Requests und hybride Verträge:

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, wenn bewusst auf abnahmefähige Erfolge verzichtet wird – ein Setup, das bei Forschung und Vorentwicklung (Prototyping, Tech-Spike, Datenaufbereitung) häufig sinnvoll ist. Problematisch ist die unreflektierte Mischung: „Time & Material“ ohne Abnahme und gleichzeitig Mängelrechte nach Werkrecht passt nicht zusammen.

Change-Requests sind der Nervenknoten in komplexen Projekten. Ohne belastbare Nachtragsmechanik drohen wirtschaftliche Verzerrungen. Ein sauberes Verfahren beginnt mit der schriftlichen Änderungsanzeige, beschreibt Auswirkungen auf Umfang, Kosten und Termine, sieht Bewertungsfristen beider Seiten vor und regelt eine Interimsphase, in der entweder die alte Spezifikation weitergilt oder die Umsetzung provisorisch beginnt. Wichtig ist die Zurechnung: Muss der Auftragnehmer auf Zuruf handeln, ohne dass Budgetfreigaben erfolgt sind, wird das Projekt zur Verlustfalle. „No Work Without Order“ und ein eskalationsfähiger Freigabeprozess sind deshalb kein Formalismus, sondern Risikosteuerung.

Für Games-Co-Development bietet sich eine Milestone-Architektur an, bei der jeder Milestone ein eigenes Mini-Pflichtenheft, Akzeptanzkriterien, Review-Termine und eine Milestone-Abnahme hat. Vertical Slice, Combat-Loop-Prototyp, Content-Drop, Beta-Freeze, Submission-Build und Day-One-Patch sind jeweils abnahmefähige Teilerfolge. Auf Dienstvertragsseite laufen parallel Bugfix-SLA, Live-Ops-Support und Balancing-Support, die nach Tickets, Prioritäten und Reaktionszeiten vergütet werden. So wird aus „agil“ ein klarer Rechtsrahmen, der beiden Seiten hilft: Auftraggeber erhalten verlässliche Liefergegenstände, Auftragnehmer eine faire Vergütungsgrundlage.

Vergütung, Caps und Risikoallokation

Werklohn ohne Abnahme ist ein Widerspruch. Die Vergütung im Werkvertragsregime gehört deshalb an Meilensteine gebunden. Anzahl, Höhe und Fälligkeit folgen der wirtschaftlichen Logik des Projekts: frühe Zahlungen sichern Cash-Flow, spätere Zahlungen koppeln Liquidität an tatsächliche Leistung. In KI-Setups hat es sich bewährt, Vorprojekte mit kleinerem Volumen als werkvertragliche „Discovery & Data Readiness“ zu strukturieren, die das Risiko teurer Fehlannahmen reduziert und ein belastbares Hauptprojekt vorbereitet. Bei unklaren Datenlagen ist ein dienstvertraglicher „Research & Feasibility“-Block sinnvoll, der ergebnisoffen arbeitet und bewusst keine Abnahme vorsieht.

Preisänderungen durch Changes sind nicht nur zulässig, sondern zwingend, wenn Leistungsumfang, Datenqualität oder Sicherheitsanforderungen wachsen. Ein Index aus Aufwands- und Terminwirkung schafft Transparenz: Jede Änderung erhält eine Einordnung in Aufwandspunkte, die auf die Budgetplanung durchschlagen. Preisgleitklauseln für erhebliche Dritt-Kosten – Compute, Hosting, Lizenzen, DOOH-Slots – sind ratsam, solange sie mit nachvollziehbaren Nachweisen hinterlegt werden. Plafonds („Caps“) dämpfen das Gesamtrisiko; sie passen in beide Welten, müssen aber mit Bedacht justiert werden. Im Werkrecht sprechen Caps vor allem den Sekundär-Schadensersatz an, während Kernerfüllung und Nacherfüllung naturgemäß nicht gekappt werden können. In Dienstleistungs-SLAs sind Caps ein zentrales Element des Risikopreises; höheres Cap, höherer Preis – so einfach ist die Korrelation.

Bonus-Malus-Mechaniken funktionieren, wenn sie an messbare, beeinflussbare Parameter anknüpfen. Eine Games-Portierung mit klaren Performance-Zielen auf Ziel-Hardware lässt sich an Frame-Time, Crash-Rate und Compliance-Pass-Rate koppeln. Ein KI-Support-Bot im Kundenservice dagegen sollte nicht an „Kundenzufriedenheit insgesamt“ gemessen werden, sondern an First-Contact-Resolution innerhalb definierter Domänen und an Halluzinations-Quoten auf eng beschriebenen Knowledge-Bases. Wichtig ist die juristische Einordnung: Bleibt es bei Tätigkeitspflichten (Dienstvertrag), sind Bonus/Malus Leistungsincentives; wird ein konkreter Erfolg vergütungsrelevant, nähert man sich werkvertraglicher Logik und sollte Abnahme- und Mängelrechte konsequent mitdenken.

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

Haftung folgt der Vertragsnatur. Im Werkvertrag führt ein Mangel zur Nacherfüllung, danach zu Minderung oder Schadensersatz. Der Auftragnehmer haftet für das Ausbleiben des geschuldeten Erfolgs, soweit nicht Mitwirkungsdefizite oder unmögliche Vorgaben die Kausalität durchbrechen. In Dienstverhältnissen wird 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 nie auftritt. Beide Welten kennen Haftungsbegrenzungen; grobe Fahrlässigkeit und Vorsatz sind typischerweise ausgenommen, Verletzungen von Leben, Körper, Gesundheit ohnehin.

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. 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 mitlaufen. Copyleft-Komponenten können im ungünstigen Fall die Lizenzierung des Gesamtwerks beeinflussen. Wer die Open-Source-Policy zum Vertragsbestandteil macht, reduziert dieses Risiko. 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 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.

Schließlich die Grenze zur Beschäftigung. § 611a BGB definiert das Arbeitsverhältnis. Wo Weisungsdichte, Eingliederung in die Organisation, einseitige Arbeitszeitvorgaben und Arbeitsplatzbindung dominieren, droht Scheinselbstständigkeit. Gerade langfristige „Dienstleistungs-Retainer“ mit voller Integration in das Product-Team sind anfällig. Verträge sollten deshalb den unternehmerischen Zuschnitt freier Mitarbeit betonen: eigenes Equipment, eigenständige Arbeitsorganisation, Ergebnisverantwortung, Vertretungsmöglichkeit, kalkulierte Projektrisiken. In Werk-Setups spricht zudem der erfolgsbezogene Zuschnitt gegen Beschäftigung. Gleichwohl gilt: Entscheidend ist die gelebte Praxis, nicht das Papier.

Typische Szenarien aus der Praxis – und wie die Einordnung gelingt

Ein mittelständisches Unternehmen beauftragt die Entwicklung eines Connectors, der ein ERP-System mit einem PIM verbindet. Die Parteien definieren in einem Pflichtenheft Datenfelder, Sync-Rhythmen, Konfliktlogik, Fehlertoleranzen und Latenzbudgets. Hier drängt sich der Werkvertrag auf: Der Connector ist abnahmefähig, Erfolgsmaß ist die Funktionsweise gemäß Spezifikation. Parallel schließt das Unternehmen einen Dienstvertrag für „Operations & Monitoring“ ab, in dem Logs überwacht, Störungen klassifiziert und SLA-Reaktionszeiten vereinbart werden. Tritt ein Bug auf, ist zu prüfen, ob es sich um einen Mangel an einem abgenommenen Werkbestandteil handelt oder um einen Betriebszwischenfall. Erstere Kategorie triggert Nacherfüllung; letztere wird als Incident nach SLA abgearbeitet.

Ein KI-Anbieter fine-tuned ein Large-Language-Model auf der Wissensbasis eines Support-Portals. Das Vorhaben gliedert sich in Datenaufbereitung, Trainings- und Evaluationsphase, Prompt-Design und Integration. Solange die Parteien nur 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, dazu Integrations-KPIs und Inferenzkosten-Budgets, entsteht ein abnahmefähiges Werk. Aus Erfahrung empfiehlt sich die Trennung: ein kurzer, dienstvertraglicher Feasibility-Block, der die Datenrealität prüft, gefolgt von einem werkvertraglichen Hauptprojekt mit klaren Abnahmeparametern.

In einem Games-Projekt soll ein externer Co-Dev-Partner das Combat-System polieren und Plattform-Ports übernehmen. Für die Portierung sind Performance-Budgets, Memory-Limits, Load-Times und Compliance-Pass-Raten definierbar; der Werkvertrag passt ideal. Für Live-Ops-Aufgaben nach Launch – Balancing, Hotfixes, Event-Betrieb – ist ein Dienstvertrag mit Incident- und Change-Regeln sinnvoll. Der häufige Fehler ist die undifferenzierte Bezeichnung „Entwicklungsvertrag“ mit Vermischung aller Komponenten. Rechtlich klarer und wirtschaftlich fairer ist das Dual-Modell: klarer Werkvertragsteil mit Milestones und Abnahmen, daneben ein Dienstleistungs-SLA für den Live-Betrieb.

Vertragsbausteine, die in der Praxis tragen – ohne Aufzählungsästhetik

Ein überzeugender Vertrag beginnt mit Definitionen, die nicht nur Begriffe ordnen, sondern die Grenzlinien ziehen: „Mangel“ ist jede Abweichung vom freigegebenen Pflichtenheft, nicht jede geschmackliche Präferenz. „Change“ ist jede neue Anforderung außerhalb des Scopes, unabhängig davon, wie „klein“ sie erscheint. Eine klare Rollen- und Mitwirkungsbeschreibung adressiert, wer Product-Owner ist, wer Release-Freigaben erteilt, wer Zugang zu Drittsystemen organisiert und in welchen Fristen Feedback zu Entwürfen gibt. Fristlogik und Eskalation 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 Formalien – sie schützen Projekt-Zeitpläne und Budgets.

Auf der Rechtsfolgenseite greifen Gewährleistung und Haftung nur, wenn sie an die Vertragsnatur andocken. 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 eine Kategorisierung nach Fehlerklassen, verknüpft mit angemessenen Reaktions- und Behebungsfristen. Vergütung muss diesen Realitäten folgen: Meilenstein-Zahlungen mit klaren Abnahmeereignissen im Werkteil; Monats- oder Quartalspauschalen mit Ticket-Deckelungen im Dienstleistungs-Teil. Für wirtschaftliche Stabilität sorgen Anpassungs-klauseln bei Dritt-Kosten, Budget-Reserven für bekannte Risiken und transparent dokumentierte Changes. Caps und Freistellungen verhindern Ausreißer, ohne den Kern der Leistung auszuhöhlen.

Besonders in KI- und Games-Projekten verdienen Bearbeitungsrechte Aufmerksamkeit. Das Recht, gelieferten Code, Assets oder Modelle anzupassen, zu übersetzen, zu kompilieren, zu integrieren und in neue Umgebungen zu portieren, ist kein „nice to have“, sondern Nutzungsgrundlage. Gleichzeitig schützt das Urheberpersönlichkeitsrecht vor entstellenden Bearbeitungen. Die vertragliche Balance lautet: umfangreiches Bearbeitungsrecht für sachlich erforderliche Transformationen, flankiert von einem Schutz vor entstellenden Veränderungen. In Teams mit mehreren Dienstleistern ist zudem zu klären, dass Bearbeitungsrechte auch untereinander gelten, damit Integration möglich bleibt.

Stolpersteine und deren elegante Umgehung

Ein häufiger Stolperstein ist die „Abnahmevermeidung“ durch endlose Feedback-Schleifen. Abhilfe leistet eine Kaskade aus definierten Feedback-Fenstern, der Fiktion der Zwischenfreigabe und einem Eskalationspfad, der eine abschließende Entscheidung herbeiführt. Ein zweiter Stolperstein ist der „Change-Creep“: kleine, scheinbar harmlose Wünsche, die kumuliert das Projekt entgleisen lassen. Gegenmittel sind disziplinierte Backlog-Pflege, transparente Burn-Down-Metriken und die vertragliche Pflicht, Auswirkungen in Zeit und Geld vor Umsetzung zu bestätigen. Drittens droht in verteilten Setups das 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.

Im Grenzbereich Dienst-/Werkvertrag lauert schließlich die Gefahr der falschen Erwartung. Auftraggeber rechnen mit „Fehlerbehebung inklusive“, obwohl nur Time & Material für Tätigkeiten vereinbart ist; Auftragnehmer kalkulieren knapp, obwohl Abnahmelogik und Mängelbeseitigung gesetzlich vorgezeichnet sind. Transparenz in den ersten Seiten des Vertrags – „Diese Leistungen sind werkvertraglich“, „jene dienstvertraglich“ – reduziert Missverständnisse. Wer zudem früh die Kündigungsrechte adressiert, vermeidet harte Brüche. Im Werkrecht existiert das freie Kündigungsrecht des Bestellers (§ 648 BGB); die Vergütung bis dahin sowie die Ersparnisse sind zu saldieren. Im Dienstvertrag greift die ordentliche Kündigung nach Frist, die ökonomisch besser steuerbar ist, wenn Mindestlaufzeiten und Kündigungsfenster klug gewählt sind.

Einordnung für die Suchintention: der „Unterschied Werk-/Dienstvertrag“ am Beispiel auf einen Blick

Der gesuchte Unterschied lässt sich exemplarisch so fassen: Ein „Managed-Hosting & Support“-Vertrag ist ein Dienstvertrag; geschuldet sind Betriebsleistungen, Reaktionszeiten und Sorgfalt. Eine „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 Dienstvertrag; die Qualität bemisst sich an der Beratungsleistung, nicht an einem fixen KPI-Erfolg. Ein „Fein-Tuning eines Modells auf Ziel-Metrik Z auf Testset T“ ist Werkvertrag; der messbare Zielerfolg steht im Zentrum. Ein „Port auf Plattform P mit Performance-Budgets“ ist Werkvertrag; ein „Post-Launch-Balancing-Support“ typischerweise Dienstvertrag. Genau diese Lesart beantwortet die Suchintention: Der Vergleich gelingt nicht über Schlagworte, sondern über das, was objektiv geprüft und abgenommen werden kann.

Fazit mit leiser Handlungsaufforderung

Die Abgrenzung „Werkvertrag vs Dienstvertrag“ entscheidet über den Projekterfolg, weil sie Fälligkeit, Abnahme, Mängelrechte, Haftung und Vergütung strukturiert. In Software-, KI- und Games-Vorhaben empfiehlt sich eine bewusste Hybrid-Architektur: werkvertragliche, abnahmefähige Deliverables dort, wo Spezifikation und Akzeptanzkriterien klar definiert sind; dienstvertragliche SLAs dort, wo Betrieb, Forschung, Coaching oder reaktive Leistungen im Vordergrund stehen. Wer die Linien in Definitionen, Mitwirkung, Change-Verfahren, Vergütungslogik, IP-Rechten und Haftung konsequent durchzieht, vermeidet die üblichen Reibungsverluste und behält wirtschaftliche und rechtliche Kontrolle.

Lassen Sie sich beraten!

Author: Marian Härtel

Marian Härtel ist Rechtsanwalt und Fachanwalt für IT-Recht mit einer über 25-jährigen Erfahrung als Unternehmer und Berater in den Bereichen Games, E-Sport, Blockchain, SaaS und Künstliche Intelligenz. Seine Beratungsschwerpunkte umfassen neben dem IT-Recht insbesondere das Urheberrecht, Medienrecht sowie Wettbewerbsrecht. Er betreut schwerpunktmäßig Start-ups, Agenturen und Influencer, die er in strategischen Fragen, komplexen Vertragsangelegenheiten sowie bei Investitionsprojekten begleitet. Dabei zeichnet sich seine Beratung durch einen interdisziplinären Ansatz aus, der juristische Expertise und langjährige unternehmerische Erfahrung miteinander verbindet. Ziel seiner Tätigkeit ist stets, Mandanten praxisorientierte Lösungen anzubieten und rechtlich fundierte Unterstützung bei der Umsetzung innovativer Geschäftsmodelle zu gewährleisten.