AI Landing Zone und AI Compliance as Code: das Governance-Pattern

Pexon Consulting | 12 Min. Lesezeit | 10.06.2026

TL;DR

AI Landing Zone plus AI Compliance as Code ist 2026 die Antwort auf die Skalierungs-Frage bei AI-Workloads in regulierten Branchen: Statt jede Agent-Initiative compliance-individuell aufzubauen, gibt es eine vordefinierte Landing Zone mit Networking, Identity, Encryption, Logging, in der AI-Workloads automatisch den Compliance-Baseline erben. Plus AI Compliance as Code: Policies (DSGVO, AI-Act, BaFin, KRITIS) werden als Code formuliert (OPA, Rego, Sentinel) und automatisch durchgesetzt. Pexon Consulting baut das als 12-16-Wochen-Sprint für regulierte Mittelständler.

Warum AI-Governance 2026 systematisch wird

Wir hören das in fast jedem CISO-Erstgespräch mit Versicherern, Energieversorgern und regulierten Mittelständlern: Das Unternehmen hat über die letzten 18 Monate sechs bis zwölf Agent- und KI-Initiativen produktiv gebracht. Jede Initiative hat ihre eigene Compliance-Story gebaut, ihre eigene Auth-Anbindung, ihre eigene Logging-Praxis. Bei der nächsten Auditrunde wird klar: Konsistenz gibt es nicht. compliance für cloud & ki, die euer business nicht ausbremst — sondern

Das Problem ist nicht böser Wille. Das Problem ist, dass jede Initiative gestartet wurde, bevor die Governance-Frage strukturell beantwortet war. Bei jedem Setup wurde die DSGVO-Folgenabschätzung neu gemacht, die Auth-Anbindung neu verhandelt, die Audit-Trail-Logik neu erfunden. Skaliert nicht. Und ab August 2026 mit den ersten zwingenden EU-AI-Act-Pflichten für Deployer wird das zum echten Problem.

Die Antwort ist ein zwei-stufiges Pattern. Erstens AI Landing Zone: Eine vordefinierte Cloud-Architektur, in der AI-Workloads automatisch den Compliance-Baseline erben — analog zur klassischen Cloud Landing Zone bei Azure/AWS, aber AI-spezifisch erweitert. Zweitens AI Compliance as Code: Compliance-Anforderungen werden als Policies in Open Policy Agent (OPA), Sentinel oder vergleichbaren Engines formuliert und automatisch beim Deploy durchgesetzt.

Was eine AI Landing Zone konkret enthält

Wir bauen die AI Landing Zone in sechs Komponenten.

Komponente 1: Netzwerk-Segmentierung. Separate VNets oder VPCs für AI-Workloads, mit klaren Firewall-Regeln zwischen AI-Zone und Rest des Unternehmens. Egress-Whitelisting auf die erlaubten Cloud-LLM-Endpoints (Bedrock mit EU-Profil, Azure OpenAI Sweden, etc.). Privater Endpoint zu Datenbanken und Speicher.

Komponente 2: Identity- und Zugriffs-Layer. Entra ID oder Keycloak als zentrales IdP, mit Privileged Identity Management für Admin-Zugriffe, Conditional Access für User-Sessions, App Registrations pro AI-Workload mit klaren Permissions-Scopes. Mehr zu User-Identity in Agent Permissions Entra ID.

Komponente 3: Encryption- und Secrets-Verwaltung. Customer-Managed Keys in Azure Key Vault oder AWS KMS, regelmäßige Rotation, klar definierte Secret-Lifecycle-Prozesse. AI-Modell-API-Keys werden zentral verwaltet, nicht in Workload-Code hardcoded.

Komponente 4: Logging und Audit-Trail. Zentraler Log-Aggregations-Workspace, in den alle AI-Workloads ihre Aufrufe streamen. Retention nach branchen-spezifischen Vorgaben. Integration in euer SIEM (Sentinel, Splunk). Bei MCP-basierten Setups Integration in das gleiche Tracing-Pattern wie MLflow LangGraph Tracing.

Komponente 5: Cost-Governance. Budget-Caps pro Workload und User, Anomalie-Erkennung bei plötzlichen Token-Spikes, monatliche Cost-Reports pro Cost-Center. Bei kritischen Use-Cases harte Stops bei Budget-Erreichen, nicht nur Warnungen.

Komponente 6: Agent Registry plus AI-Workload-Inventar. Zentrales Verzeichnis aller AI-Komponenten, mit Owner, Lifecycle-Stadium, Compliance-Status, AI-Act-Klassifikation. Mehr zur Agent Registry.

Diese sechs Komponenten sind als Terraform- oder Bicep-Templates implementiert, mit klar dokumentierter Architektur. Neue AI-Workloads deployen in die Landing Zone und erben den Compliance-Baseline.

AI Compliance as Code: Policies als ausführbarer Code

Statt Compliance-Anforderungen in Word-Dokumenten zu pflegen und auf Code-Reviews zu hoffen, formulieren wir sie als ausführbaren Code, der beim Deploy automatisch geprüft wird.

package ai.governance

# Deny: Cloud-LLM-Workloads dürfen nicht ohne klassifizierte Daten-Annotation deployen
deny[msg] {
    input.workload.type == "ai-cloud-llm"
    not input.workload.data_classification
    msg := sprintf("Workload %v braucht data_classification (public, internal, confidential, secret)", [input.workload.name])
}

# Deny: Workloads mit confidential oder secret data dürfen nicht in US-Region deployen
deny[msg] {
    input.workload.data_classification in ["confidential", "secret"]
    input.workload.region in ["us-east-1", "us-west-2", "eastus"]
    msg := sprintf("Workload %v mit %v-Daten darf nicht in US-Region %v deployen", 
        [input.workload.name, input.workload.data_classification, input.workload.region])
}

# Deny: Workloads mit secret data dürfen nur auf Whitelist-Modelle
deny[msg] {
    input.workload.data_classification == "secret"
    not allowed_models_for_secret[input.workload.model]
    msg := sprintf("Workload %v mit secret-Daten darf nicht Modell %v nutzen", 
        [input.workload.name, input.workload.model])
}

allowed_models_for_secret := {
    "on-prem-qwen-3-5",
    "on-prem-llama-3-3",
    "datagroup-defensecloud-claude",
}

# Deny: High-Risk-AI-Act-Workloads brauchen Risk-Management-Doku
deny[msg] {
    input.workload.ai_act_classification == "high_risk"
    not input.workload.risk_management_doc_url
    msg := sprintf("Workload %v als High-Risk klassifiziert, braucht Risk-Management-Doku-Link", [input.workload.name])
}

Was hier passiert: Vier konkrete Policies, die bei jedem Deploy in der CI-Pipeline ausgeführt werden. Wenn eine Policy deny zurückgibt, wird das Deploy gestoppt. Damit fällt die Compliance-Lücke von „wurde im Review vergessen“ weg — das System lässt nicht-konformes Deploy nicht durch.

OPA ist die Open-Source-Engine, die wir typisch einsetzen. Bei reinen Azure-Setups nutzen wir alternativ Azure Policy mit eigenen Custom-Definitions. AWS-Setups bekommen Cloud Custodian oder Sentinel.

Mapping auf konkrete Regulator-Anforderungen

Die Policies sind nicht abstrakt, sondern direkt aus Regulator-Vorgaben abgeleitet.

DSGVO Art. 32: Technische und organisatorische Maßnahmen zum Schutz personenbezogener Daten. Policy: „Workloads mit personenbezogenen Daten müssen Encryption-at-Rest und Encryption-in-Transit aktiviert haben, EU-Region nutzen, Audit-Trail aktivieren.“

EU AI Act Art. 16-29 (High-Risk-Systeme): Risk Management, Data Governance, Technical Documentation, Record-Keeping, Transparency, Human Oversight, Accuracy and Robustness. Policy: „High-Risk-AI-Workloads brauchen verlinkte Risk-Management-Doku, Trainings-Data-Lineage, Human-in-the-Loop-Konfiguration.“

BaFin BAIT (Bankaufsichtliche Anforderungen IT): Strenge Anforderungen an Identity, Audit, Recovery. Policy: „Banking-Workloads müssen PIM für Admin-Access aktiviert haben, Audit-Logs in dediziertem Workspace mit 10-Jahres-Retention.“

KRITIS-Konkretisierung des BSI: Logging-Anforderungen, Vor-Ort-Audit-Rechte. Policy: „KRITIS-Workloads dürfen nur in BSI-C5-zertifizierten Regions deployen, Audit-Logs müssen in Loki oder eurem Sentinel landen, kein Default-Datadog-zu-US.“

KRITIS-Sektoren (Energie, Wasser, Lebensmittel etc.): Sektor-spezifische Anforderungen. Policy-Erweiterung pro Sektor.

Wir pflegen diese Mappings in einer kommentierten Bibliothek, die wir bei Pexon-Sprints anwenden. Bei jeder Regulator-Aktualisierung wird die Policy-Bibliothek aktualisiert, die produktiven Workloads erben das automatisch beim nächsten Deploy.

Pexon-Sprint-Setup

Wir liefern AI Landing Zone plus AI Compliance as Code als 12-16-Wochen-Sprint mit festem Preis.

Wochen 1-3: Architektur-Workshop mit IT-Sicherheit, Datenschutz, Compliance, Cloud-Engineering. Mapping eurer Regulator-Anforderungen auf konkrete Policies. Definition der Workload-Typen, die unterstützt werden sollen.

Wochen 4-7: Aufbau der Landing Zone als Terraform-/Bicep-Module. Netzwerk, Identity, Encryption, Logging, Cost-Governance, Agent Registry. Test-Deploy einer Pilot-Workload in die Landing Zone.

Wochen 8-11: Implementierung der OPA-Policies. CI-Integration für automatische Policy-Prüfung beim Deploy. Test-Suite mit positiven und negativen Beispielen.

Wochen 12-16: Migration der ersten zwei oder drei produktiven AI-Workloads in die Landing Zone. Schulung der Engineering-Truppe. Übergabe inkl. Architektur-Doku und Policy-Wartungs-Konzept.

Investment 175-280k EUR je nach Scope, Regulator-Tiefe und bestehender Cloud-Maturity. Für Banking, Versicherung, Energie und Defense ist das typisch der Sprint, der die nächste AI-Wave erst skaliert betreibbar macht.

Häufig gestellte Fragen

Wie unterscheidet sich AI Landing Zone von der klassischen Cloud Landing Zone?

Die klassische Cloud Landing Zone deckt die generischen Komponenten (Netzwerk, Identity, Encryption, Logging) ab. AI Landing Zone erweitert das um AI-spezifische Komponenten: Modell-Endpoint-Whitelisting, Token-Cost-Governance, Agent Registry, AI-Workload-Klassifikation. Wir bauen meist auf einer bestehenden Cloud Landing Zone auf, statt sie zu ersetzen.

Funktioniert AI Compliance as Code auch ohne OPA?

Ja. Azure Policy mit Custom Definitions deckt 80% der Use-Cases ab, AWS Cloud Custodian ähnlich. OPA ist die Cloud-agnostische und flexibelste Lösung, aber nicht zwingend. Bei reinen Azure-Setups vereinfachen wir oft auf Azure Policy.

Wie integriert sich das mit unserer bestehenden GRC-Plattform?

Standard-Pattern: Policies werden in OPA implementiert, Violation-Events landen in eurer GRC-Plattform (ServiceNow GRC, OneTrust, LogicGate) für Compliance-Tracking. Wir bauen den Connector als Standard-Komponente in den Sprint.

Was, wenn ein Workload eine Policy aus geschäftlichen Gründen brechen muss?

Wir bauen ein Exception-Pattern: Workload-Owner kann eine zeitlich begrenzte Exception beantragen, die vom CISO oder Compliance-Officer freigegeben werden muss. Exception-Status wird im OPA-Bundle mitgeführt, beim Deploy geprüft. Damit ist die Ausnahme dokumentiert und zeitlich begrenzt — nicht eine schleichende Compliance-Aushöhlung.

Wer pflegt die Policies langfristig?

Wir empfehlen einen kleinen Policy-Engineering-Pool (1-2 Personen aus Cloud-Engineering plus 1 Person aus Compliance), der die Policies versioniert wie normalen Code pflegt. Quarterly Review mit den Regulator-Updates. Wir bieten Pflege-Verträge als optionale Komponente nach dem Sprint.

Nächster Schritt

Wenn dein Unternehmen mehr als sechs AI-Initiativen produktiv hat und die Compliance-Lage individuell pro Initiative gebaut ist: Wir machen einen 60-Minuten-Architektur-Call mit dir und idealerweise dem CISO. Du beschreibst die Workload-Landschaft und die Regulator-Anforderungen, wir skizzieren die Landing Zone plus Policy-Setup mit Festpreis.

Verwandte Themen