KI-Wissen im Unternehmen strukturieren: So arbeiten ChatGPT, Claude und Copilot mit demselben Kontext

Drei Mitarbeitende, drei KI-Systeme, drei Projektstände

Ein mittelständisches B2B-Unternehmen führt ein digitales Kundenportal ein. Kunden sollen darin Aufträge einsehen, Dokumente abrufen und Serviceanfragen stellen können. Marketing entwickelt die Texte, der Vertrieb bringt Anforderungen aus Kundengesprächen ein, der Kundenservice erarbeitet Antworten auf häufige Fragen. Die IT verantwortet Anmeldung, Schnittstellen und Berechtigungen. Datenschutz und Geschäftsführung sind bei einzelnen Entscheidungen eingebunden.

Alle arbeiten bereits mit KI: eine Mitarbeiterin mit ChatGPT, ein Kollege mit Claude, die IT vor allem mit Microsoft 365 Copilot. Jeder hat eigene Unterlagen, Gesprächsnotizen und Prompts hinterlegt. Das wirkt zunächst effizient.

In einer Projektbesprechung fragt die Geschäftsführung: „Welche Funktionen enthält die erste Version des Portals?“ ChatGPT nennt den Rechnungsdownload. Claude beschreibt zusätzlich eine Vertragsverwaltung. Copilot verweist auf einen aktuellen SharePoint-Beschluss, wonach die Vertragsverwaltung erst für eine spätere Ausbaustufe vorgesehen ist.

Alle drei Antworten lassen sich erklären: In einem persönlichen Chat liegt eine alte Wunschliste. In einem Claude-Projekt wurde ein früher Workshopbericht als Projektwissen hinterlegt. In SharePoint wurde später eine Entscheidung dokumentiert. Keine KI kann von allein erkennen, was heute verbindlich gilt, wenn Gültigkeit, Quelle und Status nicht sauber organisiert sind.

Das Beispiel zeigt den eigentlichen Engpass vieler KI-Einführungen. Es fehlt selten an Dateien. Es fehlt an einer verlässlichen Antwort auf fünf Fragen:

• Welche Information gilt für wen?
• Wo liegt die führende Fassung?
• Wer prüft und pflegt sie?
• Wer darf darauf zugreifen?
• Was darf ein KI-System damit tun?

Die Qualität einer KI-Antwort hängt vom Zusammenspiel aus Modell, Arbeitsauftrag und Kontext ab. Für die einzelne Anwendung reicht diese Betrachtung aus. Im Unternehmen kommt eine weitere Aufgabe hinzu: Der Kontext muss organisiert werden. Sonst bekommt ein leistungsfähiges Modell zwar einen guten Prompt, aber trotzdem den falschen Projektstand.

Vier Dinge, die Unternehmen nicht miteinander verwechseln sollten

Im Alltag landen Memory, Wissen, Anweisungen und Berechtigungen oft unter dem Sammelbegriff „KI-Kontext“. Technisch und organisatorisch erfüllen sie aber unterschiedliche Aufgaben.

Knowledge umfasst Informationen, auf die sich die KI bei ihrer Arbeit stützen soll: freigegebene Produktdaten, Prozessbeschreibungen, Richtlinien, Projektentscheidungen oder technische Dokumentation. Dieses Wissen braucht eine verantwortliche Quelle und einen Pflegeprozess.

Instructions steuern das Verhalten des Systems. Sie legen etwa fest, dass eine Antwort auf Deutsch formuliert, eine Entscheidung mit Quellenhinweis dokumentiert oder vor einer externen Veröffentlichung eine Freigabe eingeholt wird. Instructions sind Arbeitsregeln – kein Ort für ständig wechselnde Produktdaten.

Memory sorgt für Kontinuität über einzelne Gespräche hinweg. Auf persönlicher Ebene kann sie Darstellungspräferenzen, wiederkehrende Aufgaben oder individuelle Arbeitsweisen enthalten. Eine persönliche Memory sollte aber keine verbindliche Preisliste und keinen für alle gültigen Projektstatus ersetzen.

Permissions legen technisch fest, worauf ein Nutzer oder Agent zugreifen darf. Eine Anweisung wie „zeige vertrauliche Inhalte nicht an“ ist noch keine Zugriffskontrolle. Geschützte Informationen müssen durch das Quellsystem, den Workspace oder die Identitäts- und Rechteverwaltung geschützt werden.

Hinzu kommen Tools und Actions. Ein Agent, der Dokumente nur lesen darf, hat eine andere Risikoklasse als einer, der E-Mails verschickt, CRM-Daten ändert oder Dateien veröffentlicht. Wissen und Handlungsrechte sollten deshalb getrennt vergeben werden.

Für das Kundenportal bedeutet das konkret:

Diese Trennung wirkt auf den ersten Blick formaler als eine einzelne große Memory-Datei. In der Praxis spart sie Arbeit, weil Informationen nicht an mehreren Stellen gleichzeitig gepflegt und korrigiert werden müssen.

Eine brauchbare Wissensarchitektur besteht aus wenigen Ebenen

Die Struktur muss nicht kompliziert sein. Für viele Unternehmen reichen fünf Kontextebenen und zwei Querschnittsthemen.

Unternehmenswissen

Diese Ebene enthält Informationen, die grundsätzlich für die Organisation gelten: freigegebene Unternehmensdaten, Leistungsbeschreibungen, zentrale Begriffe, Markenregeln, allgemeine Richtlinien und verbindliche Prozesse.

Beim Kundenportal sind das zum Beispiel die offizielle Unternehmensbezeichnung, die aktuelle Leistungsbeschreibung, die Corporate-Design-Vorgaben und allgemeine Regeln zum Umgang mit Kundendaten. Ein Entwurf für eine neue FAQ gehört noch nicht hierher.

Fachbereichswissen

Fachbereichswissen gilt in einem begrenzten Verantwortungsraum. Der Kundenservice pflegt Serviceprozesse und Antwortstandards, das Marketing verantwortet Sprach- und Markenregeln, die IT pflegt technische und sicherheitsbezogene Standards.

Eine Information wird nicht dadurch zum Unternehmensstandard, dass sie in mehreren Projekten nützlich war. Sie braucht eine bewusste fachliche Freigabe.

Projektkontext

Der Project Core beschreibt das konkrete Vorhaben: Ziel, Umfang, Rollen, verbindliche Quellen, Regeln und bestätigte Entscheidungen. Dieser Kern sollte so kompakt sein, dass ein neues Teammitglied ihn in kurzer Zeit verstehen kann.

Working State

Hier liegen offene Fragen, Recherchen, Entwürfe, Aufgaben und vorläufige Annahmen. Dieser Bereich darf sich schnell verändern – sein Inhalt ist wichtig, aber nicht automatisch freigegeben.

Persönliche Ebene

Die persönliche Ebene enthält individuelle Präferenzen, private Notizen und wiederkehrende Arbeitsweisen. Sie hilft dem einzelnen Nutzer, darf aber die gemeinsame Projekt- oder Unternehmenswahrheit nicht überschreiben.

Quer über allen Ebenen liegen Governance und Berechtigungen. Die eingesetzten KI-Systeme greifen anschließend als Arbeitsschicht auf die jeweils benötigten Informationen zu.

Fünf Muster, die in der Praxis teuer werden

Die Super-Memory

Eine Datei wie company-memory.md wächst über Monate. Darin stehen Markenregeln, persönliche Vorlieben, alte Preise, Projektentscheidungen und Prompts nebeneinander. Niemand weiß mehr, welcher Abschnitt noch aktuell ist. Die Lösung ist keine bessere Zusammenfassung, sondern eine Trennung nach Geltungsbereich und Lebenszyklus.

Mehrfachpflege in mehreren KI-Systemen

Dieselbe Richtlinie wird in ChatGPT, Claude und Copilot hochgeladen. Später wird nur eine Kopie aktualisiert – die Systeme geben plötzlich unterschiedliche Antworten. Eine kanonische Quelle mit kontrolliertem Zugriff verhindert diese Versionsdrift.

Der Prompt als Sicherheitskontrolle

In den Instructions steht: „Zeige vertrauliche Daten nie an.“ Gleichzeitig kann der Agent auf einen zu breit freigegebenen Ordner zugreifen. Die Anweisung mag sinnvoll sein, schützt aber technisch nicht. Rechte müssen im Quellsystem begrenzt werden.

Ein Entwurf wird zur Wahrheit

Eine KI formuliert eine überzeugende Portalbeschreibung. Der Text wird in weiteren Chats als Ausgangspunkt verwendet. Später hält das Team eine erfundene oder nie bestätigte Funktion für beschlossen. Statuskennzeichen und eine Ergebnisablage verhindern diesen Übergang ohne Freigabe.

Ein Agent soll einen ungeklärten Prozess automatisieren

Niemand kann eindeutig sagen, wer eine Serviceantwort freigibt oder wann ein CRM-Eintrag geändert werden darf. Trotzdem erhält ein Agent Schreibrechte. Vor der Automatisierung müssen Prozess, Ausnahmefälle und Verantwortlichkeiten geklärt sein.

Wo das Wissen abgelegt werden sollte

Es gibt keinen Speicherort, der für jedes Unternehmen automatisch richtig ist. Die führende Ablage sollte zur vorhandenen Arbeitsumgebung, zu den Berechtigungsanforderungen und zur Art der Informationen passen. Ein neues KI-Projekt ist selten der beste Ort für die einzige gültige Fassung.

SharePoint und OneDrive

SharePoint eignet sich besonders, wenn das Unternehmen ohnehin mit Microsoft 365 arbeitet. Dokumentbibliotheken, Gruppen, Sites, Versionierung und Berechtigungen sind bereits vorhanden. Copilot kann direkt auf diese Umgebung aufsetzen, und auch andere KI-Systeme können je nach Produkt, Workspace und Freigabe über Apps oder Connectoren auf ausgewählte Inhalte zugreifen.

Für unternehmensweite Inhalte sollte eine eigene, verantwortete SharePoint-Site oder Dokumentbibliothek verwendet werden. Persönliche OneDrive-Ordner sind keine gute dauerhafte Heimat für gemeinsames Unternehmenswissen: Verlässt der Besitzer das Unternehmen oder ändern sich Freigaben, entstehen unnötige Abhängigkeiten.

Eine mögliche Struktur:

 Unternehmenswissen/
├── 00_Index_und_Verantwortung/
├── 10_Unternehmensbasis/
├── 20_Marke_und_Kommunikation/
├── 30_Fachbereiche/
├── 40_Aktive_Projekte/
├── 80_Referenzen/
└── 99_Archiv/ 

Sensible Bereiche erhalten eigene Bibliotheken oder Sites, wenn sich ihre Berechtigungen deutlich vom übrigen Bestand unterscheiden. Komplexe Einzelberechtigungen tief in einem großen Ordnerbaum sind schwer zu überblicken.

Google Drive

Unternehmen mit Google Workspace sollten gemeinsames Wissen in Shared Drives statt in persönlichen „My Drive“-Bereichen führen. Dateien in einem Shared Drive gehören der Organisation und bleiben erhalten, wenn ein Mitarbeiter das Unternehmen verlässt. Google unterscheidet Rollen wie Manager, Content Manager, Contributor, Commenter und Viewer. Einschränkungen für externe Freigaben, Download, Kopieren und Drucken lassen sich auf Ebene des Shared Drive steuern.

Auch hier lohnt sich eine Trennung nach Geltungsbereich:

 Shared Drive: Unternehmenswissen
├── 00_Index
├── 10_Company_Core
├── 20_Brand
└── 30_Unternehmensprozesse
Shared Drive: Kundenportal-Projekt
├── 00_Project_Core
├── 10_Working
└── 20_Results 

Ein eigener Shared Drive für das gesamte Unternehmen und für jedes sensible Projekt ist nicht zwingend nötig. Die Struktur sollte den tatsächlichen Rollen folgen. Brauchen Marketing, IT und externe Dienstleister unterschiedliche Zugriffe, sind getrennte Bereiche meist verständlicher als viele Ausnahmen innerhalb eines einzigen Drives.

Dokumentenmanagementsystem, Wiki oder Intranet

Ein DMS lohnt sich, wenn Freigaben, Aufbewahrung, Dokumentklassen oder revisionsrelevante Vorgänge im Vordergrund stehen. Ein Wiki eignet sich für vernetztes, häufig gelesenes und gemeinschaftlich gepflegtes Wissen. Intranet-Seiten sind gut für freigegebene Informationen, die viele Mitarbeitende schnell finden sollen.

Viele Unternehmen kombinieren Systeme: Der Vertrag liegt im DMS, die technische Betriebsdokumentation im Wiki, die aktuelle Projektarbeit in SharePoint. Das ist kein Fehler, solange der Quellenindex eindeutig zeigt, welches System für welches Thema führt.

Git und Repositorys

Git eignet sich für textbasierte, technische Inhalte, bei denen Änderungen überprüft, verglichen und gemeinsam freigegeben werden sollen. AGENTS.md , CLAUDE.md , technische Standards und Dokumentation können dort gut liegen. Ein Repository ist dagegen kein guter allgemeiner Ablageort für Personalakten, Verträge, große Office-Dokumente oder Unternehmenslogos, die normale Mitarbeitende ohne Entwicklerwerkzeuge nutzen sollen.

Die Entscheidung in einer Tabelle

Die wichtigste Regel: Eine Information wird möglichst nur an einer Stelle verbindlich gepflegt. Andere Systeme erhalten einen Link, einen berechtigten Zugriff oder eine kontrollierte, als Kopie erkennbare Projektausgabe.

Bevor Wissen in ein KI-System gelangt: Datenschutz und rechtliche Prüfung

Eine saubere Ordnerstruktur beantwortet noch nicht die Frage, ob ein Unternehmen bestimmte Daten in einem KI-Dienst verarbeiten darf. Für ein deutsches Unternehmen beginnt der Rollout deshalb mit einer Daten- und Vertragsprüfung. Kundendaten, Beschäftigtendaten, vertrauliche Vertragsinhalte oder besondere Kategorien personenbezogener Daten gehören nicht versuchsweise in private Einzelkonten, nur weil der Upload technisch möglich ist.

Vor dem ersten produktiven Einsatz sollte das Unternehmen sieben Punkte klären:

1. Zweck und Datenarten: Welche konkrete Aufgabe soll die KI unterstützen? Welche personenbezogenen, vertraulichen oder geschäftskritischen Daten werden dabei verarbeitet?
2. Freigegebener Dienst und Kontotyp: Welcher Unternehmens-Workspace ist zugelassen? Private Free-, Pro- oder Einzelkonten sind keine Ersatzlösung für fehlende Unternehmensverträge, zentrale Administration und verbindliche Einstellungen.
3. Rollen und Vertrag: Handelt der Anbieter für diesen Einsatz als Auftragsverarbeiter, muss die vertragliche Grundlage einschließlich Vereinbarung zur Auftragsverarbeitung geprüft werden. Die DSGVO nennt hierfür insbesondere Artikel 28.
4. Speicherort und Drittlandtransfer: Wo werden Eingaben, Dateien, Ausgaben, Protokolle und Backups gespeichert oder verarbeitet? Welche Unterauftragnehmer, Transfermechanismen und Löschfristen gelten? „EU-Region“ heißt nicht automatisch, dass jede Verarbeitung ausschließlich in der EU stattfindet.
5. Training und Produktverbesserung: Nutzt der Anbieter Unternehmensinhalte zum Training oder zur Produktverbesserung? Welche Voreinstellung gilt für genau den gebuchten Tarif, und welche Ausnahmen entstehen etwa durch Feedback, externe Apps oder freiwillige Freigaben?
6. Schutzbedarf und Folgenabschätzung: Reichen Datenminimierung, Pseudonymisierung, Berechtigungen, Protokollierung und Löschkonzept aus? Bei voraussichtlich hohem Risiko ist zu prüfen, ob eine Datenschutz-Folgenabschätzung nach Artikel 35 DSGVO erforderlich ist.
7. Weitere Beteiligte: Je nach Einsatz gehören Datenschutz, Informationssicherheit, Compliance und gegebenenfalls der Betriebsrat früh in die Prüfung. Das gilt besonders, wenn KI Leistungen, Verhalten oder Kommunikation von Beschäftigten auswertet.

Die Hersteller unterscheiden sich und ändern ihre Leistungen laufend. OpenAI schließt Inhalte aus Business-, Enterprise- und Edu-Workspaces standardmäßig vom Modelltraining aus; Möglichkeiten und Grenzen von Daten- und Inferenzresidenz hängen vom Tarif und von der Konfiguration ab. Anthropic schließt Inhalte kommerzieller Angebote wie Claude for Work standardmäßig vom Training aus, weist aber darauf hin, dass Daten kommerzieller Dienste standardmäßig in den USA gespeichert werden können und Traffic international verarbeitet werden kann, sofern nichts anderes vereinbart ist. Microsoft beschreibt für Copilot mit Enterprise Data Protection, dass Prompts und Antworten nicht zum Training der zugrunde liegenden Foundation Models verwendet werden. Diese Aussagen ersetzen keine eigene Vertrags- und Konfigurationsprüfung.

Hinzu kommt der EU AI Act. Unternehmen, die KI einsetzen, müssen unter anderem Maßnahmen zur Förderung der KI-Kompetenz der beteiligten Personen vorsehen. Je nach Anwendungsfall können weitere Transparenz-, Dokumentations- oder Risikopflichten greifen. Ein Textassistent für interne Entwürfe ist anders zu bewerten als ein System, das Beschäftigte beurteilt oder Entscheidungen über Personen vorbereitet. Die konkrete Einordnung gehört in den Freigabeprozess des Unternehmens; dieser Beitrag ersetzt keine Rechtsberatung.

So kann eine konkrete Datei- und Ordnerstruktur aussehen

Markdown-Dateien sind für solche Strukturen praktisch: einfach lesbar, durchsuchbar und versionierbar. Sie funktionieren auch dann noch, wenn das Unternehmen später das KI-System wechselt. Markdown ist allerdings kein Muss – dieselbe Logik lässt sich genauso in SharePoint-Seiten, einem Wiki, einem Dokumentenmanagementsystem oder einer gut gepflegten Ordnerstruktur abbilden.

Ein möglicher Unternehmensbereich sieht so aus:

 AI_Company_Core/
├── 00_INDEX.md
├── 10_Governance/
│   ├── ai-policy.md
│   ├── data-classification.md
│   └── agent-publishing.md
├── 20_Company_Knowledge/
│   ├── company-facts.md
│   ├── terminology.md
│   ├── services.md
│   └── company-processes.md
├── 30_Brand/
│   ├── brand-guidelines.md
│   ├── Logos/
│   └── Templates/
├── 40_Departments/
│   ├── Marketing/
│   ├── Sales/
│   ├── Service/
│   └── IT/
└── 50_Projects/
    └── Kundenportal/ 

Persönliche Memory liegt bewusst nicht in diesem gemeinsamen Baum. Sie gehört zum Benutzerkonto oder in einen ausdrücklich persönlichen Arbeitsbereich.

Der Projektordner wird weiter unterteilt:

 Kundenportal/
├── 00_PROJECT_INDEX.md
├── 01_PROJECT_BRIEF.md
├── 02_SOURCE_INDEX.md
├── 03_DECISIONS.md
├── 04_RULES.md
├── 05_STATUS.md
├── 10_WORKING/
│   ├── faq-entwurf.md
│   ├── recherche-authentifizierung.md
│   └── offene-fragen.md
└── 20_RESULTS/
    ├── freigegebene-portaltexte.md
    └── fachkonzept-v1.md 

Die Nummerierung ist optional. Sie sorgt lediglich dafür, dass Kerninformationen in einer verständlichen Reihenfolge erscheinen.

Was in den einzelnen Markdown-Dateien steht

Eine gute Datei braucht keine komplizierte technische Syntax. Eine Überschrift, wenige Metadaten und eine klare Gliederung reichen meist aus.

Praktisch entsteht eine Markdown-Datei in drei Schritten: Zuerst legt das Team die Datei in einem einfachen Texteditor oder einem für Markdown geeigneten Editor an. Dann wird der folgende Musterinhalt hineinkopiert und mit den eigenen Angaben ausgefüllt. Gespeichert wird als UTF-8-Datei mit der Endung .md , zum Beispiel 01_PROJECT_BRIEF.md . Anschließend kommt sie in den vorgesehenen Projektordner in SharePoint, Google Drive, Git oder dem gewählten Wissenssystem. Wer Markdown-Dateien dort nicht komfortabel bearbeiten kann, pflegt dieselbe Struktur als SharePoint-Seite, Wiki-Seite oder Dokumentvorlage. Entscheidend ist die Informationslogik, nicht die Dateiendung.

Für nicht technische Teams lohnt sich ein kleiner Vorlagenordner mit leeren, freigegebenen Mustern für Projektbriefing, Quellenindex, Entscheidungen, Regeln und Status. Neue Projekte kopieren nur diese fünf Vorlagen. So muss niemand die Struktur jedes Mal neu erfinden, und die Dateien bleiben trotzdem überschaubar.

Der Index: Orientierung statt Wissensmonolith

00_PROJECT_INDEX.md zeigt, welche Dateien vorhanden sind und wofür sie verwendet werden. Er enthält nicht den gesamten Projektinhalt.

 ---
Projekt: Digitales Kundenportal
Owner: Projektleitung
Status: aktiv
Letztes Review: 2026-09-12
Nächstes Review: 2026-09-26
---
# Projektindex
## Verbindlicher Kern
| Datei | Zweck | Verantwortlich |
|---|---|---|
| 01_PROJECT_BRIEF.md | Ziel, Umfang und Rollen | Projektleitung |
| 02_SOURCE_INDEX.md | Führende Quellen | Projektleitung und IT |
| 03_DECISIONS.md | Bestätigte Entscheidungen | Projektleitung |
| 04_RULES.md | Arbeits- und Qualitätsregeln | jeweiliger Fachowner |
| 05_STATUS.md | Aktueller Gesamtstand | Projektleitung |
## Arbeitsstände
Entwürfe und offene Recherchen liegen unter `10_WORKING`.
Sie sind nicht automatisch freigegeben.
## Ergebnisse
Nur bestätigte Ergebnisse liegen unter `20_RESULTS`. 

Der Index verhindert, dass ein Mitarbeiter oder ein KI-System raten muss, welche Datei die aktuelle Entscheidung enthält.

Das Projektbriefing: Was soll erreicht werden?

01_PROJECT_BRIEF.md bleibt relativ stabil und enthält keine tägliche Aufgabenliste.

 ---
Owner: Anna Beispiel, Projektleitung
Status: freigegeben
Version: 1.2
Letztes Review: 2026-09-10
---
# Digitales Kundenportal
## Ziel
Bestandskunden sollen Aufträge und freigegebene Dokumente
selbstständig einsehen und Serviceanfragen übermitteln können.
## Umfang der ersten Version
- Anmeldung für bestehende Kunden
- Übersicht laufender Aufträge
- Download freigegebener Dokumente
- Formular für Serviceanfragen
## Nicht Bestandteil der ersten Version
- Vertragsverwaltung
- Onlinebestellung
- Zahlungsabwicklung
## Rollen
- Projektleitung: koordiniert und bestätigt den Projektstatus
- IT: verantwortet Architektur, Integration und Sicherheit
- Service: verantwortet Serviceprozesse und FAQ-Inhalte
- Marketing: verantwortet Sprache, Struktur und Portaltexte
- Datenschutz: prüft datenschutzrelevante Verarbeitung
## Erfolgskriterien
- Ein Testkunde findet einen freigegebenen Auftrag und ein Dokument.
- Serviceanfragen erreichen den vorgesehenen Prozess.
- Nutzer sehen ausschließlich die für sie freigegebenen Inhalte. 

Das Beispiel trennt Ziel, Umfang und Nicht-Ziele. Dadurch kann eine KI eine kreative Funktionsidee als Vorschlag kennzeichnen, statt sie versehentlich als beschlossene Projektleistung darzustellen.

Der Quellenindex: Wo liegt die Wahrheit?

02_SOURCE_INDEX.md enthält Verweise auf führende Quellen. Große oder sensible Inhalte müssen nicht in die Markdown-Datei kopiert werden.

 # Verbindliche Quellen
| Thema | Führende Quelle | Owner | Zugriff | Aktualität |
|---|---|---|---|---|
| Leistungsumfang V1 | 01_PROJECT_BRIEF.md | Projektleitung | Portalteam | aktuell |
| Kundendaten | CRM | Vertrieb/IT | rollenbasiert | live |
| Datenschutzprüfung | Freigabevermerk im DMS | Datenschutz | eingeschränkt | 2026-09-11 |
| Portaltexte | 20_RESULTS/freigegebene-portaltexte.md | Marketing | Portalteam | Version 1.0 |
| Technische Architektur | SharePoint/Fachkonzept | IT | IT und Projektleitung | Version 2.1 |
## Konfliktregel
Bei widersprüchlichen Angaben gilt die im Quellenindex als führend
markierte Quelle. Konflikte werden an die Projektleitung gemeldet
und nicht durch die KI selbst aufgelöst. 

Dieser Index ist besonders wichtig, wenn Wissen in CRM, SharePoint, Teams und Fachanwendungen verteilt ist.

Das Entscheidungsprotokoll: Beschlüsse mit Kontext

03_DECISIONS.md sollte nicht nur das Ergebnis nennen. Datum, Verantwortliche und Auswirkung machen die Entscheidung später nachvollziehbar.

 # Bestätigte Entscheidungen
## DEC-007 – Vertragsverwaltung erst nach Version 1
- Datum: 2026-09-12
- Status: bestätigt
- Entscheider: Projektleitung und Geschäftsführung
- Anlass: Aufwandsschätzung und Abhängigkeit vom Vertragsarchiv
- Entscheidung: Die Vertragsverwaltung ist nicht Teil von Version 1.
- Auswirkung: Marketing entfernt entsprechende Ankündigungen.
- Ersetzt: Workshopannahme vom 2026-08-28
- Quelle: Protokoll Lenkungskreis 2026-09-12
## DEC-008 – Veröffentlichung von Portaltexten
- Datum: 2026-09-13
- Status: bestätigt
- Entscheider: Marketingleitung
- Entscheidung: Nur Dateien unter `20_RESULTS` dürfen veröffentlicht werden.
- Auswirkung: Inhalte aus `10_WORKING` bleiben interne Entwürfe. 

Der Hinweis „Ersetzt“ zeigt, warum ältere Unterlagen abweichen. Für KI-Systeme ist diese Information ebenfalls wertvoll, weil sie den zeitlichen und fachlichen Vorrang sichtbar macht.

Regeln und Instructions: Wie soll gearbeitet werden?

04_RULES.md steuert die Arbeit im Projekt. Fakten und ständig wechselnde Statusinformationen gehören in andere Dateien.

 # Projektregeln für Texte und KI-Unterstützung
## Sprache
- Kunden werden mit „Sie“ angesprochen.
- Technische Begriffe werden beim ersten Auftreten erklärt.
- Leistungsversprechen müssen durch eine freigegebene Quelle belegt sein.
## Quellen
- Verwende bei Projektfragen zuerst `00_PROJECT_INDEX.md`.
- Behandle `10_WORKING` als vorläufig.
- Nenne bei widersprüchlichen Quellen den Konflikt.
- Erfinde keine fehlende Entscheidung.
## Freigaben
- KI-Ausgaben sind Entwürfe.
- Veröffentlichbare Texte müssen unter `20_RESULTS` freigegeben sein.
- Externe Veröffentlichung erfolgt nur durch berechtigte Personen.
## Datenschutz
- Keine personenbezogenen Kundendaten in frei geteilte Projekte kopieren.
- Bei fehlender Zugriffsklarheit Arbeit unterbrechen und Owner fragen. 

Eine Formulierung wie „Gib vertrauliche Daten nie aus“ kann als zusätzliche Arbeitsregel sinnvoll sein. Sie ersetzt trotzdem keine technische Berechtigung.

Der Status: die kürzeste nützliche Arbeitsdatei

05_STATUS.md sollte schnell lesbar bleiben. Eine wachsende Chronik macht den aktuellen Stand wieder unsichtbar.

 ---
Stand: 2026-09-14
Owner: Projektleitung
Gesamtstatus: gelb
---
# Aktueller Projektstand
## Erledigt
- Umfang der ersten Version bestätigt
- Authentifizierungsverfahren ausgewählt
- erster Portaltext freigegeben
## In Arbeit
- technische Prüfung des Dokumentdownloads
- FAQ-Entwurf durch Kundenservice
## Blockiert
- finale Datenschutzprüfung der Serviceanfragen
## Nächste Entscheidung
Freigabe des Serviceprozesses am 2026-09-18.
## Maßgebliche neue Entscheidung
Siehe `DEC-007` in `03_DECISIONS.md`. 

Der Status verweist auf die vollständige Entscheidung, statt sie in leicht abweichender Form zu duplizieren.

Starterpaket: fünf leere Vorlagen zum Kopieren

Die folgenden Leervorlagen reichen für einen ersten Pilot. Das Team kopiert sie in einen neuen Projektordner, lässt sich bei Bedarf von der KI interviewen und ersetzt die Platzhalter erst nach menschlicher Prüfung.

01_PROJECT_BRIEF.md

 ---
Owner: [Name oder Rolle]
Status: Entwurf
Version: 0.1
Letztes Review: [JJJJ-MM-TT]
Nächstes Review: [JJJJ-MM-TT]
---
# [Projektname]
## Ziel
[Welches konkrete Problem soll gelöst werden?]
## Umfang
- [Bestandteil 1]
## Nicht-Ziele
- [ausdrücklich nicht enthalten]
## Rollen
- Projektleitung: [Name oder Rolle]
- Fachowner: [Name oder Rolle]
- Freigabe: [Name oder Rolle]
## Erfolgskriterien
- [beobachtbares Ergebnis]
## Offene Punkte
- OFFEN: [Frage und Verantwortlicher] 

02_SOURCE_INDEX.md

 # Verbindliche Quellen
| Thema | Führende Quelle | Owner | Zugriff | Stand |
|---|---|---|---|---|
| [Thema] | [Link oder Pfad] | [Rolle] | [Gruppe] | [Version/Datum] |
## Konfliktregel
Bei Widersprüchen gilt die hier als führend markierte Quelle.
Die KI zeigt den Konflikt an und entscheidet ihn nicht selbst. 

03_DECISIONS.md

 # Bestätigte Entscheidungen
## DEC-[Nummer] – [Kurztitel]
- Datum: [JJJJ-MM-TT]
- Status: [vorgeschlagen/bestätigt/ersetzt]
- Entscheider: [Name oder Rolle]
- Anlass: [Warum war die Entscheidung nötig?]
- Entscheidung: [verbindlicher Beschluss]
- Auswirkung: [Was ändert sich konkret?]
- Ersetzt: [ältere Aussage oder keine]
- Quelle: [Protokoll, Ticket oder Link] 

04_RULES.md

 # Projektregeln
## Geltungsbereich
[Für welche Aufgaben und Personen gelten diese Regeln?]
## Sprache und Qualität
- [Regel]
## Quellen
- Führende Quellen stehen in `02_SOURCE_INDEX.md`.
- Arbeitsstände gelten als vorläufig.
- Fehlende Entscheidungen werden nicht erfunden.
## Freigaben
- [Wer prüft welches Ergebnis?]
- Externe Veröffentlichung nur durch berechtigte Personen.
## Daten und Berechtigungen
- [Welche Daten dürfen verwendet werden?]
- [Welche Daten sind ausgeschlossen?] 

05_STATUS.md

 ---
Stand: [JJJJ-MM-TT]
Owner: [Name oder Rolle]
Gesamtstatus: [grün/gelb/rot]
---
# Aktueller Projektstand
## Erledigt
- [Punkt]
## In Arbeit
- [Punkt und Verantwortlicher]
## Blockiert
- [Hindernis und benötigte Entscheidung]
## Nächster Schritt
[konkrete Aktion, Owner und Termin]
## Maßgebliche neue Entscheidung
[Verweis auf DEC-Nummer oder keine] 

Ein optionaler 00_PROJECT_INDEX.md verlinkt diese fünf Dateien und die Ordner für Arbeitsstände und Ergebnisse. Er wird besonders dann nützlich, wenn weitere Dokumente hinzukommen.

Unternehmenslogo, Farben und Textreferenzen richtig organisieren

Markenassets zeigen sehr anschaulich, warum Wissen, Dateien, Regeln und Berechtigungen getrennt werden müssen. Ein Logo besteht nicht nur aus der Information „Unser Logo ist blau“ – Mitarbeitende und KI-Systeme brauchen die echte, freigegebene Datei.

Ein sinnvoller Markenbereich kann so aufgebaut sein:

 Brand/
├── 00_BRAND_INDEX.md
├── 10_Guidelines/
│   ├── brand-guidelines.md
│   ├── colors.md
│   ├── typography.md
│   ├── writing-style.md
│   └── document-rules.md
├── 20_Logos/
│   ├── 00_Master/
│   │   ├── company-logo-primary.svg
│   │   └── company-logo-primary.pdf
│   ├── 10_Office_PNG/
│   ├── 20_Dark_Background/
│   └── 30_Icons/
├── 30_Templates/
│   ├── presentation-template.pptx
│   ├── document-template.docx
│   └── social-template/
├── 40_Reference_Texts/
│   ├── approved-website-examples.md
│   └── approved-customer-texts.md
└── 99_Legacy/ 

00_BRAND_INDEX.md erklärt, welche Datei für welchen Einsatz vorgesehen ist:

 ---
Owner: Brand Management
Status: freigegeben
Letztes Review: 2026-09-01
Gültigkeitsbereich: gesamtes Unternehmen
---
# Markenindex
## Verbindliches Hauptlogo
- Vektor-Master: `20_Logos/00_Master/company-logo-primary.svg`
- Office-Version: `20_Logos/10_Office_PNG/company-logo-primary.png`
- Dunkler Hintergrund: `20_Logos/20_Dark_Background/company-logo-white.png`
## Einsatzregeln
- Originaldatei verwenden und nicht nachzeichnen.
- Seitenverhältnis nicht verändern.
- Keine neuen Farbvarianten erzeugen.
- Für neue Dokumente die freigegebenen Vorlagen verwenden.
- Dateien unter `99_Legacy` sind nur für historische Dokumente bestimmt.
## Farben
Verbindliche Farbwerte stehen in `10_Guidelines/colors.md`.
## Sprache
Sprachregeln stehen in `10_Guidelines/writing-style.md`.
Nur die unter `40_Reference_Texts` freigegebenen Texte dienen als Stilreferenz. 

Die eigentlichen Farbangaben stehen separat:

 # Unternehmensfarben
| Name | HEX | RGB | Einsatz |
|---|---|---|---|
| Primärblau | #123456 | 18, 52, 86 | Überschriften und Kernflächen |
| Akzentfarbe | #00AACC | 0, 170, 204 | sparsame Hervorhebung |
## Regeln
- Keine ähnlichen Farbwerte aus Screenshots entnehmen.
- Für Druckdaten die freigegebenen CMYK-Werte der Druckvorlage nutzen.
- Kontraste vor Veröffentlichung prüfen. 

Die Werte im Beispiel sind Platzhalter. Im echten Unternehmen werden ausschließlich die bestätigten Farbwerte eingetragen.

Für Textreferenzen gilt dieselbe Sorgfalt. Ein Ordner mit zufälligen alten Texten ist keine Stilbibliothek. Als Referenz sollten nur freigegebene, fachlich passende Beispiele dienen, jeweils mit einem kurzen Hinweis, für welchen Kanal und welche Zielgruppe der Text geeignet ist.

Technisch lässt sich die Nutzung über mehrere Ebenen absichern:

1. Der Brand Owner hat Änderungsrechte auf Richtlinien und Masterassets.
2. Mitarbeitende und Agents erhalten für Masterassets normalerweise Leserechte.
3. Veraltete Logos werden aus dem aktiven Bereich entfernt und als Legacy gekennzeichnet.
4. Projekt-Instructions verlangen ausdrücklich die Verwendung der Originaldatei.
5. Vorlagen enthalten das Logo bereits an der richtigen Stelle.
6. Eine Design- oder Veröffentlichungsprüfung kontrolliert Datei, Variante, Farbe und Seitenverhältnis.

Eine passende KI-Anweisung lautet:

 Verwende für Unternehmensmaterialien ausschließlich die im Brand Index
genannten Originalassets und Vorlagen. Rekonstruiere kein Logo mit einem
Bildmodell und entnimm keine Farben aus Screenshots. Wenn das benötigte
Originalasset nicht zugänglich ist, kennzeichne die Produktion als blockiert
und frage nach der freigegebenen Datei. 

Diese Anweisung verhindert zwar viele Fehlversuche. Die stärkere Absicherung entsteht aber durch Leserechte auf die richtigen Assets, eingeschränkte Änderungsrechte, klare Vorlagen und eine Prüfung vor der Veröffentlichung.

Die Dateien müssen nicht von Hand am leeren Bildschirm entstehen

Viele Unternehmen wissen, dass sie ihre Informationen strukturieren sollten. Der praktische Start scheitert oft daran, dass niemand eine leere PROJECT_BRIEF.md ausfüllen möchte. Genau hier kann KI helfen: als Interviewer und Redakteur.

Ein Projektleiter kann ChatGPT, Claude oder Copilot mit einem Auftrag wie diesem starten:

 Du hilfst mir, ein belastbares Projektbriefing zu erstellen.
Stelle mir immer nur eine Frage. Beginne mit Ziel und Anlass,
danach folgen Umfang, Nicht-Ziele, Beteiligte, Rollen,
verbindliche Quellen, sensible Informationen, Freigaben,
Risiken und Erfolgskriterien.
Übernimm keine Vermutung als Tatsache. Wenn meine Antwort unklar
oder widersprüchlich ist, frage konkret nach. Kennzeichne offene
Punkte als OFFEN.
Erstelle erst nach Abschluss des Interviews einen Markdown-Entwurf.
Nutze dafür die Abschnitte Metadaten, Ziel, Umfang, Nicht-Ziele,
Rollen, Quellen, Berechtigungen, Erfolgskriterien und offene Punkte.
Zeige mir den vollständigen Entwurf zur Prüfung. Speichere oder
veröffentliche nichts selbstständig. 

Das Interview kann mit einer einfachen Frage beginnen: „Welches konkrete Problem soll das Kundenportal für Kunden und Mitarbeitende lösen?“ Danach arbeitet sich das System Frage für Frage vor.

Gute Nachfragen wären zum Beispiel:

• Woran erkennen Sie, dass die erste Version ausreichend ist?
• Welche Funktion wird häufig genannt, ist aber ausdrücklich noch nicht beschlossen?
• Wer darf den Projektumfang verbindlich ändern?
• Welche Quelle enthält den aktuell bestätigten Leistungsumfang?
• Welche Informationen dürfen nicht in einen gemeinsam geteilten KI-Arbeitsraum gelangen?
• Wer prüft einen von der KI erstellten Portaltext vor der Veröffentlichung?

Das System sammelt damit keine beliebige Materialmenge, sondern klärt Gültigkeit und Verantwortung. Der Mensch prüft anschließend jeden Eintrag. Aus „wahrscheinlich macht das die IT“ sollte im Dokument kein fest zugewiesener Owner werden.

Aus vorhandenen Unterlagen einen Quellenindex erstellen

Auch eine vorhandene Ordnerstruktur lässt sich interviewgestützt aufarbeiten:

 Analysiere die bereitgestellte Dateiliste noch nicht inhaltlich.
Ordne zunächst jede Datei einer Kategorie zu:
1. mögliche verbindliche Quelle
2. Arbeitsstand oder Entwurf
3. historisch oder ersetzt
4. unklar
Frage mich anschließend bei jeder möglichen verbindlichen Quelle
nach Owner, Status, letztem Review, Berechtigungsbedarf und der
Frage, welche ältere Quelle sie ersetzt.
Erstelle daraus einen Entwurf für `02_SOURCE_INDEX.md`.
Verschiebe, lösche oder überschreibe keine Datei. 

Diese Vorgehensweise ist sicherer als der Auftrag „Räume unseren Projektordner auf“. Die KI bereitet die Entscheidung vor. Sie verändert den Bestand erst, wenn Ziel, Regeln und Freigabe eindeutig sind.

Entscheidungen aus Protokollen vorbereiten

Besprechungsprotokolle enthalten häufig Beschlüsse, Prüfaufträge und lose Ideen nebeneinander. Eine KI kann Kandidaten extrahieren:

 Lies das Protokoll und trenne:
- ausdrücklich bestätigte Entscheidungen
- vorgeschlagene, aber noch offene Optionen
- Aufgaben mit Verantwortlichen und Termin
- Annahmen ohne Bestätigung
- Widersprüche zu den bereitgestellten Projektquellen
Formuliere nur ausdrücklich bestätigte Entscheidungen als Entwurf
für `03_DECISIONS.md`. Führe alle anderen Punkte separat auf.
Frage bei Unklarheit nach und erfinde keine Freigabe. 

Die verantwortliche Person bestätigt anschließend, was tatsächlich in das Entscheidungsprotokoll übernommen wird.

Persönliche Arbeitspräferenzen ermitteln

Auch die persönliche Ebene lässt sich über ein Interview aufbauen – nur mit anderen Fragen:

• Welche Form von Zusammenfassungen hilft Ihnen?
• Welche wiederkehrenden Aufgaben bearbeiten Sie mit KI?
• Welche Begriffe oder Formate sollen beibehalten werden?
• Welche Informationen sind nur für Ihre persönliche Arbeitsweise relevant?
• Welche Angaben gehören ausdrücklich nicht in eine persönliche Memory?

Eine persönliche Memory darf etwa enthalten, dass ein Nutzer Entscheidungsoptionen mit einer klaren Empfehlung bevorzugt. Der aktuelle Projektumfang oder ein Kundenpreis gehört dagegen in die gemeinsame Quelle.

Wie der Aufbau in ChatGPT, Claude und Copilot praktisch aussieht

Die Architektur bleibt herstellerunabhängig. Die Umsetzung unterscheidet sich aber je nach Plattform und vorhandener Unternehmenslandschaft.

Für einen Einzeltest reichen oft persönliche Pläne oder vorhandene Testzugänge. Gemeinsame Projekte, zentrale Rollensteuerung, administrative Apps, Datenresidenz und organisationsweite Agents setzen je nach Hersteller jedoch verwaltete Business-, Team-, Enterprise- oder Microsoft-365-Lizenzen voraus. Das Zielbild lässt sich mit einem Einzelkonto erproben, die Unternehmensgovernance aber nicht vollständig. Vor dem Pilot sollte deshalb eine Person die aktuell gebuchten Tarife und tatsächlich verfügbaren Adminfunktionen dokumentieren.

ChatGPT

In ChatGPT können Projekte Chats, Dateien und Projektanweisungen bündeln. Für das Kundenportal kann ein Projekt eingerichtet werden, in dem das geprüfte Projektbriefing, der Quellenindex, die Regeln und relevante Arbeitsdateien liegen. Ein geteiltes Projekt wird zum gemeinsamen Arbeitsraum; OpenAI beschreibt dafür projektbezogene Memory-Grenzen.

Praktisch sollte das Team festlegen:

• Welche Dateien dürfen in das Projekt übernommen werden?
• Wer aktualisiert sie, wenn sich die führende Quelle ändert?
• Welche Mitglieder können alle Projektinhalte sehen und herunterladen?
• Welche Ergebnisse müssen zurück in SharePoint, DMS oder ein anderes führendes System?

Ein Chat im Projekt eignet sich für die Erarbeitung eines FAQ-Entwurfs. Die Freigabe wird anschließend in der kanonischen Ablage dokumentiert – erst die freigegebene Fassung kommt in 20_RESULTS oder die entsprechende Unternehmensquelle.

Für unternehmensweite Quellen können je nach Workspace angebundene Apps oder Company-Knowledge-Funktionen eine Alternative zum wiederholten Hochladen sein. Vor dem Einsatz müssen Workspace-, Berechtigungs- und Datenregeln geprüft werden.

ChatGPT kann etwa über eine verbundene Google-Drive- oder SharePoint-App auf Dateien zugreifen, die das verbundene Benutzerkonto bereits öffnen darf. In verwalteten Workspaces können Administratoren App-Verfügbarkeit, Rollen, Lese- und Schreibaktionen sowie Bestätigungsregeln steuern. Die Berechtigung im Quellsystem bleibt zusätzlich wirksam. Eine Freigabe in ChatGPT gibt einem Nutzer nicht automatisch Zugriff auf eine gesperrte SharePoint- oder Google-Drive-Datei.

Für das Portalprojekt sind drei Zugriffsmuster zu unterscheiden:

• Datei im Projekt hochladen: einfach und kontrollierbar, aber zunächst eine Kopie. Änderungen an der führenden Quelle müssen bewusst nachgeführt werden.
• Live-App oder Connector verwenden: nutzt den aktuellen Zugriff des verbundenen Kontos. Geeignet, wenn die Quelle erreichbar bleiben und nicht dupliziert werden soll.
• Administrativ synchronisierte Wissensquelle: erleichtert die Suche über größere Bestände, benötigt aber klare Inhaltsauswahl, Berechtigungen und Berücksichtigung möglicher Indexierungsverzögerungen.

Für gemeinsam geteilte ChatGPT-Projekte sollte der Projektinhaber prüfen, wer Mitglied ist und welche Dateien oder Chats dadurch sichtbar werden. Schreibende App-Aktionen wie Erstellen, Ändern, Verschieben oder Teilen sollten restriktiver behandelt werden als reine Lesezugriffe.

Claude

Claude Projects kombinieren Project Knowledge und Project Instructions. Für das Beispiel gehören die stabil benötigten Projektdateien in die Projektwissensbasis, die Arbeitsregeln werden als Projektanweisungen gepflegt.

Anthropic weist auf einen Unterschied hin, der in der Praxis wichtig ist: Inhalte aus einzelnen Projektchats werden nicht automatisch zum gemeinsamen Wissen aller anderen Chats. Soll eine Entscheidung dauerhaft verfügbar sein, muss sie in die Projektwissensbasis beziehungsweise in die führende Projektablage überführt werden.

Claude Code zeigt im Softwarekontext eine besonders anschauliche Hierarchie dateibasierter Regeln. Eine zentrale CLAUDE.md kann durch projekt- oder pfadspezifische Dateien ergänzt werden. Das Prinzip lässt sich übertragen: Ein kleiner allgemeiner Kern wird durch passende Detailregeln ergänzt. CLAUDE.md ist trotzdem kein universelles Format für Unternehmenswissen.

In Claude for Work können Projekte privat bleiben, gezielt geteilt oder je nach Workspace organisationsweit verfügbar gemacht werden. Für Mitglieder gibt es eine reine Nutzungs- und Einsichtsstufe sowie eine Bearbeitungsstufe. Die genaue UI-Bezeichnung der ersten Stufe erscheint in aktuellen Dokumentationsständen nicht vollständig einheitlich als „Can view“ beziehungsweise „Can use“. Organisatorisch zählt die Trennung: Viele Mitarbeitende dürfen das Projektwissen verwenden, nur wenige Knowledge Owner dürfen es verändern.

Google-Drive-Dokumente können je nach Claude-Plan und Integration in Project Knowledge aufgenommen werden. Auch dort gilt der Zugriff des verbundenen Nutzers. Nach der aktuellen Anthropic-Dokumentation synchronisieren eingebundene Google-Dokumente mit der aktuellen Drive-Fassung; das Hinzufügen über den Drive-Connector ist derzeit auf private Projekte beschränkt und für geteilte Projekte deaktiviert. Diese Produktgrenze kann sich ändern und sollte vor dem Rollout erneut geprüft werden.

Microsoft 365 Copilot

Bei Microsoft 365 Copilot liegt die Ausgangslage häufig bereits in SharePoint, OneDrive und Teams. Das Unternehmen muss dann nicht alle Informationen erneut in eine KI-Wissensbasis kopieren – wichtiger ist die Qualität der vorhandenen Ablage.

Für das Kundenportal könnte die SharePoint-Projektseite den Project Core enthalten. Freigegebene Dokumente liegen in einer Ergebnisbibliothek, Entwürfe in einem getrennten Arbeitsbereich. Ein Copilot-Agent wird auf die benötigten Quellen ausgerichtet.

Microsoft beschreibt, dass SharePoint-Agenten Antworten auf Basis der Zugriffsrechte des jeweiligen Nutzers geben. Das schützt jedoch nicht vor historisch zu breiten Berechtigungen: Wenn ein alter Projektordner für „Jeder außer externe Benutzer“ freigegeben wurde, kann KI das darin liegende Wissen leichter auffindbar machen. Vor einer breiten Copilot-Nutzung gehören deshalb verwaiste Freigaben, externe Zugriffe, Gruppenmitgliedschaften und sensible Sites auf den Prüfstand.

Bei Copilot sind zwei Berechtigungen getrennt zu betrachten: Wer darf den Agenten verwenden, und auf welche Quellen darf dieser Nutzer zugreifen? Das Teilen eines Agenten erweitert nicht automatisch die SharePoint-Rechte. Umgekehrt bedeutet Zugriff auf eine Site nicht zwingend, dass jeder dort selbst Agents erstellen oder veröffentlichen darf. Site-, Agenten- und Adminrechte werden getrennt gesteuert.

Für den Pilot sollte ein Administrator mit Testkonten prüfen:

1. Ein Projektmitglied findet das freigegebene Fachkonzept.
2. Ein Mitarbeiter außerhalb des Projekts erhält daraus keine Inhalte.
3. Ein eingeschränktes Dokument bleibt auch über den Agenten unsichtbar.
4. Eine geänderte Quelle erscheint nach der vorgesehenen Verarbeitung aktuell.
5. Der Agent kann ohne zusätzliche Freigabe keine Veröffentlichung oder Dateiänderung auslösen.

GitHub, Codex und AGENTS.md als Spezialfall

In Softwareprojekten werden Regeln häufig direkt im Repository gepflegt. AGENTS.md , CLAUDE.md oder Copilot-Instructions können Buildbefehle, Testregeln, Architekturhinweise und verzeichnisspezifische Konventionen transportieren.

Eine solche Datei könnte zum Beispiel festlegen:

 # Arbeitsregeln für Coding Agents
## Geltungsbereich
Diese Regeln gelten für das Portal-Frontend.
## Vor Änderungen
- bestehende Komponenten prüfen
- keine Zugangsdaten in Dateien oder Logs schreiben
- betroffene Tests identifizieren
## Prüfung
- Unit-Tests ausführen
- responsive Darstellung prüfen
- geänderte Schnittstellen dokumentieren
## Grenzen
- keine Produktionsveröffentlichung
- keine Änderung an Berechtigungen ohne Freigabe 

Das ist eine gute Arbeitsanweisung für Coding Agents. Unternehmenspreise, Personalregeln oder CRM-Daten gehören trotzdem nicht in dieses Repository. Der Spezialfall bestätigt die allgemeine Regel: Kontext sollte nahe an der Arbeit liegen, ohne seine fachliche oder sicherheitsbezogene Grenze zu verlieren.

Wie Unternehmenswissen und Projektwissen zusammenarbeiten

Ein Projekt sollte Unternehmenswissen nutzen, aber nicht kopieren und stillschweigend verändern. Der Project Core enthält deshalb Verweise und nur die projektspezifischen Ergänzungen.

Für das Kundenportal könnte 04_RULES.md mit einer Quellenpriorität beginnen:

 # Kontext- und Konfliktregeln
## Quellenpriorität
1. bestätigte aktuelle Projektentscheidungen
2. freigegebene Fachbereichsstandards
3. freigegebenes Unternehmenswissen
4. aktuelle externe Primärquellen
5. Arbeitsstände und Entwürfe
6. persönliche Memory
## Vererbungsregel
Unternehmens- und Fachbereichsregeln gelten im Projekt,
sofern eine bestätigte Projektentscheidung sie nicht für diesen
Geltungsbereich konkretisiert und die Abweichung zulässig ist.
## Konfliktregel
Widersprüche werden mit den betroffenen Quellen angezeigt.
Die KI entscheidet nicht selbst, welche Regel aufgehoben wird.
## Transferregel
Eine Projekterkenntnis wird erst nach Prüfung durch den zuständigen
Knowledge Owner zum Fach- oder Unternehmensstandard. 

Der genaue Vorrang hängt von der Governance des Unternehmens ab. Eine Projektentscheidung darf zum Beispiel keine zentrale Datenschutzregel außer Kraft setzen. Solche zwingenden Grenzen müssen technisch und organisatorisch oberhalb der Projektlogik liegen.

Wie Mitarbeitende Wissen untereinander teilen

Mitarbeitende teilen nicht ihre persönlichen Memories. Sie teilen bestätigte Informationen über gemeinsame Quellen und freigegebene Projektkontexte.

Ein praktikabler Ablauf sieht so aus:

1. Ein Mitarbeiter gewinnt in einem Chat eine relevante Erkenntnis.
2. Die KI formuliert daraus einen Kandidaten mit Quelle, Datum und offenem Status.
3. Der zuständige Owner prüft die Aussage.
4. Bei Bestätigung wird sie in DECISIONS , RESULTS oder die Fachwissensbasis übernommen.
5. Andere Mitarbeiter und ihre KI-Systeme greifen anschließend auf diese gemeinsame Quelle zu.

Ein Beispiel: Der Service erkennt in mehreren Anfragen ein wiederkehrendes Missverständnis. Eine Mitarbeiterin lässt ihre KI die Fälle zusammenfassen – diese Zusammenfassung bleibt zunächst Working State. Der Service Owner prüft die Aussage und gibt eine neue FAQ frei. Die freigegebene FAQ wird in der gemeinsamen Service-Wissensbasis gespeichert. ChatGPT, Claude und Copilot können danach auf denselben bestätigten Inhalt zugreifen.

Der Wissensaustausch läuft also nicht von „persönlicher KI zu persönlicher KI“, sondern über einen nachvollziehbaren Publikations- und Freigabeprozess. Das ist langsamer als blindes Kopieren, aber wesentlich verlässlicher.

Vier Arten des KI-Zugriffs

Für verbindliches Unternehmenswissen sind Live-Zugriff oder kontrollierte Synchronisation meist tragfähiger als manuelle Chatkopien. Für einen kleinen, zeitlich begrenzten Projektstand kann ein bewusster Upload dennoch sinnvoll sein. Die Datei sollte dann ihren Stand und ihre führende Quelle nennen.

Welche Technologie braucht ein mittelständisches Unternehmen wirklich?

Die erste Entscheidung sollte sich am Problem orientieren, nicht am attraktivsten Produktnamen.

Eine Vektordatenbank macht veraltete Dokumente nicht aktuell. Ein Wissensgraph klärt keine ungeklärte Verantwortung. Ein Agent korrigiert keine zu breiten Zugriffsrechte. Technik verstärkt die vorhandene Informationsarchitektur – die gute ebenso wie die schlechte.

Auch bei Agents führt der bloße Einbau in einen bestehenden Prozess nicht automatisch zum erwarteten Nutzen. Ein Agent braucht aktuelle Quellen, verständliche Prozessregeln, bekannte Ausnahmefälle und begrenzte Rechte. Für den Mittelstand folgt daraus keine Pflicht zum radikalen Systemumbau. Zuerst müssen Wissen und Arbeitsprozesse so geordnet sein, dass ein Agent zuverlässig handeln kann.

Governance, Rollen und Berechtigungen praktisch festlegen

Eine kleine Organisation braucht nicht für jede Aufgabe eine neue Stelle. Die Verantwortlichkeiten müssen trotzdem benannt sein.

AI User nutzen freigegebene Systeme und pflegen ihre persönlichen Präferenzen. Sie ändern keine zentralen Unternehmensregeln.

Knowledge Owner verantworten fachliche Inhalte, prüfen deren Aktualität und bestätigen Änderungen.

Agent Builder konfigurieren Agents, Quellen und Workflows. Sie haben deshalb nicht automatisch auch das Recht, diese unternehmensweit zu veröffentlichen.

AI Admin oder Publisher steuern Workspace, Tools, Apps und Veröffentlichungsrechte.

Datenschutz, Informationssicherheit oder Compliance prüfen je nach Risiko die Verarbeitung, Zugriffsklassen und Kontrollen.

In einem kleineren Unternehmen kann eine Person mehrere Rollen übernehmen. Der Rollenkonflikt sollte trotzdem sichtbar bleiben: Wer einen Agenten baut, sollte nicht automatisch allein über dessen unternehmensweite Veröffentlichung entscheiden.

Für jede wichtige Quelle reichen zunächst sechs Metadaten:

 Owner: Kundenservice
Status: freigegeben
Version: 1.3
Letztes Review: 2026-09-12
Nächstes Review: 2026-12-12
Gültigkeitsbereich: Kundenportal und Service-Team 

Das Review-Datum sollte sich am Inhalt orientieren. Eine Unternehmensanschrift wird bei Änderung geprüft, eine technische Sicherheitsanweisung kann einen festen kürzeren Reviewzyklus brauchen. Starre Fristen für alle Dateien führen oft zu formaler Pflege ohne Nutzen.

Wie die Struktur im Arbeitsalltag tatsächlich genutzt wird

Die meisten Wissensarchitekturen scheitern nicht an Markdown. Sie scheitern daran, dass Entscheidungen weiter nur im Meeting, im persönlichen Chat oder zwischen zwei E-Mails existieren. Deshalb braucht das Team wenige verbindliche Routinen.

• Entscheidung am Entstehungsort sichern: Die letzten fünf Minuten eines Entscheidungsmeetings gehören der Dokumentation. Die KI darf einen Eintrag für 03_DECISIONS.md vorbereiten; der benannte Entscheider bestätigt ihn.
• Nur einen Übergabepunkt verwenden: Chats, Protokolle und E-Mails dürfen Arbeitsquellen sein. Verbindlich wird eine Aussage erst in der gemeinsamen Projektquelle. So muss niemand dieselbe Entscheidung in drei KI-Systemen pflegen.
• Pflege in bestehende Rollen legen: Die Projektleitung aktualisiert den Status, der Fachowner bestätigt Fachinhalte, die IT prüft Rechte. Ein neues „KI-Dokumentationsteam“ ist für einen kleinen Pilot meist unnötig.
• Kurzes wöchentliches Review: 15 Minuten reichen oft, um neue Entscheidungen, offene Konflikte, veraltete Quellen und blockierte Freigaben zu prüfen. Ohne neue Änderung entfällt zusätzliche Dokumentation.
• Nutzung messbar machen: Ein neues Teammitglied muss den aktuellen Stand ohne mündliche Einführung finden. Eine veraltete Aussage muss als ersetzt erkennbar sein. Ein unberechtigtes Testkonto darf geschützte Inhalte nicht erhalten.

Führungskräfte müssen diese Routine selbst vorleben. Wer Entscheidungen weiterhin ausschließlich im Chat trifft und die gemeinsame Quelle ignoriert, macht jede Governance-Regel zur Dekoration.

Wissen muss einen Lifecycle haben

Im Kundenportal erkennt der Service, dass viele Kunden dieselbe Frage zur Anmeldung stellen. Daraus entsteht zunächst eine Arbeitsbeobachtung. Die KI kann ähnliche Anfragen gruppieren und einen FAQ-Entwurf erstellen. Ein Serviceverantwortlicher prüft die Aussage. Danach wird sie als freigegebener Portaltext übernommen. Verändert die Antwort künftig einen allgemeinen Serviceprozess, ist eine weitere fachliche Entscheidung nötig.

Die Rückrichtung ist genauso wichtig: Eine Information kann veralten, ersetzt oder archiviert werden. Das Entscheidungsprotokoll sollte festhalten, welche ältere Aussage abgelöst wurde. Eine Suche oder KI-Abfrage muss den aktuellen Stand bevorzugen können.

Zum Projektabschluss gehören:

• bestätigte Ergebnisse in der vorgesehenen Ablage sichern;
• Entscheidungen und ihre Gültigkeit nachvollziehbar halten;
• wiederverwendbare Erkenntnisse durch die zuständigen Fachowner prüfen lassen;
• Arbeitsentwürfe archivieren oder nach geltenden Regeln entfernen;
• Projekt- und Agentenberechtigungen überprüfen;
• persönliche oder toolgebundene Kopien bereinigen, soweit dafür ein freigegebener Prozess besteht.

Ein Projekt endet nicht mit dem letzten Chat. Sonst beginnt das nächste Team einige Monate später wieder mit widersprüchlichen Unterlagen.

Ein sinnvoller Start in sieben Arbeitsschritten

Das Unternehmen muss nicht den gesamten Wissensbestand auf einmal neu strukturieren. Das Kundenportal eignet sich als Pilot, weil mehrere Fachbereiche, sensible Informationen, Entscheidungen und konkrete Ergebnisse zusammenkommen.

Für einen Pilot mit fünf bis zehn Beteiligten ist als grobe Orientierung mit drei bis fünf Personentagen zu rechnen, verteilt über zwei bis drei Wochen. Darin enthalten sind zwei kurze Workshops, die Einrichtung des Project Core, ein Berechtigungstest und die Erprobung eines konkreten Arbeitsprozesses. Eine DMS-Migration, umfangreiche Datenbereinigung, juristische Einzelfallprüfung oder technische Eigenentwicklung ist darin nicht enthalten. Sind Quellen stark verstreut oder Berechtigungen historisch gewachsen, steigt der Aufwand deutlich.

Ein realistischer Ablauf: In Woche eins grenzt das Team den Anwendungsfall ein und bestimmt Quellen sowie Owner. In Woche zwei legt es die fünf Kerndateien und Berechtigungen an und bindet ein KI-System an. In Woche drei arbeitet das Team mit einem echten Vorgang, korrigiert Lücken und entscheidet erst danach über eine Ausweitung.

1. Anwendungsfall begrenzen. Das Team legt fest, welche Aufgaben KI unterstützen soll und welche vorerst ausgeschlossen bleiben.
2. Quellen inventarisieren. Bestehende Dateien, Systeme, Chats und Protokolle werden erfasst, aber noch nicht unkontrolliert zusammenkopiert.
3. Führende Quellen bestimmen. Für Leistungsumfang, Technik, Datenschutz und Texte wird jeweils ein Owner und ein System of Record benannt.
4. Project Core anlegen. Projektbriefing, Quellenindex, Entscheidungen, Regeln und aktueller Status werden als kompakte Dateien oder entsprechende SharePoint-Seiten aufgebaut.
5. Berechtigungen prüfen. Das Team testet nicht nur, ob berechtigte Nutzer etwas finden, sondern auch, ob andere Nutzer es tatsächlich nicht sehen können.
6. Ein KI-System anschließen. Zunächst wird ein klarer Arbeitsprozess erprobt, etwa die Erstellung und Prüfung einer FAQ. Weitere Tools folgen nur bei Bedarf.
7. Drei Belastungstests durchführen. Ein neuer Mitarbeiter soll den aktuellen Projektstand finden. Eine veraltete Quelle muss als überholt erkennbar sein. Ein geschütztes Dokument muss geschützt bleiben.

Nach diesem Pilot lässt sich begründet entscheiden, welche Struktur unternehmensweit übernommen wird und wo zusätzliche Technik sinnvoll ist.

Was am Ende funktionieren muss

Eine tragfähige KI-Wissensarchitektur erkennt man nicht an der Zahl der Dateien, Agents oder Tools. Sie funktioniert, wenn ein Mitarbeiter den gültigen Stand findet, eine KI Entwurf und Entscheidung unterscheiden kann, ein Wechsel des KI-Systems das Unternehmenswissen nicht zerstört und sensible Inhalte innerhalb ihrer Berechtigungsgrenzen bleiben.

Für das Kundenportal heißt das: Vertrieb, Service und IT dürfen mit unterschiedlichen KI-Werkzeugen arbeiten. Sie müssen sich trotzdem auf denselben bestätigten Projektumfang, dieselben Quellen und dieselben Freigaben beziehen. Persönliche Memory verbessert die individuelle Arbeit. Gemeinsames Wissen entsteht erst durch Verantwortung, Prüfung und nachvollziehbare Ablage.

Quellen und weiterführende Informationen

• OpenAI Help Center: Projects in ChatGPT
• OpenAI Help Center: Memory FAQ
• OpenAI Help Center: Company Knowledge in ChatGPT
• OpenAI Help Center: Knowledge in GPTs
• OpenAI Help Center: Data residency and inference residency for ChatGPT
• Anthropic Help Center: How can I create and manage projects?
• Anthropic Help Center: What are projects?
• Anthropic Help Center: Use Google Workspace connectors
• Anthropic: How Claude remembers your project
• Anthropic Privacy Center: Data use for model training in commercial offerings
• Anthropic Privacy Center: Server locations and data storage for commercial products
• Microsoft Learn: Manage access to agents in SharePoint
• Microsoft Learn: Add knowledge sources to an agent
• Microsoft Learn: Write effective instructions for declarative agents
• Microsoft Learn: Restricted SharePoint Search
• Microsoft Learn: Microsoft Copilot Chat privacy and protections
• EUR-Lex: Datenschutz-Grundverordnung
• Europäische Kommission: AI Act – Rechtsrahmen und Zeitplan
• Europäische Kommission: Fragen und Antworten zur KI-Kompetenz
• GitHub Docs: Adding repository custom instructions for GitHub Copilot
• AGENTS.md: An open format for guiding coding agents

Stand der Produktprüfung: 14. September 2026. Produktfunktionen, Tarifgrenzen und Bezeichnungen können sich ändern. Prüfen Sie vor einer Einführung die aktuellen Hersteller-, Vertrags- und Datenschutzunterlagen für Ihren konkreten Tarif und Anwendungsfall.