Was gehört in eine KI-Coding-Richtlinie für Entwicklungsteams?

Acht Abschnitte decken die Arbeitsfälle ab: freigegebene Tools und Accounts; Datenregeln pro Klassifizierungsstufe; Auftragsregeln (schriftliche Absicht vor Agent-Runs); Verifikationspflichten pro Änderung; Belege und Audit-Trail; Rechte-Grenzen für Agenten (kein Auto-Commit); Ausnahmen samt Antragsweg; und Verantwortung mit Review-Rhythmus. Alles andere – Philosophie, Tool-Tutorials, Rechtsaufsätze – gehört woanders hin. Eine Richtlinie, die auf zwei Bildschirme passt, wird gelesen; eine mit vierzig Seiten wird unterschrieben und ignoriert.

Was unterscheidet diese Seite vom KI-Coding-Governance-Artikel?

Der Governance-Artikel ist der Überblick: warum Kontrolle zählt, die Bausteine, die Einführung – mit einer Ein-Bildschirm-Mini-Policy als Illustration. Diese Seite ist die Vertiefung des einen Bausteins Richtlinien-Dokument: die vollständige Vorlage Abschnitt für Abschnitt, mit Begründung pro Abschnitt und Anpassungshinweisen für Teamgröße und Regulierungsgrad. Lest zuerst den Überblick, wenn Governance Neuland ist; startet hier, wenn ihr wisst, dass ihr das Dokument braucht.

Brauchen kleine Teams wirklich eine schriftliche Richtlinie?

Ein Fünf-Personen-Team braucht keine Policy-Abteilung – es braucht dieselben acht Entscheidungen, einmal getroffen und aufgeschrieben, was mit der Vorlage etwa eine Stunde dauert. Die Schriftform zählt auch im Kleinen, aus drei Gründen: Onboarding hört auf, mündliche Überlieferung zu sein; Kunden- und Auditor-Fragen bekommen ein Dokument statt eines Schulterzuckens; und die Regeln überleben die Person, die sie erfunden hat. Skaliert die Zeremonie herunter, nicht die Entscheidungen.

Wie führt man eine Richtlinie ein, ohne Widerstand auszulösen?

Schreibt sie mit den Menschen, die sie bindet, nicht für sie – eine einstündige Session, in der das Team die Vorlage ausfüllt, schlägt jedes Dekret von oben. Verankert jede Regel an einem Fehlermodus, den alle kennen (Secrets im Prompt, ungeprüfte Agent-Merges), statt an Autorität. Und haltet die Durchsetzung mechanisch, wo es geht: Ein Verifikations-Gate, das pro Änderung läuft, setzt sich selbst durch – eine Regel, die von manueller Wachsamkeit abhängt, wird unter Termindruck optional.

Wie oft sollte die Richtlinie überprüft werden?

Quartalsweise ist 2026 der ehrliche Default – Tool-Fähigkeiten, Anbieter-Bedingungen und der Rechtsrahmen bewegen sich schnell genug, dass ein Jahresrhythmus Veralten garantiert. Das Review ist klein: Stimmt die Tool-Liste noch, hat ein Vorfall oder Beinahe-Vorfall eine Lücke gezeigt, haben sich Anbieter-Terms oder Regulierung geändert. Benennt eine verantwortliche Person; Richtlinien ohne Owner werden nicht überprüft, sondern nach einem Vorfall wiederentdeckt.

Was macht eine Richtlinie durchsetzbar statt dekorativ?

Jede Regel braucht einen Mechanismus, und die Vorlage erzwingt diese Frage pro Abschnitt: Tool-Regeln setzen sich über verwaltete Accounts durch, Datenregeln über Filter und lokale Verarbeitung, Auftragsregeln über den Agent-Workflow, Verifikationsregeln über ein Gate pro Änderung, Beleg-Regeln über Reports als Nebenprodukt. Der Test: Wenn morgen alle die Richtlinie vergessen – welche Regeln gelten trotzdem noch? Das sind eure durchgesetzten Regeln; der Rest ist dokumentierte Absicht.

Governance

Die KI-Coding-Richtlinien-Vorlage

Zuletzt aktualisiert: 2026-07-02Lesezeit ca. 5 Min.

Eine KI-Coding-Richtlinie braucht acht Abschnitte: freigegebene Tools, Datenregeln pro Klassifizierung, Auftragsregeln für Agent-Runs, Verifikationspflichten pro Änderung, Belege, Rechte-Grenzen für Agenten, Ausnahmen und Verantwortung mit Review-Rhythmus. Die komplette Vorlage steht auf dieser Seite – ohne Schranke, bereit zum Anpassen. Ihr Designprinzip: Jede Regel trägt ihren Durchsetzungsmechanismus, denn eine Regel, die vom Gedächtnis abhängt, wird unter Termindruck optional.

Inhalt

Warum eine Richtlinie – und warum diese kurz ist

Die Zahlen hinter dem Bedarf sind in ihrem Missverhältnis deutlich: 84 % der Entwickler nutzen KI-Tools, aber nur 48 % prüfen konsequent, was diese Tools erzeugen – in den meisten Teams existieren die Regeln als Folklore. Unser Governance-Überblick zeichnet das ganze Kontrollbild; diese Seite trägt das eine Artefakt, an dem alles andere hängt. Sie ist absichtlich kurz. Richtlinien scheitern an Länge: Die Vierzig-Seiten-Version wird einmal unterschrieben und nie geöffnet – und ihre Autoren verwechseln die Unterschrift mit Akzeptanz.

Die acht Abschnitte – und warum jeder seinen Platz verdient

Tools & Accounts. Was freigegeben ist, auf welcher Account-Stufe – denn Consumer-Logins sind der klassische Datenschutzverstoß.
Datenregeln. Was welches Tool erreichen darf, nach Klassifizierungsstufe – der Abschnitt, den DSB und Kunden zuerst lesen.
Auftragsregeln. Agent-Runs bekommen schriftliche Absicht mit Grenzen vor dem Run – der Anker für alles Prüfbare.
Verifikation. Was pro Änderung bestehen muss – und dass die Validierung nicht vom generierenden Modell verfasst ist.
Belege. Ein Nachweis pro Run, gespeichert beim Code – euer Audit-Trail wächst als Nebenprodukt.
Agenten-Rechte. Advisory by default, kein Auto-Commit, kein Produktionszugriff – der Abschnitt, den Vorfälle unverhandelbar gemacht haben.
Ausnahmen. Wie man eine beantragt, wer freigibt, wo sie protokolliert wird – denn eine Richtlinie ohne Ausnahmeweg wird umgangen statt geändert.
Verantwortung & Review. Ein benannter Owner, quartalsweises Review – herrenlose Richtlinien werden nach Vorfällen wiederentdeckt, nicht vorher.

Die Vorlage

ki-coding-richtlinie.md

Beispiel – an euer Team anpassen

# KI-Coding-Richtlinie · <Team> · v1.0 · Owner: <Name> · Review: quartalsweise

## 1 Tools & Accounts
Freigegeben: <Claude Code, Cursor, Copilot> nur auf Firmen-Accounts.
Consumer-/Free-Tarife: für Arbeit untersagt. Neue Tools: <Owner> fragen.

## 2 Datenregeln
Öffentlicher/interner Code: in freigegebenen Tools erlaubt.
Vertraulich (Kundencode, infra/secrets/*, Prod-Daten): nur lokale
Verarbeitung - nie in Cloud-Prompts oder -Kontext.
Personenbezogene Daten in Prompts/Fixtures/Logs: untersagt (DSB-Notiz).

## 3 Auftragsregeln (Agent-Runs)
Jeder Agent-Run hat VOR dem Start einen schriftlichen Auftrag:
Ziel · Grenzen (erlaubte Dateien/Verzeichnisse) · Akzeptanzkriterien.
Kein Auftrag, kein Run - "Quick Fixes" eingeschlossen.

## 4 Verifikation (pro Änderung)
Muss vor dem Review bestehen: Build · Typen · änderungsrelevante Tests.
Validierung stammt nicht vom generierenden Modell / derselben Session.
Die Änderung wird gegen den Auftrag geprüft (Umfang + Kriterien).

## 5 Belege (pro Run)
Ein Run-Nachweis liegt beim Code: Auftrag, Tool+Version, Diff-Umfang,
Validierungen + Ergebnisse, Übersprungenes, Freigebender.

## 6 Agenten-Rechte
Agenten sind advisory by default: vorschlagen, nie unbeaufsichtigt
anwenden. Kein Auto-Commit. Keine direkten Writes auf geschützte
Branches. Kein Zugriff auf Produktion, Credentials, Kundendaten.

## 7 Ausnahmen
Antrag an <Owner> mit Grund + Ablaufdatum. Protokolliert in <Register>.
Abgelaufene Ausnahmen fallen automatisch auf die Richtlinie zurück.

## 8 Vorfälle
KI-zugeschriebener Defekt oder Daten-Ausrutscher: Meldung an <Kanal>
binnen 24h. Blameless Review; Richtlinien-Lücken-Check gehört zu
jedem Postmortem.

Anpassungshinweise: Ein Fünf-Personen-Team kann Abschnitt 7 und 8 auf zwei Zeilen eindampfen; ein reguliertes Team erweitert Abschnitt 2 um sein Klassifizierungsschema und Abschnitt 5 um Aufbewahrungsregeln. Was jede Anpassung überleben sollte, ist die Struktur von Abschnitt 4 und 6 – Verifikation pro Änderung und Advisory-by-default sind die zwei Regeln mit dem größten Risiko, wenn sie erodieren.

Typische Fehlermodi

Die Vierzig-Seiten-Richtlinie. Vollständigkeit fühlt sich verantwortungsvoll an und liest sich als Rauschen. Jeder Abschnitt, der kein Verhalten ändert, verdünnt die, die es müssen.
Alles verbieten. Bei 84 % Nutzung stoppt ein Verbot nicht die Nutzung – es stoppt die Offenlegung. Die BSI/ANSSI-Linie – ermöglichen mit Regeln, Output prüfen – ist sicherer und durchsetzbar.
Regeln ohne Mechanismen. „Entwickler sollen KI-Code sorgfältig prüfen“ ist ein Wunsch. Ein Gate, das pro Änderung läuft, ist eine Regel. Schreibt nur Regeln, die ihr mit einem Mechanismus hinterlegen könnt – und benennt den Mechanismus in der Richtlinie.

Wo Reality Graph ansetzt

Abschnitt 3 bis 6 der Vorlage beschreiben fast Zeile für Zeile, was Reality Graph mechanisiert: schriftliche Aufträge mit Grenzen, Verifikation jedes Runs dagegen, ein Prüfbericht pro Run, Advisory-by-default ohne Auto-Commit als Architektur statt Versprechen. Die Richtlinie steht ohne jedes bestimmte Tool – Reality Graph macht aus ihren mittleren Abschnitten Defaults statt manueller Disziplin.

Diese Vorlage gibt euch

Acht Abschnitte mit Begründung pro Abschnitt
Das volle Dokument auf der Seite – keine Download-Schranke
Einen benannten Durchsetzungsmechanismus pro Regel
Anpassungshinweise für kleine und regulierte Teams

Sie gibt euch nicht

Rechtsprüfung – euer Justiziariat liest sie, bevor sie jemanden bindet
Eine Richtlinie, die unangepasst funktioniert – die Platzhalter sind echte Arbeit
Durchsetzung von selbst – Mechanismen müssen wirklich verdrahtet werden
Abdeckung von KI jenseits des Codings – bewusst scopen oder erweitern

Wenn diese Grenzen zu eurem Team passen:

Early Access sichern So funktioniert es

FAQ

Was gehört in eine KI-Coding-Richtlinie für Entwicklungsteams?: Acht Abschnitte decken die Arbeitsfälle ab: freigegebene Tools und Accounts; Datenregeln pro Klassifizierungsstufe; Auftragsregeln (schriftliche Absicht vor Agent-Runs); Verifikationspflichten pro Änderung; Belege und Audit-Trail; Rechte-Grenzen für Agenten (kein Auto-Commit); Ausnahmen samt Antragsweg; und Verantwortung mit Review-Rhythmus. Alles andere – Philosophie, Tool-Tutorials, Rechtsaufsätze – gehört woanders hin. Eine Richtlinie, die auf zwei Bildschirme passt, wird gelesen; eine mit vierzig Seiten wird unterschrieben und ignoriert.
Was unterscheidet diese Seite vom KI-Coding-Governance-Artikel?: Der Governance-Artikel ist der Überblick: warum Kontrolle zählt, die Bausteine, die Einführung – mit einer Ein-Bildschirm-Mini-Policy als Illustration. Diese Seite ist die Vertiefung des einen Bausteins Richtlinien-Dokument: die vollständige Vorlage Abschnitt für Abschnitt, mit Begründung pro Abschnitt und Anpassungshinweisen für Teamgröße und Regulierungsgrad. Lest zuerst den Überblick, wenn Governance Neuland ist; startet hier, wenn ihr wisst, dass ihr das Dokument braucht.
Brauchen kleine Teams wirklich eine schriftliche Richtlinie?: Ein Fünf-Personen-Team braucht keine Policy-Abteilung – es braucht dieselben acht Entscheidungen, einmal getroffen und aufgeschrieben, was mit der Vorlage etwa eine Stunde dauert. Die Schriftform zählt auch im Kleinen, aus drei Gründen: Onboarding hört auf, mündliche Überlieferung zu sein; Kunden- und Auditor-Fragen bekommen ein Dokument statt eines Schulterzuckens; und die Regeln überleben die Person, die sie erfunden hat. Skaliert die Zeremonie herunter, nicht die Entscheidungen.
Wie führt man eine Richtlinie ein, ohne Widerstand auszulösen?: Schreibt sie mit den Menschen, die sie bindet, nicht für sie – eine einstündige Session, in der das Team die Vorlage ausfüllt, schlägt jedes Dekret von oben. Verankert jede Regel an einem Fehlermodus, den alle kennen (Secrets im Prompt, ungeprüfte Agent-Merges), statt an Autorität. Und haltet die Durchsetzung mechanisch, wo es geht: Ein Verifikations-Gate, das pro Änderung läuft, setzt sich selbst durch – eine Regel, die von manueller Wachsamkeit abhängt, wird unter Termindruck optional.
Wie oft sollte die Richtlinie überprüft werden?: Quartalsweise ist 2026 der ehrliche Default – Tool-Fähigkeiten, Anbieter-Bedingungen und der Rechtsrahmen bewegen sich schnell genug, dass ein Jahresrhythmus Veralten garantiert. Das Review ist klein: Stimmt die Tool-Liste noch, hat ein Vorfall oder Beinahe-Vorfall eine Lücke gezeigt, haben sich Anbieter-Terms oder Regulierung geändert. Benennt eine verantwortliche Person; Richtlinien ohne Owner werden nicht überprüft, sondern nach einem Vorfall wiederentdeckt.
Was macht eine Richtlinie durchsetzbar statt dekorativ?: Jede Regel braucht einen Mechanismus, und die Vorlage erzwingt diese Frage pro Abschnitt: Tool-Regeln setzen sich über verwaltete Accounts durch, Datenregeln über Filter und lokale Verarbeitung, Auftragsregeln über den Agent-Workflow, Verifikationsregeln über ein Gate pro Änderung, Beleg-Regeln über Reports als Nebenprodukt. Der Test: Wenn morgen alle die Richtlinie vergessen – welche Regeln gelten trotzdem noch? Das sind eure durchgesetzten Regeln; der Rest ist dokumentierte Absicht.

Weiterlesen

GovernanceDer EM-Guide zu KI-Code-QualitätDurchsatz bleibt grün, während Qualität erodiert – die vier vorlaufenden Kennzahlen aus Git- und PR-Daten, ihre Warnsignale und Gegenmaßnahmen und der Führungsrhythmus, der steuert, ohne zu gängeln.GovernanceJunior + KI: der Senior-FlaschenhalsKI hebt den Boden der Produktion, nicht die Decke des Urteils – die Review-Last konzentriert sich nach oben, und weniger Juniors einzustellen konsumiert künftige Seniorität. Mechanismus, Daten, entlastender Workflow.Alle ArtikelDie ganze Sammlung – 51 belegte, datierte Guides zur Prüfung von KI-generiertem Code.