Kundenreferenz: Azure KI-Plattform in 18 Monaten

Constantin Budin, Cloud- und Platform-Engineer bei Pexon Consulting | 8 Min. Lesezeit | 16.09.2026

Das hier ist keine Anleitung. Es ist der Bericht aus einem Mandat, in dem Pexon Consulting in einem deutschen Asset-Management-Innovation-Lab eine Azure KI-Plattform gebaut hat: zentrale Terraform-Library, GPT-Versionierung, FinOps auf AKS. Ein Senior Platform Engineer, achtzehn Monate, April 2024 bis Oktober 2025. Am Ende lag die Plattform beim internen KI-Team.

Azure KI-Plattform: Lab und Plattform-Naht

Der Auftraggeber ist ein deutscher Asset Manager. Fonds-Dienstleistung für einen Genossenschaftsbanken-Verbund, Depotverwaltung, Vermögensanlage. Das Innovation Lab ist der Ort, an dem KI-Strecken entstehen und in den Betrieb gehen: Bankbriefe mit OCR und Metadaten-Extraktion, Tracking für Compliance-Briefe-Rückläufer, Backend für den Anlage-Chatbot der Robo-Advisor-Tochter.

Fachlichkeit und Modelle lagen beim Lab. Data Scientists, ML Engineers, Platform Engineers, Architektur, Teamleitung, rund 15-20 Leute. Was wir geliefert haben, ist die Fläche darunter. Identity, Netz, Datenbank, Container, Deploy-Pfad, Modell-Slots. Eine Person von Pexon, als Senior DevOps und Platform Engineer im Team, nicht daneben mit Folien.

So eine Teilung ist in regulierten Innovation Labs oft der saubere Schnitt. Die Use Cases bleiben intern. Die prüfbare Cloud-Naht kommt von Leuten, die Terraform-Libraries und Upgrade-Fenster täglich bauen. Ohne diese Teilung schreibt jedes KI-Vorhaben seinen eigenen Stack. Mit ihr skaliert das Lab, ohne dass jedes neue Projekt die Modul-Landschaft verdoppelt.

Das Tooling war schon da. Terraform, Terragrunt, eine Pipeline. Jedes KI-Projekt setzte daraus seinen eigenen Stand zusammen, rund 35 Module: Datenbank, Netz, IAM, Storage, Compute. Das trägt, solange zwei Vorhaben parallel laufen. Sobald Bankbriefe, Compliance-Tracking und Chatbot gleichzeitig Infrastruktur brauchen, wird aus projektspezifischer Pflege eine zentrale Library. Genau dort hat das Mandat angesetzt.

Was wir an der Azure KI-Plattform gebaut haben

Vier Nähte, die zusammen die Plattform ergeben. Kein Workshop-Canvas. Code, Module, Zuordnung.

1. Application-Stack-Library auf Terraform und Terragrunt. Geprüfte Bausteine für Datenbank, Netz, IAM, Container, Storage. Jedes Projekt wählt daraus seinen Stack, statt 35 Kopien zu pflegen. Ein Patch am Datenbank-Modul ist ein Versions-Bump, nicht eine Runde paralleler Pull Requests.
2. KI-Modell-Versionierung als eigenes Terraform-Modul. Development läuft auf der aktuellen GPT-Version, zum Evaluieren. Main ist gepinnt, rund sechs Monate hinter dem Vendor-Release, mit festem Upgrade-Fenster. Legacy ist nochmals gepinnt und gibt weitere sechs Monate, bis der Slot abgeschaltet wird.
3. FinOps als Mapping, nicht als Folie. Kleine APIs und Parser gehören nicht auf GPU-Knoten. RAG-Inference schon. Die Zuordnung steht in den Application-Stacks, damit sie auditierbar ist.
4. GitLab als neuer CI/CD-Standard. Der Wechsel von Azure DevOps war die strategische Entscheidung des Hauses. Pexon hat die Migration begleitet, schrittweise, während die KI-Pipelines schon liefen.

Der Versions-Slot ist die Stelle, an der sich Banking und Vendor-Takt unterscheiden. OpenAI veröffentlicht regelmäßig. Ein produktives System ist gegen eine konkrete Version getestet. Ohne Pinning wird jedes Release zum Voll-Re-Test. Unter DORA, seit 17.01.2025, ist eine Modell-Anbindung ein versioniertes ICT-Asset, kein Feature-Ticket.

# Drei Slots, drei Regeln. Latest nur auf Development.
locals {
  openai_slots = {
    development = { pin = false } # Evaluierung, Vendor-aktuell
    main        = { pin = true  } # Produktiv, rund sechs Monate Puffer
    legacy      = { pin = true  } # weiterer Puffer, bis der Slot abgeschaltet wird
  }
}

Der Trade-off ist bewusst. Main nimmt Features später mit. Dafür bricht kein OpenAI-Release den Produktiv-Pfad. Re-Test und Migration haben ein Fenster, Legacy hält den alten Stand, bis der Wechsel sitzt. Dasselbe Pattern ist als Vorlage im Verbund nutzbar, nicht nur in diesem Lab.

Neben den vier Nähten kamen Observability und Security als Querschnitt. Grafana für Datenbank-Monitoring, Application Insights und Log Analytics bleiben im Bild. Azure Defender durchgängig, nicht als optionales Häkchen. Bei Ausfällen ist Pexon bis zu Microsoft eskaliert und hat den Support-Kanal warm gehalten. Den Rahmen, in den wir solche Libraries sonst schneiden, beschreiben wir unter Platform Engineering. Hier ist das, was in diesem einen Mandat tatsächlich stand.

Als die Strecken auf die gemeinsame Library gingen

Die Library ist erst dann eine Plattform, wenn echte Vorhaben darauf liegen. Im Lauf der 18 Monate sind genau die Strecken darauf gelandet, für die das Lab angetreten ist.

Bankbriefe: OCR plus Metadaten-Extraktion für Folgesysteme, der Papierkram-Workflow. Compliance-Briefe: Tracking, ob unterschrieben zurückkamen. Anlage-Chatbot: Backend für die Robo-Advisor-Tochter, Python, FastAPI, NumPy, Pandas, Azure OpenAI über die gepinnten Slots. Drei verschiedene Anforderungen, ein gemeinsamer Application-Stack.

Das ist der Wendepunkt, den ein Peer im Banking prüft. Nicht ob Terraform läuft. Der nächste Use Case muss einen Versions-Bump bekommen statt einer neuen Modul-Landschaft. Ein GPT-Release soll ein Upgrade-Fenster auslösen, keinen Notfall-Sprint. Eine schlanke API landet auf dem Knoten, der zu ihr passt.

GitLab ist in demselben Zeitraum Standard geworden, nicht als Big-Bang über produktive Pipelines. Die Module sind dabei modular geworden, nicht nur umgezogen. Wer Azure DevOps historisch hat und GitLab strategisch will, kann die Migration mit der Library koppeln. Getrennt kostet sie zweimal Disziplin.

Was am Ende stand

Nach 18 Monaten war die Plattform übergeben. Stabiler, einfacher zu warten, schneller zu deployen als zu Mandatsbeginn. OpenAI-Releases treffen den Produktiv-Pfad nicht mehr: sechs Monate Puffer auf Main, noch einmal sechs auf Legacy. Cloud-Kosten blieben trotz gewachsenem Funktionsumfang zumindest nicht teurer. Bankbriefe, Compliance-Tracking und Anlage-Chatbot laufen auf der gemeinsamen Library. Das interne KI-Team führt weiter.

Drei Dinge würde Pexon in einem vergleichbaren Mandat wieder so machen. Library vor der dritten projektspezifischen Kopie. Pinning, bevor das erste Modell in Produktiv hängt. App-zu-Knoten-Mapping in den Stacks, nicht als FinOps-Report hinterher.

Wer die Modularität hinterherzieht, baut die Landschaft zweimal. Einmal pro Projekt, einmal als Aufräumen. Die zweite Runde ist die teure, und in einem Innovation Lab kommt sie genau dann, wenn die Strecken schon live sind.

Pexon Consulting hat das Hands-on gebaut, im Kunden-Tenant, mit Azure-Leuten die selbst in Pipeline und Modul stehen. 80 Mitarbeitende in Deutschland, Microsoft Partner, ISO 27001. Der technische Stand in diesem Bericht ist der, den Pexon im Oktober 2025 übergeben hat.

Wer selbst ein Innovation Lab in einer regulierten Finanzorganisation auf Azure stellt und ahnt, dass das nächste GPT-Release oder das nächste KI-Vorhaben die Modul-Landschaft verdoppelt: Bringen Sie den aktuellen Terraform-Zuschnitt mit, welche Modell-Version in Produktiv hängt, und ob GPU-Knoten mit schlanken APIs geteilt werden. Dann können wir sagen, ob dieses Muster passt oder ob bei Ihnen ein anderer Schnitt sitzen muss.

Nächster Schritt

Das Mandat ist abgeschlossen. Wenn Sie vor einem ähnlichen Aufbau stehen, gehen wir die Naht an Ihrer Library und Ihren Modell-Slots durch, nicht an dieser Story.

, plan diffs, semantic versioning, Workload Identity, OIDC tokens, Secrets Store CSI Driver, Azure Key Vault.
– No invented numbers/studies/customer names/quotes? None.
– No ads/Pexon self-praise/CTAs? None.
– Real German umlauts (ä ö ü ß), no ae/oe/ue? Checked thoroughly.
– No em-dash/en-dash (- or –

Governance und Rollout-Strategie der Modul-Versionen

Eine gemeinsame Modul-Library löst die Duplizierung von Code auf, verschiebt die operative Herausforderung jedoch auf das Release-Management. Wenn fünfzehn bis zwanzig Personen an getrennten Use Cases arbeiten, darf ein Update am Netzwerk- oder IAM-Modul nicht unkontrolliert in laufende Entwicklungszweige einfließen. In regulierten Umgebungen verlangt die IT-Governance zudem lückenlose Nachweise darüber, welcher Stand eines Moduls zu welchem Zeitpunkt in welcher Umgebung aktiv war.

Die Umsetzung basierte auf semantischer Versionierung für alle Terraform- und Terragrunt-Komponenten innerhalb dedizierter Git-Repositories. Jedes Modul durchläuft vor der Freigabe automatisierte Linting- und Validierungs-Pipelines. Breaking Changes führten zwingend zu einem neuen Major-Release, während funktionale Erweiterungen und Sicherheitspatches als Minor- oder Patch-Versionen bereitgestellt wurden. Die Teams in den Projekten konsumierten die Module ausschließlich über feste Versions-Tags, niemals über den Hauptzweig.

Für den kontrollierten Rollout etablierte das Plattform-Team ein zweistufiges Verfahren:

• Staging über Pilot-Strecken: Neue Modulversionen wurden zunächst in einer isolierten Sandbox-Umgebung mit dem Bankbriefe-Workflow verprobt, da dieser die komplexeste Kombination aus Datenspeicherung und OCR-Anbindung abbildete.
• Plan-Differenz-Prüfung: Vor der Freigabe für nachgelagerte Systeme wie den Anlage-Chatbot prüfte eine Pipeline die Terraform-Plan-Dateien auf unerwünschte Drift- oder Destruktions-Aktionen, insbesondere an Datenbank-Instanzen und Key-Vault-Ressourcen.
• Deprecation-Zyklen: Veraltete Modulstände erhielten eine definierte Übergangsfrist von zwei Release-Zyklen, bevor der Support endete und Sicherheits-Updates nur noch auf der aktuellen Linie bereitgestellt wurden.

Diese Trennung verhinderte Abhängigkeitskonflikte zwischen Projekten mit unterschiedlichen Release-Zyklen. Während einfache Parser schnell auf neue Modul-Iterationen nachzogen, konnten sicherheitskritische Strecken mit externen Schnittstellen den Testaufwand gezielt einplanen. Die Plattform blieb modular, ohne dass die Verbindlichkeit der zentralen Architekturvorgaben verloren ging.

Sicherheitsarchitektur und Identitätsmanagement nach DORA-Vorgaben

Die Umsetzung von KI-Workflows im Finanzsektor erfordert eine strikte Isolation von Datenströmen und Zugriffsrechten. Unter den Anforderungen von DORA reicht es nicht aus, Dienste netzwerkseitig abzuschotten; die gesamte Authentifizierungskette zwischen Containern, Modellen und Datenspeichern muss kryptografisch nachvollziehbar und frei von statischen Zugangsdaten sein. Das verbot den Einsatz langlebiger API-Keys für Azure OpenAI oder Service-Principal-Geheimnisse in den Kubernetes-Manifesten.

Als Kern der Sicherheitsarchitektur diente Azure Workload Identity auf dem Azure Kubernetes Service (AKS). Jeder Microservice, ob FastAPI-Endpunkt oder Batch-Job für Compliance-Rückläufer, erhielt ein eigenes Kubernetes-Service-Account, das über OIDC-Federation an eine dedizierte Azure Managed Identity gekoppelt war. Pods beziehen kurzlebige Tokens direkt über die Azure-Plattform, wodurch das Risiko kompromittierter Anmeldeinformationen im Code oder in CI/CD-Variablen vollständig entfiel.

Auf Netzwerkebene wurden sämtliche KI-Komponenten in privaten Subnetzen isoliert. Der Zugriff auf Azure OpenAI und Azure Key Vault erfolgte ausschließlich über Private Endpoints, sodass kein Datenverkehr das interne Netz verließ. Für die Verwaltung von Laufzeitkonfigurationen und Zertifikaten kam der Secrets Store CSI Driver zum Einsatz, der Geheimnisse direkt aus dem Azure Key Vault in den Arbeitsspeicher der Pods einhängt, ohne persistente Spuren auf Cluster-Nodes zu hinterlassen.

Die Sicherheitsüberprüfung wurde über Richtlinien im Azure Defender for Cloud automatisiert. Jedes Image in der Container Registry wurde vor dem Deployment auf Schwachstellen gescannt, während AKS-Admission-Controller das Starten von Containern mit Root-Rechten oder unsicheren Host-Mounts blockierten. Diese Sicherheitsnaht stellte sicher, dass das Innovation Lab zügig neue KI-Experimente starten konnte, während die regulatorische Konformität gegenüber internen Prüfern und Aufsichtsbehörden durch die Plattformgarantien der Library gewahrt blieb.