Azure AI Foundry für einen Versicherungskonzern: Self-Service-KI mit belegbarer Wiederherstellbarkeit

Pexon Consulting arbeitet als Platform Engineer im internen Plattform-Team. Der Ansatz ist bewusst kein KI-Prototyping, sondern klassisches Platform Engineering: Die Plattform ist das Produkt, die Fachbereiche sind die Kunden, und die Übergabegrenze ist explizit definiert. Das Plattform-Team stellt die AI-Plattform, die Dokumentation und Hilfestellung bereit. Den Betrieb ihrer Use Cases verantworten die nutzenden Abteilungen selbst. Diese Grenze verhindert, dass ein Vier-Personen-Team zum Betriebsdienstleister für den gesamten Konzern wird, und hält den Scope handlungsfähig trotz knapper Allokation. Der Trade-off ist klar: Weniger zentrale Kontrolle über einzelne Agenten-Workflows, dafür eine skalierbare Self-Service-Grenze, die unter wachsender Nachfrage nicht kollabiert. Feedback von Early Adoptern fließt regelmäßig in die Weiterentwicklung, die Plattform wird an echten Anforderungen geschärft, nicht an einem starren Anforderungsdokument.

Die gesamte Azure-Infrastruktur rund um Microsoft Foundry, Storage Accounts, Cosmos DB und die Foundry-Ressourcen selbst, wird als Terraform-Code verwaltet. Wiederholbarkeit ist in einem regulierten Umfeld nicht Komfort, sondern Nachweispflicht. Der Trade-off gegen ClickOps oder nur ARM-/Bicep-Fragmente: höherer initialer Modellierungsaufwand, dafür versionierte Änderungen, Review-fähige Diffs und die Möglichkeit, aus dem Code heraus neu zu erzeugen, was keinen irreversiblen Zustand trägt. Genau diese Trennung steuert später das Backup-Konzept: Was Terraform jederzeit neu aufbauen kann, braucht keine klassische Sicherung; was Zustand trägt, schon. Parallel wurde die Entwicklungs- und Deployment-Kette von Azure DevOps auf GitHub umgezogen, ohne die laufende Plattformentwicklung anzuhalten. Eine Toolchain statt zwei reduziert kognitive Last in einem Team, das ohnehin knapp bemessen ist.

Hat Azure AI Foundry ein natives Backup? Nein. Wer die Plattform in einem VAIT- und DORA-regulierten Umfeld produktiv setzen will, muss Bestandsaufnahme und Sicherungsverfahren selbst bauen. Der Weg beginnt nicht mit einem Tool, sondern mit einer Inventur. Leitfrage: Welche Bestandteile lassen sich aus dem Terraform-Code jederzeit neu erzeugen, und welche tragen einen Zustand, der bei Verlust unwiederbringlich wäre? Nur der zweite Teil braucht ein echtes Sicherungsverfahren. Fertige Anleitungen gibt es für diesen Fall nicht, der Weg ist Recherche- und Konstruktionsarbeit an einem Produkt, das sich selbst noch schnell bewegt. Aktueller Stand: Die Übersicht sicherungsfähiger Plattformartefakte liegt vor. Auf ihr baut das Sicherungs- und Wiederherstellungsverfahren auf, das sich in Umsetzung befindet. Ohne diese Übersicht wäre jedes Backup-Konzept Raten, und ohne belegbare Wiederherstellbarkeit gibt es im Versicherungskonzern keine Produktionsfreigabe.

Der Konzern hat eine direkte Verbindung zu Microsoft. In gemeinsamen Terminen wurde die Architektur durchgegangen, instabile Preview-Bausteine entfernt und gegen stabilere Alternativen ersetzt. Trade-off: Weniger Feature-Breite kurzfristig, dafür ein belastbares Grundgerüst, bevor die Nutzerzahl steigt. Eine KI-Plattform wird nicht durch das neueste Preview-Feature produktionsreif, sondern durch die Bausteine, die man wieder ausbaut. Organisatorisch ist das Plattform-Team von der konzernweiten SAFe-PI-Planung ausgenommen und fährt Kanban-Light: ein Daily zur Abstimmung, kein Scrum Master, keine Retros, keine Standardmeetings. Entscheidungen fallen im Team und fallen schnell. Zusammensetzung: interner Initiator mit Projektleitung und Koordination, ein weiterer interner Kollege, ein Berufseinsteiger und der Pexon-Engineer als einziger Externer und gleichberechtigter Owner für Backup und Wiederherstellbarkeit.