KI-Agent, Copilot, Chatbot, Workflow und RPA: die Unterschiede

Das Etikett sagt wenig über die tatsächliche Architektur

Ein Anbieter nennt sein Produkt „Agent“, obwohl es auf eine Frage antwortet und anschließend auf den nächsten Klick wartet. Ein anderer verkauft einen „Copilot“, der selbstständig Datensätze verändert. Dazu kommen Workflows mit Sprachmodell, RPA-Roboter mit Chatoberfläche und Chatbots, die interne APIs aufrufen. Die Namen klingen nach klaren Produktklassen, sind aber keine verlässliche technische Spezifikation.

Für eine Architekturentscheidung sind sechs andere Fragen wichtiger: Wer startet die Arbeit? Wer bestimmt den nächsten Schritt? Welche Daten darf das System lesen? Welche Werkzeuge kann es auswählen? Welche Aktion darf es ausführen? Und wer trägt die Folgen, wenn die Entscheidung falsch ist?

Die allgemeine Pillarpage zur KI-Automatisierung erklärt, wie KI-Schritte in kontrollierte Geschäftsprozesse eingebettet werden. Der Leitfaden zur KI-Automatisierung im E-Commerce ordnet passende Prozesse ein. Hier geht es um die Architekturbegriffe, die bei der Auswahl solcher Lösungen ständig durcheinandergeraten.

Der Vergleich auf einen Blick

Diese Einordnung ist technisch, nicht rechtlich. Die Europäische Kommission weist in ihren Leitlinien zur Definition eines KI-Systems darauf hin, dass Systeme anhand ihrer konkreten Merkmale bewertet werden müssen. Ein Produktname wie „Copilot“ oder „Agent“ entscheidet daher weder über die Architektur noch über eine regulatorische Einordnung.^[1]

Eine Adressänderung zeigt die Unterschiede besser als eine Definition

Ein Kunde schreibt: „Bitte schickt meine Bestellung an die Firmenadresse aus der letzten Bestellung.“ Der Auftrag ist bereits bezahlt. Im Shop steht eine Privatadresse, im CRM mehrere Firmenkontakte und im ERP wurde der Auftrag möglicherweise schon an das Lager übergeben. Die Oberfläche kann identisch aussehen; die technische Verantwortung ist es nicht.

Der Chatbot erklärt oder sammelt Informationen

Ein einfacher Chatbot beantwortet die Frage nach der Änderungsfrist oder fragt Bestellnummer und neue Adresse ab. Ohne verlässlichen Systemzugriff sollte er nicht behaupten, die Änderung sei erledigt. Sein Ergebnis ist eine Antwort oder ein strukturierter Übergabedatensatz.

Der Copilot bereitet die Entscheidung vor

Ein Service-Copilot zeigt der Mitarbeiterin Bestellung, Lieferstatus und mögliche Firmenadressen. Er formuliert eine Antwort und kann eine Änderung vorbereiten. Die Mitarbeiterin prüft Identität, Adresse und Versandstatus und bestätigt die Aktion. Das System verkürzt Recherche und Eingabe, verschiebt aber nicht automatisch die Verantwortung.

Der Workflow folgt dem festgelegten Fallbaum

Ein Workflow prüft in fester Reihenfolge: Identität bestätigt, Bestellung noch nicht an das Lager übergeben, Zielland unverändert, Adresse validiert. Sind alle Bedingungen erfüllt, ruft er eine definierte API auf. Andernfalls erstellt er ein Ticket. Ein Sprachmodell kann die E-Mail klassifizieren oder Adressbestandteile extrahieren, ohne den Ablauf zu steuern.

RPA bedient das Altsystem

Fehlt im ERP eine geeignete API, kann ein RPA-Flow die freigegebene Adresse in die vorgesehenen Felder übertragen. Er klickt und tippt entlang eines bekannten Pfads. RPA entscheidet nicht, ob die Änderung fachlich erlaubt ist. Diese Entscheidung gehört vor den UI-Lauf.

Der Agent wählt aus mehreren nächsten Schritten

Ein Agent kann selbst entscheiden, ob er Bestelldaten liest, nach einer fehlenden Angabe fragt, eine Adressprüfung aufruft oder an den Service übergibt. Für das tatsächliche Rückschreiben gelten trotzdem feste Rechte, Grenzwerte und Freigaben. „Das Modell kann den Fall verstehen“ ist keine Berechtigung, eine bereits laufende Lieferung umzuleiten.

Chatbot und Copilot unterscheiden sich vor allem in der Arbeitsbeziehung

Ein Chatbot ist zunächst eine Gesprächsschnittstelle

Ein Chatbot nimmt Eingaben in Dialogform entgegen und erzeugt Antworten. Er kann regelbasiert, mit einem Sprachmodell oder als Oberfläche vor einem Workflow gebaut sein. Der Chatkanal sagt nichts darüber aus, ob die Antwort aus freiem Modellwissen, einer Wissensbasis oder aktuellen Shopdaten stammt. Auch Werkzeugzugriff macht aus der Oberfläche noch keinen autonomen Agenten.

Ein Copilot arbeitet sichtbar neben einem Menschen

„Copilot“ beschreibt eine Assistenzrolle: Das System fasst zusammen, recherchiert, entwirft oder bereitet eine Aktion im Kontext der aktuellen Arbeit vor. Microsoft unterscheidet entsprechend zwischen einem eingebauten Copilot und spezialisierten Agents, die Wissen, Fähigkeiten und externe Dienste ergänzen. Das zeigt zugleich, warum der Name keine feste technische Grenze garantiert.^[2]

Ein Copilot ist sinnvoll, wenn fachliches Urteil häufig nötig bleibt, der Mensch aber nicht jedes Dokument und jeden Systemkontext selbst zusammensuchen soll. Er ist keine Sicherheitsfunktion. Vorschläge benötigen Quellen, sichtbare Unsicherheit und eine klare Trennung zwischen „entworfen“ und „ausgeführt“.

Workflow und RPA sind planbare Automation – auf unterschiedlichen Ebenen

Der Workflow besitzt einen definierten Kontrollfluss

Ein Workflow verbindet Trigger, Prüfungen und Aktionen über vorab modellierte Pfade. Einzelne Schritte dürfen KI verwenden: eine E-Mail klassifizieren, PDF-Werte extrahieren oder einen Antwortentwurf erzeugen. Die Verzweigungen und erlaubten Aktionen bleiben jedoch im Code oder in der Workflow-Konfiguration.

Anthropic zieht dieselbe architektonische Grenze: In Workflows werden Modelle und Werkzeuge über vordefinierte Codepfade orchestriert; bei Agents steuert das Modell Prozess und Werkzeugnutzung dynamisch. Für klar zerlegbare Aufgaben empfiehlt Anthropic die einfachere Lösung und weist darauf hin, dass zusätzliche Agentenkomplexität Latenz und Kosten erhöht.^[3]

RPA ersetzt den fehlenden programmatischen Zugriff

Robotic Process Automation bedient eine Oberfläche so, wie es ein Mensch tun würde. Microsoft beschreibt Desktop-Flows als Automatisierung wiederkehrender regelbasierter Aufgaben in Web-, Desktop- und älteren Anwendungen. Das ist nützlich im API-Knast, bleibt aber empfindlicher als ein stabiler API-Aufruf: Fensterzustand, Selektoren, Sitzungen und Oberflächenänderungen werden Teil des Betriebs.^[4]

Ein KI-Agent kontrolliert Teile der Ausführung selbst

Ein Agent erhält ein Ziel, Kontext, Anweisungen und eine Auswahl erlaubter Werkzeuge. Das Modell bewertet den aktuellen Zustand, wählt einen nächsten Schritt, verarbeitet das Werkzeugergebnis und entscheidet, ob es fortsetzt, nachfragt, stoppt oder übergibt. Der Pfad entsteht damit teilweise während der Ausführung.

OpenAI grenzt einfache Chatbots und einzelne Modellaufrufe ausdrücklich von Agents ab: Bei einem Agent steuert das Modell den Workflow, erkennt Abschluss oder Fehler und wählt Werkzeuge dynamisch innerhalb von Guardrails. Zu diesen Werkzeugen können Datenabfragen, API-Aktionen oder eine Computeroberfläche gehören.^[5]

Werkzeugzugriff ist notwendig, aber nicht hinreichend

Ein Chatbot, der genau eine Suchfunktion aufruft, ist nicht automatisch ein Agent. Entscheidend ist, ob das Modell den Ablauf über mehrere Zustände hinweg steuert. Umgekehrt kann ein Agent hauptsächlich lesen und Vorschläge erstellen. Autonomie und Schreibrecht sind zwei getrennte Achsen.

Mehr Flexibilität vergrößert die Testfläche

Ein festes Skript hat bekannte Pfade. Ein Agent kann Werkzeuge in unerwarteter Reihenfolge verwenden, zu früh stoppen oder einen plausiblen Zwischenstand falsch bewerten. Deshalb braucht er maximale Schrittzahlen, Zeit- und Kostenbudgets, erlaubte Zustandsübergänge, idempotente Aktionen, eine Übergabe an Menschen und Tests auf vollständigen Abläufen statt nur auf einzelne Antworten.

Ein produktives System kombiniert die Begriffe häufig

Ein Service-Copilot kann einen deterministischen Workflow starten. Der Workflow kann einen KI-Schritt zur Klassifikation und RPA für ein altes ERP verwenden. Ein Agent kann denselben Copilot-Kanal nutzen, aber nur lesende Werkzeuge besitzen. Die Architektur wird erst verständlich, wenn jede Ebene separat benannt wird.

Welcher Ansatz passt zu welchem Prozess?

Die sinnvollste Lösung ist oft eine Kombination, aber nicht die maximal komplexe Kombination. Wenn eine feste Verzweigung ausreicht, macht ein Agent den Betrieb nicht automatisch besser. Wenn eine Fachkraft jede Ausnahme neu interpretieren muss, kann ein reiner Workflow dagegen an einer wachsenden Regelliste ersticken.

• Starte mit dem kleinsten Baustein, der das Prozessziel zuverlässig erreicht.
• Trenne Leserechte, Vorschläge, vorbereitete Aktionen und tatsächliche Schreibrechte.
• Nutze APIs vor RPA, wenn beide Wege fachlich und wirtschaftlich verfügbar sind.
• Erweitere Agentenautonomie erst nach Tests mit realistischen Fällen und sichtbaren Fehlerpfaden.
• Bewerte Korrekturaufwand und kritische Fehler, nicht nur Antwortqualität oder Demo-Geschwindigkeit.

Die Messung richtet sich nach der Verantwortung des Systems

Beim Chatbot zählen fachlich korrekte, belegte Antworten und saubere Übergaben. Beim Copilot kommt hinzu, wie oft Vorschläge ohne oder mit kleinen Änderungen übernommen werden und ob die Bearbeitungszeit tatsächlich sinkt. Beim Workflow werden Durchsatz, Ausnahmequote und fehlgeschlagene Aktionen gemessen. Beim Agent müssen außerdem Werkzeugwahl, Schrittzahl, Abbruchverhalten, Kosten und unzulässige Aktionsversuche sichtbar sein.

Das NIST AI Risk Management Framework verlangt, Aufgaben, Methoden, Wissensgrenzen und menschliche Aufsicht konkret zu dokumentieren. Tests sollen unter Bedingungen erfolgen, die dem späteren Einsatz ähneln; Verhalten und Komponenten sollen im Betrieb überwacht werden. Diese Anforderungen hängen an der tatsächlichen Systemfunktion, nicht an der Bezeichnung auf einer Produktseite.^[6]

Ein Vergleichsprojekt sollte deshalb mit einem Prozessdiagramm, einer Rechte- und Risikomatrix und einer Liste realistischer Testfälle beginnen. Erst danach lohnt sich die Frage, welches Produkt oder Framework die gewählte Architektur am besten unterstützt.

Eine belastbare Auswahl entsteht in sieben Schritten

1. Prozessziel, Eingang, Ergebnis, Volumen und Ausnahmen dokumentieren.
2. Führende Systeme und verbindliche Datenquellen pro Feld bestimmen.
3. Markieren, welche Entscheidungen vollständig regelbasiert möglich sind.
4. Variable Interpretationsaufgaben identifizieren, für die KI einen messbaren Vorteil bietet.
5. Lese-, Vorschlags-, Vorbereitungs- und Schreibrechte separat festlegen.
6. Erfolgsmetriken, kritische Fehler, Fallback und menschliche Freigabe definieren.
7. Erst danach Chatbot, Copilot, Workflow, RPA oder Agent als Bausteine auswählen.

Die Potenzial-Analyse wendet diese Trennung auf einen konkreten Unternehmensprozess an. Das Ergebnis sollte auch ausdrücklich lauten dürfen: normale API, kleiner Workflow oder bessere Datenpflege – ohne Agent.