Pexon Consulting | 12 Min. Lesezeit | 15.06.2026
TL;DR
Eine AI Landing Zone ist das compliance-konforme Azure-Fundament, auf dem produktive AI-Workloads in KRITIS und NIS2 ohne 9-Monats-Audit-Verzug starten. Pexon Consulting liefert die Landing Zone in 2 Wochen als Festpreis-Sprint zwischen 38 und 58k EUR mit Compliance-as-Code-Artefakten, dokumentiertem Audit-Trail und Policy-as-Code-Pattern aus 12+ produktiven Sprints.
Was eine AI Landing Zone konkret enthält
Wir hören das oft in CISO-Erstgesprächen bei KRITIS-Betreibern: „Wir wollen Generative AI produktiv bringen, aber die Compliance-Hürden lassen uns nicht starten.“ Die ehrliche Antwort ist meist nicht „AI ist zu riskant“, sondern „Euch fehlt das vorbereitete Fundament — die Landing Zone.“
Eine AI Landing Zone ist die Übertragung des Azure-Landing-Zone-Patterns auf AI-Workloads. Statt für jedes neue AI-Projekt erneut Netzwerk, Identity, Secrets, Monitoring und Compliance-Doku aufzubauen, liegt das Fundament fertig bereit. Neue AI-Use-Cases starten innerhalb von Tagen, nicht Monaten.
Die acht Komponenten einer produktionsfähigen AI Landing Zone bei Pexon.
1. Identity und Access-Layer. Entra ID als Single Source of Truth, Conditional Access für AI-Endpunkte, dedizierte Service-Principals pro Workload, klar getrennte Rollen (Engineer, Operator, Auditor). Mehr zum User-Identity-Propagation-Pattern für AI-Agenten.
2. Netzwerk-Isolation. Private Endpoints für Azure OpenAI, Azure AI Search, Storage-Accounts, Key Vault. Kein einziger AI-Endpoint mit Public IP. Hub-Spoke-Topologie mit dediziertem AI-Spoke pro Sensitivitäts-Klasse.
3. Key Management. Azure Key Vault mit Customer-Managed Keys für Verschlüsselung von Storage und Vector-DB. Keine API-Keys im Code, alles als Managed Identity oder Secret-Referenz.
4. Vector-DB-Layer. Azure AI Search oder pgvector als geschützte Backend-Komponente, abgesicherter Index-Layer mit Multi-Tenant-Isolation. Mehr zur Vector-DB-Auswahl für regulierte Setups.
5. Compute-Layer. AKS-Cluster mit Pod Security Standards, Image-Signing, automatisches Patching. Bei sensiblen Workloads on-prem GPU-Fallback verfügbar. Mehr zur Compute-Strategie zwischen Cloud und On-Prem.
6. Monitoring und Audit-Trail. Log Analytics mit dediziertem AI-Workspace, strukturierte Event-Schemata für jeden Retrieval-Lauf, jede LLM-Anfrage, jeden Tool-Use. SIEM-Integration in eure bestehende Security-Pipeline.
7. Cost-Governance. Quoten pro Workload, Hard-Limits pro Team, Tagging-Pflicht für Cost-Center-Reporting. Verhindert „Surprise-Bills“ durch Endlos-Schleifen oder Missbrauch.
8. Policy-as-Code-Layer. Azure Policy für Region-Lock auf EU West/Germany, verbotene SKUs, Pflicht-Tags. Wird beim Setup als Code deployed und ist Audit-Artefakt zugleich.
Was KRITIS und NIS2 konkret fordern
Hier ist die Lage 2026 nüchtern.
KRITIS gemäß BSI-Gesetz §8a: Betreiber kritischer Infrastrukturen müssen „angemessene organisatorische und technische Vorkehrungen“ treffen. Konkret: dokumentierter Stand-der-Technik, Audit-Trail, Incident-Response-Pipeline. Für AI-Workloads bedeutet das: Jede LLM-Anfrage muss nachvollziehbar sein, Daten-Klassifikation muss durchgesetzt werden, Verfügbarkeit muss messbar sein.
NIS2-Umsetzungs- und Cybersicherheits-Stärkungsgesetz: Das deutsche Umsetzungsgesetz erweitert den KRITIS-Begriff erheblich — mehr Branchen, mehr Unternehmensgrößen, härtere Meldepflichten (24h Frühwarnung, 72h Meldung, 1 Monat Abschlussbericht). Wer 2026 noch keine Compliance-Architektur für AI hat, läuft ab Q4 2026 in die Compliance-Lücke.
Die konkreten Anforderungen, die in der AI Landing Zone abgedeckt werden müssen.
Risikoanalyse-Pflicht. Pro AI-Workload eine dokumentierte Risikoanalyse mit Daten-Klassifikation, Verarbeitungs-Zwecken, Datenfluss-Diagramm. In der Landing Zone als Template, das pro Workload nur befüllt werden muss.
Audit-Trail für 6-12 Monate. Jede LLM-Anfrage mit User-ID, Tenant-ID, Query-Hash, Treffer-IDs, Output-Hash. Bei Banking 12 Monate, bei KRITIS-Versorgern 6 Monate Mindestaufbewahrung.
Incident-Response-Pipeline. Definierter Eskalationsweg bei Sicherheitsvorfällen, automatisierte Alarmierung, Forensik-Datenbestand. Mehr zum Multi-Tenant-Schutz mit Audit-Trail-Pattern.
Verfügbarkeits-Metriken. SLA-Definitionen pro Workload, gemessene Verfügbarkeit, Recovery-Time-Objective dokumentiert.
Mitarbeiter-Schulungen. Schulungsnachweise für alle Mitarbeiter mit Zugang zu AI-Systemen. Wir bauen das als Trainings-Modul mit jedem Sprint mit ein.
Compliance as Code — was das technisch bedeutet
Der entscheidende Hebel der Landing Zone. Statt Compliance-Doku in Word-Files zu pflegen, ist die Compliance der Code.
Azure Policy als Audit-Artefakt. Jede Compliance-Regel ist als Azure Policy deployed — und damit gleichzeitig erzwungen und dokumentiert.
// Beispiel: Region-Lock auf Germany / EU West
resource regionPolicy 'Microsoft.Authorization/policyAssignments@2023-04-01' = {
name: 'ai-region-lock-de-eu'
properties: {
displayName: 'AI workloads must run in DE or EU West'
policyDefinitionId: '/providers/Microsoft.Authorization/policyDefinitions/e56962a6-4747-49cd-b67b-bf8b01975c4c'
parameters: {
listOfAllowedLocations: {
value: ['germanywestcentral', 'westeurope']
}
}
enforcementMode: 'Default'
}
}Diese Policy verhindert nicht nur, dass jemand versehentlich einen AI-Service in US-East deployt — sie ist gleichzeitig der dokumentarische Nachweis für den BaFin- oder BSI-Audit, dass die Region-Beschränkung technisch erzwungen wird.
Infrastructure as Code für Audit-Reproduzierbarkeit. Der komplette Infrastruktur-Stack als Bicep oder Terraform versioniert in Git. Bei Audit-Frage „Wie war die Konfiguration vor 6 Monaten?“ reicht ein git checkout des passenden Tags. Wir liefern den Code als Customer-eigenes Repository, kein Lock-in.
Strukturierte Audit-Events. Jeder relevante Event wird in ein einheitliches Schema geschrieben — User, Tenant, Workload, Operation, Result, Timestamp.
audit_log.write({
"event_type": "rag.retrieve",
"workload_id": "kfz-claims-assistant",
"user_id": claims["sub"],
"tenant_id": claims["tenant_id"],
"query_hash": hashlib.sha256(query.encode()).hexdigest(),
"result_count": len(results),
"result_doc_ids": [r.metadata["doc_id"] for r in results],
"data_classification": "internal",
"timestamp": datetime.utcnow().isoformat()
})Diese Logs landen in einem dedizierten Log Analytics Workspace mit fixierter Aufbewahrungs-Dauer. Für den Audit wird ein Standard-Report ausgeführt, der die Compliance-Kennzahlen liefert.
Der 2-Wochen-Sprint im Detail
Was passiert in den 2 Wochen wirklich. Transparent, weil „2 Wochen“ leicht nach Marketing klingt.
Tage 1-2: Kick-off und Architektur-Workshop. Wir setzen mit eurem CISO, Engineering-Lead und Compliance-Officer ein 1,5-Tage-Architektur-Setup auf. Output: Zielarchitektur als Diagramm, Entscheidungen zu Subscription-Struktur, Region, Identity-Anbindung, Logging-Backend. Sie wissen nach Tag 2 was deployed wird.
Tage 3-7: Code-Aufbau und Initial-Deploy. Pexon-Engineering baut die Bicep- oder Terraform-Module für die acht Komponenten. Wir nutzen ein internes Repository mit getestetem Pattern aus 12+ Sprints. Initial-Deploy in eure Subscription am Ende der ersten Woche. Erstes RAG-Demo-Workload läuft Tag 7.
Tage 8-10: Compliance-Layer und Policy-Hardening. Azure Policies werden aktiviert, Audit-Trail-Pipeline an euer SIEM angebunden, Cost-Governance konfiguriert. Penetration-Test-Setup mit synthetischen Angriffsvektoren wird automatisiert.
Tage 11-14: Doku, Übergabe, Schulung. Compliance-Doku wird generiert (aus dem Code, nicht von Hand). Übergabe an euer Engineering-Team mit Hands-on-Workshop. Optional: Mitarbeiter-Trainings-Modul als ergänzender Sprint.
Was in 2 Wochen ehrlich NICHT geht
Wichtiger Abschnitt — sonst ist die Erwartung falsch gesetzt.
Migration eurer bestehenden AI-Workloads. 2 Wochen reichen für das Fundament plus einen Demo-Workload. Wenn ihr 8 produktive AI-Apps habt, die in die Landing Zone migrieren sollen, ist das ein eigenes Folgeprojekt (typisch 3-6 Wochen pro Workload).
SIEM-Anbindung an exotische Systeme. Wir liefern Standard-Integration für Sentinel, Splunk, ELK-Stack. Wenn ihr ein proprietäres SIEM betreibt, kann die Integration zusätzlich 1-2 Wochen brauchen.
KRITIS-Audit-Vorbereitung. Die Landing Zone liefert die technischen Voraussetzungen. Der eigentliche KRITIS-Audit braucht zusätzlich Compliance-Doku-Sichtung, Schulungs-Nachweise, Notfall-Übungen. Wir empfehlen, das parallel mit dem internen Compliance-Team aufzusetzen.
Mitarbeiter-Schulungen. Wir machen den Engineering-Hands-on-Workshop in den 2 Wochen. Flächendeckende Schulungen für alle Mitarbeiter mit AI-Zugang sind ein separates Trainings-Format (typisch 2-4 Tage über mehrere Wochen verteilt).
Sagen wir transparent, weil enttäuschte Erwartungen schlimmer sind als ein Sprint, der eine Woche länger dauert.
Pexon-Sprint und Folgekosten
Klare Investment-Übersicht.
Sprint-Festpreis: 38-58k EUR je nach Komplexität. Untere Spanne bei Single-Region-Setup mit Standard-SIEM, obere Spanne bei Multi-Region plus Hybrid-Cloud-Anbindung plus on-prem GPU-Fallback.
Laufende Cloud-Kosten: 800-2.500 EUR pro Monat für die Landing Zone selbst (Log Analytics, Key Vault, Private Endpoints, AKS-Cluster minimal). Workload-Kosten kommen je AI-Use-Case dazu.
Optional: Managed-Service-Option. Pexon übernimmt den laufenden Betrieb der Landing Zone (Updates, Patching, Audit-Trail-Monitoring, monatliche Compliance-Reports). Investment 4-7k EUR pro Monat je nach Umfang. Sinnvoll bei Banking/Versicherung ohne vollzeitlichen Cloud-Operator.
ROI-Vergleich: Ein nicht-vorbereitetes AI-Projekt im KRITIS-Umfeld braucht typisch 5-8 Monate vom Start bis zum Compliance-OK. Mit Landing Zone schrumpft das auf 4-8 Wochen. Bei einer Million EUR jährlichem AI-Business-Impact bedeutet das 250-450k EUR Beschleunigungs-Wert pro Projekt.
Häufig gestellte Fragen
Funktioniert das auch auf AWS oder GCP?
Ja. Wir liefern die Landing Zone für Azure (häufigster Fall in regulierten Branchen), AWS (Bedrock-zentrische Stacks) und GCP (Vertex AI). Die Compliance-Pattern sind cloud-übergreifend ähnlich, die konkreten Services unterscheiden sich. Pexon hat aktive Setups in allen drei Clouds.
Was kostet das Audit-Logging in der Praxis?
Bei einem Mittelständler mit 50.000 AI-Anfragen pro Tag bei 12-Monats-Aufbewahrung sehen wir typisch 180-340 EUR pro Monat Log-Storage. Bei höheren Volumen oder strengeren Aufbewahrungs-Zeiten skaliert es linear. Im Banking-Umfeld haben wir Setups mit 800-1.200 EUR pro Monat Log-Kosten gesehen.
Wir haben schon Azure Landing Zone — brauchen wir die AI-Variante extra?
Häufige Frage. Standard-Azure-Landing-Zone deckt klassische IT-Workloads ab. Für AI braucht ihr zusätzlich: Vector-DB-Layer mit Tenant-Isolation, dedizierte Logging-Schemata für LLM-Anfragen, Cost-Governance für token-basierte Verbräuche, Policy-Set für AI-spezifische Region-Locks (Azure OpenAI ist nicht in jeder Region verfügbar). Wir bauen das als Erweiterung eurer bestehenden Landing Zone, kein Parallelbau.
Wie verhält sich die Landing Zone zu BSI C5-Testat?
C5 ist ein Audit-Framework des BSI für Cloud-Anbieter (nicht direkt für Cloud-Kunden). Eure AI Landing Zone in Azure kann auf C5-testierten Microsoft-Services aufbauen — das ist eine Voraussetzung für KRITIS-konforme Setups. Wir nutzen ausschließlich C5-testierte Services in der Standard-Landing-Zone.
Wer haftet bei Compliance-Vorfall?
Vertraglich liegt das Restrisiko bei euch als Datenverarbeiter. Pexon haftet im Sprint-Vertrag für Engineering-Qualität (vereinbarte Architektur korrekt umgesetzt, dokumentierte Pattern angewendet, Standard-Pen-Test erfolgreich). Für den laufenden Betrieb und die operative Compliance braucht es interne Verantwortlichkeit — die kann optional als Pexon Managed Service ausgelagert werden.
Nächster Schritt
Wenn dein Unternehmen unter KRITIS- oder NIS2-Pflicht fällt und AI-Workloads produktiv bringen will: Wir machen einen 60-Minuten-Architektur-Call mit dir und idealerweise dem CISO. Du beschreibst die geplante Workload-Landschaft und Compliance-Anforderungen, wir skizzieren den 2-Wochen-Sprint mit Festpreis.
Verwandte Themen
→Compute-Strategie zwischen Azure Foundry, Bedrock und On-Prem GPU
→Multi-Tenant-Schutz mit Defense-in-Depth-Pattern
→User-Identity-Propagation mit OAuth On-Behalf-Of-Flow
