Das Gespräch, das jeder VP Engineering gerade führt
Wir schreiben 2026, und die Frage lautet nicht mehr „sollen wir AI-Coding-Assistenten zulassen". Jede ernsthafte Engineering-Organisation hat sie bereits – offiziell oder inoffiziell. Die Frage ist, wie man sie verantwortungsvoll betreibt: welche Tools, in welchen Repositories, mit welcher Telemetrie, mit welchen Guardrails, und was passiert, wenn jemand versehentlich PII eines Kunden in einen Prompt einfügt.
Dieser Beitrag ist eine Vorlage für dieses Gespräch. Er basiert auf Policies, die wir mit Kunden von Series-B-SaaS-Unternehmen bis hin zu regulierten Branchen verfasst haben. Er deckt Copilot, Cursor, Claude Code, Windsurf und was immer nächsten Dienstag noch auf einem Laptop landet. Wir tun nicht so, als gäbe es eine einzige richtige Antwort, aber die funktionierenden folgen einem recht konsistenten Muster.
Grundprinzipien
Fünf Prinzipien, die die Policy verankern sollten:
- Behandeln Sie AI-Assistenten wie jedes andere Entwickler-Tool – mit Security-Review, Procurement und SSO.
- Gehen Sie davon aus, dass Prompts Ihr Netzwerk verlassen – denn das tun sie, sofern Sie keinen privaten Endpoint konfiguriert haben.
- Generierter Code ist Ihr Code – das Modell haftet nicht, Sie tun es.
- Lizenzrisiko ist real – GPL-Code in Suggestions ist möglich, unwahrscheinlich, aber möglich.
- Opt-in pro Team, nicht pro Person – Pilot, dann Tiers, dann General Availability.
Die Risiken, klar benannt
Bevor die Policy steht, benennen Sie die Risiken. Jeder Engineer sollte sie aufsagen können.
| Risiko | Wie es aussieht | Blast Radius |
|---|---|---|
| Secret-Exfiltration | API-Key in einem Prompt wird geloggt | Hoch |
| PII-Exposure | Kundendaten zum Debuggen eingefügt | Hoch (regulatorisch) |
| IP-Leakage | Proprietäre Algorithmen im Context Window | Hoch (Wettbewerb) |
| Lizenzkontamination | GPL-Code wird vorgeschlagen und in proprietäre Codebase gemergt | Mittel |
| Supply Chain | Vorgeschlagener Paketname ist ein Typosquat | Mittel |
| Qualität / Halluzination | Selbstbewusster Unsinn geht in Produktion | Mittel |
| Overreliance | Juniors überspringen das Erlernen von Grundlagen | Langfristig |
| Telemetrie | Anbieter behält Tastatureingaben oder Code-Snippets | Mittel (vertraglich) |
Gute Governance ist die Schnittmenge der Kontrollen, die jedes dieser Risiken auf ein akzeptables Maß reduzieren, ohne das Tool unbrauchbar zu machen.
Die Policy-Vorlage
Unten steht ein Policy-Dokument, das Sie adaptieren können. Betrachten Sie es als Ausgangspunkt.
1. Geltungsbereich
Diese Policy gilt für alle Engineering-Mitarbeitenden, Contractors und eingebetteten Berater, die AI-Coding-Assistenten im Zusammenhang mit Unternehmenscode verwenden. Sie umfasst IDE-Plugins (GitHub Copilot, Cursor, Windsurf, Zed AI), CLI-Assistenten (Claude Code, Aider, OpenAI Codex CLI), chatbasierte Assistenten für Code (ChatGPT, Claude.ai) und jedes andere Tool, das Quellcode oder technischen Kontext an ein Drittanbieter-Modell sendet.
2. Freigegebene Tools
Nur Tools auf der Freigabeliste dürfen mit Unternehmenscode verwendet werden. Die Freigabeliste wird quartalsweise geprüft und von Platform- und Security-Team gepflegt.
Stand dieser Version:
- GitHub Copilot Business oder Enterprise – Enterprise Tenancy, SSO, Zero-Retention aktiv.
- Cursor Business – mit Custom OpenAI-/Anthropic-Endpoints und Privacy Mode.
- Claude Code – mit Anthropic-Business-Tier und Default Data Handling.
- GitHub Copilot Chat (über dieselbe Business-Tenancy).
Persönliche Accounts und Free Tiers sind für keinerlei dienstliche Nutzung zulässig. Tools, die nicht auf dieser Liste stehen, benötigen vor Gebrauch einen Security-Review.
3. Erlaubte und verbotene Kontexte
AI-Assistenten dürfen in Repositories verwendet werden, die im Repository-Katalog mit ai: allowed oder ai: limited gekennzeichnet sind. Sie dürfen nicht in Repositories verwendet werden, die mit ai: forbidden markiert sind.
Erlaubte Kontexte
- Anwendungs-Code (Frontend, Backend, Services).
- Infrastruktur-Code (Terraform, Helm, Kubernetes-Manifeste).
- Internes Tooling und Skripte.
- Testcode und Generierung von Testdaten (ausschließlich synthetisch).
Verbotene Kontexte
- Repositories mit Kundendaten-Exporten.
- Repositories mit kryptografischen Implementierungen, die nicht von Security freigegeben wurden.
- Repositories mit Signing Keys, KMS-Bootstrap oder Root-of-Trust-Material.
- Jedes Repository oder jede Datei mit PII, PHI oder regulierten Daten.
- Security-Forschung gegen eigene Systeme ohne schriftliche Freigabe.
4. Prompt-Hygiene
Engineers dürfen in keinen AI-Assistenten-Prompt einfügen:
- API-Keys, Tokens, Passwörter oder andere Secrets.
- Kundendaten, auch teilweise oder anonymisiert.
- Personenbezogene Daten.
- Nicht-öffentliche Finanzdaten oder Forecasts.
- Nicht-öffentliche Roadmap- oder HR-Informationen.
Im Zweifel: redaktieren.
5. Review von generiertem Code
Sämtlicher AI-generierter oder AI-modifizierter Code unterliegt demselben Review-Prozess wie menschlicher Code: PR-Review, CI-Checks und Security Scanning. Engineers sind für den Code verantwortlich, den sie committen, unabhängig von seiner Herkunft.
6. Lizenz-Hygiene
Engineers dürfen keine Suggestions wissentlich übernehmen, die substanzielle Teile externen Quellcodes replizieren. Wo das Tool einen Public-Code-Filter anbietet (Copilots Duplicate Detection), muss dieser aktiviert sein. Suggestions, die wortgleicher Drittcode zu sein scheinen, sind abzulehnen und zu melden.
7. Telemetrie
Telemetrie- und Retention-Einstellungen der Anbieter sind zentral so konfiguriert, dass Exposure minimiert wird:
- Copilot: Organization Policy mit „Allow suggestions matching public code" auf Block und „Prompt and suggestion collection" deaktiviert.
- Cursor: Privacy Mode via Configuration Management erzwungen.
- Claude Code: Default-Verhalten (kein Training auf Business-Daten) plus explizites
claude-code-settings-Management.
8. Incidents
Jeder vermutete Secret-Leak, jede PII-Exposure oder Lizenz-Sorge im Zusammenhang mit einem AI-Assistenten ist innerhalb von 24 Stunden an das Security-Team zu melden. Das Standard-Incident-Response-Runbook gilt.
9. Review und Änderung
Diese Policy wird alle 6 Monate oder bei einer wesentlichen Änderung in Tooling oder Regulierung überprüft.
Durchsetzbar machen
Eine Policy, die niemand liest, ist keine Policy. Die Durchsetzung kommt aus drei Schichten: Pre-Commit-Hooks auf dem Entwickler-Laptop, CI-Checks in jedem PR und OPA-Regeln in der CI selbst.
Pre-Commit-Hook: Secrets blocken, bevor sie in Git landen
# .pre-commit-config.yaml
repos:
- repo: https://github.com/gitleaks/gitleaks
rev: v8.21.0
hooks:
- id: gitleaks
- repo: https://github.com/Yelp/detect-secrets
rev: v1.5.0
hooks:
- id: detect-secrets
args: ["--baseline", ".secrets.baseline"]
- repo: local
hooks:
- id: block-ai-forbidden-paths
name: block AI-forbidden paths
entry: scripts/check-ai-allowed-paths.sh
language: script
pass_filenames: true
Ein kleines Skript, das Commits auf verbotene Pfade ablehnt:
#!/usr/bin/env bash
set -euo pipefail
FORBIDDEN=(
"services/crypto/"
"secrets/"
"customer-exports/"
)
for file in "$@"; do
for path in "${FORBIDDEN[@]}"; do
if [[ "$file" == "$path"* ]]; then
echo "refusing commit: $file is in an AI-forbidden path"
exit 1
fi
done
done
CI-Check: AI-generierten Code mit fragwürdiger Herkunft erkennen
Sie können AI-verfassten Code nicht perfekt erkennen, aber offensichtliche Hinweise schon: verdächtige Copyright-Header, große Blöcke ohne passende History oder neue Dependencies, die nicht in der PR-Beschreibung auftauchen.
name: ai-governance
on:
pull_request:
jobs:
secret-scan:
runs-on: ubuntu-24.04
steps:
- uses: actions/checkout@v4
with:
fetch-depth: 0
- uses: gitleaks/gitleaks-action@v2
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
license-scan:
runs-on: ubuntu-24.04
steps:
- uses: actions/checkout@v4
- uses: fossas/fossa-action@v3
with:
api-key: ${{ secrets.FOSSA_API_KEY }}
dependency-review:
runs-on: ubuntu-24.04
steps:
- uses: actions/checkout@v4
- uses: actions/dependency-review-action@v4
with:
fail-on-severity: moderate
deny-licenses: "GPL-3.0,AGPL-3.0"
OPA-Policy: Merges basierend auf dem Repo-Katalog gaten
Jedes Repository hat einen Eintrag in einem zentralen Katalog mit einer Klassifizierung. OPA prüft, dass das aktuelle Repo AI-Assistenten nutzen darf und dass PRs, die verbotene Pfade anfassen, nicht durchschlüpfen.
package ai.repo_policy
default allow_merge := false
allow_merge if {
input.repo.ai_classification in {"allowed", "limited"}
count(forbidden_changes) == 0
}
forbidden_changes contains path if {
some change in input.changes
path := change.path
startswith(path, "services/crypto/")
}
forbidden_changes contains path if {
some change in input.changes
path := change.path
contains(path, "customer-exports")
}
Rollout-Strategie
Durchsetzung ist der letzte Schritt. Der erste ist, das Tool in die Hände der Engineers zu bekommen, ohne etwas zu zerbrechen. Wir empfehlen einen dreistufigen Rollout.
Tier 0: Pilot (4–6 Wochen)
Wählen Sie ein Team, 5–10 Engineers, auf einem Service ohne Kundenkontakt. Geben Sie ihnen das Tool, die Policy und einen direkten Draht zum Platform-Team. Messen Sie:
- PR-Durchsatz
- Defect-Rate
- Time-to-Merge
- Qualitatives Feedback (war es netto positiv?)
Noch keine Durchsetzung. Nur beobachten.
Tier 1: Opt-in-Teams (6–8 Wochen)
Offene Einschreibung für Teams, die sich melden. Verlangen Sie die Policy-Kenntnisnahme, verlangen Sie Pre-Commit-Hooks, aktivieren Sie CI-Gates in ihren Repositories. Erweitern Sie die Freigabeliste auf Basis des Pilot-Feedbacks.
Tier 2: General Availability (Quartal 3)
Gesamtes Engineering. Policy im Handbuch. CI-Gates überall durchgesetzt. Zentrales Dashboard für Tool-Lizenzen und Auslastung. Incident-Runbook um AI-bezogene Vorfälle ergänzt.
Messen, ob es funktioniert
Governance ohne Messung ist Bauchgefühl. Die Metriken, die wir in Kundenmandaten verfolgen:
- Adoption Rate – % des Engineerings mit aktiven Seats.
- Acceptance Rate – bei Copilot der Anteil angenommener Suggestions.
- Erfasste Policy-Verstöße – durch Pre-Commit und CI pro Monat.
- Security-Incidents mit AI-Bezug – hoffentlich null.
- Developer-Zufriedenheit – per Quartalsumfrage.
- DORA-Metriken vorher/nachher – hat sich die Lead Time verbessert?
Häufige Fallstricke
Dinge, die wir schieflaufen sehen:
- Policy in Juristendeutsch, niemand liest sie. Fix: eine Seite, Klartext.
- Freigabeliste zu restriktiv. Engineers nutzen ihre privaten Accounts. Fix: großzügig sein, aber SSO und Privacy-Einstellungen verlangen.
- Durchsetzung nur in CI. Secrets sind bereits in der Git-History. Fix: Pre-Commit ist nicht verhandelbar.
- Kein Rollback-Plan. Ein breit ausgerolltes und dann als ungeeignet erkanntes Tool ist schmerzhaft. Fix: erst pilotieren.
- Das Tool als Produktivitätswunder behandeln. Unrealistische ROI-Erwartungen führen zu Enttäuschung. Fix: ehrlich messen.
Nächste Schritte
AI-Coding-Assistenten sind inzwischen Teil des Default-Entwickler-Werkzeugkastens. Ein Governance-Framework für sie ist Teil der Default-Haltung von Security und Engineering Operations. Starten Sie mit den Prinzipien, passen Sie die Policy an, installieren Sie die Hooks und rollen Sie in Tiers aus. Wenn Sie Unterstützung beim Verfassen einer maßgeschneiderten Policy, beim Piloten mit einem Team oder beim Aufbau der Enforcement-Pipeline wünschen, nehmen Sie Kontakt auf.