Wie souverän sind KI-Agenten mit Foundry Local im eigenen Rechenzentrum?

Ihr Unternehmen kann KI-Agenten mit Foundry Local künftig im eigenen Rechenzentrum betreiben, doch nur auf Microsofts Plattform Azure Local, und ob das „souverän“ ist, bleibt umstritten. Microsoft hat am 20. Oktober 2026 im Unternehmensblog angekündigt, dass Foundry Local zur Ignite für verbundenen und getrennten Betrieb auf Azure Local allgemein verfügbar werden soll. Ein Datum für die Ignite nennt Microsoft im Blog nicht. Ergänzend kündigt Microsoft Kontrollfunktionen, lokale Datenbanken und eine Entwicklerplattform an. Die Gesellschaft für Informatik (GI) hält den Souveränitätsbegriff dennoch für zu kurz gegriffen, weil Software-Stack und Betriebsmodell beim US-Konzern bleiben. Preise für die nötige Hardware nennt Microsoft nicht.

Welche Bausteine Microsoft für Azure Local angekündigt hat

Douglas Phillips, President und CTO von Microsoft Specialized Clouds, beschreibt im Microsoft-Blog vom 20. Oktober 2026 ein Paket für Organisationen, die Daten und Betrieb näher an sich halten wollen. Zentral ist Foundry Local: Es soll laut Microsoft zur Ignite für „connected and disconnected operations“ auf Azure Local allgemein verfügbar werden. Azure Local ist Microsofts Plattform, mit der Azure-Dienste auf Hardware im eigenen Haus laufen. „Disconnected“ meint den Betrieb ohne dauerhafte Verbindung zur öffentlichen Azure-Cloud.

Der Modellkatalog wächst dabei. Microsoft nennt eigene Modelle, Modelle von Partnern sowie Open-Weight- und Open-Source-Modelle. Bei Open-Weight-Modellen sind die trainierten Gewichte frei herunterladbar, der Trainingsprozess ist aber nicht zwingend offengelegt. Welche Modelle konkret im Katalog stehen, nennt Microsoft nicht. Das sollten Sie vor einer Planung gegen Ihre Anforderungen prüfen.

Für Fachabteilungen interessanter ist „agentic retrieval“. Gemeint ist, dass ein KI-Agent lokale Unternehmensdaten selbstständig durchsucht und in natürlicher Sprache antwortet, wobei die Antworten laut Microsoft auf diesen Daten beruhen. Das ist eine Recherche- und Auskunftsaufgabe, etwa zu Verträgen, Handbüchern oder Mails. Wie gut die Treffer sind, hängt von Ihrer Datenqualität und Ihren Berechtigungen ab, nicht allein vom Modell. Eine Messung dazu liefert Microsoft nicht.

Dazu kommt die Anbindung an Microsoft 365 Local. Sie soll dieselbe Funktion auf lokal betriebene SharePoint- und Exchange-Server ausdehnen, ist aber laut Blog nur in einer Vorschau für freigegebene Kunden verfügbar. Allgemein verfügbar sind laut Microsoft bereits Confidential Virtual Machines auf Azure Local, also VMs mit hardwaregestützt abgeschirmtem Arbeitsspeicher, sowie die externe Schlüsselverwaltung mit Azure Managed HSM. Dort kann der Root-Schlüssel auf Hardware liegen, die Sie selbst oder ein vertrauenswürdiger Dritter betreibt. SQL Server auf Azure Local ist ebenfalls bereits für verbundene und getrennte Szenarien verfügbar.

Weitere Bausteine befinden sich noch in der Vorschau. DocumentDB und Blob Storage auf Azure Local treten laut Microsoft in die öffentliche Vorschau ein, ebenso die Möglichkeit, Workloads vom verbundenen in den getrennten Betrieb zu überführen. Das Sovereign Control Panel startet zur Ignite als öffentliche Vorschau im Azure-Portal.

Für die öffentliche Cloud nennt Microsoft zwei Funktionen für Kundschaft in EU und EFTA: Data Guardian, das Microsoft derzeit ausrollt, ergänzt eine Aufsicht durch einen vertrauenswürdigen EU-Partner, wenn Microsoft-Techniker aus der Ferne auf Produktivsysteme zugreifen. Production Touch Ledger, laut Microsoft mit gestuftem Rollout gestartet, protokolliert diese Zugriffe und die ausgeführten Aktionen manipulationssicher. Für Entwicklungsteams kündigt Microsoft außerdem GitHub Enterprise Local zur Ignite an.

Was noch Vorschau bleibt und was das für den Betrieb heißt

Nicht alles in der Ankündigung ist produktionsreif. Das Sovereign Control Panel tritt laut Microsoft „at Microsoft Ignite“ in die öffentliche Vorschau (Public Preview) ein. Es bündelt in einer Azure-Portal-Ansicht Signale zur Souveränitätslage, hilft Kontrollen anzuwenden, Lücken zu erkennen und Abhängigkeiten von Workloads sowie deren Übertragbarkeit einzuschätzen. Für Audits oder Vorstandsberichte taugt eine Vorschau nur eingeschränkt, weil Funktionsumfang und Support sich noch ändern können.

Ähnlich steht es um den Wechsel zwischen den Betriebsarten. Die Möglichkeit, Workloads von verbundenem zu getrenntem Betrieb zu überführen, tritt laut Blog in die öffentliche Vorschau. Wer „disconnected“ als Notfallplan versteht, kann sich darauf also noch nicht verlassen. DocumentDB und Blob Storage auf Azure Local sind ebenfalls erst in der Vorschau, was für Agenten-Projekte mit größeren Dokumentbeständen relevant ist. Mehrmandantenfähigkeit (Multitenancy) soll Azure Local unterstützen, einen Termin nennt Microsoft nicht.

Für Entwicklungsteams ist die GitHub Enterprise Local Appliance wichtig. Sie soll zur Ignite allgemein verfügbar werden, als validierte Appliance des GitHub Enterprise Servers auf Azure Local. Entwickelnde können laut Microsoft GitHub Copilot mit lokal gehosteten Modellen für die Inferenz nutzen. Das ist ein anderer Anwendungsfall als Retrieval: Hier geht es um Codevorschläge, nicht um Auskünfte aus Unternehmensdaten. Microsoft sagt nicht, wie sich lokal gehostete Modelle bei Codequalität oder Funktionsumfang gegenüber der Cloud-Variante unterscheiden.

Für den Betrieb heißt das: Sie bekommen eine Mischung aus verfügbaren und noch unfertigen Bausteinen. Pilotprojekte mit Foundry Local können sinnvoll sein, sobald die Verfügbarkeit tatsächlich eintritt. Verbindliche Souveränitäts-Nachweise über das Control Panel sollten Sie dagegen erst planen, wenn es aus der Vorschau heraus ist. Das ist eine dm-Einordnung, keine Aussage von Microsoft.

Offen bleibt auch die Betreiberfrage. Data Guardian und Production Touch Ledger setzen dort an, wo Microsoft-Personal aus der Ferne auf Produktivsysteme in der öffentlichen Cloud zugreift; Data Guardian rollt Microsoft derzeit aus, Production Touch Ledger startet gestuft. Ob und wie sie für Azure Local gelten, sagt Microsoft nicht. dm-Einordnung: Dass solche Zugriffe überhaupt geregelt werden müssen, zeigt, dass Betrieb und Wartung nicht vollständig bei Ihnen liegen.

Wo die GI-Kritik an US-Stacks und CLOUD Act ansetzt

Dieses Bild wurde komplett mit KI generiertProviderhiggsfieldModellgpt_image_2PromptIT team meeting in front of a large screen showing an abstract network diagram of on-premises AI agents, modern conference room. Photorealistic editorial magazine photo, 16:9. Absolutely no text, no letters, no numbers, no logos, no brand marks.

Microsoft nennt das Paket „Sovereign Private Cloud“ und verspricht mehr Kontrolle und Wahlfreiheit. Die heise-Meldung vom 20. Oktober 2026 zitiert dagegen Fachverbände. Die Gesellschaft für Informatik sieht solche Angebote von US-Hyperscalern skeptisch: Der Begriff der digitalen Souveränität greife zu kurz, da es sich überwiegend um vertragliche und technische Zusatzkontrollen an der Oberfläche handele.

Der Kern des Einwands betrifft die Ebene darunter. Laut GI bleiben die zugrunde liegenden Software-Stacks, die komplexen Cloud-Architekturen und teils proprietäre Betriebssysteme in den Händen der US-Konzerne. Damit würden langfristige Abhängigkeiten zementiert. Die GI äußert sich laut heise allgemein zu US-Hyperscalern, nicht speziell zu Foundry Local. dm-Einordnung: Wer Foundry Local auf Azure Local betreibt, nutzt Microsofts Plattform und Microsofts Verwaltungsportal, auch wenn die Server im eigenen Haus stehen.

Hinzu kommt die Rechtslage. Der US Cloud Act, ein US-Gesetz, das Behörden unter Umständen Zugriff auf Daten von US-Unternehmen auch im Ausland erlaubt, könne laut GI aufgrund technischer Verflechtungen erhebliche rechtliche Risiken bergen, selbst wenn Daten in Europa verschlüsselt verarbeitet werden. Ob das Gesetz im Einzelfall greift, ist damit nicht entschieden. Die GI formuliert ein Risiko, keinen Automatismus. dm-Einordnung: Ihre Rechtsabteilung sollte klären, welche Daten betroffen wären.

Echte souveräne IT-Infrastruktur erfordert laut GI offene Standards, komplette Transparenz beim Quellcode und das Loslösen von marktbeherrschenden Plattformbetreibern. dm-Einordnung: An diesem Maßstab gemessen kann ein Azure-Local-Betrieb höchstens ein Zwischenschritt sein. Microsofts Gegenposition: Kontrollen wie extern verwaltete Schlüssel auf eigener Hardware, Aufsicht durch einen EU-Partner und manipulationssichere Zugriffsprotokolle verringern den Zugriff. Beides lässt sich vereinbaren, wenn Sie Souveränität als Abstufung verstehen und nicht als Schalter.

Microsoft verweist außerdem auf National Partner Clouds, darunter Bleu Cloud in Frankreich und Delos Cloud in Deutschland. Sie bieten laut Blog unabhängig betriebene Umgebungen für Kundschaft, die ein anderes Eigentums- und Betriebsmodell benötigt. Ob Delos Cloud Foundry Local bereits anbietet, sagt Microsoft nicht. Wie stark Unternehmen in Deutschland von digitalen Importen und langen Ausstiegszeiten betroffen sind, hat zuletzt der Bitkom beziffert.

Welche Prüffragen IT vor dem Pilot beantworten sollte

Klären Sie zuerst, welche Aufgabe der Agent übernimmt. Retrieval, also Auskunft aus lokalen Daten, ist über Foundry Local und gegebenenfalls Microsoft 365 Local gedacht, wobei letzteres nur in einer Vorschau für freigegebene Kunden verfügbar ist. Coding-Unterstützung läuft über die GitHub Enterprise Local Appliance mit Copilot und lokal gehosteten Modellen. Das sind zwei Projekte mit unterschiedlichem Status, unterschiedlichen Teams und eigenen Berechtigungsfragen.

Zweitens der Update-Pfad. Microsoft sagt im Blog nicht, wie oft Modelle und Plattform aktualisiert werden und wer das im getrennten Betrieb einspielt. Fragen Sie nach: Wie gelangen neue Modellversionen in eine Umgebung ohne Cloud-Verbindung? Wer testet sie? Und wie lange bleibt eine ältere Version unterstützt? Das ist eine dm-Einordnung, keine Angabe aus der Ankündigung. Ohne Antworten bleibt offen, was „disconnected“ im Alltag bedeutet.

Drittens die Hardware. Microsoft nennt keine Preise und keine Mindestausstattung. Welche Konfiguration für welche Modellgröße validiert ist, müssen Sie beim Hersteller oder Hardware-Partner erfragen. Planen Sie Angebote ein, bevor Sie Budgets zusagen.

Viertens die Rechte der Agenten. Ein Agent, der lokale Daten durchsucht, braucht eine Identität und klar begrenzte Zugriffe. In Microsoft-Umgebungen gehören dazu eigene Agent-Konten mit Governance-Regeln wie in Copilot Studio. Ob dieselben Mechanismen im getrennten Betrieb gelten, ist offen und gehört in Ihren Fragenkatalog.

Fünftens die Abhängigkeit vom Anbieter selbst. Auch ein lokaler Betrieb ersetzt keinen Notfallplan (dm-Einordnung). Prüfen Sie außerdem, ob Zugriffe von Microsoft-Personal für Wartung vorgesehen sind, ob Data Guardian und Production Touch Ledger in Ihrer Region schon ausgerollt sind und ob der Root-Schlüssel mit Azure Managed HSM wirklich bei Ihnen liegt.

Als nächsten konkreten Schritt bietet sich ein begrenzter Test mit einem Datenbestand an, dessen Verlust oder Offenlegung verkraftbar wäre. Dokumentieren Sie dabei, welche Komponenten Sie selbst betreiben und welche Microsoft kontrolliert. Diese Liste ist die Grundlage für jede spätere Aussage zur Souveränität gegenüber Geschäftsführung, Datenschutz und Aufsicht.