AI Agents on DR.365

Microsofts AI Strategy Roadmap aus Betreibersicht: was trägt und was regulierte Organisationen ergänzen müssen

Tue, 20 Oct 2026 07:00:00 +0200

Im Juli 2026 hat Microsoft ein 66-seitiges E-Book veröffentlicht: The AI Strategy Roadmap, Untertitel How organizations are achieving Frontier Transformation. Als Service Owner für Digital Workplace & AI bei einem IT-Dienstleister, dessen Kunden überwiegend aus regulierten Branchen kommen (KRITIS, NIS2), habe ich es mit einer Frage gelesen: Was trägt im Betrieb, was ist Marketing, und was fehlt?

„Frontier Transformation“ nennt Microsoft den Schritt von einzelnen KI-Use-Cases zu KI, die in den Kernprozessen eines Unternehmens steckt.

Worauf das E-Book beruht

Grundlage sind 70 Interviews von 30 bis 45 Minuten mit Entscheidern aus IT und Fachbereichen, geführt von der Emerald Research Group im Auftrag von Microsoft zwischen dem 23. Februar und dem 13. März 2026. Zweite Quelle ist Microsofts eigener interner Rollout als „Customer Zero“.

Die Tabelle am Anfang nennt sieben typische Hürden: zu viele Ideen ohne klaren Startpunkt, ein ROI, der abstrakt bleibt, fragmentierte Daten, Compliance-Reviews, die die Ausweitung bremsen, Skalierung ohne klare Verantwortung, Nutzer, die dem Agent nicht trauen, und fehlende Skills. Die Antworten der „Frontier Firms“ laufen meist auf dasselbe hinaus: eng anfangen, früh messen, einen Use Case nach dem anderen ausweiten.

Danach definiert das E-Book fünf übergreifende Reifestufen (Exploring, Planning, Implementing, Scaling, Realizing, in der Grafik sinngemäß Erkunden, Planen, Umsetzen, Skalieren, Verankern) und gibt jedem der fünf Werttreiber ein eigenes fünfstufiges Reifegradmodell.

Fünf Treiber über fünf Stufen: meine verdichtete Lesart der Reifegradmodelle aus dem E-Book, in eigenen Worten.

Die fünf Treiber als Selbstcheck

Jeder Treiber kurz zusammengefasst, mit einer Frage für deine eigene Organisation. Die Fragen zielen auf Stufe 3, wo zwischen Pilot und Produktion die meiste Arbeit liegt.

1. Business-Strategie. KI-Vorhaben hängen an Geschäftszielen, werden bewusst finanziert und als Portfolio gesteuert. Das E-Book will zuerst einen engen, messbaren Use Case, priorisiert nach einem einheitlichen Raster. Genannt wird das Microsoft AI Decision Framework, auch BXT-Framework (Business, Experience, Technology). Check für Stufe 3: Tauchen KI-KPIs in deiner regulären Geschäftsplanung auf oder nur im Projektstatus?

2. Technologie und Daten. Datenqualität ist Voraussetzung, und eine gemeinsame, verwaltete Plattform ersetzt den Neubau für jeden Piloten. Kostenmanagement gehört von Anfang an ins Design. Check für Stufe 3: Kannst du die Datenquellen benennen, die ein produktiver Agent nutzen darf, und wem jede davon gehört?

3. KI-Strategie und Erfahrung. Piloten sind vom ersten Tag an instrumentiert, und was funktioniert, wird zur Vorlage für das nächste Team. GenAIOps-Praktiken wie versionierte Prompts und laufende Tests machen aus Experimenten Betrieb. Check für Stufe 3: Wenn sich Prompt oder Modell eines produktiven Agents ändern, gibt es vor dem Go-live einen Testlauf?

4. Organisation und Kultur. Ein Frontier Center of Excellence (CoE) setzt Standards und Leitplanken, ohne jede Lösung selbst zu besitzen, unterstützt von Champions und rollenbasierten Schulungen (das E-Book verweist auf AI Skills Navigator, der inzwischen als Preview im Learning Agent in Copilot steckt). Laut Microsofts Work Trend Index 2026, den das E-Book zitiert, gehen 67 % des realisierten KI-Werts auf organisatorische Faktoren zurück. Check für Stufe 3: Hat dein CoE ein Mandat, ein Budget und eine benannte Leitung, oder ist es ein Jour fixe?

5. Governance und Security. Governance steckt im Lifecycle der Agents: Identitäten, Least Privilege, Monitoring, ein Inventar aller KI-Systeme und eine Prüfung vor jedem Deployment. Check für Stufe 3: Kannst du heute jeden produktiven Agent mit Owner und Berechtigungen auflisten, ohne herumzufragen?

Auf Microsoft Learn gibt es ein verwandtes Reifegradmodell für die Einführung von Agentic AI mit fast denselben fünf Säulen und den Stufen 100 bis 500. Für einen Assessment-Workshop würde ich das nehmen: Jede Säule hat eine eigene, ausführliche Seite.

Was im Betrieb trägt

Datenhygiene ist der kritische Pfad. Microsofts eigene Lehre als Customer Zero: Sind Daten schlecht klassifiziert, dupliziert oder zu breit geteilt, verstärken Agents das Problem. Den Satz würde ich jedem Lenkungskreis zeigen: „For agents, data quality becomes action quality.“ Bei Copilot sehen wir dasselbe: Oversharing, das es seit Jahren gibt, wird an dem Tag sichtbar, an dem ein Agent darin suchen kann. Die konkreten Schritte stehen in meinem Leitfaden zu Oversharing vor dem Rollout.

Der sichere Weg muss der einfache sein. Macht die IT die freigegebenen Wege langsam, weichen Leute auf öffentliche Tools aus und nehmen Firmendaten mit. Das E-Book empfiehlt, Leitplanken direkt in die Werkzeuge einzubauen, mit denen Experimentieren leicht ist, und die IT vom Besitzer jeder Lösung zum Verwalter von Plattform und Daten zu machen. Nach meiner Erfahrung ist das auf Dauer das Einzige, was gegen Schatten-KI hilft. Verbote altern schnell.

Agents brauchen Identitäten und ein Lifecycle-Register. Das E-Book will pro Agent Berechtigungen, Lifecycle-Kontrollen und Monitoring, dazu ein Register, das jeden Agent von der Freigabe bis zur Stilllegung verfolgt. In Microsoft 365 entspricht das Microsoft Entra Agent ID und der Agent-Registry in Agent 365. Über die Lifecycle-Seite und über delegierte Berechtigungen zur Laufzeit habe ich schon geschrieben.

Jeder Agent sollte vor dem Deployment eine Sicherheitsprüfung bekommen. Security-Teams testen vor der Produktion, und laufendes Monitoring sucht danach nach Prompt Injection und unsicheren Tool-Aufrufen. Das ist die Phase Measure aus Microsofts Vier-Phasen-Modell für verantwortungsvolle generative KI, und sie gehört ins Release-Gate.

Wiederverwendung funktioniert am besten, wenn die Leitplanken mitkommen. Vorlagen und Pattern-Bibliotheken sollten die Vorgaben zu Governance, Datenumgang und Evaluierung enthalten, damit ein neues Team die Kontrollen erbt. Microsoft beschreibt, wie eigene Agents vom persönlichen zum unternehmensweiten Einsatz „graduieren“, mit Validierung, Security-Review und gehärteter Integration, bevor sie skalieren. Ob du mit Agent Builder, Copilot Studio oder Foundry baust, entscheidet, wie viel davon du zentral durchsetzen kannst.

Die IT wird Kurator statt Türsteher. Bei Microsoft stellt die IT zertifizierte Datenquellen bereit und betreibt Agent-Memory und Integrationen (APIs, MCP, Konnektoren). Das CoE startete 2023 als Beratungsgruppe und wechselte dann zur Koordination. Ideen prüft es entlang von vier Säulen: Strategy, Architecture, Roadmap und Culture. Ein „Fast Train“ gibt einer vertrauenswürdigen Gruppe früh breiten Zugang unter klaren Leitplanken. Das Modell würde ich übernehmen und die Gruppe klein halten.

Wo es zu glatt ist

Die ROI-Botschaft widerspricht sich. In der Hürden-Tabelle heißt es, es sei schwer, Führungskräfte davon zu überzeugen, dass ein harter ROI-Nachweis nicht das Ziel ist. Ein paar Seiten später sollst du Use Cases wählen, die früh ROI zeigen. In einem reifen Programm kann beides stimmen. Ein Lenkungskreis, der beides hört, sucht sich die Variante aus, die ihm passt.

Enabler oder Ersatz? Laut Change-Management-Kapitel soll klar sein, dass Agents Enabler sind und keine Bedrohung für Arbeitsplätze. Der Zielzustand von Treiber 1 sagt dagegen, Wachstum sei nicht mehr durch Headcount begrenzt, und die Liste der Vorteile verspricht Skalierung ohne proportional mehr Personal. Belegschaft und Betriebsrat lesen beide Sätze. Wenn du das E-Book intern nutzt, entscheide, welche Botschaft du meinst, und bleib dabei.

Die Evidenz ist dünn. Siebzig vom Hersteller beauftragte Interviews plus dessen eigener Rollout beschreiben Muster, belegen aber keine Wirkung. Die 67 % stammen aus Microsofts eigenem Work Trend Index. Zur Orientierung taugt das, als Business Case kaum.

Das Kostenmanagement bleibt vage. Das E-Book will Kosteneffizienz früh im Design und nennt fehlende Kostenmodelle als Lücke beim Skalieren, ohne zu sagen, wie: kein Verrechnungsmodell, keine Stückkosten pro Agent, nichts zur verbrauchsabhängigen Abrechnung. Für einen Dienstleister bleiben Piloten genau hier stecken.

Was für Europa fehlt

Die Regulierungskarte in Treiber 5 zeigt den EU AI Act, das NIST AI RMF, ISO 42001, ISO 23894 und Regelwerke aus mehreren anderen Ländern. Die DSGVO wird einmal erwähnt, neben HIPAA. Drei Dinge, die jedes KI-Projekt in einer regulierten deutschen Organisation prägen, fehlen. Das Folgende ist meine fachliche Einschätzung, keine Rechtsberatung.

Mitbestimmung. Nach § 87 Abs. 1 Nr. 6 BetrVG bestimmt der Betriebsrat mit bei technischen Einrichtungen, die dazu bestimmt sind, Verhalten oder Leistung der Beschäftigten zu überwachen, und die Rechtsprechung legt „bestimmt“ weit aus: Es reicht, dass sie dazu objektiv geeignet sind. Copilot und Agents, die Nutzung protokollieren, erfüllen das in aller Regel. Seit 2021 nennt § 90 BetrVG den Einsatz von KI ausdrücklich bei den geplanten Arbeitsabläufen, über die der Betriebsrat zu unterrichten ist. Das gehört in Treiber 4: den Betriebsrat schon bei der Planung des ersten Use Case einbinden und eine Betriebsvereinbarung als Teil der Roadmap behandeln.
NIS2. Für betroffene Einrichtungen ist ein Agent ein IT-System wie jedes andere. Risikomanagement, Meldepflichten und die Verantwortung der Geschäftsleitung gelten. In Treiber 5 heißt das: Agent-Inventar und Incident-Prozess müssen Agents abdecken.
DORA. Finanzunternehmen unterliegen seit dem 17. Januar 2025 DORA, einschließlich IKT-Risikomanagement und eines Informationsregisters zu den vertraglichen Vereinbarungen mit IKT-Drittdienstleistern. Jede KI-Plattform und jedes externe Modell ist ein Kandidat für dieses Register. Das betrifft Treiber 2 (Plattformwahl) und Treiber 5 (Nachweise).

Wie sich die Kontrollen aus AI Act, DSGVO, NIS2 und ISO bei Agents überschneiden, beschreibt meine Compliance-Landkarte für Microsoft-365-Agents.

Was ich daraus mitnehmen würde

Für eine Organisation auf der Stufe Planning oder Implementing:

Mit einem messbaren Use Case und einem Menschen in der Schleife starten. Den KPI vor dem Bau festlegen und den Freigabeschritt im Ablauf lassen, bis die Zahlen rechtfertigen, ihn wegzunehmen.
Das Agent-Inventar vor dem zweiten Agent anlegen: Owner, Zweck, Datenquellen, Berechtigungen, nächster Review-Termin. Bei Agent Nummer 30 nachzurüsten ist ein eigenes Projekt.
Das CoE zum „Center of Acceleration“ machen, ein Begriff, den das E-Book selbst verwendet. Messen würde ich es daran, wie schnell ein Team eine sichere Vorlage und eine Entscheidung bekommt, nicht daran, wie viele Anträge es ablehnt.
Datenschutz, Betriebsrat und Informationssicherheit an den Tisch holen, wenn der erste Use Case ausgewählt wird. Beim Go-live können sie nur noch Nein sagen.

Wo bleiben Organisationen im KRITIS- und NIS2-Umfeld typischerweise hängen? Ich würde die meisten zwischen Planning und Implementing verorten: Der erste Use Case ist definiert, aber noch nicht produktiv. Gebremst wird meist von Treiber 4 und 5 gemeinsam. Niemand entscheidet verbindlich, worauf ein Agent zugreifen darf, und Betriebsrat und Informationssicherheit kommen spät dazu, sodass jede Freigabe wieder bei null beginnt. Deshalb stehen die Schritte 2 und 4 vor dem zweiten Agent.

Fazit

Die fünf Treiber liefern ein gemeinsames Vokabular für einen Reifegrad-Check; das Modell auf Microsoft Learn liefert die Details.
Am stärksten ist der operative Teil: Datenhygiene, Agent-Inventar, Prüfung vor dem Deployment und Leitplanken, die in Vorlagen stecken.
Die Aussagen zu ROI und Headcount kritisch lesen, die Evidenz als Herstellerstudie.
In Europa Mitbestimmung, NIS2 und DORA selbst in die Treiber 4 und 5 eintragen.

Quellen

Microsoft: The AI Strategy Roadmap: How organizations are achieving Frontier Transformation (E-Book, PDF, Juli 2026, Englisch)
Microsoft Learn: Agentic AI adoption maturity model
Microsoft Learn: Build an agentic Center of Excellence
Microsoft Learn: Evaluate and prioritize an AI use case with business envisioning (BXT)
Microsoft Learn: Agent registry im Microsoft 365 Admin Center
Microsoft Learn: What are agent identities? (Microsoft Entra Agent ID)
Microsoft Learn: Manage AI Skills Navigator
Betriebsverfassungsgesetz: § 87, § 90 (gesetze-im-internet.de)
EUR-Lex: NIS2-Richtlinie (EU) 2022/2555, DORA-Verordnung (EU) 2022/2554

Auf Menschentempo ausgelegt: Was Anthropics neue Versionskontrolle für die IT-Strategie bedeutet

Wed, 14 Oct 2026 07:00:00 +0200

Im Mai 2026 hat Anthropic rund 2.500 Code-Änderungen pro Tag in sein Monorepo gemergt. Im September waren es über 30.000. Git und die Mirror-Infrastruktur drumherum kamen nicht mehr hinterher, also hat ein Team aus sieben Leuten ein eigenes Versionskontrollsystem gebaut und das komplette Monorepo in fünf Monaten migriert (Anthropic Engineering).

Kaum jemand, der das hier liest, wird ein Versionskontrollsystem bauen. Darum geht es bei der Geschichte auch nicht. Jede Organisation hat Prozesse, die auf das Tempo von Menschen ausgelegt sind: Change Advisory Boards, Vier-Augen-Freigaben, Access Reviews, CI-Pipelines, Budgets in Personentagen. Sobald Agents einen großen Teil der Arbeit erledigen, werden genau diese Prozesse zum Engpass. Die Frage ist, welche davon du umbaust, bevor sie brechen.

Kurz gesagt

Agents werden zu den Hauptnutzern deiner Systeme. Architekturentscheidungen sollten von Maschinen-Clients ausgehen, die immer online sind und APIs in hoher Frequenz aufrufen.
Review und Freigabe müssen weg von „ein Mensch hat alles angesehen“ hin zu Regeln, die festlegen, wo ein Mensch hinsehen muss.
Jeder Agent braucht eine Identität, eine verantwortliche Person und eine Kostenstelle. Ohne diese drei kannst du Agentenarbeit weder steuern noch budgetieren.

Was Anthropic tatsächlich geändert hat

In den Schlagzeilen heißt es „Anthropic hat Git rausgeworfen“. Der Engineering-Beitrag selbst ist vorsichtiger. Das neue System heißt Scion, das Review-Werkzeug Antique. Anthropic schreibt ausdrücklich, dass Scion kein allgemeiner Ersatz für Git ist, weil dafür die gesamte Entwicklungs-Toolchain ersetzt werden müsste. Veröffentlicht wurde das Design, damit Git-Plattformen Teile davon übernehmen können.

Warum sie es trotzdem gemacht haben, zeigen die Zahlen. Die Historie des Main-Branch umfasst fast 100 GB, eine komprimierte Arbeitskopie über 25 GB, und die CI zieht rund 25 Millionen Checkouts pro Tag. Git ist für verteilte Clients gebaut, die offline arbeiten. Die Clients bei Anthropic sind fast ausschließlich Agents und Jobs, die immer online sind. Scion verlagert die teure Arbeit auf den Server: Commits, Merges, Rebases, Historie und Blame laufen dort, Clients bekommen schlanke, virtualisierte Checkouts, die Dateien bei Bedarf nachladen, und vieles ist per API ganz ohne lokales Repository nutzbar. Laut Beitrag braucht die neue Infrastruktur etwa 200-mal weniger CPU und Speicher als die alten Git-Mirrors, CI-Checkouts dauern Sekunden statt Minuten.

Drei Entscheidungen aus dem Beitrag sind über Versionskontrolle hinaus relevant:

Es gibt keine Merge Queue mit globalem Lock. Anthropic hat stattdessen in Tests nach dem Merge und vor dem Deployment investiert. Konflikte zwischen parallelen Änderungen kommen vor, und Claude behebt sie meist schneller, als ein Mensch sie bemerken würde.
Antique kann semantische Regeln für Freigaben abbilden. Eine Änderung nur an Kommentaren wird anders behandelt als eine Änderung an sensibler Logik, damit menschliche Reviewer ihre Zeit dort verbringen, wo es zählt.
Zugriffssteuerung auf Repository- und Verzeichnisebene war von Anfang an eingebaut, nicht nachträglich ergänzt.

Agents sind die neuen Hauptnutzer

Die erste Lehre betrifft die Architektur. Die meisten Unternehmenssysteme gehen von einem Menschen vor einem Bildschirm aus. Agents verhalten sich anders: Sie pollen, sie laufen parallel, und Mittagspause machen sie auch keine.

In Microsoft 365 sieht man das heute schon am Throttling von Microsoft Graph. Microsoft nennt zwei typische Ursachen: viele Anfragen über alle Anwendungen eines Tenants hinweg und viele Anfragen einer Anwendung über alle Tenants hinweg. Regelmäßiges Abfragen einer Ressource und wiederholtes Durchsuchen von Collections werden ausdrücklich als Muster genannt, die zu Throttling führen. Empfohlen werden stattdessen Delta Queries und Change Notifications, für große Datenmengen verweist Microsoft auf Graph Data Connect statt der REST-APIs (Microsoft Learn). SharePoint Online geht noch einen Schritt weiter: Eine Anwendung, die Limits dauerhaft überschreitet, kann komplett blockiert werden (Microsoft Learn).

Diese Hinweise wurden für Integrationsentwickler geschrieben. Inzwischen gelten sie für jeden Agent, der im Auftrag von jemandem Postfächer, Sites oder Teams-Kanäle liest. Wenn ich ein Agent-Szenario bewerte, frage ich deshalb zuerst, wie es Änderungen erkennt, und erst danach, was es tut. Ein Agent, der alle zehn Minuten eine Dokumentbibliothek komplett durchsucht, läuft im Pilot einwandfrei und wird zum Problem, wenn 40 Abteilungen ihn kopieren.

Für eigene Systeme gilt dasselbe in umgekehrter Richtung. Wenn Agents die Hauptnutzer einer internen Plattform werden, braucht sie eine ordentliche API, Change Feeds und Limits pro Client. Eine Weboberfläche mit einem Scraping-Agent davor ist der Git-Mirror deiner Organisation: Sie funktioniert, bis das Volumen sich verzehnfacht.

Review nach Absicht statt Zeile für Zeile

Die zweite Lehre betrifft Kontrollprozesse. Das Team bei Anthropic prüft weiterhin jede Änderung, aber es prüft die Absicht und nicht jede Zeile. Ihre wichtigste Aufgabe ist nach eigener Beschreibung, Claude „Nein“ zu sagen: wenn Systemgrenzen verletzt werden oder Claude wegen hypothetischer Bedenken überkonstruiert.

In regulierten Umgebungen ist das der unbequeme Teil. Viele Change-Prozesse versprechen implizit, dass eine qualifizierte Person alles geprüft hat. Bei 30.000 Änderungen am Tag lässt sich dieses Versprechen nicht halten, und ehrlich gesagt wurde es oft schon bei 30 pro Woche nicht gehalten. Das CAB, das in 45 Minuten einen Stapel Changes durchwinkt, prüft vor allem, ob das Formular vollständig ist.

Nach meiner Erfahrung wollen Auditoren Belege dafür sehen, dass Änderungen kontrolliert und nachvollziehbar sind. NIS2 verlangt Risikomanagementmaßnahmen, zu denen auch Sicherheit bei Entwicklung und Wartung gehört; dass ein Mensch jede Zeile liest, schreibt die Richtlinie nicht vor. Damit bleibt Raum für ein Modell, das ITIL als Standard Changes kennt, angewendet auf die Arbeit von Agents:

Geringes Risiko (Dokumentation, Tests, Formatierung, Konfiguration innerhalb definierter Leitplanken): automatische Prüfungen, kein verpflichtendes menschliches Review, vollständige Protokollierung.
Mittleres Risiko (Geschäftslogik, Integrationen): menschliches Review von Absicht und Testnachweisen, mit der Zusammenfassung des Agents als Grundlage.
Hohes Risiko (Authentifizierung, Berechtigungen, Datenflüsse über Vertrauensgrenzen, alles Regulierte): Review Zeile für Zeile durch eine benannte Person, wie bisher.

Was über die Stufe entscheidet, muss eine Regel sein und kein Bauchgefühl. Anthropic bildet das im Review-Werkzeug ab, du kannst es in Branch Protection Rules, CODEOWNERS-Dateien oder einem Genehmigungsflow in Power Automate abbilden. Die Regel selbst ist die Kontrolle, die ein Auditor sehen will.

Bei einem Teil des Anthropic-Ansatzes wäre ich vorsichtig: Prüfungen hinter den Merge zu verlegen. Für eine interne Entwicklerplattform ist das ein vertretbarer Tausch. Für ein System in einer KRITIS-Umgebung, bei dem eine fehlerhafte Änderung direkt in Produktion landen kann, würde ich das nicht machen. Die Absicherung muss vor dem Deployment sitzen, auch wenn sie nicht mehr vor dem Merge sitzt.

Jeder Agent braucht eine Identität und einen Verantwortlichen

Anthropic hat die Zugriffssteuerung in Scion vom ersten Tag an eingebaut, bis auf Verzeichnisebene. In Microsoft 365 entspricht dem die Identitätsschicht für Agents. Microsoft Entra Agent ID gibt Agents eigene Identitäten im Verzeichnis, erzeugt aus Agent Identity Blueprints. Jede Agent-Identität braucht einen menschlichen Sponsor, der für Zweck, Lebenszyklus und Access Reviews verantwortlich ist. Verlässt der Sponsor das Unternehmen, geht die Verantwortung auf seine Führungskraft über. Conditional Access und Access Packages aus dem Entitlement Management gelten auch für Agents (Microsoft Learn). Stand Oktober 2026 ist Identity Governance für Agents als Preview gekennzeichnet, und die Lizenzierung hängt an Microsoft 365 E7 oder Agent 365. Prüf die aktuellen Bedingungen, bevor du damit planst.

Darüber liegt in Microsoft Agent 365 die Registry als gemeinsames Inventar für Microsoft- und Fremd-Agents, inklusive der Anzahl an Agents ohne Besitzer (Microsoft Learn). Die Governance-Seite habe ich ausführlicher im Beitrag zum Agent Lifecycle beschrieben.

Strategisch heißt das: Ein Agent, der unter einem geteilten Dienstkonto oder mit den delegierten Rechten einer Person läuft, lässt sich im Audit-Log nicht unterscheiden, nicht separat drosseln und nicht separat abrechnen. Das später für Hunderte Agents nachzuziehen, ist genau die Art Projekt, für die niemand Budget freigibt.

Agentenarbeit messen

Beim Budget bricht es an derselben Stelle. Das Controlling rechnet in den meisten IT-Organisationen noch in Personentagen, und für Agentenarbeit gibt es in diesem Modell keine Zeile. Ein praktikabler Weg ist, Agent-Sitzungen über ein AI Gateway zu leiten. Dann lässt sich jedes Token und jede Stunde Laufzeit einem Projekt und einem Repository zuordnen und mit echten Preisen bewerten.

Ein Feature, das letztes Jahr 20 Tage gebraucht hat und dieses Jahr 3 Tage Review plus Agentenlaufzeit, passt nicht in dieses Modell. Agentenstunden zu zählen ist ein Anfang, aber Stunden sind eine Input-Kennzahl. Wissen willst du die Kosten pro akzeptierter Änderung: Tokens und Laufzeit plus die menschliche Zeit für Review, Nacharbeit und die Fälle, in denen jemand „Nein“ sagen musste. Ohne den menschlichen Anteil sieht Agentenarbeit billiger aus, als sie ist.

Für Microsoft-Agents sammelt die Observability in Agent 365 Aktivitätsdaten und soll Kennzahlen wie Nutzung und Zeitersparnis liefern (Microsoft Learn). Das deckt einen Teil des Bildes ab. Coding-Agents außerhalb von Microsoft 365 brauchen eine eigene Zuordnung, und dort kommt der Gateway-Ansatz ins Spiel.

Entscheidungen für die nächsten zwölf Monate

Anthropic erwartet, dass andere Organisationen in den nächsten sechs bis zwölf Monaten auf diese Art Problem stoßen. Auch wenn dein Zeitplan länger ist, diese Entscheidungen würde ich jetzt treffen:

Menschlich getaktete Kontrollen erfassen. Liste jede Freigabe, jedes Review und jeden Pipeline-Schritt auf, der von einer Person und einem Arbeitstag ausgeht. Markiere, was beim zehnfachen Volumen bricht.
Risikostufen für Änderungen einführen. Schreib auf, welche Änderungen einen Menschen brauchen, welche nur eine Prüfung der Absicht und welche nur Protokollierung. Mach die Regel maschinenlesbar.
Agents eigene Identitäten geben. Keine geteilten Dienstkonten, jeder Agent mit Sponsor, Berechtigungen über Access Packages mit Ablaufdatum.
Integrationen für Maschinen-Clients auslegen. Delta Queries, Change Notifications und API-Budgets statt Polling und Scraping.
Agentenkosten zuordnen. Tokens und Laufzeit pro Projekt plus die menschliche Review-Zeit, ab dem ersten produktiven Agent.

Was ich nicht tun würde: Anthropics Werkzeuge nachbauen. Deren Problem waren 25 Millionen Checkouts am Tag. Deins ist wahrscheinlicher ein Change-Prozess, der zwei Wochen für eine Konfigurationsänderung braucht, die ein Agent in zehn Minuten vorbereitet hat. Dort fängst du an.

Quellen

Anthropic Engineering: Redesigning source control at Anthropic (13. Oktober 2026)
Microsoft Learn: Microsoft Graph throttling guidance
Microsoft Learn: Avoid getting throttled or blocked in SharePoint Online
Microsoft Learn: Governing agent identities
Microsoft Learn: Manage agent registry in Microsoft 365 admin center
Microsoft Learn: Agent 365 observability
EUR-Lex: Richtlinie (EU) 2022/2555 (NIS2), Artikel 21

Team Knowledge Base in SharePoint: Copilot kompiliert das Wissen, Agents lesen es

Wed, 14 Oct 2026 07:00:00 +0200

Microsoft hat am 14. Oktober 2026 im SharePoint-Blog eine „Team Knowledge Base“ vorgestellt. Copilot stellt dabei aus den Inhalten eines Teams eine eigene Wissensbasis zusammen: eine Bibliothek aus verlinkten Markdown-Dateien, die Menschen lesen können und die Agents als Grounding dient. Das Ganze startet als Frontier Preview und läuft über usage-based billing.

Für mich ist das die spannendste SharePoint-Ankündigung seit Längerem, weil sie verändert, worauf ein Agent seine Antworten stützt. Aus demselben Grund habe ich dazu auch die meisten Fragen.

Was ist eigentlich neu?

Bisher lief das Grounding in Microsoft 365 über Retrieval. Copilot oder ein Agent sucht zur Frage passende Stellen in den Originaldokumenten und formuliert daraus die Antwort. Der Knowledge Agent in SharePoint hat diese Dokumente zwar aufgewertet, mit Metadaten und Struktur. Die Grundlage der Antwort blieb aber immer das Original.

Die Team Knowledge Base schiebt eine Schicht dazwischen. Copilot liest die Teaminhalte und kompiliert daraus eine eigene Wissensbasis. Technisch ist das eine spezielle Bibliothek, deren Markdown-Dateien untereinander verlinkt und so aufgebaut sind, dass Agents gut damit arbeiten können. Erzeugt wird sie von der „Knowledge Compilation Engine“, die zu Work IQ gehört. Was Work IQ sonst umfasst, habe ich im Beitrag zu RAG und Foundry IQ kurz eingeordnet.

Beim Retrieval entsteht das Wissen bei jeder Anfrage neu aus den Rohdaten. In der Knowledge Base liegt es vorab aufbereitet als eigenes Artefakt, das man öffnen, lesen und korrigieren kann. Ein Agent muss sich seine Antwort dann nicht mehr aus zwanzig Versionen derselben Präsentation zusammensuchen.

So funktioniert’s

Am Anfang steht eine bewusste Entscheidung im Team: Die Mitglieder steuern gezielt E-Mails, Chats, Meetings und Inhalte der Site bei. Die Knowledge Compilation Engine macht daraus die verlinkten Markdown-Dateien. Danach hält Copilot den Bestand aktuell. Anlegen, ergänzen und kuratieren können sowohl Copilot als auch Agents, die Wissensbasis ist also kein einmaliger Export.

Hängen lässt sie sich an jede SharePoint-Site, ausdrücklich auch an Sites hinter Teams-Kanälen und Microsoft-365-Gruppen. Das sind in den meisten Tenants genau die Orte, an denen die eigentliche Teamarbeit liegt.

Genutzt wird die Wissensbasis über Copilot in SharePoint und über den Autopilot in der neuen Copilot-App. Über den Autopilot kommt man auch aus Teams heran oder schreibt ihm einfach eine E-Mail. Der Autopilot wird allerdings separat ausgerollt. Nur weil die Knowledge Base im Tenant aktiv ist, steht er also nicht automatisch zur Verfügung.

Zur Leistung nennt Microsoft Zahlen aus eigenen internen Tests vom Oktober 2026: Agent-Antworten seien mit der Wissensbasis bis zu viermal schneller und 30 % tokeneffizienter. Das sind Herstellerangaben. Ich würde sie erst einplanen, wenn ich sie mit eigenen Inhalten nachvollzogen habe.

Als Beispiele skizziert Microsoft Szenarien aus drei Bereichen. Im Legal-Team bündelt die Wissensbasis das Wissen rund um Verträge. In der Entwicklung liefert sie Kontext für Coding-Agents und hilft beim Onboarding neuer Teammitglieder. Im Vertrieb entstehen Account-Snapshots. Das Engineering-Szenario finde ich am interessantesten: Ein Coding-Agent, der die Architekturentscheidungen aus dem Teams-Kanal kennt, schreibt vermutlich brauchbareren Code als einer, der nur das Repository sieht.

Verfügbarkeit und Lizenzierung

Stand heute gibt es die Team Knowledge Base nur in der Frontier Preview und nur für User mit usage-based billing. Gesteuert wird sie im Microsoft 365 Admin Center. Microsoft weist ausdrücklich darauf hin, dass sich die Abrechnungsbedingungen bis zur allgemeinen Verfügbarkeit noch ändern können.

Praktisch heißt das: Es gibt keinen festen Preis pro Lizenz, die Kosten hängen von der Nutzung ab, und die Regeln dafür sind noch nicht final. Für einen Pilot würde ich mir deshalb ein Team mit überschaubarem, gut gepflegtem Inhalt suchen. Die Abteilungs-Site mit zehn Jahren Altlasten ist dafür der falsche Startpunkt.

Roadmap

Für die Zeit nach der Preview hat Microsoft mehrere Ausbaustufen angekündigt, allerdings ohne Termine:

Knowledge Bases auch in Cowork, in Copilot in Teams und in Agents aus Copilot Studio
engere Integration mit Microsoft-365-Gruppen, inklusive Bootstrapping der Wissensbasis aus Kanälen und Mail
automatische Kuratierung über Agent Flows in Copilot Studio
Skalierung auf größere Bestände über einen Ansatz namens „Corpus Map“
Anbindung an CLIs und Coding-Agents über Work IQ

Im selben Zug gab es eine Reihe weiterer SharePoint-Neuigkeiten. Copilot in SharePoint ist jetzt allgemein verfügbar, die SharePoint-Tools in Work IQ sind nutzbar, und dazu kommen ein SharePoint Admin Agent, Catalog Management, ein Berechtigungsreport für EEEU („Everyone except external users“) auf Dateiebene, Insights zum Zugriff von Agents und ein Governance Hub für Site Owner. Den EEEU-Report und die Insights zum Agent-Zugriff würde ich mir als Erstes ansehen. Mit ihnen findet man Oversharing, bevor zu weit geteilte Inhalte in eine Wissensbasis wandern.

Einordnung und offene Fragen

Viele meiner Kunden arbeiten in regulierten Umgebungen, bei KRITIS-Betreibern oder unter NIS2. Dort entscheidet sich ein Feature wie dieses an Fragen, die die Ankündigung nicht beantwortet. Ich formuliere sie bewusst als offene Fragen, weil ich die Antworten nicht kenne.

Berechtigungen. Die Markdown-Dateien sind neue Dateien in einer Bibliothek. Erben sie die Berechtigungen der Quellen oder die der Bibliothek? Was passiert, wenn eine Mail einfließt, die nur ein Teil des Teams lesen durfte? Sieht dann das ganze Team die daraus abgeleitete Zusammenfassung?

Sensitivity Labels. Übernimmt eine Datei, die aus einem als vertraulich gelabelten Dokument entsteht, dieses Label? Und welches Label gilt, wenn eine Datei Inhalte aus mehreren Quellen mit unterschiedlichen Labels zusammenführt? Bei Mails und Chats ist das besonders heikel, weil dort Labels oft anders gesetzt werden als in Dokumentbibliotheken.

Retention. Mails, Chats und Site-Inhalte unterliegen häufig unterschiedlichen Aufbewahrungsrichtlinien. Wird ein abgeleiteter Inhalt entfernt, wenn das Original nach Ablauf der Frist gelöscht wird? Oder lebt er in der Wissensbasis nach den Regeln der Bibliothek weiter? Für Löschpflichten und eDiscovery macht das einen erheblichen Unterschied.

Kostenkontrolle. Wenn Copilot die Wissensbasis laufend aktuell hält, wie viel Verbrauch entsteht dann, auch wenn gerade niemand eine Frage stellt? Lässt sich der Verbrauch pro Site oder Team begrenzen, und wie gut sieht man vorab, was ein Pilot kosten wird?

Ein Werkzeug dafür gibt es schon: Im Microsoft 365 Admin Center lassen sich unter Copilot > Cost Management Ausgabenrichtlinien mit Limits für die Organisation und pro User festlegen (Microsoft Learn). Die Einstellung „Auto-apply new services“ ist dort standardmäßig aktiv, neue unterstützte Dienste fallen also automatisch unter bestehende Richtlinien. Ob die Knowledge Base dort als eigener Dienst auftaucht, geht aus der Ankündigung nicht hervor. Wer neue Features vor der Freigabe prüfen will, sollte die Einstellung in den betroffenen Richtlinien abschalten.

Solange diese Punkte nicht geklärt sind, würde ich die Knowledge Base an keine Site hängen, auf der regulierte oder personenbezogene Daten liegen. Für einen Pilot mit unkritischem Inhalt spricht dagegen nichts.

Fazit

Die Team Knowledge Base ist ein echter Architekturwechsel: Agents antworten auf Basis einer gepflegten, lesbaren Zwischenschicht statt direkt auf Rohdokumenten. Wie gut das in der Praxis trägt, hängt an der Vererbung von Berechtigungen, Labels und Aufbewahrung. Darauf würde ich in der Preview zuerst schauen, noch vor den Performance-Zahlen.

Quellen

RAG für Agents: wo ein einfacher Agent an Grenzen stößt und was Foundry IQ daran ändert

Mon, 12 Oct 2026 07:00:00 +0200

Diese Woche (12. bis 14. Oktober 2026) sitze ich in der Schulung zu AI-103, Developing AI Apps and Agents on Azure. Eine Folie hat einen einfachen Agent mit einem RAG-Agent verglichen: links fünf Grenzen, rechts fünf Lösungen. Die Folie stimmt. Als Service Owner für M365 Collaboration und Copilot bei einem IT-Dienstleister mit Kunden aus regulierten Branchen (KRITIS, NIS2) lese ich sie aber mit SharePoint, Berechtigungen und Governance im Hinterkopf, und dann sehen einige der Lösungen nach neuer Arbeit für die Leute aus, die die Daten verantworten.

Kurz gesagt

Mit RAG ist ein Agent nur so aktuell, korrekt und sicher wie die Inhalte und Berechtigungen dahinter. Oversharing und veraltete Dokumente in SharePoint werden direkt zu schlechten Antworten.

Foundry IQ bietet eine gemeinsame Knowledge Base für viele Agents, aufgebaut auf Agentic Retrieval in Azure AI Search. Damit muss nicht mehr jedes Team seine eigene Pipeline bauen.

Stand Oktober 2026 sind genau die Teile, die du für SharePoint in einem regulierten Tenant brauchst (beide SharePoint-Knowledge-Sources, LLM-Query-Planning, Rechteprüfung), noch in Preview.

RAG in wenigen Sätzen

Ein Sprachmodell kennt nur seine Trainingsdaten. Retrieval Augmented Generation (RAG) schiebt vor die Antwort einen Suchschritt: Der Agent durchsucht angebundene Quellen nach passenden Textstellen, gibt sie dem Modell mit in den Prompt und lässt es auf dieser Grundlage antworten, idealerweise mit Verweis auf die Quelle jeder Aussage. Das Modell bleibt dasselbe, nur das Material, mit dem es arbeitet, ändert sich.

Fünf Grenzen eines einfachen Agents

Grenze eines einfachen Agents	Was ohne RAG passiert	Was RAG ändert
Knowledge Cutoff	Antworten spiegeln den Stand der Trainingsdaten, Richtlinien und Produkte können Monate oder Jahre veraltet sein.	Aktuelle Dokumente werden zum Zeitpunkt der Frage aus angebundenen Quellen geholt.
Kein Zugriff auf interne Daten	Der Agent liefert nur Allgemeinwissen, nicht deinen Prozess, deinen Vertrag, dein System.	Interne Wissensbasen werden für den Agent durchsuchbar.
Fehlender Unternehmenskontext	Ratschläge ignorieren Freigabeketten, Workflows und Security-Policies.	Antworten stützen sich auf die abgerufenen Richtlinien und Abläufe.
Erfundene Antworten	Plausible, aber falsche Aussagen werden zum Compliance-Risiko.	Antworten verweisen auf ihre Quelle und lassen sich prüfen.
Skalierung	Jedes Team baut und betreibt eine eigene RAG-Pipeline mit eigenem Index, Chunking und eigener Rechtelogik.	Eine gemeinsame Wissensplattform bedient viele Agents, zum Beispiel Foundry IQ.

Wo die Folie zu optimistisch ist

„Immer aktuell“ heißt „so aktuell wie der Index“

Foundry IQ unterscheidet zwei Arten von Knowledge Sources. Indizierte Quellen kopieren Inhalte in einen Azure-AI-Search-Index: Chunking, Embeddings, Metadaten, optional Berechtigungen. Sie sind so frisch wie der letzte Indexer-Lauf, und den Zeitplan legst du selbst fest. Remote-Quellen speichern nichts und fragen das Quellsystem zum Zeitpunkt der Suche ab. Die Inhalte sind damit per Design aktuell.

Für Berechtigungen gilt dieselbe Logik, und da würde ich genauer hinschauen als beim Inhalt. Für indiziertes SharePoint mit ACL-Ingestion (Preview) dokumentiert Microsoft: Rechteänderungen auf Elementebene werden beim nächsten Indexer-Lauf übernommen. Änderungen auf übergeordneter Ebene (Site, Bibliothek, Ordner) nicht, dafür braucht es einen expliziten Resync. Bis dahin liefert der Index veraltete Berechtigungen. Wenn dein Offboarding oder dein Need-to-know-Prinzip darauf beruht, jemanden aus einer Site zu entfernen, gehört diese Lücke in die Risikobewertung.

Eine Quellenangabe macht eine Antwort nicht richtig

Ein Quellenverweis belegt, dass eine Textstelle gefunden wurde. Er belegt nicht, dass es die richtige war, dass sie noch gilt oder dass das Modell sie korrekt wiedergegeben hat. RAG reduziert Halluzinationen, es beseitigt sie nicht. Das Modell kann zwei richtige Textstellen zu einem falschen Schluss verbinden oder die Fassung einer Richtlinie von 2023 zitieren, weil sie höher gerankt wurde als die von 2026. Quellen machen Fehler leichter auffindbar, nachsehen muss trotzdem jemand.

RAG macht SharePoint-Hygiene zur Agent-Qualität

Mit RAG hängen die Antworten des Agents direkt davon ab, was in den Quellen liegt. Alles, was dich in SharePoint ohnehin stört, landet in den Antworten:

Oversharing: Zu breit geteilte Inhalte werden gefunden und zitiert, denn die Rechteprüfung arbeitet mit den Berechtigungen, die existieren, nicht mit denen, die du gemeint hast.
Veraltete Dokumente: Eine alte Richtlinie, die niemand archiviert hat, konkurriert mit der aktuellen.
Dubletten: Drei Kopien derselben Prozessbeschreibung in drei Versionen geben der Retrieval-Engine drei Optionen zur Auswahl.

Berechtigungen und Sensitivity Labels werden damit zum Steuerungsinstrument für Qualität. Eine Knowledge Source auf die richtigen Sites eingrenzen, Freigaben an „Jeder außer externen Benutzern“ entfernen und veraltete Inhalte archivieren verbessert direkt die Antworten.

Ein Agent kennt nur die Freigabekette, die aufgeschrieben ist

RAG kann Antworten nur auf Freigabeketten und Security-Policies stützen, die irgendwo dokumentiert sind, wo der Agent sie findet. In vielen Organisationen existiert die tatsächliche Freigabekette in den Köpfen der Beteiligten oder in einem Teams-Chat von 2022. In der Praxis beginnt ein RAG-Projekt deshalb oft als Dokumentationsprojekt.

Foundry IQ kurz erklärt

Foundry IQ ist die verwaltete Wissensschicht in Microsoft Foundry (früher Azure AI Foundry). Sie besteht aus drei Bausteinen, die alle auf Azure AI Search laufen:

Knowledge Base: das Objekt auf oberster Ebene. Es bündelt eine oder mehrere Knowledge Sources und steuert das Retrieval-Verhalten. Mehrere Agents können sich eine Knowledge Base teilen.
Knowledge Sources: Verbindungen zu indizierten oder Remote-Inhalten. Stand Oktober 2026 listet Microsoft Learn unter anderem Suchindex, Azure Blob, OneLake, Azure SQL, Datei-Upload, indiziertes und Remote-SharePoint, Fabric Data Agents und Ontologien, MCP-Server, Work IQ und Web-Grounding über Bing.
Agentic Retrieval: die Retrieval-Engine. Mit einem optionalen LLM zerlegt sie eine Frage in Teilabfragen (Query Planning), wählt die passenden Quellen, sucht parallel, rankt die Ergebnisse neu und liefert extrahierte Inhalte mit Quellenverweisen. Wie viel LLM-Arbeit dabei anfällt, steuert der Retrieval Reasoning Effort: minimal ohne LLM (bis zu 10 Quellen), low mit drei Quellen und drei Teilabfragen, medium mit je fünf plus einem iterativen Durchlauf.

Agents binden die Knowledge Base über ihren MCP-Endpunkt an: im Foundry Agent Service (als MCP-Tool), mit dem Microsoft Agent Framework oder in jeder eigenen App über REST und SDKs. Copilot Studio erreicht eine Knowledge Base indirekt: Du verbindest einen Foundry-Agent, der die Knowledge Base nutzt, mit deinem Copilot-Studio-Agent (Preview).

Foundry IQ ist einer von drei „IQ“-Workloads. Work IQ liefert Kontext aus der Zusammenarbeit in Microsoft 365 (Dokumente, Meetings, Chats). Fabric IQ modelliert Geschäftsdaten in Microsoft Fabric. Foundry IQ verbindet Unternehmenswissen aus Azure, SharePoint, OneLake und dem Web. Die drei sind unabhängig, lassen sich aber kombinieren; Work IQ gibt es sogar als Knowledge Source in Foundry IQ.

SharePoint als Knowledge Source

Für SharePoint gibt es zwei Wege, Stand Oktober 2026 beide in Preview:

Indiziertes SharePoint erzeugt eine Indexer-Pipeline und kopiert die Inhalte nach Azure AI Search. Berechtigungen greifen nur, wenn du ACL-Ingestion konfigurierst und zur Abfragezeit das Token des Benutzers mitgibst. Die dokumentierten Einschränkungen solltest du vorher lesen: Freigabelinks für „Jeder“ oder „Personen in Ihrer Organisation“ werden nicht unterstützt, Entra-Gruppen innerhalb von SharePoint-Gruppen werden nicht aufgelöst, und laut Dokumentation des SharePoint-Indexers werden Tenants mit aktiviertem Conditional Access nicht unterstützt. Für die meisten regulierten Tenants, die ich kenne, ist allein der letzte Punkt ein K.-o.-Kriterium.

Remote-SharePoint nutzt die Copilot Retrieval API und fragt SharePoint live im Namen des Benutzers ab. Kopiert wird nichts; die Retrieval API setzt SharePoint-Berechtigungen und Microsoft-Purview-Sensitivity-Labels selbst durch. Microsoft empfiehlt diesen Weg für eigene RAG-Apps auf SharePoint. Die Kehrseite: Jeder Benutzer braucht eine Microsoft-365-Copilot-Lizenz oder Retrieval-API-Pay-as-you-go (Preview, setzt mindestens eine Copilot-Lizenz im Tenant voraus). Es gilt ein Limit von 200 Anfragen pro Benutzer und Stunde und maximal 25 Ergebnissen pro Abfrage, OneDrive-Inhalte sind nicht enthalten, und abgerufen wird nur Text.

Wenn deine Benutzer ohnehin Copilot-Lizenzen haben, würde ich Remote-SharePoint zum Standard machen: keine zweite Kopie der Daten, kein zweites Berechtigungsmodell, das synchron bleiben muss.

Was das für regulierte Umgebungen heißt

Rechte-bewusstes Retrieval passiert nicht automatisch. Die Doku ist da eindeutig: Ohne das Token des Benutzers in der Anfrage liefern Quellen mit Rechteprüfung ihre Ergebnisse ungefiltert. Ruft ein Agent die Knowledge Base mit seiner eigenen Managed Identity auf, bekommt jeder Benutzer dieselbe Ergebnismenge. Die Token-Weitergabe gehört vor den ersten Pilot gebaut und getestet, nicht danach.
Nachvollziehbarkeit ist ein echter Gewinn. Verweise mit URLs und Informationen zum Sensitivity Label zeigen, auf welchen Dokumenten eine Antwort beruht. Bei Audit-Fragen ist das deutlich besser als „das Modell hat es so gesagt“, vorausgesetzt, dein Logging hält es fest.
Den Preview-Status Zeile für Zeile prüfen. Mit der stabilen API-Version 2026-04-01 sind nur die Knowledge Sources Suchindex, Azure Blob, OneLake und Web allgemein verfügbar, und das mit Reasoning Effort minimal. Beide SharePoint-Quellen, LLM-Query-Planning, Answer Synthesis und die Berechtigungsfunktionen sind Preview, ohne SLA und nicht für den Produktivbetrieb empfohlen. Im Foundry-Portal und im Azure-Portal stehen alle Agentic-Retrieval-Funktionen nur als Preview zur Verfügung. Für einen KRITIS-Kunden ist das ein Pilot, kein produktiver Service.

In meinem Beitrag zum Vier-Phasen-Modell für verantwortungsvolle generative KI ist Grounding zusammen mit der Systemnachricht die dritte von vier Schutzschichten. Foundry IQ ist ein konkreter Weg, diese Schicht zu bauen. Die anderen drei ersetzt es nicht.

Fazit

Erst aufräumen, dann anbinden. Oversharing, veraltete Dokumente und Dubletten in SharePoint werden zu Fehlern des Agents. Eine Bereinigung auf Site-Ebene ist die günstigste Qualitätsverbesserung, die du bekommst.
Remote-SharePoint bevorzugen, wenn die Benutzer Copilot-Lizenzen haben. Keine zweite Kopie, Berechtigungen und Labels werden an der Quelle durchgesetzt, kein ACL-Sync zu überwachen.
Den Token-Pfad gezielt testen. Ohne ihn liefern Quellen mit Rechteprüfung ungefilterte Ergebnisse, und jeder Benutzer sieht dieselben Inhalte.
Foundry IQ auf SharePoint vorerst als Pilot behandeln. Den Produktivbetrieb planen, sobald die SharePoint-Knowledge-Sources und die Berechtigungsfunktionen allgemein verfügbar sind.