Unterscheiden Sie eine harte Blockade von einer Benutzerüberschreibung
Eine als blockiert gekennzeichnete Nachricht kann dennoch eine erlaubte Fortsetzung bieten. Bewerten Sie die Aktion, die ein Benutzer ausführen kann, nicht nur den Wortlaut der Benachrichtigung. Warnung, Begründung, Schwärzung und bedingungslose Einschränkung erfüllen unterschiedliche Richtlinienanforderungen.
Für Sicherheitsrichtlinienverantwortliche und technische Bewerter
Zwei fiktive Fälle mit unterschiedlichen Richtlinienentscheidungen
Ein Team erlaubt eine Begründung für ein risikoarmes fiktives Dokument, verlangt aber eine Verhinderung für ein separates synthetisches eingeschränktes Testobjekt. Derselbe Bewerter prüft beide Regeln auf einem genehmigten Testgerät.
Womit Sie arbeiten
- Ein vom Anbieter genehmigtes synthetisches Testobjekt, das einer Regel zugeordnet ist, die eine bedingungslose Einreichungsverhinderung erfordert.
- Ein separates fiktives Beispiel, das einer Regel zugeordnet ist, bei der eine dokumentierte Benutzer-Ausnahme akzeptabel ist.
- Eine schriftliche Entscheidungstabelle, die Erlauben, Warnen, Überschreiben, Schwärzen und Blockieren für diesen Piloten unterscheidet.
Ein sichererer Ansatz
- Bestätigen Sie, welche Aktionen das bewertete Produkt tatsächlich unterstützt, bevor Sie den Richtlinienvergleich vorbereiten.
- Verwenden Sie nur sichtbare, autorisierte Fortsetzungskontrollen; dies ist eine Richtlinienvalidierung, kein Versuch, die Endpunktsicherheit zu umgehen.
- Protokollieren Sie endgültige Einreichungen und verfügbare Beweise, ohne anzunehmen, dass Rechtfertigungstexte oder jede Benutzeraktion protokolliert werden.
Erwartetes Ergebnis: Ein Bewerter kann die beabsichtigte Unterscheidung zwischen einem verbotenen Senden und einer erlaubten Ausnahme demonstrieren, einschließlich dessen, was dem Benutzer jeweils mitgeteilt wird.
Arbeiten Sie das Verfahren durch
Formulieren Sie das erforderliche Ergebnis
Übersetzen Sie die Richtliniensprache in ein beobachtbares Ergebnis. Definieren Sie bei einer bedingungslosen Einschränkung, was nicht das Ziel erreichen darf. Bei einer Ausnahme identifizieren Sie, wer fortfahren darf und welche Überprüfung erforderlich ist. Vermeiden Sie es, ein Interface-Label als Richtlinienspezifikation zu behandeln.
Lösen Sie die konfigurierten Aktionen aus
Führen Sie jeden synthetischen Fall mit der vereinbarten Regel auf einer festen Anbieter- und Browserkombination aus. Lesen Sie die vollständige Nachricht und identifizieren Sie alle angezeigten Steuerelemente. Notieren Sie, ob das Schließen eines Dialogs die Einreichung abbricht, ausstehend lässt oder eine weitere dokumentierte Aktion erlaubt.
Vervollständigen Sie die erlaubten Pfade
Führen Sie die gewöhnlichen vom Interface erlaubten Aktionen aus, einschließlich Abbrechen und jeder autorisierten Überschreibung. Prüfen Sie gegebenenfalls die resultierende Konversation und protokollieren Sie das tatsächliche Ergebnis. Eine geschwärzte Einreichung sollte auf ihren bereinigten Inhalt geprüft werden, anstatt als unveränderte erlaubte Sendung gezählt zu werden.
Überprüfen Sie Ausnahmewesen
Untersuchen Sie alle vom Produkt bereitgestellten Richtlinienereignisse und vergleichen Sie sie mit Ihrem Arbeitsblatt. Ermitteln Sie, welche Fakten eine Ausnahmereview unterstützen können. Wenn ein erwartetes Feld fehlt, vereinbaren Sie einen anderen Beweisprozess oder überarbeiten Sie die Richtlinienanforderung, anstatt die Erfassung anzunehmen.
Was vor dem Fortfahren zu prüfen ist
1. Bedingungslose Einschränkung
- Bereit, wenn
- Die verbotene Aktion kann über die gewöhnlichen Benutzerkontrollen der bewerteten Schnittstelle nicht fortgesetzt werden.
- Wenn die Prüfung fehlschlägt
- Bezeichnen Sie die Regel nicht als harte Blockade; untersuchen Sie deren Konfiguration und unterstütztes Verhalten.
2. Erlaubte Ausnahme
- Bereit, wenn
- Nur der vereinbarte Ausnahmepfad wird fortgesetzt und seine Anweisungen sind für den Testbenutzer klar.
- Wenn die Prüfung fehlschlägt
- Korrigieren Sie die Richtlinie oder Benutzerbenachrichtigung, bevor Sie die Ausnahme breit verfügbar machen.
3. Reviewability
- Bereit, wenn
- Verfügbare Beweise sind ausreichend für die in der Entscheidungstabelle definierte Überprüfungspflicht.
- Wenn die Prüfung fehlschlägt
- Fügen Sie einen separaten genehmigten Überprüfungsprozess hinzu oder wählen Sie eine Richtlinie, die nicht von nicht verfügbaren Beweisen abhängt.
Häufige Fehler vermeiden
- Eine Warnung mit einem Weiter-Button als bedingungslose Blockade zu bezeichnen, nur weil die Anfangsbenachrichtigung restriktive Sprache verwendet.
- Anzunehmen, jede Einschränkung benötige eine Überschreibung, selbst wenn die genehmigte Richtlinie verlangt, dass die Daten nicht in den KI-Dienst gelangen.
Bewerten Sie diesen Workflow mit Aona
Wo Aona helfen kann
Bitten Sie Aona, die unterstützten Richtlinienaktionen an Ihren synthetischen Fällen zu demonstrieren und bestätigen Sie, wie ein etwaiger Ausnahme-Workflow belegt wird.
Was zu bestätigen ist
Leiten Sie keine willkürlichen Genehmigungsketten, Rechtfertigungsfelder oder unveränderliche Prüfprotokolle aus einer Blockierungsdemonstration ab.
Bewerten Sie eine Kontrolle für Ihre Organisation?
Bringen Sie Ihr Ziel-KI-Tool, Gerät und Akzeptanzkriterien mit. Überprüfen Sie den unterstützten Kontrollpfad, die benötigten Nachweise und etwaige Einschränkungen, bevor Sie sich für einen Pilot entscheiden.
FAQ