Vom eingehenden E-Mail zum gelösten Fall: Einen kontrollierten KI-Workflow entwerfen

1. Den Anwendungsfall abgrenzen, bevor Sie KI auswählen

Ein Klassifizierungs- und Weiterleitungsworkflow macht aus einer eingehenden Anfrage – etwa einer E-Mail – einen geordneten Fall, der an eine Zielwarteschlange oder ein Zielsystem übergeben wird. KI kann dabei helfen, frei formulierte Texte zu interpretieren. Sie sollte jedoch weder der Ausgangspunkt sein noch standardmäßig entscheiden, welche Aktionen ausgeführt werden. Legen Sie zuerst fest, welche Nachrichten eingehen, welches Ergebnis der Prozess liefern soll und welche Situationen außerhalb des Geltungsbereichs liegen.

Beschreiben Sie den Auslöser genau: einen bestimmten Ordner, eine Empfangsadresse oder eine Reihe überprüfbarer Kriterien. Die Power-Automate-Dokumentation beschreibt E-Mail-Auslöser, die nach Eigenschaften wie Ordner, Absender, Empfänger, Vorhandensein von Anhängen und Betreff filtern können. So lassen sich irrelevante Eingaben vor der Verarbeitung reduzieren. Diese Filter ersetzen jedoch weder die Prüfung des Inhalts noch bestimmen sie eigenständig eine semantische Kategorie.

Definieren Sie das operative Ergebnis anhand beobachtbarer Kriterien. Zum Beispiel: In einer Support-Warteschlange wird ein Fall mit einer zulässigen Kategorie, der Nachrichten-ID und einem Verweis auf den ursprünglichen Inhalt angelegt. Versprechen Sie nicht, dass das System die Anfrage löst, wenn der Umfang nur ihre Klassifizierung und Weiterleitung vorsieht. Eine Klassifizierung ist ein Vorschlag oder ein Datenwert im Workflow – sie löst nicht automatisch das Problem der absendenden Person.

Legen Sie außerdem ausdrückliche Ausschlüsse fest. Ein erster Workflow könnte Nachrichten ausnehmen, deren Anhänge eine fachkundige Prüfung erfordern, ebenso rechtliche Anfragen, nicht für die Verarbeitung freigegebene sensible Daten oder Nachrichten, die keine Serviceanfragen sind. In solchen Fällen sollte die sichere Vorgehensweise darin bestehen, die Nachricht zu erhalten und zur Prüfung weiterzuleiten, statt eine ähnliche Kategorie zu erzwingen.

Dokumentieren Sie vor dem Formulieren von Modellanweisungen, wer für den Prozess verantwortlich ist, wer die Kategorien pflegt, wer Änderungen genehmigt und wer die Prüfwarteschlange bearbeitet. Das Team muss erklären können, was geschieht, wenn das System eine Anfrage nicht versteht – nicht nur, wie der Normalfall abläuft.

2. Entscheidungen Regeln, Modell, Mensch oder System zuordnen

Nicht jeder Schritt benötigt KI. Verwenden Sie deterministische Regeln, wenn ein Kriterium eindeutig und stabil ist: nur einen bestimmten Ordner akzeptieren, prüfen, ob ein Absender vorhanden ist, oder feststellen, ob eine erforderliche Kennung fehlt. Eine Regel liefert bei derselben Eingabe dasselbe Ergebnis und lässt sich leichter testen. Verwenden Sie kein Modell für eine Entscheidung, die sich als exakte Prüfung formulieren lässt.

Setzen Sie das Modell für eine klar begrenzte Interpretationsaufgabe ein, etwa um anhand des Anfrageinhalts eine Kategorie vorzuschlagen. Beschränken Sie die Auswahl auf eine geschlossene Liste und verlangen Sie eine strukturierte Ausgabe, die sich von der Integration validieren lässt. Das Modell darf weder Ziele noch Berechtigungen oder Aktionen erfinden können. Allgemeine Beschreibungen von KI-Workflows nennen die Klassifizierung eingehender Tickets als möglichen Anwendungsfall. Sie belegen jedoch nicht die Genauigkeit einer konkreten Implementierung; diese muss das Team in eigenen Tests messen.

Die prüfende Person sollte sich um Ausnahmen kümmern, die das System nicht sicher klassifizieren kann: mehrdeutige Anfragen, überlappende Kategorien, unvollständige Eingaben, Nachrichten außerhalb des Umfangs oder Validierungsfehler. Die Prüfung ist kein optionaler Zwischenschritt, sondern ein definierter Weg mit einer konkreten Warteschlange, einer zuständigen Person und einer nachvollziehbaren Folgeaktion.

Das Zielsystem führt operative Aktionen aus, etwa einen Fall anzulegen oder einen bestehenden Fall zu ergänzen. Trennen Sie den Klassifizierungsvorschlag von der Aktion, die das System verändert. Validieren Sie zuerst den Vorschlag; führen Sie anschließend nur die autorisierte Aktion aus. Erlauben Sie eingehendem E-Mail-Text nicht, das Verhalten des Workflows zu ändern, seine Berechtigungen zu erweitern oder eine nicht im Vertrag vorgesehene Aktion auszuwählen.

Eine vorsichtige Aufteilung der Zuständigkeiten lautet: Regeln filtern und validieren, das Modell schlägt eine Kategorie vor, eine Person bearbeitet Ausnahmen und das System speichert oder leitet nur freigegebene Ergebnisse weiter. Diese Trennung erleichtert die Fehlersuche und verhindert, dass aus einer Vorhersage unmittelbar eine irreversible Aktion wird.

3. Einen Datenvertrag mit Enthaltung entwerfen

Der Datenvertrag legt fest, welche Informationen eingehen, welches Ergebnis akzeptiert wird und was die Integration tun muss, wenn etwas fehlt oder eine Regel nicht erfüllt ist. Er bildet eine technische Grenze zwischen Modell und Zielsystem. Ohne einen solchen Vertrag kann eine plausibel klingende Antwort in natürlicher Sprache mit einem gültigen Ergebnis verwechselt werden, selbst wenn sie unerwartete Felder oder eine nicht existierende Kategorie enthält.

Für einen ersten Test könnten Sie eine Anfrage-ID, den relevanten Text, eine Kategorie aus einer geschlossenen Liste und einen Prüfstatus verlangen. Fügen Sie eine kurze Begründung nur hinzu, wenn sie der Überwachung dient; vermeiden Sie es, mehr personenbezogene Inhalte als nötig zu kopieren. Unterscheiden Sie klar zwischen einem unbekannten Wert, einem fehlenden Feld und einem Validierungsfehler. Diese Fälle sind nicht gleichbedeutend und dürfen nicht stillschweigend in eine Standardkategorie umgewandelt werden.

Eine Enthaltung ist ein gültiges Ergebnis des Workflows. Sehen Sie sie vor, wenn die Eingabe mehrdeutig oder unvollständig ist, außerhalb des Umfangs liegt oder sich anhand eines vom Team definierten und getesteten Kriteriums nicht mit ausreichender Sicherheit klassifizieren lässt. Stellen Sie keinen allgemeinen Schwellenwert als Garantie dar. Der geeignete Wert hängt von den Folgen einer falschen Weiterleitung ab und muss anhand repräsentativer Beispiele kalibriert werden.

Validieren Sie die Ausgabe, bevor Sie sie verwenden. Prüfen Sie, ob alle Pflichtfelder vorhanden sind, die Datentypen stimmen, die Kategorie zur aktuellen Liste gehört und der Prüfstatus mit den geltenden Regeln übereinstimmt. Ist eine Bedingung nicht erfüllt, darf der Fall nicht so an eine operative Warteschlange weitergeleitet werden, als wäre er freigegeben. Bewahren Sie die Anfrage auf und leiten Sie den Fehler an eine Prüfung oder Fehlerwarteschlange weiter.

Behandeln Sie eingehenden Text als Daten, nicht als Steueranweisungen. Eine E-Mail kann Formulierungen enthalten, die versuchen, die Aufgabe zu ändern oder andere Aktionen anzufordern. Die Integration darf nur die im festgelegten Vertrag vorgesehene Extraktion und Klassifizierung durchführen; der Nachrichteninhalt darf die verfügbaren Funktionen des Workflows niemals erweitern.

4. Einen sicheren Ausführungsweg aufbauen

Gestalten Sie die Abfolge als kleine, beobachtbare Schritte: E-Mail empfangen, identifizieren, Geltungsbereich prüfen, Daten vorbereiten, Kategorie anfordern, Antwort validieren, Ausnahmen prüfen, Fall weiterleiten und Ergebnis protokollieren. Jeder Schritt braucht eine Erfolgsbedingung und einen Fehlerpfad. Schlägt eine Phase fehl, muss die Anfrage weiterhin auffindbar sein und darf nicht verloren gehen, weil die Verarbeitung unvollständig blieb.

Verwenden Sie Filter im Auslöser, wenn sie unnötige Ausführungen reduzieren. Die Microsoft-Dokumentation weist darauf hin, dass E-Mail-Eigenschaften direkt im Auslöser geprüft werden können, und warnt davor, sie erst später als Bedingung zu prüfen: Auch wenn der Filter nicht zutrifft, kann dann eine Ausführung auf das Kontingent angerechnet werden. Das ist eine Besonderheit von Power Automate und dessen Kontingenten; sie lässt sich nicht automatisch auf andere Plattformen übertragen.

Prüfen Sie vor dem Anlegen eines Falls, ob die Anfrage bereits verarbeitet wurde. Verwenden Sie dafür eine stabile Nachrichtenkennung oder einen mit dem Zielsystem vereinbarten Idempotenzschlüssel. Die verfügbare Anleitung zu E-Mail-Auslösern beschreibt keinen vollständigen Idempotenzmechanismus. Deshalb muss dieser Schutz in der gewählten Integration geprüft werden; er darf nicht allein aufgrund des Einsatzes eines automatisierten Workflows vorausgesetzt werden.

Geben Sie der Integration nur die Berechtigungen, die sie für ihre Aufgaben benötigt. Muss sie Nachrichten lesen und Fälle anlegen, sollte sie nicht zusätzlich E-Mails löschen, Benutzer verwalten oder Kategorien ändern dürfen, sofern dafür kein nachgewiesener Bedarf besteht. Wenn die Plattform es ermöglicht, trennen Sie die Identität zum Lesen von E-Mails von der Identität zum Schreiben in die Warteschlange. Dokumentieren Sie außerdem, wer Verbindungen und Zugangsdaten ändern darf.

Protokollieren Sie Kennungen und Entscheidungen so, dass sich der Ablauf rekonstruieren lässt: Eingang, Kategorienversion, validiertes Ergebnis, Weiterleitung, Fehler und menschliche Prüfung. Legen Sie gemäß den einschlägigen Richtlinien fest, welche Daten nicht gespeichert werden dürfen, wer die Protokolle einsehen kann und wie lange sie aufbewahrt werden. Das Protokoll darf nicht zur unselektierten Kopie des gesamten Posteingangs werden.

Planen Sie für Teilausfälle. Antwortet das Zielsystem nicht, muss der Fall als ausstehend erhalten bleiben und der Fehler protokolliert werden. Verhindern Sie Duplikate bei Wiederholungsversuchen. Lässt sich nicht bestätigen, ob eine Aktion abgeschlossen wurde, wiederholen Sie sie nicht blind: Fragen Sie den Status anhand der Anfragenkennung ab oder leiten Sie den Fall zur manuellen Abstimmung weiter.

5. Normale, unvollständige und mehrdeutige Fälle testen

Ein sinnvoller Test besteht nicht darin, eine einzelne E-Mail zu senden und zu prüfen, ob ein Fall erscheint. Erstellen Sie eine Reihe fiktiver Nachrichten, die erwartete Abläufe und Ausnahmen abdeckt. Verwenden Sie für erste Verhaltenstests nach Möglichkeit synthetische Beispiele statt echter personenbezogener Daten. Achten Sie darauf, dass Testtexte keine Verbindungen oder Aktionen außerhalb der kontrollierten Umgebung auslösen.

Nehmen Sie vollständige Anfragen aus verschiedenen Kategorien, Nachrichten ohne erforderliche Angaben, E-Mails mit überlappenden Kategorien, Nachrichten außerhalb des Umfangs und fehlerhaft formatierte Modellausgaben auf. Testen Sie auch Integrationsfehler: nicht erreichbares Ziel, Zeitüberschreitung, abgelehnte Berechtigungen und einen erneuten Versuch nach unklarem Ergebnis. Schreiben Sie für jeden Fall vorab das erwartete Ergebnis, die Zielwarteschlange und den erwarteten Protokolleintrag auf.

Bewerten Sie beobachtbare Fakten, nicht den subjektiven Eindruck von der Textqualität. Prüfen Sie, ob die richtige Nachricht am vorgesehenen Ziel ankommt, Kennungen erhalten bleiben, mehrdeutige Eingaben zur Enthaltung oder Prüfung führen und Fehler die Anfrage nicht verschwinden lassen. Schlägt das Modell eine falsche Klassifizierung vor, messen Sie, wie oft dies im Testsatz geschieht, und bewerten Sie die Folgen der jeweiligen Fehlerart.

Der Testsatz sollte die tatsächlich eingehenden Kategorien und Formulierungen abbilden – innerhalb der geltenden Datenschutz- und Zugriffsgrenzen. Ändern sich Kategorien, führen Sie die relevanten Tests erneut aus. Behaupten Sie keine Genauigkeit, bevor sie im eigenen Kontext gemessen wurde; Beispiele aus allgemeinen Leitfäden oder von Anbietern ersetzen keine eigenen Ergebnisse.

Behalten Sie zu Beginn der Einführung einen Vergleich mit dem manuellen Prozess bei. So lassen sich Unterschiede zwischen dem Modellvorschlag und der Entscheidung der prüfenden Person erkennen. Legen Sie fest, wer einen Fall korrigieren darf und wie die Korrektur protokolliert wird. Dadurch kann das Team einen Klassifizierungsfehler von einem Integrationsfehler unterscheiden.

6. Mit menschlicher Prüfung und minimalen Berechtigungen integrieren

Die Prüfwarteschlange muss ein konkretes Ziel sein, keine vage Bezeichnung. Bestimmen Sie, wer sie bearbeitet, innerhalb welcher betrieblichen Frist, welche Informationen benötigt werden und wie eine Korrektur kommuniziert wird. Ist niemand für Ausnahmen zuständig, verlagert die Enthaltung das Problem lediglich und kann einen unsichtbaren Rückstau erzeugen.

Beginnen Sie, sofern praktikabel, im Beobachtungsmodus: Das System schlägt Kategorien vor und eine Person bestätigt jede Weiterleitung. Vergleichen Sie Vorschläge und menschliche Entscheidungen, bevor Sie den Automatisierungsgrad erhöhen. Legen Sie im Voraus fest, welche Nachweise die automatische Anlage von Fällen rechtfertigen und wer diese Änderung genehmigen darf. Das bedeutet nicht, dass die Genauigkeit des Modells bereits bekannt ist; so kann sie im tatsächlichen Prozess gemessen werden.

Konfigurieren Sie die Berechtigungen so, dass der Workflow nur das Notwendige ausführen kann. Prüfen Sie die verwendeten Verbindungen, den Zugriff auf Postfächer und die Fähigkeit, Fälle anzulegen oder zu ändern. Die Power-Automate-Anleitungen verlangen für die dort beschriebenen Beispiele Verbindungen zu den verwendeten Diensten. Sie legen jedoch kein universelles Modell für minimale Berechtigungen in allen Umgebungen fest. Die Konfiguration muss daher für die konkrete Plattform und Organisation geprüft werden.

Trennen Sie Lese-, Schreib- und Administrationsrechte, sofern dies möglich ist. Begrenzen Sie, wer Kategorien, Weiterleitungsregeln, Zugangsdaten und den Klassifizierungsprompt ändern darf. Verändert eine Änderung das Ziel oder den Umfang, sind vor der Freigabe Tests und eine Genehmigung erforderlich.

Sorgen Sie dafür, dass prüfende Personen die nötigen Informationen sehen können, ohne mehr Daten zu erhalten als erforderlich. Legen Sie fest, wie sensible Nachrichten behandelt werden, wie auf das Original zugegriffen wird und welche Daten in Benachrichtigungen oder Protokollen erscheinen. Aufbewahrungs- und Zugriffsentscheidungen hängen von den Richtlinien der Organisation ab; sie folgen nicht automatisch daraus, dass eine Automatisierung funktioniert.

7. Überwachung, Vorfälle und Rückkehr zum manuellen Prozess festlegen

Legen Sie vor dem Start Kennzahlen fest, die den Betrieb beschreiben, ohne sie als Leistungsversprechen darzustellen: eingehendes Volumen, Anteil der Fälle in der Prüfwarteschlange, Validierungsfehler, doppelte Weiterleitungen, Ausfälle des Zielsystems, Wiederholungsversuche und menschliche Korrekturen. Vergleichen Sie zur Bewertung der Klassifizierung den Modellvorschlag mit einer geprüften Entscheidung und dokumentieren Sie, wie das Ergebnis berechnet wird.

Vereinbaren Sie betriebliche Grenzen, bei deren Überschreitung der Workflow pausiert wird. Ein unerwarteter Anstieg von Fehlern, eine Prüfwarteschlange, die ihre Kapazität überschreitet, oder eine nicht genehmigte Änderung von Kategorien können beispielsweise eine Deaktivierung der automatischen Aktion rechtfertigen. Die Schwellenwerte müssen zur Arbeitslast und zum Risiko des Prozesses passen; die verfügbare Dokumentation belegt keinen universellen Wert.

Die Rückkehr zum manuellen Prozess muss möglich sein, ohne ausstehende Anfragen zu verlieren. Führen Sie eine Liste der verarbeiteten und ausstehenden Nachrichten, dokumentieren Sie die Deaktivierung des Workflows und verhindern Sie, dass nach einer Wiederaufnahme bereits bearbeitete E-Mails unkontrolliert erneut verarbeitet werden. Testen Sie Pause und Wiederanlauf vor dem Start, nicht erst während eines echten Vorfalls.

Protokollieren Sie Änderungen an Kategorien, Prompts, Regeln, Berechtigungen und Konnektoren mit verantwortlicher Person und Datum. Führen Sie nach jeder wesentlichen Änderung die einschlägigen Tests für Normalfälle, Enthaltungen, Fehler und Duplikate erneut aus. Ändern sich Zielplattform oder Auslöser, prüfen Sie außerdem Verbindungen und Berechtigungen.

Eine kontrollierte Implementierung ist nicht abgeschlossen, sobald der Workflow gespeichert wurde. Operations und Technik müssen Fehler erkennen, Ausnahmen bearbeiten, Fälle korrigieren und die Automatisierung stoppen können. Erfolg bedeutet, dass jede Anfrage nachvollziehbar ist und in einen gültigen Prozesspfad gelangt – auch wenn die KI keine Entscheidung treffen kann.

8. Den gesamten Ablauf mit fiktiven Daten durchspielen

Angenommen, das Postfach erhält die Nachricht msg-1042 im Ordner „Anfragen“. Der Betreff lautet „Ich kann mich nicht anmelden“, der Text: „Seit heute Morgen kann ich mich nicht anmelden. Können Sie mir helfen?“ Der Filter bestätigt, dass die Nachricht im überwachten Ordner eingegangen ist. Die Integration bewahrt die Kennung und bereitet nur den Betreff und den für die Klassifizierung erforderlichen Text auf.

Das Modell gibt die Kategorie „Zugang“ zurück. Sie steht auf der zulässigen Liste und wird mit dem Status „zur Weiterleitung bereit“ versehen. Die Validierung bestätigt, dass alle Felder vorhanden sind und der Kategorie ein Ziel zugeordnet ist. Das System prüft, ob msg-1042 bereits mit einem Fall verknüpft ist. Da kein Fall gefunden wird, legt es einen fiktiven Fall mit Verweis auf die E-Mail an und protokolliert die Entscheidung.

Ändern Sie nun die Nachricht zu: „Es funktioniert nicht. Es ist dringend.“ Reicht der Kontext nicht aus, um zwischen einem Zugangsproblem, einem allgemeinen Ausfall oder einem anderen Vorfall zu unterscheiden, darf der Workflow nicht raten. Er gibt eine Enthaltung zurück und leitet die Nachricht unter Beibehaltung ihrer Kennung an die Prüfwarteschlange weiter. Die prüfende Person kann weitere Informationen anfordern oder die richtige Kategorie gemäß dem festgelegten Verfahren zuweisen.

Simulieren Sie abschließend eine nicht zulässige Kategorie oder einen Ausfall des Zielsystems. Die nicht zulässige Kategorie muss bei der Validierung gestoppt werden. Bei einem Ausfall des Zielsystems muss die Anfrage mit einem Fehler ausstehend bleiben und sich kontrolliert erneut versuchen oder manuell abstimmen lassen. In keinem der beiden Fälle darf die Nachricht verloren gehen oder stillschweigend zu einer gültigen Weiterleitung werden.

An diesem Ablauf lässt sich die Grenze zwischen Interpretation und Aktion überprüfen: Das Modell schlägt vor, die Regeln validieren, eine Person bearbeitet Ausnahmen und das System führt die autorisierte Aktion aus. Wiederholen Sie die Tests mit den für den Prozess relevanten Fällen, bevor Sie von einer Testumgebung in den operativen Betrieb wechseln. Leiten Sie aus wenigen Beispielen keine Aussagen über alle Nachrichten ab, die die Organisation erhalten wird.

Weiter entdecken

Korrekturen und Transparenz

Wenn du falsche oder veraltete Angaben findest, sende uns die Seite und die zu prüfende Quelle.