KI-Agent in Slack und Teams: Warum der Chat der richtige Eingang ist und was er nicht leisten kann

Ein KI-Agent gehört dorthin, wo dein Team ohnehin Aufgaben verteilt, und in den meisten Unternehmen ist das ein Kanal in Slack oder Teams. Das hat einen einfachen Grund. Jede zusätzliche Oberfläche macht eine Bitte teurer. Wer erst ein anderes Programm öffnen, sich anmelden und den Zusammenhang neu erklären muss, gibt kleine Aufgaben gar nicht ab. Gerade diese kleinen, wiederkehrenden Aufgaben kann ein Agent aber zuverlässig übernehmen.

Trotzdem scheitern viele Agenten im Chat an derselben Stelle. Im Kanal ist eine Aufgabe schnell gestellt. Was danach kommt, regelt er aber nicht. Wer ist zuständig, was darf der Agent dabei, und wo liegt das Ergebnis so, dass sich jemand darauf verlassen kann? Lässt du diese Fragen offen, bekommst du einen Agenten, der freundlich antwortet und dessen Arbeit nach zwei Tagen im Verlauf verschwunden ist.

Warum der Chat als Eingang so gut funktioniert

Delegation scheitert im Alltag selten an den Fähigkeiten dessen, der die Aufgabe bekommt. Sie scheitert daran, dass das Übergeben länger dauert als das Selbermachen. Im Kanal reicht für eine Bitte ein Satz, weil der Kontext schon da ist. Der Kundenname steht in der Nachricht darüber, die Datei hängt im Thread, und wer Bescheid wissen muss, ist ohnehin im Kanal.

Dazu kommt, dass alle mitlesen. Antwortet der Agent im Kanal, sieht das Team, was er gemacht hat, und kann ihn direkt dort korrigieren. Wenn dein Vertriebsleiter bemerkt, dass der Agent einen veralteten Ansprechpartner nennt, schreibt er das in den Thread, und die anderen wissen es danach auch. In einem privaten KI-Chat bleibt dieselbe Korrektur bei einer Person, und der nächste Kollege stolpert über denselben Fehler.

Der dritte Grund ist die Rückfrage. Fehlt dem Agenten eine Angabe, muss er jemanden fragen können. Im Kanal erreicht die Frage die Leute, die das Thema kennen. In einem eigenen Postfach würde sie oft liegen bleiben, weil es niemand öffnet.

Was ein Agent in Slack und Teams tatsächlich sieht

Viele Geschäftsführer gehen davon aus, dass ein Agent in Slack oder Teams automatisch alles mitliest. Technisch stimmt das nicht, und das ist gut so. In Slack sieht eine App mit der Berechtigung channels:history die Nachrichten der öffentlichen Kanäle, zu denen sie hinzugefügt wurde. Für private Kanäle und Direktnachrichten gibt es eigene Berechtigungen.

Slack hat 2025 außerdem das massenhafte Auslesen von Kanalverläufen eingeschränkt. Kommerziell vertriebene Apps, die nicht im Slack Marketplace gelistet sind, dürfen den Verlauf bei neuen Installationen nur noch einmal pro Minute abrufen, mit höchstens 15 Nachrichten pro Abruf. In der Ankündigung der Änderung begründet Slack das damit, dass ungeprüfte Apps sonst große Mengen vertraulicher Unterhaltungen abziehen könnten. Interne Apps, die ein Unternehmen selbst baut, sind davon nicht betroffen. Auch andere Apps können Verlauf lesen, müssen ihre Arbeit aber innerhalb dieser Limits planen. Unabhängig vom Vertriebsweg solltest du wissen, welche Kanäle eine App liest.

Teams arbeitet nach einem ähnlichen Prinzip. Mit der ressourcenspezifischen Zustimmung gibt ein berechtigter Nutzer einer App Zugriff auf ein bestimmtes Team und dessen Kanäle, ohne dass sie damit alle anderen Teams im Unternehmen sieht. Microsoft beschreibt als Beispiel jemanden, der zwei Teams besitzt und der App nur Zugriff auf eines davon gibt. Daneben gibt es organisationsweite Berechtigungen, die ein Administrator erteilt und die viel weiter reichen.

Slack und Teams regeln diese Zugriffe im Detail unterschiedlich. Gemeinsam ist beiden, dass der Agent nur dort liest, wo man ihm Zugang gegeben hat. Wer einen Agenten in einen Kanal holt, entscheidet damit, welche Gespräche er lesen darf. Diese Entscheidung sollte jemand bewusst treffen und nicht nebenbei, weil ein Kollege die App gerade praktisch fand.

Wo der Chat als Arbeitsort an Grenzen stößt

Ein Kanal ist ein laufender Strom von Nachrichten. Ältere Nachrichten rutschen nach oben weg, Threads verzweigen sich, und ob eine Aufgabe erledigt ist, steht nirgends, höchstens als Daumen-hoch unter einer Nachricht. Unter Menschen geht das halbwegs gut, weil sie sich merken, wer was zugesagt hat. Ein Agent hat dieses Gedächtnis nur, wenn es ausdrücklich gebaut wurde, und das Team verlässt sich trotzdem darauf.

Typischerweise gehen dabei drei Dinge verloren. Eine Bitte im Kanal hat keinen Status, also weiß niemand, ob sie offen ist, auf eine Antwort wartet oder erledigt ist. Ein Ergebnis, das nur als Chatnachricht im Thread steht, findest du nach einer Woche kaum wieder. Im CRM, wo der Kollege aus dem Außendienst nachsieht, taucht es gar nicht auf. Und ein Emoji unter einem Entwurf sagt nicht, wer genau was gebilligt hat.

Deshalb trennst du den Ort, an dem Arbeit hereinkommt, von dem Ort, an dem sie festgehalten wird. Der Kanal bleibt der Eingang und der Ort für kurze Rückmeldungen. Aufgaben, Rechte und Ergebnisse brauchen eine Struktur, die auch dann noch stimmt, wenn der Thread längst aus dem Blick ist.

Wer für eine Anfrage an den Agenten zuständig ist

Sobald der Agent eine Bitte aus dem Kanal aufnimmt, sollte daraus eine Aufgabe mit Verantwortlichem, Status und Fälligkeit werden. Der Agent antwortet im Thread kurz, dass er übernimmt, und verlinkt die Aufgabe. Ist er fertig, schreibt er das Ergebnis dorthin, wo es hingehört, und meldet im Thread, wo es liegt. So kann jeder im Kanal sehen, was aus der Bitte geworden ist, ohne den Verlauf durchzuscrollen.

Die Zuständigkeit hat zwei Seiten. Der Agent ist für die Ausführung zuständig. Ein Mensch ist für das Ziel zuständig, also für die Frage, ob die Aufgabe richtig gestellt war und ob das Ergebnis den Zweck erfüllt. Im Normalfall ist das die Person, die gefragt hat. Bei wiederkehrenden Aufgaben ist es besser, einen festen Verantwortlichen pro Kanal oder Thema zu benennen, weil sonst jeder fragt und niemand das Ergebnis prüft.

Fehlt dem Agenten eine Angabe, hält er die Aufgabe an und fragt eine bestimmte Person, statt den ganzen Kanal anzuschreiben. Eine Frage an alle beantwortet erfahrungsgemäß niemand, weil jeder annimmt, dass sich ein anderer kümmert. Nach der Antwort läuft die Aufgabe weiter, und im Kanal steht nur, was sich geändert hat.

Kläre auch, wer dem Agenten in einem Kanal überhaupt Arbeit geben darf. In einem Kanal mit vierzig Mitgliedern kommen sonst Bitten an, die sich widersprechen, etwa zwei verschiedene Fassungen derselben Kundenliste. Ein Mensch würde nachfragen, welche gilt. Ein Agent erledigt ohne klare Regel beide.

Wessen Rechte der Agent nutzt

Hier liegt das Risiko, das Geschäftsführer am häufigsten übersehen. Angenommen, dein Agent hat Lesezugriff auf das CRM und sitzt in einem Kanal, in dem auch Werkstudenten und externe Dienstleister mitlesen. Fragt einer von ihnen nach den Umsätzen eines Kunden, antwortet der Agent mit seinen eigenen Rechten, und die Antwort steht für alle sichtbar im Kanal. Keiner hat dabei eine Regel gebrochen. Der Agent hat bloß Rechte, die mehr erlauben, als der Kanal sehen sollte.

Dafür gibt es zwei saubere Lösungen. Entweder der Agent handelt mit den Rechten der Person, die fragt, und sieht dann nur, was diese Person ohnehin sehen dürfte. Microsoft unterscheidet bei Teams-Apps genau so zwischen delegiertem Zugriff, der nur im Namen eines angemeldeten Nutzers erfolgt, und Anwendungszugriff, bei dem die App ohne angemeldeten Nutzer arbeitet. Oder du beschränkst die Rechte des Agenten in diesem Kanal auf das, was alle Mitglieder sehen dürfen. Welche Lösung passt, hängt vom Kanal ab. Wichtig ist nur, dass jemand die Frage beantwortet, bevor der Agent dort freigeschaltet wird.

Lesen und Handeln sind zwei verschiedene Rechte. Ein Agent, der einen Projektkanal liest und daraus Aufgaben anlegt, macht Routinearbeit, die er ohne Rückfrage erledigen sollte. Dasselbe gilt für einen Eintrag im CRM oder einen Entwurf im Postfach. Anders ist es bei Aktionen, die nach außen wirken und sich nicht zurücknehmen lassen. Dazu gehören eine verbindliche Preiszusage an einen Kunden, eine Zahlung oder eine E-Mail an jemanden, der das Unternehmen noch nicht kennt. Hier ist eine ausdrückliche Freigabe sinnvoll, und sie sollte zeigen, was genau passieren wird.

Zugangsdaten gehören nicht in den Agenten. Seriöse Lösungen lassen die Verbindung zum CRM oder Postfach beim Nutzer oder beim Unternehmen und leiten die Aufrufe des Agenten über einen kontrollierten Weg. Dann kannst du einen Zugriff entziehen, ohne Passwörter auszutauschen, und nachvollziehen, was der Agent mit welcher Verbindung getan hat.

Ergebnisse, auf die sich das Team verlassen kann

Eine Antwort im Chat liest man einmal. Worauf das Team später zurückgreift, ist der Eintrag im System, und wenn beides voneinander abweicht, verliert der Agent schnell das Vertrauen. Deshalb sollte jedes Ergebnis, das über eine kurze Auskunft hinausgeht, im passenden System landen. Eine Kundeninformation gehört als Aktivität ins CRM, eine Antwort an einen Kunden als Entwurf ins Postfach und eine Auswertung als Dokument in den gemeinsamen Speicher. Im Kanal steht dann ein Satz und ein Link.

Belastbar heißt außerdem, dass jede Aussage eine Quelle hat. Fasst der Agent ein Meeting zusammen, sollte jede Aufgabe auf die Stelle im Transkript verweisen, aus der sie stammt. Nennt er einen Ansprechpartner, sollte erkennbar sein, ob die Angabe aus dem CRM, aus einer E-Mail oder von einer Website kommt. Das kostet den Agenten kaum Aufwand und spart dir die Frage, ob er sich die Angabe ausgedacht hat. Sprachmodelle formulieren falsche Angaben genauso flüssig wie richtige, und ohne Quelle merkst du den Unterschied erst, wenn ein Kunde nachfragt.

Wie das in vier konkreten Abläufen aussieht

Vier Abläufe tauchen in fast jedem Mittelständler auf, und an ihnen sieht man gut, was der Agent selbst erledigt und wo ein Mensch übernimmt. Needs bietet sie als betreute Rollen an, und die Grenzen sind dort so gezogen, wie sie im Folgenden beschrieben sind.

Eingehende Anfragen

Der Agent liest ein ausgewähltes Postfach in Outlook oder Gmail. Er ordnet Anfragen ein, schreibt Antwortentwürfe und belegt jede Angabe darin. Fälle, die er nicht beantworten kann, übergibt er an die zuständige Person. Er löscht und verschiebt keine Nachrichten, das Postfach bleibt also so, wie dein Team es kennt. Versendet wird eine Antwort erst, wenn ein Mensch sie freigegeben hat, weil sie den Kunden direkt erreicht. Im Kanal erfährt das Team, welche Anfragen auf eine Entscheidung warten.

Neue Kunden gewinnen

Ihr legt das Zielbild fest, also welche Unternehmen und Ansprechpartner infrage kommen. Der Agent sucht passende Leads, belegt, warum sie passen, und legt Kontakte und Aktivitäten in Pipedrive an. Den Erstkontakt übernimmt ein Mensch, weil der erste Eindruck bei einem Wunschkunden nicht automatisiert werden sollte. Zeigt ein Interessent Interesse, stimmt der Agent den Termin über das bestätigte Microsoft-365-Firmenkonto des einladenden Unternehmens ab. Teams-Einladungen folgen der bestehenden Werkzeugfreigabe.

Meetings nachbereiten

Nach einem Teams-Meeting liest der Agent das Transkript, sofern es existiert und er darauf zugreifen darf. Microsoft knüpft das an mehrere Bedingungen. Teams muss das Transkript erstellt haben, die App braucht eine passende Berechtigung, und laut der Dokumentation zu Transkripten kann ein Administrator den Zugriff auf Transkripte über die Graph-Schnittstelle für die ganze Organisation abschalten. Needs liest nur solche vorhandenen, erlaubten Transkripte und startet selbst keine Aufnahme. Daraus entstehen eine Zusammenfassung und Aufgaben, die jeweils auf die passende Stelle im Gespräch verweisen. Auf Anfrage legt der Agent einen CRM-Eintrag und einen Entwurf für die Nachfass-Mail an. Den Versand übernimmt ein Mensch.

Inhalte erstellen

Der Agent schreibt Entwürfe für Beiträge, Newsletter oder Produkttexte aus Fakten, die ihr freigegeben habt, und hält sich an euren Markenleitfaden. Veröffentlicht wird von einem Menschen, der für den Text geradesteht. Das hat neben der Qualität auch einen rechtlichen Grund, der im nächsten Abschnitt steht.

Allen vier Abläufen ist gemeinsam, dass der Agent die Vorarbeit vollständig erledigt und das Ergebnis im richtigen System ablegt. Bei der Aktion, die nach außen wirkt, übernimmt ein Mensch. Dafür muss niemand jeden Zwischenschritt prüfen.

Was rechtlich und im Betrieb dazugehört

Seit dem 2. August 2026 gilt Artikel 50 der KI-Verordnung. Er verpflichtet Anbieter von KI-Systemen, die direkt mit Menschen interagieren, diese Systeme so zu gestalten, dass die Betroffenen wissen, dass sie mit einer KI zu tun haben, außer das ist für einen verständigen Menschen ohnehin offensichtlich. Die Pflicht trifft zuerst den Anbieter des Systems. Für dich heißt das praktisch, dass du bei der Auswahl darauf achtest, dass der Agent überall als KI erkennbar ist, im Kanal ebenso wie in E-Mails nach außen.

Für Inhalte enthält derselbe Artikel eine Regel, die den Content-Ablauf oben erklärt. Wer KI-generierte Texte veröffentlicht, die die Öffentlichkeit über Angelegenheiten von öffentlichem Interesse informieren, muss das offenlegen. Die Pflicht entfällt, wenn ein Mensch den Text redaktionell geprüft hat und eine Person oder ein Unternehmen die redaktionelle Verantwortung trägt. Ein Ablauf, in dem ein Mensch prüft und veröffentlicht, ist also nicht nur sorgfältiger, sondern verändert auch die rechtliche Lage.

Hat dein Betrieb einen Betriebsrat, kommt § 87 Abs. 1 Nr. 6 BetrVG dazu. Danach bestimmt der Betriebsrat bei der Einführung und Anwendung technischer Einrichtungen mit, die dazu bestimmt sind, Verhalten oder Leistung der Arbeitnehmer zu überwachen. Ein Agent, der Kanäle liest und protokolliert, wer ihm welche Aufgabe gegeben hat, erzeugt genau die Art von Daten, um die es dabei geht. Sprich deshalb früh mit dem Betriebsrat und lege gemeinsam fest, welche Kanäle der Agent liest und wofür die Protokolle verwendet werden dürfen. Das ist leichter, als eine laufende Einführung nachträglich zu verhandeln.

Womit du anfangen solltest

Fang mit einem Kanal und einer wiederkehrenden Art von Anfrage an, die heute schon dort gestellt wird. Typische Kandidaten sind die Nachbereitung von Kundenterminen, die Vorbereitung von Antworten auf Standardanfragen oder das Pflegen von Kontakten im CRM. Leg vor dem Start vier Dinge schriftlich fest. Wer darf dem Agenten in diesem Kanal Arbeit geben? Wer ist für das Ergebnis verantwortlich? Mit welchen Rechten arbeitet der Agent? Wo landet das Ergebnis?

Nach ein paar Wochen siehst du an den Aufgaben selbst, ob es funktioniert. Prüf, wie viele Bitten zu Aufgaben mit Ergebnis geworden sind, wie oft der Agent zurückfragen musste und ob die Ergebnisse dort liegen, wo das Team sie sucht. Fragt er oft zurück, fehlt ihm Kontext, den du ihm einmal geben kannst. Liegen die Ergebnisse im Thread statt im System, ist der Ablauf noch nicht fertig.

Erst dann lohnt sich der zweite Kanal. Du übernimmst dafür die Antworten auf die vier Fragen und änderst nur, was dort anders ist. So wächst der Agent in Bereiche, für die ihr die Regeln schon geklärt habt. Ohne diese Vorarbeit sitzt er bald in Kanälen, deren Inhalt keiner im Blick hat.