Was ist Foundry IQ — und wann brauchen Schweizer KMU es (nicht)?

Seit Microsoft «Foundry IQ» bewirbt, klingt es für viele Schweizer KMU nach dem nächsten Produkt, das man prüfen, lizenzieren und in die Roadmap aufnehmen muss. Genau hier lohnt sich die Entzauberung: Foundry IQ ist keine neue Suchmaschine und kein separater KI-Stack, sondern Microsofts verwaltete Wissensschicht für Agenten — gebaut auf Azure AI Search und dessen Agentic-Retrieval-Funktionen. Es gibt keine separate Plattform, auf die Sie migrieren müssten; die Rechnung landet weiterhin bei Azure AI Search und Azure OpenAI.

Belanglos ist das trotzdem nicht. Foundry IQ kann mehrere Wissensquellen in einer Knowledge Base bündeln, Suchanfragen in Teilfragen zerlegen, Quellen auswählen, Ergebnisse mit Zitaten zurückgeben und — je nach Quelle und Konfiguration — Berechtigungen berücksichtigen. Der Preis dafür ist nicht nur Geld, sondern Komplexität: zusätzliche Tokenkosten, höhere Latenz, Preview-Anteile, Quellkonfiguration, Berechtigungsdetails und mehr Betriebsverantwortung.

Für viele Schweizer KMU ist deshalb nicht die Frage: «Brauchen wir Foundry IQ?» Die bessere Frage lautet: «Sind unsere Nutzerfragen wirklich so zusammengesetzt, quellenübergreifend und berechtigungssensitiv, dass klassisches RAG oder der Minimalmodus nicht mehr reichen?» Dieser Artikel liefert das Raster, um genau das zu beantworten.

Was Microsoft mit «Foundry IQ» tatsächlich verkauft

Foundry IQ ist Microsofts Foundry-seitige, verwaltete Wissensschicht für KI-Agenten: Knowledge Bases, die eine oder mehrere Wissensquellen unter einem Endpunkt bündeln, plus die Integration in Azure OpenAI und den Foundry Agent Service. Die Suchmaschine darunter ist Azure AI Search; der Motor, der Anfragen plant und zerlegt, heisst Agentic Retrieval. Microsofts FAQ sagt es direkt: «Foundry IQ is built on Azure AI Search's agentic retrieval capabilities» — und wer eigene Lösungen baut, kann Agentic Retrieval auch ohne den Foundry-Überbau direkt über die Azure-AI-Search-APIs nutzen. Zur selben Einordnung kommt unabhängig die Beratungsfirma Spyglass.

Wichtig für die Budgetdiskussion: Es gibt durchaus etwas zu konfigurieren und zu bezahlen — Microsoft betreibt sogar eine eigene «Foundry IQ pricing»-Seite, deren Untertitel «Foundry IQ (Azure AI Search)» die Verwandtschaft gleich mitliefert. Aber es gibt keine separate Suchplattform zu evaluieren und kein Migrationsprojekt zu planen. Die Agentic-Retrieval-Aktivität wird laut derselben Seite unter «Azure AI Search» verrechnet; die LLM-Anteile unter Azure OpenAI.

Weil die Begriffe im Umlauf munter vermischt werden, hier die saubere Trennung:

Eine Randnotiz zur Orientierung: Die FAQ nennt drei IQ-Workloads — Work IQ für Microsoft-365-Kontext, Fabric IQ für strukturierte Geschäftsdaten, Foundry IQ für Unternehmenswissen. Auf der Marketing-Hubseite kommt Web IQ für Live-Webinhalte als viertes Familienmitglied dazu. Wer die Namen verwechselt, befindet sich in bester Gesellschaft. Für diesen Artikel gilt: Foundry IQ ist die Schicht für den belegten Abruf aus Dokumenten- und Wissensquellen.

Was sich gegenüber klassischem RAG ändert

Klassisches RAG stellt pro Frage genau eine Suchanfrage und übergibt die Treffer dem Modell. Die Agentic-Retrieval-Übersicht beschreibt den agentischen Ansatz dagegen als «retrieval as a reasoning task»: Ein LLM analysiert die Frage samt Gesprächsverlauf, zerlegt sie in Teilanfragen, wählt die passenden Wissensquellen aus, fragt sie parallel ab, prüft, ob das Signal reicht, iteriert bei Bedarf und liefert belegte Ergebnisse zurück.

Konkret kauft man mit einer Foundry-IQ-Knowledge-Base gegenüber einem selbst gebauten Single-Query-Stack diese Fähigkeiten ein:

Indexierte Quellen übernehmen laut FAQ Chunking, Vektorisierung, Metadaten-Extraktion und ACL-Synchronisation automatisch; Remote-Quellen (SharePoint via Copilot Retrieval API, Web via Grounding with Bing) speichern nichts, sondern fragen das Quellsystem zur Laufzeit ab. Abgerufen wird die Knowledge Base über die Retrieve-API — oder als MCP-Endpunkt, was sie für Agenten ausserhalb des Foundry-Ökosystems anschlussfähig macht.

Das Entscheidungsmodell: klassisches RAG, «minimal», «low» oder «medium»

Die eigentliche Entscheidung ist keine Produktentscheidung, sondern die Wahl einer Stufe. Der Reasoning-Effort-Regler macht daraus ein Kontinuum — und dass Microsoft einen agentischen Modus mit eingebautem Ausschalter liefert, ist das stillschweigende Eingeständnis, dass die volle Stufe schwer und teuer ist:

Ein Warnhinweis zu allen Limiten in diesem Umfeld: Sie sind API-versionsabhängig und haben sich bereits verschoben. In der 2026-05-01-preview erlauben «low» und «medium» auf den meisten Bezahl-Tiers bis zu 10 Wissensquellen pro Knowledge Base; ältere Preview-Versionen limitierten auf 3 Teilanfragen aus 3 Quellen («low») beziehungsweise 5 aus 5 («medium»). Wer solche Zahlen in eine Architekturentscheidung einbaut, prüft sie gegen die konkret verwendete API-Version — nicht gegen einen Blogartikel, auch nicht gegen diesen.

Das verlässlichste Entscheidungskriterium bleibt der Fragetyp. Solange Ihre Nutzer nachschlagen, definieren und verifizieren («Was steht im Vertrag zu Kündigungsfristen?»), trägt eine einzelne gute Suchanfrage. Sobald Fragen mehrere Quellen kombinieren und Zwischenschritte brauchen («Welche Mandate betrifft die Regeländerung, und was haben wir ihnen zugesichert?»), beginnt der Bereich, in dem geplante Teilanfragen ihren Aufpreis wert sind. Eine harte Dokumentenzahl als Schwelle gibt es nicht; kippen kann es schon ab einigen hundert Dokumenten, wenn die Fragen zusammengesetzt sind.

Was es kostet — und was es an Latenz kostet

Die vier Zähler, die sich bewegen können

Eine seriöse Kostenbetrachtung trennt vier Posten, die unabhängig voneinander laufen:

1. 1Azure-AI-Search-Kapazität oder Serverless-Compute. Klassisch als Fixkostenblock pro Search Unit; neu wahlweise als Serverless-Tarif in Compute Units (0.25-CU-Schritte pro Minute). Für Serverless hat die Verrechnung noch nicht begonnen — laut Preisseite erwartet ab Ende 2026, mit mindestens 30 Tagen Vorankündigung. Eine belastbare Serverless-Kostenschätzung ist heute schlicht nicht möglich.
2. 2Agentic-Retrieval-Tokens, verrechnet in Azure AI Search. Die ersten 50 Millionen Tokens pro Monat sind frei; danach kosten «minimal» und «low» USD 0.022 pro Million Tokens, «medium» USD 0.10 pro Million — die iterative Stufe ist also auch pro Token rund viereinhalbmal teurer.
3. 3Azure-OpenAI-Tokens für Query-Planung und Answer Synthesis. Separat verrechnet, skalieren mit jeder geplanten Teilanfrage. Unterstützt sind dafür nur gpt-4o-, gpt-4.1- und gpt-5-Modelle aus Azure OpenAI.
4. 4Quellenspezifische Zusatzkosten. Remote-SharePoint und Web werden separat verrechnet; Remote-SharePoint setzt zusätzlich Microsoft-365-Copilot-Lizenzen für die Endnutzer voraus — ein Posten, der in keiner Azure-Rechnung auftaucht und trotzdem budgetrelevant ist.

Eine anekdotische Referenzgrösse — keine Foundry-IQ-Schätzung

Zur Grössenordnung des Fundaments eine reale Zahl aus meinem eigenen Betrieb, ausdrücklich als anekdotischer Vergleichswert gekennzeichnet: Mein RAG-Produkt AmpliQ — klassische Single-Query-Architektur auf Azure AI Search, ohne agentische Stufe — kostete im Mai 2026, einem Monat mit bewusst tiefer Nutzung, CHF 491:

Die Lehre daraus betrifft die Zähler eins bis drei: Die Suchkapazität ist ein Fixkostenblock — die S1-Einheit kostet ihre rund CHF 178 im Monat, ob zehn oder zehntausend Abfragen laufen. Die Token-Kosten dagegen skalieren mit der Nutzung. Genau dort setzt die agentische Stufe an: Sie erhöht nicht primär die Fixkosten, sondern multipliziert die Modellaufrufe pro Frage — auf Zähler zwei und drei gleichzeitig.

Der Latenz-Aufpreis ist dokumentiert und gewollt

Die Planungsschritte kosten Zeit. Microsoft benennt das in der Übersicht selbst: «Agentic retrieval adds latency compared to a single-query pipeline, but it handles query complexity that a single query can't.» Gegen die Latenz nennt Microsoft drei Hebel: ein kleineres, schnelleres Modell für die Query-Planung, das Zusammenfassen langer Gesprächsverläufe vor der Abfrage und den Schalter auf «minimal».

Zu realen Antwortzeiten existieren belegte Community-Daten: Ein Microsoft-Q&A-Thread zur Foundry-Orchestrierung beschreibt normale Antworten bei etwa 3 bis 6 Sekunden, mit Ausreissern von 20 bis über 40 Sekunden bei kaltem Cache oder regionaler Auslastung. Berichte über 90 bis 120 Sekunden und mehrminütige Antworten betreffen das Model-Serving im Foundry-Ökosystem generell und sind nicht bestätigt Foundry-IQ-spezifisch.

Der Schweizer Blick: gut versorgt — aber kein Sonderfall

Hier eine Korrektur an einer Erzählung, die auch durch meine eigene frühere Recherche geisterte: Switzerland North sei eine von nur drei Regionen weltweit mit Agentic Retrieval. Das ist überholt. Laut der aktuellen Regionsliste unterstützen inzwischen Dutzende Regionen Agentic Retrieval — in Europa unter anderem France Central, Germany West Central, Italy North, Sweden Central, UK South, West Europe sowie Switzerland North und Switzerland West (Stand: Juli 2026). Ein exklusiver Schweizer Zugangsvorteil ist das nicht mehr.

Was für Schweizer Deployments trotzdem zählt: Switzerland North ist vollständig versorgt — Agentic Retrieval inklusive Free-Tier-Unterstützung, Semantic Ranker und Query Rewrite — und gehört zu den rund 15 Regionen weltweit, in denen auch die iterative Stufe «medium» verfügbar ist. Wer in Switzerland North bereits Azure AI Search betreibt, kann die agentische Stufe also ohne Regionswechsel und ohne Datenexport in eine andere Geografie testen. Das ist der praktisch relevante Punkt — nicht ein vermeintlicher Exklusivzugang.

Und: Regionale Verfügbarkeit ist keine Datenresidenz-Zusage; diese zwei Konzepte werden gern verschmolzen. Auf Ebene der Foundry-Plattform hängt eine vertragliche EU-Residenz-Garantie an speziellen Data-Zone-SKUs in Sweden Central oder Germany West Central; eine Foundry-IQ-spezifische Residenz-Zusage adressiert derzeit keine auffindbare Quelle. Dazu kommt der Hinweis aus Microsofts eigenen Preview-Bedingungen: Die 2026-05-01-preview unterstützt Verbindungen zu Dritt-Services, deren Nutzung Datenflüsse ausserhalb der Azure-Compliance-Grenze auslösen kann — die Verantwortung dafür liegt explizit beim Kunden. Wer revDSG- oder FINMA-Anforderungen hat, klärt die Residenzfrage deshalb pro Feature und pro Wissensquelle, nicht pro Region.

Wann sich ein Test lohnt: drei Ja-Szenarien

Microsoft publiziert keine Schwelle, ab der sich die agentische Stufe lohnt; die folgende Signatur ist Editorial Synthesis aus der Quellenlage: mehrere getrennte, zugriffsgeschützte Wissensquellen, echte zusammengesetzte Fragen und eine heterogene Dokumentbasis. Konkret sehen Ja-Kandidaten so aus:

1. 1Der regulierte Policy-Assistent. Kombiniert SharePoint-Weisungen, HR-Dokumente, Vertragsvorlagen und aktuelle Web- oder Regulatorik-Quellen — mit berechtigungsbewusstem Abruf, weil nicht jede Mitarbeiterin jede Weisung sehen darf. Hier zahlen Multi-Source-Föderation, Quellenauswahl und ACL-Unterstützung direkt ein.
2. 2Der Mandats- oder Projekt-Intelligence-Agent. Muss Verträge, Offerten, Sitzungsnotizen, Lieferdokumente und Statusberichte über geschützte Arbeitsbereiche hinweg kombinieren («Welche Mandate betrifft die Regeländerung, und was haben wir ihnen zugesichert?»). Das ist der Prototyp der zusammengesetzten Frage, an der Single-Query-RAG scheitert.
3. 3Der Support- und Knowledge-Operations-Agent. Nutzt Produktdokumentation, Ticket-Historie, interne Runbooks, Known-Issues-Listen und Webwissen — und braucht belegte, zitierfähige Antworten, weil nachgelagerte Agenten oder Menschen auf der Evidenz weiterarbeiten.

Zwei Einordnungen gehören zu jedem Ja: Microsofts «36 % relevantere Antworten» sind eine Eigenmessung ohne offengelegte Methodik. Und die Wissensquellen-Liste ist Microsoft-zentrisch, ein Betrieb gegen Nicht-Azure-Modelle nicht vorgesehen: Das kritisiert mit Graphlit ausgerechnet ein Konkurrent, aber die Abhängigkeit von Azure AI Search und Azure OpenAI bestätigen Microsofts eigene Docs.

Wann Sie (noch) verzichten: drei Nein-Szenarien und die Checkliste

Das typische Schweizer KMU-Szenario sieht anders aus als Microsofts Demo. Drei Konstellationen, in denen klassisches RAG oder die Stufe «minimal» sehr wahrscheinlich reicht — wieder als Editorial Synthesis, nicht als Microsoft-Empfehlung:

1. 1Eine SharePoint-Bibliothek, überwiegend Nachschlagefragen. «Wo steht …?», «Was gilt für …?» — eine gute hybride Suchanfrage trägt, die LLM-Planung hätte nichts zu planen.
2. 2Ein kuratierter PDF- oder Handbuch-Korpus. Homogene Quelle, homogene Struktur: Der Mehrwert von Quellenauswahl und Teilanfragen fällt weg, die Latenz und die Tokenkosten bleiben.
3. 3Ein internes Prozesshandbuch, wo deterministische Suche plus klassisches RAG bereits funktioniert. Ein laufendes System gegen ein Preview-Feature einzutauschen, ist keine Modernisierung, sondern Risikotransfer ohne Gegenwert.

Halten Sie Ihre eigene Wissensbasis gegen fünf Fragen:

• Liegen Ihre Dokumente in mehr als einer zugriffsgeschützten Quelle?
• Kombinieren typische Nutzerfragen mehrere Quellen oder Zwischenschritte?
• Ist die Dokumentbasis heterogen (Verträge, Mails, Tabellen, Scans)?
• Tolerieren Ihre Nutzer spürbar längere Antwortzeiten für bessere Antworten?
• Trägt Ihr Budget zusätzliche Modellaufrufe pro Frage — auf zwei Zählern gleichzeitig?

Bei zwei oder mehr Nein: Bleiben Sie bei klassischem RAG oder «minimal», und streichen Sie «Foundry IQ evaluieren» von der Projektliste. Das Zielbild trägt trotzdem: Eine 50-Personen-Treuhandfirma betreibt klassisches RAG über die Mandatsdokumente, Antworten kommen in ein bis zwei Sekunden mit Fundstelle, geprüft und entschieden wird weiterhin von Menschen. Die agentische Stufe bleibt eine dokumentierte Option für den Tag, an dem die Fragen zusammengesetzter werden.

Betriebsrealität: was nach dem Ja auf Sie zukommt

Wer die agentische Stufe einführt, übernimmt Betriebsaufgaben, die in den Ankündigungen nicht vorkommen:

• Quellenkuratierung ist Arbeit. Die Quellenauswahl funktioniert nur so gut wie die Beschreibungen der Wissensquellen und die Retrieval-Instruktionen der Knowledge Base («use the employee-handbook-index for questions about time off»). Ohne diese Pflege wählt die Engine blind.
• Berechtigungen sind ein Projekt, kein Häkchen. ACL-Synchronisation pro Quelle konfigurieren, den Remote-SharePoint-Sonderweg samt Copilot-Lizenzfrage klären, und testen, dass Resultate tatsächlich identitätsgefiltert ankommen.
• API-Versions-Churn einplanen. Limits und Fähigkeiten haben sich zwischen Preview-Versionen bereits verschoben; wer heute gegen 2026-05-01-preview baut, budgetiert Anpassungsaufwand für die nächste Version mit.
• Preview/GA-Gemenge im Blick behalten. Teile von Agentic Retrieval sind in der REST-API 2026-04-01 GA, der Reasoning-Effort-Regler und weitere Funktionen bleiben Preview — «not recommended for production workloads» steht wörtlich in Microsofts eigenen Preview-Hinweisen. Dokumentierte Reibung wie fehlende UI-Felder beim Anbinden von SharePoint-Quellen gehört zum aktuellen Reifegrad.
• Evaluation und Monitoring aufsetzen. Query-Pläne und Activity-Logs zeigen, was gesucht wurde; ohne eigene Relevanz- und Latenzmessung bleibt die Frage «ist medium den Aufpreis wert?» unbeantwortbar.

Und eine Plattform-Grenze, die für die Toolwahl zentral ist: Knowledge Bases lassen sich aus dem Foundry Agent Service, dem Microsoft Agent Framework oder jeder eigenen Applikation über die Azure-AI-Search-APIs aufrufen. Nicht kompatibel sind sie mit der Copilot-Welt: Laut FAQ sind Copilot-Wissensquellen und Foundry-IQ-Wissensquellen konzeptionell ähnlich, aber nicht interoperabel — Foundry-IQ-Quellen funktionieren nicht in Copilot, Copilot-Quellen nicht in Foundry IQ. Wer zwischen Copilot Studio, M365 Copilot und einem eigenen Foundry-Agenten abwägt, entscheidet damit auch, in welchem der beiden getrennten Wissensquellen-Ökosysteme investiert wird.

Was ich in eigenen Deployments sehe

Zuerst die Offenlegung: Ich baue und verkaufe Retrieval-Lösungen, unter anderem AmpliQ. An einer Empfehlung für die teurere agentische Stufe würde ich kurzfristig verdienen — gerade deshalb dürfen Sie die Aussage «Sie brauchen sie wahrscheinlich nicht» ernst nehmen.

Was klassisches Single-Query-RAG leistet, sehe ich täglich: In Kundendeployments antwortet der AmpliQ-Stack — Azure AI Search, hybride Suche, eine Abfrage pro Frage — end-to-end meist unter ein bis zwei Sekunden. Das ist die Referenz, gegen die ein agentischer Aufpreis von mehreren Sekunden bis zweistelligen Sekunden antreten muss.

Die zweite, unbequemere Beobachtung: Rate Limits. Trotz erheblicher Arbeit an der Retrieval-Strategie, gerade um Modellaufrufe zu sparen, schlagen die Token-Kontingente der Modell-Deployments schneller an, als Budgetpläne es vorsehen. Daraus folgt für die agentische Stufe eine einfache Rechnung: Query-Planung, Teilanfragen und Synthese machen aus einer Nutzerfrage mehrere Modellaufrufe. Wer heute schon an Kontingenten anschlägt, multipliziert dieses Problem, bevor die erste bessere Antwort ankommt.

Ein eigener Foundry-IQ-Test in Switzerland North steht bei mir noch aus; die Zahlen oben sind der klassische Kontrast, keine agentische Messung. Auch das gehört zur Ehrlichkeit.

Häufige Fragen

Ist Foundry IQ generell verfügbar (GA)?

Gestaffelt — und die Antwort hängt an der API-Version. Teile von Agentic Retrieval sind in der REST-API 2026-04-01 generell verfügbar; der Reasoning-Effort-Regler, der Serverless-Tarif und einzelne Konnektoren bleiben Preview und verlangen die 2026-05-01-preview. Dass ein älterer Q&A-Thread Foundry IQ pauschal als «not recommended for production workloads» einstufte, während spätere Produktkommunikation GA verkündete, ist Timeline-Drift, kein Widerspruch: Beide Aussagen stimmten zu ihrem Zeitpunkt — und für die Preview-Anteile gilt der Produktions-Vorbehalt bis heute.

Wie gut ist Foundry IQ wirklich?

Belastbare unabhängige Messungen existieren nicht. Microsofts eigene Zahlen — 36 % relevantere Antworten, bis zu 54 % mehr Recall, eine 10'000-Query-Studie zur Groundedness — stammen sämtlich aus Microsoft-eigenen, selbst bewerteten Benchmarks ohne unabhängige Replikation. Als Richtungssignal brauchbar, als Entscheidungsgrundlage nicht.

Kann ich Foundry-IQ-Wissensquellen in Copilot nutzen — oder umgekehrt?

Nein. Laut Microsofts FAQ sind die Konzepte ähnlich, die Quellen aber nicht interoperabel: Foundry-IQ-Wissensquellen funktionieren nicht in Copilot, Copilot-Wissensquellen nicht in Foundry IQ. Die Plattformwahl ist damit auch eine Investitionsentscheidung für eines der beiden Ökosysteme.

Was ist der Unterschied zwischen Foundry IQ, Work IQ und Fabric IQ?

Work IQ liefert Agenten Kontext aus Microsoft 365 (wer arbeitet woran: Mails, Meetings, Dokumente), Fabric IQ eine semantische Schicht über strukturierten Geschäftsdaten, Foundry IQ den belegten Abruf aus Dokumenten- und Wissensquellen. Auf der Marketing-Hubseite kommt Web IQ für Live-Webinhalte als viertes Familienmitglied dazu.

Fazit: Bewerten Sie nicht die Marke, sondern Ihre Fragen

Foundry IQ ist kein neues Produkt, das Sie als solches evaluieren müssten: Es ist Microsofts verwaltete Wissensschicht auf Azure AI Search und Agentic Retrieval — real und in Teilen nützlich, aber kein Migrationsziel und kein Pflichtprogramm. Was bleibt, sind drei Dinge: die Einordnung, die Ihnen ein Scheinevaluationsprojekt erspart; ein Fähigkeits- und Kostenraster, das die vier beweglichen Zähler benennt; und ein Entscheidungsmodell entlang des Fragetyps statt entlang des Produktnamens.

Die bessere Abschlussfrage lautet deshalb nicht «Foundry IQ: ja oder nein?», sondern: Sind Ihre Nutzerfragen wirklich so zusammengesetzt, quellenübergreifend und berechtigungssensitiv, dass klassisches RAG oder der Minimalmodus nicht mehr reichen — und ist Ihre Wissensbasis überhaupt der Engpass, oder Ihre Retrieval-Architektur? Wenn Sie das für Ihr eigenes Setup nicht sicher beantworten können, ist genau diese Frage der Gegenstand eines unabhängigen RAG- und Grounding-Reviews von PowerLeap. Die Checkliste oben können Sie aber schon morgen selbst gegen Ihre Dokumentenbasis halten — bevor es ein Anbieter für Sie tut.