Richtlinie für Coding Agents im Unternehmen: Inhalte und Aufbau

This page in English

Kurz gesagt

Eine interne Richtlinie für Coding Agents legt fest, welche Agenten und Modelle genutzt werden dürfen, welche Datenklassen sie erreichen dürfen, wie Zugangsdaten geschützt bleiben, wer generierten Code prüft und verantwortet, wie mit Lizenzrisiken umgegangen wird und was protokolliert wird. In Deutschland gehören Betriebsrat, Datenschutz und Geheimnisschutz von Anfang an dazu.

Warum eine Richtlinie – und warum eine kurze

In den meisten Entwicklungsteams werden Coding Agents längst genutzt, mal offiziell, mal über private Konten. Ein Verbot verschiebt die Nutzung nur dorthin, wo niemand mehr kontrolliert, welche Daten abfließen. Ein dreißigseitiges Regelwerk liest dagegen niemand. Was funktioniert: wenige Seiten mit klaren Antworten, eingebettet in bestehende Strukturen wie Ihr ISMS nach ISO 27001 oder Ihre IT-Nutzungsrichtlinie, und technisch durchgesetzt, wo immer es geht.

Bewährte Gliederung

  1. Geltungsbereich, Rollen und Verantwortliche
  2. Freigegebene Werkzeuge, Kontoarten und das Verfahren für neue Freigaben
  3. Datenklassen und was davon welches Werkzeug erreichen darf
  4. Geheimnisse, Zugangsdaten und Umgebungen
  5. Berechtigungen und Autonomiegrad der Agenten
  6. Review-Pflicht und Verantwortung
  7. Lizenzen, Urheberrecht und Nutzungsrechte
  8. Protokollierung und Mitbestimmung
  9. Vorgehen bei Vorfällen, etwa wenn Zugangsdaten oder personenbezogene Daten an ein Modell gegangen sind
  10. Schulung und regelmäßige Überprüfung der Richtlinie

Datenklassen statt Einzelfallentscheidungen

Knüpfen Sie die Freigaben an Ihre bestehende Klassifizierung:

  • Öffentlich (Open-Source-Code, öffentliche Doku): alle freigegebenen Werkzeuge.
  • Intern (der Großteil des eigenen Quellcodes): freigegebene Werkzeuge mit Geschäftskonditionen – kein Training mit Ihren Eingaben, definierte Speicherdauer.
  • Vertraulich (sicherheitskritischer Code, Kundencode unter NDA): nur ausdrücklich freigegebene Umgebungen, etwa EU-gehostet oder selbst betrieben, oder gar nicht.
  • Personenbezogen (Kunden- und Beschäftigtendaten, Logs mit Kennungen): nie im Prompt, vorher anonymisieren.

Ein oft übersehener Punkt: Das Geschäftsgeheimnisgesetz schützt Informationen nur, wenn angemessene Geheimhaltungsmaßnahmen getroffen wurden. Klare Regeln, welcher Code in welche Werkzeuge darf, gehören zu solchen Maßnahmen. MCP-Server, Plugins und Erweiterungen brauchen wie jede andere Software eine Freigabe, weil sie Daten lesen und in Systemen handeln können.

Technisch durchsetzen statt nur verbieten

  • Agenten per Konfiguration den Zugriff auf .env-Dateien und Schlüsselspeicher verweigern.
  • Secret-Scanning in Pre-Commit-Hooks und in der CI.
  • Keine produktiven Zugangsdaten für Agenten; Test- und Entwicklungsumgebungen mit eigenen, eingeschränkten Konten.
  • Vollautonome Modi nur in isolierten Containern mit begrenztem Netzwerkzugriff.
  • Prompt Injection benennen: Inhalte aus Tickets, Webseiten oder fremder Dokumentation können Agenten steuern. Agentenläufe, die durch externe Eingaben ausgelöst werden, brauchen besondere Prüfung.

Für den Ernstfall braucht die Richtlinie einen kurzen, eindeutigen Ablauf: Gelangt ein Schlüssel in einen Prompt, wird er sofort widerrufen und ersetzt – nicht erst geprüft, ob der Anbieter ihn speichert. Sind personenbezogene Daten betroffen, informieren Beschäftigte umgehend die Datenschutzbeauftragten, denn für Meldungen an die Aufsichtsbehörde nach Art. 33 DSGVO gilt in der Regel eine Frist von 72 Stunden.

Review, Lizenzen und Mitbestimmung

Verantwortlich für Code ist, wer ihn prüft und zusammenführt – unabhängig davon, wer oder was ihn geschrieben hat. Generierter Code kann vorhandenem Open-Source-Code ähneln; wo das relevant ist, helfen Lizenz-Scans, und jede vom Agenten hinzugefügte Abhängigkeit durchläuft die übliche Lizenzprüfung.

Bei der Protokollierung ist Vorsicht geboten: Werkzeuge, die Arbeitsschritte einzelner Beschäftigter aufzeichnen, sind technische Einrichtungen im Sinne von § 87 Abs. 1 Nr. 6 BetrVG, sofern sie zur Leistungs- oder Verhaltenskontrolle geeignet sind. Eine Betriebsvereinbarung schafft hier Klarheit. Hinzu kommt die Pflicht aus der EU-KI-Verordnung, für ausreichende KI-Kompetenz des Personals zu sorgen. Diese Hinweise ersetzen keine Rechtsberatung. Mehr zur technischen Seite im Beitrag zu Sicherheitsrisiken von Agentic Coding.

Wie jocapps unterstützt

Eine Richtlinie wirkt erst, wenn das Team sie versteht und anwendet. neooutput bietet Praxis-Workshops, Team-Trainings und 1:1-Beratung zu Agentic Coding auf Deutsch oder Englisch, vor Ort oder remote – inklusive der Werkzeugkonfiguration, die Ihre Regeln durchsetzt. Für die Regel zu personenbezogenen Daten entfernt Textwash Pro solche Daten mit einer lokalen KI vollständig offline oder arbeitet als Datenschutz-Schicht vor ChatGPT, Claude & Co. Für ein erstes Gespräch buchen Sie ein kostenloses 30-minütiges Erstgespräch im Terminplaner.

Häufige Fragen

Muss der Betriebsrat bei Coding Agents beteiligt werden?

Häufig ja, wenn die Werkzeuge geeignet sind, Verhalten oder Leistung von Beschäftigten zu überwachen. Klären Sie das früh; eine Betriebsvereinbarung schafft Rechtssicherheit für beide Seiten.

Sollten wir Coding Agents bis zur fertigen Richtlinie verbieten?

Eine kurze Übergangsregel ist meist besser: ein oder zwei Werkzeuge mit Geschäftskonditionen freigeben, vertrauliche und personenbezogene Daten ausschließen.

Wer haftet für Fehler in generiertem Code?

Intern verantwortet ihn, wer ihn prüft und zusammenführt – genau wie bei anderem Code. Die Richtlinie sollte das ausdrücklich festhalten.

Guides zum Thema

Sprechen wir über Ihr Projekt

Ehrliche Einschätzung zu Idee, Prototyp oder App.

  • 30 Minuten
  • Kostenlos
  • Unverbindlich

Kostenloses Gespräch buchen [email protected]