Autonome KI-Agenten können Aufgaben planen, Werkzeuge aufrufen und Ergebnisse in Unternehmenssysteme zurückschreiben. Dadurch wächst ihr Nutzen, zugleich aber auch die Angriffsfläche durch Prompt Injection, manipulierte Tools und vergiftete Speicherinhalte. Zukunftsfähig werden sie nicht durch grenzenlose Autonomie, sondern durch begrenzte Rechte, überprüfbare Aktionen und eine belastbare Betriebsarchitektur.
Warum verändern autonome KI-Agenten die Unternehmenssoftware?
Bisher war die Rollenverteilung in der Unternehmens-IT relativ eindeutig: Ein Mitarbeiter bediente eine Anwendung, die Anwendung verarbeitete Eingaben nach fest programmierten Regeln, und eine Schnittstelle übertrug Daten in ein anderes System. Selbst umfangreiche Workflow-Automationen blieben im Kern deterministisch. Ein Prozessdesigner legte fest, welche Aktion auf welches Ereignis folgen sollte.
Autonome KI-Agenten verändern dieses Prinzip. Sie erhalten ein Ziel, zerlegen es in Arbeitsschritte, wählen geeignete Werkzeuge und reagieren während der Ausführung auf Zwischenergebnisse. Das Sprachmodell ist dabei nicht nur eine Oberfläche zur Texteingabe. Es wird zum Entscheidungsbaustein innerhalb eines sogenannten Agentic Loop: wahrnehmen, planen, handeln, Ergebnis prüfen und den nächsten Schritt ableiten.
Im mittelständischen Alltag kann ein Agent beispielsweise eine eingehende Serviceanfrage auswerten, passende Informationen aus einer Wissensbasis abrufen, den Kundenstammsatz im CRM prüfen, eine Rückfrage formulieren und ein Ticket an die zuständige Fachgruppe übergeben. Ein anderer Agent vergleicht Lieferantenangebote, identifiziert Abweichungen von Einkaufsrichtlinien und bereitet eine Entscheidungsvorlage vor. Technisch entstehen solche Abläufe durch die Verbindung von Large Language Models, APIs, Datenbanken, RAG-Systemen, lokalen Anwendungen und Protokollen wie dem Model Context Protocol.
Der wirtschaftliche Nutzen liegt nicht allein in einer schnelleren Textproduktion. Entscheidend ist, dass Agentic AI Übergänge zwischen Anwendungen bearbeiten kann, an denen heute häufig manuelle Recherche, Rückfragen und Medienbrüche entstehen. Genau diese Handlungsfähigkeit macht die Technologie jedoch sicherheitsrelevant.
KI-Agenten gezielt als Mitarbeiter einsetzen
Die KrambergAI KI-Mitarbeiter übernehmen klar definierte Aufgaben in Service oder Verwaltung und arbeiten mit vorhandenem Unternehmenswissen entlang abgestimmter Prozesse.
Praxisnah eingeführt · Aufgabenbezogen konzipiert · Made in Germany
Wo entsteht die neue Angriffsfläche?
Ein klassischer Chatbot kann eine falsche Antwort liefern. Ein autonomer Agent kann auf Basis einer falschen Interpretation zusätzlich eine E-Mail versenden, eine Datei verändern, einen Datenbankeintrag anlegen oder einen externen Dienst aufrufen. Das Risiko entsteht deshalb nicht nur im Modell, sondern in der Verbindung aus Modell, Kontext, Berechtigungen und ausführbaren Werkzeugen.
Die Angriffsfläche verteilt sich auf mehrere Ebenen. Der Agent verarbeitet Eingaben von Nutzern, Inhalte aus E-Mails, Webseiten, Dokumenten oder Tickets, Systemanweisungen, gespeicherte Erinnerungen und Rückgaben externer Tools. Jeder dieser Kanäle kann manipulierte Informationen enthalten. Gleichzeitig verfügt der Agent häufig über technische Identitäten, API-Schlüssel oder Zugriffstoken, mit denen er Aktionen in Drittsystemen ausführt.
Damit verschiebt sich die Sicherheitsfrage. Es reicht nicht mehr, nur zu prüfen, ob ein Modell unerwünschte Texte erzeugt. Unternehmen müssen untersuchen, welche Aktionen aus einem fehlerhaften oder manipulierten Modelloutput entstehen können. Eine scheinbar harmlose Fehlinterpretation wird relevant, sobald sie eine Tool-Kette auslöst, in der Daten gelesen, verändert und anschließend an einen externen Empfänger übertragen werden.
Die Sicherheitsforschung bestätigt, wie anspruchsvoll diese Situation ist. Der Agent Security Bench ermittelte bei untersuchten Angriffsmethoden einen höchsten durchschnittlichen Angriffserfolg von 84,30 Prozent. Der Benchmark betrachtet unter anderem Prompt Injection, manipulierte Planungsabläufe, Tool-Nutzung und Memory-Angriffe.
Wie kann Prompt Injection einen handelnden Agenten übernehmen?
Bei einer Prompt Injection wird versucht, die ursprünglichen Anweisungen eines KI-Systems durch eingeschleuste Befehle zu verdrängen oder umzudeuten. Bei einem einfachen Chat ist die Folge möglicherweise eine problematische Antwort. Bei einem Agenten kann dieselbe Technik den Ausführungspfad beeinflussen.
Besonders schwierig ist die indirekte Prompt Injection. Der Angreifer muss nicht mit dem Agenten selbst kommunizieren. Er platziert die Anweisung in einer Quelle, die der Agent später verarbeitet: in einer E-Mail, einem PDF-Dokument, einer Webseite, einem Supportticket, einem Kommentar im Quellcode oder einem Datensatz. Der Agent interpretiert den Inhalt möglicherweise nicht nur als Information, sondern als Arbeitsanweisung.
Ein Einkaufsagent könnte beispielsweise ein manipuliertes Angebotsdokument analysieren. Darin befindet sich unsichtbarer oder unauffällig formulierter Text, der den Agenten auffordert, vertrauliche Vergleichsdaten an eine externe Adresse zu senden. Ein Supportagent könnte in einer Kundennachricht angewiesen werden, interne Systemprompts oder frühere Gesprächsinhalte auszugeben. Ein Coding-Agent kann in einem Repository auf Anweisungen stoßen, die ihn zur Ausführung eines unerwünschten Terminalbefehls bewegen.
Das Kernproblem besteht darin, dass natürliche Sprache gleichzeitig Daten und Steuerinformation sein kann. Eine traditionelle Anwendung unterscheidet Programmcode und Nutzdaten über technische Strukturen. Ein Sprachmodell verarbeitet beides zunächst als Tokenfolge. Filter können viele offensichtliche Manipulationen erkennen, bieten aber allein keinen verlässlichen Schutz gegen neu formulierte, verschachtelte oder kontextabhängige Angriffe.
Aus diesem Grund sollte kein einzelner Modelloutput unmittelbar eine kritische Aktion autorisieren. Zwischen Planung und Ausführung gehört eine separate Kontrollschicht, die Berechtigungen, Zielsystem, Datentyp, Empfänger und erwartete Prozessfolge bewertet.
Warum sind manipulierte Tools und MCP-Server besonders riskant?
Agenten gewinnen ihre praktische Wirkung durch Tools. Ein Tool kann eine CRM-Abfrage durchführen, einen Kalendertermin anlegen, eine Rechnung auslesen, eine Datei speichern oder einen Prozess im ERP-System starten. Über standardisierte Protokolle lassen sich solche Funktionen relativ schnell an einen Agenten anbinden.
Diese Erweiterbarkeit erzeugt jedoch ein Supply-Chain-Risiko. Ein manipuliertes Tool kann andere Funktionen ausführen als angegeben, übermäßige Daten sammeln oder Ergebnisse so formulieren, dass der Agent anschließend einen weiteren schädlichen Schritt einleitet. Auch ein technisch legitimes Tool wird problematisch, wenn seine Beschreibung manipuliert wurde oder der Agent mehr Rechte erhält, als der Anwendungsfall benötigt.
In der Praxis scheitern Projekte häufig daran, dass Tool-Registrierungen wie normale Plug-ins behandelt werden. Ein Entwickler bindet eine Erweiterung ein, weil sie einen schnellen Funktionsgewinn verspricht. Herkunft, Wartungsstatus, Abhängigkeiten, Signaturen und Datenflüsse werden nicht ausreichend geprüft. Später ist kaum noch nachvollziehbar, welche Agenten welchen Tool-Stand verwenden.
Für produktive Systeme braucht es deshalb ein verwaltetes Tool-Repository. Jede Funktion sollte einen verantwortlichen Eigentümer, eine freigegebene Version, dokumentierte Ein- und Ausgaben sowie eine definierte Berechtigung besitzen. Schreibende Funktionen sind getrennt von lesenden Funktionen zu behandeln. Ein Agent, der Auftragsdaten recherchiert, benötigt nicht automatisch die Berechtigung, Aufträge zu stornieren oder Bankverbindungen zu ändern.
Auch bei lokalen Agenten bleibt dieses Risiko bestehen. Lokal ausgeführte Modelle reduzieren bestimmte Datenübertragungen, beseitigen aber weder schädliche Erweiterungen noch übermäßige Betriebssystemrechte. Ein lokaler Agent mit Zugriff auf Dateisystem, Browser, Terminal und gespeicherte Zugangsdaten kann bei einer erfolgreichen Manipulation erheblichen Schaden verursachen.
Wie werden Agent-Memory-Systeme zum langfristigen Einfallstor?
Viele Agenten speichern Informationen über frühere Aufgaben. Ein solches Memory kann Präferenzen, Prozesswissen, Zwischenergebnisse, Kontakte oder wiederkehrende Regeln enthalten. Dadurch muss der Agent nicht bei jeder Ausführung von vorne beginnen. Für langfristige Arbeitsabläufe ist diese Persistenz besonders wertvoll.
Aus Sicherheitssicht entsteht jedoch ein neuer Zustand, der über einzelne Sitzungen hinausreicht. Wird eine manipulierte Information als Erinnerung gespeichert, kann sie Tage oder Wochen später erneut abgerufen werden. Der auslösende Angriff und die schädliche Handlung liegen dann zeitlich auseinander. Das erschwert Ursachenanalyse und Incident Response.
Die im Juli 2026 veröffentlichte GhostWriter-Untersuchung demonstriert dieses Prinzip bei werkzeugnutzenden Agenten. Der beschriebene Angriff erreichte eine Injektionsrate von ungefähr 98 Prozent. Wurde der vergiftete Speicher später abgerufen, lag die durchschnittliche Aktivierungsrate bei ungefähr 60 Prozent. Die Studie führt die Anfälligkeit insbesondere auf fehlende Sicherheitsregeln für das Speichern und Abrufen von Memory-Inhalten zurück.
Ein Unternehmen sollte Agent-Memory deshalb nicht wie einen gewöhnlichen Notizspeicher behandeln. Jeder Eintrag benötigt Herkunftsinformationen, Vertrauensstatus, Zeitbezug und einen nachvollziehbaren Anlass. Inhalte aus externen Quellen dürfen nicht automatisch zu dauerhaften Regeln werden. Besonders sensible Erinnerungen sollten nur aus freigegebenen Systemen stammen oder vor dem Speichern bestätigt werden.
Ebenso wichtig ist die Möglichkeit, gespeicherte Inhalte zu prüfen, zu korrigieren und vollständig zu entfernen. Ohne Memory-Governance kann ein Agent falsche Annahmen immer wieder reproduzieren und dabei formal zulässige Aktionen ausführen. Aus Sicht des Systems wirkt der Ablauf regelgerecht, obwohl die zugrunde liegende Erinnerung manipuliert wurde.
Worin unterscheiden sich klassische Automatisierung und autonome Agenten?
| Merkmal | Klassische Workflow-Automatisierung | Autonomer KI-Agent |
|---|---|---|
| Prozesslogik | Vorab definierte Regeln und Übergänge | Dynamische Planung auf Basis eines Ziels |
| Umgang mit Abweichungen | Ausnahme oder Prozessabbruch | Anpassung des weiteren Vorgehens |
| Nutzung von Schnittstellen | Fest konfigurierte Aufrufe | Auswahl geeigneter Tools während der Aufgabe |
| Prozesszustand | Strukturierte Variablen und Statusfelder | Kontext, Verlauf und optional persistentes Memory |
| Typisches Fehlerbild | Technischer Fehler oder falsche Regel | Plausibel wirkende, aber ungeeignete Handlungskette |
| Sicherheitsansatz | Rollen, Validierung und Prozesskontrollen | Zusätzlich Tool-Governance, Kontextprüfung und Laufzeitkontrolle |
| Menschliche Freigabe | Meist an festgelegten Prozesspunkten | Abhängig von Risiko, Aktion und aktueller Situation |
Die Tabelle zeigt, warum vorhandene Automatisierungsregeln weiterhin wichtig bleiben. Agenten sollten sie nicht vollständig ersetzen, sondern innerhalb definierter Prozessgrenzen arbeiten. Deterministische Systeme eignen sich für unveränderliche Vorgaben, während Agenten dort Mehrwert schaffen, wo Informationen interpretiert, Optionen bewertet oder Ausnahmen bearbeitet werden müssen.
Was läuft bei Agentenprojekten in der Praxis üblicherweise falsch?
Ein häufiger Fehler ist der Start mit einer möglichst breiten Aufgabe: Der Agent soll E-Mails bearbeiten, Termine koordinieren, Dokumente verwalten und Entscheidungen vorbereiten. Damit wächst die Zahl der Datenquellen, Werkzeuge und Berechtigungen schneller als das Verständnis des tatsächlichen Prozesses.
Ein zweites Problem ist die Verwechslung von Demonstration und Betriebsfähigkeit. In einer vorbereiteten Umgebung funktioniert ein Ablauf überzeugend. Im Alltag treffen jedoch unvollständige Stammdaten, widersprüchliche Dokumente, fehlende Schnittstellen, Sonderfälle und wechselnde Verantwortlichkeiten aufeinander. Der Agent beginnt zu improvisieren, obwohl die Organisation an dieser Stelle verbindliche Regeln benötigt.
Auch fehlende Zuständigkeiten führen zu Problemen. Ohne fachlichen Prozesseigentümer kann niemand verbindlich entscheiden, welche Aktionen zulässig sind. Ohne technischen Eigentümer bleiben Modelle, Prompts, Tools und Abhängigkeiten ungepflegt. Ohne Security-Verantwortung werden Protokolle zwar gespeichert, aber nicht systematisch ausgewertet.
Hinzu kommt eine unterschätzte Kostenlogik. Agenten können in Schleifen geraten, unnötig viele Tool-Aufrufe erzeugen oder umfangreiche Dokumente wiederholt verarbeiten. Tokenbudgets, Zeitlimits, maximale Aktionsfolgen und Abbruchbedingungen gehören daher zur Betriebsarchitektur und nicht erst in eine spätere Optimierungsphase.
Gartner erwartet, dass mehr als 40 Prozent der Agentic-AI-Projekte bis Ende 2027 eingestellt werden. Als Ursachen nennt das Unternehmen steigende Kosten, fehlenden messbaren Geschäftsnutzen und unzureichende Risikokontrollen. Die Prognose spricht nicht gegen Agenten, sondern gegen Projekte ohne belastbaren Anwendungsfall und Betriebsmodell.
Wie lässt sich Agentic AI im Mittelstand kontrolliert einsetzen?
Ein sinnvoller Einstieg beginnt nicht mit maximaler Autonomie, sondern mit einem eng abgegrenzten Geschäftsprozess. Geeignet sind Aufgaben, deren Eingangsdaten bekannt sind, deren Ergebnis überprüft werden kann und bei denen Fehler keine unmittelbaren irreversiblen Folgen auslösen.
Beispiele sind die Vorqualifizierung eingehender Anfragen, das Zusammenfassen von Servicefällen, die Vorbereitung von CRM-Follow-ups, die Prüfung von Dokumenten auf Vollständigkeit oder die Zuordnung interner Wissensartikel. Der Agent kann recherchieren, strukturieren und einen Handlungsvorschlag erzeugen. Die endgültige Freigabe verbleibt zunächst bei einem Mitarbeiter.
In der nächsten Ausbaustufe können risikoarme Aktionen automatisiert werden. Dazu zählen das Anlegen eines Entwurfs, die Aktualisierung eines internen Status oder das Erstellen einer Aufgabe. Zahlungsfreigaben, Vertragsänderungen, Benutzeradministration, Löschvorgänge und externe Veröffentlichungen sollten dagegen eigene Kontrollmechanismen besitzen.
Technisch bewährt sich eine Trennung zwischen Planungs- und Ausführungsebene. Der Agent entwickelt einen Vorschlag, während ein Policy Gateway jede Tool-Anfrage gegen Berechtigungen, Prozessregeln und Kontextbedingungen prüft. Der Agent erhält eine eigene technische Identität. Kurzlebige Zugangsdaten, Least Privilege, Allowlisting, Egress-Kontrollen und getrennte Lese- und Schreibrechte begrenzen die Auswirkungen einer Fehlentscheidung.
Ebenso erforderlich sind vollständige Audit-Trails. Unternehmen müssen später nachvollziehen können, welche Eingabe zu welcher Planung führte, welche Datenquellen verwendet wurden, welches Tool mit welchen Parametern aufgerufen wurde und welcher Mitarbeiter eine Freigabe erteilte. Reine Chatprotokolle reichen dafür nicht aus.
Die US-amerikanische Cybersecurity and Infrastructure Security Agency empfiehlt für agentische Dienste eine schrittweise Einführung mit Sicherheitskontrollen über Design, Bereitstellung und Betrieb hinweg. MITRE ATLAS stellt dazu eine fortlaufend gepflegte Wissensbasis für Angriffstechniken gegen KI-Systeme bereit. Aktuelle Referenzarchitekturen setzen außerdem auf getrennte Agentenidentitäten, zentrale Protokollierung, isolierte Umgebungen und überwachte Tool-Zugriffe.
Warum werden autonome KI-Agenten die Zukunft trotzdem prägen?
Die Risiken autonomer KI-Agenten sind erheblich, weil die Systeme erstmals Sprache, Entscheidungen und technische Ausführung in einer gemeinsamen Architektur verbinden. Gerade diese Kombination löst jedoch ein Problem, an dem viele Digitalisierungsprojekte bisher scheitern: Unternehmensprozesse lassen sich nicht vollständig in starre Wenn-dann-Regeln übersetzen.
Mitarbeiter müssen Informationen aus verschiedenen Quellen zusammenführen, Ausnahmen bewerten und zwischen Anwendungen wechseln. Klassische Software unterstützt einzelne Arbeitsschritte, versteht aber selten das übergeordnete Ziel. Agenten können diese Lücke teilweise schließen, indem sie Kontext verarbeiten und Werkzeuge situationsabhängig koordinieren.
Die Zukunft gehört daher wahrscheinlich weder vollständig autonomen Systemen noch rein manuellen Abläufen. Erfolgreich werden abgestufte Modelle sein: Assistenten für Recherche, Copiloten für Entscheidungsvorbereitung und Agenten für begrenzte Ausführung. Der Autonomiegrad richtet sich nach Schadenspotenzial, Datenklasse, Reversibilität und Nachweisbarkeit.
Für den Mittelstand liegt darin eine realistische Chance. Unternehmen müssen keine universellen digitalen Mitarbeiter entwickeln. Sie können spezialisierte Agenten für einzelne Prozessabschnitte einsetzen und diese mit vorhandenem Fachwissen, Unternehmensregeln und kontrollierten Schnittstellen verbinden. So entsteht nicht ein allmächtiges System, sondern eine nachvollziehbare digitale Arbeitsteilung.
Die entscheidende Fähigkeit wird deshalb nicht sein, möglichst viele Agenten zu installieren. Unternehmen benötigen ein Betriebsmodell, das Identitäten, Tools, Memory, Freigaben, Monitoring und Verantwortlichkeiten gemeinsam verwaltet. Wer diese Grundlage aufbaut, kann Agentic AI produktiv nutzen, ohne zentrale Unternehmensprozesse einem unkontrollierten Modellverhalten zu überlassen.
Quellen der verwendeten Kennzahlen
Agent Security Bench: Formalisierung und Bewertung von Angriffen und Schutzmaßnahmen bei LLM-Agenten
https://arxiv.org/abs/2410.02644
When Agents Remember Too Much: Memory-Poisoning-Angriffe auf LLM-Agenten
https://arxiv.org/abs/2607.06595
Gartner: Mehr als 40 Prozent der Agentic-AI-Projekte könnten bis Ende 2027 eingestellt werden
https://www.gartner.com/en/newsroom/press-releases/2025-06-25-gartner-predicts-over-40-percent-of-agentic-ai-projects-will-be-canceled-by-end-of-2027
Interessante Links
CISA: Sorgfältige Einführung agentischer KI-Dienste
https://www.cisa.gov/resources-tools/resources/careful-adoption-agentic-ai-services
MITRE ATLAS: Wissensbasis zu Angriffstechniken gegen KI-Systeme
https://atlas.mitre.org/
Google Cloud: Referenzarchitektur für mandantenfähige agentische KI-Systeme
https://docs.cloud.google.com/architecture/multi-tenant-agentic-ai-system
Häufige Fragen
Was ist ein autonomer KI-Agent?
Ein autonomer KI-Agent ist ein Softwaresystem, das ein vorgegebenes Ziel in Arbeitsschritte zerlegt, Informationen beschafft und über angebundene Werkzeuge Aktionen ausführt. Im Unterschied zu einem reinen Sprachmodell erzeugt er nicht nur Text. Er kann beispielsweise Daten abrufen, Dateien bearbeiten, Tickets anlegen oder Prozessschritte in anderen Anwendungen auslösen.
Worin unterscheidet sich Agentic AI von einem Chatbot?
Ein Chatbot reagiert überwiegend auf einzelne Eingaben und liefert eine Antwort. Agentic AI kann dagegen einen mehrstufigen Arbeitsablauf planen, Zwischenergebnisse bewerten und geeignete Tools auswählen. Der Unterschied liegt damit weniger in der Benutzeroberfläche als in der Handlungsfähigkeit, dem Prozesszustand und den Berechtigungen gegenüber Unternehmenssystemen.
Was ist Prompt Injection bei KI-Agenten?
Prompt Injection bezeichnet den Versuch, die Anweisungen eines KI-Systems durch eingeschleuste Befehle zu verändern. Bei Agenten kann ein solcher Angriff nicht nur eine Antwort beeinflussen, sondern auch Tool-Aufrufe auslösen. Das Risiko steigt, wenn der Agent externe Inhalte verarbeitet und zugleich Schreibrechte in E-Mail-, CRM-, Datei- oder ERP-Systemen besitzt.
Was bedeutet indirekte Prompt Injection?
Bei einer indirekten Prompt Injection befindet sich die schädliche Anweisung in einer Datenquelle, die der Agent im Rahmen seiner Aufgabe abruft. Das kann eine Webseite, eine E-Mail, ein Dokument oder ein Supportticket sein. Der Angreifer kommuniziert nicht direkt mit dem Agenten, sondern wartet darauf, dass das System den präparierten Inhalt verarbeitet.
Wie gefährlich sind MCP-Server und Agenten-Tools?
MCP-Server und andere Agenten-Tools sind nicht grundsätzlich unsicher. Sie erweitern jedoch den Aktionsradius des Agenten und werden dadurch Teil der Software-Lieferkette. Risiken entstehen durch manipulierte Tool-Beschreibungen, ungeprüfte Abhängigkeiten, übermäßige Berechtigungen oder kompromittierte Updates. Produktive Umgebungen benötigen deshalb geprüfte Versionen, Verantwortlichkeiten und technische Freigabeverfahren.
Was ist Memory Poisoning bei KI-Agenten?
Memory Poisoning beschreibt die gezielte Manipulation des Langzeitspeichers eines Agenten. Eine eingeschleuste Information wird als Erinnerung gespeichert und bei einer späteren Aufgabe erneut verwendet. Dadurch können Angriff und schädliche Handlung zeitlich getrennt sein. Schutzmaßnahmen umfassen Herkunftsnachweise, Speicherregeln, Vertrauensbewertungen und Prüfungen beim späteren Abruf eines Memory-Eintrags.
Benötigt jeder KI-Agent einen Human-in-the-Loop?
Nicht jede einzelne Aktion benötigt eine menschliche Bestätigung. Der Freigabebedarf sollte sich nach Schadenspotenzial, Reversibilität, Datenklasse und Außenwirkung richten. Das Erstellen eines internen Entwurfs kann automatisiert erfolgen. Zahlungen, Vertragsänderungen, Löschvorgänge, Zugriffsvergaben oder externe Veröffentlichungen benötigen dagegen in der Regel zusätzliche Kontrollen oder eine ausdrückliche Freigabe.
Welche Prozesse eignen sich für den Einstieg?
Geeignet sind wiederkehrende Prozesse mit bekannten Datenquellen, überprüfbaren Ergebnissen und begrenzten Auswirkungen bei Fehlern. Dazu zählen Anfrageklassifizierung, Dokumentenprüfung, Wissensrecherche, Ticketvorbereitung und CRM-Nacharbeit. Weniger geeignet sind zunächst Aufgaben mit weitreichenden finanziellen, rechtlichen, personellen oder sicherheitskritischen Entscheidungen, insbesondere wenn eine Handlung nur schwer rückgängig gemacht werden kann.
Wie sollten mittelständische Unternehmen Agenten berechtigen?
Jeder Agent sollte eine eigene technische Identität und nur die für seine Aufgabe erforderlichen Rechte erhalten. Lese- und Schreibzugriffe sind zu trennen, Zugangsdaten sollten kurzlebig und widerrufbar sein. Zusätzlich benötigt das Unternehmen ein Verzeichnis aller Agenten, Tools, Datenquellen und Verantwortlichen sowie eine zentrale Protokollierung sämtlicher ausgeführter Aktionen.
Werden autonome KI-Agenten Mitarbeiter ersetzen?
Autonome Agenten werden vor allem einzelne Tätigkeiten und Übergaben zwischen Systemen verändern. Fachliche Verantwortung, Ausnahmeentscheidungen, Kundenbeziehungen und die Bewertung ungewöhnlicher Situationen bleiben menschliche Aufgaben. Wahrscheinlicher als ein vollständiger Ersatz ist eine neue Arbeitsteilung: Mitarbeiter definieren Ziele und Grenzen, während spezialisierte Agenten Recherche, Vorbereitung und risikoarme Prozessschritte übernehmen.
