top of page

Microsoft 365 Copilot Agent SharePoint: Kundendaten sauber trennen

  • Autorenbild: Marcus Machon
    Marcus Machon
  • 8. Mai
  • 12 Min. Lesezeit

Vor zwei Wochen wollte ich nur eine simple Sache prüfen: Deckt meine IT-Haftpflicht eine bestimmte Klausel in einem Kundenrahmenvertrag wirklich ab? Mein Microsoft 365 Copilot Agent „Kundenprojekt-Begleiter" (ein deklarativer Agent, im Agent Builder erstellt) fand den Vertrag, zitierte die richtige Stelle und tat dann etwas, das mir wichtiger wurde als die Antwort selbst: Er bremste. „Juristisches Thema, bitte manuell prüfen." Genau in dem Moment hat sich für mich ein Modell verdichtet, das ich seit Monaten in der Praxis lebe, ohne es vorher klar benannt zu haben.

Dieser Beitrag erzählt diese Geschichte zu Ende. Drei getrennte KI-Welten, eine harte Regel dazwischen, und warum gerade die Reibung zwischen ihnen die Sicherheit ist (kein Bug, ein Feature). Ich glaube (!), wer Kundenarbeit, Vertragswissen und eigenes KI-Denken in dasselbe System kippt, baut keine KI-Strategie, sondern eine Datenwaschmaschine.

Für mich ist das kein abstraktes Keyword, sondern ein echter Praxisfall: ein Agent auf SharePoint-Daten, begrenzt durch Informationsarchitektur, Berechtigungen und menschliche Kontrolle.

Der Beitrag trennt bewusst zwischen Kundendaten, Vertragswissen und Strategie-Brain.

Microsoft 365 Copilot Agent SharePoint: Was im Dezember noch offen war

Microsoft hat deklarative Copilot Agents seit Februar 2026 von GPT-5.1 auf GPT-5.2 migriert; in Microsoft 365 Copilot Chat kamen GPT-5.2 und später GPT-5.4 Thinking als auswählbare Modi dazu. Inzwischen (Stand Mai 2026) taucht im Agent Builder meines Tenants auch GPT-5.5 als Modell-Option auf - eine offizielle Microsoft-Rollout-Ankündigung dazu habe ich bisher nicht gefunden. Welches Modell pro Agent-Anfrage tatsächlich antwortet, sieht der Nutzer trotzdem nicht transparent.

Im Dezember 2025 habe ich auf LinkedIn öffentlich gefragt, ob Copilot Agents auf älteren Modellen laufen als der normale Copilot Chat (Machon, 2025). Damals war ich frustriert: Ein einfacher Custom-Agent halluzinierte Daten, die in der gerade zitierten Quelle wörtlich anders standen. ChatGPT und Gemini lieferten mit identischem Prompt die korrekte Antwort.

Heute weiß ich: Ja, es gibt reale Modell-Unterschiede, aber die einfache Antwort „Agents laufen immer auf dem alten Modell" wäre inzwischen zu grob. Für einen Microsoft Copilot Agent im Mittelstand ist genau diese Unschärfe wichtig: Die meisten Teams bauen ihre ersten Agents nicht in einer großen Enterprise-Agent-Fabrik, sondern im Microsoft 365 Copilot Agent Builder, in Copilot Studio Lite oder direkt als SharePoint Agent aus einer SharePoint-Site heraus. Microsoft beschreibt für deklarative Agents erst die Umstellung auf GPT-5.1 und inzwischen den GPT-5.2-Rollout bis Ende März 2026 (Microsoft Learn, 2026; Microsoft Tech Community, 2026). Stand Mai 2026 sehe ich in meinem Tenant zusätzlich GPT-5.5 als wählbare Option im Agent Builder - eine offizielle Microsoft-Rollout-Doku dazu habe ich bislang nicht gefunden, das ist eigene Beobachtung. Gleichzeitig können Sie in Copilot Studio („Full Experience") Modelle expliziter wählen, inzwischen auch Claude-Modelle für bestimmte Agent- und Prompt-Szenarien (Microsoft Learn, 2026). In der Lite-Experience und im Agent Builder bleibt diese Modellkontrolle deutlich geringer. Microsoft selbst empfiehlt in der Doku gegen „Inference Drift" explizitere Instruktionen, was praktisch heißt: „Rechnen Sie damit, dass sich das Verhalten produktiver Agents nach Modellwechseln ändert."

Das ist die Tür, durch die mein 3-Schichten-Modell überhaupt erst Sinn ergibt. Wenn ich nicht wissen kann, welches Modell mein Agent gerade benutzt, brauche ich Grenzen, die unabhängig vom Modell gelten.

Wer nach Microsoft 365 Copilot Agent SharePoint sucht, meint meist genau diese Konstellation: einen Agenten, der aus einer SharePoint-Site heraus arbeitet und trotzdem sauber abgegrenzt bleiben muss.

Schicht 1: Die Hauptarbeit findet im Tenant des Kunden statt

Wenn ich für einen Kunden arbeite, bin ich Microsoft-365-Gast in seinem Tenant. Seine Daten bleiben dort, sein Compliance-Team behält die Kontrolle, und ich brauche keinen eigenen Tresor für fremde Daten zu bauen.

Das ist die unspektakulärste Schicht und gleichzeitig die wichtigste. Die meisten Consultants zentralisieren reflexartig: Kundendaten ins eigene Projektlaufwerk, Notizen ins eigene OneNote, Verträge ins eigene Dropbox-Äquivalent. Klingt nach Produktivität. Ist aber rechtlich und operativ ein Minenfeld.

Der Concentric AI Data Risk Report 2H 2025 (ein Vendor-Report, also mit Eigeninteresse zu lesen) dokumentiert, dass Microsoft Copilot pro Kundenorganisation im Schnitt auf rund drei Millionen sensible Datensätze zugreift und dass 57 Prozent der organisationsweit geteilten Datensätze sensitive Inhalte enthalten (Concentric AI, 2025). Wenn ich diese Daten zusätzlich in meinen Tenant kopiere, vervielfache ich genau dieses Risiko, ohne den Nutzen zu vergrößern. Und das deutsche Gerichts-Vorbild dafür, wer für die Aussagen einer KI haftet, ist auch längst geklärt: Operator-Haftung. Die Kanadische BCCRT entschied im Fall Moffatt v Air Canada, dass die Airline für die falsche Auskunft ihres Chatbots haftet: „it makes no difference whether the information comes from a static page or a chatbot" (BCCRT 149, 2024). Wer fremde Daten in den eigenen Stack zieht, zieht auch fremde Haftung mit.

Praktisch heißt das: Discovery-Workshops, Konzeptarbeit, Implementierung, alles als Gast im Kunden-Tenant. Was später als Erfahrungswert für mich relevant ist, abstrahiere ich anschließend bewusst (dazu kommt Schicht 3).

Schicht 2: Mein eigener Tenant mit dem Copilot Agent - Wie nutzt man Microsoft 365 Copilot Agents mit SharePoint?

Beim SharePoint Copilot Agent Datenschutz gilt eine einfache Regel: Ein Microsoft 365 Copilot Agent sollte nur klar begrenzte SharePoint-Quellen nutzen, Berechtigungen respektieren und sensible Daten nicht in externe KI-Workflows weiterreichen.
Der LGL-ClientVault als echte SharePoint-Bibliothek. Vertragsdokumente liegen metadatenbasiert statt in Ordnerketten. Inkl. automatischer Meta-Daten KI Zuweisung durch SharePoint "Autofill".

Technisch ist das bei mir ein eigener SharePoint-Hub mit internem EXT-*-Prefix. Für andere Organisationen wäre das typischerweise eine SharePoint-Hubwebsite, ein Extranet oder eine sauber abgegrenzte Kundenakte. Der Name ist egal. Entscheidend ist, dass der Copilot-Agent-Use-Case nicht auf einem diffusen Tenant läuft, sondern auf einer bewusst geschnittenen Informationsarchitektur.

Was ist eine SharePoint-Hubwebsite?

Eine SharePoint-Hubwebsite ist eine Dach-Struktur: Sie bündelt mehrere darunter hängende SharePoint-Sites unter gemeinsamer Navigation, einem gemeinsamen Design und einer übergreifenden Suche - aber sie hebelt deren Berechtigungen nicht aus. Was auf einer einzelnen Kunden-Site liegt, bleibt auch dort. Der Hub ist der gemeinsame Eingang, nicht der gemeinsame Datentopf.

Bei mir heißt das Dach „Client Success Hub". Darunter hängt pro Kunde eine eigene SharePoint-Site mit eigenen Zugriffsrechten - und nur dort liegen die Dokumente dieses Kunden. Wenn der Copilot-Agent für eine Frage zu einem Vertrag von Kunde A nachschaut, sieht er auch nur den Inhalt aus dieser einen Kundensite. Das ist keine Magie der KI, sondern saubere SharePoint-Architektur, die der Agent erbt. Die Trennung passiert in SharePoint, nicht im Copilot.

Der „Client Success Hub" als zentrale Dach-Site. Darunter hängen die einzelnen Kundensites, jede mit eigenen Berechtigungen.

Welcher Agent-Typ ist das eigentlich? Agents in SharePoint vs Microsoft 365 Copilot Agents

Microsoft unterscheidet vier Wege, einen Agent zu bauen. Wer sie nicht trennt, plant am falschen Werkzeug (Microsoft Learn, 2026).

Agents in SharePoint. Ein SharePoint-naher Einstieg für Agents, die Fragen zu SharePoint-Websites, Bibliotheken, Seiten oder Dateien beantworten. Sie werden direkt aus der Site-Homepage, einer Bibliothek oder dem Kontextmenü einer Datei erstellt und als .agent-Datei gespeichert. Der Scope ist die SharePoint-Auswahl, auf die der Agent ausgerichtet wurde. Vorteil: sekundenschneller Einstieg, Berechtigungen erbt der Agent von der Site. Nachteil: ein eigener Agent pro Bereich, kein Querbezug über Sites hinweg (Microsoft Support, 2026).

Agent Builder in Microsoft 365 Copilot. Der einfache Baukasten für deklarative Microsoft-365-Copilot-Agents - direkt in Microsoft 365 Copilot Chat, mit natürlicher Sprache, Instructions, Wissensquellen und Prompts. Wissensquellen können mehrere SharePoint-Sites, OneDrive, Teams, Outlook oder Copilot-Connectors kombinieren. Nutzt das eingebaute Copilot-Modell und den Orchestrator (Microsoft Learn, 2026). Das ist die Variante, die ich für meinen „Kundenprojekt-Begleiter" einsetze.

Copilot Studio. Der Weg, wenn aus einem Q&A-Agent ein Prozess- oder Integrationsagent wird: Low-Code-Plattform für komplexere Agents mit Workflows, externen Integrationen, größeren Zielgruppen, Anwendungslebenszyklus-Management und Governance über die Power Platform.

Custom Engine Agents. Vollständig angepasste Agents mit eigener Orchestrierung und Modellwahl. Spezialbau, kein typischer Fachbereichseinstieg.

Was alle vier gemeinsam haben: Sie respektieren bestehende Microsoft-365-Berechtigungen. Sie schaffen keine neuen Zugriffsrechte, sondern machen vorhandene Inhalte leichter abfragbar. Deshalb sind die SharePoint-Informationsarchitektur, Berechtigungen, Owner und Datenlebenszyklen die Grundlage für gute Agent-Antworten - nicht die KI selbst.

Mein Setup konkret: Der „Kundenprojekt-Begleiter" ist ein deklarativer Microsoft 365 Copilot Agent, gebaut im Agent Builder. Er liest den LGL-ClientVault (Vertragsbibliothek) und die Kundensites unter dem Client Success Hub - mehrere Quellen kombiniert in einem Agent. Ein einzelner Agent in SharePoint pro Site wäre für meinen Use-Case zu eng. Ich brauche den Querbezug zwischen Vertragslage und konkretem Kundenkontext - und genau dafür ist der deklarative Agent gemacht.

Greifen Copilot Agents nur auf erlaubte Dateien zu?

Copilot Agents arbeiten grundsätzlich entlang der Nutzerberechtigungen. Das schützt aber nur, wenn SharePoint-Berechtigungen, Extranet-Struktur und Sensitivity Labels vorher aufgeräumt sind.

Hier sitzt mein „Kundenprojekt-Begleiter". Drei Beispielfragen, die ich ihm in den letzten Wochen tatsächlich gestellt habe:

„Habe ich für Mandat XY eine Haftungsbegrenzung im Rahmenvertrag, und wenn ja, in welcher Höhe?" Der Agent zitiert die Klausel wörtlich, mit Verweis auf das Quelldokument im LGL-ClientVault. Das spart mir das Querlesen eines 30-Seiten-PDFs vor einem Pricing-Gespräch. Nutzbar in unter 30 Sekunden.

„Was war das letzte Thema mit Mandat ABC?" Der Agent zieht das letzte Meeting-Protokoll, fasst die offenen Punkte zusammen, nennt das Datum. Vor jedem Re-Connect ein kleiner, aber realer Zeitgewinn (vorausgesetzt, ich habe die Protokolle konsistent abgelegt, sonst Müll rein, Müll raus).

„Darf ich für Mandat 123 ein anonymisiertes Case-Study-Snippet auf LinkedIn veröffentlichen?" Der Agent prüft die NDA-Klausel, gibt den exakten Wortlaut der Geheimhaltungs-Vereinbarung zurück und empfiehlt eine explizite Freigabe-Anfrage beim Kunden. Auch hier wieder: Antwort plus Disclaimer.

Und jetzt der unbequeme Teil: Mein Copilot Agent halluziniert. Nicht oft, aber regelmäßig. Ein öffentlicher Microsoft-Q&A-Thread dokumentiert einen Nutzerbericht zu Build bizchat.20260210.47.1, in dem die Mehrheit der Antworten mindestens eine inkorrekte Citation enthielt: Die zitierte Quelle passte nicht zur getroffenen Aussage (Microsoft Q&A, 2026). Stanford-Forschende zeigen in einer pre-registrierten, peer-reviewten Audit-Studie für die etablierten Legal-RAG-Tools (Lexis+ AI, Westlaw AI-Assisted Research, Ask Practical Law AI), dass diese trotz Retrieval-Augmentation zwischen 17 und 33 Prozent der Anfragen halluzinieren (Magesh et al., 2025). RAG mindert das Problem, eliminiert es aber nicht.

Genau deshalb ist der eingebaute Vorsichts-Reflex meines Agents: „bei juristischen oder steuerlichen Fragen Rücksprache mit Fachleuten". Das wertvollste Feature, nicht die Suchgeschwindigkeit. Ich behandle den Agent wie einen sehr fleißigen, sehr schnellen Werkstudenten, der nicht raten darf, aber gerne wieder zu mir kommen soll. Trust but verify, jedes Mal.

Schicht 3: Mein eigenes KI-System - Wie trennt man Kundendaten von externen KI-Tools wie Claude Code?

Claude Code und Codex eignen sich für Strategie, Recherche und Wissensarbeit. Kundennamen, Verträge und personenbezogene Projektdaten bleiben im Microsoft-365-Tenant oder Kunden-Tenant.

In dieser Schicht baue ich seit Monaten ein eigenes Wissenssystem auf: Studien zu KI-Adoption, dokumentierte Patterns aus M365-Projekten, eigene Beobachtungen aus Discovery-Calls (ohne Mandantenbezug), Marktdaten, Fakten-Pipeline mit automatischer Verifikation. Wer den Aufbau im Detail nachlesen will, findet ihn in meinen Beiträgen „Multi-Agent-System aufbauen" und „KI-Faktenprüfung im Wissenssystem".

Warum diese harte Trennung? Drei Gründe.

Modell-Vielfalt. In Claude und Codex kann ich gezielt Opus, Sonnet oder GPT-5.5-Codex einsetzen, je nachdem, ob ich strukturiert analysieren, schnell draften oder Cross-LLM-Sparring will. Microsoft schreibt in Copilot mittlerweile ehrlich, dass es weg von Modellnamen will und stattdessen über „Outcomes" routen möchte (GeekWire, 2026). Für Vertragssuche akzeptabel. Für Strategiedenken zu wenig Kontrolle.

Datenklassen-Hygiene. Ein zweiter Grund ist juristisch. Die EDPB hat im Dezember 2024 in Opinion 28/2024 klargestellt, dass KI-Modelle nicht pauschal als anonym gelten können und dass Verantwortliche die Rechtmäßigkeit der Modell-Entwicklung im konkreten Einsatzkontext mitbewerten müssen (EDPB, 2024). Solange diese Fragen bei Sub-Prozessoren und Modellketten nicht final geklärt sind, hat in meiner Brain-Welt schlicht nichts personenbezogen Verarbeitetes verloren.

Darf ein IT-Berater Claude oder ChatGPT für Kundenprojekte nutzen?

Wer KI Tools Kundendaten trennen will, braucht eine klare Antwort: Ja zu externen Modellen, aber nur für Strategie, Recherche und abstrahierte Wissensarbeit. Kundendaten, Vertragsauszüge und personenbezogene Mandatsdetails gehören nicht in externe KI-Tools.

Habitat-Robustheit. Microsoft hat mit Agent 365 (GA seit 01.05.2026) eine Control Plane für Agent-Governance geschaffen, in der Defender und Intune unter anderem OpenClaw-Agents auf Windows-Geräten erkennen und blockieren können (Microsoft Security Blog, 2026). Das ist legitim, aber es zeigt: Wer alles in einer Welt zentralisiert, baut auch eine zentrale Abhängigkeit. Mein Brain muss laufen, wenn der Tenant gerade nicht erreichbar ist.

Mein zentraler Kunden-Hub gibt Orientierung. Rollen und Rechte bleiben je Kundensite und Dokumentenbibliothek entscheidend. Die meiste aber findet aber in der Kundenumgebung selbst statt.

Wo ist die Schnittstelle zwischen den Welten? Ich. Und das ist die Schwachstelle.

Es gibt keine API zwischen Tenant und Brain. Kein Auto-Sync, keine Connector-Brücke. Übertragen wird, was ich bewusst manuell rüberkopiere. Und genau dieser Mensch in der Mitte ist sowohl der Sicherheits-Filter als auch das größte Restrisiko.

Diesen Punkt habe ich tatsächlich am längsten verdrängt. Klingt erst mal nach guter Architektur: „Der Mensch entscheidet." Aber das UK Department for Business and Trade hat in seinem Copilot-Pilot festgestellt, dass 22 Prozent die Halluzinationsfrage nicht beantworteten und weitere 11 Prozent unsicher waren, ob sie eine Halluzination erlebt hatten (UK DBT, 2025). Wenn selbst ausgebildete Knowledge-Worker diese Frage nicht zuverlässig beantworten, dann ist „der Mensch entscheidet" eine ziemlich wackelige Sicherheits-Annahme.

Mein eigener Filter besteht ehrlich gesagt aus einer einzigen Regel: In Claude und Codex landen nur allgemeine Infos. Keine Kundennamen, keine Vertragsauszüge, keine konkreten Mandantendetails. Das ist keine ausgefeilte Methodik, das ist eine bewusst minimal gehaltene Heuristik, die ich konsequent anwende. Trotzdem (und das ist der unbequeme Teil) könnte ich mir unter Zeitdruck (eine Angebots-Deadline, ein Lead-Brief, ein „nur kurz zusammenfassen") sehr leicht selbst auf die Füße treten. Davor schützt mich keine Architektur, sondern Disziplin. Diese Ehrlichkeit gehört in jede KI-Strategie, die im Mittelstand wirklich tragen soll, sonst wird sie zu PowerPoint-Compliance.

Was hilft? Vor jedem Wechsel in die Brain-Welt eine Sekunde innehalten und sich genau eine Frage stellen: „Würde ich das, was ich gleich kopiere, auch dem Mandanten zeigen, mit dem Hinweis, dass es jetzt nach extern geht?" Wenn die Antwort nein ist, wird abstrahiert oder es bleibt im Tenant. Klingt banal, ist aber im Stress die einzige Heuristik, die zuverlässig greift 😉.

Was muss der Mittelstand vor Copilot Agents in SharePoint prüfen?

Vor Copilot Agents in SharePoint braucht der Mittelstand drei Dinge: ein Audit, wie Copilot Agents SharePoint Berechtigungen abgreifen, eine Datenklassifizierung mit Sensitivity Labels und klare Regeln für externe KI-Tools.

Der naheliegende Einwand ist berechtigt: „Das ist ein Berater-Setup, kein Mittelstands-Setup." Stimmt. Microsoft 365 E7, das die Agent-365-Control-Plane enthält, kostet 99 USD pro Nutzer und Monat; bei 200 Mitarbeitenden ergibt das 237.600 USD im Jahr (Microsoft 365 Blog, 2026). Für die meisten Mittelständler wirtschaftlich illusorisch. Höchstens ausgewählte Power User. Bitkom Research zeigt in seiner repräsentativen Befragung 2026 (n=604 Unternehmen ab 20 MA), dass 41 Prozent aktiv KI nutzen, aber 51 Prozent Probleme haben, die Digitalisierung zu bewältigen; Datenschutzanforderungen nennen 77 Prozent als Digitalisierungsbremse (Bitkom, 2026). KfW Research kommt parallel auf nur 20 Prozent KI-Nutzung im deutschen Mittelstand insgesamt, mit Digitalstrategie immerhin 35 Prozent (KfW, 2026). Das Setup-Problem ist im Mittelstand also real. Was Microsoft 365 Copilot Datenschutz Mittelstand praktisch heißt, entscheidet sich deshalb selten an der Lizenz und fast immer an der Frage, welche Daten den Agenten überhaupt erreichen dürfen.

Was übertragbar bleibt, ist die Trennlogik. DACH-Beratungshäuser (von Aithoria über Net at Work bis copilotenschule.de) konvergieren erstaunlich konsistent auf ein Vier-Stufen-Hybrid-Pattern, das im Kern genau das beschreibt, was ich hier beschreibe:

  1. M365 Copilot und Agents nur auf Daten mit Sensitivity-Label „Internal" und niedriger.

  2. „Confidential" und „Strictly Confidential" via Purview-DLP-Policy aus Copilot ausgeschlossen.

  3. Externe LLMs (ChatGPT Enterprise, Claude, Gemini) nur für Strategie-, Recherche- und Public-Web-Tasks ohne personenbezogene oder geschäftskritische Daten.

  4. Self-Hosting oder dediziertes Enterprise-Deployment für regulierte Branchen oder höchste Vertraulichkeitsstufen. Dazu zählen echte On-Prem-Modelle wie Aleph Alpha oder Mistral mit Open WebUI als Frontend, aber auch dediziertes Cloud-Setup mit Azure OpenAI Service (eigene GPT-Modelle im eigenen Tenant, ohne Daten-Sharing mit OpenAI). In der Praxis höre ich von vielen Mitarbeitenden, dass gerade diese Stufe am schlechtesten abschneidet: stark eingeschränkter Funktionsumfang, ältere Modell-Versionen, fühlt sich an wie ChatGPT vor zwei Jahren. Vorteil bleibt die Compliance-Freigabe für vertrauliche Daten. Nachteil ist der spürbare Abstand zu den aktuellen Frontier-Modellen.

Das ist kein Norm-Standard, sondern ein gewachsener Berater-Konsens. Und genau deshalb ist er im Mittelstand so brauchbar: Er funktioniert auch ohne E7-Lizenz, wenn man die Sensitivity-Label-Taxonomie sauber zieht und Purview konsequent betreibt. Der Hessische Datenschutzbeauftragte hat in seinem 137-Seiten-Bericht vom 15. November 2025 die DPA-Kritikpunkte der DSK von 2022 für ausgeräumt erklärt: Microsoft 365 ist datenschutzkonform nutzbar, vorausgesetzt EU Data Boundary, das überarbeitete DPA, ein dokumentierter AVV und eine durchgeführte DSFA sind vorhanden (HBDI Hessen, 2025). Die DSK selbst hat sich allerdings noch nicht offiziell neu positioniert (Stand Mai 2026), und der EU AI Act ist ohnehin parallel zu beachten. Artikel 4 (KI-Kompetenz, also Schulungspflicht für jede betroffene Person) gilt seit dem 2. Februar 2025, Hochrisiko-Pflichten ab dem 2. August 2026.

Wer also fragt „Was ist eigentlich Pflicht?", bekommt drei Antworten in einem Satz: Berechtigungs-Audit auf SharePoint, Datenklassifizierung mit Sensitivity Labels, dokumentierte Schulungspflicht. Und erst dann eine Copilot-Lizenz.

Fazit

Ob ein Microsoft 365 Copilot Agent SharePoint am Ende sauber läuft, entscheidet nicht das Tool, sondern die Grenze, die ich drumherum ziehe.

Mein 3-Schichten-Modell ist nicht elegant. Es ist umständlich, manuell, langsamer als ein All-in-One-Stack, und es lässt mich gelegentlich fluchen, wenn ich nach einem 30-Minuten-Block in Claude erneut in den Tenant wechseln muss. Aber genau diese Reibung ist die Sicherheit. Trust, but separate. Kundendaten gehören in den Kunden-Tenant. Vertragswissen in einen kontrollierten eigenen Microsoft SharePoint mit ggf. übergreifenden SharePoint Hub. Strategie, Recherchen, Content und Wissensaufbau in ein bewusst getrenntes KI-Brain. Und zwischen den Schichten arbeitet kein Connector, sondern ein Mensch, der sich im Zweifel selbst die richtigen Fragen stellt.

Wenn Sie an einem Copilot-Rollout im eigenen Haus arbeiten und vor genau dieser Frage stehen, wie viel KI-Vermischung Sie sich erlauben können, dann reden wir über Ihren Use Case, bevor Sie Lizenzen kaufen.

Mehr will dieser Copilot Agent SharePoint Praxisbericht nicht sein: ein ehrlicher Werkstattbericht aus echten Kundenprojekten, kein Verkaufsprospekt.

Über den Autor: Marcus Machon berät mittelständische Unternehmen bei Microsoft 365 Governance, SharePoint-/Teams-Struktur, Power-Platform-Automatisierung und Copilot-/KI-Readiness.

Quellen

  1. Marcus Machon (2025). Copilot Agents hallucinations. LinkedIn"

  2. Microsoft Learn (2026). Understand model changes in GPT 5.1+. Dokumentation"

  3. Microsoft Tech Community (2026). Microsoft 365 Copilot Declarative Agents Are Getting Smarter with GPT-5.2. Artikel"

  4. Microsoft Learn (2026). What''s new in Copilot Studio. Dokumentation"

  5. GeekWire (2026). Microsoft 365 Copilot and the end of the single-model era. Artikel"

  6. Concentric AI (2025). Data Risk Report 2H 2025. Report"

  7. BCCRT (2024). Moffatt v. Air Canada, 2024 BCCRT 149. Entscheidung"

  8. Microsoft Q&A (2026). Citations consistently wrong in M365 Copilot BizChat. Thread"

  9. Magesh et al. (2025). Hallucination-Free? Assessing the Reliability of Leading AI Legal Research Tools. DOI"

  10. EDPB (2024). Opinion 28/2024 on certain data protection aspects related to the processing of personal data in AI models. PDF"

  11. Microsoft Security Blog (2026). Microsoft Agent 365 now generally available. Artikel"

  12. UK Department for Business and Trade (2025). Evaluation of the M365 Copilot pilot. Bericht"

  13. Bitkom (2026). Digitalisierung der Wirtschaft: "Unternehmen beschäftigen sich mit KI. Presseinformation"

  14. KfW Research (2026). Künstliche Intelligenz im Mittelstand. PDF"

  15. Microsoft 365 Blog (2026). Powering Frontier Transformation with Copilot and agents. Artikel"

  16. HBDI Hessen (2025). Bericht zu Microsoft 365 und Datenschutz. PDF"

  17. https://www.nous-works.de/post/ki-faktenpruefung-wissenssystem"

bottom of page