Richtlinie für KI-Coding-Assistenten: Code-Klassen, Anbieterbedingungen, Lizenzen, AI Act

Was eine Richtlinie für KI-Coding-Assistenten regeln muss

Eine Richtlinie für KI-Coding-Assistenten sagt der Entwicklung, welchen Code sie welchem Werkzeug unter welchem Konto geben darf und wie generierter Code geprüft wird, bevor er ausgeliefert wird. Sie regelt vier Fragen: die Klassen von Code und die Werkzeuge, die jede Klasse erreichen darf, was die Bedingungen der Anbieter zu Training und Aufbewahrung sagen, Urheberrecht und Lizenzen von generiertem Code und die Pflichten des Unternehmens nach dem EU AI Act. Ein Codemodell auf dem eigenen Server erledigt die Fragen nach Training und Aufbewahrung bei Anbietern und lässt die Lizenzprüfung bestehen.

Dieser Leitfaden richtet sich an CTOs, Entwicklungsleitungen, Rechtsabteilungen und Datenschutz­beauftragte, die eine solche Richtlinie schreiben oder überarbeiten, und an die IT, die sie durchsetzt. Unser Artikel zu Schatten-KI und einer KI-Nutzungsrichtlinie behandelt Chatbots und andere KI-Werkzeuge im ganzen Unternehmen; diese Seite behandelt, was für Code eigen ist: Repositories, Secrets, Kundencode, Agenten, die Befehle ausführen, und die Lizenzen dessen, was ein Modell schreibt. Es handelt sich um allgemeine Informationen mit Stand Oktober 2026, nicht um Rechtsberatung; wie sie auf Ihre Verträge und Produkte zutreffen, bestätigt Ihre Rechtsberatung, die Regeln für personenbezogene Daten Ihr Datenschutz­beauftragter.

Welcher Code zu welchem Werkzeug darf

Eine Richtlinie funktioniert, wenn die Entwicklung sie ohne Rückfrage anwenden kann. Teilen Sie Code danach ein, wem er gehört und was er enthält, und entscheiden Sie dann je Werkzeug und Kontotyp. Die Tabelle ist ein Beispiel; die Entscheidungen treffen Sie.

Eine Beispielrichtlinie; „Business-Vertrag“ meint einen Unternehmensvertrag mit dem Anbieter, etwa Copilot Business oder Claude Team. Die Zeilen zu Kundencode und personenbezogenen Daten brauchen Ihre Rechtsberatung und Ihren Datenschutz­beauftragten (DSB).

Secrets brauchen eine eigene Regel, weil Agenten ganze Verzeichnisse lesen. Ein Agent, der einen Build reparieren soll, öffnet unter Umständen eine .env-Datei oder ein Deployment-Skript und schickt sie mit dem übrigen Kontext an das Modell. Halten Sie Secrets aus Repositories heraus, pflegen Sie die Ignore- oder Deny-Listen jedes Werkzeugs, wo es sie gibt, und behandeln Sie einen Schlüssel, der einen externen Dienst erreicht hat, als kompromittiert und tauschen Sie ihn aus. Kundencode ist die zweite Falle. Ob der Code eines Kunden zu einem Cloud-Anbieter darf, entscheidet der Vertrag, mit dem er kam; unser Artikel zu Geschäftsgeheimnissen, NDAs und KI-Werkzeugen geht das durch.

Ein Coding-Agent führt Befehle mit den Rechten der Entwicklerin oder des Entwicklers aus, und Text in einem Repository, einem Issue oder auf einer Webseite kann Anweisungen enthalten, denen der Agent folgt. Die Richtlinie sollte festlegen, wo Agenten laufen dürfen, etwa nur in Entwicklungscontainern ohne Produktionszugangsdaten, und welche Befehle eine Freigabe brauchen. Unser Artikel zu Prompt Injection und LLM-Sicherheit beschreibt den Angriff.

Was Copilot, Claude Code und Cursor zu Training und Aufbewahrung festlegen

Bedingungen ändern sich, und der Kontotyp entscheidet mehr als der Anbieter. Wir haben die aktuellen Seiten der Anbieter am 30. Oktober 2026 gelesen.

GitHub-Blog „Updates to GitHub Copilot interaction data usage policy“ (25. März 2026); Dokumentation von Claude Code „Data usage“; Cursor-Seite „Data Use“ (zuletzt aktualisiert am 3. September 2026); alle gelesen am 30. Oktober 2026. Zitate und Einzelheiten im Text.

GitHub Copilot. GitHubs Ankündigung vom 25. März 2026 sagt, dass ab dem 24. April Interaktionsdaten aus Copilot Free, Pro und Pro+ zum Training und zur Verbesserung seiner Modelle genutzt werden, sofern die Nutzerin oder der Nutzer nicht widerspricht. Zu diesen Daten zählen Eingaben, Ausgaben, Code-Ausschnitte, der Code um den Cursor, Dateinamen und die Repository-Struktur. GitHub ergänzt: „Copilot does process code from private repositories when you are actively using Copilot“, und die Daten können an Unternehmen in GitHubs Konzernverbund gehen, nicht aber an fremde Anbieter von KI-Modellen. „Copilot Business and Copilot Enterprise users are not affected by this update.“ Firmencode gehört also auf Firmenkonten: Ein privater Plan stellt ihn unter diese Bedingungen.

Claude Code. Anthropics Dokumentation sagt, dass unter kommerziellen Bedingungen (Team- und Enterprise-Pläne, die API und Drittplattformen) „Anthropic does not train generative models using code or prompts sent to Claude Code under commercial terms, unless the customer has chosen to provide their data to us for model improvement“. Zero Data Retention gibt es für berechtigte Konten von Claude for Enterprise, je Organisation freigeschaltet. Verbraucherkonten folgen der Einstellung der Person: Ist sie an, dienen die Daten dem Training und werden 5 Jahre aufbewahrt, sonst 30 Tage. Der Client speichert außerdem Sitzungsprotokolle im Klartext unter ~/.claude/projects/, standardmäßig 30 Tage lang; auch Notebooks gehören also zur Frage der Aufbewahrung. Ein Bericht über den Befehl /feedback enthält die Unterhaltung samt Code und wird 5 Jahre aufbewahrt; DISABLE_FEEDBACK_COMMAND=1 schaltet den Befehl ab.

Cursor. Cursors Seite zur Datennutzung sagt: „Even if you use your API key, your requests will still go through our backend!“ Mit Privacy Mode gilt: „Customer Data will not be used for training by Cursor“, und Cursor „maintains zero data retention (ZDR) agreements with all providers“. Ohne Privacy Mode darf Cursor Codebasisdaten, Prompts, Editoraktionen und Code-Ausschnitte nutzen und speichern. Unser Artikel zu Cursor mit lokalem Modell behandelt ein selbst gehostetes Modell hinter Cursor.

Für Copilot CLI dokumentiert GitHub einen Offline-Modus mit selbst gehostetem Modell, in dem „No GitHub authentication is attempted“ und die Telemetrie vollständig abgeschaltet ist, wie unser Vergleich der selbst gehosteten Copilot-Alternativen darlegt; unser Leitfaden zu Claude Code mit lokalem Modell beschreibt denselben Weg für Claude Code.

Wir richten Cline oder Kilo Code gegen ein Modell auf Ihrem eigenen Server ein; fragen Sie uns, welcher Aufbau zu den Werkzeugen passt, die Ihre Entwicklung schon nutzt.

Urheberrecht und Lizenzen bei KI-generiertem Code

Das EU-Recht schützt Software über die Richtlinie 2009/24/EG. Artikel 1 schützt Computerprogramme urheberrechtlich als literarische Werke, und nach Artikel 1 Absatz 3 wird ein Programm geschützt, wenn es individuell in dem Sinne ist, dass es die eigene geistige Schöpfung seines Urhebers ist. Artikel 2 Absatz 1 nennt als Urheber die natürliche Person oder Personen, die das Programm geschaffen haben, oder, soweit das nationale Recht es zulässt, die juristische Person, die es als Rechtsinhaber bestimmt. Nach Artikel 2 Absatz 3 ist ausschließlich der Arbeitgeber berechtigt, alle wirtschaftlichen Rechte an einem Programm auszuüben, das ein Arbeitnehmer in Wahrnehmung seiner Aufgaben oder nach den Anweisungen seines Arbeitgebers schafft, sofern vertraglich nichts anderes vereinbart ist. Mit KI generierten Code behandelt sie nicht. Wie weit Prompts, Auswahl und Änderungen einer Entwicklerin oder eines Entwicklers das Ergebnis zu ihrer eigenen geistigen Schöpfung machen, beurteilt Ihre Rechtsberatung; nationales Recht und Gerichte können abweichen.

Die Richtlinie funktioniert auch, ohne diese Frage zu klären: Verantwortlich ist, wer den Code committet, gleich wer oder was ihn entworfen hat, und er durchläuft dasselbe Review und dieselben Tests wie jede andere Änderung. Ein Trailer in der Commit-Nachricht, der KI-gestützte Commits kennzeichnet, ist in Sekunden gesetzt und hilft, wenn später eine Frage aufkommt.

Praktischer ist die Lizenzfrage. Ein Vorschlag kann Code aus einem öffentlichen Repository entsprechen, und dieser Code kann unter einer Open-Source-Lizenz mit Bedingungen stehen, etwa zur Weitergabe, die Ihre Rechtsberatung beurteilt. GitHubs Code Referencing geht das in der Cloud an: Entspricht ein Vorschlag öffentlichem Code, zeigt Copilot den Lizenztyp und die URL der passenden Datei, und Organisationen können Vorschläge, die öffentlichem Code entsprechen, auf „Block“ stellen. Ein selbst gehostetes offenes Modell hat keinen solchen Filter. Auch seine Lizenz hilft nicht: Qwen3-Coder und gpt-oss stehen unter Apache 2.0, die das Werk auf einer „AS IS“-Basis bereitstellt, „WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND“, und nichts über Ausgaben sagt. Unser Vergleich offener LLM-Lizenzen für den Unternehmenseinsatz behandelt die übrigen Modelllizenzen.

Die Richtlinie verlegt die Prüfung daher in Ihre Pipeline. Ein Lizenzscanner wie ScanCode Toolkit (Apache-2.0), der laut README „detects licenses, copyrights, package manifests, direct dependencies“, findet Lizenztexte und Hinweise, indem er Ihren Code mit einer Datenbank von Lizenztexten vergleicht. Sein README beansprucht nicht, Fragmente zu finden, die ohne Lizenzhinweis kopiert wurden; fragen Sie daher Ihren Anbieter für Software Composition Analysis, ob er Snippets abgleicht. Ergänzen Sie zwei Regeln für die Entwicklung: Fremder Code kommt als deklarierte Abhängigkeit über den Paketmanager herein, nie aus der Antwort eines Modells kopiert, und Prompts verlangen nicht, eine benannte Bibliothek nachzubauen. Bieten die Business-Bedingungen eines Anbieters Schutz gegen Ansprüche Dritter wegen geistigen Eigentums an der Ausgabe, lesen Sie die Bedingungen mit Ihrer Rechtsberatung; bei einem selbst gehosteten Modell steht kein Anbieter für die Ausgabe ein.

Der EU AI Act für Entwicklungsteams

Ein Unternehmen, dessen Entwicklung einen Coding-Assistenten nutzt, ist Betreiber im Sinne des AI Act; Artikel 3 Nummer 4 beschreibt damit eine Person oder Stelle, die ein KI-System in eigener Verantwortung verwendet. Artikel 4 gilt seit dem 2. Februar 2025. In der Fassung des Digital Omnibus on AI, der Verordnung (EU) 2026/1744, die seit dem 27. Juli 2026 in Kraft ist, verlangt er von Anbietern und Betreibern, Maßnahmen zu ergreifen, um die Entwicklung der KI-Kompetenz ihres Personals zu unterstützen. Für die Entwicklung gehören erfundene APIs und Pakete, unsichere Vorschläge, in Repository-Inhalten versteckte Anweisungen und die obigen Lizenzregeln in diese Schulung. Unser Leitfaden zur KI-Kompetenz-Schulung nach Artikel 4 beschreibt Inhalte und Nachweise.

Teams, die KI in ihre eigene Software einbauen, können Anbieter werden, nach Artikel 3 Nummer 3 eine Stelle, die ein KI-System entwickelt oder entwickeln lässt und es unter eigenem Namen oder eigener Marke in Verkehr bringt oder in Betrieb nimmt. Solange die Arbeit noch Entwicklung ist, gilt die Verordnung nach Artikel 2 Absatz 8 nicht für Forschungs-, Test- und Entwicklungstätigkeiten zu KI-Systemen oder KI-Modellen, bevor diese in Verkehr gebracht oder in Betrieb genommen werden; Tests unter Realbedingungen fallen ausdrücklich nicht unter diese Ausnahme. Unser Leitfaden zum EU AI Act für Unternehmen mit LLMs behandelt die Pflichten der Betreiber und die Fristen, unser Artikel zu Fine-Tuning und Anbieterstatus veränderte Modelle. Ein selbst gehosteter Assistent wirft eine weitere Frage für Ihre Rechtsberatung auf. Nach Artikel 3 Nummer 11 gilt schon die Bereitstellung eines KI-Systems zum Eigengebrauch in der Union als Inbetriebnahme; ein Unternehmen, das seinen Assistenten selbst aus einem offenen Modell, einem Gateway und einem Werkzeug wie Cline zusammenstellt, kann daher neben dem Betreiber auch als dessen Anbieter gelten.

Artikel 53 Absatz 1 verlangt außerdem von Anbietern von KI-Modellen mit allgemeinem Verwendungszweck eine Strategie zur Einhaltung des Urheberrechts der Union und eine hinreichend detaillierte, öffentlich zugängliche Zusammenfassung der Inhalte, mit denen das Modell trainiert wurde. Nach Artikel 53 Absatz 2 befreit eine Veröffentlichung unter freier und quelloffener Lizenz den Anbieter nur von den Dokumentationspflichten der Buchstaben a und b; Urheberrechtsstrategie und Trainingszusammenfassung gelten also auch für offene Modelle. Öffentlich zugänglich machen muss der Anbieter nur die Zusammenfassung; wo er eines von beiden veröffentlicht hat, lohnt die Lektüre, bevor Sie ein Modell freigeben, und für Modelle, die vor dem 2. August 2025 in Verkehr gebracht wurden, haben die Anbieter nach Artikel 111 Absatz 3 bis zum 2. August 2027 Zeit.

Wie ein selbst gehostetes Modell die Richtlinie vereinfacht

Läuft das Modell auf Ihrem eigenen Server, schrumpft die Tabelle oben auf eine Entscheidung je Klasse: Alles außer Secrets darf im Rahmen der Zugriffsrechte an das interne Modell gehen, Kundencode so, wie sein Vertrag es erlaubt, und personenbezogene Daten nach Freigabe durch den DSB. Kein Anbieter bewahrt Prompts auf, keine Einstellung auf einem privaten Konto entscheidet über Training, und kein externer Auftragsverarbeiter kommt hinzu, den ein Kundenvertrag erlauben müsste. Das Protokoll gehört Ihnen: Ein Gateway mit Schlüsseln und Abfrageprotokoll hält fest, wer welches Modell aufgerufen hat, und Sie entscheiden, wie lange Prompts mit Code aufbewahrt werden und wer sie lesen darf, eine Vereinbarung, die unser Artikel zu Betriebsrat und internem KI-Assistenten vorbereiten hilft.

Was bleibt: der Lizenzscan, das Review von generiertem Code, die Regel zu Secrets und die Schulung zur KI-Kompetenz. Cline (Apache 2.0) verbindet sich mit jedem OpenAI-kompatiblen Server, und Kilo Code (MIT) dokumentiert Ollama. Laut Dokumentation von Kilo Code laufen dessen Autocomplete-Anfragen über das Kilo Gateway (gelesen am 31. Oktober 2026); die Richtlinie sollte diese Funktion daher abgeschaltet lassen, wo Code Ihr Netz nicht verlassen darf. Claude Code lässt sich auf ein Modell unter Ollama oder vLLM richten; Anthropic unterstützt das laut seiner Dokumentation aber nicht („doesn't support routing Claude Code to non-Claude models through any gateway“). Unser Leitfaden zu Claude Code mit lokalem Modell zeigt auch, wie seine verwalteten Einstellungen es an das Firmen-Gateway binden.

Sie können den Server allein bestellen, die Einrichtung von Modell, Gateway und Cline oder Kilo Code allein oder beides zusammen: den Server mit allem fertig installiert und eingerichtet; schreiben Sie uns, wir schlagen Ihnen die beste Lösung für Ihre Aufgaben und Ihr Budget vor.

Servergrößen für einen selbst gehosteten Coding-Assistenten

Die Größe des Servers folgt der Zahl der Personen, die im selben Moment Code erzeugen lassen. Unser Leitfaden zum Server für Coding-Agenten erklärt die Methode hinter diesen Werten, unsere Regel für Nutzer je Karte: 90 Prozent des Speichers, den der Treiber meldet, abzüglich 3 GiB pro Karte und abzüglich der Gewichte.

Unsere Schätzungen wie in unserem Vergleich der selbst gehosteten Copilot-Alternativen, keine Messungen: Sitzungen zu 64K Token mit 16-Bit-Cache (FP8-Cache in Klammern); die ersten beiden Zeilen sind Speichergrenzen, die letzten beiden begrenzen jede Sitzung auf 50 Token pro Sekunde aus 1.792 GB/s (Workstation Edition, Max-Q) und 1.597 GB/s (Server Edition), nach unserer Schätzung eine Obergrenze. Gewichte laut Hugging Face: gpt-oss-20b 13,76 GB, Qwen3-Coder-30B-A3B 31,2 GB, Qwen3-Coder-Next 80,4 GB in FP8.

Ein Pilot mit einer Workstation zeigt vor dem Rollout, welche Werkzeuge die Entwicklung wählt, wie viele Personen gleichzeitig generieren und was das Gateway-Protokoll festhält. Der Server mit vier Karten ist der Inferenzknoten auf unserer Seite zu KI-Servern, mit 768 GB DDR5-ECC-Speicher, bei etwa 3,4 kW nach unserer Schätzung. Zwei Karten der Workstation Edition sind für diese Edition das realistische Maximum, drei oder vier Max-Q gehören nur in ein dafür gebautes Gehäuse mit starkem, gerichtetem Luftstrom.

Wir bauen diese Workstations und Server auf Bestellung; nennen Sie uns die Zahl Ihrer Entwickler, die Werkzeuge, die sie heute nutzen, und Ihre Git-Plattform, und unser Team antwortet mit einer Konfiguration.

Eine Richtlinie als Vorlage in zwölf Punkten

1. Geltungsbereich. Alle Werkzeuge, die Code vervollständigen, erzeugen, prüfen oder erklären, einschließlich Agenten, CLI-Werkzeugen und KI-Funktionen der Git-Plattform.
2. Freigegebene Werkzeuge und Konten. Nur gelistete Werkzeuge, mit Firmenkonten oder dem internen Modell; keine privaten Pläne für Firmencode.
3. Code-Klassen. Die Tabelle oben, mit der Entscheidung je Werkzeug.
4. Secrets. Nie in Prompts oder Repositories; Ignore-Listen der Werkzeuge gepflegt; jeder Schlüssel, der einen externen Dienst erreicht hat, wird ausgetauscht.
5. Kundencode. Nur so, wie der Kundenvertrag es erlaubt; die Rechtsabteilung bestätigt vor dem ersten Projekt.
6. Personen­bezogene Daten. Keine echten personenbezogenen Daten in Testdaten, Logs oder Dumps, die ein Werkzeug erhält, außer mit Freigabe durch den Datenschutz­beauftragten.
7. Verantwortung und Review. Verantwortlich ist, wer committet; generierter Code durchläuft dasselbe Review und dieselben Tests wie jeder andere; ein Review-Bot auf Ihrem eigenen Server, wie in unserem Leitfaden zum KI-Code-Review selbst gehostet, liest als zweiter Leser mit.
8. Lizenzen. Filter für öffentlichen Code eingeschaltet, wo das Werkzeug sie hat; ein Lizenzscan in der CI; fremder Code nur als deklarierte Abhängigkeit.
9. Agenten. Laufen in Entwicklungscontainern ohne Produktionszugangsdaten; Befehle, die Systeme ändern, brauchen eine Freigabe.
10. Protokollierung. Was das Gateway festhält, wie lange es aufbewahrt wird, wer es lesen darf und welche Feedback- und Telemetriefunktionen der Werkzeuge eingeschaltet bleiben, abgestimmt mit dem Datenschutz­beauftragten und, wo vorhanden, dem Betriebsrat.
11. Schulung. Maßnahmen zur KI-Kompetenz je Rolle vor dem Zugang, mit internem Nachweis.
12. Überprüfung. Die Bedingungen der Anbieter werden in festem Abstand und nach jeder angekündigten Änderung neu geprüft, wie GitHubs Änderung vom April 2026 zeigt.

FAQ