SharePoint wird Copilot-Grundlage und baut „agentisch“

SharePoint als Wissensquelle für Copilot: Warum das strategisch ist (und nicht nur „nice to have“)

Copilot ist kein Zauberer. Er ist eher wie ein extrem schneller Praktikant mit Lesebrille: Er arbeitet nur mit dem, was er findet, was er verstehen kann und wozu er Zugang hat. Genau deshalb wird SharePoint zur strategischen Schaltzentrale. Denn im DACH-Alltag liegt das „unternehmensfähige Wissen“ typischerweise nicht in schicken Prompt-Sammlungen, sondern in Projektseiten, Richtlinien, Vorlagen, Prozessdokumenten, FAQs, Vertragsmustern, Lessons Learned und manchmal auch in „final_final_v7.docx“.

Wenn Copilot wirklich Nutzen stiften soll (Recherche, Zusammenfassungen, Entwürfe, Q&A, Entscheidungsgrundlagen), braucht er eine verlässliche Wissensbasis. SharePoint ist dafür ideal, weil er Struktur, Berechtigungen, Metadaten und Lebenszyklus mitbringt. Heißt im Klartext: Je besser SharePoint organisiert ist, desto weniger halluziniert der Praktikant und desto mehr liefert er belastbare Antworten.

Die strategische Logik: „Wissensqualität“ ist die neue „Suchqualität“

Früher war die wichtigste Frage: „Findet die Suche das Dokument?“
Heute lautet sie: „Kann Copilot das Richtige finden, richtig einordnen und korrekt verwenden?“

Dafür braucht es vier Dinge, die SharePoint besonders gut kann – wenn man ihn lässt:

1. Vertrauenswürdige Quellenräume: Teams/SharePoint-Sites als „Container“ für Themen, Abteilungen, Projekte.

2. Berechtigungen als Sicherheitsgeländer: Copilot sieht nur, was der Benutzer sehen darf. Das ist gut. Aber nur, wenn Berechtigungen sauber sind.

3. Metadaten als Bedeutungsanker: Ohne Metadaten ist vieles nur Text. Mit Metadaten wird es „Wissen“ (Status, Gültigkeit, Thema, Risiko, Prozessbezug).

4. Lifecycle als Realitätscheck: Veraltete Inhalte sind Copilot-Futter mit Ablaufdatum. Dann kommen Antworten von gestern für Probleme von heute.

Grundlagen, die IT schaffen muss (damit Copilot nicht im Datennebel fährt)

1) Informationsarchitektur: weniger Wildwuchs, mehr Landkarte

• Klare Site-Typen: z. B. Abteilung, Projekt, Community, Wissensbasis.

• Einheitliche Navigation und Startseiten-Templates.

• Wissens-Hubs (Hub Sites) für zentrale Themen (HR, IT, Qualität, Vertrieb).

Ziel: Inhalte sind erwartbar auffindbar, nicht „irgendwo“ in 700 Sites.

2) Berechtigungen: Copilot folgt Regeln, nicht Absichten

Copilot respektiert Berechtigungen. Deshalb sind zu breite Zugriffe genauso gefährlich wie zu viele Einzelberechtigungen:

• Weg von „jeder darf alles“.

• Weg von „Hans hat da mal kurz Zugriff bekommen und der lebt seit 2019“.

Best practice: Gruppenbasiert, rollenorientiert, möglichst wenig Item-Level-Berechtigungen.

3) Metadaten: Ohne Etikett ist alles Marmelade

Mindestens nötig (pragmatisch, nicht akademisch):

• Dokumenttyp (Richtlinie, Vorlage, Prozess, Vertrag, Präsentation, FAQ)

• Thema/Domain (z. B. Datenschutz, Einkauf, Vertrieb)

• Gültigkeitsstatus (Entwurf, geprüft, freigegeben, obsolet)

• Owner (fachlich verantwortlich)

• Optional: Vertraulichkeit/Schutzbedarf, Region/DACH, Aufbewahrungsklasse

4) Lifecycle: Inhalte altern. Copilot sagt sonst „Opa erzählt vom Krieg“

• Review-Zyklen (z. B. jährlich für Richtlinien, halbjährlich für Prozessdokus)

• Archivierung statt Datenfriedhof

• Retention/Labels dort, wo es regulatorisch oder geschäftlich nötig ist

5) Governance: Standards gewinnen gegen Zufall

Governance ist nicht „Verbieten“, sondern Betriebsanleitung:

• Wer darf Sites erstellen?

• Welche Site-Templates gibt es?

• Welche Metadaten sind Pflicht?

• Wie werden Inhalte freigegeben?

• Wer räumt auf?

Konkrete Maßnahmen, die schnell Wirkung bringen

Site-Standards (Minimum Viable Standard)

• Namenskonventionen (z. B. PRJ-2026-… / DEP-HR-…)

• Standard-Bibliotheken (z. B. „Richtlinien“, „Vorlagen“, „Projekte“, „Wissen“)

• Startseiten-Module: „Wichtigste Dokumente“, „Neuigkeiten“, „FAQ“, „Owner/Support“

Content-Typen (damit Dokumente sich wie Dokumente benehmen)

• Content-Type „Richtlinie“: Owner, Status, Gültig bis, Version, Freigabe

• Content-Type „Vorlage“: Zweck, Zielgruppe, letzte Prüfung

• Content-Type „Prozess“: Prozessowner, Schnittstellen, Tools, KPIs

Labeling und Schutz

• Vertraulichkeitskennzeichnungen dort, wo nötig (z. B. Intern, Vertraulich, Streng vertraulich)

• Klare Regeln: Was darf in eine offene Wissensbibliothek, was nicht?

Rollenmodell (klein anfangen, sauber durchziehen)

• Site Owner: verantwortet Struktur und Berechtigungen

• Content Owner: fachlich verantwortlich, entscheidet über Gültigkeit

• Redakteur: pflegt Inhalte, Metadaten, Seiten

• Governance/Compliance: Standards, Audits, Eskalation

• Champion-Netzwerk: Multiplikatoren für Copilot & Intranet

Roadmap 30/60/90 Tage für DACH-Unternehmen

0–30 Tage: Fundament + Quick Wins

• Ist-Aufnahme: Top-20 Wissensquellen, größte Schmerzpunkte, Schattenablagen

• Definition „Copilot-taugliche Bibliothek“ (Standardstruktur + Pflichtmetadaten)

• Pilotbereich auswählen (z. B. IT, HR oder Qualitätsmanagement)

• Berechtigungs-Check: Gruppen statt Einzelrechte, externe Freigaben prüfen

• 2–3 Content-Typen einführen (Richtlinie, Vorlage, FAQ)

• Erste „Wissens-Landingpage“ als Hub: „So finden wir Dinge hier“

Ergebnis: Copilot findet schon bessere Antworten – nicht perfekt, aber spürbar.

31–60 Tage: Skalierung + Governance light

• Site-Templates und Provisioning festziehen (Standardbibliotheken, Navigation, Owner)

• Metadaten-Set erweitern und Pflichtfelder definieren

• Lifecycle-Regeln starten: Review-Datum, Owner-Pflicht, Archivpfad

• Labeling-Regeln in die Praxis bringen (kurze, klare Matrix)

• Schulungsformat: 60 Minuten „Copilot im Intranet“ + 10 Beispielprompts aus dem Alltag

Ergebnis: Aus „Pilot“ wird „Betriebsmodell“.

61–90 Tage: Betrieb, Qualität, Change

• Governance-Board (klein): IT + Fachbereich + Compliance (monatlich 30 Minuten)

• KPI-Set: Suchtrefferqualität, veraltete Inhalte, Owner-Abdeckung, Nutzungszahlen

• Ausbau Champions: 1 pro Bereich, klare Aufgaben (Sprechstunde, Best Practices)

• Content-Cleanup-Wellen: „Altlasten“ pro Bereich priorisiert entsorgen/archivieren

• Copilot-Use-Cases standardisieren: Q&A zu Richtlinien, Onboarding, Projekt-Retros, Angebotsbausteine

Ergebnis: Copilot wird vom Gimmick zum Werkzeug.

Change Management für „KI im Intranet“: pragmatisch statt PowerPoint-Oper

1. Erklären, was Copilot ist (und was nicht)
   Kein Orakel. Kein Wahrheitsministerium. Sondern Assistenz auf Basis vorhandener Inhalte und Rechte.

2. Mit echten Aufgaben starten
   „Fasse diese Richtlinie zusammen“, „Erstelle eine Checkliste“, „Finde den Prozess für…“ – und zwar mit echten Intranet-Links.

3. Vertrauen über Transparenz
   „Woher kommt die Antwort?“ ist Pflicht. Nutzer müssen Quellen prüfen können.

4. Fehlerkultur einplanen
   Antworten können falsch sein. Das ist kein Skandal, sondern ein Arbeitsmodus: prüfen, korrigieren, verbessern.

5. Support nicht vergessen
   Ein kurzer Leitfaden: „Wenn Copilot Unsinn sagt: Was prüfe ich zuerst?“
   (Quelle, Berechtigung, Aktualität, Metadaten, Dubletten)

Fazit

SharePoint ist für Copilot nicht „eine weitere Ablage“. Er ist der Wissensmotorraum. Wenn dort Ordnung herrscht, wird Copilot schnell nützlich. Wenn dort Chaos herrscht, wird Copilot schnell kreativ – und Kreativität ist bei Compliance-Fragen ein sehr teures Hobby.

Mit klaren Site-Standards, Content-Typen, Metadaten, sauberem Berechtigungsmodell und einem realistischen 30/60/90-Tage-Plan bekommen DACH-Unternehmen Copilot im Intranet pragmatisch auf die Straße: mit Mehrwert, weniger Risiko und ohne Governance-Theaterdonner.