Eine Standard-Freelancer-Vertragsvorlage, gedacht für ein Website-Redesign oder ein Marketing-Deliverable, lässt mehrere Dinge aus, die ein KI-Projekt konkret braucht. Wem gehören die Modellgewichte, die ein Freelancer auf Ihren Daten trainiert? Was passiert mit diesen Daten, sobald die Beauftragung endet? Was passiert, wenn der Ansatz, den der Freelancer in gutem Glauben vorgeschlagen hat, schlicht nicht gut genug performt, um ausgeliefert zu werden, ist das sein Problem oder Ihres? Das alles ist keine Rechtsberatung, holen Sie sich für alles Verbindliche eigenen rechtlichen Rat, aber hier ist die praktische Checkliste, die es sich lohnt durchzugehen, bevor ein KI-Freelancer startet, damit das Gespräch mit Ihrer Anwältin bei den richtigen Fragen beginnt.
Warum KI-Projektverträge mehr als eine Standardvorlage brauchen
Eine typische Freelancer-Vereinbarung geht von einem einigermaßen vorhersehbaren Verhältnis zwischen Aufwand und Ergebnis aus: Der Freelancer erledigt die definierte Arbeit, das Deliverable existiert oder nicht. KI-Arbeit bricht diese Annahme auf zwei konkrete Arten. Erstens wirft das entstehende Artefakt, ein trainiertes Modell, ein feinabgestimmtes System, ein Satz Embeddings oder Evaluationspipelines, Eigentumsfragen auf, die eine generische Klausel „Arbeitsergebnis gehört dem Kunden“ oft nicht klar löst. Zweitens tragen KI-Projekte echte Unsicherheit darüber, ob ein bestimmter technischer Ansatz die gewünschte Messlatte tatsächlich erreicht, was ein Vertrag mit festem Umfang und festem Deliverable schlecht handhabt, sofern diese Unsicherheit nicht vorab explizit adressiert wird.
IP und Eigentum: Modelle, Code und alles dazwischen
- Code und Infrastruktur, die der Freelancer für Sie schreibt, sollten Ihnen explizit übertragen werden, namentlich im Vertrag, nicht einer allgemeinen „gesamtes Arbeitsergebnis“-Klausel überlassen, die älter ist als KI-spezifische Artefakte.
- Trainierte oder feinabgestimmte Modellgewichte brauchen eine eigene Zeile: Gehören sie Ihnen vollständig, oder behält der Freelancer Rechte, den zugrunde liegenden Ansatz (nicht Ihre konkreten Gewichte oder Daten) bei künftigen Projekten wiederzuverwenden?
- Nutzt der Freelancer eigene, bereits bestehende Tools, Frameworks oder ein zuvor gebautes Basismodell, klären, was für dieses Projekt an Sie lizenziert wird und was bei ihm bleibt, damit später keine Abhängigkeit überrascht, die Ihnen gar nicht gehört.
- Auch regeln, was mit Zwischenartefakten passiert, Datenpipelines, Evaluationssets, Prompts, Skripten, nicht nur mit dem finalen Modell, denn diese tragen oft eigenständigen Wert.
Datenumgang und Vertraulichkeitsklauseln
KI-Projekte bedeuten fast immer, dass ein Freelancer Zugriff auf echte, mitunter sensible Unternehmens- oder Kundendaten erhält. Der Vertrag sollte festlegen, auf welche Daten zugegriffen werden darf, wie sie auf seiner Seite gespeichert und gesichert werden, was bei Ende der Beauftragung damit passiert (gelöscht? zurückgegeben? unter welchen Bedingungen behalten?), und explizit, ob aus der Arbeit mit Ihren Daten Gelerntes, Muster, Erkenntnisse, Techniken, bei anderen Kund:innen wiederverwendet werden darf. „Vertraulich“ als einzelnes Pauschalwort in einer Standardvorlage reicht dafür in der Praxis meist nicht aus.
Umfang und Zahlung: Meilensteine vs. reine Stundenabrechnung
Reine Stundenabrechnung legt das gesamte Zeitplan- und Budgetrisiko auf Sie und gibt dem Freelancer wenig Anreiz, den Umfang vorab eng zu definieren. Meilensteinbasierte Zahlung, gekoppelt an konkrete, definierte Deliverables, erzwingt vor Projektstart ein nützlicheres Gespräch: Wie sieht „fertig“ an jeder Stufe genau aus, und was passiert, wenn ein Meilenstein nachgebessert werden muss. Viele gut geführte Beauftragungen mischen beides, stundenweise für offene Recherche- oder Explorationsphasen, meilensteinbasiert für die Bauphase, sobald der Umfang klarer ist, aber diese Aufteilung sollte eine bewusste, im Vertrag festgehaltene Entscheidung sein, kein Standardfall.
Was passiert, wenn das Modell oder der Ansatz nicht funktioniert
Das ist die Klausel, die generische Verträge am häufigsten komplett auslassen, und genau die, die bei KI-Arbeit die meisten Streitfälle verursacht. Vorab schriftlich klären, was als vertragsgemäße Lieferung gilt, selbst wenn die Ergebnisse unterperformen (der vereinbarte Ansatz wurde kompetent gebaut und getestet, hat die Messlatte einfach nicht erreicht, das ist ein Projektrisiko, das beide Seiten von vornherein akzeptiert haben), gegenüber dem, was als tatsächliches Lieferversagen gilt (die vereinbarte Arbeit wurde nicht gemacht, es wurde abgekürzt oder Fähigkeiten falsch dargestellt). Ersteres sollte ein umfangsbezogenes Gespräch über nächste Schritte auslösen, möglicherweise einen Change Order, keinen Zahlungsstreit. Zweiteres ist ein völlig anderes Gespräch. Erfolgskriterien und eine Test-/Evaluationsmethode vorab, vor Projektstart, festzulegen, ist genau das, was diese Unterscheidung später sauber möglich macht.
Eine praktische Checkliste vor der Unterschrift
- Wem gehört der Code, und getrennt davon, wem gehören trainierte oder feinabgestimmte Modellgewichte, schriftlich, namentlich.
- Auf welche Daten greift der Freelancer zu, wie werden sie gesichert, und was passiert damit nach Ende der Beauftragung.
- Darf der Freelancer aus Ihren Daten oder Ihrem Projekt Gelerntes bei anderen Kund:innen wiederverwenden, und wenn ja, was genau.
- Wird stundenweise, meilensteinbasiert oder in einer definierten Mischung bezahlt, und was löst die Zahlung an jeder Stufe aus.
- Wie sieht Erfolg aus, definiert und messbar, vor Projektstart, damit „gut genug zum Ausliefern“ später keine subjektive Debatte wird.
- Was passiert, wenn der Ansatz diese Messlatte nicht erreicht: eine umfangsbezogene Iteration, ein Change Order, oder Grund für eine andere Lösung, im Voraus entschieden, nicht im Moment.
