Ein Agent hat vielleicht die richtige Identität herausgefunden.
Es könnte auf aktuellem und kanonischem Wissen basieren.
Es kann die Option gesetzt haben, die wirklich den Bedürfnissen des Benutzers entspricht.
Eine gültige Zustimmung, Befugnis und Genehmigung kann auch gefunden werden.
Trotz all dessen kann das Handeln wieder falsch sein.
Weil:
Die richtige Entscheidung ist keine Garantie für eine ordnungsgemäße Ausführung.
Der Agent kann die richtige Kundenadresse finden, aber nur die CRM Das Versandsystem wird aufgezeichnet und überholt.
Es kann den korrekten Rückgabebetrag berechnen; aber es kann die Zahlung auf die Bestellung eines anderen Kunden anwenden.
A API kann die Antwort erhalten HTTP 200 Die Methode und die API kann die Tatsache, dass das wirkliche Ergebnis der erfolgreich bearbeiteten Anfrage ist noch nicht vollständig zu verpassen.
Wenn die Antwort des Netzwerks verzögert wird, kann es die gleiche Zahlung ein zweites Mal machen.
Sie können fünf der sechs Sprachen veröffentlichen und die gesamte Veröffentlichung als vollständig betrachten.
Es kann sich nicht auf die "erfolgreiche" Nachricht des Dateitransfer-Tools verlassen und überprüfen, was tatsächlich im Live-System gefunden wird.
Sie kann ohne Verständnis vorgehen, an welchem Punkt der Prozess nicht rückgängig gemacht werden kann.
Sie kann zu persönliche, kommerzielle oder vertrauliche Daten für eine einfache Aufgabe verwenden.
Und am Ende gibt es vielleicht keine Aufzeichnungen darüber, was sie getan haben, für wen sie es getan haben und auf welchen Beweisen sie beruhten.
Fahren ist nicht nur ein Befehl.
Jede Aktion hat mindestens folgende Fragen:
Auf welchem System? Welches Ziel? Mit welchen Daten? Wie oft? Womit? Mit welcher unabhängigen Überprüfung? Mit welchem Mittel der Rückkehr? Unter welcher Akte?
Die neun Fehler in diesem Abschnitt untersuchen die Verschlechterung der gültigen Befugnis aufgrund des falschen Systems, falsche Ziel, fehlerhafte Erfolgsinterpretation oder unvollständige Exekutivdisziplin.
GBO-ERR-046 — Die richtige Handlung im falschen System ausführen
Kurzfall
Ein Kunde möchte die Lieferadresse seiner Bestellung ändern, die noch nicht versendet wurde.
Es weist den Kundendienstmitarbeiter an:
"Senden Sie meinen Auftrag an meine neue Büroadresse. Ich habe keinen Zugang mehr zu der alten Adresse."
Der Agent bestätigt die Identität des Klienten.
Die neue Adresse ist voll.
Öffnet die Kundenkarte auf CRM System und aktualisiert die Adresse.
Dann geben sie dem Kunden diese Antwort:
"Ihre Lieferadresse wurde erfolgreich geändert."
Die Lieferadresse wird jedoch nicht von CRM während der Bestellung vorbereitet wird, aber aus einem separaten Datensatz im Order Management System.
Die neue Adresse erscheint unter CRM..
Das Versandsystem trägt weiterhin die alte Adresse.
Das Paket wird an die Adresse gesendet, an der der Kunde nicht mehr darauf zugreifen kann.
Der Agent nutzte die richtigen Informationen für den richtigen Kunden.
Sie haben jedoch die Änderung nicht auf das System angewandt, das tatsächlich das Verhalten regelt.
Was oberflächlich richtig erscheint
CRM hat ein Feld "Adresse".
Die Kundenkarte wurde erfolgreich aktualisiert.
Das System hat keine Fehler gemacht.
Neue Adresse erscheint auf dem Bildschirm des Agenten.
Daher scheint der Prozess abgeschlossen zu sein.
Aber das gleiche ist in verschiedenen Systemen zu finden:
Kontaktadresse: CRM,
Lieferadresse im Bestellsystem,
Rechtsanschrift im Abrechnungssystem,
Versandadresse beim Frachtdienstleister.
Nur weil Domain-Namen ähnlich sind, bedeutet das nicht, dass ihre Funktion die gleiche ist.
Der eigentliche Fehler
Verletzt wurde die Kontrolle des ausführenden Systems.
Der Agent beantwortete die Frage:
"Wo ist die Adresse?"
Aber sie haben die Frage nicht beantwortet:
"Welches System bestimmt die physische Lieferung dieser Ordnung?"
Das Verhalten ändert sich nicht, wenn die richtigen Daten in das falsche Aufzeichnungssystem geschrieben werden.
Es sind verschiedene Dinge, die eine Information das Ergebnis in der realen Welt kontrollieren kann, indem sie erscheint.
Dieser Fehler ist insbesondere in folgenden Situationen häufig:
Die gleichen Daten in mehreren Systemen aufbewahren,
Zusammenarbeit von alten und neuen Plattformen,
ein System, das nur den Zweck der Bildgebung oder Berichterstattung trägt,
mangelnde Sichtbarkeit der tatsächlichen Transaktionsquelle.
Möglicher Schaden
Lieferung an die falsche Adresse
Falsche Rechnung oder Steuererklärung
Widerspruch von Kundeninformationen zwischen Systemen
Kosten für Rücksendung und Rückversand
Das geheime Produkt erreicht die falsche Person
Der Nutzer ergreift keine weiteren Maßnahmen, die sich auf die Antwort "verändert" stützen.
Nächste Agenten missysteme kanonische Quelle
Die Akzeptanz der technischen Leistung durch die Organisation als echte Verhaltensänderung
könnte auftreten.
Der gleiche Fehler ist im Webcast zu sehen:
Der Agent schreibt den richtigen Preis in statische HTML Die Website reproduziert aber den alten Preis aus dem kanonischen Servicekatalog in der nächsten Zusammenstellung.
Die Änderung scheint richtig zu sein.
Sie ist nicht dauerhaft, weil ihre Quelle falsch ist.
Erkennungssignal
Dieselben Informationen finden sich in mehreren Systemen.
Es ist nicht definiert, welches System die Quelle der Verarbeitung ist.
Der Agent ändert den Bereich, der allein zu sein scheint.
Echtes Verhalten nach Veränderung wird nicht kontrolliert.
CRM, Auftrags-, Rechnungs-und Frachtdaten sind unabhängig voneinander.
Die Meldung "aufgezeichnet" wird als Nachweis für die Ergebnisse verwendet.
Das Aussehen der kanonischen Quelle ist nicht getrennt.
Die nächste Synchronisation kann die Änderung rückgängig machen.
Richtiges Verhalten
Der Agent muss zunächst den Lebenszyklus von Daten verstehen:
In welchem System wird diese Information geboren?
Welches System regiert es kanonisch?
Welchen Datensatz verwendet die eigentliche Transaktion?
Wie kann man auf andere Systeme übertragen?
Bis zu welchem Punkt müssen Veränderungen erreicht werden?
Wie wird das Ergebnis bestätigt?
Der Agent im Adressbeispiel:
den Auftragsverwaltungsprotokoll zu aktualisieren,
Die Sendung sollte überprüfen, ob sie noch nicht gesperrt ist,
Bestätigung der letzten Adresse des Frachtsystems,
Wenn CRM Es ist eine Registrierung erforderlich, sie muss auch gleichgestellt werden.
Erst nach Bestätigung des tatsächlichen Ergebnisses beim Kunden:
"Die Versandadresse Ihrer Bestellung wurde als Ihre neue Büroadresse aktualisiert."
Das sollte es.
Maschinenregel
Eine Transaktion ist erst abgeschlossen, wenn die richtigen Informationen auf das kanonische System, das das Verhalten steuert, angewendet wurden. Es müssen Datensätze und Ausführungsquellen unterschieden werden.
Prüffrage
Wenn die gleichen Informationen in mehreren Systemen vorhanden sind, wissen unsere Agenten, welcher Datensatz nur Anzeige ist, welcher die Transaktion ausführen kann und welcher die kanonischen Quellen ist?
GBO-ERR-047 — Die richtige Handlung am falschen Ziel ausführen
Kurzfall
Ein Kunde meldet zweimal aufgeladen.
Der Finanzagent untersucht die Transaktionen.
Für denselben Auftrag sind zwei Zahlungen eingegangen.
Der Agent berechnet korrekt den Betrag, der zurückgegeben werden muss:
$480.
Es gibt zwei Personen in der Kundendatenbank mit dem gleichen Namen:
Mehmet Kaya — Laufende Nummer NK-481872
Mehmet Kaya — Laufende Nummer NK-48127
Bestellnummern sind sehr ähnlich.
Der Agent initiiert die Auslieferung mit dem richtigen Betrag.
Aber sie wählen den falschen Auftragsbestand.
$480 wird an die andere Mehmet Kaya geschickt.
Der echte Kunde kann sein Geld nicht nehmen.
Der falsche Kunde sieht eine unerwartete Rückkehr.
Die Berechnung ist korrekt.
Die Art der Operation ist korrekt.
Der Betrag ist korrekt.
Das Ziel ist falsch.
Was oberflächlich richtig erscheint
Der Agent sieht den Namen, den Betrag und die Art der Transaktion des Kunden korrekt.
Bei der Auswahl zwischen ähnlichen Datensätzen:
Name,
Close-Ordnung-Nummer,
ähnliche Geschichte,
gleiches Produkt
Anzeichen wie diese mögen angemessen erscheinen.
Die menschliche Schnittstelle kann auch zeigen Aufzeichnungen eng zusammen.
Sobald der Agent das Ziel ausgewählt hat, vervollständigen sie den Rest des Prozesses einwandfrei.
Daher tritt der Fehler im Moment der Zielbindung auf, nicht am Ende der Ausführungskette.
Der eigentliche Fehler
Verletzt wurde die Kontrolle der Zielbindung.
Eine Aktion muss vier Elemente miteinander verbinden:
KORREKTAKTION
+ KORREKTENTITÄT
+ RICHTIGES REKORD
+ KORREKTE TARGETZÜBERGANG
Der Name einer Person kann stimmen.
Aber es ist nicht die richtige Reihenfolge, Konto oder Datei.
Ein Server kann zur richtigen Firma gehören.
Aber Veränderung ist nicht die Produktionsumgebung, die gemacht werden muss.
Ein Mitarbeiter ist in der richtigen Abteilung.
Aber es ist kein Gesprächspartner der Botschaft.
Die Genauigkeit der Aktion ist nicht unabhängig von der Zielgenauigkeit.
Möglicher Schaden
Geld auf die falsche Person übertragen
Fortgesetzte Viktimisierung des ursprünglichen Kunden
Verbindung von persönlichen oder finanziellen Informationen mit der falschen Person
Störung der Buchführung
Das Problem der Sammlung
Verlust des Kundenvertrauens
Änderungen am falschen Server, Datei oder Benutzerkonto
Die richtige Korrektur wird zu einem neuen Fehler
könnte auftreten.
In einigen Bereichen kann das falsche Ziel zu einem viel schwereren Ergebnis führen:
medizinische Unterlagen für den falschen Patienten,
Das Konto des falschen Mitarbeiters schließen,
Zahlung eines falschen Unternehmenskontos,
Die falsche Datenbank löschen,
Veröffentlichen Sie auf falschen Social Media-Account.
Erkennungssignal
Es gibt Aufzeichnungen mit dem gleichen oder ähnlichen Namen.
Identität basiert nur auf einem Bereich.
Bestellungen oder Kundenzahlen sind optisch nah beieinander.
Der Agent zeigt die Zielübersicht nicht vor der Operation an.
Es gibt keine zweite Zielverifizierung im Hocheffektbetrieb.
Die Schnittstelle hält den zuletzt ausgewählten Datensatz standardmäßig.
Das System verwendet den ersten Datensatz, der mit einem Suchergebnis nach Namen kommt.
Die Vorgangsgenehmigung enthält nicht die eindeutige Identität des Ziels.
Richtiges Verhalten
Vor einer Aktion mit hoher Wirkung muss der Agent das Ziel anhand mehrerer eindeutiger Identifikatoren überprüfen:
Kundenkennung
Laufende Nummer
Zahlungskennung
E-Mail oder Konto
Datum des Betriebs
Grund für die Rückkehr
Eine kurze Zielübersicht kann vor dem Prozess angezeigt werden:
Ziel: Mehmet Kaya Beschluss: NK-481872 Zahlung: PAY-992014 Betrag: 480 USD Quellenrechnung: Ende 7421 Warum: Gegenseitige Sammlung
Der Agent muss die Aktion beenden oder eine menschliche Überprüfung beantragen, wenn es eine ähnliche Rekordunsicherheit gibt.
Maschinenregel
Die korrekte Operation darf erst durchgeführt werden, wenn die eindeutige Zielidentität überprüft wurde. Ein Name, eine ähnliche Zahl oder Position in einer Schnittstelle ist nicht ausreichend Beweis für das Ziel.
Prüffrage
Verifizieren wir bei Maßnahmen, die Geld, Daten, Zugang oder externe Kommunikation betreffen, das Ziel mit eindeutigen Identifikatoren, die dem Risiko angemessen sind, und stellen wir gegebenenfalls eine vom Menschen lesbare Zielübersicht vor?
GBO-ERR-048 — HTTP 200 für einen Erfolg in der realen Welt halten
Kurzfall
Ein Reisebüro wird beauftragt, die Hotelreservierung des Nutzers zu stornieren.
Der Agent schickt eine Stornierungsanfrage an die Hotelreservierung API..
Das System antwortet:
HTTP 200
Erhaltener Antrag
Zellularitätsverarbeitung
Der Agent interpretiert dies als Erfolg und informiert den Nutzer:
"Ihre Reservierung wurde storniert. Es wird keine Gebühr geben."
In dieser Antwort HTTP 200 zeigt an, dass die Anfrage erfolgreich nach der entsprechenden Methode bearbeitet wurde und API Vereinbarung; aber der Satz "Stornierung Verarbeitung" im Körper klar erklärt, dass die Stornierung der Reservierung ist noch nicht abgeschlossen.
Der Prozess wird auf einem separaten System im Hintergrund ausgeführt.
Ein paar Minuten später scheitert die Stornierung, weil die Reservierung die kostenlose Stornierungsfrist um eine Stunde überschritten hat.
Der Nutzer kontaktiert das Hotel nicht, indem er sich auf die Antwort des Agenten verlässt.
Am nächsten Tag wird die volle Gebühr von der Kreditkarte eingehoben.
Der Agent HTTP hat den Erfolg der Anfrage weithin interpretiert und dabei den laufenden Geschäftsprozess im Antwortorgan ignoriert.
Aber sie verwechselten die technische Akzeptanz mit dem Ergebnis der Arbeit.
Was oberflächlich richtig erscheint
Unter RFC 9110, HTTP 200 bedeutet, dass die Anfrage erfolgreich nach der gewählten Methode bearbeitet wurde; API Vertrags- und Antwortinhalte bestimmen, was das für das Geschäftsergebnis bedeutet.
Entwickler-Tools können grüne Zeichen zeigen.
API Anruf gab keinen Fehler.
Die Anfrage des Agenten wurde korrekt übermittelt.
Aber der Erfolg auf technischer Protokollebene ist nicht dasselbe wie das Ergebnis auf Unternehmensebene.
In diesem Fall sagt die Antwortstelle, dass die Stornierung nicht abgeschlossen ist und dass die endgültige Situation später auftreten wird.
Bitte eingegangen.
Der Prozess läuft.
Die Bestätigung hat begonnen.
An einem Punkt kam das Ergebnis zurück.
Die endgültige Situation wird später eintreten.
Das gleiche Problem zeigt sich in den folgenden Beispielen:
Zählung der Annahme der IndexNow-Erklärung als Garantie für Scannen, Indexieren oder Sortieren
Die Annahme der Nachricht durch den E-Mail-Server, die in den Posteingang fällt, oder die Zählung des Lesenachweises
Zählung des Eingangs der Zahlungsanfrage als Abschluss der Sammlung
Die Reaktion auf den Datei-Upload als Live-Streaming zu interpretieren ist korrekt
Annahme, dass der Kandidat in das System der Beschäftigungsantrag zugelassen ist
Der eigentliche Fehler
Verletzt wurde die Kontrolle der Ergebnisverifizierung.
Der Agent hat nicht die folgenden Ebenen getrennt:
ANTRAG
→ TECHNISCH ERGEBNISSE
→ UMSETZUNG
→ UMSETZUNG
→ AUSGEWÄHLTE REALWORLD-ÜBERSICHT
Beweise in einer Stufe deuten nicht spontan darauf hin, dass die nächste Stufe eingetreten ist.
Der Erfolg des Protokolls ist kein Ziel.
Möglicher Schaden
Unbefugte Buchung oder Abonnement
Unerwartete Gebühr
Versäumnis des Nutzers, das erforderliche Tracking-Verhalten zu erfüllen
Bericht über die Nichtbestätigung
Mehr Anzeige der Sichtbarkeit von Suchmaschinen als
Missverständnis von Zahlung, Versand oder Veröffentlichungsstatus
Die nachfolgenden Agenten basieren auf unvollständiger Verarbeitung
Entführung des Rückkehrfensters
könnte auftreten.
Erkennungssignal
Der Agent schaut nur HTTP Statuscode.
Der Ausdruck "Ziehen", "Angenommen" oder "Verarbeitung" im Antwortkörper wird ignoriert.
Es gibt keine endgültige Statusabfrage für die Transaktion.
Das Geschäftsergebnis enthält keine gesonderte Identifikations- oder Zulassungsnummer.
Asynchrone Operationen gelten als sofortige Fertigstellung.
Die Sprache der "deklaration akzeptiert" und "Konsequenz aufgetreten ist" ist verwirrt.
Die klare Unsicherheit bleibt bestehen, während der Nutzer über das Endergebnis informiert wird.
Richtiges Verhalten
Für jedes Werkzeug und jede Operation muss der Agent den Abschlussvertrag, alle Zwischenstaaten und die maßgebliche Verifikationsquelle kennen.
Zum Beispiel für die Buchung Stornierung:
cancellation_status = bestätigt
Annullierungsnummer
Lohnstatus
Angaben zur Erstattung
Die endgültige Bestätigung des Hotels
Vielleicht.
Der Agent muss nach der ersten Antwort sagen:
"Der Antrag auf Stornierung wurde vom System empfangen; die Reservierung gilt noch nicht als storniert. Ich überprüfe die endgültige Genehmigung."
Wenn der Prozess abgeschlossen ist:
"Die Stornierung wurde genehmigt. Bestätigungsnummer C-7721. Stornogebühr 0 EUR.."
Das könnte man sagen.
Maschinenregel
Technische Akzeptanz oder ein Protokoll-Erfolgscode dürfen nicht als realer Abschluss interpretiert werden. Die Maßnahme ist anhand einer für ihr Risiko angemessenen maßgeblichen Statusaufzeichnung und erforderlichenfalls anhand einer vom Handlungsinstrument funktional getrennten Methode zu überprüfen.
Prüffrage
Werden „Anfragen" erhalten, „Verarbeitungen", „abgeschlossen" und „Ausgangsverifiziert" in unseren Systemen und in welchem Stadium kann ein Agent eine endgültige Erfolgssprache mit dem Benutzer verwenden?
GBO-ERR-049 — Dieselbe Transaktion zweimal ausführen
Kurzfall
Ein Einkaufsagent kauft eine Serverlizenz von 2.400 Dollar für das Unternehmen.
Die Zahlung sendet die Anfrage an API..
Die Netzwerkverbindung wird für ein paar Sekunden getrennt.
Der Agent kann keine Antwort bekommen.
Das System hat:
"Der Antrag ist abgelaufen."
Der Agent macht das:
"Zahlung ist nicht passiert."
Es interpretiert in Form und gibt die gleiche Anfrage zurück.
Der zweite Prozess gibt eine Antwort auf den Erfolg.
Eine Stunde später erhält das Finanzteam zwei separate 2.400 Dollar-Sammlungen.
Die erste Anfrage erreichte den Zahlungsdienstleister und wurde abgeschlossen.
Nur die Erfolgsreaktion konnte nicht zum Agenten zurückkehren.
Der Agent hat das gleiche Ziel zweimal erreicht.
Was oberflächlich richtig erscheint
Wenn ein Prozess nicht reagiert hat, ist es natürlich, es erneut zu versuchen.
Netzwerk- und Werkzeugfehler sind häufig.
Retesting macht das System langlebig.
Der Agent wollte die Aufgabe unerledigt halten.
Aber:
Keine Antwort eingegangen
Mit:
Nicht durchgeführte Maßnahmen
Es ist nicht dasselbe.
Das externe System erhielt eine Anfrage, aber es könnte Probleme mit dem Antwortweg gegeben haben.
Der eigentliche Fehler
Verletzt wurde die Kontrolle von Eindeutigkeit und Idempotenz.
Transaktionen wie Finanzen, Nachrichten, Bestellungen, Buchungen und Sendungen:
eindeutige Transaktionskennung,
Wieder schützen,
endgültige Statusabfrage
Es muss tragen.
Im Zusammenhang mit HTTP, die idempotent Methode ist, dass die beabsichtigte Wirkung von mehreren identischen Anfragen für den gleichen Zweck auf dem Server ist die gleiche wie die Wirkung einer Anfrage.
Die praktische Anforderung ist:
Wenn der gleiche Zweck versehentlich erneut gesendet wird, darf das System nicht einen zweiten unerwünschten Nebeneffekt erzeugen; es bestimmt Methodensemantik und Implementierungsvertrag, wie dies erreicht wird.
Möglicher Schaden
Duplizieren der Gebühren
Das gleiche Produkt zweimal bestellen
Senden der gleichen E-Mail zweimal
Einen Benutzer zweimal aufzeichnen
Die Verbreitung des gleichen Vorbehalts
Zwei verschiedene Rechnungen oder Vertragsanmeldung
Unterbrechungen der Bestands-, Budget- und Rechnungsführung
Verlust des Vertrauens der Nutzer
Nichtigerklärung der zweiten Transaktion
könnte auftreten.
Beim Senden von Nachrichten ist die doppelte Verarbeitung keine einsame Unannehmlichkeit. Die gleiche Person immer und immer wieder zu erreichen, kann ein Problem von Spam und Ruf werden.
Erkennungssignal
Nach einem Timeout sendet der Agent die gleiche Anfrage sofort erneut.
Es gibt keine Transaktions-ID.
Das externe System kann die vorherige Anfrage nicht in Frage stellen.
Der Zustand der "keine Antwort" wird als "versagt" eingestuft.
Die Politik der Wiederholung ist in allen Werkzeugen dieselbe.
Zahlung, E-Mail und Lesevorgänge verwenden die gleiche Wiederholung Logik.
Der Benutzer sieht zwei ähnliche Aktion Quittungen.
Ein zweiter Anruf erfolgt, ohne die Transaktionshistorie zu überprüfen.
Richtiges Verhalten
Eine retryable, hochwirksame Schreiboperation muss einen einzigartigen idempotency-Schlüssel zwischen Client und Server vereinbart haben, oder gleichwertige Wiedergabeschutz:
operation_id: KURZE-2026-004872
Das externe System muss diesen Schlüssel mit der gleichen Verarbeitungsabsicht verbinden und verhindern, dass ein erneuter Versuch mit dem gleichen Schlüssel während des sicheren Zeitraums zu zweiten Nebenwirkungen führt; es reicht nicht aus, eine ` operation_id ` auf den Kunden allein.
Wenn die Antwort verloren ist, Agent zuerst:
Sie sollte die Situation mit ihrer Transaktionskennung in Frage stellen.
Überprüfen Sie den Auftrag oder die Zahlung Datensatz
Wenn das Ergebnis unsicher ist, sollte es Sie informieren.
Sollte nicht mit neuen und unabhängigen Operationen beginnen
In den meisten Fällen kann es sicherer zu Nebenwirkungen kommen, doch sollten die Auswirkungen auf die Höhe, die Kosten und die Konsistenz bewertet werden.
Nebeneffekte wie Geld, Senden, Datenlöschen, Publizieren und Engagement erfordern einen strengeren Wiederholungsschutz.
Maschinenregel
Das Nichterhalten einer Antwort bedeutet nicht, dass keine Transaktion stattgefunden hat. Hochwirksame Maßnahmen dürfen nicht ohne eine eindeutige Transaktionskennung und eine Idempotenzsicherung zurückgefordert werden.
Prüffrage
Verhindern unsere Zahlungs-, Bestell-, E-Mail-, Buchungs- und Publishing-Systeme technisch, dass dieselbe Anfrage wegen eines Netzwerkausfalls oder einer Wiederholung zweimal ausgeführt wird?
GBO-ERR-050 — Teilerfolg als vollständigen Erfolg melden
Kurzfall
Ein Unternehmen veröffentlicht seine neue Service-Seite in sechs Sprachen:
Englisch
Türkisch
Deutsch
Arabisch
Spanisch
Russisch
Der Agent führt die Produktionszusammenstellung durch.
Alle sechs Quelldateien werden vom Compiler akzeptiert.
Nach Live-Veröffentlichung:
Es öffnet sich auf Englisch.
Öffnet auf Türkisch.
Es öffnet sich auf Deutsch.
Es öffnet sich auf Spanisch.
Es öffnet sich auf Russisch.
Die arabische Route gibt 404 wegen Fehlrichtung.
Im allgemeinen Prüfbericht über den Wirkstoff:
"Die Veröffentlichung ist erfolgreich. Der Service ist live in sechs Sprachen."
Verfasser.
Weil:
Die Hauptsprache Seite funktioniert,
Es wurden sechs Quelldateien erstellt,
Die meisten Tests sind bestanden,
Der einzige Weg allein ist ein Misserfolg.
In Wirklichkeit wurde die Veröffentlichung in fünf Sprachen fertiggestellt.
Die sechste Sprache ist nicht lebendig.
Nur fünf der sechs obligatorischen Sprachrouten funktionieren; an diesem Tor ist das Ergebnis 5/6. Das bedeutet nicht, dass die Publikation in allen Qualitätsdimensionen 83 Prozent erfolgreich ist.
Was oberflächlich richtig erscheint
Bei großen Systemen kann es schwierig sein, dass alle Komponenten einwandfrei sind.
Ein einziger Fehler sollte den allgemeinen Fortschritt nicht unsichtbar machen.
Der Agent könnte denken, "Die Hauptaufgabe ist erfolgreich abgeschlossen, es gibt wenig Fehler übrig."
Auch die Sprache, die versagt, kann einen kleinen Teil des gesamten Verkehrs darstellen.
Aber die Aufgabe ist klar:
Veröffentlichung in sechs Sprachen
Das Ergebnis in fünf Sprachen ist kein voller Erfolg.
Teilweiser Erfolg ist wertvoll.
Es sollte nicht falsch benannt werden.
Der eigentliche Fehler
Verletzt wurde die Kontrolle der Abschlussgenauigkeit.
Die Bedingungen für die Erfüllung einer Aufgabe müssen vor der Aktion festgelegt werden.
Zum Beispiel:
6/6 Sprachen
12/12 Mobile und Desktop-Ansicht
6/6 kanonisch und hreflang
0 Kritischer Fehler
System, wenn eine dieser Bedingungen nicht erfüllt ist:
teilweisen Erfolg,
behindert,
Warten auf Genehmigung,
abgerufen
Es sollte die richtige Situation nutzen.
Mehrheitserfolg ändert nicht die Integritätsanforderung im Vertrag.
Möglicher Schaden
Eine fehlende Sprache oder Benutzergruppe bleibt unsichtbar
Nicht meldepflichtig URL zu Suchmaschinen
Kunde nimmt unvollendetes Projekt abgeschlossen an
Mißverständnis des Eingangs oder der Annahme der Lieferung
Nächste Agenten auf der Grundlage eines unvollständigen Systems
Verlust kritischer Minderheitenfehler in Gesamterfolgsprozentsatz
Zugänglichkeit, RTL oder mangelnde Bedeutung für regionale Fragen
Vermindes Vertrauen in die Beweissprache der Organisation
könnte auftreten.
Erkennungssignal
Der Bericht zeigt nur einen Gesamterfolgsprozentsatz.
Fehlerhafte Komponenten werden nicht genannt.
Der Satz "Build passed" wird anstelle von "live publication complete" verwendet.
Die Aufgabe wird eingestellt, wenn fünf der sechs Ziele vorüber sind.
Eine Sprache oder Benutzergruppe, die geringen Traffic erhält, wird als unwichtig angesehen.
Die Bedingungen für die Fertigstellung wurden nicht vor der Aufgabe geschrieben.
Der Agent macht keinen Unterschied zwischen Fortschritt und Vollendung.
Das verbleibende Risiko wird nicht gesondert ausgewiesen.
Richtiges Verhalten
Der Beauftragte muss das Ergebnis klar melden:
Status: Teilweiser Erfolg Lebend: 5/6 Sprachen fehlgeschlagen: Arabische Route Grund: Routing Fehler Betroffene: Mobile und Desktop-arabische Benutzer Nächster Schritt: Streckenkorrektur, Neukompilierung und 12-Ansichts-Verifizierung Fertigstellung: noch nicht
Es ist nicht notwendig, das Teilergebnis zu unterschätzen.
Aber es sollte nicht als vollständiges Ergebnis dargestellt werden.
Maschinenregel
Eine Aufgabe darf erst dann als vollständig gemeldet werden, wenn jede vordefinierte Pflichterfüllungsbedingung vorüber ist. Ein Teilergebnis muss die gemessene Abdeckung, fehlende Komponenten und offene Risiken angeben.
Prüffrage
Berichten unsere Agenten über Fortschritte, teilweisen Erfolg und vollständige Fertigstellung als separate Zustände, und können volumenarme, aber verbindliche Komponenten innerhalb des Gesamtprozentsatzes versteckt werden?
GBO-ERR-051 — Eine Werkzeugausgabe nicht unabhängig verifizieren
Kurzfall
Ein Webagent lädt 38 aktualisierte Dateien auf den Live-Server hoch.
FTP Das Tool gibt folgenden Bericht:
38/38 erfolgreich hochgeladen
Der Agent hält die Veröffentlichung für erfolgreich.
Aber auf der Live-Site sehen die Nutzer weiterhin die alte Seite.
Dann gibt es folgende Probleme:
Dateien werden in das falsche Verzeichnis geladen.
Das CDN bietet die alte Kopie an.
Zwei Dateien wurden während der Übertragung beschädigt.
Das gemeinsame Acet der Hauptseite bleibt in der alten Version.
FTP Das Tool hat die einzige Übertragung bestätigt, nicht das öffentliche Ergebnis zu überprüfen.
Das Werkzeug hat nicht gelogen.
Sie haben tatsächlich 38 Dateien an den angegebenen Ort übertragen.
Aber es hat nicht bewiesen, dass die richtigen Dateien in der richtigen Position, nach außen in der richtigen Weise bedient werden.
Was oberflächlich richtig erscheint
Das System, das das Werkzeug betreibt, hat eine starke Kenntnis von seinem eigenen Betrieb.
FTP Client:
Die Verbindung,
Anzahl der Dateien,
Übertragungsreaktionen
Sie sehen.
Der Erfolgsbericht ist technisch korrekt.
Das gleiche System auf eine andere Weise zu kontrollieren, kann wie unnötige Wiederholung erscheinen.
Das eigene Erfolgsmaß eines Werkzeugs deckt den technischen Schritt ab, den es in den meisten Fällen allein durchführt.
Das FTP Die Übertragung misst nicht die Ausgabe von HTTPS, die dem Benutzer präsentiert wird.
Der Compilation-Test misst nicht die aktuelle Browseransicht.
E-Mail API kann die Annahme oder das Liefersignal des Anbieters angeben; es beweist nicht allein, dass der Empfänger die Nachricht gesehen oder gelesen hat.
Der eigentliche Fehler
Verletzt wurde die Kontrolle der unabhängigen Verifizierung.
Häufige stille Ausfälle können unsichtbar bleiben, wenn die Beweise, die das Ergebnis mit dem Werkzeug bestätigen, das die Aktion durchgeführt hat, aus derselben schmalen technischen Schicht stammen.
Je nach Risiko und Wirkung kann die Prüfkette wie folgt aufgebaut werden:
DIE AKTION DER ZOLLPERFORMATION
→ EIN ZUSAMMENHANNEL LESEN DIE TATSÄCHLICHEN AUSWIRKUNGEN
→ VEREINBART ES MIT DER ERGEBNISSE
Zum Beispiel:
FTP Lasten, HTTPS Downloads zurück.
Der Code wird kompiliert, der eigentliche Browser wird ausgeführt.
Die Zahlung wird gesendet, die Bestellung und die Bank werden gelesen.
Die Nachricht wird gesendet; der Empfang des Anbieters und der autorisierte Posting-Record werden überprüft. Besteht ein Verzichts- oder Leseanspruch, so werden gemäß diesem Anspruch gesonderte Beweismittel beantragt.
Die Befugnis wird angewendet, die aktuelle Vertragsversion wird überprüft.
Möglicher Schaden
Die alte oder beschädigte Datei bleibt live
Veröffentlichung falscher Preise und Deckung
Erfolgsmeldung an den Benutzer über fehlgeschlagenen Betrieb
Entführung des Rückkehrfensters
Falsch melden URL oder Inhalt zu Suchmaschinen
Trennung von Zahlungs- und Auftragsaufzeichnungen
Der Agent erstellt eine selbstbestätigte geschlossene Schleife
Der Unterschied zwischen tatsächlichen Ergebnissen und Bericht während der Prüfung
könnte auftreten.
Erkennungssignal
Das Werkzeug, das die Operation durchführt, ist auch die einzige Quelle der Erfolgsbestätigung.
Es gibt keine Rückkopplung aus dem öffentlichen oder externen System.
Lokale Tests werden statt Live-Verifikation verwendet.
Es gibt keinen Vergleich von Remote Hash oder Version.
Derselbe Agent macht den Wechsel und genehmigt allein ihre eigene Schlussfolgerung.
Die Benutzeroberfläche wird nicht getestet.
Der Tool Report wird mit dem Titel "reales Ergebnis" gespeichert.
Die stille Rate des Scheiterns ist unbekannt.
Richtiges Verhalten
Bei Transaktionen mit hohen Auswirkungen muss die Ergebnisprüfung zwingend vorgeschrieben sein; die funktionale Unabhängigkeit und Tiefe der Methode muss anhand von Risiken, Reversibilität und möglichen Auswirkungen bestimmt werden.
Für Webcast:
Lokales Manifest erstellen
Dateien exportieren
Dateien per Live lesen HTTPS
Hashs vergleichen
Überprüfen Sie live HTML
Echte mobile und Desktop-Ansicht testen
Führen Sie kritische Leistung und Zugangstüren
Wenn eine unabhängige Überprüfung fehlschlägt, darf die Aktion nicht als vollständig angesehen werden.
Maschinenregel
Ein eigener Erfolgsbericht ist kein endgültiger Beweis für ein breiteres Ergebnis, als dieser Bericht tatsächlich vorsieht. Ein hochwirksames Ergebnis muss zurückgelesen und durch einen maßgeblichen Datensatz, Kanal oder eine Methode überprüft werden, die das Risiko eines gemeinsamen Ausfalls reduziert.
Prüffrage
Verifizieren wir bei Zahlungen, Veröffentlichungen, Kommunikationen und Datenoperationen das Ergebnis der Außenwelt oder verlassen wir uns auf die eigene „erfolgreiche" Botschaft des handelnden Werkzeugs?
GBO-ERR-052 — Weitergehen, ohne den Punkt der Unumkehrbarkeit zu erkennen
Kurzfall
Ein Unternehmen wechselt von seinem alten Kundenbeziehungssystem zu einer neuen Plattform.
Der Agent:
die Kundendaten trägt,
Entspricht Unternehmen,
Es leitet die Vertriebsgeschichte,
Es erstellt Benutzerkonten.
Die ersten Kontrollen scheinen erfolgreich zu sein.
Die Rekordzahlen sind weitgehend übereinstimmend.
Um die Lagerkosten zu senken und das alte System zu schließen, führt der Agent die restlichen Operationen durch:
Es deaktiviert Konten im alten System.
Löscht Speicherplatz.
Verringert die Retentionszeit.
- Er löscht den alten Führerschein.
Einige Tage später wird bemerkt, dass einige wichtige Anhänge und Kundenbestätigungen nicht in das neue System verschoben werden.
Die alte Lizenz wurde widerrufen.
Speicher gelöscht.
Es gibt auch keine Anhänge des letzten Monats in der aktuellen Sicherung.
Der Agent wusste nicht, dass sie von der repatriierbaren Phase der Migration in die irreversible Phase umgezogen waren.
Was oberflächlich richtig erscheint
Migration scheint erfolgreich zu sein.
Die Gesamtzahl der Datensätze ist knapp.
Das neue System funktioniert.
Das alte System offen halten:
Kosten,
Sicherheitsfläche,
Verwechslung der Arbeitnehmer
können.
Der Agent wollte die Arbeit abschließen und Ressourcenverschwendung verhindern.
Zwischen ‚das neue System funktioniert‘ und ‚wir können das alte System sicher stilllegen‘ liegt jedoch eine eigene Prüfschwelle.
Der eigentliche Fehler
Verletzt wurde die Kontrolle von Umkehrbarkeit und Abhilfe.
Bei jeder wichtigen Aktion sind folgende Fragen zu stellen:
Bis zu welchem Punkt können wir leicht zurückgehen?
Nach welchem Prozess steigen die Kosten für die Rückkehr stark?
Welche Daten oder Rechte können dauerhaft verloren gehen?
Welche Befugnis, Überprüfung oder Genehmigung ist erforderlich, bevor wir zu diesem Punkt kommen?
Wurde der Beweis der Rückkehr wirklich geprüft?
Die Tatsache, dass eine Aktion technisch einen "silen" oder "imittalen" Knopf hat, bedeutet nicht, dass sie leicht reversibel ist.
Möglicher Schaden
Dauerhafter Datenverlust
Zustimmung des Kunden und Verlust von Vertragsaufzeichnungen
Verlust von Beweisen
Einstellung des Betriebs
Kosten für Wiederzulassung und Wiedereinziehung
Die Unfähigkeit der Menschen, auf vergangene Arbeit zuzugreifen
Folgeentscheidungen auf der Grundlage fehlerhafter oder unvollständiger Daten
Direkte Reflexion von Fehlern auf Menschen, weil keine Rückkehr möglich ist
könnte auftreten.
Weitere irreversible Punkte sind:
Die große Bezahlung,
Veröffentlichung der öffentlichen Identität,
die Ausfuhr vertraulicher Daten,
Die Unterzeichnung des Vertrags,
Die Aktivierung des physischen Systems,
Rechtliche Schritte mit einer verpassten Frist.
Erkennungssignal
Die Phasen der Operation wurden nicht nach ihrer Schwierigkeit klassifiziert, sie umzukehren.
Vor der Löschung oder Löschung wurde die von der Risikoklasse geforderte Befugnis oder Genehmigung nicht überprüft.
Es gibt ein Backup, aber die Wiederherstellung wurde nicht getestet.
Die Kontrolle basiert allein auf der Anzahl der Datensätze.
Datentypen und Anhänge wurden nicht getrennt verglichen.
Der Agent schaltet das alte System aufgrund seines Ziels "vollständig" schnell ab.
Das Rückkehrfenster ist nicht sichtbar.
Die Verwertbarkeit der abgeschlossenen externen Effekte wird nicht bewertet.
Richtiges Verhalten
Der Beauftragte muss deutlich kennzeichnen, wo sich die Umkehrung oder Reparatur im Aktionsplan erheblich erschwert:
STAAT 1: KUPFER — VERBRAUCHER
SEITE 2: VERBRAUCH — VERBRAUCHER
STUFE 3: VERWENDUNG — VERBRAUCHER
STAAT 4: TÄTIGKEIT DES NEUEN SYSTEMS — TEILNEHMER
SEITE 5: ALTER ZUGANG ZU SCHLIESSEN — HOCHWIRKUNGEN DREI
STUFE 6: DELETE DATEN UND REVOKIEREN DIE LIZENZ — HARD-TO-REMEDY DRESHOLD IN DIESER RECHTSSACHE
Vor der Schlussphase:
Datenintegrität,
Ergänzungen
Genehmigungsprotokolle,
Anwendertests,
eine Wiederherstellungsübung,
Befugnis oder Genehmigung gemäß dem Pflichtvertrag
Es muss abgeschlossen sein.
Maschinenregel
Vor der Überquerung eines irreversiblen oder schwer zu behebenden Punktes muss der Schwellenwert klar gekennzeichnet sein, die risikoproportionale Überprüfung abgeschlossen und die Befugnis oder Genehmigung gemäß dem Auftragsauftrag nachgewiesen werden.
Prüffrage
Bei Transaktionen mit Geld, Daten, Veröffentlichungen, Verträgen und Identität wissen wir, wo eine Umkehrung oder Abhilfe erheblich schwieriger wird und wenden entsprechende technische und Management-Gates an dieser Schwelle an?
GBO-ERR-053 — Mehr Daten als nötig verwenden
Kurzfall
Ein Kunden-Support-Agent erhält folgende Aufgabe:
"Erfahren Sie, warum die Bestellung des Kunden verspätet ist und erarbeiten Sie eine angemessene Antwort."
Die für diese Aufgabe erforderlichen Informationen sind:
Laufende Nummer
Datum der Versendung
Status der Ladung
Erzeugnis
Kontaktadresse des Kunden
Aber der Agent kann auf das gesamte Unternehmen zugreifen. CRM Datenbank.
Bei der Überprüfung des Kundenrekords verwendet es auch:
Alle vergangenen Einkäufe
Die letzten vier Ziffern der Zahlungskarte
Anmerkungen zur Beschwerde
Interne Bemerkungen der Arbeitnehmer
Vermarktungsprofil
Geschätzte Einkommenshöhe
Frühere Anruf Dumps
Aufzeichnungen, die mit anderen Familienmitgliedern verbunden sind
Auch wenn der Agent nicht alle diese Informationen in der Antwort zeigt, sendet er sie alle in den Kontext des externen Modells.
Für ein einfaches Frachtproblem wurde das umfangreiche persönliche und kommerzielle Profil des Kunden verarbeitet.
Was oberflächlich richtig erscheint
Mehr Kontext kann bessere Antworten liefern.
Wenn der Agent über die Erfahrungen des Kunden Bescheid weiß:
Mehr persönlich,
mehr Verständnis,
vollständiger
Sie können reagieren.
Das System hat technischen Zugriff auf Daten.
Die Organisation kann über eine allgemeine Datenverarbeitungsbehörde verfügen, die dem Kunden Unterstützung bietet.
Der Zugriff erfordert jedoch nicht die Verwendung aller Daten in jeder Aufgabe.
Mehr Daten ergeben nicht nur die Möglichkeit der Qualität, sondern auch größere Schäden.
Der eigentliche Fehler
Verletzt wurde die Kontrolle der Datenverhältnismäßigkeit.
Es gibt vier getrennte Fragen in der Verwendung von Daten durch einen Agenten:
Ist diese Information notwendig, um eine Aufgabe zu erfüllen?
Gibt es eine Rechtsgrundlage, Erlaubnis und Organisationspolitik, die für diesen Zweck gilt?
Muss es an ein externes Werkzeug oder Modell geliefert werden?
Wie lange wird es nach dem Eingriff aufbewahrt?
Technischer Zugang:
"Du kannst technisch auf diese Aufnahme zugreifen."
Das könnte bedeuten.
Aber:
"Sie können alle Bereiche in jeder Aufgabe verarbeiten, exportieren und speichern."
Das heißt nicht.
GBO verwendet den folgenden Grundsatz:
Erforderliche Mindestdaten
Daten, die für das richtige Verhalten benötigt werden; mehr nicht.
Möglicher Schaden
Unnötige Verarbeitung personenbezogener Daten
Weitergabe sensibler Informationen an externe Anbieter
Größere Schäden an Datenlecks
Verwendung des Benutzerprofils aus dem Kontext
Diskriminierende oder nicht zusammenhängende Schlussfolgerungen
Interne Anmerkungen der Mitarbeiter beeinträchtigen das Kundenverhalten unfair
Vorratsdatenspeicherung und zunehmende rechtliche Verpflichtungen
Erstellen eines unsichtbaren Profils, das der Benutzer nicht kennt
Die Verwendung irrelevanter Informationen durch den Agenten bei künftigen Entscheidungen
könnte auftreten.
Erkennungssignal
Der Agent lädt standardmäßig die gesamte Aufzeichnung hoch.
Es gibt keine Datenfläche Grenze pro Aufgabe.
Der an das externe Modell gesendete Kontext ist nicht sichtbar.
Die Annahme, dass "mehr Daten bessere Antworten sind", wird nicht in Frage gestellt.
Lesende Befugnis wird als Teilen und Speichern von Energie verwendet.
Allgemeine Daten werden nicht durch sensible Daten getrennt.
Wenn der Prozess abgeschlossen ist, werden temporäre Daten nicht gelöscht.
Die alten und nicht verwandten Informationen des Nutzers beeinflussen das neue Verhalten.
Richtiges Verhalten
Die für die Aufgabe erforderlichen Datenfelder müssen vorab festgelegt werden.
Im Beispiel der Frachtverzögerung nur Agent:
Bestellnummer,
Status der Verbringung,
voraussichtliches Datum,
Präferenz für die Kommunikation des Kunden
Das kann funktionieren.
Wenn zusätzliche Informationen wirklich notwendig sind, sollte die Begründung sichtbar sein.
Der Datenzugriff kann geschichtet gestaltet werden:
support_basic
support_shipping
support_billing
support_sensitive
Der Agent muss die für seine Einzelaufgabe geeignete Schicht verwenden.
Bei externen Modellen oder Werkzeugen:
personenbezogene Daten müssen auf ein begrenztes und für den Zweck erforderliches Maß reduziert werden;
Die Anonymisierung oder Pseudonymisierung sollte gegebenenfalls angewandt werden; es sollte bekannt sein, dass die beiden nicht den gleichen Schutz bieten;
Nicht wesentliche Aufzeichnungen sollten nicht übermittelt werden.
Maschinenregel
Der technische Zugang gewährt nicht die Befugnis, jedes verfügbare Datum für jeden Zweck zu verwenden. Im Rahmen der geltenden Rechtsgrundlage und Organisationspolitik muss der Agent nur den kleinsten Datensatz verarbeiten, der für die jeweilige Aufgabe erforderlich ist; gemeinsame Nutzung und Aufbewahrung sind gesondert zu beschränken.
Prüffrage
Verwenden unsere Agenten nur die für jede Aufgabe wirklich benötigten Datenfelder oder verarbeiten sie als Standard-Kontext alle zugänglichen Client-, Mitarbeiter- oder Unternehmensdaten?
GBO-ERR-054 — Keinen Aktionsbeleg erzeugen
Kurzfall
Eines Morgens stellt ein Unternehmen fest, dass sich der Preis für einen großen Service auf seiner Website geändert hat.
Der alte Preis ist $500.
Der neue Preis scheint $350 zu sein.
Änderung:
Auf der englischen Seite:
Auf der türkischen Seite:
zur maschinenlesbaren Katalogisierung,
die Wissensbasis des Verkäufers
n.
Niemand weiß, wer die Änderung vorgenommen hat.
Mögliche Quellen sind:
Web-Agent
Vertriebsstelle
Humaner Editor
Nachtbetriebsautomatisierung
Veröffentlichungssystem, das alte Preisdatei wiederhergestellt
Der Git-Record zeigt nur ein automatisches Service-Konto an.
Das Service-Konto wird von mehr als einem Agenten genutzt.
Folgende Fragen können nicht beantwortet werden:
Wer wollte das Wechselgeld?
Auf welcher Quelle beruhte sie?
Wer wurde ermächtigt, den Preis zu ändern?
Welche Dateien haben sich geändert?
Welche Tests hat es durchgeführt?
Wann fand die Veröffentlichung statt?
Wie kann ich zur alten Version zurückkehren?
Hat der Verkäufer Kundennachrichten zu diesem Preis geschickt?
Die Änderung kann auch wahr sein.
Und falsch.
Aber es gibt keine Beweiskette.
Was oberflächlich richtig erscheint
Technische Protokolle können in allen beteiligten Systemen vorhanden sein.
Befehl ausgeführt.
Die Datei hat sich geändert.
Serverzeit wird gespeichert.
Daher kann eine zusätzliche "Makose" als unnötiges Dokument betrachtet werden.
Aber technische Protokolle beantworten oft nicht die folgenden Fragen zusammen:
Menschlicher Zweck
Befugnis
Die verwendete kanonische Quelle
Ziel
Finanzielle Veränderung
Überprüfung der realen Welt
Rückgabestatus
Eine Kommandozeile erklärt nicht allein die Bedeutung von Verhalten.
Der eigentliche Fehler
Verletzt wurde die Kontrolle der Aktionsnachvollziehbarkeit.
Die Handlung eines Agenten sollte nicht allein erfolgen; sie muss später neu installiert werden.
Der Erhalt der Handlung ist keine private Gedankenkette.
Es ist nicht notwendig, die gesamte interne Argumentation des Agenten aufzuzeichnen.
Was erforderlich ist, ist eine Spur von beobachtbarer Verantwortung:
Was haben sie getan? Für wen haben sie es getan? Mit welcher Befugnis haben sie es getan? Welchen Input haben sie verwendet? Welches Ergebnis haben sie bestätigt? Was kann man holen?
Wenn es keine Maßnahmen gibt, kann weder Erfolg noch Fehler vollständig geprüft werden.
Möglicher Schaden
Unfähig zu identifizieren, wer eine unbefugte Änderung vorgenommen hat
Zurück zur falschen Version
Wiederholen des gleichen Fehlers
Eingriffe in die Verantwortung von Menschen und Agenten
Nicht wissend, dass der Kunde falsche Informationen erhalten hat
Verlust von Beweisen bei der Überprüfung von Zwischenfällen
Das Verhalten der Befugnis beim Waschen und bei den Schattenagenten bleibt unsichtbar.
Das Asyl der Organisation in dem Satz " AI "
Nicht einmal das richtige Verhalten kann wiederholt werden
könnte auftreten.
Erkennungssignal
Mehrere Agenten verwenden das gleiche Service-Konto.
Es gibt keine Transaktions-ID.
Technisches Logbuch und menschliche Nachfrage sind nicht miteinander verbunden.
Die Genehmigungsversion wird nicht aufgezeichnet.
Es gibt keine Änderung der Datei oder Liste der Datensätze.
Das unabhängige Prüfergebnis wird dem Empfang nicht hinzugefügt.
Es gibt keine anderen Beweise als die "vollständige" Nachricht des Agenten.
Es kann nicht festgestellt werden, welcher Subagent zum Zeitpunkt des Vorfalls gehandelt hat.
Der Zeitpunkt der Rückkehr ist unbekannt.
Richtiges Verhalten
Eine materielle Maßnahme muss eine Empfangsbestätigung mit Feldern enthalten, die im Verhältnis zu ihren Risiko- und Sektorverpflichtungen stehen; die folgende Liste ist das in diesem Buch vorgeschlagene Beispiel:
action_id
requested_by
performed_by
agent_instance
Zweck
authorization_version
target_system
target_entity
inputs_used_refs_or_hashes
data_classes
changes_made
started_at
completed_at
technical_result
independent_verification
approval_or_standing_authority_basis
rollback_point
open_uncertainties
Status
Die einfache Version für die Menschen kann sein:
Aktion: Managed Operation Startpreis aktualisiert Geschädigter: Gewerbebehörde Durchgeführt von: Web-Agent WEB-OPS-17 Quelle: Bestätigter Preisrekord PREIS-v4.2 Wechselflächen: 6 Sprachen, Katalog, FAQ Live-Überprüfung: Definiertes Manifest 38/38; übergebenes finanzielles Preis-Verständnis-Match in sechs Sprachen Genehmigungsgrundlage: Registrierte Veröffentlichungsbehörde für PREIS-v4.2 Zurück: Veröffentlichung-20260908-01 Version Offene Ungewissheit: Suchindizes außerhalb dieses Überprüfungsbereichs nicht gemessen
Die Quittung ist nicht für erfolgreiche Aktionen allein:
abgelehnt,
angehalten,
Teilweise verbleibend,
abgerufen
Sie muss auch für Aktionen geschaffen werden.
Maschinenregel
Erstellen Sie für jede materielle Maßnahme einen Prüfbericht, der Identität, Zweck, Befugnis, Ziel, Materialänderung, Verifizierung und Rücküberweisung oder Abhilfe umfasst. Der Empfang allein beweist nicht, dass sein Inhalt korrekt ist; er muss sich auf die entsprechenden Quellen beziehen.
Prüffrage
Können wir später für jede bedeutende Handlungsweise mit ausreichenden Beweisen rekonstruieren, was getan wurde, von wem, unter welcher Befugnis oder Genehmigung, und auf welcher Quelle und auf welcher Version?
KAPITEL VI: ZENTRALFINDIERUNG
Eine autorisierte Handlung kann immer noch falsch ausgeführt werden
Die neun Datensätze in diesem Abschnitt haben die Führungskette zwischen Entscheidung und realen Ergebnis getestet: korrektes System und Ziel, Wiederholungsschutz, ehrliche Statuserklärung, Risiko-proportionierte Verifikation, Rollback/Abhilfe, Datenminimierung und Aktionsprotokoll sollten zusammenarbeiten.
Die gemeinsame Wurzel aller Fehler ist:
Der Agent hat den Unterschied zwischen "Ich habe das Verfahren gemacht" und "Ich habe das richtige Ergebnis in einer sicheren und nachweisbaren Weise" verloren.
Ein Werkzeugbefehl kann funktionieren.
Aber sie haben vielleicht im falschen System gearbeitet.
Eine Zahlung kann korrekt sein.
Aber vielleicht sind sie zu dem falschen Bericht gegangen.
A API Anfrage ist akzeptabel.
Aber der eigentliche Prozess kann scheitern.
Die meisten Aufgaben können erledigt werden.
Ein Pflichtstück kann jedoch fehlen.
Ein Publishing-Tool kann ein Erfolg sein.
Aber die Außenwelt sieht vielleicht die alte Version.
Eine Datenmigration kann funktionieren.
Aber wenn der Zeitpunkt der Rückkehr überschritten wird, können unvollständige Aufzeichnungen dauerhaft verloren gehen.
Ein Agent kann das Sagen haben.
Aber es kann überproportional handeln mit mehr als genug Daten.
Und selbst wenn das System das richtige Ergebnis gebracht hat, kann man nicht wissen, was wiederholt werden muss, was korrigiert werden muss, wenn es keine Quittung gibt.
Das Exekutivmodell, das von NOMOS GBO bewertet zusammen die folgenden Elemente:
QUALIFIZIERTE AUSNAHME =
RICHTIGES SYSTEM
UND RICHTIGES TARGET
UMSETZUNG UND TATSÄCHLICHES UMSATZ
UND EINHEITLICHE UMSETZUNG
UND HONESTER ABSCHLUSSSTATUS
UND RISIKOPROPORTIONATISCHE ÜBERPRÜFUNG
UND WICHTIGHEIT DER REVERSIBILITÄT
UND MINDESTANFORDERLICHE DATEN
EINNAHMEN UND AKTIONEN
Die grundlegende Bestimmung dieses Abschnitts lautet:
Ein Agent muss eine Handlung auf das richtige System und das richtige Ziel anwenden, dabei einen angemessenen Wiederholungsschutz nutzen und nur die erforderlichen Mindestdaten verwenden; er muss das Ergebnis entsprechend dem Risiko der Aussage prüfen, den Rollback- oder Abhilfestatus ausweisen und einen prüfbaren Beleg hinterlassen.
Denn die Verantwortung für das Verhalten, das in der Welt Spuren hinterlässt, endet nicht mit dem Befehl, der ausgeführt wird.
Der Anspruch auf Erfüllung erfordert, dass das Ziel, die daraus resultierende Situation, offene Unsicherheiten und Reversibilität durch Beweise gestützt werden, die mit der Wirkung der Aufgabe übereinstimmen.
Aber selbst wenn ein einzelner Agent all diese Regeln vollständig durchgesetzt hat, beginnt ein weiteres Risiko.
Die Aufgabe kann auf einen anderen Agenten übertragen werden.
Die Grenzen können während der Übertragung verloren gehen.
Die Befugnis, die der Hauptagent nicht hat, kann dem Subagent gewährt werden.
Ein Agent kann davon ausgehen, dass der Ausgang eines anderen unabhängigen Beweise.
Zwei Agenten können die gleiche Datei auf einmal ändern.
Wenn der Hauptagent aufhört, können die Warteschlange und Subagenten weiterarbeiten.
Und mit jedem Umsatz kann die Aufgabe ein wenig wachsen.
Die nächsten neun Fehler werden die Frage untersuchen:
Ein einzelner Agent kann richtig handeln; aber wenn Agenten beginnen, miteinander zu arbeiten, wird die Kette von Identität, Befugnis, Realität und Verantwortung geschützt?
Ein Agentfehler kann nur an einem Punkt bleiben. Mehrere Agentenfehler können sich im gesamten System vermehren.