The Holy Trinity: Was KI wirklich braucht, um zu arbeiten

Ein Fertigungsunternehmen möchte wissen, welche seiner 14.000 SKUs tatsächlich profitabel sind. Die Antwort liegt in drei Systemen, die noch nie einen einzigen Datenpunkt miteinander ausgetauscht haben. Bis vor Kurzem hat es drei Abteilungen, zwei Wochen und einiges an gutem Willen gekostet, sie zu bekommen. Seit Anfang 2026 kann eine KI diese Frage in Minuten beantworten: die Daten durchsuchen, Zusammenhänge herstellen, eine Empfehlung produzieren. Vorausgesetzt, sie hat Zugriff.

Die Modelle sind so weit. Sie handeln, führen Aufgaben über mehrere Schritte und Systemgrenzen hinweg aus, bereiten Entscheidungen vor, stoßen Workflows an. Viele Unternehmen haben davon durch Copilot bereits einen ersten Eindruck bekommen, aber Copilot kennt das M365-Universum: Mails, Dokumente, Kalender. Wer KI auf die Daten ansetzen will, die das eigentliche Geschäft tragen, auf ERP, CRM, IoT und Produktionssysteme, braucht ein anderes Fundament.

Dieses Fundament besteht aus drei Teilen. Wir haben jeden davon als Managed Service gebaut, jeder geht in drei bis vier Wochen in Produktion, und zusammen bilden sie die Plattform, auf der KI echte Arbeit leisten kann.

Erstens: Daten, die eine Abfrage wert sind

Zurück zu den 14.000 SKUs. Produktionsdaten stecken im ERP, Verkaufszahlen im CRM, und irgendwo dazwischen pflegt eine einzelne Person eine Tabelle, die zufällig die einzige Quelle für einen geschäftskritischen KPI ist. Das ist kein Sonderfall. Das ist die Regel. Und solange diese Daten in getrennten Systemen liegen, hat KI keinen zusammenhängenden Blick auf das Geschäft.

Eine Lakehouse-Architektur löst das in drei Schichten: Rohdaten aus den Quellsystemen (Bronze), kuratierte und validierte Datensätze (Silver), Business-Aggregate, die direkt in Analytics- oder KI-Pipelines fließen (Gold). Ob das auf Databricks oder Fabric läuft, hängt von der Anforderung ab. Beides funktioniert. Ein Hybrid aus beidem auch.

Die Azure Data Foundation ist unser Managed Service dafür. Sie integriert Daten aus ERP, CRM, IoT und weiteren Quellsystemen in eine einzige Plattform, vollständig als Infrastructure as Code definiert, mit automatischer Drift Detection, durchgängiger Data Governance über Unity Catalog oder Purview und rollenbasiertem Zugriff für Business User, Analysten und Data Engineers gleichermaßen. Die praktische Folge: Ein Unternehmen mit diesem Fundament kann zum ersten Mal Fragen stellen, die vorher unbeantwortbar waren, nicht weil man nicht wollte, sondern weil die Daten zwar da waren, aber nie verbunden.

Zweitens: Ein Ort, an dem Workloads tatsächlich laufen

Daten zu haben, ist das eine. Etwas damit zu tun, das über eine einmalige Abfrage hinausgeht, ist das andere. KI-Anwendungen, automatisierte Business-Logik, langlaufende Jobs: Alles, was autonom und wiederholt auf Unternehmensdaten zugreift, braucht eine Laufzeitumgebung, die man kontrollieren kann. Diese Umgebung besteht, ob so geplant oder nicht, aus Containern.

Die Azure Container Foundation liefert diesen Rahmen: eine standardisierte Container-Plattform auf Basis von Azure Container Apps oder Azure Kubernetes Service, je nach Workload. Einheitliche Netzwerkzugriffe, zentrale Authentifizierung über Entra ID mit Managed Identities, durchgängiges Monitoring. Alles über Terraform und GitHub verwaltet, alles reproduzierbar.

Was das ermöglicht: Statt dass jedes Team seinen eigenen Cluster hochzieht und eigene Regeln definiert, gibt es einen gemeinsamen Rahmen, in dem Workloads nicht nur laufen, sondern beherrschbar bleiben. Das ist die Voraussetzung dafür, ihnen Autonomie zu geben.

Drittens: Der Ort, an dem aus Modellen Agents werden

Ein Modell ist noch kein Agent. Zwischen einem Sprachmodell und etwas, das zuverlässig Bestellungen erfasst, Rechnungen prüft oder Servicefälle eskaliert, liegt eine Menge unspektakulärer Arbeit: welches Modell, welche Werkzeuge, welche Datenquellen, welche Leitplanken, und was passiert, wenn der Agent daneben liegt. Diese Arbeit muss irgendwo stattfinden, nachvollziehbar und wiederholbar, nicht in einem Notebook auf dem Laptop einer einzelnen Person.

Die Azure AI Foundation ist unser Managed Service für diese Schicht, aufgesetzt auf Microsoft Foundry (vormals Azure AI Foundry): Modellkatalog, Agent-Orchestrierung, Anbindung an Werkzeuge und Datenquellen, Evaluierung und Observability an einem Ort. Ein Agent, der hier gebaut wird, greift über dieselben Entra-Identitäten auf Daten und Workloads zu wie der Rest der Landschaft, läuft gegen die Leitplanken, die man definiert hat, und hinterlässt eine Spur, die sich prüfen lässt.

Wir liefern sie als Code definiert, mit rollenbasiertem Zugriff, Content-Filtern und Netzwerkgrenzen, die nicht zur Diskussion stehen, und mit einem Deployment-Weg, der einen Agenten aus der Entwicklung in die Produktion bringt, ohne dass jemand von Hand an Schrauben dreht. Erst damit hört ein Agent auf, ein Prototyp zu sein, und wird zu etwas, das ein Unternehmen tatsächlich betreiben kann.

The Holy Trinity

Drei Bausteine, jeder in drei bis vier Wochen produktiv, jeder einzeln einsetzbar, zusammen die Plattform, auf der KI dort ankommt, wo im Unternehmen tatsächlich Wert entsteht.

Die Azure Data Foundation verschafft KI Zugriff auf die Daten, die das Geschäft beschreiben. Die Azure Container Foundation gibt ihren Workloads einen Ort, an dem sie laufen können, dauerhaft und kontrolliert. Und die AI Foundation ist der Ort, an dem aus diesen Daten und diesen Workloads ein Agent wird, den man bauen, prüfen und betreiben kann.

Setzt man alle drei zusammen, hat man den Boden, auf dem KI aufhört zusammenzufassen und anfängt zu arbeiten.