claude-code/06-teams-enterprise-ci.md

Kapitel 6

Teams, Enterprise und CI – wenn aus „mein Agent“ „unser System“ wird

Kern in einem Satz: Im Team zählen wiederholbare Standards, nicht überstimmbare Policies und enge Automationen – nicht der cleverste Einzel-Prompt.

---

6.1 Team-Standards etablieren

Onboarding-Tag 1, 14:30: Neue Kollegin clont das Repo, startet claude – und kämpft zwei Stunden mit anderen Test-Commands, anderen Allows und einem MCP-Server, den nur du lokal hast. Slack-Thread: „Bei mir funktioniert Claude anders.“ Das ist kein Modell-Problem. Es fehlen committed Artefakte.

Solo optimiert auf persönlichen Flow. Teams optimieren auf Vorhersagbarkeit: Jeder Laptop, jeder PR, jeder Onboarding-Tag soll denselben Agenten-Rahmen sehen.

Was gehört mindestens ins Git?

Die Tabelle ist die Checkliste für „Clone → gleiche Leitplanken“ – nicht die vollständige Enterprise-Policy.

Artefakt	Zweck	Warum im Git
CLAUDE.md	gemeinsame Fakten	reviewbar, versioniert
.claude/settings.json	Permissions, ggf. Hooks	gleiche Leitplanken für alle
.claude/rules/	thematische Normen	modular wachsbar
.claude/skills/	Team-Workflows	Rituale ohne Kontext-Romane
.mcp.json	freigegebene Server (ohne Secrets)	transparente Angriffsfläche
kurzer Abschnitt in README	Onboarding „AI setup“	Menschen finden den Einstieg

Diese Woche: CLAUDE.md + Project-settings mit Deny-Basisset committen. Skills und MCP folgen, sobald der Nutzen klar ist.

Ein genialer Prompt stirbt mit dem Chat. Eine Zeile in CLAUDE.md und ein Verify-Skill leben in jedem Checkout.

Onboarding-Reibung ist das Messgerät: Wenn ein neuer Dev „zwei Tage braucht, bis Claude bei mir so läuft wie bei euch“, fehlen committed Artefakte. Zielbild: Clone → claude doctor → Trust → Session mit denselben Test-Commands und Deny-Regeln wie der Rest des Teams. Alles, was nur in Slack-Threads lebt, ist kein Standard.

Skill-Bibliothek (Beispiele)

.claude/skills/
  verify/SKILL.md
  review-pr/SKILL.md
  add-migration/SKILL.md
  release-notes/SKILL.md

review-pr (Skizze):

---
name: review-pr
description: Review current branch against main for bugs and security
---

1. git diff main...HEAD
2. Fokus: Korrektheit, AuthZ, Secrets, Tests
3. Findings als Markdown: severity, file, why, suggestion
4. Keine Code-Änderungen außer explizit verlangt

Review und Implement mischen Bias. Getrennte Rollen (oder Sessions) halten Findings ehrlich.

Onboarding-Checkliste für neue Dev-Laptops

1. Claude Code installieren (claude doctor)
2. Login mit Org-Konto
3. Repo clonen, Trust akzeptieren
4. MCP-Auth nur für freigegebene Server
5. /init nicht blind committen – Team-CLAUDE.md ist Source of Truth

/init nicht blind committen: Init optimiert auf dieses Checkout und halluziniert gern Commands. Team-CLAUDE.md ist das Ergebnis von Reviews – nicht der erste Generator-Output eines Neulings.

---

6.2 Enterprise-Settings und Managed Policies

Szene: Drei Entwickler, drei Local-Allowlists. Der vierte hat gestern bypassPermissions in .claude/settings.local.json – und wundert sich, warum CI und der Laptop der Kollegin „irgendwie anders“ reagieren. Team braucht gemeinsame Normen im Git und, wo die Org es verlangt, Managed Policy, die lokale Bequemlichkeit nicht aushebelt.

Managed gewinnt immer. Das ist kein Komfort-Feature – es ist das Compliance-Modell: Org-Regeln dürfen nicht pro Entwickler-Pref aushebelbar sein.

Team Config vs. Managed Policy

Ebene	Wer setzt es?	Wirkung
Team / Repo (CLAUDE.md, .claude/settings.json, Skills)	Team per PR	gemeinsame Baseline; reviewbar; greift nach Clone + Trust
User / Local	Einzelperson	Prefs und Host-Spezifisches; darf Team-Deny nicht aushebeln
Managed (MDM / Admin / Datei unter Org-Pfad)	IT / Security	erzwingt Grenzen (Permission-only-managed, MCP-Allowlist, …) – schlägt User- und Project-Wünsche

Lokal bleibt Workspace Trust die Tür fürs Repo. Managed schlägt User- und Project-Wünsche, wenn die Org es so setzt. Für Team-Leads ohne MDM: Zuerst Project-Settings + Review (6.1). Managed kommt, sobald „jeder Laptop ist eine Schneeflocke“ Compliance bricht.

Auslieferungswege (Stand 2026-Doku):

• Server-managed (Admin Console / Gateway)
• MDM: macOS plist com.anthropic.claudecode, Windows Registry Policies
• Datei:
  • macOS: /Library/Application Support/ClaudeCode/
  • Linux/WSL: /etc/claude-code/
  • Windows: C:\Program Files\ClaudeCode\

Drop-ins: managed-settings.d/*.json (alphabetisch gemerged).

Wie Rollout gelingt: Pilot-Laptops → claude doctor → Feedback → breiter ausrollen. Invalid managed entries werden teilweise tolerant gestrippt (Security-Felder failen closed) – vor Org-weit und vor jedem Rollout auf einer Test-Maschine prüfen.

Typische Managed-Inhalte

{
  "permissions": {
    "deny": [
      "Read(**/.env)",
      "Read(**/.env.*)",
      "Bash(curl * | bash *)"
    ],
    "defaultMode": "default"
  },
  "allowManagedPermissionRulesOnly": true,
  "allowManagedHooksOnly": true,
  "allowedMcpServers": [
    { "serverName": "github" }
  ],
  "allowManagedMcpServersOnly": true,
  "availableModels": ["sonnet", "haiku"],
  "claudeMd": "Never commit secrets. Run the team verify skill before PR."
}

Die JSON-Felder oben sind die Hebel, mit denen IT „lokales Aufweichen“ und Schatten-MCP stoppt. Kurz die Wirkung:

Feld	Wirkung	Warum
allowManagedPermissionRulesOnly	User/Project dürfen keine eigenen allow/deny setzen	verhindert „lokales Aufweichen“
allowManagedHooksOnly	nur verwaltete/erzwungene Plugin-Hooks	keine Schatten-Automation
allowedMcpServers	Allowlist; leer = Lockdown wenn enforced	Supply-Chain und Datenabfluss begrenzen
claudeMd	Org-Text als managed Memory	Mindest-Normen überall
forceLoginOrgUUID	Login nur in die richtige Org	Schatten-Konten vermeiden

---

6.3 Sicherheit: Secrets, Deny, Audit

Agenten vergrößern die Angriffsfläche: Sie lesen Dateien, führen Shell aus und folgen Anweisungen aus Code-Kommentaren und Issues. Security ist deshalb Harness-Design, nicht nur „Mitarbeiter schulen“.

Secrets schützen

1. Deny Read auf .env, Key-Files, secrets/**
2. Secrets Manager / CI Secrets – nicht in CLAUDE.md
3. Keine Tokens in Beispiel-Prompts committen
4. MCP-Header nur über Env + Allowlists

Ein Issue-Text oder eine README kann den Agenten anweisen, Secrets zu lesen oder Netz-Calls zu machen. Deny und Managed stoppen den Tool-Call im Harness – höfliche Bitten in CLAUDE.md nicht.

Sandbox und Netzwerk

Wo verfügbar (u. a. WSL2/Linux-Szenarien): Sandboxing für Commands. Native Windows: Sandboxing laut Doku eingeschränkt – Architektur wählen.

Sandbox begrenzt, wie weit ein Befehl greift; deny begrenzt, was überhaupt angeboten wird; Audit macht den Rest nachvollziehbar. Eine Linie reicht selten.

Audit und Telemetrie (Kurz)

Deny und Sandbox begrenzen Schaden; ohne Nachvollziehbarkeit bleibt der Incident eine Geschichte ohne Beweise. Mindestens intern klären: Wer darf bypassPermissions? Welche MCP-Server sind freigegeben? Wie werden CI-Keys rotiert?

Die Schichten (OpenTelemetry, Org-Audit, Hooks/CI//export), Datenschutz und AI-Act-nahe Deployer-Hebel: 6.8.

---

6.4 Claude Code in CI/CD

Der verlockende PR-Bot: Jeder Diff bekommt automatisch einen Kommentar. Drei Sprints später: Review-Lärm, Token-Rechnung, und niemand traut den Findings – weil der Bot auch bei Typos „Critical“ schreibt und mit zu breiten Cloud-Rechten läuft. CI ist mächtig. Ohne Grenzen wird daraus teure, laute und manchmal gefährliche Automation.

Welches CI-Muster passt – und welches Risiko nimmst du?

Muster	Beschreibung	Risiko
PR-Review-Bot	Diff analysieren, Kommentar posten	Lärm, False Positives
Issue-Triage	Labels/Repros vorschlagen	falsche Labels
Generative Tasks	Translations, Boilerplate in Branch	ungeprüfte Diffs
Gate (vorsichtig)	Nur mit strengen Prompts + menschen-Review	nie blind mergen

Start klein: Ein enger Review-Prompt auf geänderte Pfade, least-privilege Token, kein Auto-Merge. Skalieren erst, wenn die Signalqualität stimmt.

Achtung: Kein Auto-Merge durch den Agenten. Ownership und Accountability bleiben menschlich – CI-Agenten sind Assistenten, keine Release-Manager.

Ein Review-Bot mit Merge-Recht multipliziert Prompt-Injection und Fehlurteile in den main-Branch. Least privilege und Menschen-Review sind die Bremse.

Headless:

claude -p "Review the diff for security issues. Output markdown only." 

Wichtige Flags (Namen je Release prüfen): Print/non-interactive Mode, erlaubte Tools, Setting-Sources.

GitHub Actions – Gerüst

Kopiervorlage: beispiele/configs/github-actions-claude.yml. Offizieller Einstieg: /install-github-app in der CLI oder manuell App + Secret + Workflow (Docs). Action-Namen und Inputs können driften – bei Abweichung gilt die aktuelle Doku; das Konzept bleibt: least privilege, kein Auto-Merge, enger Prompt.

Kern der offiziellen Action (v1, Stand Docs 2026):

- uses: anthropics/claude-code-action@v1
  with:
    anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
    prompt: "Review the PR diff for bugs and secrets. Markdown only. Do not push or merge."
    claude_args: |
      --max-turns 8

Ohne prompt (nur @claude in Kommentaren) antwortet die Action interaktiv auf Mentions. Mit prompt läuft Automation-Mode (z. B. jeder PR).

Praxisregeln CI:

• Kein bypassPermissions auf Runnern mit breiten Cloud-Credentials
• Least-privilege permissions: im Workflow
• Prompt: read-only Review vs. write (Issues/PR) trennen
• Kosten-Budgets (--max-turns, Branch-/paths:-Filter) setzen
• Ausgabe als PR-Comment oder Artifact, nie ungeprüfter Merge durch den Agenten

Ein Prompt darf keine Cloud-Admin-Rechte erben. Least privilege begrenzt den Schaden gestohlener Tokens und kompromittierter PRs. Docs-Typos sollen keine Max-Modell-Sessions triggern.

GitLab CI

Analog: Job-Image mit CLI, ANTHROPIC_API_KEY als masked variable, nur merge_request_event triggern, Report als MR-Note.

Team-System in einem Bild: Managed Policies steuern den Laptop-Agenten; CI liefert Review und Artefakte; Merge und Release bleiben menschlich. Die Schichten ergänzen sich – keine ersetzt Ownership.

{width=90%}

Transfer: Org-Policy, die der Einzelne nicht aushebelt, und CI-Review als zweite Sicherung sind Muster, keine Anthropic-Exklusivität. Andere Stacks lösen MDM, Sandbox und Bot-Review anders – die Frage bleibt: Was ist auf dem Laptop erzwingbar, was prüft die Pipeline, und wer mergt? Hybrid (IDE + CLI-Agent) ist normal; teuer wird es bei doppelter, widersprüchlicher Policy.

---

6.5 Multi-Agent und Subagents

Claude Code kann Subagents spawnen (Explore, Plan, general-purpose, custom).

/agents

Custom Agent unter .claude/agents/reviewer.md (Konzepte):

---
name: security-reviewer
description: Security-focused code review
tools: Read, Grep, Glob, Bash
---

Du bist Security-Reviewer. Keine Features implementieren.
Fokus: Injection, AuthZ, Secrets, unsichere Deserialization.

Wann Subagents helfen: Isolation von Rolle und Tool-Scope – z. B. Reviewer ohne Write, Explorer ohne Deploy. Wann Overhead: Kleine Tasks in einer Session sind billiger und klarer. Multi-Agent ohne Briefing erzeugt Doppelarbeit und widersprüchliche Diffs.

Advisor vs. Subagent: Der Advisor (Kap. 4.6) ist kein Subagent – gleiche Session, volle Transcript-Sicht, situativer Rat vom stärkeren Modell. Subagents trennen Rolle und Kontext; Advisor eskaliert Urteilskraft innerhalb des laufenden Loops. Beides kann zusammen existieren (Subagents erben advisorModel), ersetzt sich aber nicht.

Kontext-Ventil: Der Subagent liest und exploriert in seinem Fenster. In deine Session soll idealerweise nur die Zusammenfassung zurück – nicht der Roh-Leseberg. Das schützt dein Kontextfenster und trennt Recherche von Umsetzung.

{width=90%}

Mini-Walkthrough (Parent steuert, Subagent forscht):

# In der Parent-Session
Nutze einen Subagenten (Explore/read-only):
Wo speichert dieses Repo JSON und wie werden leere Dateien behandelt?
Nur Zusammenfassung mit Dateipfaden – keine Edits.

# Danach im Parent, mit freigegebenem Plan
Setze atomare Writes um laut PLAN.md. Verify: pytest -q.

Custom-Agent-Vorlage (nur online – Begleit-Service → Material / Repo): vorlagen/agents/security-reviewer.md → nach .claude/agents/ kopieren, mit /agents prüfen.

Agent teams / background agents: mehrere Sessions koordiniert – stark bei großen Migrationen, teuer und koordinationsintensiv. Lead-Agent plant, Spezialisten liefern, Mensch merged.

SDK: Für eigene Produkte die Agent-SDK-Doku – bewusst out of scope für dieses Praxisbuch (andere API-Oberfläche). Link: Ressourcen im Anhang.

---

6.6 IDE und Desktop im Team

Surfaces wechseln – Policies nicht. Sonst entsteht „hart im Terminal, weich in der Desktop-App“.

Surface	Team-Hinweis
VS Code Extension	gleiche CLAUDE.md; Diff-Review im Editor schult Qualität
JetBrains	CLI muss installiert sein
Desktop	gut für parallele Tasks; Policies gelten trotzdem
Web/Cloud	gut für lange Jobs; Secrets und Repo-Zugriff org-seitig klären

Remote Control / Mobile: praktisch, aber Trust-Boundary (wer darf von unterwegs force-push-nahe Aktionen freigeben?).

Im Team: Project- und Managed-Settings sind der gemeinsame Nenner – unabhängig davon, wer welche UI bevorzugt.

---

6.7 Performance, Kontext, Kosten

Welche Hebel zählen wirklich?

Finance fragt nach der Claude-Rechnung. Bevor du „einfach Haiku“ verordnet: Die teuersten Sessions sind oft Kontext-Schleudern – lange CLAUDE.md, zehn MCP-Server, Kitchen-Sink-Chats – nicht das Modell-Label allein.

Hebel	Effekt	Warum
Kurze CLAUDE.md	weniger Tokens/Session	Dauerlast pro Turn
Path-scoped rules	weniger irrelevanter Kontext	Relevanz statt Roman
Skills statt Romane	on-demand	Prozeduren nicht immer laden
/compact / neue Session	gegen Kontext-Ballast	Qualität und Kosten
Modellwahl	Kosten/Qualität	Task-Passung
Advisor (experimental)	starker Rat nur an Knoten	oft günstiger als Dauer-Opus; extra Tokens pro Call
Enge Tasks	weniger Tool-Loops	Scope bremst Exploration
MCP-Anzahl	weniger Tool-Schema-Overhead	jedes Tool kostet Kontext

Drei Hebel vor dem Modellwechsel: CLAUDE.md kürzen, MCP reduzieren, Tasks engen. Dann /cost und /context lesen.

{width=90%}

/cost
/usage
/context

Budgets: Team-Abos und API-Keys haben unterschiedliche Limits. CI-Jobs hart deckeln (nur auf Label /claude-review oder Draft-PRs).

Auto-compact

autoCompactEnabled (Settings) – hilfreich, aber Compact ist verlustbehaftet. Wichtige Entscheidungen in Dateien (PLAN.md, CLAUDE.md) festhalten, nicht nur im Chat. Manuell früher compacten und Hints setzen – Details und Rituale in Kapitel 07.2–7.4.

Compact fasst zusammen und vergisst Nuancen. Teams, die nur im Chat entscheiden, verlieren den Thread – wörtlich.

---

6.8 Compliance-Tiefe: Audit, Datenschutz, EU AI Act, Haftung

Kern: Managed Deny, CI least privilege und Diff-Review sind notwendig – aber nicht hinreichend. Ohne Audit-Story, klare Datenflüsse und menschliche Ownership bleibt „Enterprise“ eine Config-Sammlung, kein belastbares System.

Freitag, 09:15. Security schreibt im Ticket: „Der PR-Bot hat gestern prod-Credentials gesehen – wer hat freigegeben, was ist im Modell-Kontext gelandet, und wer haftet, wenn der Diff falsch grün war?“ Die Project-settings.json ist sauber. Was fehlt, ist die zweite Ebene: Nachvollziehbarkeit, Datenschutz und Rollen – nicht noch ein Allow-Pattern.

Handoff einmal klar. Dieser Abschnitt ist Orientierung – kein Rechtsgutachten, keine Freigabe (Stand Mitte/Ende 2026).

Du als Harness-Team: Deny, Managed, MCP-Allowlist, CI, Audit, Evidence.
Legal/DPO/Security: Use-Case (AI Act), DSGVO/AVV, Verträge, Freigabe.

Bei regulierten Daten, Personalentscheidungen oder kritischen Systemen zuerst Legal und Security – die Configs aus 6.1–6.7 sind Vorbereitung.

Wann du Legal und Security holst

Enterprise-Leser brauchen eine klare Stop-and-escalate-Schwelle – nicht noch eine Feature-Tabelle.

Hol Legal/DPO unter anderem bei:

• personenbezogenen oder besonderen Kategorien von Daten im Repo oder in Agent-Sessions
• Prompt-/Content-Logging, SIEM mit Volltext, Auswertungen mit Mitarbeiter-Monitoring-Nähe
• Cloud-Region, AVV/DPA, Enterprise-Zusatz, Subprozessoren
• AI-Act-Rollenfrage, High-Risk-Use-Cases, Personal- oder Leistungsentscheidungen

Hol Security/IT unter anderem bei:

• Managed Policy org-weit, MCP-Allowlist, Key-Rotation, Bypass-Policy
• CI mit Cloud-Rechten, prod-nahe Runner, Incident-Playbook
• Telemetrie-Endpoint und Zugriff auf Audit-Logs

Was du vorher liefern kannst (Evidence-Paket, oft eine halbe Seite):

1. Use-Case in einem Satz (z. B. Coding-Assistent im Dev-Alltag – keine Personalbewertung)
2. Datenfluss-Skizze (Provider, MCP, CI, OTel – Content-Logging ja/nein)
3. Policy-Artefakte (CLAUDE.md, settings, relevante Managed-Felder)
4. Ownership: wer mergt, wer darf bypassPermissions

Legal und Security beantworten ob und unter welchen Bedingungen – du zeigst was technisch passiert. Ohne Skizze wird aus dem Termin ein Config-Workshop.

Drei Audit-Schichten – nicht „ein Log“

„Wir loggen doch irgendwas“ reicht im Incident nicht. Es gibt typischerweise drei Quellen, die sich ergänzen:

Schicht	Was sie typisch sieht	Was sie nicht ersetzt
Claude Code OpenTelemetry	Endpoint-Sessions: Nutzung, Kosten, Tool-Aktivität; optional Events/Traces	Org-Admin-Events und Web-Chat außerhalb von Code
Org-/Enterprise-Audit (Admin / Compliance API, je Plan)	Logins, Org-Änderungen, admin-seitige Spuren	Den feinen Tool-Loop auf dem Laptop
Lokale/Team-Spuren	Hooks, CI-Artifacts, PR-Comments, /export, Git	Zentrale Policy und org-weite Retention

Wie OTel im Harness greift: Claude Code kann Metriken und Events per OpenTelemetry exportieren (CLAUDE_CODE_ENABLE_TELEMETRY, OTLP-Endpoint, Exporter). Administratoren können die Telemetrie über Managed Settings (env) org-weit setzen – Entwickler sollen den Collector nicht „privat umbiegen“. Details und aktuelle Variablen: Monitoring-Doku.

Content ist opt-in. Prompt-Text, Tool-Argumente und Response-Inhalte sind in der Doku nicht der Default – Flags wie OTEL_LOG_USER_PROMPTS (und verwandte Tool-/Content-Schalter) schalten sie erst ein. Das ist Absicht: Metadata first senkt Datenschutz- und Retention-Risiko.

Skizze Managed-Telemetrie (Host und Token sind Platzhalter; Flags in der Doku gegenprüfen):

{
  "env": {
    "CLAUDE_CODE_ENABLE_TELEMETRY": "1",
    "OTEL_METRICS_EXPORTER": "otlp",
    "OTEL_LOGS_EXPORTER": "otlp",
    "OTEL_EXPORTER_OTLP_PROTOCOL": "grpc",
    "OTEL_EXPORTER_OTLP_ENDPOINT": "http://collector.example.com:4317",
    "OTEL_EXPORTER_OTLP_HEADERS": "Authorization=Bearer YOUR_TOKEN"
  }
}

Org-Audit vs. Endpoint-OTel: Enterprise-Audit-Logs bzw. Compliance APIs (wo im Plan verfügbar) decken die Kontrollebene ab – wer sich anmeldet, was an Org-Rechten passiert. Sie ersetzen nicht den Session-Trace auf dem Developer-Laptop. Für die vollständige Story brauchst du oft beide plus CI/Git.

Hooks und /export: PreToolUse kann zusätzlich loggen oder blocken – das ist Team-Spur, keine SIEM-Strategie. /export sichert ein Gespräch für Postmortem oder Lernen; es ist kein zentrales Audit mit Retention-Policy.

Im Incident willst du rekonstruieren wer, wann, welches Tool, allow/deny, welcher CI-Job – nicht monatelang Volltext-Prompts mit Kundendaten aus dem Diff. Prompt-Logging ist eine bewusste Datenschutz-Entscheidung, kein Default „für Compliance“.

Intern festhalten (Checkliste, keine Magie):

1. Wer darf Telemetrie und Org-Audit einsehen?
2. Retention und Löschkonzept?
3. Alerts auf ungewöhnliche Muster (bypassPermissions, neue MCP-Server, CI-Kosten-Spikes)?
4. Wer rotiert Keys und prüft die Allowlist?

Datenschutz: was die Session wirklich verlässt

Neben der Tool-Angriffsfläche (6.3) zählt der Datenfluss: Was im Kontext liegt, kann zum Provider, zu MCP-Servern, in Telemetrie oder in CI-Logs wandern – oft ohne dass es sich wie ein klassischer „Upload“ anfühlt.

Pfad	Beispiele	Steuerhebel
Modell / Provider	Dateiinhalte, Prompts, Tool-Outputs	Scope eng, Deny auf Secrets, keine Prod-Dumps im Chat
MCP-Drittserver	Issues, Tickets, DB-Tools	Allowlist, Credential-Review (Kap. 5/6)
Telemetrie / SIEM	Metriken, optional Prompt-Inhalt	OTel-Flags, Managed Endpoint, Zugriffskontrolle
CI-Runner	Diffs, Env-Secrets	least privilege, enge Prompts, kein Auto-Merge
Lokaler Export	/export, Session-Artefakte	Aufbewahrung und Share-Policy im Team

Repo-Klassifikation hilft vor dem ersten Prompt: intern vs. personenbezogen vs. reguliert. Liegen Kundendaten oder Gesundheitsdaten im Tree, ist die Agent-Session potentielle Verarbeitung – nicht erst der Produktions-Deploy.

Mitarbeiter und Transparenz: Wenn Sessions oder OTel ausgewertet werden, gehört das in die interne AI-/IT-Policy (und wo nötig Betriebsvereinbarung) – dieses Buch liefert keine Vertragsmuster.

Residenz und Verträge: Cloud-Region, Auftragsverarbeitung und Enterprise-Zusatzvereinbarungen klärst du mit Provider-Doku und Einkauf – nicht über eine Zeile in CLAUDE.md. Das Buch garantiert keine Speicherorte.

Handoff DSGVO / Datenschutz: Scope eng, Deny auf Secrets und Metadata-first steuert der Harness. Verarbeitungsgrundlage, Betroffenenrechte, AVV/DPA und interne Datenschutz-Policy entscheidet DPO/Legal – nicht dieses Kapitel. Trigger und Evidence-Paket: oben unter Wann du Legal und Security holst.

Achtung: Volltext von Prompts und Tool-Inhalten ins SIEM zu schieben multipliziert Retention-, Zugriff- und Leak-Risiken. Starte mit Metadaten; Content nur mit klarem Zweck, Zugriff und Löschfrist.

EU AI Act: Use-Case vor Feature-Flag

Der EU AI Act (im Folgenden: AI Act) ist kein Schalter in settings.json. Ob und welche Pflichten greifen, hängt von Rolle (Anbieter vs. Betreiber) und Use-Case ab – und von der jeweils geltenden Frist. Legal/DPO klassifizieren; das Harness liefert höchstens Belege (Policies, Logs, Review-Pflicht).

Typische Einordnung (Orientierung, Stand 2026): Ein Coding-Assistent im normalen Entwicklungsalltag (schreiben, reviewen, refaktorieren, debuggen) fällt oft nicht unter die Annex-III-High-Risk-Kategorien. Sobald dieselbe Telemetrie oder derselbe Bot Mitarbeiter bewertet, Personal- oder Leistungsentscheidungen steuert oder in einem regulierten Hochrisiko-Kontext entscheidet, ändert sich das Bild – dann ist es kein „nur Claude Code“-Problem mehr.

Provider-Pflichten für das GPAI-Modell (General-Purpose AI) liegen primär beim Anbieter. Was dein Team steuert, sind betreibernahe Praktiken: Aufsicht, Transparenz, Dokumentation, Risikobewusstsein.

AI-Act-nahe Erwartung	Harness-Praxis in diesem Buch
Menschliche Aufsicht	Diff lesen; kein Auto-Merge; kein bypassPermissions als Alltag (siehe CI in 6.4)
Transparenz	Team-Policy: wann AI-Hilfe ok; optional Hinweis im PR
Nachvollziehbarkeit / Doku	CLAUDE.md + settings im Git; OTel/Org-Audit; CI-Artifacts; PLAN.md
Risikominderung	Deny Secrets, MCP-Allowlist, Managed Policies
Keine Schein-Compliance	OTel nicht als heimliche Produktivitätsüberwachung missbrauchen

Die Hebel aus 6.1–6.7 (Standards, Managed, Deny, CI, Ownership) sind dieselben, die Auditoren als „menschliche Kontrolle“ wiedererkennen – wenn du sie dokumentierst. Klassifizierung und Fristen: Legal/DPO (siehe Handoff oben).

Haftung und Ownership

Der Agent multipliziert Tempo – nicht die rechtliche oder organisatorische Verantwortung. Merge, Release und Prod-Zugriff bleiben menschlich; CI-Agenten sind Assistenten, keine Release-Manager (Brücke zu 6.4).

Typische Schadensklassen, die Configs mindern, aber Ownership nicht ersetzen:

• Secret im Kontext oder im MCP-Call
• Destruktive Shell trotz zu breitem Allow
• „Sicherer“ Bot-Review, dem niemand widerspricht
• Bypass ohne Audit-Spur

Rollen (praktisch): Dev (Diff lesen, Scope, keine Secrets im Chat); Tech Lead (CLAUDE.md/settings reviewen, Review-Pflicht); Security/IT (Managed Policies, MCP-Allowlist, Telemetrie, Key-Rotation); Legal/DPO (Use-Case-Klassifizierung, Verträge, interne AI-Policy).

Impressum und Anhang 8.12. Escalation und Evidence: Wann du Legal und Security holst (oben) – vor dem Rollout, nicht nach dem ersten Incident.

---

Jetzt selbst machen: Team-Baseline (ca. 20 Min)

In einem Demo-Repo (oder todo-cli als Sandbox – dort nicht force-pushen):

1. Root-CLAUDE.md aus vorlagen/CLAUDE.md.team.md (Begleit-Service → Material; nicht Anhang A) anpassen – oder zuerst A.1 und später Team-Vorlage.
2. .claude/settings.json aus A.3 oder vorlagen/settings.permissions.json – Deny für .env*, Allow für Tests/Git-Status.
3. .gitignore: CLAUDE.local.md, .claude/settings.local.json (A.2).
4. Session: claude doctor und /status – Project-Settings sichtbar?
5. Optional: Workflow aus beispiele/configs/github-actions-claude.yml (nur online) nach .github/workflows/ kopieren und lokal gegen die aktuelle Action-Doku prüfen (Secret erst auf einem Test-Repo).
6. Optional (~5 Min, Compliance): Zehn Zeilen Evidence-Notiz (Wiki oder gitignored docs/ai-use.md) – Use-Case in einem Satz, Provider/MCP/CI, wer merged, Prompt-Content in Telemetrie ja/nein; bei regulierten Daten: „Legal/DPO vor Pilot?“ als offene Frage.

Erfolgskriterien:

• Ein frischer Clone hat CLAUDE.md + Project-Settings ohne Slack-Thread
• /status oder doctor zeigt Project-Quelle
• Du kannst erklären, warum Managed erst nach dem Pilot kommt
• CI-Workflow (falls angelegt) hat least-privilege permissions: und keinen Auto-Merge
• Du kannst die drei Audit-Schichten in einem Satz unterscheiden
• Du kannst in einem Satz sagen, wann Legal/DPO bzw. Security übernehmen

---

Checkliste – Team-Rollout

• CLAUDE.md + settings im Repo
• Managed baseline auf Pilot-Laptops getestet (claude doctor)
• MCP-Allowlist definiert
• Ein CI-Job im dry-run
• Skill verify verpflichtend vor PR (sozial oder per Hook/CI)
• Incident-Playbook: leaked key, rogue allow, hook-outage
• Audit-Story skizziert (OTel und/oder Org-Audit und/oder Hook/CI-Spuren)
• Entscheidung: Prompt-Content in Telemetrie ja/nein + grobe Retention
• Datenfluss-Skizze intern (Provider, MCP, CI) – auch wenn nur eine Seite
• Menschliche Review-Pflicht für AI-gestützte Änderungen festgehalten
• Eskalations-Trigger intern benannt (wann Legal/DPO, wann Security)
• Evidence-Paket für Pilot-Repo skizziert (Use-Case, Datenfluss, Policies, Ownership)
• Legal/DPO einbezogen, wo regulierte oder personenbezogene Daten im Repo liegen – vor breitem Rollout

Häufige Fehler

Dieselben Schmerzen wie in den Mikrogeschichten dieses Kapitels – Onboarding-Drift, CI-Lärm, Kontextkosten und die Compliance-Lücke hinter sauberen Denys:

Fehler	Folge	Fix
Jeder hat private Chaos-Config	„Bei mir funktioniert der Agent anders“	Project + Managed
CI mit vollen Cloud-Admin-Rechten	Blast radius	Least privilege
Subagents ohne Briefing	Doppelarbeit, Konflikte	Klare Rollen, Worktrees
Kosten nicht monitoren	Rechnungsspitze ohne Alert	usage + Budget-Alerts
Nur Deny, kein Audit	Incident nicht rekonstruierbar	OTel/Org-Logs + CI-Artifacts
Prompt-Volltext default loggen	Datenschutz- und Retention-Ballast	Metadata first
AI-Act als settings-Feature	Scheinsicherheit	Use-Case + Legal; Harness als Evidence
Buch-Abschnitt oder Deny-Liste als „Freigabe“ behandelt	Scheinsicherheit, Audit-Lücke	Legal/Security + Evidence; 6.8 ist Orientierung

Wenn du nur eines commitest: Project-CLAUDE.md + Deny-Basisset – der Rest baut darauf auf.

So baust du das in deinem Projekt nach

1. Pilot-Team (3–5 Personen), eine CLAUDE.md
2. Zwei Wochen: nur Project-Settings, Feedback
3. Managed Deny-Baseline
4. Ein CI-Review-Job auf internen PRs
5. Skill-Bibliothek wächst aus echten Wiederholungen
6. Audit- und Datenfluss-Skizze (6.8) und Entscheidung, ob Legal/DPO vor dem ersten regulierten Repo-Pilot nötig ist

Erfolgskriterien (Team): Neuer Dev startet in unter einer Stunde mit denselben Allows/Denies; ein CI-Review-Job läuft auf Draft-PRs; niemand braucht private „magische“ settings für den Standard-Workflow; Security kann im Incident die drei Audit-Schichten benennen.

Managed ohne Feedback erzeugt Schatten-Workarounds. Zuerst lernen, was das Team braucht – dann erzwingen, was unverhandelbar ist.

---

Was du jetzt kannst

• Team-Baseline (Git) vs. Managed Policy (Org) unterscheiden und begründen
• Team- und Managed-Konfiguration entwerfen und begründen
• CI-Integration risikobewusst skizzieren (least privilege, kein Auto-Merge)
• Multi-Agent und Kostenhebel einordnen
• Drei Audit-Schichten und typische Datenflüsse einordnen
• Benennen, wann Legal/DPO bzw. Security übernehmen und welches Evidence-Paket du vorbereitest
• Begründen, warum Ownership und Haftung menschlich bleiben

Nächste Schritte

→ Kapitel 07 – Best Practices und Troubleshooting: wenn es hakt – systematisch debuggen.