KI-Agenten im Unternehmen: Welche Aufgaben sie zuverlässig übernehmen können

Ein KI-Agent beantwortet nicht nur eine Frage. Er erhält ein Ziel, prüft den aktuellen Zustand, wählt einen nächsten Schritt und nutzt dafür freigegebene Werkzeuge. Ein Agent kann beispielsweise eine eingehende Anfrage lesen, erforderliche Angaben erkennen, Informationen aus einem System abrufen und einen Vorgang zur Prüfung vorbereiten. Entscheidend ist nicht das Chatfenster, sondern die Verbindung zwischen Sprachmodell, Regeln, Daten und ausführbaren Aktionen.

Diese Handlungsfähigkeit unterscheidet einen Agenten von einem gewöhnlichen Assistenten. Ein Assistent formuliert einen Vorschlag, den ein Mensch anschließend überträgt. Ein Agent kann innerhalb seiner Rechte selbst einen Datensatz suchen, eine Aufgabe anlegen oder einen Entwurf in einem Fachsystem speichern. Damit steigt der mögliche Nutzen, zugleich aber auch die Verantwortung für Zugriffe, Fehlerwege und Kontrolle.

Agent bedeutet nicht autonom ohne Grenzen

Der Begriff wird oft so verwendet, als müsse ein Agent vollständig selbstständig arbeiten. In Unternehmen ist meistens das Gegenteil sinnvoll. Ein guter Agent besitzt einen klar abgegrenzten Handlungsspielraum. Er darf bestimmte Informationen lesen, ausgewählte Aktionen vorbereiten und nur risikoarme Schritte selbst ausführen. Bei Unsicherheit, Ausnahmen oder folgenreichen Entscheidungen übergibt er an eine zuständige Person.

Autonomie ist deshalb keine pauschale Produkteigenschaft. Sie wird für jeden Schritt festgelegt. Ein Agent darf eine E-Mail klassifizieren, aber nicht automatisch einen Vertrag bestätigen. Er darf einen Kundendatensatz vorschlagen, aber nicht zwei Unternehmen ohne Prüfung zusammenführen. Diese Abstufung macht den Einsatz beherrschbar und lässt sich später erweitern.

Ein Workflow bleibt vorhersehbarer als ein Agent

Wenn Auslöser, Regeln und Ergebnis vollständig feststehen, genügt häufig klassische Automatisierung. Eine freigegebene Bestellung in ein ERP zu übertragen, benötigt kein Sprachmodell, solange Felder und Bedingungen eindeutig sind. Ein Agent wird interessant, wenn Eingangsdaten variieren, Informationen aus mehreren Quellen zusammengeführt oder Zwischenschritte anhand des Inhalts gewählt werden müssen.

Auch dann sollte ein deterministischer Workflow die äußeren Grenzen bilden. Er startet den Agenten, stellt zulässige Werkzeuge bereit, prüft das Ergebnis und entscheidet über den nächsten Systemschritt. Das Modell übernimmt den Teil, der sprachliche oder kontextbezogene Einordnung braucht. Fachliche Regeln, Berechtigungen und Transaktionen bleiben im kontrollierbaren Anwendungscode.

Die Aufgabe definiert den Agenten

„Ein Agent für den Vertrieb“ ist zu groß, um Qualität oder Rechte sinnvoll festzulegen. „Neue Website-Anfragen auf Vollständigkeit prüfen und einen strukturierten CRM-Entwurf vorbereiten“ ist dagegen überprüfbar. Es gibt einen erkennbaren Eingang, zugelassene Quellen, ein erwartetes Ergebnis und eine Person, die Ausnahmen übernimmt. Erst diese Präzision macht aus einer Produktidee ein umsetzbares System.

Die Bezeichnung des Systems sollte diese Begrenzung widerspiegeln. Ein „Anfrageprüfer“ weckt realistischere Erwartungen als ein „autonomer Vertriebsagent“. Klare Namen helfen Nutzern zu erkennen, wann sie sich auf das Ergebnis stützen können und wann weiterhin eigene fachliche Prüfung notwendig ist.

Eine geeignete Agentenaufgabe besitzt wiederkehrende Eingänge, ein erkennbares Ziel und genügend Beispiele für normale sowie schwierige Fälle. Der Weg zum Ergebnis darf variieren, aber die Qualität muss sich beurteilen lassen. Typische Kandidaten sind informationsintensive Abläufe, in denen Mitarbeitende lesen, vergleichen, in mehreren Systemen nachschlagen und anschließend einen strukturierten nächsten Schritt vorbereiten.

Das bedeutet nicht, dass jede zeitraubende Tätigkeit geeignet ist. Manche Arbeit braucht Verhandlung, persönliche Verantwortung oder stilles Erfahrungswissen, das sich nicht in Quellen und Kriterien abbilden lässt. Andere Prozesse sind so selten, dass Entwicklung und Betrieb mehr Aufwand verursachen als die manuelle Bearbeitung. Die Auswahl beginnt deshalb beim Prozess, nicht bei einer Liste spektakulärer KI-Funktionen.

Gute Aufgaben haben einen prüfbaren Abschluss

Ein Agent kann eingegangene Dokumente einem Vorgang zuordnen, fehlende Angaben markieren und eine Checkliste vorbereiten. Das Ergebnis lässt sich gegen Originaldokument, Pflichtfelder und fachliche Regeln prüfen. Ebenso kann er Supportanfragen klassifizieren, passende Wissensartikel finden und einen Antwortentwurf samt Quellen bereitstellen. Auch hier bleibt sichtbar, ob Kategorie, Belege und vorgeschlagene Antwort stimmen.

Ungeeignet ist eine Formulierung wie „Der Agent verbessert unseren Kundenservice“. Sie nennt weder Eingang noch Ergebnis. Daraus lassen sich keine Rechte, Tests oder Übergaben ableiten. Eine belastbare Aufgabe beschreibt, was ankommt, welche Informationen benutzt werden dürfen, welche Aktion erwartet wird und woran ein Mensch einen Fehler erkennt.

Variabilität rechtfertigt noch keine freie Entscheidung

Sprachliche Vielfalt ist ein guter Grund für ein Modell. Sie ist kein Grund, dem Agenten alle Folgeschritte zu überlassen. Eine Anfrage kann unterschiedlich formuliert sein und trotzdem in eine feste Auswahl von Kategorien führen. Der Agent ordnet ein; der Workflow wendet anschließend bekannte Regeln an. Diese Kombination nutzt die Stärke des Modells, ohne betriebliche Logik in einem schwer prüfbaren Prompt zu verstecken.

Je größer der mögliche Schaden einer falschen Aktion, desto kleiner sollte der autonome Anteil sein. Eine interne Aufgabe anzulegen ist leichter rückgängig zu machen als eine Zahlung, eine Vertragsänderung oder eine Nachricht an einen Kunden. Reversibilität, Datenempfindlichkeit und Außenwirkung bestimmen deshalb gemeinsam, welche Schritte automatisch laufen dürfen.

Ein realer Fall statt zehn hypothetischer Anwendungsfelder

Für den ersten Einsatz reicht ein häufiger Vorgang mit klarer fachlicher Zuständigkeit. Sammle echte, zulässig verwendbare Beispiele einschließlich Sonderfällen. Notiere, welche Entscheidungen Mitarbeitende treffen, welche Quellen sie öffnen und an welchen Stellen sie Rückfragen stellen. Daraus entsteht eine Aufgabenkarte, die deutlich mehr über die Eignung verrät als eine allgemeine Abteilungsübersicht.

Ein sinnvoller Kandidat lässt sich außerdem vorübergehend im Schattenbetrieb testen. Der Agent bearbeitet reale Eingänge, führt aber keine endgültige Aktion aus. Seine Vorschläge werden mit der tatsächlichen Bearbeitung verglichen. So zeigt sich früh, ob das System den Prozess verstanden hat oder nur in einfachen Demonstrationen überzeugend wirkt.

Berücksichtige auch das Arbeitsvolumen. Ein Vorgang kann häufig sein und trotzdem ungeeignet bleiben, wenn fast jeder Fall eine andere Ausnahme enthält. Umgekehrt kann eine kleine, stabile Teilmenge einen guten Einstieg bilden. Der Agent muss nicht den ganzen Prozess übernehmen, um im Alltag eine klar abgegrenzte Unterstützung zu leisten.

Ein Sprachmodell allein ist noch kein Agent. Die Anwendung muss festlegen, welche Informationen der Agent erhält, welche Werkzeuge er aufrufen kann, wie Zwischenergebnisse gespeichert werden und wann der Ablauf endet. Hinzu kommen Authentifizierung, Protokollierung, Fehlerbehandlung und eine Oberfläche für menschliche Entscheidungen. Diese Bausteine bestimmen die Zuverlässigkeit stärker als eine besonders ausführliche Rollenbeschreibung im Prompt.

Kontext liefert nur die Informationen für den aktuellen Schritt

Der Agent braucht nicht pauschal Zugriff auf alle Unternehmensdaten. Die Anwendung stellt den für den Vorgang nötigen Kontext zusammen: die aktuelle Anfrage, relevante Stammdaten, freigegebene Wissensquellen und bisherige Bearbeitungsschritte. Jede Information trägt Herkunft und Zeitpunkt. So kann der Agent unterscheiden, ob eine Aussage aus dem Kundentext, einer internen Richtlinie oder einem berechneten Systemfeld stammt.

Zu viel Kontext verschlechtert Übersicht und Kontrolle. Veraltete Notizen können aktuelle Regeln verdrängen, ähnliche Kundennamen können verwechselt werden und lange Verläufe erhöhen die Gefahr, dass wichtige Einschränkungen untergehen. Kontextauswahl ist daher ein eigener Anwendungsschritt mit Berechtigungsprüfung, nicht bloß das Zusammenkopieren aller verfügbaren Texte.

Werkzeuge kapseln konkrete Aktionen

Ein Werkzeug kann „Kunden suchen“, „Aufgabe als Entwurf anlegen“ oder „Dokument aus freigegebenem Ordner laden“ heißen. Dahinter liegt normaler Anwendungscode mit festen Eingaben, Validierung und Rechten. Der Agent entscheidet, welches Werkzeug er benötigt und welche zulässigen Parameter er übergibt. Er erhält aber keinen freien Datenbankzugriff und keine allgemeine Möglichkeit, beliebigen Code auszuführen.

Gute Werkzeugbeschreibungen erklären Zweck, Grenzen und erwartete Eingaben. Ebenso wichtig ist die technische Durchsetzung: Ein Feld darf nur bekannte Werte annehmen, eine Kunden-ID muss zum aktuellen Mandanten gehören und schreibende Aktionen benötigen eine Vorgangskennung. Das Werkzeug lehnt ungültige Aufrufe ab, statt darauf zu hoffen, dass das Modell immer korrekt formuliert.

Zustand macht den Ablauf nachvollziehbar

Jeder Lauf besitzt eine stabile Kennung und einen expliziten Status. Gespeichert werden Eingangsreferenz, aufgerufene Werkzeuge, Ergebnisse, Freigaben, Abbrüche und die finale Übergabe. Freie Gedankentexte des Modells sind dafür nicht erforderlich. Entscheidend sind strukturierte, für den Betrieb notwendige Ereignisse: Was wurde gelesen, welche Aktion wurde vorgeschlagen, wer hat sie bestätigt und welches System meldete Erfolg?

Die Kontrolllogik setzt Grenzen für Schritte, Laufzeit und Wiederholungen. Sie erkennt, wenn ein Agent im Kreis arbeitet, dieselbe Suche mehrfach ausführt oder ein Werkzeug nicht erreichbar ist. Ein klarer Endzustand verhindert, dass ein technisch laufender Prozess fachlich unbemerkt offenbleibt.

Ein Agent kann nur dann sicher handeln, wenn seine technischen Rechte enger sind als seine sprachlichen Möglichkeiten. Ein Prompt wie „Bearbeite ausschließlich Supportfälle“ ist keine Zugriffskontrolle. Die Identität des Agenten muss auf Systemebene genau die Datensätze und Aktionen erhalten, die für den aktuellen Auftrag nötig sind. Alles andere bleibt auch dann gesperrt, wenn ein Modell oder ein manipulierter Inhalt danach fragt.

Lesen, vorbereiten und ausführen sind verschiedene Rechte

Viele Werkzeuge benötigen mehrere Stufen. Ein Agent darf einen Datensatz lesen, einen Änderungsvorschlag erzeugen und diesen als Entwurf speichern. Die endgültige Änderung erfolgt erst nach Freigabe. Diese Trennung ist stärker als ein allgemeines Schreibrecht und ermöglicht einen nutzbaren Pilot, ohne sofort produktive Daten zu verändern.

Auch innerhalb einer Aktion unterscheiden sich Felder. Ein Agent kann eine Gesprächszusammenfassung ergänzen, aber weder Kundennummer noch Zahlungsziel ändern. Er kann einen Termin vorschlagen, aber keine Einladung versenden. Solche Feld- und Aktionsgrenzen gehören in die API und werden bei jedem Aufruf geprüft.

Mandanten- und Vorgangsgrenzen dürfen nicht vom Modell abhängen

Wenn ein System mehrere Kunden, Standorte oder Gesellschaften enthält, setzt die Anwendung den zulässigen Bereich aus der angemeldeten Identität und dem aktuellen Vorgang. Der Agent darf diesen Bereich nicht durch einen Parameter erweitern. Eine Suche erhält die Mandantenkennung serverseitig; ein Dokumentabruf prüft die Zugehörigkeit erneut. Damit kann eine falsche Modellentscheidung nicht zu einem Datenzugriff außerhalb des Auftrags führen.

Dasselbe gilt für personenbezogene oder vertrauliche Inhalte. Der Agent bekommt nur Felder, die er für die Aufgabe benötigt. Protokolle vermeiden unnötige Volltexte und speichern sensible Werte nicht doppelt. Aufbewahrung und Löschung folgen den Regeln des führenden Systems, statt im Agentenspeicher eine zweite unkontrollierte Datenablage zu schaffen.

Schreibende Aktionen brauchen Wiederholschutz

Netzwerkfehler können dazu führen, dass ein Agent nicht weiß, ob eine Aktion erfolgreich war. Ein erneuter Aufruf darf dann keine zweite Aufgabe, Bestellung oder Nachricht erzeugen. Schreibwerkzeuge erhalten deshalb eine eindeutige Vorgangskennung und liefern bei Wiederholung das bereits bekannte Ergebnis zurück. Der Agent fragt den Status ab, statt blind noch einmal auszuführen.

Zusätzlich werden Grenzwerte technisch festgelegt: maximale Anzahl betroffener Datensätze, zulässige Empfänger, erlaubte Dateitypen oder ein Höchstwert für eine Transaktion. Solche Regeln gehören nicht in einen Prompt, weil sie unabhängig von Modellverhalten gelten müssen.

Die Zugriffsprüfung umfasst außerdem den Zeitpunkt. Kurzlebige Berechtigungen werden nur für den aktuellen Lauf vergeben und anschließend entzogen. Dauerhafte Dienstkonten mit breiten Rechten erleichtern zwar den ersten Prototyp, erschweren aber später die Zuordnung von Aktionen und vergrößern die Folgen kompromittierter Zugangsdaten.

Eine Freigabe ist nur sinnvoll, wenn die prüfende Person versteht, was der Agent tun will und welche Informationen die Entscheidung tragen. Ein Button mit „Bestätigen“ unter einem langen generierten Text genügt nicht. Die Oberfläche zeigt Originaleingang, relevante Quellen, vorgeschlagene Änderung, betroffene Systeme und erkennbare Unsicherheiten nebeneinander. So wird aus menschlicher Beteiligung eine echte Kontrolle statt einer formalen Abzeichnung.

Risiko bestimmt den Freigabepunkt

Interne, reversible und leicht erkennbare Schritte können nach erfolgreicher Erprobung automatisch laufen. Dazu gehören etwa Klassifizierung, Priorisierung oder das Anlegen eines internen Entwurfs. Externe Kommunikation, Rechteänderungen, finanzielle Vorgänge und Entscheidungen über Personen benötigen deutlich stärkere Kontrolle. Manche Schritte bleiben grundsätzlich menschlich, auch wenn der Agent sie technisch ausführen könnte.

Die Freigabe sollte möglichst spät genug erfolgen, damit ein vollständiger Vorschlag vorliegt, aber vor dem ersten schwer rückgängig zu machenden Schritt. Muss ein Mensch jeden kleinen Werkzeugaufruf einzeln bestätigen, wird der Ablauf unbrauchbar. Bestätigt er dagegen erst nach Versand oder Datenänderung, ist die Kontrolle wirkungslos. Der richtige Punkt liegt am fachlichen Übergang.

Unsicherheit löst Übergabe aus

Ein Modellwert allein ist keine verlässliche Wahrheit über Sicherheit. Trotzdem kann die Anwendung erkennbare Situationen für eine Übergabe definieren: widersprüchliche Quellen, fehlende Pflichtangaben, unbekannte Kategorien, ungewöhnlich viele betroffene Datensätze oder ein Ergebnis außerhalb zulässiger Werte. Der Agent benennt den Grund und legt alle bisher gesammelten Informationen vor.

Auch Nutzer müssen eine einfache Möglichkeit haben, den Agenten zu stoppen, zu korrigieren oder einen Vorgang vollständig manuell zu übernehmen. Der Prozess speichert diese Entscheidung, damit später sichtbar wird, welche Fälle regelmäßig menschliche Arbeit benötigen. Eine Übergabe ist kein Fehler des Systems, sondern eine geplante Betriebsart.

Freigaben brauchen Verantwortung und Frist

Ein wartender Vorgang darf nicht in einer unsichtbaren Agentenliste liegen bleiben. Er erhält eine zuständige Rolle, einen Status und gegebenenfalls eine Bearbeitungsfrist. Vertretungen und Eskalationen werden wie bei anderen Geschäftsprozessen geregelt. Der Agent kann erinnern, aber nicht seine eigene Freigabe ersetzen.

Korrekturen werden strukturiert erfasst. „Falsch“ hilft bei der Verbesserung wenig. Sinnvoll sind Gründe wie falsche Zuordnung, fehlende Quelle, unzulässige Aktion oder sprachlich ungeeigneter Entwurf. Diese Rückmeldungen fließen in Tests, Werkzeugregeln oder Aufgabenabgrenzung ein, nicht ungeprüft in ein automatisches Selbstlernen.

Agenten verarbeiten E-Mails, Dokumente, Webseiten und Systemdaten. Darin können Texte stehen, die wie Anweisungen formuliert sind. Ein gewöhnlicher Mensch erkennt den Unterschied zwischen einer Kundenmail und einer internen Arbeitsanweisung meist aus dem Kontext. Ein Sprachmodell kann manipulierten Inhalt dagegen als neue Aufgabe interpretieren. Diese indirekte Prompt-Injection ist besonders gefährlich, wenn der Agent Werkzeuge und sensible Daten erreicht.

Daten und Anweisungen werden technisch getrennt

Unvertrauenswürdiger Inhalt wird als Datenquelle gekennzeichnet und erhält nie die Möglichkeit, Systemregeln zu überschreiben. Die Anwendung entscheidet, welche Felder als Anweisung gelten dürfen. Ein Dokument kann Informationen für eine Zusammenfassung liefern, aber keine neuen Werkzeuge freischalten oder Empfänger bestimmen. Der Agent bekommt diese Grenze ausdrücklich erklärt; entscheidend bleibt jedoch die technische Beschränkung.

Ausgaben aus einem Werkzeug werden ebenfalls nicht automatisch zu Befehlen. Eine gefundene Webseite, ein Dateitext oder ein CRM-Kommentar kann manipuliert sein. Bevor daraus eine Aktion entsteht, prüft der Workflow Datentyp, Herkunft und erlaubte Verwendung. Hochriskante Inhalte werden isoliert verarbeitet oder nur angezeigt.

Geheimnisse gehören nicht in den Modellkontext

API-Schlüssel, Datenbankzugänge und Sitzungstoken bleiben im ausführenden Dienst. Der Agent ruft ein Werkzeug über eine definierte Schnittstelle auf, ohne dessen technische Zugangsdaten zu sehen. Rückgaben enthalten nur die benötigten Felder. Protokolle und Fehlermeldungen maskieren vertrauliche Werte, damit ein Diagnosefall nicht selbst zum Datenleck wird.

Auch ein legitimer Nutzer darf den Agenten nicht als Umweg zu fremden Berechtigungen verwenden. Jede Aktion wird sowohl gegen die Agentenrolle als auch gegen den auftraggebenden Nutzer geprüft. Kann die Person einen Datensatz nicht öffnen, darf sie ihn auch nicht über eine geschickte Frage vom Agenten zusammenfassen lassen.

Sicherheitsprüfungen brauchen reale Angriffsmuster

Tests enthalten nicht nur normale Beispiele. Sie versuchen, den Agenten zu fremden Empfängern, unerlaubten Daten, zusätzlichen Werkzeugen oder verdeckten Aktionen zu bewegen. Dokumente enthalten irreführende Anweisungen, E-Mails fordern zur Preisgabe interner Informationen auf und Werkzeugantworten liefern manipulierte Texte. Erwartet wird nicht nur eine höfliche Ablehnung, sondern der technisch belegte Misserfolg der verbotenen Aktion.

NIST weist bei agentischen Systemen besonders auf Werkzeugmissbrauch, indirekte Prompt-Injection und ungewollte reale Aktionen hin. Daraus folgt für den Betrieb: Sicherheitsgrenzen müssen unabhängig vom verwendeten Modell wirksam sein, regelmäßig getestet und nach Änderungen erneut geprüft werden.

Zum Sicherheitskonzept gehört auch eine begrenzte Ausgabemöglichkeit. Ein Agent darf sensible Daten nicht über frei wählbare URLs, Empfänger oder Dateiziele ausleiten. Netzwerkziele, E-Mail-Domains und Speicherorte werden zugelassen statt nur unerwünschte Ziele nachträglich zu sperren. So bleibt der mögliche Aktionsraum überschaubar.

Ein überzeugender Einzeltest beweist wenig. Ein Agent kann einen Vorgang sprachlich gut erklären und trotzdem den falschen Kunden öffnen, eine Quelle übersehen oder eine Aktion doppelt ausführen. Die Bewertung muss deshalb den gesamten Ablauf vom Eingang bis zum gespeicherten Ergebnis abdecken. Dazu gehören fachliche Richtigkeit, Werkzeugwahl, Rechte, Übergaben, Laufzeit und Fehlerbehandlung.

Ein Testbestand bildet normale und schwierige Fälle ab

Aus historischen, zulässig verwendbaren Beispielen entsteht ein fester Evaluationssatz. Er enthält häufige Standardfälle, unvollständige Eingänge, widersprüchliche Informationen, unbekannte Kategorien und sicherheitskritische Manipulationsversuche. Für jeden Fall sind erwartete Entscheidungen und verbotene Aktionen dokumentiert. Bei offenen Aufgaben kann es mehrere akzeptable Ergebnisse geben; die unverzichtbaren Fakten und Grenzen bleiben trotzdem prüfbar.

Der Testbestand wird versioniert. Wenn neue Fehler auftreten, kommt ein repräsentativer Fall hinzu. Dadurch lässt sich vor einem Modell-, Prompt- oder Werkzeugwechsel prüfen, ob frühere Probleme wiederkehren. Ein Agent wird nicht allein nach subjektivem Eindruck in einer Demo freigegeben.

Teilmetriken zeigen die Ursache

Eine einzige Erfolgsquote verdeckt, wo ein Ablauf scheitert. Getrennt gemessen werden beispielsweise richtige Klassifikation, gefundene Quelle, korrekte Werkzeugparameter, zulässige Aktion, erfolgreiche Übergabe und fachlich akzeptiertes Endergebnis. So wird sichtbar, ob das Modell falsch einordnet, eine Schnittstelle fehlerhafte Daten liefert oder die Aufgabe grundsätzlich zu breit ist.

Neben Qualität zählen Kosten und Bearbeitungszeit, aber nicht isoliert. Ein schneller Agent, dessen Vorschläge häufig korrigiert werden müssen, verlagert Arbeit statt sie zu reduzieren. Erfasst werden deshalb auch menschliche Nacharbeit, Abbruchgründe und Fälle, die vollständig manuell übernommen werden.

Produktionsbeobachtung schützt vor stiller Verschlechterung

Im Betrieb werden strukturierte Ereignisse überwacht: ungewöhnlich viele Werkzeugaufrufe, steigende Übergaberaten, häufige Validierungsfehler oder fehlgeschlagene Aktionen. Stichproben prüfen die fachliche Qualität. Personenbezogene Inhalte werden dabei so sparsam wie möglich verarbeitet und nur berechtigten Prüfern zugänglich gemacht.

Ändern sich Produkte, Richtlinien oder Eingangsdaten, kann die Qualität sinken, obwohl Modell und Code unverändert bleiben. Deshalb gehören fachliche Besitzer zum Monitoring. Sie erkennen neue Falltypen und entscheiden, ob Quellen, Regeln, Testbestand oder Aufgabenbereich angepasst werden müssen.

Vergleiche sollten zudem gegen eine nachvollziehbare Ausgangslage erfolgen. Vor dem Pilot wird gemessen, wie der Vorgang heute bearbeitet wird, welche Fehlerklassen auftreten und wo Wartezeiten entstehen. Ohne diese Basis lässt sich später zwar Aktivität zählen, aber nicht beurteilen, ob der Agent den Ablauf tatsächlich verbessert.

Ein produktiver Agent ist kein persönliches Experiment eines einzelnen Mitarbeiters. Er verarbeitet Unternehmensdaten, beeinflusst Abläufe und kann nach außen wirken. Deshalb benötigt er einen dokumentierten Zweck, einen fachlichen Besitzer, eine technische Betriebsverantwortung und klar benannte Personen für Datenschutz, Sicherheit oder Recht, soweit der Anwendungsfall sie berührt.

Die Agentenakte beschreibt den zulässigen Einsatz

Dokumentiert werden Aufgabe, Nutzergruppen, Datenquellen, Werkzeuge, Rechte, Freigabepunkte, bekannte Grenzen und erwartete Ergebnisse. Hinzu kommen Modell- und Promptversionen, Anbieter, Aufbewahrung sowie der Weg für Beschwerden oder Korrekturen. Diese Unterlagen müssen nicht bürokratisch umfangreich sein. Sie müssen einer prüfenden Person ermöglichen zu verstehen, was das System tatsächlich tut.

Der Zweck begrenzt spätere Erweiterungen. Ein Agent, der interne Supportentwürfe vorbereitet, wird nicht stillschweigend für Leistungsbewertungen von Mitarbeitenden verwendet. Eine wesentliche neue Nutzung durchläuft erneut fachliche, technische und rechtliche Prüfung. So verhindert Governance, dass ein erfolgreicher Pilot unkontrolliert in andere Entscheidungen hineinwächst.

Rechtliche Pflichten hängen vom konkreten Einsatz ab

Der EU AI Act unterscheidet nach Rolle, Zweck und Risikokategorie. Für bestimmte Systeme gelten besondere Anforderungen an Risikomanagement, Dokumentation, Transparenz oder menschliche Aufsicht. Auch Datenschutz, Mitbestimmung, Urheberrecht und branchenspezifische Regeln können betroffen sein. Eine pauschale Aussage für „KI-Agenten“ wäre deshalb unzuverlässig; der tatsächliche Ablauf muss eingeordnet werden.

Die EU-Kommission betont für Hochrisikosysteme unter anderem Betrieb nach Gebrauchsanweisung, Überwachung und wirksam ausgestattete menschliche Aufsicht. Unabhängig von der formalen Kategorie sind diese Prinzipien auch für gewöhnliche Unternehmensagenten praktisch sinnvoll. Dieser Ratgeber ersetzt keine Rechtsberatung; er zeigt, welche technischen und organisatorischen Fragen für die Prüfung sichtbar gemacht werden sollten.

Änderungen brauchen dieselbe Sorgfalt wie der erste Start

Ein neues Modell, ein zusätzliches Werkzeug oder eine erweiterte Datenquelle kann den Risikoraum verändern. Änderungen laufen deshalb über eine Testumgebung, den festen Evaluationssatz und eine dokumentierte Freigabe. Notfalländerungen werden nachträglich überprüft. Alte Versionen bleiben soweit nötig nachvollziehbar, damit ein auffälliger Vorgang rekonstruiert werden kann.

Ein Abschaltweg gehört von Anfang an dazu. Werkzeuge können zentral deaktiviert, Zugänge entzogen und wartende Vorgänge in die manuelle Bearbeitung übergeben werden. Das Unternehmen bleibt arbeitsfähig, wenn Modellanbieter, Schnittstelle oder Agent vorübergehend ausfallen.

Auch Beschaffung und Anbieterwechsel gehören zur Verantwortung. Verträge, Datenverwendung, Unterauftragnehmer und Exportmöglichkeiten werden vor dem produktiven Einsatz geprüft. Der Agent sollte so gebaut sein, dass fachliche Regeln und Prozessdaten nicht untrennbar in einer einzelnen Anbieteroberfläche verschwinden.

Ein belastbarer Pilot beginnt mit einer einzigen Aufgabenkarte und einem begrenzten Nutzerkreis. Er soll nicht zeigen, dass ein Modell grundsätzlich Texte erzeugen kann. Er soll belegen, dass der vollständige Ablauf mit echten Eingängen, freigegebenen Daten, Werkzeugen, Übergaben und Fehlerwegen unter den Bedingungen des Unternehmens funktioniert.

Vor dem Bau steht eine beobachtete Prozessstrecke

Das Team begleitet mehrere reale Vorgänge vom Eingang bis zum Abschluss. Es notiert Quellen, Entscheidungen, Sonderfälle und Folgen eines Fehlers. Daraus entstehen Akzeptanzkriterien sowie die Liste erlaubter und verbotener Aktionen. Fehlt dieses Prozesswissen, automatisiert der Pilot Annahmen und erzeugt später Diskussionen über das gewünschte Verhalten.

Der Umfang umfasst auch Betriebselemente: Anmeldung, Rollen, Protokolle, Wiederholschutz, Warteschlange und manuelle Übernahme. Ein Chatfenster ohne diese Bausteine kann eine Idee illustrieren, beantwortet aber nicht, ob der Agent in den Arbeitsalltag passt.

Schattenbetrieb trennt Bewertung von Wirkung

In der ersten Phase sieht der Agent reale Eingänge und erzeugt Vorschläge, verändert aber kein führendes System. Seine Ergebnisse werden mit der menschlichen Bearbeitung verglichen. Abweichungen werden nach Grund erfasst. Erst wenn normale und schwierige Fälle ausreichend verstanden sind, darf der Agent ausgewählte Entwürfe speichern oder interne Aktionen ausführen.

Die nächste Stufe automatisiert ausschließlich reversible Schritte. Freigaben bleiben an folgenreichen Übergängen bestehen. Jede Erweiterung basiert auf beobachteten Ergebnissen, nicht auf dem Wunsch, möglichst schnell einen vollständig autonomen Prozess zu präsentieren.

Die Pilotentscheidung kennt mehr als Erfolg oder Misserfolg

Ein Pilot kann in den Betrieb übergehen, enger zugeschnitten, technisch verändert oder beendet werden. Vielleicht zeigt sich, dass klassische Regeln den größten Teil besser abdecken und das Modell nur bei der Dokumentauswertung hilft. Vielleicht ist die Datenqualität zu schwach oder der Vorgang zu selten. Auch diese Erkenntnisse sind wertvoll, weil sie eine teure Ausweitung verhindern.

Vor dem Übergang werden Verantwortliche, Supportweg, Qualitätsgrenzen und Rückfallprozess bestätigt. Nutzer erhalten eine kurze Einweisung: Was erledigt der Agent, was prüft er nicht, wie wird ein Fehler gemeldet und wann ist manuelle Bearbeitung verpflichtend? Erst dann wird aus dem Experiment ein Arbeitsmittel.

Die Einweisung nutzt echte Grenzfälle statt nur eine Produktvorführung. Mitarbeitende üben, einen Vorschlag abzulehnen, einen Vorgang zu übernehmen und eine fehlerhafte Quelle zu melden. Dadurch wird die vorgesehene Kontrolle im Alltag tatsächlich nutzbar und nicht erst während einer Störung entdeckt.

Wenn du Aufgabe, Rechte und Pilotstrecke nicht allein abbilden kannst, unterstützen wir bei der technischen Umsetzung kontrollierter Automatisierungsabläufe. Fachliche Freigaben und die Verantwortung für den Prozess bleiben dabei im Unternehmen.

Nach dem Start verändert sich nicht nur die Technik. Neue Produkte, Richtlinien, Eingangsformate und Zuständigkeiten beeinflussen die Aufgabe. Gleichzeitig ändern Anbieter Modelle und Schnittstellen. Ein Agent braucht deshalb einen geregelten Betrieb mit Monitoring, fachlichen Stichproben, Updates und einem Backlog für bekannte Grenzen. Ohne diese Pflege wird ein anfangs brauchbarer Ablauf schrittweise unzuverlässig.

Störungen landen in einer sichtbaren Warteschlange

Fehlgeschlagene Werkzeugaufrufe, abgebrochene Läufe und wartende Freigaben erhalten Status, Ursache und Zuständigkeit. Automatische Wiederholungen gelten nur für eindeutig vorübergehende technische Fehler und sind begrenzt. Fachliche Ablehnungen werden nicht durch erneute Modellaufrufe überschrieben. Eine Person kann jeden Vorgang übernehmen und sieht die bereits gesammelten Informationen.

Alarme orientieren sich an Folgen. Ein einzelner langsamer Lesezugriff ist weniger kritisch als mehrere unbestätigte Schreibaktionen oder eine plötzlich steigende Zahl falscher Zuordnungen. Dashboards verbinden technische Signale mit fachlichen Qualitätswerten, damit Betrieb und Fachbereich dieselbe Lage beurteilen.

Modellwechsel sind normale Softwareänderungen

Ein neueres Modell kann besser formulieren und sich trotzdem bei Werkzeugwahl oder strukturierten Ausgaben anders verhalten. Deshalb läuft jede Änderung gegen den festen Testbestand und anschließend im begrenzten Verkehr. Kosten, Geschwindigkeit und Qualität werden gemeinsam betrachtet. Eine Rückkehr zur vorherigen Version bleibt möglich, solange die neue Variante nicht freigegeben ist.

Prompts und Werkzeugbeschreibungen werden wie Code versioniert. Spontane Änderungen direkt im Produktivsystem sind ausgeschlossen. Wer eine Regel anpasst, dokumentiert Anlass, erwartete Wirkung und Testergebnis. Dadurch bleibt nachvollziehbar, warum der Agent einen Vorgang zu einem bestimmten Zeitpunkt anders bearbeitet hat.

Abhängigkeiten werden ebenfalls sichtbar gehalten. Fällt eine Wissensquelle aus oder liefert ein Fachsystem nur veraltete Daten, darf der Agent nicht mit einem scheinbar vollständigen Ergebnis weiterarbeiten. Er kennzeichnet den fehlenden Baustein, stoppt den betroffenen Schritt und übergibt den Vorgang mit einer verständlichen Ursache. Diese Reaktion wird genauso getestet wie der erfolgreiche Normalfall.

Skalierung erfolgt über bewährte Muster, nicht über einen Universalagenten

Ein erfolgreicher Agent kann gemeinsame Bausteine liefern: Anmeldung, Protokollierung, Freigabeoberfläche, Werkzeugregister und Evaluation. Neue Aufgaben erhalten trotzdem eigene Rechte, Testfälle und fachliche Besitzer. Ein großer Universalagent mit Zugriff auf alle Systeme wäre schwerer zu prüfen und vergrößerte die Folgen eines Fehlers.

Mehrere spezialisierte Agenten dürfen zusammenarbeiten, wenn Übergaben strukturiert und begrenzt bleiben. Der erste Agent liefert beispielsweise einen geprüften Datensatz, der zweite erstellt daraus einen Entwurf. Jeder Schritt hat ein eigenes Ergebnis und kann unabhängig abgebrochen werden. Die Architektur folgt damit der Verantwortung im Prozess.

Der Nutzen wird regelmäßig neu geprüft

Gemessen werden akzeptierte Ergebnisse, vermiedene Doppelarbeit, Bearbeitungsqualität und notwendige Nacharbeit. Bleibt ein Agent nur aktiv, weil bereits investiert wurde, entsteht technische Last ohne betrieblichen Wert. Ein geordneter Rückbau ist deshalb ebenso Teil des Lebenszyklus wie Ausbau und Optimierung.

Regelmäßige Reviews verbinden diese Werte mit Rückmeldungen der betroffenen Teams. Sie prüfen, ob der Agent weiterhin dieselbe Aufgabe löst, ob Freigaben sinnvoll liegen und ob sich neue manuelle Umwege gebildet haben. Ein technisch stabiler Dienst kann fachlich trotzdem seinen Zweck verlieren.

Die verantwortliche Person dokumentiert anschließend Entscheidung, Maßnahmen und nächsten Prüftermin.