Ein KI-Entwicklungsvertrag ist der rechtliche Rahmen, der regelt, wie ein KI-System gebaut, geliefert und bezahlt wird — und wenn die Entwicklung offshore stattfindet, wird er zum wichtigsten Risikokontrollmechanismus des gesamten Engagements. Nach der Auswahl eines KI-Entwicklungspartners ist der Vertrag der Ort, an dem Ihre Evaluierungsergebnisse zu durchsetzbaren Verpflichtungen werden: wem das Modell gehört, was das System nachweisbar leisten muss, wohin Ihre Daten gehen dürfen und wer zahlt, wenn etwas schiefgeht.
Anders als eine konventionelle Softwarevereinbarung regelt ein KI-Entwicklungsvertrag Artefakte, die traditionelle Entwicklung nie hervorgebracht hat — trainierte Gewichte, feinabgestimmte Modelle, Evaluierungsdatensätze, Prompt-Pipelines — sowie Verpflichtungen, die sich nicht durch bloße Prüfung verifizieren lassen. Dieser Leitfaden behandelt die zehn wichtigsten Klauseln, eine Verantwortungsmatrix zu ihrer Zuteilung, die Warnsignale für vertragliche Unklarheit und eine Checkliste für die Zeit vor der Unterzeichnung.
Kernpunkte
- Ein Offshore-KI-Entwicklungsvertrag ist ein Stack — MSA, SOW, DPA, Sicherheitsanlagen — kein einzelnes Dokument; die meisten Lücken entstehen an den Nahtstellen dazwischen.
- KI-spezifisches Risiko konzentriert sich auf vier Bereiche: IP- und Modelleigentum, Datenverarbeitung, Abnahmekriterien für probabilistische Ergebnisse und Haftung für das Verhalten von Drittanbieter-Modellen.
- “Funktionierende Software” ist kein Abnahmekriterium — KI-Verträge brauchen messbare Benchmarks und ein definiertes Testprotokoll.
- Binden Sie Zahlungsmeilensteine an Abnahmeereignisse, nicht an Kalenderdaten.
- Die meisten Vertragsfehler sind Unklarheitsfehler: vage IP-Formulierungen, Deemed Acceptance, unbegrenzte “angemessene Bemühungen”.
Was ist ein KI-Entwicklungsvertrag?
Ein KI-Entwicklungsvertrag ist eine kommerzielle Vereinbarung, die definiert, wie ein KI-System — oder die KI-Komponenten eines größeren Systems — definiert, gebaut, geliefert und bezahlt wird. Er ist selten ein einzelnes Dokument: Die meisten Engagements stapeln einen Master Services Agreement (MSA) für die rechtlichen Bedingungen, Statements of Work für den Projektumfang, eine Datenverarbeitungsvereinbarung (DPA) bei personenbezogenen oder regulierten Daten sowie Sicherheits- oder Vertraulichkeitsanlagen.
Drei Eigenschaften unterscheiden eine KI-Entwicklungsvereinbarung von einem Standard-Softwarevertrag. Die Liefergegenstände umfassen Artefakte, die konventionelle Verträge nie vorsahen — trainierte Gewichte, Fine-Tune-Varianten, Evaluierungsdatensätze, Prompt-Pipelines. Die Leistung ist probabilistisch — ein Modell, das in der Demo überzeugt, kann an Ihrer Datenverteilung scheitern; “es funktioniert” kann daher kein Abnahmestandard sein. Und das System hängt von Drittanbieter-Grundlagen ab — Foundation Models, APIs, vortrainierte Komponenten — deren Lizenzen und Verhalten teilweise außerhalb der Kontrolle beider Parteien liegen.
Eine Unterscheidung hält den Vertrag sauber: Er regelt was geliefert wird und wer welches Risiko trägt, während der KI-Softwareentwicklungslebenszyklus regelt, wie die Arbeit ausgeführt wird. Öffentliche Beschaffungsleitfäden sehen das genauso — die Übersicht des Australian Government Solicitor über KI-Modellvertragsklauseln argumentiert, dass KI-Vereinbarungen Klauseln brauchen, die Daten, IP, Verantwortlichkeit und regulatorische Exposition gezielt adressieren.
Warum Offshore-KI-Entwicklung zusätzliche vertragliche Schutzvorkehrungen braucht
Jedes Risiko eines KI-Vertrags existiert auch im Inland. Offshore-Lieferung schafft keine neuen Risikokategorien — sie verstärkt vier bestehende:
- Durchsetzbarkeit. Ein Urteil Ihrer Heimatgerichte lässt sich gegen einen Anbieter, dessen Vermögenswerte anderswo liegen, schwer vollstrecken — darum tragen Governing Law und Streitbeilegung offshore mehr Gewicht.
- Datenresidenz und Fernzugriff. Ihre Daten überschreiten Grenzen, sobald ein Offshore-Ingenieur einen Datensatz öffnet — und das “Ansehen” von Daten aus dem Ausland gilt in den meisten Regimen als Übertragung. Der Vertrag muss sagen, wo Daten liegen, wer sie erreichen darf und über welchen Rechtsmechanismus.
- Unterschiedliche IP-Regime. Eine Klausel, die Rechte nach Ihrem Recht sauber überträgt, kann nach dem Recht des Anbieters anders wirken — besonders die Kette, die Rechte von den Ingenieuren zum Anbieter und weiter zu Ihnen bewegt.
- Subunternehmer-Sichtbarkeit. Offshore-Anbieter binden regelmäßig Subprozessoren ein, die Sie nie kennenlernen; ohne vertragliches Genehmigungsrecht wächst Ihre Lieferkette unsichtbar.
Nichts davon macht Offshore-KI-Entwicklung unsicher — es bedeutet, dass der Vertrag oft Ihre einzige durchsetzbare Kontrolle ist, sobald Daten und Code Grenzen überschreiten. Diese Schutzvorkehrungen sind Standard in ausgereiften Offshore-Softwareentwicklungsdiensten; was KI ändert, ist das geschützte Asset — Modelle, Daten, abgeleitetes IP — und die weniger vertrauten Fehlerbilder.
10 wesentliche Klauseln in einem Offshore-KI-Entwicklungsvertrag
Die Klauseln folgen der Reihenfolge der meisten Verträge: Umfang, dann Abnahme und Eigentum, dann Risikoverteilung, dann Ausstieg.
1. Umfang, Liefergegenstände & das Statement of Work
Jeder Offshore-KI-Entwicklungsvertrag steht und fällt mit seinem Statement of Work. Der MSA setzt den rechtlichen Kontext; das SOW definiert die Transaktion — und in KI-Projekten versteckt sich die Unklarheit in der Lieferliste. Ein gut formuliertes KI-Entwicklungs-SOW zählt Artefakte auf, nicht Aktivitäten: Quellcode, Trainings- und Fine-Tuning-Pipelines, Modellgewichte und Checkpoints, Evaluierungs-Harnesses und -Datensätze, Dokumentation und Deployment-Definitionen. Es nennt auch, was außerhalb des Umfangs liegt — Produktionsmonitoring, Retraining, Annotation — damit beide Seiten dasselbe Engagement bepreisen. Offshore kommen zwei Punkte hinzu: die Arbeitssprache der Liefergegenstände festlegen und die Abnahmeumgebung bestimmen — wessen Infrastruktur, wessen Daten — denn “geliefert” bedeutet über zwölf Zeitzonen hinweg Unterschiedliches.
2. Abnahmekriterien & Evaluierungs-Benchmarks
Bei deterministischer Software kann Abnahme eine Feature-Checkliste sein. Abnahmekriterien für KI-Projekte müssen stattdessen messbare Tests definieren: Accuracy- oder Task-Erfolgsschwellen auf einem vereinbarten Evaluierungsdatensatz, Latenz unter spezifizierter Last, Qualitätsgrenzen für generative Ausgaben (rubric-bewertet oder stichprobenartige menschliche Prüfung) und Verhalten bei aufgezählten Edge Cases. Die Klausel sollte auch den Eval-Datensatz festschreiben — wer ihn liefert, ob er eingefroren ist und was passiert, wenn sich die reale Datenverteilung nach Abnahme verschiebt. Verhandlungshinweis: Begrenzen Sie die Nachbesserungsrunden und definieren Sie den Ausstieg, falls die Abnahme nie erreicht wird — Teilerstattung, Kündigungsrecht oder Umstellung auf Time-and-Materials. Ohne diesen Ausstieg wird das Abnahmeversagen zur unendlichen Verpflichtung für beide Seiten.
3. Eigentum an geistigem Eigentum
IP-Eigentum in der KI-Entwicklung gliedert sich in drei Schichten, und der Vertrag sollte jede benennen. Vorbestehendes IP — Bibliotheken, Tools und interne Modelle jeder Partei — bleibt erhalten und wird nur nach Bedarf lizenziert. Neu entstehendes IP — der für Sie erstellte Code, trainierte Gewichte, Fine-Tunes, Prompts, Eval-Sets und Dokumentation — geht typischerweise mit Zahlung an den Kunden. Eingebettetes Drittanbieter-IP — Open-Source-Komponenten und Foundation Models — unterliegt eigenen Lizenzen (Klausel 6). Offshore kommt eine Falte hinzu: Die Übertragung muss nach lokalem Recht des Anbieters wirksam sein, und Arbeitsverträge müssen Rechte von den Ingenieuren zum Anbieter und weiter zu Ihnen übertragen — die IP-”Eigentumskette”. Prüfen Sie auch License-back-Klauseln: Wiederverwendung “allgemeiner Fähigkeiten und Know-how” ist angemessen; Rechte an Ihrem trainierten Modell oder Ihren Daten nicht.
4. Datenrechte & grenzüberschreitende Datenverarbeitung
Diese Klausel beantwortet vier Fragen: welche Daten der Anbieter verarbeiten darf, zu welchen Zwecken, wo und durch wen. Bei personenbezogenen Daten legen Sie Controller-/Processor-Rollen fest und schließen eine DPA ab. Sie sollte Umfang, Sicherheitsmaßnahmen, Subprozessor-Zustimmung, Meldung von Vorfällen innerhalb eines definierten Fensters (24–72 Stunden ist ein üblicher Vertragswert) sowie Rückgabe oder Löschung bei jedem Meilenstein abdecken — nicht nur bei Vertragsende. Grenzüberschreitende KI-Datenverarbeitung fügt die Übertragungsebene hinzu: Benennen Sie den Mechanismus — Standardvertragsklauseln für DSGVO-Daten — legen Sie die Jurisdiktionen offen, die Training und Inferenz hosten, und behandeln Sie Fernzugriff explizit: Offshore-Ingenieure, die EU- oder US-Daten ansehen, bleiben in den meisten Regimen eine Übertragung. Die ICO-Leitlinie zu KI-Verträgen und Datenverantwortlichkeiten gegenüber Dritten ist eine praktische Referenz für die Zuteilung dieser Verantwortlichkeiten. Eine kostenlose Ergänzung: Verbieten Sie dem Anbieter, Ihre Daten zum Trainieren von Modellen für andere Kunden zu verwenden.
5. Vertraulichkeit, Sicherheit & Zugangskontrollen
Generische NDA-Sprache unterschätzt KI-Engagements, weil die Geheimnisse ungewöhnlich sind — Trainingsdaten, Modellgewichte, Eval-Sets, Prompt-Logik — Assets, deren Leck nicht “zurückgegeben” werden kann. Führen Sie sie explizit als vertrauliche Materialien auf. Bei der Sicherheit sollte eine Anlage Umgebungstrennung abdecken (Anbieterumgebungen erreichen keine Produktionsdaten), Least-Privilege-Zugang mit benannten Konten und MFA, Protokollierungspflichten — wer was berührt hat, wie lange aufbewahrt, von wem einsehbar — und Meldemechanismen passend zu Klausel 4. Für Offshore-Lieferung ergänzen Sie Screening-Standards für Personal, eine Key-Personnel-Liste und Beschränkungen für Subunternehmen ohne Zustimmung.
6. Drittanbieter-KI-Modelle, Lizenzen & Leistungszusagen
Kaum ein produktives KI-System wird von Grund auf gebaut — es steht auf Foundation Models, APIs und vortrainierten Komponenten, deren Bedingungen in Ihren Vertrag fließen, ob sie jemand hinschreibt oder nicht. Diese Klausel macht den Fluss explizit. Benennen Sie die genutzten Drittanbieter-Modelle und -Provider. Entscheiden Sie, wer die Providerbeziehung und API-Konten hält — konten in Kundenhand bewahren Portabilität. Legen Sie fest, wie Providerbedingungen beide Parteien binden (API-Nutzungsbeschränkungen, Datennutzungsrichtlinien, Ausgabebeschränkungen) und setzen Sie Open-Source- oder Open-Weights-Lizenzpflichten fest, die von permissiv bis nicht-kommerziell reichen. Dann der Wandel: Provider deprezieren Versionen nach eigenem Zeitplan — definieren Sie, wer die Roadmap verfolgt, wer Migration bezahlt und in welchem Zeitfenster. Leistungszusagen gehören ebenfalls hierher: Für proprietäre Komponenten kann ein Anbieter ehrlich nur eine Bandbreite zusagen — dokumentierte Provider-Benchmarks plus eigene Eval-Ergebnisse — und die Klausel sollte sagen, welcher Standard für welche Komponente gilt.
7. Haftung, Freistellung & Risikoverteilung
Hier bepreisen die Parteien die Risiken, die frühere Klauseln identifiziert haben. Zuerst der Gewährleistungsumfang: Standard-Nichtverletzungs-Garantien plus eine KI-gemäße Leistungsgarantie — eine begrenzte Zusage, dass das System die Benchmarks aus Klausel 2 erfüllt, mit Nachbesserungspflicht. Probabilistische Systeme können ehrlich keine perfekte Ausgabe garantieren. Bei der Haftung ist eine Obergrenze an gezahlte Gebühren Standard — verhandeln Sie Ausnahmen für IP-Verletzung, Datenverletzung und Missbrauch vertraulicher Informationen. Die Freistellung sollte Drittansprüche aus Trainingsdaten-Verletzungen oder Lizenzverstößen in anbietergewählten Komponenten abdecken.
Die schwierigere Kante ist Autonomie — die Analyse von Mayer Brown zu vertraglichen Risiken in agentic-AI-Implementierungen zeigt, wo Freistellungsstrukturen belastet werden, wenn KI von der Ergebnisproduktion zum Handeln übergeht. Wenn Ihr System auf die Welt einwirkt — agentische Workflows, automatisierte Entscheidungen — sprechen Sie diese Verteilung in der Verhandlung explizit an.
8. Preise, Zahlungsmeilensteine & Änderungskontrolle
Strukturieren Sie Zahlungen um Abnahmeereignisse, nicht Kalenderdaten: Startzahlung, Meilensteine an die Abnahme aus Klausel 2, Schlusszahlung bei Übergabe — das richtet den Anbieteranreiz an nachweisbarer Lieferung aus. Änderungskontrolle ist ebenso wichtig: KI-Projekte entdecken ständig Umfang, verlangen Sie schriftliche Change Requests mit Kosten- und Terminbewertung, genehmigt vor Arbeitsbeginn — sonst wird Umfangsentdeckung zum Abrechnungsstreit. Offshore-Spezifika: Währung und Devisenhandling, Quellensteuer-Verteilung und der Satz für Post-Abnahme-Arbeit.
9. Laufzeit, Kündigung & Exit-Unterstützung
Kündigungsrechte zählen nur, wenn der Ausstieg durchführbar ist. Decken Sie Kündigung aus wichtigem Grund (wesentliche Verletzung mit Heilungsfrist) und aus Convenience (Frist plus Zahlung für abgenommene Arbeit) ab; das Exit-Paket bei jeder Kündigung — Lieferung aller Arbeitsergebnisse bis dahin, einschließlich unfertiger Modellgewichte, Trainingscode, Eval-Sets und Dokumentation in nutzbarer Form; ein bezahltes Knowledge-Transfer-Fenster an Ihr Team oder einen Nachfolgeanbieter; und das Fortbestehen von IP-Übertragung, Vertraulichkeit und Datenlöschungspflichten. Für hochabhängige Engagements erwägen Sie Quellcode- und Modell-Escrow — oder verlangen Sie, dass alle Artefakte von Tag eins an in Repositories liegen, die Sie kontrollieren. Die billigste Exit-Versicherung ist, dass der Anbieter nie alleinige Verwahrung Ihrer Assets hat.
10. Governing Law, Streitbeilegung & regulatorische Compliance
Grenzüberschreitende Durchsetzbarkeit ist das Offshore-Problem in einer Zeile: Ein Urteil Ihrer Heimatgerichte kann dort, wo die Vermögenswerte des Anbieters liegen, nicht vollstreckbar sein. Wählen Sie das anwendbare Recht bewusst und bevorzugen Sie Schiedsverfahren (ICC, SIAC o. ä.), wo grenzüberschreitende Durchsetzung zählt — Schiedssprüche reisen unter dem New Yorker Übereinkommen deutlich besser als Gerichtsurteile. Dann die Compliance-Ebene: Exportkontroll-Exposition wo anwendbar; Zuteilung von Pflichten unter aufkommender KI-Regulierung — der EU AI Act etwa teilt Verantwortlichkeiten zwischen Providern und Betreibern auf, also sollte der Vertrag sagen, welche Partei welche Rolle spielt; und eine Change-in-Law-Klausel, die neue Anforderungen in den Umfang aufnimmt.
Beispielhafte Verantwortungsmatrix für Offshore-KI-Verträge
Die Klauseln definieren, was der Vertrag sagt; die Matrix definiert, wer was tut. Prüfen Sie Ihren SOW-Entwurf dagegen — eine Zeile mit zwei leeren Spalten ist eine Lücke, keine geteilte Verantwortung.
| Vertragsbereich | Kundenverantwortung | Anbieternverantwortung |
|---|---|---|
| Trainings- & Testdaten | Daten und Nutzungsrechte bereitstellen | Verarbeitung per DPA; keine Sekundärnutzung |
| Evaluierungsdatensatz | Eval-Set genehmigen; Edge Cases liefern | Harness bauen; Ergebnisse berichten |
| Drittanbieter-Modellkonten | Providerkonten und API-Keys halten | Innerhalb der Providerbedingungen implementieren |
| Sicherheit & Zugang | Scoped Access gewähren; Logs prüfen | Trennung, Logging, Personal-Screening |
| IP-Übertragung | Meilensteine bezahlen (Übertragungs-Trigger) | Eigentumskette sichern; Übertragung ausführen |
| Subprozessor-Änderungen | Genehmigen/ablehnen im Zeitfenster | Subs offenlegen; Pflichten weiterreichen |
| Vorfallmeldung | Reaktionskontakte stellen | Innerhalb SLA melden |
| Modell-Deprecation | Migrationsfenster genehmigen | Roadmap verfolgen; Migration vorschlagen |
| Exit-Übergabe | Nachfolgeumgebung bereitstellen | Artefakte plus Knowledge Transfer liefern |
Häufige Warnsignale in Vertragsverhandlungen
Das sind vertragliche Signale, keine Anbieterbewertung — jedes ist Formulierung, die Risiko durch Unklarheit statt durch Vereinbarung auf Sie abwälzt.
- “IP geht bei vollständiger Zahlung über” ohne IP-Definition. Umfasst das Gewichte, Eval-Sets, Dokumentation, Prompts? Endet das Engagement bei 80% Zahlung — geht dann irgendetwas über?
- Deemed Acceptance. “Gilt als abgenommen, wenn nicht innerhalb von N Tagen beanstandet” bestraft die Partei, die am wenigsten schnell testen kann — gefährlich, wenn Abnahme Evaluierungsläufe erfordert.
- “Wirtschaftlich angemessene Bemühungen” statt messbarer Zusagen. Der Anbieter verspricht Bemühung, nie Ergebnis — und Bemühung lässt sich später kaum bestreiten.
- Haftungsobergrenzen unter Ihrem Datenrisiko. Ein Cap von einem Monatsgehalt bedeutet wenig gegen einen Verstoß gegen Ihren gesamten Trainingskorpus.
- Kein Genehmigungsrecht für Subprozessoren. Die Stelle, die Ihre Daten verarbeitet, kann am Ende eine sein, die Sie nie bewertet haben.
- Kündigungsrechte ohne Übergabepflicht. Sie können den Vertrag verlassen, aber Modelle, Daten und Dokumentation nicht mitnehmen — ein Recht nur auf dem Papier.
- Stille Verlängerung mit Preissteigerungen. Das SOW verlängert sich und Sätze steigen ohne Genehmigungsereignis — entdeckt bei der Rechnung.
Checkliste für den Offshore-KI-Entwicklungsvertrag vor Unterzeichnung
Gehen Sie den Entwurf vor der Unterschrift anhand dieser Checkliste durch. Jede Zeile muss ein Dokument oder eine Klauselreferenz liefern — was nur mündlich bestätigt wurde, steht noch nicht im Vertrag.
| Vertragselement | Was prüfen | Erforderlicher Nachweis |
|---|---|---|
| SOW & Liefergegenstände | Modellartefakte und Out-of-Scope aufgelistet | Signierter SOW-Anhang |
| Abnahmekriterien | Messbare Schwellen, Protokoll, fixer Eval-Datensatz | Benchmark-Dokument |
| IP-Eigentum | Neues IP umfasst Gewichte, Fine-Tunes, Prompts | Übertragungsklausel gültig nach Anbieterrecht |
| Datenverarbeitung | Rollen, Übertragungsmechanismus, Breach-SLA | Ausgefertigte DPA plus Subprozessor-Liste |
| Drittanbieter-Modelle | Providerbedingungen weitergegeben; Update-Zuständigkeit | Lizenz- oder Modellanhang |
| Sicherheitskontrollen | Trennung, Zugangsprotokoll, Meldefenster | Sicherheitsanlage |
| Garantien & Haftung | Begrenzte Garantie; Breach-/IP-Ausnahmen | Haftungsklausel |
| Zahlungsmeilensteine | An Abnahmeereignisse gebunden | Meilensteinplan |
| Kündigung & Exit | Exit-Paket, Knowledge Transfer, Fortbestand | Exit-Assistance-Klausel |
| Governing Law | Durchsetzbarer Gerichtsstand; Schiedsverfahren | Streitbeilegungsklausel |
Fazit
Ein Offshore-KI-Entwicklungsvertrag ist Risikokontrolle, die schriftlich festgehalten wird, bevor das Risiko existiert. Die zehn Klauseln folgen einer Logik: Liefergegenstände präzise definieren, Abnahme messbar machen, IP- und Dateneigentum explizit halten, das verbleibende Risiko ehrlich bepreisen und sich einen durchsetzbaren Ausstieg lassen. Was Sie nicht in den unterschriebenen Dokumenten zeigen können, ist eine Annahme, keine Vereinbarung.
Dieselbe Disziplin — definierte Abnahme, explizites Eigentum, kontrollierte Datenbehandlung — ist auch, wie ausgereifte Delivery-Teams das Engagement selbst strukturieren. HDWEBSOFTs KI-Entwicklungsdienste sind genau um diese Kontrollen gebaut, von der Deliverable-Definition auf SOW-Ebene bis zur meilensteinbasierten Abnahme. Wenn Sie ein Offshore-KI-Engagement vorbereiten und besprechen möchten, wie ein solches Projekt abgegrenzt und geliefert wird, kontaktieren Sie unser Team — wir zeigen Ihnen gern, wie wir es strukturieren.
FAQ
Was sollte ein KI-Entwicklungsvertrag enthalten?
Mindestens: einen MSA mit dem rechtlichen Rahmen; ein SOW, das Liefergegenstände definiert — Modellartefakte, nicht nur Code; messbare Abnahmekriterien; IP-Eigentum über trainierte Gewichte und Fine-Tunes; eine DPA für grenzüberschreitende Daten; Sicherheitsbedingungen; Lizenzen für Drittanbieter-Modelle; Haftung und Freistellung; meilensteinbasierte Zahlungen; und Kündigung mit durchsetzbarer Exit-Unterstützung.
Wem gehört das KI-Modell in einem ausgelagerten Entwicklungsprojekt?
Wem der Vertrag es zuschreibt — es gibt keinen verlässlichen Standard. Der Vertrag sollte vorbestehendes IP (verbleibt bei jeder Partei), neu entstehendes IP (Code, trainierte Gewichte, Fine-Tunes und Eval-Sets, die für Sie erstellt wurden — geht typischerweise mit Zahlung an den Kunden) und Drittanbieter-IP (Foundation Models und Open-Source-Komponenten unter eigenen Lizenzen) trennen. Prüfen Sie, ob die Übertragung auch nach lokalem Recht des Anbieters wirkt.
Was ist ein Statement of Work für KI-Entwicklung?
Das SOW ist das Projektdokument unter dem Rahmenvertrag, das die Transaktion definiert: aufgelistete Liefergegenstände — Quellcode, Trainings-Pipelines, Modellgewichte, Evaluierungs-Harnesses, Dokumentation — plus Abnahme-Benchmarks, Zeitplan, Preise und Out-of-Scope-Posten. Der häufigste Formulierungsfehler ist das Auflisten von Aktivitäten (“Modellentwicklung”) statt Artefakten (“trainierte Gewichte, die den definierten Benchmark erreichen”).
Wie sollte grenzüberschreitende Datenverarbeitung in einem Offshore-KI-Vertrag geregelt werden?
Durch eine Datenverarbeitungsvereinbarung, die Controller-/Processor-Rollen festlegt, erlaubte Zwecke definiert, den legalen Übertragungsmechanismus benennt — etwa Standardvertragsklauseln für DSGVO-Daten — Hosting-Jurisdiktionen offenlegt, Subprozessor-Zustimmung verlangt, ein Breach-Meldefenster setzt und Sekundärnutzung Ihrer Daten verbietet.
Was sind die größten vertraglichen Warnsignale beim Offshore-Outsourcing von KI-Entwicklung?
Undefinierte IP-Übertragung, Deemed-Acceptance-Klauseln, die ablaufen bevor realistisch getestet werden kann, “wirtschaftlich angemessene Bemühungen” statt messbarer Garantien, Haftungsobergrenzen unter Ihrem Datenrisiko, kein Subprozessor-Genehmigungsrecht, Kündigung ohne durchsetzbare Übergabe und stille Verlängerungen mit Preissteigerungen. Die Lösung ist immer dieselbe: Benennen Sie die Sache, setzen Sie die Zahl, verlangen Sie den Nachweis.
