Microsoft 365 Copilot oder zusätzlicher RAG-Assistent?

Die Wahl zwischen einem vorhandenen Microsoft-Angebot und einem eigenen RAG-Assistenten verläuft entlang von drei Wegen:

1. Vorhandene Microsoft-Funktionen. Der erste Weg nutzt vorhandene Microsoft-Funktionen möglichst nah an den bereits verwalteten Inhalten.
2. Konfigurierter Agent. Der zweite konfiguriert einen thematisch begrenzten Agenten mit bestimmten Wissensquellen und Abläufen.
3. Eigene Anwendung. Der dritte baut eine eigene Anwendung, die Suche, Kontext, Modell und Oberfläche selbst steuert.

Zwischen diesen Wegen gibt es Übergänge. Eine angepasste Oberfläche kann einen verwalteten Suchdienst nutzen. Ein konfigurierter Agent kann eigene Schnittstellen aufrufen. Entscheidend ist deshalb nicht das Etikett, sondern die Verantwortung für die einzelnen Teile.

Microsoft beschreibt RAG ausdrücklich als Bestandteil von Copilot Studio. Produkt- und Architekturentscheidung müssen daher getrennt werden. Microsoft: RAG in Copilot Studio. Die hier genannten Produktdetails wurden am 26. September 2026 anhand der offiziellen Dokumentation geprüft; konkrete Tenant-, Regions- und Tarifbedingungen bleiben Teil der Einführung.

Erfassen Sie, welches Produkt tatsächlich lizenziert und aktiviert ist. Ein Unternehmen kann verschiedene Angebote unter dem Namen Copilot kennen, ohne dass deren Datenzugriff, Einsatzort und Abrechnung identisch sind. Notieren Sie Produkt, Umgebung, Nutzergruppe und administrative Einstellungen.

Für die Interaktion mit SharePoint-Agenten nennt Microsoft eine passende Copilot-Lizenz oder einen von der Organisation aktivierten nutzungsabhängigen Zugang. Das ist keine pauschale Aussage, dass jeder Microsoft-365-Nutzer sämtliche Agentenfunktionen ohne Zusatzkosten erhält. Microsoft: Einstieg in SharePoint-Agenten.

Prüfen Sie mit einem normalen Benutzerkonto, welche Quellen erreichbar sind und welche Funktionen tatsächlich erscheinen. Eine Vorführung mit dem administrativen Konto kann sowohl Lizenz- als auch Berechtigungsgrenzen verdecken. Halten Sie den getesteten Zustand fest, damit ein späterer Vergleich auf derselben Grundlage beruht.

Schreiben Sie für jede benötigte Quelle auf, welcher Inhalt verwendet wird: Seiten, Dateien, Anhänge, strukturierte Datensätze oder aktuelle Transaktionen. Ein Konnektorname allein sagt nicht, ob die entscheidende Ausnahme in einer Tabelle oder einem Anhang erhalten bleibt.

Prüfen Sie außerdem die Aktualisierung. Wie lange dauert es, bis eine Änderung in Antworten erscheint? Was geschieht bei einer gelöschten Datei oder einer abgelaufenen Verbindung? Wie werden historische und zukünftige Fassungen unterschieden? Diese Fragen gelten für Standardprodukte und eigene Anwendungen gleichermaßen.

Für aktuelle Bestände oder Statuswerte kann eine direkte Systemabfrage nötig sein. Ein regelmäßig importiertes Dokument kann fachlich zu alt sein, selbst wenn es technisch erfolgreich indexiert wurde. Formulieren Sie deshalb pro Quelle das erforderliche Aktualitätsfenster.

Testen Sie außerdem die Quellenlinks als gewöhnliche Nutzerin oder gewöhnlicher Nutzer. Eine technisch korrekte Quellenangabe, die sich nur für eine Administratorin öffnet, ist kein brauchbarer Beleg für die Person, die die Antwort erhält. Die Bewertung sollte den gesamten Weg von der Frage bis zur zugänglichen Belegstelle abdecken.

Für SharePoint-Agenten beschreibt Microsoft Antworten entsprechend den Berechtigungen der fragenden Person. Der Zugriff auf den Agenten und der Zugriff auf dessen Wissensquellen sind dabei getrennte Fragen. Microsoft: Agentenzugriff verwalten.

Besonders wichtig ist eine konkrete Ausnahme in der Copilot-Studio-Dokumentation: SharePoint-/OneDrive-Wissensquellen werden dort mit delegierter Authentifizierung und Security Trimming beschrieben. Die konfigurierte Azure-AI-Search-Verbindung wird dagegen als nicht delegiert und ohne automatische entsprechende Nutzerfilterung beschrieben. Das bedeutet nicht, dass Azure AI Search grundsätzlich keine Zugriffskontrolle kann. Es bedeutet, dass diese konkrete Verbindung nicht pauschal die gleichen Rechteigenschaften liefert. Microsoft: Wissensquellen und Authentifizierung.

Wenn unterschiedliche Nutzer nur Teilbestände sehen dürfen, muss die Lösung diesen Unterschied technisch durchsetzen. Die Anweisung „Beachte die Zugriffsrechte“ im Prompt genügt nicht. Dokumentieren Sie für jeden Pfad die verwendete Identität und testen Sie Rechteentzug sowie gemeinsame Caches.

Ein vorhandenes Angebot ist besonders prüfenswert, wenn Quellen und Identitäten bereits im gleichen verwalteten Umfeld liegen, die Aufgaben überwiegend aus Fragen zu diesen Inhalten bestehen und die vorhandene Oberfläche akzeptiert wird. Dadurch kann eigener Betriebsaufwand begrenzt werden.

Auch dann sind Bereinigung und Fachprüfung notwendig. Ein vorhandenes Produkt weiß nicht automatisch, welche von zwei widersprüchlichen Richtlinien verbindlich ist. Bestehende überbreite Freigaben können durch bessere Auffindbarkeit erst sichtbar werden. Die Einführung braucht deshalb einen Quellenverantwortlichen.

Beginnen Sie mit einem begrenzten Aufgabenpaket und prüfen Sie den tatsächlichen Nutzen. Wenn das Produkt die Aufgabe ausreichend löst, ist das ein gutes Ergebnis. Eine individuelle Entwicklung sollte einen nachweisbaren zusätzlichen Bedarf erfüllen, nicht lediglich mehr technische Kontrolle ermöglichen, die niemand benötigt.

Eine eigene Lösung kann sinnvoll sein, wenn ein notwendiger Suchablauf, eine spezielle Quelle, eine klare Mandantentrennung oder ein fachliches Ausgabeformat anders nicht ausreichend umsetzbar ist. Auch eine eng integrierte Oberfläche innerhalb eines bestehenden Arbeitsprozesses kann relevant sein.

Schreiben Sie die Lücke so konkret, dass sie getestet werden kann. „Wir brauchen mehr Flexibilität“ ist zu unbestimmt. „Die Antwort muss vier freigegebene Felder aus Quelle A und einen aktuellen Status aus System B mit getrennten Zugriffsprüfungen zeigen“ lässt sich dagegen vergleichen.

Mit zusätzlicher Kontrolle wächst die Betriebsverantwortung. Jemand muss Importfehler, Modellwechsel, Ausfälle, Quellenversionen und Sicherheitsmeldungen bearbeiten. Ein Prototyp, der eine gute Antwort erzeugt, belegt nicht, dass dieses Betriebsmodell vorhanden ist. Die RAG-Architektur hilft, die notwendigen Verantwortlichkeiten sichtbar zu machen.

Ein erfundenes Team nutzt freigegebene SharePoint-Anleitungen und ein separates System mit aktuellen Wartungsaufträgen. Ein Teil der Fragen betrifft allgemeine Produktabläufe, ein anderer Teil den Status eines bestimmten Kundenauftrags. Einige Techniker dürfen nur ihre eigenen Kunden sehen.

Für allgemeine Anleitungen kann ein SharePoint-Agent bereits passen. Für den aktuellen Auftragsstatus muss eine passende Systemverbindung einschließlich Identitätsprüfung nachgewiesen werden. Die Entscheidung kann daher aus zwei Wegen bestehen, statt sämtliche Aufgaben in ein einziges Produkt zu pressen.

Der Versuch sollte dieselben Fragen mit denselben zulässigen Quellen prüfen. Eine Variante darf nicht dadurch gewinnen, dass sie mehr vertrauliche Daten erhält. Bewertet werden richtige Antwort, gültiger Beleg, korrekte Rechte und tatsächlicher Aufwand bis zur erledigten Aufgabe. Dieses Szenario ist ein Planungsbeispiel, kein durchgeführter Produktvergleich.

Die folgende Entscheidungstabelle nennt je Kriterium den Nachweis, den ein Vergleich zwischen Copilot und einer eigenen RAG-Anwendung liefern sollte.

Legen Sie vorab fest, welche Kriterien zwingend sind. Ein günstigeres Angebot darf einen unzulässigen Zugriff nicht durch gute Antwortgeschwindigkeit ausgleichen. Andere Kriterien können gegeneinander abgewogen werden, wenn die Fachverantwortlichen die Folgen verstehen.

Trennen Sie zwingende Anforderungen von Wünschen. Eine exakte Markenfarbe im Chat kann wünschenswert sein, während der authentifizierte Zugriff auf eine geschützte Quelle unverzichtbar sein kann. Diese Unterscheidung verhindert, dass Unterschiede in der Oberfläche schwerer wiegen als ein wesentliches Versagen im Betrieb.

Vorhandene Lizenzen. Vorhandene Lizenzen können zusätzliche Ausgaben verringern, machen die Einführung aber nicht kostenlos. Quellenbereinigung, Zugriffsprüfung, Schulung und laufende Pflege entstehen unabhängig vom Modell. Nutzungsabhängige Funktionen brauchen eine realistische Mengenschätzung, die anhand der tatsächlichen Aufrufe überprüft wird.

Eigene Anwendung. Eine eigene Anwendung benötigt zusätzlich Entwicklung, Hosting, Suchinfrastruktur, Modellnutzung und Wartung. Berücksichtigen Sie auch Vertretung: Wenn nur eine Person die Pipeline versteht, kann ein scheinbar günstiger Aufbau ein Betriebsrisiko darstellen.

Gleicher Maßstab. Vergleichen Sie einen festgelegten Zeitraum mit ähnlichem Nutzungsumfang und gleicher Qualitätsanforderung. Trennen Sie einmalige Einführungskosten von wiederkehrendem Betrieb. Erfassen Sie menschliche Nacharbeit, statt eine schnell erzeugte, aber ungeprüfte Antwort als abgeschlossene Aufgabe zu zählen.

Höhere Nutzung und Neuverarbeitung. Prüfen Sie, was bei höherer Nutzung und bei einer Neuverarbeitung geschieht. Eine Änderung an der Dokumentenextraktion kann eine umfangreiche Neuindexierung erfordern, auch wenn die Zahl der Fragen der Mitarbeitenden gleich bleibt. Das wirkt sich auf eigene und verwaltete Dienste unterschiedlich aus und gehört in die Betriebsschätzung.

Gemeinsamer Fragenbestand. Stellen Sie einen gemeinsamen Fragenbestand zusammen und lassen Sie die Sollantworten fachlich freigeben, bevor die Produkte antworten. Teilen Sie den Bestand nach Aufgaben auf: einfache Fundstelle, Erklärung mit Ausnahme, Frage über mehrere Quellen und aktuelle Systeminformation. So kann ein gutes Ergebnis bei einfachen Fragen keine Schwäche im entscheidenden Arbeitsablauf verdecken.

Gleiche Testidentitäten. Führen Sie die Varianten mit denselben normalen Testidentitäten aus. Halten Sie fest, welche zusätzlichen Konfigurationen notwendig waren und wer sie erstellt hat. Ein scheinbar sofort nutzbares Produkt kann erheblichen Vorbereitungsaufwand benötigen; eine eigene Anwendung kann von bereits vorhandener Infrastruktur profitieren. Beide Effekte gehören transparent in den Vergleich.

Zwei Prüfperspektiven. Bewerten Sie Ergebnisse möglichst ohne sichtbaren Produktnamen. Eine fachkundige Person prüft Inhalt und Belege; eine typische Nutzerin erledigt die zugehörige Aufgabe. Die erste Perspektive erkennt Fehler, die zweite zeigt, ob die Antwort verständlich und praktisch verwendbar ist. Notieren Sie Abweichungen zwischen beiden Bewertungen.

Wiederholung nach Änderungen. Wiederholen Sie die kritischen Fälle nach einer Quellenkorrektur und einem Rechteentzug. Damit prüfen Sie nicht nur einen vorbereiteten Idealzustand. Ein Ablauf, der ausschließlich bei unveränderten Dokumenten funktioniert, genügt für laufenden Betrieb selten.

Differenziertes Ergebnis. Das Ergebnis darf differenziert ausfallen: Eine Variante kann für allgemeine Anleitungen freigegeben werden, während aktuelle Kundeninformationen einen anderen Weg benötigen. Halten Sie diese Grenze in der Produktbeschreibung und in der Schulung fest. Mitarbeitende sollten wissen, welche Fragen der jeweilige Assistent verlässlich bearbeiten soll und wann ein anderes System maßgeblich bleibt.

Dokumentieren Sie Quellen, Testfragen und fachliche Regeln möglichst außerhalb eines einzelnen Chatverlaufs oder eines proprietären Prompt-Editors. Diese Informationen sollten beim Produktwechsel weiterhin nutzbar bleiben. Prüfen Sie, welche Konfigurationen exportiert werden können und welche Funktionen neu aufgebaut werden müssten.

Legen Sie außerdem fest, wann neu bewertet wird: neue vertrauliche Quellen, zusätzliche Werkzeuge, andere Nutzergruppen oder wesentlich veränderte Produktfunktionen. Eine heute passende, rein lesende Lösung kann zusätzliche Kontrollen benötigen, wenn sie Datensätze anlegen oder Nachrichten versenden soll.

Der nächste sinnvolle Schritt ist deshalb ein kleiner, fairer Vergleich anhand der eigenen Aufgaben. Beginnen Sie mit vorhandenen Möglichkeiten und bauen Sie nur die nachgewiesenen Lücken aus. Der Abnahmeplan liefert dafür die Prüffälle; die Kostenanleitung hilft bei der vollständigen Kalkulation.

Dokumentieren Sie die Entscheidung anhand von Nachweisen: welche Aufgaben erfolgreich bearbeitet wurden, welche nicht, welche Einschränkungen akzeptiert wurden und wer für sie verantwortlich ist. Diese Aufzeichnung ist nützlicher, als eine Architektur für grundsätzlich überlegen zu erklären. Sie erleichtert es auch, eine spätere Erweiterung zu beurteilen, ohne die gesamte Auswahl zu wiederholen.

Diese Leitfäden von modernagents behandeln angrenzende Entscheidungen rund um KI-Wissensassistenten:

• KI-Wissensassistent: internes Wissen auffindbar machen
• KI-Wissensdatenbank aufbauen: Quellen zuerst ordnen
• RAG mit SharePoint: Berechtigungen bis zur Antwort erhalten
• RAG-Kosten: Aufbau, Suche, Modelle und laufende Pflege

Für eine konkrete Ablaufprüfung reichen zunächst eine Prozessbeschreibung, die beteiligten Systeme und typische Ausnahmen. Mit modernagents besprechen.