Sicheres Degradationsverhalten entwerfen: Leitfaden für KI-Automatisierungen

Anwendungsfall und mögliche Schäden eingrenzen

Bevor Sie festlegen, wie eine Automatisierung auf Fehler reagiert, müssen Sie den Umfang der Aufgabe und die möglichen Folgen eines Fehlers eingrenzen. Nicht alle Fehler sind gleich schwerwiegend: Eine fehlerhaft formatierte Textausgabe ist zunächst ein Validierungsproblem. Eine Aktion mit externen Auswirkungen – etwa eine E-Mail zu versenden oder einen Datenbankeintrag zu ändern – birgt dagegen ein höheres betriebliches Risiko.

Entscheidend ist, Fehler bei der Generierung von Fehlern bei der Ausführung zu unterscheiden. Erstere betreffen die Qualität der Modellausgabe, Letztere die Fähigkeit des Systems, die Aufgabe tatsächlich abzuschließen. Diese Trennung ermöglicht angemessene Schutzmaßnahmen: strenge Validierung für generierte Ausgaben und die Prüfung des vorherigen Zustands, um Aktionen bei einer Wiederholung nicht doppelt auszuführen. Beschränken Sie den Anwendungsfall auf einen klar abgegrenzten Arbeitsablauf und benennen Sie, welche Folgen ein falsches, verspätetes oder ausbleibendes Ergebnis haben kann.

Eine tragfähige Richtlinie für den Fehlerfall beschreibt nicht nur, was technisch schiefgehen kann, sondern auch, was das System dann tun darf. Für jede mögliche Reaktion sollte feststehen, ob sie eine reine Abfrage wiederholt, eine Aufgabe sicher anhält, sie an eine zuständige Person weiterleitet oder den manuellen Ablauf wieder aufnimmt. Legen Sie außerdem fest, wer für einen eskalierten Fall verantwortlich ist und welche Informationen diese Person zur Bearbeitung benötigt.

Die Abgrenzung des Anwendungsfalls erfordert eine präzise Analyse der spezifischen Risiken, die mit der jeweiligen Aufgabe verbunden sind. Dabei ist zu berücksichtigen, dass die Schwere eines Fehlers nicht nur von der technischen Natur der Störung abhängt, sondern auch von der Geschwindigkeit, mit der die negativen Auswirkungen eintreten. Eine fehlerhafte Textausgabe kann oft noch vor der Weitergabe an den Endnutzer korrigiert werden, während eine bereits versendete E-Mail oder eine modifizierte Datenbankzeile sofortige und schwerwiegende Konsequenzen nach sich ziehen kann. Diese zeitliche Dimension muss bei der Festlegung der Schutzmaßnahmen einbezogen werden, um sicherzustellen, dass die Reaktionszeit des Systems den potenziellen Schaden begrenzt, bevor er irreversibel wird.

Zusätzlich zur Unterscheidung zwischen Generierungs- und Ausführungsfehlern ist es wichtig, die Abhängigkeiten des Systems von externen Diensten zu kartieren. Jede externe Schnittstelle stellt einen potenziellen Punkt dar, an dem Fehler auftreten können, die nicht direkt durch das eigene System kontrolliert werden. Die Dokumentation dieser Abhängigkeiten hilft, die Grenzen der automatisierten Wiederherstellung zu erkennen. Wenn ein externer Dienst nicht verfügbar ist, kann das System nur begrenzte Maßnahmen ergreifen, wie das Warten oder das Anhalten der Aufgabe. Es ist daher entscheidend, dass die Richtlinie klar definiert, wie lange das System auf eine Antwort warten darf, bevor es die Aufgabe als fehlgeschlagen markiert und an eine menschliche Instanz übergibt, um unendliche Warteschleifen zu vermeiden.

Beobachtbare Fehlerzustände festlegen

Eine wirksame Wiederherstellungsrichtlinie setzt voraus, dass sich jeder Fehlerzustand anhand eines objektiven und reproduzierbaren Signals erkennen lässt. Vermeiden Sie Regeln, die auf subjektiven Eindrücken wie „die Antwort wirkt zweifelhaft“ beruhen. Definieren Sie stattdessen konkrete Bedingungen, die sich durch technische Prüfungen oder messbare Ereignisse feststellen lassen.

Zu den wichtigen Zuständen zählen eine ungültige Ausgabe, eine unvollständige Antwort, eine abgelaufene Wartezeit, ein nicht verfügbarer Dienst, ein mehrdeutiges Ergebnis und eine Aktion, deren Ausführungsergebnis unbekannt ist. Ordnen Sie jedem Zustand eine eindeutige Reaktion zu. So entstehen keine Grauzonen, in denen das System weder sicher fortfahren noch zuverlässig stoppen kann.

Unterscheiden Sie dabei zwischen einem Fehler, der lediglich eine weitere Abfrage betrifft, und einem Fehler, der während oder nach einer Aktion mit externen Auswirkungen auftritt. Ein Zeitlimit beim Abruf von Informationen lässt nicht automatisch darauf schließen, ob eine anschließend ausgelöste Aktion bereits ausgeführt wurde. Ist der Zustand einer solchen Aktion unklar, muss die Richtlinie zuerst eine Prüfung vorsehen und darf nicht blind erneut ausführen.

Die Definition beobachtbarer Fehlerzustände muss so granular sein, dass jede mögliche Abweichung vom erwarteten Verhalten eindeutig zugeordnet werden kann. Dies erfordert die Implementierung von Logging-Mechanismen, die nicht nur den Erfolg oder Misserfolg eines Schrittes protokollieren, sondern auch den Kontext des Fehlers erfassen. Ohne diese Kontextinformationen ist es schwierig, die Ursache eines Fehlers zu bestimmen und die angemessene Wiederherstellungsmaßnahme auszuwählen. Die Protokollierung sollte so gestaltet sein, dass sie nachvollziehbar ist und es ermöglicht, den Verlauf der Automatisierung im Fehlerfall zu rekonstruieren, um zukünftige Probleme zu vermeiden.

Ein weiterer wichtiger Aspekt der Beobachtbarkeit ist die Unterscheidung zwischen einem temporären und einem permanenten Fehler. Ein temporärer Fehler, wie eine kurze Netzwerkstörung, kann durch eine begrenzte Wiederholung behoben werden, während ein permanenter Fehler, wie eine ungültige Konfiguration, eine menschliche Intervention erfordert. Die Richtlinie muss Kriterien definieren, anhand derer das System diese Unterscheidung treffen kann. Dies kann durch die Analyse der Fehlermeldungen oder durch das Überwachen der Antwortzeiten erfolgen. Wenn das System nicht in der Lage ist, diese Unterscheidung automatisch zu treffen, sollte es die Aufgabe an eine menschliche Instanz übergeben, um eine falsche Wiederherstellungsmaßnahme zu vermeiden.

Für jeden Zustand eine Reaktion festlegen

Legen Sie für jeden beobachtbaren Zustand eine Standardreaktion fest. Die wichtigsten Möglichkeiten sind: eine begrenzte Wiederholung, die Enthaltung – also die Aufgabe ohne Ausführung der abschließenden Aktion anzuhalten – oder die Übergabe an eine zuständige Person. Welche Reaktion passt, hängt unter anderem von der Umkehrbarkeit der Aktion und den Folgen eines Fehlers ab.

Eine Wiederholung kann bei vorübergehenden Störungen einer externen Abhängigkeit sinnvoll sein. Begrenzen Sie dabei sowohl die Anzahl als auch den Zeitraum der Versuche. Enthaltung ist die sicherere Wahl, wenn die Ausgabe ungültig ist oder der Status einer Aktion nicht feststeht: Das System führt die abschließende Aktion nicht aus und kennzeichnet den Fall zur Prüfung. Eine menschliche Entscheidung ist besonders wichtig, wenn ein Fehler hohe Folgen haben kann oder sich eine Aktion nicht ohne Weiteres rückgängig machen lässt.

Bestimmen Sie für jede Weiterleitung eine konkrete zuständige Rolle, die benötigten Informationen und den Abschluss des Falls. Der manuelle Rückweg muss ebenfalls beschrieben sein: Wer übernimmt die Aufgabe, wie wird der bisherige Bearbeitungsstand weitergegeben und woran erkennt man, dass die Automatisierung nicht parallel weiterarbeitet? So bleibt kein Fall ohne Verantwortliche liegen.

Die Festlegung der Reaktionen auf Fehlerzustände muss auch die Kosten der menschlichen Intervention berücksichtigen. Wenn die Kosten für eine menschliche Prüfung höher sind als die potenziellen Schäden durch einen Fehler, kann es sinnvoll sein, eine automatische Wiederherstellungsmaßnahme zu wählen, auch wenn sie ein gewisses Risiko birgt. Umgekehrt, wenn die Kosten für einen Fehler sehr hoch sind, sollte die Schwelle für eine menschliche Intervention niedriger angesetzt werden. Diese Abwägung muss für jeden Fehlerzustand individuell getroffen werden und in der Richtlinie dokumentiert sein. Die Dokumentation dieser Entscheidungen hilft, die Transparenz des Systems zu erhöhen und es den Betreibern zu ermöglichen, die Richtlinie bei Bedarf anzupassen.

Die Übergabe an eine zuständige Person muss so gestaltet sein, dass der Kontext des Fehlers vollständig übergeben wird. Dies umfasst nicht nur die Fehlermeldung, sondern auch den aktuellen Zustand der Aufgabe, die bereits ausgeführten Schritte und die geplanten nächsten Schritte. Ohne diese Informationen ist es für die menschliche Instanz schwierig, die Aufgabe schnell und korrekt zu bearbeiten. Die Übergabe sollte daher einen standardisierten Bericht enthalten, der alle relevanten Informationen zusammenfasst. Dieser Bericht sollte auch Vorschläge für mögliche Lösungen enthalten, um die Bearbeitungszeit zu verkürzen und die Fehlerquote zu reduzieren.

Doppelte Auswirkungen vermeiden

Das größte Wiederherstellungsrisiko besteht darin, eine Aktion mit Folgen zu wiederholen, die möglicherweise bereits ausgeführt wurde. Wird eine Aktion nach einer Unterbrechung blind erneut gestartet, kann das beispielsweise zwei E-Mails versenden oder zwei Datensätze anlegen. Unterscheiden Sie daher zwischen einer wiederholbaren Abfrage und einer Aktion, die externe Auswirkungen hat. Eine Abfrage lässt sich oft gefahrlos wiederholen; bei einer Aktion ist das nicht automatisch der Fall.

Eine technische Schutzmaßnahme ist Idempotenz: Mehrere Ausführungen derselben Aktion sollen denselben Endzustand erzeugen wie eine einzelne Ausführung. Ist das nicht möglich, muss vor der erneuten Ausführung der aktuelle Zustand im Zielsystem geprüft werden. Diese Prüfung gehört verbindlich in den Wiederherstellungsablauf und darf nicht als optionale Zusatzkontrolle behandelt werden.

Verwenden Sie, wo es die Schnittstelle ermöglicht, einen eindeutigen Schlüssel für eine Aktion und protokollieren Sie den Ausführungsstatus. Geht eine Antwort verloren oder läuft ein Aufruf in ein Zeitlimit, darf das System nicht allein aus dem fehlenden Ergebnis schließen, dass die Aktion fehlgeschlagen ist. Es muss zunächst feststellen, ob die Wirkung bereits eingetreten ist. Kann der Status nicht verlässlich ermittelt werden, ist Enthaltung mit menschlicher Prüfung sicherer als ein unkontrollierter Wiederholungsversuch.

Die Vermeidung doppelter Auswirkungen erfordert eine sorgfältige Planung der Schnittstellen zwischen dem Automatisierungssystem und den Zielsystemen. Jede Schnittstelle muss so gestaltet sein, dass sie Idempotenz unterstützt oder zumindest die Möglichkeit bietet, den Status einer Aktion zu überprüfen. Wenn eine Schnittstelle keine Idempotenz unterstützt, muss das Automatisierungssystem zusätzliche Mechanismen implementieren, um doppelte Ausführungen zu verhindern. Dies kann durch die Verwendung von Transaktionen oder durch das Protokollieren der ausgeführten Aktionen erfolgen. Die Wahl des Mechanismus hängt von den Anforderungen des jeweiligen Zielsystems ab und muss in der Architektur des Automatisierungsystems berücksichtigt werden.

Die Protokollierung des Ausführungsstatus ist ein wesentlicher Bestandteil der Vermeidung doppelter Auswirkungen. Die Protokolle müssen so gestaltet sein, dass sie lückenlos und unveränderlich sind, um sicherzustellen, dass der Status einer Aktion nicht versehentlich überschrieben oder gelöscht wird. Die Protokolle sollten auch so strukturiert sein, dass sie leicht durchsuchbar sind, um den Status einer bestimmten Aktion schnell zu überprüfen. Die Verfügbarkeit dieser Protokolle ist entscheidend für die Fehlersuche und die Überprüfung der Korrektheit des Automatisierungssystems. Ohne diese Protokolle ist es schwierig, nachzuweisen, dass eine Aktion nur einmal ausgeführt wurde, was zu einem erhöhten Risiko für doppelte Auswirkungen führt.

Fehler gezielt testen und Abnahmekriterien festlegen

Eine Degradationsrichtlinie ist erst dann belastbar, wenn sie unter gezielt herbeigeführten Fehlerbedingungen getestet wurde. Die Abnahmetests sollten kontrollierte Störungen abdecken: eine nicht verfügbare Abhängigkeit, eine fehlerhaft formatierte Ausgabe, eine verspätete Antwort, ein mehrdeutiges Ergebnis und eine Unterbrechung während der Ausführung. Ziel ist zu prüfen, ob das System tatsächlich entsprechend der Entscheidungsmatrix reagiert.

Legen Sie überprüfbare Abnahmekriterien fest: Wurde der Fehler innerhalb der vorgesehenen Zeit erkannt? Wurde die richtige Wiederherstellungsreaktion ausgelöst? Wurde eine Aktion nur einmal ausgeführt? Wurde die zuständige Person informiert, wenn eine Prüfung nötig war? Konnte der Vorgang anschließend manuell fortgesetzt werden, ohne dass die Automatisierung parallel weiterlief? Ohne solche Tests ist nicht belegt, dass der Ablauf für einen kontrollierten Einsatz bereit ist.

Prüfen Sie nicht nur den erfolgreichen Wiederanlauf. Testen Sie ausdrücklich auch, ob das System sich enthält oder weiterleitet, wenn der Status einer Aktion unklar bleibt. Dokumentieren Sie die Testergebnisse und ordnen Sie Abweichungen einer verantwortlichen Person zu. Diese Anleitung beschreibt Entwurfs- und Prüfempfehlungen; sie stellt weder eine rechtliche Verpflichtung noch eine unabhängige Sicherheitsgarantie dar.

Die Durchführung von Tests mit gezielt herbeigeführten Fehlerbedingungen muss in einer kontrollierten Umgebung erfolgen, die die Produktionsumgebung so genau wie möglich nachbildet. Dies ist wichtig, um sicherzustellen, dass die Testergebnisse realistisch sind und die tatsächliche Leistung des Systems unter Fehlerbedingungen widerspiegeln. Die Testumgebung sollte alle relevanten Abhängigkeiten und Schnittstellen enthalten, um die Interaktion des Systems mit der Umgebung zu testen. Die Ergebnisse der Tests sollten dokumentiert und analysiert werden, um Schwachstellen in der Fehlerbehandlung zu identifizieren und zu beheben. Diese iterative Verbesserung der Fehlerbehandlung ist entscheidend für die Zuverlässigkeit des Automatisierungssystems.

Die Abnahmekriterien müssen so formuliert sein, dass sie objektiv überprüfbar sind. Dies erfordert die Definition von quantitativen Metriken, wie der Reaktionszeit des Systems, der Anzahl der Wiederholungsversuche und der Genauigkeit der Fehlererkennung. Diese Metriken sollten in den Tests gemessen und mit den definierten Grenzwerten verglichen werden. Wenn die gemessenen Werte die Grenzwerte überschreiten, muss die Ursache des Problems ermittelt und behoben werden. Die Dokumentation der Testergebnisse und der ergriffenen Maßnahmen hilft, die Transparenz des Systems zu erhöhen und es den Betreibern zu ermöglichen, die Zuverlässigkeit des Systems zu bewerten. Ohne diese objektiven Kriterien ist es schwierig, die Qualität der Fehlerbehandlung zu beurteilen und sicherzustellen, dass das System für den produktiven Einsatz bereit ist.

Weiter entdecken

Korrekturen und Transparenz

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