Partner codet mit KI: Was in den Vertrag gehört

Programmiert Ihr Salesforce-Umsetzungspartner mit KI-Agenten, braucht der Vertrag Regeln für KI-Coding, die eine klassische Leistungsbeschreibung nicht abdeckt: welche Tools und Modellwege genutzt werden, welche Daten ins Modell dürfen, kein Produktionszugriff für Agenten, dasselbe Review für jede Zeile und wem Code gehört, den eine Maschine geschrieben hat. Verbieten würde ich KI-Coding nicht. Ich würde den Partner offenlegen lassen, wie er arbeitet, und das prüfbar machen. Heikel ist für Hersteller vor allem, was ein Agent lesen kann: Servicefälle, Händlerpreise und SAP-Zugangsdaten.

Warum braucht KI-Coding durch Partner eigene Klauseln?

Ein klassisches SOW (Statement of Work, die Leistungsbeschreibung) regelt Lieferumfang, Abnahme, Rechte und Vertraulichkeit. Stillschweigend geht es davon aus, dass Menschen des Partners den Code auf Rechnern des Partners geschrieben haben. Mit einem Coding-Agenten ändern sich drei Dinge.

Daten verlassen das Haus über einen neuen Kanal. Was der Agent liest, geht als Prompt an einen Modellanbieter. Ob der damit trainiert, hängt am Vertragstyp, nicht am Tool. Anthropic schreibt, dass es nicht mit Code oder Prompts trainiert, die unter kommerziellen Bedingungen an Claude Code gehen1 (Team, Enterprise, API); bei den Verbraucherplänen Free, Pro und Max hängt das Training an einer Nutzereinstellung. Kommerzielle Konten haben eine Standard-Aufbewahrung von 30 Tagen. Dazu speichert Claude Code Sitzungsprotokolle standardmäßig 30 Tage lokal im Klartext. Auf dem Laptop eines Entwicklers liegt also eine Kopie dessen, was der Agent gelesen hat.

Die Codemenge wächst schneller als die Review-Kapazität. Veracode hat im Bericht von 2026 die Sicherheits-Passrate von KI-generiertem Code2 gemessen. Getestet wurden reine Modelle ohne Tooling und ohne menschliches Review. Das Review ist die Kontrolle, also gehört es in den Vertrag.

56 %

durchschnittliche Sicherheits-Passrate für KI-generierten Code

30 %

Passrate für Java, den nächsten Verwandten von Apex

Die Rechtelage wird unscharf. Laut CMS3 ist vollständig von KI erzeugter Code nach deutschem Recht gemeinfrei, weil nur ein Mensch Urheber sein kann, und die AGB des Anbieters ändern daran nichts. Und die Zusagen des Anbieters gelten seinem eigenen Kunden. Als Anthropic im Dezember 2023 seine Urheberrechts-Freistellung4 einführte, versprach es, „our customers“ zu verteidigen. Im Partnerprojekt ist dieser Kunde der Partner, nicht Sie.

Welche Regeln für KI-Coding gehören in den Partnervertrag?

Diese neun Punkte nutze ich als Prüfliste für Leistungsbeschreibungen und Rahmenverträge. Nicht jedes Programm braucht alle in derselben Tiefe.

1. Offenlegung von Tools und Modellwegen. Der Partner nennt jedes Coding-Tool, den Modellanbieter, den Weg (direkte API, Cloud-Anbieter oder ein Salesforce-Werkzeug wie Agentforce Vibes) und den Vertragstyp. Änderungen kündigt er vor dem Einsatz an. Der Weg entscheidet, wo Daten verarbeitet werden: Anthropics eigene API bietet als Inferenzregion nur „us“ oder „global“5, bei Amazon Bedrock folgt die Region dem Endpunkt. OpenAI bietet seit Februar 2025 europäische Datenresidenz für API-Projekte6.
2. Nur kommerzielle Konten. Keine privaten Pro- oder Max-Konten im Kundenprojekt. Stellen Sie die Lizenzen selbst, bestimmen Sie auch die Einstellungen, wie in warum Kunden ihre DevOps-Tools selbst besitzen sollten beschrieben. Wer die Tokens bezahlt, ist eine eigene Verhandlung, siehe KI-Coding-Kosten im Salesforce-Projekt.
3. Datenklassen für den Agentenkontext. Code und Metadaten dürfen ins Modell. Produktivdaten, personenbezogene Daten, Händlerpreislisten, Konditionen und Kundendaten aus Servicefällen nicht. Agenten arbeiten in Scratch Orgs oder Developer-Sandboxes mit anonymisierten Daten. Eine Full-Copy-Sandbox zählt als Produktivdaten.
4. Kein Produktionszugriff für Agenten. Deployments nach Produktion laufen über die Pipeline mit menschlicher Freigabe. Salesforce erlaubt, Agentforce Vibes für eine Produktions-Org im Setup abzuschalten7, und der Salesforce DX MCP Server8 erreicht nur Orgs, die beim Start ausdrücklich freigegeben sind. Dieser Server erreicht am 2. November 2026 das Ende seiner Laufzeit, siehe Ende des Salesforce DX MCP Server. Zugangsdaten wie der SAP-Integrationsnutzer bleiben außer Reichweite des Agenten; Anthropics Leitfaden für sicheren Betrieb9 beschreibt einen Proxy, der sie einsetzt, ohne dass der Agent sie je sieht.
5. Dasselbe Review für jede Zeile. Jeder Pull Request hat einen benannten menschlichen Verantwortlichen, der KI-Anteil steht in der Beschreibung, und die Pipeline-Prüfungen gelten unverändert. Salesforce formuliert es in der eigenen Vibes-Dokumentation so: „Permission modes protect your filesystem. Code review protects your application.“10 Wie Reviews ablaufen, steht in warum Pull-Request-Reviews Pflicht sind, worauf es bei KI-Code ankommt, in KI-generierten Salesforce-Code prüfen.
6. Regeldatei in Ihrem Repository. Konventionen für Agenten wie API-Version, Sharing und Teststandards stehen in einer KI-Regeldatei in Ihrem Repository und gelten für jeden Partner. Mehr dazu in eine KI-Regeldatei für das Salesforce-Repository.
7. Rechte und Lizenzen. Die Rechteklausel erfasst menschliche und KI-generierte Anteile, und der Partner dokumentiert, wo KI eingesetzt wurde, was CMS für spätere Due-Diligence-Prüfungen empfiehlt. Fragen Sie, wie mit Treffern aus öffentlichem Code umgegangen wird: GitHub Copilot kann Vorschläge blockieren, die öffentlichem Code entsprechen11, oder sie mit Lizenzhinweis anzeigen.
8. Die Haftung bleibt, wo sie war. Der Partner steht für seine Lieferungen ein, egal welches Werkzeug sie erzeugt hat. Gewährleistung, Abnahmekriterien und Mängelbehandlung gelten wie bisher, ohne Ausnahme für „von KI erzeugt“. CMS warnt, dass Freistellungen der Anbieter oft weitreichende Ausschlüsse haben; sie ersetzen die des Partners also nicht.
9. Nachweise und Ausstieg. Sie dürfen Tool-Liste, Kontenliste und relevante Einstellungen zu Beginn und einmal im Jahr anfordern. Zum Ende des Auftrags bestätigt der Partner, dass lokale Protokolle und Caches mit Ihrem Code gelöscht sind.

Beispiel: zwei Partner, ein Fragebogen

Nehmen wir einen Maschinenbauer mit Sales Cloud, Service Cloud und Field Service für den Außendienst auf einer Org, SAP als ERP und zwei Partnern. Partner A baut mit sechs Entwicklern das Händlerportal und die Serviceprozesse, Partner B mit drei Entwicklern die SAP-Schnittstelle. Alle Details sind Annahmen, die das Vorgehen zeigen sollen.

Bevor die Leistungsbeschreibungen verlängert werden, schickt die IT beiden Partnern einen einseitigen Fragebogen: Tools, Modellwege, Kontotypen, Sandboxes mit echten Daten, wer welche Zugangsdaten hat. Die Antworten im Szenario:

• Partner A nutzt einen Coding-Agenten mit Firmenkonto, zwei Entwickler weichen aber gelegentlich auf private Konten aus, wenn das Firmenkontingent aufgebraucht ist.
• Der Agent von Partner A arbeitet in einer Full-Copy-Sandbox mit echten Servicefällen samt Kundennamen und Seriennummern der Maschinen.
• Partner B hat das Passwort des SAP-Integrationsnutzers in einer lokalen Datei im Projektordner, den der Agent lesen kann.
• Partner B lässt Vorschläge zu, die öffentlichem Code entsprechen, und hat die Lizenzhinweise nie angesehen.

Keiner dieser vier Befunde wäre im Code-Review aufgefallen, denn der Code selbst ist in Ordnung. Die Lösung ist eine zweiseitige Anlage zum Rahmenvertrag mit den neun Punkten oben, dazu einige Wochen, um Partner A auf eine Developer-Sandbox mit anonymisierten Daten umzustellen und die Zugangsdaten von Partner B in den Tresor des Kunden zu verlegen. Für neue Leistungsbeschreibungen gilt die Anlage automatisch.

Was ändert sich, wenn mehrere Partner an einer Org arbeiten?

Agenten machen Änderungen billig, auch Änderungen an Objekten, die ein anderer Stream verantwortet. Ein Agent, der bei einer Story fürs Händlerportal eine Validierungsregel auf dem Account „repariert“, weiß nicht, dass der Service-Stream davon abhängt. Damit wird die Object Ownership Matrix wichtiger. Eine CODEOWNERS-Datei im Repository fragt den verantwortlichen Stream automatisch als Reviewer an, wenn ein Pull Request seine Objekte berührt.

Die Anlage sollte für alle Partner identisch sein. Bringt jeder Partner eigene KI-Regeln mit, wird stillschweigend die strengste oder die lauteste zu Ihrem Standard, und Partner lassen sich schwerer vergleichen. Damit die Regeln nach einigen Monaten nicht verwässern, braucht es mehr als den Vertrag: Pipeline, Review und einen festen Termin für neue Fälle, beschrieben in Reinforcement: Standards bei Partnern verankern. Diese Regeln auf Kundenseite festzulegen, gehört zu meiner Arbeit in der Partnersteuerung.

Einen Fragebogen an jeden Partner schicken

1. 01

   Fragebogen verschicken

   An jeden Partner, auch an kleine, die nur eine Schnittstelle liefern.

2. 02

   Daten einteilen

   In das, was ein Agent sehen darf, und das, was nicht, gemeinsam mit Ihrem Datenschutzbeauftragten.

3. 03

   Anlage entwerfen

   Mit Ihrer Rechtsabteilung, angehängt an den Rahmenvertrag, damit sie für jede Leistungsbeschreibung gilt.

4. 04

   Technisch durchsetzen

   Vibes für Produktion abgeschaltet, Deployments nur über die Pipeline, CODEOWNERS für gemeinsame Objekte.

5. 05

   Einmal im Jahr prüfen

   Tools, Tarife und Nutzungsbedingungen ändern sich schneller als Verträge.

Quellen11

1. 1nicht mit Code oder Prompts trainiert, die unter kommerziellen Bedingungen an Claude Code gehen (öffnet in einem neuen Tab)code.claude.com
2. 2Sicherheits-Passrate von KI-generiertem Code (öffnet in einem neuen Tab)veracode.com
3. 3CMS (öffnet in einem neuen Tab)cms.law
4. 4Urheberrechts-Freistellung (öffnet in einem neuen Tab)anthropic.com
5. 5„us“ oder „global“ (öffnet in einem neuen Tab)platform.claude.com
6. 6europäische Datenresidenz für API-Projekte (öffnet in einem neuen Tab)openai.com
7. 7Agentforce Vibes für eine Produktions-Org im Setup abzuschalten (öffnet in einem neuen Tab)developer.salesforce.com
8. 8Salesforce DX MCP Server (öffnet in einem neuen Tab)developer.salesforce.com
9. 9Leitfaden für sicheren Betrieb (öffnet in einem neuen Tab)code.claude.com
10. 10„Permission modes protect your filesystem. Code review protects your application.“ (öffnet in einem neuen Tab)developer.salesforce.com
11. 11Vorschläge blockieren, die öffentlichem Code entsprechen (öffnet in einem neuen Tab)github.blog