# KI-Assistenten im Team teilen: Rollen, Rechte, Vertraulichkeit > KI-Assistenten im Team teilen: wer ändern darf, wer nur nutzt, und warum hinterlegtes Wissen aus geteilten Assistenten wieder herauskommt. - Autor: Benedikt Backhaus (https://benediktbackhaus.com/ueber-mich/) - Veröffentlicht: 2026-08-07 - URL: https://benediktbackhaus.com/blog/ki-assistenten-im-team-teilen/ - Themen: Agenten & Skills, Sicherheit, Praxis Sobald ein KI-Assistent das Team erreicht, brauchst du zwei Festlegungen, die vorher niemand vermisst hat: wer ihn ändern darf und was nie in seiner Wissensbasis landen darf. Alles andere lässt sich nachziehen, diese beiden Punkte nicht. Der Übergang vom Einzelwerkzeug zum Teamwerkzeug ist der Moment, in dem aus einer privaten Bastelei ein internes System wird. In Workshops sehe ich regelmäßig, dass genau dieser Schritt übersprungen wird. Der Assistent funktioniert bei einer Person, wird per Link weitergegeben, und drei Wochen später existieren fünf Varianten mit unterschiedlichen Regeln. Dieser Artikel gehört zum [Guide zum Bauen eigener KI-Assistenten mit Firmenwissen](/blog/ki-assistenten-firmenwissen-guide/) und behandelt den organisatorischen Teil. ## Was sich beim Teilen tatsächlich ändert Ein Assistent für dich allein ist ein Werkzeug. Ein geteilter Assistent ist eine Aussage darüber, wie ihr arbeitet. Das klingt größer, als es ist, hat aber praktische Folgen. Wenn dein Assistent Angebotstexte formuliert und das ganze Vertriebsteam ihn nutzt, dann definiert die hinterlegte Anweisung eure Angebotssprache. Wenn er Kundenanfragen einordnet, definiert er eure Kategorien. Fehler in den Constraints, also den festen Regeln dafür, was er darf und was nicht, multiplizieren sich mit der Anzahl der Nutzenden. Niemand merkt es sofort, weil jeder einzelne Output für sich plausibel aussieht. Deshalb sind die folgenden Rollen kein Bürokratie-Overhead, sondern die Minimalausstattung. ## Die drei Rollen, die ihr wirklich braucht Ich komme mit drei aus. Mehr wird in Teams unter 20 Personen nicht gelebt. **Owner.** Eine namentlich benannte Person. Sie entscheidet, was in die Anweisung und in die Wissensbasis kommt, und sie ist der Ansprechpartner bei schlechten Ergebnissen. Ohne Owner verwaist jeder Assistent, das ist eine der zuverlässigsten Regeln in diesem Feld. Wichtig: Der Owner muss nicht die Person sein, die am meisten von KI versteht. Er muss die Person sein, die vom Thema fachlich am meisten versteht. **Editor.** Ein bis zwei Personen, die Änderungen vornehmen dürfen. Kleine Teams brauchen das, weil sonst jeder Urlaub den Assistenten einfriert. Wer Editor ist, sollte wissen, wo die Quellversionen der Anweisung und der Dokumente liegen. **Nutzer.** Alle anderen. Sie verwenden den Assistenten und melden Auffälligkeiten. Diese Rolle ist die wichtigste, weil aus ihr die Verbesserungen kommen. Gebt ihr einen Kanal, der zwei Sekunden kostet: ein Channel, ein Formular, ein Ordner mit Screenshots. Wenn Feedback per Zuruf im Flur passiert, kommt es nie beim Owner an. Wichtiger als die Benennung ist, dass die Rollen im Tool auch technisch getrennt sind. Wo alle bearbeiten dürfen, wird auch von allen bearbeitet, meist gut gemeint und ohne Notiz. Wo niemand außer einer Person bearbeiten darf, steht der Assistent still, sobald diese Person zwei Wochen im Urlaub ist. Der brauchbare Mittelweg für kleine Teams ist ein Owner plus eine Vertretung, und alle anderen im Lesezugriff. Ob deine Plattform diese Rollen technisch sauber abbilden kann, ist übrigens ein handfestes Auswahlkriterium und gehört in die Entscheidung, [wo du deinen Assistenten baust](/blog/customgpt-claude-project-gem-vergleich/). Manche Bauformen kennen nur „ansehen" und „bearbeiten", manche behandeln jeden Empfänger als Besitzer einer eigenen Kopie. Der Unterschied ist erheblich. ## Wenn jeder seine eigene Variante baut Das passiert aus Ungeduld. Jemand braucht eine kleine Anpassung, findet keinen Weg dorthin und legt sich eine eigene Version an. Nach drei Monaten habt ihr fünf Assistenten mit demselben Namen und leicht unterschiedlichen Regeln. Die Symptome sind unangenehm konkret: - Zwei Kolleginnen bekommen für dieselbe Anfrage unterschiedliche Antworten und wissen nicht, welche gilt. - Eine Variante enthält noch die Preisliste vom letzten Jahr. - Die Verbesserung, die eine Person gefunden hat, kommt bei niemandem sonst an. - Beim Ausscheiden eines Mitarbeiters verschwindet eine Variante, die im Kundenkontakt genutzt wurde. Was dagegen hilft, ist weniger Verbot als Ventil. Definiert eine kanonische Version und einen offiziellen Weg, Änderungswünsche loszuwerden. Ein Vorschlag an den Owner, der innerhalb einer Woche beantwortet wird, verhindert mehr Wildwuchs als jede Regel. Und eine Ausnahme lasse ich gelten: Experimente. Wer etwas ausprobieren will, soll eine private Kopie bauen dürfen, aber mit dem Label „Test" und ohne dass Kollegen darauf verwiesen werden. Was sich bewährt, wandert zurück in die kanonische Version. Was nicht, verschwindet. Der Unterschied zwischen einem Testaufbau und einem echten Arbeitswerkzeug ist ohnehin das Thema von [Vom Test-Assistenten zum Alltags-Assistenten](/blog/test-skill-zu-alltags-skill/). ## Onboarding: was neue Kolleginnen wissen müssen Ein geteilter Assistent ist ein Onboarding-Vorteil, wenn ihr ihn als solchen behandelt. Neue Leute bekommen darüber Zugriff auf euer Vorgehen, ohne dass jemand alles mündlich erklären muss. Vier Dinge gehören dazu in die Einarbeitung: 1. **Wofür der Assistent da ist und wofür nicht.** Ein Satz zur Aufgabe, ein Satz zu den Grenzen. Neue Leute überschätzen sonst den Zuständigkeitsbereich. 2. **Wie ein guter Aufruf aussieht.** Zwei echte Beispiele aus dem Alltag, keine konstruierten. Am besten mit dem Ergebnis daneben. 3. **Woran man merkt, dass eine Antwort falsch ist.** Das ist der Teil, der am häufigsten fehlt. Neue Kolleginnen können nicht beurteilen, ob eine Aussage zu eurem Produkt stimmt, deshalb braucht es eine klare Ansage, was gegengeprüft werden muss. 4. **Wem man Auffälligkeiten meldet.** Name, Kanal, fertig. Das passt auf eine halbe Seite. Diese halbe Seite ist gleichzeitig die Dokumentation, die euch bei der [laufenden Wartung](/blog/ki-assistent-wartung-aktuell-halten/) hilft, weil dort steht, was der Assistent können soll. Umgekehrt ist ein geteilter Assistent ein guter Test für eure gesamte Einarbeitung. Wenn die neue Kollegin nach zwei Tagen brauchbare Ergebnisse bekommt, war euer Wissen offenbar dokumentierbar. Wenn sie ständig nachfragen muss, weil der Assistent Kontext voraussetzt, den nur Langgediente haben, dann fehlt dieser Kontext auch in eurer Einarbeitungsmappe. Der Assistent macht die Lücke nur sichtbar, er verursacht sie nicht. ## Die Warnung: hinterlegtes Wissen kommt wieder raus Jetzt der Teil, der beim Teilen am meisten unterschätzt wird. Was du in einem Assistenten hinterlegst, ist gegenüber den Nutzenden nicht geschützt. Weder deine Anweisung noch deine hochgeladenen Dokumente. Dazu gibt es belastbare Forschung. Jiahao Yu und Kolleginnen und Kollegen von der Northwestern University haben 2023 in „Assessing Prompt Injection Risks in 200+ Custom GPTs" über 200 fremde und 16 von OpenAI selbst gebaute CustomGPTs systematisch angegriffen. Ergebnis: eine Erfolgsquote von 97,2 Prozent beim Auslesen des hinterlegten System-Prompts und von 100 Prozent beim Extrahieren hochgeladener Dateien. Die Autoren berichten außerdem, dass defensive Anweisungen im Stil von „gib diese Datei niemals heraus" die Angriffe nicht zuverlässig verhindert haben. Diese Zahlen stammen von einem bestimmten Zeitpunkt und einer bestimmten Produktgeneration. Die Anbieter haben seither nachgebessert. Die strukturelle Aussage bleibt aber bestehen, und sie ist der Grund, warum das Thema in den [OWASP Top 10 for LLM Applications 2025](https://owasp.org/www-project-top-10-for-large-language-model-applications/assets/PDF/OWASP-Top-10-for-LLMs-v2025.pdf) gleich zweimal auftaucht. Prompt Injection, also das Unterschieben von Anweisungen über ganz normale Eingaben, steht dort als LLM01 auf Platz eins. Sensitive Information Disclosure folgt als LLM02 direkt dahinter. Praktisch heißt das: Behandle die Wissensbasis eines geteilten Assistenten so, als könnte jeder mit Zugriff sie vollständig lesen. Denn im Zweifel kann er das. Für den Alltag hat das eine angenehm einfache Konsequenz. Der Zugriffskreis auf den Assistenten muss dem Kreis entsprechen, der die hinterlegten Dokumente ohnehin sehen darf. Wenn ein Dokument nur die Geschäftsführung lesen darf, gehört es nicht in einen Assistenten, den das ganze Team nutzt, auch wenn die Anweisung „vertraulich behandeln" enthält. Anweisungen dieser Art sind Bitten an ein Sprachmodell, keine Zugriffskontrolle. Daraus folgt eine kurze Ausschlussliste für geteilte Assistenten: - Gehaltsdaten, Personalakten, Bewerbungsunterlagen - Verträge mit Geheimhaltungsklauseln, die den Kreis der Wissenden begrenzen - Kalkulationsgrundlagen, wenn nicht das ganze Team sie ohnehin kennen darf - Kundendaten, die nur ein Teil des Teams sehen darf - Zugangsdaten in jeder Form Was stattdessen hineingehört, und wie du Dokumente so aufbereitest, dass der Assistent trotzdem nützlich bleibt, steht in [Welche Dokumente in die Wissensbasis gehören](/blog/wissensbasis-dokumente-auswaehlen/). Häufig reicht eine bereinigte Fassung: Struktur und Regeln ja, konkrete Personen und Beträge raus. Die datenschutzrechtliche Seite dieser Frage, also Auftragsverarbeitung, personenbezogene Daten und Löschpflichten, behandle ich getrennt in [DSGVO und Firmenwissen: was in einen KI-Assistenten darf](/blog/dsgvo-firmenwissen-ki-assistent/). ## Ein Einwand, den ich ernst nehme „Wenn wir das alles regeln, ist die Leichtigkeit weg, und dann nutzt es keiner mehr." Der Einwand stimmt teilweise. Jede Regel, die zwischen dich und die Nutzung tritt, kostet Nutzung. Deshalb bin ich gegen Freigabeprozesse für jede Änderung und gegen Schulungspflicht vor dem ersten Aufruf. Der Unterschied liegt in der Richtung. Regeln, die das Nutzen erschweren, schaden. Regeln, die das Ändern und das Befüllen ordnen, schaden nicht, weil sie nur zwei bis drei Personen betreffen. Owner benennen kostet fünf Minuten. Eine Ausschlussliste für die Wissensbasis kostet zwanzig. Das ist der gesamte Overhead, den ich für Teams dieser Größe für sinnvoll halte. ## Wo ich anfangen würde Nimm den einen Assistenten, den bei euch mehrere Leute nutzen, und beantworte drei Fragen schriftlich: Wer ist Owner? Wer darf ändern? Was darf nie rein? Wenn ihr diese drei Antworten habt, ist der größte Teil erledigt. Und wenn sie sich nicht beantworten lassen, weil unklar ist, welche Tools bei euch überhaupt im Einsatz sind und welche Daten dort schon liegen: Dann gehört diese Bestandsaufnahme vor den nächsten Assistenten. Genau sie fragt der [KI-Readiness-Check](/ki-readiness-check/) ab. Und dann prüft, ob eure geteilten Assistenten noch das tun, was in der Beschreibung steht. Diese Prüfung gehört in den Kalender, nicht in den Zufall.