ca. 3 Minuten

Human Approval + Technical Safety Envelope: Das Sicherheitsmodell von SupraWorx

Veröffentlicht von · SupraTix GmbH
Veröffentlicht am · Aktualisiert am

Human Approval + Technical Safety Envelope: Das Sicherheitsmodell von SupraWorx

Verantwortliche KI braucht menschliche Freigaben und technisch erzwungene Grenzen. Das SupraWorx-Architekturleitbild trennt Aktion, Berechtigung, Quelle, Gerätegrenze und Audit – vom Vorschlag bis zum belegten Ergebnis.

Eine KI erkennt eine Abweichung, schlägt eine Maßnahme vor und bereitet den nächsten Arbeitsschritt vor. In einem Industrieunternehmen entscheidet sich genau an diesem Übergang, ob aus einer hilfreichen Assistenz ein beherrschbarer Prozess wird. Wer darf die Maßnahme freigeben? Welche Anlage ist betroffen? Welche Informationen tragen die Entscheidung? Und was verhindert, dass eine freigegebene Aktion technische Grenzen überschreitet?

Für die öffentliche Positionierung der SupraWorx-Sicherheitsarchitektur steht deshalb ein klares Leitbild im Mittelpunkt: Human Approval + Technical Safety Envelope. Menschliche Verantwortung und technisch erzwungene Handlungsgrenzen bilden zwei eigenständige Schutzebenen. Dieser Beitrag beschreibt das Architekturleitbild und die Anforderungen an seine konkrete Umsetzung. Der Funktionsumfang ist je Integration und freigegebenem Produktstand zu prüfen.

Zwei Schutzebenen mit unterschiedlichen Aufgaben

Human Approval bedeutet eine bewusste Entscheidung der zuständigen Person über eine verständlich dargestellte Handlung. Eine Freigabe soll erkennen lassen, welches Ziel verfolgt wird, welches Objekt betroffen ist, welche Änderung entsteht und wie lange die Zustimmung gilt. Ein allgemeines „Weiter“ ohne diese Angaben reicht für folgenreiche Aktionen nicht aus.

Der Technical Safety Envelope bezeichnet den technisch durchgesetzten Rahmen zulässiger Aktionen: zugelassene Schnittstellen, Geräteidentitäten, Parameterbereiche, Betriebszustände und Ausführungsbedingungen. Er bleibt auch nach einer menschlichen Freigabe wirksam. Eine Zustimmung darf keine technischen Schutzfunktionen aufheben.

Damit dieses Modell überprüfbar bleibt, müssen fünf Fragen getrennt beantwortet werden.

1. Aktion: Was soll konkret geschehen?

Die Aktion beschreibt die beabsichtigte Veränderung: beispielsweise einen Wartungsauftrag als Entwurf anlegen, einen Prüfbericht freigeben oder einen definierten Geräteauftrag übergeben. Zielobjekt, Parameter, erwartete Wirkung und mögliche Nebenwirkungen gehören in eine strukturierte Aktionsbeschreibung. „Wartung veranlassen“ wäre zu ungenau, wenn offenbleibt, ob lediglich ein Auftrag erstellt oder bereits eine Maschine beeinflusst wird.

2. Berechtigung: Wer darf diese Aktion veranlassen?

Berechtigung und Zustimmung erfüllen unterschiedliche Aufgaben. Ein angemeldeter Nutzer kann einen Vorschlag lesen, ohne ihn ausführen zu dürfen. Eine fachlich zuständige Person kann einen Bericht freigeben, ohne Geräteparameter ändern zu dürfen. Maßgeblich sind Identität, Rolle, Unternehmenskontext und der erlaubte Umfang der konkreten Aktion. Die ausführende Schnittstelle muss diese Voraussetzungen unmittelbar vor der Ausführung erneut prüfen.

3. Quelle: Worauf beruht die Entscheidung?

Messwerte, Bilder, Arbeitsanweisungen und historische Ereignisse benötigen eine nachvollziehbare Herkunft. Zur Entscheidungsgrundlage gehören deshalb Quelle, Zeitpunkt, Version und fachlicher Bezug. Ein veralteter Prüfplan oder ein Messwert von einer anderen Anlage kann eine überzeugend formulierte Empfehlung entwerten.

Inhalte aus Dokumenten oder Werkzeugantworten bleiben Daten. Eine darin enthaltene Aufforderung darf keine Berechtigung erzeugen oder eine Freigaberegel ändern. Quellenqualität begründet außerdem keine Ausführungsautorität: Auch eine richtige Diagnose ist noch keine Erlaubnis zum Eingriff.

4. Gerätegrenze: Was kann technisch überhaupt ausgeführt werden?

Bei Geräteaktionen muss der zulässige Rahmen außerhalb der freien Textgenerierung durchgesetzt werden. Dazu gehören eine eindeutige Zielgerätebindung, erlaubte Befehle, validierte Parameter und die Prüfung des aktuellen Betriebszustands. Ein Auftrag für Anlage A darf nicht auf Anlage B übertragbar sein.

Funktionale Sicherheit bleibt Aufgabe der dafür vorgesehenen und für die Anwendung geeigneten Komponenten. Not-Halt, Schutzverriegelungen sowie sichere Geschwindigkeits- und Arbeitsraumgrenzen dürfen durch KI-Vorschläge oder Workflowfreigaben nicht umgangen werden. Dieses Architekturleitbild ist kein Nachweis einer Safety-Zertifizierung.

5. Audit: Was wurde tatsächlich entschieden und ausgeführt?

Ein belastbarer Nachweis verbindet Aktionsvorschlag, Quellenstand, Regelversion, Freigabeentscheidung, ausführende Identität und Ergebnis. Er unterscheidet zwischen vorgeschlagen, freigegeben, übergeben, bestätigt und fehlgeschlagen. Eine erfolgreiche Übertragung an ein Gerät beweist noch keine erfolgreiche Ausführung.

Die Protokollierung benötigt ein eigenes Schutzkonzept: eingeschränkte Schreibrechte, nachvollziehbare Korrekturen, geeigneten Integritätsschutz und definierte Aufbewahrung. Geheimnisse und unnötige personenbezogene Inhalte gehören nicht in ein Auditprotokoll.

Praxisbeispiel: Eine auffällige Prüfung

Eine Kamera liefert einen möglichen Qualitätsfehler. Die KI bereitet einen Prüfbericht und einen Vorschlag für eine Nachprüfung vor. Eine qualifizierte Person prüft die Originalaufnahme und den gültigen Prüfplan. Erst eine gesondert berechtigte und freigegebene Aktion darf einen Folgeauftrag anstoßen. Ob daraus eine Gerätebewegung entstehen darf, entscheidet zusätzlich die technische Geräteprüfung. Das Audit hält Entscheidung und bestätigtes Ergebnis getrennt fest.

SupraTix hat die Trennung zwischen KI-Bewertung und realer Bewegungsautorität bereits in der Darstellung zur agentischen Edge-KI beschrieben. Das hier formulierte Leitbild macht die fünf Verantwortungsbereiche explizit und bildet den Rahmen für die weitere Produktisierung.

Ihr nächster Schritt: Wählen Sie einen konkreten Prozess und dokumentieren Sie Aktion, Berechtigung, Quelle, Gerätegrenze und Audit auf einer Seite. SupraTix kann diesen Prozess mit Ihnen als klar abgegrenzten SupraWorx-Anwendungsfall strukturieren.


Die Beitragsserie

  1. SupraWorx-Sicherheitsarchitektur: Human Approval + Technical Safety Envelope

  2. Werkzeug- und Geräteaktionen in SupraWorx: Freigaben nach Risiko produktisieren

  3. Industrielle Arbeitsergebnisse in SupraWorx: Ein Workspace für Version und Freigabe





SupraTix GmbH oder Partnergesellschaften - Alle Rechte vorbehalten.

Copyright © 2016–2026