Governance an der CI/CD-Grenze.
Compliance-Befunde, die erst nach dem Deploy auftauchen, sind teuer. Die meisten Tracker-vor-Consent-Issues, die meisten US-Transfer-Risiken, die meisten Modell-Wechsel landen ohne Prüfung in Production — schlicht weil das Tooling sie nicht sieht. Deployment Governance schiebt die Prüfung an die Stelle, wo eine Änderung bewertbar ist, ohne dass Produktion bereits betroffen ist.
Wann der Check feuert
Drei Trigger sind heute unterstützt: GitHub-PR-Hook (push, PR, release), Cloudflare-Pages-Deploy-Webhook (für statisch gebaute Sites) und GitLab-Pipeline-Hook. Die Check-Action liest den Diff, identifiziert Änderungen mit Governance-Relevanz und ruft die Policy-Engine an. Das Ergebnis landet als Check-Run auf der PR, plus ein strukturierter Kommentar mit Begründung.
Was als "governance-relevant" gilt
- Neuer Third-Party-Vendor (Tracker, AI-API, Mail-Provider, Analytics)
- Veränderter Tracking-Stack: zusätzliches Script, anderes Tag-Manager-Configurierung
- AI-Modell-Switch (Provider, Version, Region) im Source
- Dataset-Erweiterung mit höherer PII-Klasse (Diff in der Dataset-Manifest-Datei)
- Consent-Bypass (Script ohne
data-consent-Gate) - Policy-Drift: lokale Policy-Files in einem Repo überschreiben Tenant-Policies
Risk-Delta
Die Engine berechnet drei Scores: Pre-Deploy-Risk (aktueller Stand), Post-Deploy-Risk (projiziert nach Merge), Delta. Konkret: ein neuer US-Vendor erhöht den Score um eine konfigurierte Konstante; ein neues Modell ohne ai_act_class-Tag triggert eine Reclassifikation; ein Tracker ohne Consent-Gate erhöht den Score um die TDDDG-§25-Penalty. Das Delta ist die Zahl, die in der Check-Box steht.
Gate-Outcomes
- allow — Delta unter konfiguriertem Schwellwert, kein Block, Evidence wird trotzdem sealed (für Audit-Lineage).
- warn — Check ist grün, aber Kommentar weist auf die Änderung hin. Owner-Team sieht den Hinweis im Review.
- require_approval — Check ist gelb. PR kann nicht gemerged werden ohne expliziten Approve-Klick vom Reviewer mit Compliance-Rolle.
- block — Check ist rot. Merge ist gesperrt durch die Branch-Protection-Rule, bis die zugrunde liegende Policy-Violation entweder behoben oder mit signiertem Override umgangen wird.
Was die Action liest
Die Action liest aus dem Repo: .well-known/governance.json (optional, für Self-Description des Repos), package.json (Dependency-Diff), HTML/JSX (Tracker-Detection per Pattern-Match auf bekannte Vendor-URLs), vercel.json /netlify.toml (Deploy-Config-Diff), CI-Files (workflow-Änderungen).
Was die Action nicht liest: produktive Datenbanken, Secrets, Source-Daten des Kunden. Die Analyse ist statisch und repo-lokal.
Override-Pfad
Manchmal muss man bewusst etwas mergen, das die Engine flaggt — z. B. ein experimentelles Feature-Flag, dessen Rollout policy-konform geplant ist. Der Override-Pfad ist explizit: Reviewer mit compliance_override-Permission klickt im PR-UI auf "Override", gibt einen Reason an, und der Event landet im Audit-Log mit action=deployment.override. Die Branch-Protection lässt den Merge zu. Aber: das Override ist auditbar, jeder zukünftige Auditor sieht wer wann was übersteuert hat.
Evidence für jeden Deploy
Jedes Gate-Outcome (allow, warn, require_approval, block, override) erzeugt einen Evidence-Record im Vault: kind=deployment_decision, mit dem PR-SHA als Subject, der Policy-Bundle-SHA, dem Risk-Delta, den verlinkten Controls. Bei Audits ist die Frage "wie habt ihr 2026-03-15 entschieden, dass dieser Tracker durchgewunken wurde?" in 30 Sekunden mit verifiable Hash beantwortbar.
Status der GitHub-Integration
Die Action ist im Blueprint §9 spezifiziert und Teil der Phase-2-Roadmap. Heute existiert die Policy-Engine, die Evidence-Vault-Anbindung und der Connector zu Jira/GitHub für Remediation-Tickets. Die PR-Check-Action selbst wird im nächsten Release-Zyklus veröffentlicht. Bis dahin können Tenants den Compliance-Loop manuell über die Connectors + den Telemetry-SDK abdecken.