Dein SharePoint als KI-Gehirn: Knowledge-Bot mit Foundry IQ in 4 Schritten
Dein Unternehmenswissen liegt in SharePoint: Richtlinien, Projektdokus, Handbücher, Prozessbeschreibungen. Alles da. Aber wirklich nutzbar für Mitarbeiter? Nur wenn jemand weiß, wo er suchen muss.
Foundry IQ ändert das. Es ist der managed Knowledge Layer in Microsoft Foundry (Azure AI Foundry), der aus SharePoint-Inhalten eine permission-aware Wissensbasis für KI-Agenten macht — ohne dass du selbst eine RAG-Pipeline bauen musst.
Dieser Artikel zeigt dir, was Foundry IQ ist, welche Voraussetzungen du brauchst und wie du in 4 konkreten Schritten einen Knowledge-Bot aufbaust, der nur das antwortet, was Nutzer auch sehen dürfen.
Was ist Foundry IQ?
Foundry IQ (offizielle Docs: learn.microsoft.com/azure/foundry/agents/concepts/what-is-foundry-iq) ist der Wissensbaustein innerhalb von Microsoft Foundry. Du erstellst eine Knowledge Base, verbindest sie mit einer Datenquelle — SharePoint, OneLake, Azure Blob, Azure AI Search — und jeder Foundry Agent kann diese Wissensbasis abfragen.
Was das von einer selbst gebauten RAG-Pipeline unterscheidet:
| Selbstgebaute RAG-Pipeline | Foundry IQ |
|---|---|
| Eigene Indexierung (Chunking, Embedding-Logik) | Komplett verwaltet |
| Kein Permission-Check | Permission-aware (SP-Berechtigungen werden respektiert) |
| Manuelles Refresh-Management | Incremental refresh automatisch |
| Keine standardisierten Zitierungen | Quellenangaben out-of-the-box |
| Setup: Stunden bis Tage | Setup: Minuten |
Kurz: Foundry IQ ist RAG-as-a-Service — du zeigst auf deine Daten, bekommst eine Wissensbasis, sparst dir das Klempnerwerk.
Wann macht ein SharePoint Knowledge-Bot Sinn?
Nicht jede Organisation braucht das sofort. Foundry IQ ist dann der richtige Ansatz, wenn:
- Doku-Volumen groß ist — Mitarbeiter suchen aktiv in SharePoint, finden aber schlecht
- Wissen fragmentiert liegt — Mehrere Sites, Libraries, Teams
- Permission-Logik wichtig ist — HR-Dokumente sollen nicht für alle sichtbar sein
- Keine Entwickler-Ressourcen für Custom RAG vorhanden
Typische Use Cases: HR-FAQ-Bot, IT-Helpdesk erste Ebene, Compliance-Auskunft, Projektwissen-Abfragen.
Voraussetzungen (Checklist)
Bevor du startest, prüf diese Punkte:
- Azure-Subscription mit Zugriff auf Microsoft Foundry (ai.azure.com)
- Foundry-Projekt mit einem AI Services Connection angelegt
- Azure AI Search Service (mind. Basic-Tier — Free-Tier reicht nicht)
- SharePoint Online Site mit Inhalten (Dateien, Pages, Listen)
- Benutzer mit
Azure AI User-Rolle auf dem Foundry-Parent-Resource - Für MCP-Verbindung:
Azure AI Project Manager-Rolle
Kostenschätzung (grob): Azure AI Search Basic ~€75/Monat, Foundry Agent Service nach Token-Verbrauch. Für ein KMU-Pilotprojekt mit moderater Last: ~€100–150/Monat gesamt.
4 Schritte zum SharePoint Knowledge-Bot
Schritt 1: Foundry IQ Knowledge Base erstellen
Im Foundry-Portal (ai.azure.com):
- Linke Navigation → Foundry IQ
- + New Knowledge Base → Name vergeben
- Data Source hinzufügen → Typ: SharePoint
- SharePoint-Site-URL eingeben und Zugriff autorisieren (OAuth, Managed Identity)
- Index-Konfiguration: Welche Document Libraries / Ordner / Dateitypen indexieren?
- Indexierung starten — je nach Datenvolumen: 5 Minuten bis 2 Stunden
💡 Tipp: Starte mit einer einzelnen Document Library (z.B. Richtlinien). Lieber klein und scharf als groß und ungenau.
Schritt 2: Knowledge Base mit Agent verbinden
Im Foundry-Portal:
- Foundry Agent Service → neuen Agent erstellen (oder bestehenden öffnen)
- Knowledge → + Add Knowledge Source → deine Foundry IQ Knowledge Base auswählen
- Verbindungstyp: MCP (nutzt Managed Identity des Projekts — kein Passwort nötig)
- Agent-Instructions ergänzen:
Du bist ein interner Wissensassistent für [Firmenname].
Beantworte ausschließlich auf Basis der bereitgestellten Wissensbasis.
Wenn du eine Antwort nicht findest: Sage klar "Diese Information ist in meiner Wissensbasis nicht verfügbar."
Gib immer die Quelle (Dokumentname + Abschnitt) an.- Test im Playground — ein paar Testfragen stellen
Schritt 3: Permission-Check validieren
Das ist der kritische Schritt, der in Self-Build-RAG oft fehlt:
Foundry IQ respektiert SharePoint-Berechtigungen — aber nur wenn der aufrufende Nutzer authentifiziert ist. Für einen internen Unternehmens-Bot bedeutet das:
- Option A (Einfach): Bot antwortet als Service Principal mit Lesezugriff auf alle Inhalte — kein User-Context. Geeignet wenn alle Nutzer gleiche Rechte haben.
- Option B (Permission-aware): On-behalf-of (OBO) Flow — Bot agiert im Kontext des eingeloggten Nutzers. Nur Inhalte die der Nutzer in SP sehen darf werden zurückgegeben.
Für HR/Compliance-Szenarien immer Option B. Für allgemeine Wissens-FAQs reicht Option A.
Test: Zwei Testnutzer mit unterschiedlichen SP-Berechtigungen → gleiche Frage → unterschiedliche Antworten prüfen.
Schritt 4: Kanal anbinden (Teams / SharePoint Page / Web)
Ein Foundry Agent ohne Interface ist kein Bot. Typische Kanäle für KMU:
Microsoft Teams (empfohlen):
- Foundry Agent → Deploy → Teams
- Direkte 1:1-Unterhaltung oder in Teams-Kanal einbetten
- Lizenz: kein Copilot-Abo nötig, nur Azure-Abrechnung
SharePoint Embedded (neueste Option):
- Foundry Agent als WebPart in einer SharePoint-Seite einbetten
- Nutzer interagieren direkt im SP-Intranet-Kontext
Web-App / eigene Integration:
- REST-API des Foundry Agent Service
- Für individuelle Oberflächen oder bestehende Tools
Praxis-Einschätzung: Was funktioniert gut, was nicht?
Nach ersten Projekterfahrungen mit Foundry IQ in Kundenprojekten:
Was gut funktioniert:
- ✅ Setup ist tatsächlich in unter 30 Minuten machbar (kleines Datenvolumen)
- ✅ Quellenangaben im Antworttext erhöhen die Akzeptanz beim Nutzer stark
- ✅ Incremental refresh hält die Wissensbasis aktuell ohne manuellen Aufwand
- ✅ Multi-Source möglich: SP + Azure Blob + OneLake in einer Knowledge Base
Wo du aufpassen musst:
- ⚠️ Dokumentqualität entscheidend — schlecht strukturierte PDFs/Scans liefern schlechte Antworten. Bereinige die Quellen vorher.
- ⚠️ Chunking-Grenzen — sehr lange Dokumente (100+ Seiten) werden zerschnitten; wichtige Zusammenfassungen an den Anfang stellen
- ⚠️ Azure AI Search Tier — Basic reicht für den Start, bei >50.000 Dokumenten auf Standard S1 upgraden
- ⚠️ OBO-Flow komplex — Permission-aware Setup braucht App Registration, OBO-Grant, Token-Handling; plan 1 Tag Zusatzaufwand ein
Foundry IQ vs. Copilot Pages / SharePoint Agents
Kurz zur Abgrenzung, weil die Frage in Projekten immer kommt:
SharePoint Knowledge Agent (eingebaut in SP Online): Einfacher Q&A über Site-Inhalte, kein Custom-Agent möglich, kein Multi-Source, kein Kanal-Deploy. Gut für: schneller Einstieg ohne Azure.
Copilot Pages / Copilot Studio: Erfordert M365 Copilot Lizenz (~€30/User/Monat). Gut für: Nutzer die bereits Copilot haben, wenig technische Komplexität.
Foundry IQ + Foundry Agent: Kein Copilot-Abo nötig, volle Kontrolle, multi-source, beliebiger Kanal. Gut für: IT-Pros, individuelles Enterprise-Setup, Kostenkontrolle.
Faustformel: Hast du weniger als 20 Nutzer und wenig IT-Expertise → Copilot Studio. Hast du mehr Nutzer, Azure-Kenntnisse oder willst Permission-Logik selbst steuern → Foundry IQ.
Fazit
Foundry IQ macht das was viele Unternehmen wollten aber nie bauen konnten: Ein KI-Agent der die eigene Dokumentation kennt, nur antwortet was er darf und den Nutzer bei Bedarf zur Originalquelle führt.
Der Aufwand für einen ersten Piloten ist überschaubar — 1 halber Tag Setup, 1 Tag für Permission-Feinschliff, dann iterieren. Das ist deutlich weniger als eine selbst gebaute RAG-Lösung.
Nächster Schritt für dich: Im M365-Audit prüfen wir gemeinsam, ob Foundry IQ in deinem Tenant sinnvoll ist — welche SharePoint-Sites als Wissensquellen taugen, welchen Tier du brauchst und welcher Bot-Kanal zu eurer Infrastruktur passt.
Dieser Artikel ist Teil der Serie “Azure AI Foundry für M365-Profis” — erscheint KW23/2026.