Claude Projects im Unternehmen sinnvoll nutzen
Claude Projects im Unternehmen: Aufbau mit Projektanweisungen und Wissen, 6 Beispielprojekte mit Anweisungen im Codeblock, Pflege, Datenschutz und Grenzen.
Wer Claude im Unternehmen nur im leeren Chat nutzt, verschenkt den größten Hebel. Jeder Mitarbeitende erklärt in jedem Chat aufs Neue, was das Unternehmen macht, wie es kommuniziert und welche Regeln gelten. Die Ergebnisse schwanken je nach Person, und niemand profitiert von den guten Prompts der Kollegen.
Claude Projects lösen dieses Problem. Sie sind Arbeitsbereiche, in denen Anweisungen und Dokumente einmal hinterlegt werden und dann für alle Unterhaltungen gelten. Für kleine und mittelständische Unternehmen sind sie das wichtigste Werkzeug, um aus gelegentlicher Nutzung einen verlässlichen Arbeitsprozess zu machen.
Dieser Artikel erklärt, was Projects sind, wie sie aufgebaut werden, und zeigt sechs konkrete Beispielprojekte mit vollständigen Projektanweisungen, die Sie übernehmen und anpassen können. Dazu kommen Hinweise zur Pflege, zum Datenschutz und zu den Grenzen, insbesondere bei großen Datenmengen.
Was Claude Projects sind
Claude Projects sind Arbeitsbereiche innerhalb von Claude, die aus drei Teilen bestehen: einer Projektanweisung, einer Wissensbasis aus hochgeladenen Dokumenten und den Unterhaltungen, die in diesem Bereich geführt werden. Anweisung und Wissen stehen in jeder Unterhaltung automatisch zur Verfügung, ohne dass sie erneut eingegeben werden müssen.
Ein einfaches Bild: Der leere Chat ist ein neuer Kollege am ersten Tag, ohne Einarbeitung. Ein Project ist derselbe Kollege nach der Einarbeitung, mit Handbuch, Stilrichtlinie und Musterdokumenten auf dem Schreibtisch. Die Fragen, die Sie stellen, sind dieselben. Die Antworten sind deutlich besser.
Projects gibt es in den Plänen Pro, Max, Team und Enterprise. Im Team-Plan und in Enterprise lassen sich Projects mit Kolleginnen und Kollegen teilen. Das ist für den Unternehmenseinsatz die entscheidende Funktion, weil so alle mit denselben Anweisungen und demselben Wissen arbeiten.
Aufbau eines Projects: Anweisung und Wissen
Die Projektanweisung
Die Projektanweisung ist ein Text, der vor jeder Unterhaltung im Project gilt. Technisch entspricht sie einem System Prompt. Sie legt fest, in welcher Rolle Claude arbeitet, welche Tonalität und welche Formate gelten, welche Regeln einzuhalten sind und wie mit den hochgeladenen Dokumenten umgegangen werden soll.
Eine gute Projektanweisung ist konkret, aber nicht endlos. Erfahrungsgemäß reichen 150 bis 400 Wörter. Sie enthält:
- Rolle: Wer ist Claude in diesem Project?
- Unternehmenskontext: Was macht das Unternehmen, für wen?
- Tonalität und Form: Sie- oder Du-Form, Länge, Stil, Grußformeln
- Regeln: Was ist erlaubt, was verboten, was muss immer enthalten sein?
- Umgang mit Wissen: Welche Dokumente gibt es, wie sollen sie genutzt werden?
- Verhalten bei Unsicherheit: Nachfragen, kennzeichnen, nicht raten
Die Wissensbasis
Die Wissensbasis besteht aus Dokumenten, die Sie ins Project hochladen: Textdateien, PDFs, Tabellen, Präsentationen. Claude greift in jeder Unterhaltung darauf zu. Geeignet sind Dokumente, die sich selten ändern und die für viele Aufgaben im Project relevant sind: Leistungsbeschreibungen, Preislisten, Stilrichtlinien, Musterdokumente, FAQ, Prozessbeschreibungen.
Weniger geeignet sind Dokumente, die sich täglich ändern, sehr große Datenbestände oder Inhalte, die nur für eine einzige Aufgabe gebraucht werden. Die laden Sie besser in der jeweiligen Unterhaltung hoch.
Ein praktischer Hinweis zur Qualität der Dokumente: Claude arbeitet mit dem, was drinsteht. Veraltete Preislisten führen zu falschen Angeboten, widersprüchliche Musterdokumente zu uneinheitlichen Ergebnissen. Bevor Sie ein Dokument hochladen, prüfen Sie kurz, ob es aktuell ist und ob es dem entspricht, was Sie als Ergebnis erwarten. Drei gute Musterdokumente sind mehr wert als zehn mittelmäßige.
Die Wissensbasis ist durch das Kontextfenster begrenzt. Es ist sehr groß, aber nicht unendlich. Als Faustregel gilt: einige Dutzend Seiten Text sind unproblematisch, mehrere hundert Seiten werden knapp, und ab einem gewissen Umfang sinkt die Qualität, weil zu viel Irrelevantes mitgelesen wird. Wählen Sie Dokumente gezielt aus.
Sechs Beispielprojekte mit Projektanweisung
Die folgenden Projekte haben sich in Unternehmen unterschiedlicher Branchen bewährt. Die Anweisungen sind als Vorlagen gedacht: Firmennamen, Produkte und Regeln ersetzen Sie durch Ihre eigenen.
Projekt 1: Angebotserstellung
Ziel: Aus Stichpunkten eines Kundengesprächs ein Angebot in Unternehmenssprache erstellen.
Wissensbasis: zwei bis drei gute Musterangebote, Leistungsbeschreibung, Preisliste, Allgemeine Geschäftsbedingungen in Kurzform.
Du bist Vertriebsmitarbeiter der Beispiel IT GmbH, einem IT-Dienstleister
für mittelständische Unternehmen in Norddeutschland. Du erstellst
Angebote auf Basis von Gesprächsnotizen.
Aufbau jedes Angebots:
1. Kurze Einleitung mit Bezug auf das Gespräch (2 bis 3 Sätze)
2. Ausgangslage und Ziel des Kunden (ein Absatz)
3. Leistungsbeschreibung mit Positionen, orientiert an den Musterangeboten
4. Preise gemäß Preisliste, netto zzgl. USt., als Tabelle
5. Zeitplan und nächste Schritte
6. Gültigkeit 30 Tage, Verweis auf AGB
Regeln:
- Sie-Form, sachlich, freundlich, keine Superlative
- Preise ausschließlich aus der Preisliste. Fehlt eine Position,
schreibe "Preis auf Anfrage" und weise mich darauf hin
- Keine Leistungen aufnehmen, die nicht in den Notizen stehen
- Keine Zusagen zu Terminen, die nicht in den Notizen stehen
- Wenn Angaben fehlen, liste sie am Ende unter "Offene Punkte"
Die Musterangebote zeigen Ton und Struktur. Übernimm die Struktur,
nicht die Inhalte.
Projekt 2: Kundenservice-Antworten
Ziel: Antwortentwürfe für Kundenanfragen, die Mitarbeitende prüfen und versenden.
Wissensbasis: FAQ, Garantie- und Rückgabebedingungen, Versandinformationen, zehn gelungene Beispielantworten, Eskalationsregeln.
Du bist Mitarbeiter im Kundenservice der Beispiel Gartenmöbel GmbH.
Du formulierst Antwortentwürfe auf Kundenanfragen per E-Mail. Jeder
Entwurf wird von einem Menschen geprüft, bevor er versendet wird.
Tonalität: freundlich, klar, in Sie-Form. Wir sprechen wie ein
hilfsbereiter Fachhändler, nicht wie eine Behörde. Keine Floskeln
wie "Unannehmlichkeiten" oder "wir bedauern zutiefst".
Struktur: Anrede, Bezug auf das Anliegen in einem Satz, Lösung oder
nächster Schritt, Grußformel "Freundliche Grüße, Ihr Team der
Beispiel Gartenmöbel GmbH". Maximal 150 Wörter.
Regeln:
- Antworte nur auf Basis der hochgeladenen Dokumente
- Bei Reklamationen: Verständnis zeigen, einmal entschuldigen,
konkrete Lösung nennen
- Keine Zusagen zu Kulanz über 50 Euro, das entscheidet ein Mensch.
Schreibe in diesem Fall "[KULANZ PRÜFEN]" in den Entwurf
- Bei rechtlichen Drohungen, Beschwerden über Mitarbeitende oder
Themen, die nicht in den Dokumenten stehen: keinen Entwurf
schreiben, sondern "[ESKALATION]" und den Grund nennen
Die Beispielantworten zeigen unseren Ton. Orientiere dich daran.
Projekt 3: Stellenanzeigen
Ziel: Stellenanzeigen, die ehrlich beschreiben, was die Stelle bietet, in einheitlichem Stil.
Wissensbasis: Unternehmensbeschreibung, drei gute bestehende Anzeigen, Liste der Benefits, Hinweise zum Bewerbungsprozess.
Du bist Personalreferent der Beispiel Logistik GmbH, einem
Familienunternehmen mit 120 Mitarbeitenden in Bremen. Du schreibst
Stellenanzeigen.
Aufbau: Überschrift mit Stellenbezeichnung (m/w/d), Einstieg mit
zwei Sätzen zum Unternehmen, "Ihre Aufgaben" (4 bis 6 Punkte),
"Das bringen Sie mit" (3 bis 5 Punkte), "Das bieten wir"
(aus der Benefit-Liste, 4 bis 6 Punkte), Abschluss mit
Bewerbungsweg. Maximal 350 Wörter.
Tonalität: Sie-Form, freundlich, direkt, ohne Phrasen wie
"dynamisches Umfeld", "spannende Herausforderungen" oder
"Teamplayer". Wir schreiben, was die Person tatsächlich tut.
Regeln:
- Keine Anforderungen erfinden, die ich nicht nenne
- Anforderungen ehrlich trennen: notwendig und wünschenswert
- Gehaltsangabe nur, wenn ich sie nenne
- Alle Aussagen zum Unternehmen aus der Unternehmensbeschreibung
Die bestehenden Anzeigen zeigen unseren Stil.
Projekt 4: Besprechungsprotokolle
Ziel: Protokolle in einheitlichem Format aus Notizen oder Transkripten.
Wissensbasis: Protokollvorlage, Liste der Abteilungen und Kürzel, ein Beispielprotokoll.
Du erstellst Besprechungsprotokolle für die Beispiel Maschinenbau GmbH.
Eingabe: Stichpunkte, Sprachnotizen als Text oder Transkripte.
Ausgabe: Protokoll nach der hochgeladenen Vorlage mit den Abschnitten
Teilnehmende, Datum, Themen, Entscheidungen, Aufgaben.
Regeln:
- Aufgaben als Tabelle: Aufgabe, Verantwortlich, Frist
- Fehlende Verantwortliche oder Fristen als "offen" eintragen
- Nichts erfinden, nichts interpretieren. Bei unklaren Stellen
im Transkript "[UNKLAR]" einfügen
- Sachlich, Sie-Form, keine wörtlichen Zitate außer bei
Entscheidungen
- Namen mit Abteilungskürzel gemäß der hochgeladenen Liste
Bei Transkripten: Smalltalk, Wiederholungen und Nebenthemen
weglassen. Entscheidungen und Aufgaben vollständig erfassen.
Projekt 5: Unternehmensstil
Ziel: Texte aller Art in der Sprache des Unternehmens überarbeiten oder erstellen.
Wissensbasis: Stilrichtlinie, Glossar mit Begriffen und Schreibweisen, Liste verbotener Formulierungen, drei bis fünf Beispieltexte.
Du bist Lektor und Texter der Beispiel Steuerberatung, einer Kanzlei
mit 25 Mitarbeitenden. Du überarbeitest Texte oder erstellst neue
Texte in unserem Stil.
Unser Stil:
- Sie-Form, verständlich, kurze Sätze, keine Schachtelsätze
- Fachbegriffe erklären, wenn Mandanten sie nicht kennen
- Keine Gedankenstriche zur Satzgliederung
- Keine Formulierungen aus der Verbotsliste
- Schreibweisen gemäß Glossar (z. B. "E-Mail", "Mandantin und
Mandant")
Bei Überarbeitungen: Inhalt und Aussage unverändert lassen, nur
Sprache anpassen. Nenne am Ende in drei Punkten, was du geändert
hast und warum.
Bei neuen Texten: Frage nach Zielgruppe, Zweck und Länge, bevor
du beginnst, falls das nicht angegeben ist.
Projekt 6: Interne Regelungen als Wissensbasis
Ziel: Mitarbeitende können Fragen zu internen Regelungen stellen, ohne die Personalabteilung zu bemühen.
Wissensbasis: Reisekostenrichtlinie, Urlaubsregelung, IT-Nutzungsrichtlinie, Homeoffice-Vereinbarung, Ansprechpartnerliste.
Du beantwortest Fragen von Mitarbeitenden der Beispiel Handel GmbH
zu internen Regelungen. Grundlage sind ausschließlich die
hochgeladenen Dokumente.
Regeln:
- Antworte nur, wenn die Antwort in den Dokumenten steht. Zitiere
die Fundstelle (Dokumentname und Abschnitt)
- Wenn die Antwort nicht in den Dokumenten steht, sage das klar
und nenne den Ansprechpartner aus der Liste
- Keine Auslegung von Einzelfällen. Bei "Gilt das auch, wenn..."
auf den Ansprechpartner verweisen
- Kurz und verständlich, Sie-Form, maximal 100 Wörter
- Keine arbeitsrechtliche Beratung
Beispiel: Auf "Wie viele Tage Homeoffice sind möglich?" antwortest
du mit der Regelung aus der Homeoffice-Vereinbarung und dem Verweis
auf den Abschnitt.
Projects im Team teilen und organisieren
Im Team-Plan werden Projects für das gesamte Team oder einzelne Personen freigegeben. Wenige klare Projects sind besser als viele halbfertige. Als Startpunkt für ein Unternehmen mit 20 bis 100 Mitarbeitenden haben sich drei bis sechs geteilte Projects bewährt, jeweils mit einer verantwortlichen Person.
Bewährte Praxis bei der Organisation:
- Einheitliche Benennung, etwa “Vertrieb: Angebote”, “Service: Antworten”, “HR: Stellenanzeigen”
- Eine Beschreibung pro Project, die sagt, wofür es gedacht ist und wofür nicht
- Ein Verantwortlicher pro Project, der Anweisung und Wissen pflegt
- Keine persönlichen Experimente in geteilten Projects, dafür eigene Projects anlegen
Projects ersetzen die Prompt-Bibliothek nicht, sie ergänzen sie. Die Projektanweisung enthält, was immer gilt. Die Prompt-Bibliothek enthält die konkreten Aufträge, die im Project gestellt werden, etwa “Erstelle ein Angebot aus folgenden Notizen”. Wie gute Prompts aufgebaut sind, beschreibt der Praxisleitfaden zum Prompten.
Projects pflegen: Wer, wann, wie
Ein Project, das nach dem Anlegen nie wieder angefasst wird, veraltet. Preise ändern sich, Regeln werden angepasst, Beispielantworten passen nicht mehr. Die Pflege ist kein großer Aufwand, aber sie muss jemandem gehören.
Empfehlung für den Pflegeprozess:
- Der Verantwortliche prüft die Wissensbasis alle drei Monate: Sind alle Dokumente aktuell? Fehlt etwas? Ist etwas überflüssig?
- Feedback aus dem Team wird gesammelt. Wenn mehrere Personen dieselbe Korrektur an Ergebnissen vornehmen, gehört diese Korrektur in die Projektanweisung.
- Änderungen an der Anweisung werden kurz getestet, bevor sie für alle gelten. Drei typische Aufgaben durchspielen reicht.
- Größere Änderungen werden dem Team mitgeteilt, damit niemand von neuen Ergebnissen überrascht wird.
Ein Beispiel für sinnvolle Pflege: Im Project Kundenservice fällt auf, dass Claude bei Fragen zu einer neuen Produktlinie ausweicht, weil der Produktkatalog von letztem Jahr stammt. Der Verantwortliche tauscht den Katalog aus, ergänzt in der Anweisung einen Satz zur neuen Linie und testet drei typische Anfragen. Aufwand: eine halbe Stunde.
Ein Hinweis aus der Praxis: Halten Sie die Projektanweisung schlank. Wenn sie über die Zeit auf zwei Seiten anwächst, weil jede Ausnahme ergänzt wurde, sinkt die Qualität. Streichen Sie Regeln, die kaum relevant sind, und fassen Sie ähnliche zusammen.
Datenschutz bei Projects
Alles, was in ein Project hochgeladen wird, ist für alle Personen sichtbar, die Zugriff auf das Project haben. Bevor Sie Dokumente hochladen, prüfen Sie zwei Dinge: Dürfen alle Personen mit Zugriff diese Inhalte sehen? Und dürfen diese Daten überhaupt in Claude verarbeitet werden?
Für die zweite Frage gilt: Im Team- und Enterprise-Plan werden Inhalte standardmäßig nicht zum Training der Modelle verwendet, und ein Auftragsverarbeitungsvertrag ist verfügbar. Bei Consumer-Plänen sollten Sie die Einstellungen zur Datennutzung prüfen und keine Unternehmensdaten hochladen. Personenbezogene Daten, etwa in Kundenlisten oder Personalunterlagen, erfordern eine Rechtsgrundlage und die Klärung des Drittlandtransfers.
Praxisregeln:
- Nur Unternehmensaccounts für Projects mit Firmendaten
- Personenbezogene Daten in der Wissensbasis vermeiden oder anonymisieren
- Vertrauliche Dokumente wie Verträge oder Kalkulationen nur in Projects mit eingeschränktem Zugriff
- Den Datenschutzbeauftragten einbeziehen, bevor das erste geteilte Project mit Unternehmensdaten angelegt wird
Grundsätzlich ist der Einsatz von Projects mit Unternehmensdaten möglich, abhängig von Plan, Vertragsgestaltung und Art der Daten. Dieser Artikel ist keine Rechtsberatung. Eine Übersicht der wichtigsten Fragen gibt der Beitrag Claude, Datenschutz und DSGVO.
Grenzen von Projects
Projects sind ein hervorragendes Werkzeug für wiederkehrende Aufgaben mit überschaubarem Wissen. Sie haben aber klare Grenzen, die Sie kennen sollten, bevor Sie zu viel von ihnen erwarten.
Kein Ersatz für RAG bei großen Datenmengen
Projects laden das gesamte hinterlegte Wissen in jede Unterhaltung. Das funktioniert gut bei einigen Dutzend Seiten. Bei tausenden Dokumenten, einer kompletten Produktdatenbank oder einem Archiv aus zehn Jahren ist das nicht mehr sinnvoll und technisch nicht möglich. Für solche Fälle ist Retrieval Augmented Generation der richtige Ansatz: Die Dokumente werden in einer Vektordatenbank abgelegt, und nur die jeweils relevanten Abschnitte werden an Claude übergeben. Das ist ein technisches Projekt, das über die API und Werkzeuge wie n8n umgesetzt wird.
Keine Automatisierung
Projects sind für interaktive Arbeit gedacht. Ein Mensch stellt eine Anfrage, Claude antwortet. Wer Aufgaben ohne manuelle Eingabe ausführen möchte, etwa jede eingehende E-Mail automatisch kategorisieren, braucht die API und einen Workflow. Die Projektanweisung lässt sich dabei als System Prompt weiterverwenden.
Kein Wissen über den Moment hinaus
Claude weiß in einem Project nur, was in Anweisung, Wissen und der aktuellen Unterhaltung steht. Es kennt nicht die Unterhaltungen anderer Kollegen im selben Project und lernt nicht aus Korrekturen. Alles, was dauerhaft gelten soll, muss in die Anweisung oder das Wissen.
Keine Garantie für Fehlerfreiheit
Auch mit gutem Project können Ergebnisse Fehler enthalten. Die Prüfung durch einen Menschen bleibt Pflicht, insbesondere bei Zahlen, Zusagen und allem, was nach außen geht.
Wer diese Grenzen kennt, nutzt Projects dort, wo sie stark sind, und wählt für den Rest den passenden Weg. Beim Aufbau von Projects, der Formulierung der Anweisungen und der Auswahl der Wissensdokumente unterstütze ich im Rahmen der Claude Beratung, auch als Teil einer strukturierten Einführung nach dem Ablauf im Artikel Claude im Unternehmen einsetzen. Weitere Anwendungsideen finden Sie in den 25 Use Cases für KMU und auf der Seite Claude für Unternehmen.
Häufige Fragen
Was ist der Unterschied zwischen einem Claude Project und einem normalen Chat?
Im normalen Chat beginnt jede Unterhaltung ohne Vorwissen. In einem Project gelten eine hinterlegte Projektanweisung und hochgeladene Dokumente für alle Unterhaltungen. Sie müssen Kontext, Regeln und Wissen nicht wiederholen, und das Ergebnis ist gleichbleibend.
Wie viele Dokumente kann ich in ein Project hochladen?
Die Grenze wird durch das Kontextfenster bestimmt. Einige Dutzend Seiten sind unproblematisch, mehrere hundert Seiten werden knapp. Wählen Sie Dokumente gezielt aus. Für sehr große Wissensbestände ist Retrieval Augmented Generation der bessere Ansatz.
Können mehrere Mitarbeitende dasselbe Project nutzen?
Ja, im Team- und Enterprise-Plan lassen sich Projects mit dem Team teilen. Alle arbeiten dann mit denselben Anweisungen und demselben Wissen. Einzelne Unterhaltungen bleiben dabei privat, sofern sie nicht bewusst geteilt werden.
Lernt Claude aus Korrekturen innerhalb eines Projects?
Nein. Claude lernt nicht aus einzelnen Unterhaltungen. Wenn eine Korrektur dauerhaft gelten soll, muss sie in die Projektanweisung oder in ein hochgeladenes Dokument aufgenommen werden. Das ist die Aufgabe des Projektverantwortlichen.
Sind Projects für Kundendaten datenschutzrechtlich zulässig?
Grundsätzlich möglich, abhängig von Plan, Auftragsverarbeitungsvertrag, Rechtsgrundlage und Art der Daten. Nutzen Sie nur Unternehmensaccounts, vermeiden oder anonymisieren Sie personenbezogene Daten in der Wissensbasis und beziehen Sie Ihren Datenschutzbeauftragten ein. Dies ist keine Rechtsberatung.
Wie lang sollte eine Projektanweisung sein?
Erfahrungsgemäß 150 bis 400 Wörter. Sie sollte Rolle, Kontext, Tonalität, Regeln, Umgang mit Wissen und Verhalten bei Unsicherheit enthalten. Wächst sie über die Zeit stark an, ist es Zeit zum Kürzen und Zusammenfassen.