Microsoft Enterprise RAG: Azure AI Search, Foundry IQ und Copilot Studio

Für Unternehmen mit Microsoft 365 und Azure liegt ein RAG-Aufbau auf der vorhandenen Plattform nahe. Automatisch richtig ist diese Wahl nicht: Ein produktives System benötigt weiterhin saubere Dokumente, kontrolliertes Retrieval, Identitäten, Berechtigungen, Evaluation und Betrieb.

Warum Microsofts RAG-Stack jetzt relevant ist

RAG – Retrieval-Augmented Generation – sucht relevante Passagen aus freigegebenen Unternehmensinformationen und gibt sie dem Sprachmodell als Kontext. Antworten können so auf aktuellen internen Quellen beruhen und Fundstellen ausweisen.

Microsoft entwickelt diese Architektur inzwischen in zwei Richtungen weiter. Klassisches RAG bleibt als kontrollierbare Pipeline mit Azure AI Search und einem Modell-Endpunkt verfügbar. Parallel positioniert Microsoft mit Foundry IQ eine verwaltete Wissensschicht, die mehrere Quellen für Agenten bündeln und Anfragen über ein agentisches Retrieval zerlegen kann.

RAG kann damit von einer einzelnen Chat-Anwendung zur wiederverwendbaren Wissensinfrastruktur für mehrere Assistenten werden. Zugleich steigen die Anforderungen an Berechtigungen, Kostenkontrolle und Lebenszyklusmanagement.

Welcher Microsoft-Weg passt?

Die Produktauswahl sollte vom Betriebsmodell ausgehen, nicht von der Länge der Funktionsliste. Entscheidend ist, ob zuerst ein begrenzter Low-Code-Assistent, eine kontrollierte eigene RAG-Pipeline oder eine gemeinsam genutzte Wissensbasis für mehrere Agenten produktiv werden soll.

Die Wege können kombiniert werden: Copilot Studio kann Azure AI Search anbinden, Foundry IQ baut auf Azure AI Search auf. Foundry File Search bleibt für einen begrenzten hochgeladenen Dokumentbestand pragmatisch. Entscheidend ist, welche Schicht das Unternehmen selbst gestalten, prüfen und betreiben will.

Azure AI Search: Die Retrieval-Schicht

Azure AI Search ist der technische Kern des Microsoft-RAG-Stacks. Der Dienst speichert Suchindizes und kann Volltext-, Vektor- und hybride Abfragen ausführen. Bei hybrider Suche werden klassische Schlüsselwortsuche und semantische Vektorsuche parallel ausgeführt und die Treffer zusammengeführt.

Integrierte Vektorisierung reduziert Pipeline-Code

Mit integrierter Vektorisierung können Indexer Dokumente einlesen, in Abschnitte teilen, Embeddings erzeugen und die Ergebnisse in einen Vektorindex schreiben. Microsoft stellt dafür unter anderem Text-Splitting und layoutorientierte Verarbeitung bereit.

Das senkt den Entwicklungsaufwand, ersetzt aber keine fachliche Konfiguration. Ein Wartungshandbuch, ein Vertrag und eine tabellarische Preisliste benötigen unterschiedliche Chunking-Strategien. Werden Überschriften, Tabellenbezüge oder Dokumenthierarchien zerstört, findet auch ein gutes Embedding-Modell nicht zuverlässig die richtige Passage.

Hybrid Search ist häufig belastbarer als reine Vektorsuche

Vektorsuche findet semantisch ähnliche Inhalte, Volltextsuche exakte Produktnummern, Fehlercodes oder Paragraphen. Die Kombination ist bei Unternehmensdokumenten oft belastbarer. Ob zusätzlich der kostenpflichtige Semantic Ranker hilft, muss ein festes Testset mit Volltext-, Vektor- und Hybridvarianten zeigen.

Quellenangaben müssen im Index vorbereitet werden

Eine zitierfähige Antwort entsteht nicht allein durch das Modell. Der Index muss Metadaten wie Dokumenttitel, URL, Version, Seiten- oder Abschnittsreferenz enthalten. Auch Copilot Studio benötigt bei der Anbindung von Azure AI Search ein passendes URL-Feld, damit Quellen als Links ausgegeben werden können.

Microsoft Foundry und Foundry IQ: Vom RAG-Endpunkt zur Wissensschicht

Microsoft Foundry stellt Modelle, Agentenentwicklung, Evaluation und Deployment-Funktionen bereit. Azure AI Search kann darin als Index und Retrieval-Werkzeug verwendet werden. Foundry IQ setzt eine Ebene darüber: Wissensquellen werden zu einer Knowledge Base gebündelt, die mehrere Agenten oder eigene Anwendungen über einen gemeinsamen Endpunkt nutzen können.

Klassisches Retrieval oder agentisches Retrieval?

Klassisches Retrieval gibt die besten Indextreffer direkt an das Sprachmodell weiter und bleibt vergleichsweise vorhersehbar, messbar und kostenseitig begrenzbar. Agentisches Retrieval kann komplexe Fragen dagegen zerlegen, mehrere Quellen durchsuchen und Ergebnisse zusammenführen.

Diese Planungslogik hilft bei quellenübergreifenden Fragen, erhöht aber Latenz, Tokenverbrauch und Fehlermöglichkeiten. Für einfache FAQ- oder Richtlinienanfragen ist sie deshalb nicht automatisch die bessere Wahl.

Copilot Studio: Der schnelle Weg für Microsoft-365-nahe Szenarien

Copilot Studio ist die Low-Code-Option für klar begrenzte Microsoft-365-nahe Fachprozesse. Fachbereichsteams können etwa SharePoint, Dataverse, Websites oder Copilot Connectors als Wissensquellen anbinden und Antworten in Teams, Microsoft 365 Copilot oder eigene Kanäle bringen.

Bei unterstützten authentifizierten SharePoint-Szenarien können vorhandene Berechtigungen berücksichtigt werden; Umfang und Aktualität müssen für den konkreten Connector und Use Case getestet werden. Die Grenze liegt in der technischen Kontrolle: Retrieval-Stufen, Ranking und Evaluation lassen sich weniger frei gestalten als in einer eigenen Azure-Anwendung. Für einen zentralen Dienst mit vielen Anwendungen, eigenen Frontends oder komplexen Datenquellen ist eine eigene Azure-Architektur meist passender.

Sicherheit und Berechtigungen: Der schwierigste Teil liegt vor dem Modell

RAG kann sensible Informationen leichter auffindbar machen. Ein zuvor verborgenes Dokument wird nicht harmlos, nur weil das Sprachmodell seine Inhalte zusammenfasst. Die wichtigste Sicherheitsfrage lautet deshalb: Welche Passagen darf dieser konkrete Nutzer abrufen?

Drei Berechtigungsmuster

Azure AI Search bietet mehrere Wege für Zugriffskontrolle auf Dokumentebene:

1. Security-Filter: Nutzer- oder Gruppenkennungen werden als Metadaten in den Index geschrieben und bei jeder Anfrage als Filter übergeben. Das ist flexibel, aber die Anwendung trägt Verantwortung für korrekte Identitäten und Filter.
2. Native ACL- oder RBAC-Muster: Berechtigungsinformationen aus unterstützten Quellen können in den Index übernommen und gegen Entra-Identitäten geprüft werden. Teile dieser Funktionen sind weiterhin Preview.
3. Purview-Sensitivitätsbezeichnungen: Labels können bei unterstützten Quellen indexiert und bei der Abfrage berücksichtigt werden. Auch hier gelten API-, Mandanten- und Preview-Einschränkungen.

Besonders kritisch ist Chunking. Wenn ein Dokument in viele Textabschnitte zerlegt wird, müssen Berechtigungs- und Sensitivitätsmetadaten auf jeden Chunk projiziert werden. Fehlt diese Vererbung, kann eine technisch korrekte Suche trotzdem unzulässige Passagen liefern.

SharePoint-Berechtigungen sind kein Selbstläufer

Microsoft dokumentiert für den SharePoint-Indexer Einschränkungen bei externen Nutzern, bestimmten Freigabelinks und Informationsrichtlinien. Änderungen an Elementen mit eigenen Berechtigungen können mit dem nächsten erfolgreichen Indexlauf übernommen werden. Ändert sich dagegen eine vererbte Berechtigung auf Site-, Bibliotheks-, Listen- oder Ordnerebene, kann ein expliziter Berechtigungs-Resync erforderlich sein. Unternehmen müssen deshalb messen, wie lange entzogene Rechte im RAG-Index noch wirksam bleiben könnten. Für neue eigene RAG-Anwendungen mit SharePoint sollte außerdem geprüft werden, ob Microsofts Remote-SharePoint-Knowledge-Source geeigneter ist als eine vollständige Indexierung.

Manipulierte Quellen sind ein eigenes RAG-Risiko

Korrekte Berechtigungen schützen nicht vor fachlich falschen oder absichtlich manipulierten Inhalten. Versteckte Anweisungen in Dokumenten, Webseiten oder Tickets können als indirekte Prompt-Injection in den Modellkontext gelangen. RAG beseitigt dieses Risiko nicht. Besonders kritisch wird es, wenn ein Agent auf Basis solcher Treffer Werkzeuge aufrufen, Nachrichten versenden oder Daten verändern darf.

Ein belastbarer Pilot trennt deshalb vertrauenswürdige und veränderbare Quellen, prüft neue Inhalte vor der Indexierung und behandelt abgerufene Dokumenttexte grundsätzlich als Daten statt als Anweisungen. Der Goldstandard sollte manipulierte Dokumente, widersprüchliche Quellen und versuchte Datenabflüsse enthalten. Technische Rechtebegrenzung, Tool-Allowlisting und Protokollierung bleiben auch dann erforderlich, wenn die Modellantwort plausibel wirkt.

Netzwerk und Schlüssel

Für sensible Architekturen gehören Managed Identities, rollenbasierte Zugriffssteuerung, Private Endpoints, deaktivierter öffentlicher Netzwerkzugriff und eine kontrollierte Schlüsselstrategie in das Zielbild. Customer-Managed Keys können je nach Schutzbedarf ergänzen, lösen aber keine fehlerhaften Inhaltsberechtigungen.

Datenschutz und DACH-Perspektive

Microsoft erklärt für Azure Direct Models in Foundry, dass Prompts und Antworten nicht zum Training der Basismodelle verwendet werden. Die Datenverarbeitung richtet sich jedoch nach Deployment-Typ und gewählter Geografie. Globale oder Data-Zone-Bereitstellungen können andere Verarbeitungsorte und Betriebsmodelle haben als regionale Deployments.

Für eine DSGVO-Einordnung reicht diese Herstellerzusage nicht aus. Unternehmen müssen Zweck, Rechtsgrundlage, Datenkategorien, Aufbewahrung, Empfänger, Drittlandbezug und Betroffenenrechte für den konkreten Use Case bewerten. Bei personenbezogenen oder besonders sensiblen Daten kann eine Datenschutz-Folgenabschätzung erforderlich sein. Das ist eine organisatorische und rechtliche Prüfung, keine automatische Produkteigenschaft.

Der AI-Fabrik-Lernpfad Datenschutz & KI-Recht vertieft diese Prüffelder. Eine rechtliche Einzelfallprüfung kann der Artikel nicht ersetzen.

Kosten: Microsoft-RAG wird über mehrere Zähler abgerechnet

Eine einzelne Preiszahl wäre irreführend. Suche, Indexierung, Embeddings, Ranking, agentisches Retrieval, Modell-Inferenz, Copilot-Kapazität sowie Betrieb und Governance werden über unterschiedliche Zähler abgerechnet.

Im Dedicated-Modell von Azure AI Search steigt der Preis mit zusätzlichen Replikaten und Partitionen linear über die Search Units. Für Hochverfügbarkeit sind laut Microsoft mehrere Replikate erforderlich. Der aktuell angebotene Serverless-Ansatz kann für schwankende Last interessant sein, bietet in der Preview jedoch keinen SLA und unterstützt nicht alle Netzwerkfunktionen.

Im Pilot zählt deshalb nicht der isolierte Tokenpreis, sondern die Kosten pro fachlich korrekter und berechtigter Antwort einschließlich notwendiger Nacharbeit.

Qualität messen: Quellenanzeige ist noch kein Qualitätsnachweis

Microsoft Foundry stellt Evaluatoren für Retrieval, Dokument-Retrieval, Groundedness, Relevanz und Antwortvollständigkeit bereit. Das ist eine brauchbare Grundlage, ersetzt aber keinen unternehmenseigenen Goldstandard.

Ein belastbarer Test trennt drei Fehlerklassen:

• Retrieval-Fehler: Die richtige Passage wurde nicht gefunden.
• Generierungsfehler: Die Passage war vorhanden, wurde aber falsch interpretiert oder ergänzt.
• Governance-Fehler: Eine fachlich passende Passage hätte für diesen Nutzer nicht sichtbar sein dürfen.

LLM-basierte Evaluatoren sind selbst probabilistisch. Für kritische Anwendungsfälle brauchen Unternehmen zusätzlich fachlich geprüfte Referenzfragen, erwartete Quellen und klare Abbruchkriterien.

Empfohlene Pilotmetriken

Praxisbeispiel: Servicewissen beim DACH-Maschinenbauer

Hypothetisches, aber realistisches Szenario: Ein Maschinenbauer mit 1.200 Mitarbeitenden möchte Servicetechnikern Antworten aus deutsch- und englischsprachigen Wartungshandbüchern, Fehlercode-Listen, Sicherheitsanweisungen und Servicebulletins in SharePoint und Azure Storage liefern.

Phase 1: Copilot Studio für den begrenzten SharePoint-Bestand

Das Unternehmen startet mit freigegebenen Handbüchern einer Produktlinie in Copilot Studio. Der Pilot prüft Fragen, Dokumentqualität, Nutzerführung und Quellenanzeige.

Phase 2: Azure AI Search für kontrolliertes Retrieval

Für Fehlercodes, Tabellen und mehrsprachige Handbücher baut das Plattform-Team anschließend einen eigenen Azure-AI-Search-Index, testet hybride Suche und passt Chunking sowie Metadaten an.

Phase 3: Foundry IQ für mehrere Agenten

Foundry IQ kommt erst ins Spiel, wenn Serviceportal, interner Assistent und Ersatzteil-Agent dieselbe Wissensbasis benötigen und Berechtigungssynchronisation, Preview-Status sowie Kosten bewertet sind.

Der entscheidende Punkt ist die Reihenfolge: Das Unternehmen beginnt mit dem Wissensproblem, nicht mit der maximalen Plattformarchitektur.

Ein 90-Tage-Plan für den Microsoft-RAG-Pilot

Der Pilot beginnt mit einem Fachbereich, einer Nutzergruppe, klaren Datenklassen und 100 bis 150 realen Fragen. Danach werden Produktpfad, Region, Logging und mindestens fünf Rollenprofile festgelegt. Volltext-, Vektor- und hybride Suche werden auf demselben Goldstandard verglichen; manipulierte Dokumente und Prompt-Injection gehören ausdrücklich in das Testset. Erst nach einem begrenzten Fachbereichsbetrieb folgt die dokumentierte Go/No-Go-Entscheidung.

Kritische Einordnung: Integration ist Stärke und Abhängigkeit zugleich

Der Stack ist besonders attraktiv, wenn Entra, SharePoint, Azure, Purview und Power Platform bereits Kernsysteme sind. Dieselbe Integration erhöht jedoch den Wechselaufwand: Indizes, Rollen, Policies, Foundry-Projekte und Copilot-Studio-Agenten lassen sich nicht ohne Weiteres übertragen.

Ein bewusster Microsoft-Stack kann sinnvoller sein als fünf lose Einzelprodukte. Er bleibt eine Plattformentscheidung, die Architekturprinzipien, Exportstrategie, Kostenbeobachtung und eine klare Trennung zwischen allgemein verfügbaren und vorläufigen Funktionen benötigt.

FAQ

Verhindert Microsoft-RAG Halluzinationen?

Nein. RAG kann Antworten besser auf interne Quellen stützen, aber irrelevante Treffer, unvollständige Quellen und Modellfehler bleiben möglich. Quellenanzeige und Evaluation sind deshalb Pflicht.

Können Unternehmensdaten für das Modelltraining verwendet werden?

Microsoft erklärt für Azure Direct Models in Foundry, dass Prompts und Antworten nicht zum Training der Basismodelle verwendet werden. Unternehmen müssen dennoch Deployment-Typ, Geografie, Protokollierung, Missbrauchsüberwachung und Vertragsbedingungen für den konkreten Dienst prüfen.

Ist der Microsoft-Stack DSGVO-konform?

Kein Produkt ist pauschal DSGVO-konform. Die Bewertung hängt von Zweck, Daten, Rechtsgrundlage, Region, Vertrag, Berechtigungen, Aufbewahrung und organisatorischen Maßnahmen des konkreten Einsatzes ab.

Fazit: Microsoft-RAG ist eine Architekturentscheidung

Microsoft bietet einen weitgehend durchgängigen RAG-Stack. Sein Nutzen entsteht aber erst, wenn ein begrenzter Wissensprozess nachweisbar bessere Antworten liefert, Berechtigungen einhält und wirtschaftlich betrieben werden kann.

Der nächste Schritt ist ein Pilot-Canvas mit Use Case, Nutzergruppe, erlaubten Daten, erwarteten Quellen, Qualitätsmetriken, Verantwortlichen und Abbruchkriterien. Erst danach wird der passende Microsoft-Weg gewählt.

Weiterführende Artikel auf AI-Fabrik

• Microsoft Harrier OSS v1: Neue Embedding-Modelle für Enterprise-RAG
• Privacy Guardrails: Wie KI-Systeme Datenschutz automatisch durchsetzen
• AI Skills & Technologies Map: Ein Reifegradmodell für KI-Kompetenzen im Unternehmen
• Generative AI, Agentic AI und AI Agents: Der Unterschied einfach erklärt

Quellen

• Microsoft Learn: Retrieval-Augmented Generation in Azure AI Search, aktualisiert 2026, abgerufen am 20. Juli 2026.
• Microsoft Learn: Retrieval-Augmented Generation und Indizes in Microsoft Foundry, aktualisiert 2026, abgerufen am 20. Juli 2026.
• Microsoft Learn: Was ist Foundry IQ?, erneut geprüft am 11. September 2026.
• Microsoft Learn: Foundry IQ FAQ, aktualisiert 2026, abgerufen am 20. Juli 2026.
• Microsoft Learn: Hybrid Search in Azure AI Search, aktualisiert 2026, abgerufen am 20. Juli 2026.
• Microsoft Learn: Integrierte Vektorisierung in Azure AI Search, aktualisiert 2026, abgerufen am 20. Juli 2026.
• Microsoft Learn: Dokumentbasierte Zugriffskontrolle in Azure AI Search, erneut geprüft am 11. September 2026.
• Microsoft Learn: SharePoint-Berechtigungen mit Azure AI Search indexieren, erneut geprüft am 11. September 2026.
• Microsoft Learn: ACL- und RBAC-Durchsetzung zur Abfragezeit, abgerufen am 11. September 2026.
• Microsoft Learn: SharePoint in Microsoft 365 indexieren, abgerufen am 11. September 2026.
• Microsoft Learn: Purview-Sensitivitätsbezeichnungen mit Azure AI Search indexieren, aktualisiert am 8. Juli 2026, abgerufen am 20. Juli 2026.
• Microsoft Learn: RAG-Evaluatoren in Microsoft Foundry, aktualisiert 2026, abgerufen am 20. Juli 2026.
• Microsoft Learn: Preismodell und Service-Tarife für Azure AI Search, erneut geprüft am 11. September 2026.
• Microsoft Learn: Daten, Datenschutz und Sicherheit für Azure Direct Models in Microsoft Foundry, aktualisiert 2026, abgerufen am 20. Juli 2026.
• Microsoft Learn: SharePoint als Wissensquelle in Copilot Studio, aktualisiert 2026, abgerufen am 20. Juli 2026.
• Microsoft Learn: Azure AI Search als Wissensquelle in Copilot Studio, abgerufen am 20. Juli 2026.
• OWASP GenAI Security Project: LLM01:2025 Prompt Injection, abgerufen am 11. September 2026.
• EUR-Lex: Verordnung (EU) 2024/1689 – EU AI Act, insbesondere Artikel 4, abgerufen am 20. Juli 2026.