Microsoft Foundry Local: KI-Inferenz ohne Cloud – was Unternehmen jetzt wissen müssen

Table of Contents

⚡ In 30 Sekunden

Was ist es? Microsoft Foundry Local lässt KI-Modelle (GPT, Phi, Qwen, Llama u. a.) vollständig lokal auf Windows- und macOS-Geräten laufen – ohne Azure-Abonnement, ohne Cloud-Verbindung nach dem ersten Modell-Download.
Aktueller Status: Public Preview (Stand April 2026). Das übergeordnete Microsoft Foundry Portal und der Foundry Agent Service wurden am 16. März 2026 als Generally Available (GA) freigegeben; Foundry Local selbst bleibt im Preview-Stadium.
Warum relevant für DACH? Seit Februar 2026 ist Foundry Local Teil der Microsoft Sovereign Private Cloud – d. h. große multimodale Modelle laufen vollständig disconnected auf eigener Hardware, innerhalb der eigenen Datengrenzen.
Kritischer Vorbehalt: Preview bedeutet: API-Stabilität nicht garantiert, kein Production-SLA, nicht für verteilte Multi-User-Deployments ausgelegt. Wer heute produktiv geht, muss Migrationsrisiken einplanen.

Dieser Artikel wurde mit Künstlicher Intelligenz erstellt und redaktionell kuratiert.

Cloudbasierte KI ist für viele DACH-Unternehmen ein Datenschutz-Dilemma: Entweder sie schicken sensible Daten an US-Hyperscaler – mit allen rechtlichen Unsicherheiten des CLOUD Act – oder sie verzichten auf leistungsstarke KI-Werkzeuge. Microsoft versucht diesen Widerspruch mit Foundry Local aufzulösen: einem Werkzeug, das KI-Inferenz komplett auf die eigene Hardware verlagert. Was genau steckt dahinter, wo sind die Grenzen, und was bedeutet das konkret für IT-Entscheider im DACH-Raum?

Was ist Microsoft Foundry Local?

Foundry Local ist Microsofts On-Device-KI-Inferenzlösung. Entwickler können KI-Modelle lokal über eine CLI, ein SDK oder eine REST-API ausführen – ohne Azure-Abonnement, ohne permanente Internetverbindung nach dem einmaligen Modell-Download. Die Plattform läuft auf Windows 10/11 (x64 und ARM), Windows Server 2025 und macOS.

Technisch setzt Foundry Local auf das ONNX Runtime als Inferenz-Engine, die automatisch die optimale Hardware-Beschleunigung wählt: NPU, GPU oder CPU – ohne plattformspezifischen Code seitens der Entwickler. Unterstützt werden NVIDIA-GPUs (ab Serie 2000), AMD-GPUs (ab 6000er-Serie), AMD- und Intel-NPUs sowie Qualcomm Snapdragon X Elite. Ein entscheidender Punkt: Ein SDK deckt sowohl Chat als auch Audio ab – separate Werkzeuge wie whisper.cpp, llama.cpp oder ollama werden nicht mehr benötigt.

Die Schnittstelle ist OpenAI-kompatibel. Wer bereits mit der OpenAI Chat-Completions-API arbeitet, wechselt per Base-URL-Tausch von Cloud zu lokal – der restliche Anwendungscode bleibt unverändert.

Der Weg zur GA: Was bisher passiert ist

Am 19. Mai 2025 startete Microsoft Foundry Local als Public Preview – zunächst für Windows und macOS. Seitdem wurde die Plattform kontinuierlich erweitert. Version 0.7 brachte im September 2025 erweiterte NPU-Unterstützung für Intel und AMD unter Windows 11 sowie dynamische Execution-Provider-Erkennung.

Im Dezember 2025 hob Microsoft die gesamte Foundry-Plattform auf ein neues Niveau: GPT-5.2 und GPT-5.1 Codex Max erreichten den GA-Status – der Agent Service folgte im März 2026. Den entscheidenden strategischen Schritt vollzog Microsoft Ende Februar 2026: Foundry Local wurde in die Sovereign Private Cloud integriert – große multimodale Modelle können nun vollständig disconnected auf lokaler Hardware betrieben werden, mit APIs, die die Cloud-Oberfläche exakt spiegeln.

Am 16. März 2026 erreichten das Foundry Portal und der Foundry Agent Service den GA-Status. Der Foundry Agent Service ist nun produktionsreif, mit SDKs für Python, JavaScript, Java und .NET sowie End-to-End Private Networking ohne öffentlichen Egress. Foundry Local selbst bleibt offiziell im Preview-Stadium – wer produktive Workloads plant, muss das einkalkulieren.

⚠️ Preview-Vorbehalt: Foundry Local ist noch im Public Preview. Features, Prozesse und APIs können sich bis zur General Availability noch ändern. Die Plattform ist nicht für verteilte oder containerisierte Produktions-Deployments ausgelegt. Wer heute darauf aufbaut, sollte API-Breaking-Changes aktiv monitoren.

Praxisbeispiel: Mittelständischer Maschinenbauer mit KRITIS-Nähe

Ein mittelständischer Zulieferer für die Automobilindustrie (ca. 320 Mitarbeitende, Standort Baden-Württemberg) betreibt ein internes Wissensmanagement-System mit rund 15.000 technischen Dokumenten – Fertigungsanleitungen, Qualitätsprotokolle, Zertifizierungsunterlagen. Kundendaten und Produktionsspezifikationen dürfen das interne Netzwerk aus vertraglichen Gründen nicht verlassen.

Mit Foundry Local im Sovereign-Disconnected-Modus läuft ein Phi-4-Modell vollständig auf einem lokalen Server mit NVIDIA-GPU. Techniker stellen Fragen in natürlicher Sprache; das Modell antwortet auf Basis der internen Dokumentenbasis – ohne dass ein einziges Zeichen die Betriebsgrenzen verlässt. Der Betriebsrat wurde vorab eingebunden; eine Betriebsvereinbarung regelt, dass das System keine Leistungsüberwachung durchführt. Ergebnis: Kürzere Einarbeitungszeiten, weniger Fehler bei der Maschinenwartung – und eine DSFA, die deutlich einfacher fiel als bei einem Cloud-basierten Ansatz.

Sovereign Cloud: Der DACH-relevante Durchbruch

Die wichtigste Neuerung für europäische Unternehmen ist nicht das lokale Inferenz-Feature an sich – sondern die Integration in Microsofts Sovereign Private Cloud. Azure Local, Microsoft 365 Local und Foundry Local können ohne Verbindung zur Public Cloud betrieben werden. Damit reagiert Microsoft direkt auf das rechtliche Spannungsfeld zwischen CLOUD Act und DSGVO.

Der US CLOUD Act verpflichtet US-Unternehmen, US-Behörden auf Verlangen Zugriff auf kontrollierte Daten zu gewähren – unabhängig vom physischen Speicherort. Das steht in einem juristischen Spannungsfeld zu europäischen Datenschutzgesetzen wie der DSGVO oder dem Schweizer DSG. Der Disconnected-Modus von Foundry Local adressiert genau dieses Problem: Wenn keine Verbindung zu Microsoft-Servern besteht, gibt es auch keine Daten, auf die Behörden zugreifen könnten.

Kunden können nun missionskritische Workloads auf lokaler Hardware ausführen, ununterbrochenen Betrieb sicherstellen und dabei Daten, Identitäten und Betrieb innerhalb ihrer eigenen souveränen Grenzen halten. Für KRITIS-Betreiber, Behörden und stark regulierte Branchen wie Finanz- und Gesundheitswesen ist das ein substanzieller Fortschritt gegenüber rein Cloud-basierten Ansätzen.

Compliance-Analyse: DSGVO, EU AI Act und BetrVG

DSGVO: Art. 28, Art. 44 ff. und der Disconnected-Vorteil

Beim Cloud-Betrieb von KI-Systemen müssen Unternehmen mit Microsoft einen Auftragsverarbeitungsvertrag (AVV) nach Art. 28 DSGVO abschließen. Im Disconnected-Modus von Foundry Local entfällt die Auftragsverarbeitung durch Microsoft weitgehend – die Datenverarbeitung verbleibt vollständig im eigenen Kontrollbereich. Eine Datenschutz-Folgenabschätzung (DSFA) nach Art. 35 DSGVO ist dennoch zu prüfen, wenn besonders sensible Daten (Gesundheits-, Beschäftigungs- oder Finanzdaten) verarbeitet werden. Die Entscheidung für lokalen Betrieb vereinfacht diese Bewertung erheblich, da Drittlandtransfers nach Art. 44 ff. DSGVO entfallen.

EU AI Act: Risikoklassifikation lokal betriebener Systeme

Der EU AI Act (seit August 2025 in Kraft) klassifiziert KI-Systeme nach Risikostufen – unabhängig davon, ob sie cloud- oder lokal betrieben werden. Foundry Local ändert die Risikoeinstufung eines KI-Systems nicht automatisch. Wer ein Hochrisiko-KI-System (Anhang III EU AI Act) lokal betreibt, unterliegt denselben Anforderungen: Konformitätsbewertung, technische Dokumentation, Logging, menschliche Aufsicht. Der Vorteil liegt im Audit-Trail: Lokaler Betrieb ermöglicht lückenlosere Protokollierung ohne Abhängigkeit von Cloud-Logging-Diensten. Wer sich in die EU AI Act Grundlagen einlesen möchte, findet auf AI-Fabrik einen vertiefenden Artikel zu Hochrisiko-KI und FRIA-Pflichten.

BetrVG §87: Mitbestimmung bei KI-gestützten Arbeitsmitteln

Der Betriebsrat hat nach §87 Abs. 1 Nr. 6 BetrVG ein Mitbestimmungsrecht bei der Einführung technischer Einrichtungen, die das Verhalten oder die Leistung von Arbeitnehmern überwachen können. Das gilt auch für lokal betriebene KI-Tools. Unternehmen sollten Betriebsvereinbarungen proaktiv abschließen, die Nutzungsszenarien, Datenlöschfristen und Ausschluss personenbezogener Leistungsüberwachung regeln. Der lokale Betrieb über Foundry Local kann die Verhandlungsposition gegenüber dem Betriebsrat stärken, da Daten das Unternehmensnetzwerk nachweislich nicht verlassen.

Technische Einschränkungen: Was Foundry Local nicht kann

🚫 Nicht geeignet für:

Multi-User-Produktionsumgebungen: Foundry Local ist für Einzelgeräte oder Edge-Szenarien ausgelegt. Für Multi-User-, Hochdurchsatz- oder breite Produktions-Workloads empfiehlt Microsoft die Cloud-Version von Foundry.
Sehr große Modelle ohne leistungsstarke GPU: GPT-OSS-20B erfordert laut Microsoft eine NVIDIA-GPU mit mindestens 16 GB VRAM.
Produktionskritische Systeme mit SLA-Anforderungen: Als Preview-Produkt ohne GA-Status fehlt ein verbindliches Service Level Agreement.
Web-Search-Integration: Foundry Local arbeitet offline – Echtzeit-Websuche ist nicht verfügbar.

Unterstützte Modelle und Hardware-Anforderungen

Der Modell-Katalog von Foundry Local umfasst eine wachsende Auswahl offener und halboffener Modelle. Verfügbar sind unter anderem Qwen 2.5 (verschiedene Größen), Phi-4, Llama 3.x sowie – für Geräte mit ausreichend VRAM – GPT-OSS-20B, Microsofts erstes eigenes Open-Weight-Modell. Foundry Local lädt automatisch die zur Hardware passende Modellvariante herunter: CUDA für NVIDIA-GPUs, NPU-optimierte Versionen für entsprechende Hardware, CPU-Varianten als Fallback.

Die Mindestanforderungen für erste Experimente sind moderat: 8 GB RAM, 3 GB freier Speicherplatz, Windows oder macOS. Für produktiven Einsatz mit mittelgroßen Modellen empfiehlt Microsoft 16 GB RAM und 15 GB Speicher.

Foundry Local vs. Alternativen: Marktüberblick

Lösung	Anbieter	Status	Stärke	Schwäche	Typische Einsatzszenarien
Foundry Local	Microsoft	Public Preview	Azure-Integration, NPU-Support, OpenAI-kompatibel	Preview-Status, kein SLA, kein Multi-User	Lokaler Entwickler-Pilot, datensensible Enterprise-PoCs, Sovereign-Cloud-Deployments
Ollama	Open Source	GA (v1.x)	Einfach, breite Modellauswahl, Community	Kein Enterprise-Support, kein NPU-Fokus	Schnelles lokales Experimentieren, Entwicklerworkstations, Home-Lab
LM Studio	LM Studio Inc.	GA	GUI-freundlich, Entwickler-Tools	Kein Unternehmens-Support, kein SDK	Nicht-technische Nutzer, Modell-Evaluierung ohne CLI
NVIDIA NIM	NVIDIA	GA	Optimiert für NVIDIA-Hardware, Container-basiert	NVIDIA-Hardware erforderlich, Lizenzkosten	High-Performance-Inferenz, Multi-GPU-Server, MLOps-Teams
Hugging Face TGI	Hugging Face	GA	Breiteste Modellauswahl, Open Source	Infrastruktur-Aufwand, kein Windows-First	Linux-Server, Research-Umgebungen, maßgeschneiderte Deployments

Der Hauptvorteil von Foundry Local gegenüber reinen Open-Source-Alternativen liegt in der nativen Azure-Integration: Entwickler können Prototypen lokal bauen und sie mit minimalem Aufwand in die Cloud-Version von Foundry überführen – inkl. Enterprise-Governance, Private Networking und Observability.

Empfehlungen nach Unternehmensgröße und Rolle

✅ Empfehlungen für DACH-Unternehmen

IT-Leiter und Architekten: Foundry Local jetzt evaluieren, aber noch nicht als Produktionssystem einplanen. Die Preview-Phase nutzen, um Modelle zu testen, Hardware-Anforderungen zu benchmarken und Integrationsarchitekturen für den GA-Zeitpunkt vorzubereiten. Hybrid-Strategie ausarbeiten: Welche Workloads lokal, welche in der Cloud?

CISOs und Datenschutzbeauftragte: Den Disconnected-Modus im Kontext der eigenen DSGVO-Bewertungen prüfen. Foundry Local im Sovereign-Cloud-Modus kann Art. 44 ff.-Risiken (Drittlandtransfer) strukturell eliminieren. DSFA-Dokumentation entsprechend aktualisieren. AVV-Pflicht nach Art. 28 DSGVO mit Datenschutz-Rechtsanwalt klären – auch für Preview-Betrieb können Verarbeitungen anfallen (z. B. bei optionaler Diagnose-Telemetrie). Wer KI auch in der Cloud betreibt, findet in unserem Artikel zu KI-Modellen DSGVO-konform nutzen weitere Orientierung.

Betriebsräte und Works Council: Betriebsvereinbarung für den Einsatz lokal betriebener KI-Assistenzsysteme proaktiv verhandeln. Der lokale Betrieb macht die Datenfluss-Transparenz nachweisbarer – nutzen Sie diesen Vorteil für sachliche Verhandlungen nach §87 BetrVG.

Mittelstand (50–500 MA): Foundry Local als kosteneffiziente Alternative zu Cloud-KI für definierte, datensensible Anwendungsfälle prüfen: interne Dokumentensuche, Wissensmanagement, Code-Assistenz für interne Repositories. Kein Azure-Abonnement erforderlich für den Einstieg. Wer die Anforderungen übersteigt und eine vollständig verwaltete Agenten-Infrastruktur benötigt, sollte auch Cloud-basierte Alternativen wie Claude Managed Agents in den Vergleich einbeziehen.

Schnellstart: Foundry Local in 5 Minuten

Schritt 1 – Installation über den Windows-Paketmanager winget (macOS: Homebrew, siehe unten):

# Windows
winget install Microsoft.FoundryLocal

# macOS
brew tap microsoft/foundrylocal
brew install foundrylocal

Schritt 2 – Erstes Modell herunterladen und starten. Foundry Local wählt automatisch die optimale Hardware-Variante (CUDA / NPU / CPU):

# Verfügbare Modelle anzeigen
foundry model list

# Kleines Testmodell laden und starten
foundry model run qwen2.5-0.5b

Schritt 3 – REST-API testen. Den aktuellen Port ermitteln mit foundry service status, dann die erste Anfrage senden:

curl http://localhost:PORT/v1/chat/completions 
  -H "Content-Type: application/json" 
  -d '{
    "model": "qwen2.5-0.5b",
    "messages": [{"role": "user", "content": "Erkläre RAG in zwei Sätzen."}]
  }'

Nach dem ersten Modell-Download können alle Inferenz-Anfragen vollständig offline erfolgen. Die REST-API ist OpenAI-kompatibel – ein Base-URL-Wechsel von https://api.openai.com auf http://localhost:PORT genügt in bestehenden Anwendungen.

Fazit: Strategisch wertvoll, taktisch noch früh

Microsoft Foundry Local adressiert ein reales Enterprise-Problem: KI-Fähigkeiten ohne Cloud-Abhängigkeit, innerhalb der eigenen Datengrenzen, auf Standard-Hardware. Die Integration in die Sovereign Private Cloud macht das Angebot für DACH-Unternehmen mit DSGVO- und CLOUD-Act-Bedenken strategisch relevant.

Der kritische Vorbehalt bleibt: Foundry Local ist noch im Public Preview. Wer heute Produktionsentscheidungen auf Preview-APIs aufbaut, riskiert Breaking Changes. Die richtige Haltung jetzt ist evaluieren, pilotieren, Architektur vorbereiten – aber den GA-Status abwarten, bevor unternehmenskritische Workloads migriert werden. Auf Basis des Entwicklungstempos der letzten Monate dürfte dieser Schritt 2026 noch kommen.

📬 Foundry Local pilotieren und auf dem Laufenden bleiben? Wir aktualisieren diesen Leitfaden zum GA-Release. Der AI-Fabrik Newsletter liefert DACH-fokussierte Enterprise-KI-News wöchentlich – inklusive Hinweis, wenn Foundry Local den GA-Status erreicht und produktionsreif wird.

FAQ

Ist Microsoft Foundry Local kostenlos?

Foundry Local selbst ist kostenlos zu installieren und zu nutzen. Ob für die Ausführung von Modellen Kosten anfallen, hängt vom jeweiligen Modell ab – Open-Source-Modelle sind frei, andere können lizenzpflichtig sein. Ein Azure-Abonnement ist nicht erforderlich.

Welche Daten verlassen das Gerät?

Nach dem initialen Modell-Download werden Prompts und Modellantworten lokal verarbeitet. Foundry Local kann das Netzwerk weiterhin für optionale Diagnose-Telemetrie nutzen, wenn der Nutzer sich entscheidet, Logs zu teilen. Im Sovereign-Cloud-Disconnected-Modus entfällt auch diese optionale Verbindung.

Wann kommt der GA-Release von Foundry Local?

Microsoft hat keinen offiziellen GA-Termin kommuniziert. Das Entwicklungstempo mit mehreren Releases pro Monat, die GA-Freigabe des übergeordneten Foundry Agent Service im März 2026 und die Integration in die Sovereign Private Cloud deuten auf 2026 hin. Unternehmen sollten den offiziellen Microsoft Foundry Blog und das GitHub-Repository beobachten.

Kann ich eigene Modelle in Foundry Local einbinden?

Ja. Neben dem vordefinierten Modell-Katalog können Unternehmen eigene Modelle einbinden – relevant für feinabgestimmte (fine-tuned) Modelle aus eigenen Trainingsdaten.

Wie verhält sich Foundry Local im Vergleich zu Ollama?

Ollama ist einfacher einzurichten und hat eine größere Open-Source-Community. Foundry Local bietet bessere Hardware-Abdeckung (insbesondere NPU-Support unter Windows), eine OpenAI-kompatible REST-API ohne Konfigurationsaufwand und einen nativen Migrationspfad in die Azure-Cloud. Für Entwickler im Microsoft-Ökosystem ist Foundry Local strategisch vorzuziehen; für modellbasiertes Experimentieren außerhalb des Azure-Stack ist Ollama weiterhin eine valide Wahl.

Weiterführende Artikel auf AI-Fabrik

Quellen

Teile es