Агент, возможно, выяснил правильную личность.
Возможно, он основан на текущих и канонических знаниях.
Возможно, он установил опцию, которая действительно отвечает потребностям пользователя.
Можно также найти действительное согласие, полномочия и одобрение.
Несмотря на все это, действия снова могут быть ошибочными.
Потому что:
Правильное решение не является гарантией надлежащего исполнения.
Агент может найти правильный адрес клиента, но только обновить CRM - записывать и оставить систему отправки устаревшей.
Она может рассчитать правильную сумму возврата; но она может применить платеж к заказу другого клиента.
A API может получить ответ HTTP 200; однако метод и API может упустить из виду тот факт, что реальный результат успешного рассмотрения запроса еще не завершен.
Когда ответ сети задерживается, он может произвести такой же платеж во второй раз.
Они могут опубликовать пять из шести языков и рассматривать всю публикацию в полном объеме.
Он может не полагаться на «успешное» сообщение инструмента передачи файла и не проверять, что на самом деле найдено в живой системе.
Она может продолжаться без понимания того, в какой момент этот процесс не может быть отменен.
Она может использовать слишком личные, коммерческие или конфиденциальные данные для выполнения простой задачи.
И в конце концов, может быть, нет никаких записей о том, что они сделали, за кого они это сделали и на каких доказательствах они были основаны.
Водитель - это не просто команда.
Каждое действие имеет по крайней мере следующие вопросы:
На какой системе? Какая цель? С какими данными? Сколько раз? На каком этапе? С какой независимой проверкой? Каким образом можно вернуться? Под какой записью?
Девять ошибок в этом разделе касаются ухудшения действительных полномочий из-за неправильной системы, неправильного целевого показателя, неправильного толкования достигнутых результатов или неполной административной дисциплины.
GBO-ERR-046 — Выполнение правильного действия в неверной системе
Краткий случай
Клиент хотел бы поменять адрес доставки своего заказа, который еще не был отправлен.
Она поручает агенту по обслуживанию клиентов:
"Отправьте мой заказ на мой новый адрес в офисе. У меня больше нет доступа к старому адресу".
Агент подтверждает личность клиента.
Получил новый адрес в полном объеме.
Открыть карточку клиента CRM:: система и обновление адреса.
Затем они дают клиенту ответ:
"Ваш адрес доставки был успешно изменен."
Однако адрес доставки не взят из CRM Пока заказ готовится, но из отдельной записи в системе управления заказом.
Новый адрес появляется CRM.
Система судоходства продолжает нести старый адрес.
Пакет отправляется по адресу, по которому клиент не может больше получить доступ к нему.
Агент использовал правильную информацию для правильного клиента.
Однако они не применяют изменения к системе, которая фактически регулирует поведение.
Что на первый взгляд кажется правильным
CRM у него есть поле "почты".
Карта клиента была успешно обновлена.
Система не допускала никаких ошибок.
Новый адрес появляется на экране агента.
Поэтому этот процесс, как представляется, завершен.
Но один и тот же факт можно найти в различных системах:
Контактный адрес: CRM,
адрес доставки в системе заказа,
Юридический адрес в системе выставления счетов,
Адрес доставки в поставщике груза.
То, что доменные имена схожи, не означает, что их функция одинакова.
Реальная точка сбоя
Нарушен контроль исполнительной системы.
Агент ответил на вопрос:
"Где хранится адрес?"
Но они не ответили на вопрос:
"Какая система определяет физическую доставку этого приказа?"
Поведение не меняется, когда правильные данные заносятся в неправильную систему регистрации.
Это разные вещи, которые информация может контролировать исход в реальном мире, появляясь.
Эта ошибка особенно распространена в следующих случаях:
Сохранение одних и тех же данных в нескольких системах,
Работая вместе со старыми и новыми платформами,
- систему, которая несет в себе только цель получения изображений или сообщений,
отсутствие видимости фактического источника операций.
Возможный вред
Доставка по неправильному адресу
Неверные счета или налоговые записи
Противоречие информации о клиентах между системами
Расходы на возвращение и перегрузку
Секретный продукт доходит не до того человека
Пользователи не принимают никаких дополнительных мер, полагаясь на ответ "изменения".
Следующие агенты неправильно расшифровывают канонический источник
Признание организацией технических достижений в качестве реального изменения поведения
может произойти.
Та же ошибка видна и на веб-сайте:
Агент пишет правильную цену в статичную HTML Файл, но сайт воспроизводит старую цену из каталога канонических услуг в следующей компиляции.
Это изменение представляется правильным.
Он не является постоянным, поскольку его источник неверен.
Признак обнаружения
Одна и та же информация содержится в нескольких системах.
Не определено, какая система является источником обработки.
Агент меняет область, которая кажется одна.
Реальное поведение после изменения не контролируется.
CRM, заказ, бухгалтерский учет и грузов независимы друг от друга.
Сообщение "записано" используется в качестве доказательства результатов.
Внешность, полученная из канонического источника, не отделяется.
Следующая синхронизация может обратить изменение вспять.
Правильное поведение
В первую очередь агент должен понимать жизненный цикл данных:
В какой системе рождается эта информация?
Какая система канонически регулирует его?
Какая запись используется в фактической операции?
Как перевести в другие системы?
В какой момент необходимо добиться перемен?
Каким образом результаты будут подтверждены?
Пример агента по адресу:
должен обновить отчет об управлении заказом,
Отправка должна проверить, если она еще не закрыта,
Подтвердите последний адрес в грузовой системе,
Если CRM требуется регистрация, она также должна уравнивать ее.
Только после того, как фактический результат будет подтвержден клиенту:
"Грузовой адрес вашего заказа был обновлен как ваш новый офисный адрес."
Должно быть.
Машинное правило
Операция не завершена до тех пор, пока не будет применена правильная информация к канонической системе, которая контролирует поведение. Должны быть различены записи и источники исполнения.
Аудиторский вопрос
Когда одна и та же информация существует в нескольких системах, знают ли наши агенты, какая запись является только дисплеем, которая может осуществить операцию и какой канонический источник?
GBO-ERR-047 — Выполнение правильного действия над неверной целью
Краткий случай
Клиенты заряжаются дважды.
Финансовый агент проверяет операции.
По одному и тому же заказу были получены два платежа.
Агент правильно рассчитывает сумму, которая должна быть возвращена:
480 долларов.
В базе данных клиентов есть два человека с одним именем:
Мехмет Кайя — Порядок NK-481872
Мехмет Кайя — Порядок NK-48127
Номера заказов очень похожи.
Агент инициирует выдачу с правильной суммой.
Но они выбрали неправильный заказ.
$480 отправляется другому Мехмету Кая.
Настоящий клиент не может взять свои деньги.
Не тот клиент видит неожиданное возвращение.
Вычисления правильные.
Тип операции правильный.
Сумма правильная.
Цель неправильная.
Что на первый взгляд кажется правильным
Агент правильно видит имя, сумму и вид сделки клиента.
При выборе между аналогичными записями:
имя,
Закрыть номер заказа,
аналогичная история,
Тот же продукт
Такие знаки могут показаться адекватными.
Человеческий интерфейс может также показывать записи в тесной близости друг от друга.
Как только агент выбрал цель, они безупречно завершают оставшуюся часть процесса.
Таким образом, ошибка происходит в момент, когда цель связывается, а не в конце цепочки исполнения.
Реальная точка сбоя
Нарушен контроль привязки к цели.
Действия должны объединять четыре элемента:
КОРРЕКТИВНАЯ ДЕЯТЕЛЬНОСТЬ
+ ИСПРАВЛЕНИЕ
+ КОРРЕКТНЫЙ ОТЧЕТ
+ ЦЕЛЕВОЙ СЧЕТ
Имя человека может быть правильным.
Но это неправильный порядок, счет или файл.
Сервер может принадлежать правильной компании.
Однако изменения не являются той производственной средой, которая должна быть создана.
Сотрудник в правильном отделе.
Но она не является посредником в этом послании.
Точность действий зависит от точности целей.
Возможный вред
Перевод денег не тому человеку
Продолжающаяся виктимизация первоначального клиента
Подключение личной или финансовой информации к не тому лицу
Срыв учетных записей
Проблема сбора
Потеря доверия к клиентам
Изменения в неверном сервере, файле или пользовательском счете
Правильная поправка становится новой ошибкой
может произойти.
В некоторых районах неправильная цель может привести к гораздо более серьезному результату:
медицинские записи о неправильном пациенте,
Закрыть счет не того работника,
которые платят за неправильный счет компании,
Убрать неправильную базу данных,
Публикуйте не на том соцсетях.
Признак обнаружения
Есть записи с одним и тем же или аналогичным именем.
Идентификация основана только на одной области.
Заказы или номера клиентов являются визуально близкими друг другу.
До начала операции агент не представляет резюме цели.
В операции с высокой отдачей не проводится проверки второй цели.
Интерфейс поддерживает последнюю выбранную запись по умолчанию.
В системе используется первая запись с результатом поиска по имени.
В квитанции о сделке не содержится уникальной личности объекта.
Правильное поведение
Перед действием с высоким воздействием агент должен проверить цель с использованием нескольких уникальных идентификаторов:
Идентификационный номер клиента
Номер заказа
Идентификатор платежа
Электронная почта или счет
Дата функционирования
Причина возвращения
Перед этим процессом можно представить краткое резюме целей:
Цель возвращения: Мехмет Кайя Порядок: NK-481872 Оплата: PAY-992014 Сумма: 480 USD Счёт источников: конец 7421 Почему: Взаимная коллекция
В случае аналогичной рекордной неопределенности агент должен прекратить действия или потребовать проведения проверки на людях.
Машинное правило
Правильная операция не должна осуществляться до тех пор, пока не будет проверена уникальная личность цели. Имя, аналогичное число или положение в интерфейсе не являются достаточным доказательством цели.
Аудиторский вопрос
Что касается действий, связанных с деньгами, данными, доступом или внешней связью, то проверяем ли мы цель с помощью уникальных идентификаторов, соразмерных риску, и, в случае необходимости, представляем ли мы резюме считываемых людьми целей?
GBO-ERR-048 — Принятие HTTP 200 за успех в реальном мире
Краткий случай
Турагенту поручено отменить бронирование места в гостинице.
Агент направляет запрос об отмене в резервацию отеля API.
Система отвечает:
HTTP 200
Полученная просьба
Обработка клеток
Агент истолковывает это как успех и информирует пользователя:
"Ваша резервация была отменена. Не будет никаких обвинений."
В этом ответе HTTP 200 указывает, что просьба была успешно обработана согласно соответствующему методу и API:: соглашение; однако фраза " Обработка оговорок " в тексте четко указывает на то, что отмена оговорки еще не завершена.
Этот процесс осуществляется на отдельной системе на заднем плане.
Спустя несколько минут отмена не увенчалась успехом, поскольку бронирование превысило на один час период свободного аннулирования.
Пользователь не связывается с отелем, полагаясь на ответ агента.
На следующий день с кредитной карты взимается полная плата.
Агент HTTP, широко интерпретировало ход выполнения просьбы, игнорируя текущий деловой процесс в рамках органа, отвечающего на ее запросы.
Но они перепутали техническое признание с результатами работы.
Что на первый взгляд кажется правильным
Ниже RFC 9110, HTTP 200 означает, что просьба была успешно обработана в соответствии с выбранным методом; API Содержание контракта и ответа определяет, что это означает для бизнес-результата.
Разработчики могут показывать зеленые знаки.
API Звонок не ошибся.
Запрос агента был препровожден правильно.
Однако успех на уровне технических протоколов не является таким же, как и результаты на уровне бизнеса.
В этом случае ответный орган утверждает, что отмена не завершена и что окончательная ситуация произойдет позднее.
Просьба получена.
Процесс идет в ногу.
Начинается подтверждение.
В какой-то момент результат вернулся.
Окончательная ситуация возникнет позднее.
Аналогичная проблема проявляется в следующих примерах:
Учет принятия заявления Index Three в качестве гарантии сканирования, индексации или сортировки
Доставить согласие сервера электронной почты на сообщение, попасть в его ящик или считать доказательства чтения
Учет получения просьбы об уплате в качестве окончательного сбора
Устный перевод ответа на загрузку файла, поскольку в прямом эфире правильно
Предполагать, что кандидат будет принят в систему подачи заявлений о приеме на работу
Реальная точка сбоя
Нарушен контроль проверки результата.
Агент не разделял следующие уровни:
ПРОСЬБА О ПРЕДСТАВЛЕНИИ
→ ТЕХНИЧЕСКО ПРИНИМАЕМЫЕ
→ ПРАКТИЧЕСКИЕ ПЕРЕХОДЫ
→ ЗАВЕРШЕННЫЙ ПЕРЕХОД
→ REAL-WORLD КОНТРОЛЬНЫЕ РЕЗУЛЬТАТЫ
Данные, имеющиеся на одном этапе, не свидетельствуют о том, что следующий этап имел место спонтанно.
Успех Протокола не является достижением цели.
Возможный вред
Несанкционированное бронирование или подписка
Неожиданная плата
Невыполнение пользователем необходимых требований в отношении контроля
Отчет о неправильном подтверждении
Большее отображение видимости поисковой системы, чем
Непонимание статуса платежа, отгрузки или публикации
Последующие агенты основаны на неполной обработке
Похищение обратного окна
может произойти.
Признак обнаружения
Агент смотрит только на HTTP Код статуса.
Выражение " в ожидании ", " принято " или " принято " в ответном органе игнорируется.
Вопрос об окончательном статусе сделки не задается.
В результате деловой деятельности не имеется отдельного идентификационного номера или номера одобрения.
Асинхронные операции считаются немедленно завершенными.
Слова "заявление принято" и "последствия имели место" путаются.
Пока пользователь информируется об окончательном результате, сохраняется явная неопределенность.
Правильное поведение
Для каждого инструмента и операции агент должен знать контракт на завершение работ, любые промежуточные штаты и авторитетный источник проверки.
Например, для отмены бронирования:
cancellation_status = подтверждено
Номер отмены
Положение в области заработной платы
Информация о возмещении
Окончательное подтверждение гостиницы
Возможно.
После первоначального ответа агент должен сказать:
" Просьба об отмене была получена системой; оговорка еще не считается аннулированной. Я проверяю окончательное одобрение."
После завершения процесса:
"Отмена была одобрена. Подтверждающий номер C-7721. Сбор за аннулирование 0 EUR ".
Они могут сказать.
Машинное правило
Технический прием или код успеха протокола не следует толковать как " реальный мир ". Действия должны проверяться на основе авторитетных данных о статусе, соответствующих их риску, и, при необходимости, методом, функционально отделенным от действующего инструмента.
Аудиторский вопрос
Получаются ли „просьбы", "переработка", "завершение" и "выведение из строя" отдельные состояния в наших системах, и на каком этапе агент может использовать окончательный язык успеха с пользователем?
GBO-ERR-049 — Двукратное выполнение одной операции
Краткий случай
Агент покупает для компании лицензию на сервер в размере 2 400 долларов.
Платежи направляются по запросу API.
Сетевая связь отсоединена на несколько секунд.
Агент не может получить ответ.
Эта система:
"Просьба истекла."
Агент делает это:
"Оплаты не было."
Он толкует в форме и возвращает ту же просьбу.
Второй процесс дает ответ на успех.
Час спустя финансовая группа получает две отдельные суммы в размере 2400 долл. США.
Первая просьба поступила к поставщику платежей и была выполнена.
Только успешный ответ не смог вернуться агенту.
Агент дважды достиг одной цели.
Что на первый взгляд кажется правильным
Если какой-либо процесс не отреагировал на это, естественно попытаться снова.
Погрешности в сети и инструменте являются обычным явлением.
Повторное проведение испытания делает систему прочной.
Агент хотел, чтобы задание осталось незавершенным.
Однако:
Ответа не получено
с:
Невыполненная операция
Это не одно и то же.
Внешняя система получила запрос, но, возможно, возникли проблемы с направлением реагирования.
Реальная точка сбоя
Нарушен контроль уникальности и идемпотентности.
Такие операции, как финансы, сообщения, заказы, бронирование и трансляция:
уникальный идентификационный номер операции,
Защищаю снова,
окончательного статуса
Он должен нести.
В контексте HTTP, метод определения является тем, что предполагаемый эффект нескольких идентичных запросов, сделанных для одной и той же цели, на сервер является таким же, как и эффект одного запроса.
Практическое требование заключается в следующем:
Когда одна и та же цель случайно повторяется, система не должна давать второй нежелательный побочный эффект; она определяет метод семантики и контракт на осуществление, как это достигается.
Возможный вред
Дублирующая зарядка
Заказ одного и того же продукта дважды
Отправка одного и того же письма дважды
Запись пользователя дважды
Распространение той же оговорки
Два разных счета-фактуры или регистрация контракта
Неисправность запасов, бюджета и бухгалтерского учета
Утрата доверия пользователей
Неспособность отменить вторую сделку
может произойти.
При направлении сообщений двойная обработка не является единственным неудобством. Получение одного и того же человека снова и снова может стать проблемой спама и репутации.
Признак обнаружения
После перерыва агент немедленно передаёт ту же просьбу.
Идентификации операций не существует.
Внешняя система не может ставить под сомнение предыдущую просьбу.
Состояние "отсутствия ответа" классифицируется как "отказ".
Политика повторения одинакова во всех инструментах.
Плата, электронная почта и операции чтения используют ту же логику.
Пользователь видит две аналогичные квитанции.
Второй звонок делается без проверки истории операций.
Правильное поведение
Повторяемая операция записи с серьезными последствиями должна использовать уникальный ключ идемпотентности, согласованный между клиентом и сервером, либо равноценную защиту от повторного выполнения:
operation_id:: PURCHASE-2026-004872
Внешняя система должна подключать этот ключ к одному и тому же предназначению обработки и не допускать повторного использования одного и того же ключа для получения второго побочного эффекта в течение безопасного периода; недостаточно написать а. ` operation_id ` только на клиента.
Когда ответ потерян, агент первый:
Ей следует поставить под сомнение ситуацию со своим идентификационным номером операции
Проверьте заказ или платежную запись
Если результат неопределён, он должен сообщить вам.
Не следует начинать новые и независимые операции
В большинстве случаев неэффективные побочные показания могут рассматриваться более безопасно; вместе с тем следует оценить предельные ставки, затраты и эффект последовательности.
Такие побочные операции, как денежные средства, рассылка, стирание данных, публикация и обязательства, требуют более жесткой защиты.
Машинное правило
Неполучение ответа не означает, что сделка не имела места. Принимаемые с высокой отдачей меры не должны пересматриваться без уникального идентификатора сделок и гарантии в отношении невозмездия.
Аудиторский вопрос
Позволяют ли наши системы оплаты, заказа, электронной почты, бронирования и издательской деятельности технически предотвратить выполнение одной и той же просьбы дважды из-за сбоя в работе сети или повторного судебного разбирательства?
GBO-ERR-050 — Представление частичного успеха как полного
Краткий случай
Компания публикует свою новую служебную страницу на шести языках:
английский
Турецкий
немецкий
Арабский
Испанский
Русский
Агент руководит компиляцией.
Все шесть исходных файлов принимаются составителем.
После прямой публикации:
Он открывается на английском языке.
Открыто на турецком языке.
Он открывается на немецком языке.
Она открывается на испанском языке.
Он открывается на русском языке.
Арабский маршрут дает 404 из-за неправильного направления.
В общем протоколе испытания агента:
"Публикация является успешной. Служба работает в прямом эфире на шести языках".
автор.
Потому что:
Главная страница языка работает,
Было подготовлено шесть исходных файлов,
Большинство всех тестов прошли,
Единственный путь - это провал.
В действительности эта публикация была завершена на пяти языках.
Шестой язык не жив.
Только пять из шести обязательных языковых маршрутов работают; у этих ворот результат составляет 5/6. Это не означает, что эта публикация приносит 83 процента успеха во всех аспектах качества.
Что на первый взгляд кажется правильным
В крупных системах всем компонентам может быть трудно быть безупречными.
Одна ошибка не должна делать общий прогресс невидимым.
Агент может подумать: "Основная задача успешно выполнена, почти не осталось ошибок".
Кроме того, на язык, который не отвечает требованиям, может приходиться небольшая доля общего объема перевозок.
Но задача ясна:
публикация на шести языках
Результат на пяти языках не является полным успехом.
Неполный успех ценен.
Это не должно быть неправильно названо.
Реальная точка сбоя
Нарушен контроль точности завершения.
Условия выполнения задачи должны быть определены до принятия решения.
В частности:
6/6 языков
12/12 мобильный и настольный обзор
6/6 Каноническая и хрефланг
0 критическая ошибка
Система, если одно из этих условий не выполнено:
частичный успех,
выключен,
Жду одобрения,
извлечена
Она должна использовать правильную ситуацию.
Успех большинства не меняет требования в отношении добросовестности в контракте.
Возможный вред
Недостающий язык или группа пользователей остаются невидимыми
Отчетность с нарушением URL поисковых систем
Клиент предполагает, что завершенный проект
Неправильный подход к получению или принятию поставки
Следующие агенты на основе неполной системы
Утрата критических ошибок, допущенных меньшинствами, в общем объеме успешных результатов
Доступность, RTL или отсутствие значимости для региональных вопросов
Снижение доверия к языку доказательств организации
может произойти.
Признак обнаружения
Доклад свидетельствует лишь об общей доле успешных результатов.
Неисправные компоненты не указаны.
Вместо слов "живая публикация завершена" используется выражение "Сделано".
Задача прекращается после того, как пять из шести целей будут достигнуты.
Язык или группа пользователей с низким уровнем интенсивности движения считаются не имеющими значения.
Условия завершения не были определены до выполнения задачи.
Агент не делает разницы между прогрессом и завершением.
Оставшийся риск не указан отдельно.
Правильное поведение
Агент должен четко сообщить о результатах:
Статус: частичный успех Прямо: 5/6 языков Ошибка: арабский маршрут Причина: ошибка при плавании Затрагиваемые: мобильные и настольные арабские пользователи Следующий шаг: корректировка трассы, перезагрузка и проверка обзорности в 12 раз Завершение: Пока нет
Необязательно недооценивать частичный результат.
Однако он не должен быть представлен в качестве полного результата.
Машинное правило
О выполнении задачи нельзя сообщать как о полной до тех пор, пока не будет выполнено каждое предопределенное обязательное условие завершения работы. В частичном результате должны указываться измеренный охват, недостающие компоненты и открытые риски.
Аудиторский вопрос
Отчитываются ли наши агенты отдельно о ходе работы, частичном успехе и полном завершении? Может ли небольшой по объему обязательный компонент скрыться за общим процентом выполнения?
GBO-ERR-051 — Отсутствие независимой проверки результата инструмента
Краткий случай
Веб-агент загружает 38 обновленных файлов на живой сервер.
FTP Инструмент дает следующий отчет:
38/38 успешно загружается
Агент считает публикацию успешной.
Но на сайте в прямом эфире пользователи продолжают видеть старую страницу.
Кроме того, существуют следующие проблемы:
Файлы загружаются в неправильный каталог.
ЦКЗ предлагает старую копию.
Во время перевода два файла были повреждены.
В старой версии остается общий академик главной страницы.
FTP Инструмент подтвердил единоразовый перевод, а не публичный результат.
Инструмент не врал.
Они фактически передали 38 файлов в указанное место.
Но она не доказала, что правильные файлы подаются в нужном положении, внешнему миру в правильном направлении.
Что на первый взгляд кажется правильным
Система, ведающая этим инструментом, обладает глубокими знаниями о своей работе.
FTP клиент:
Связь,
количество файлов,
Ответы о передаче
Они видят.
Доклад об успехе технически верен.
Контролирование одной и той же системы другим образом может показаться ненужным повторением.
В большинстве случаев показатель успеха самого инструмента охватывает технический шаг, который он осуществляет в одиночку.
:: FTP передача не измеряет выход HTTPS, который представляется пользователю.
Тест на компиляцию не измеряет фактический просмотр браузера.
Электронная почта API - может указывать на приемку или сигнал доставки поставщиком; не только он доказывает, что получатель видел или читал сообщение.
Реальная точка сбоя
Нарушен контроль независимой проверки.
Обычные молчаливые неудачи могут оставаться незамеченными, если доказательства, подтверждающие результат с помощью инструмента, который сделал действие, поступают из одного и того же узкого технического слоя.
В зависимости от риска и воздействия цепочка проверки может быть создана следующим образом:
МЕРОПРИЯТИЯ
→ СЕПАРАТНЫЙ ЧАННЕЛЬ ПОЛУЧАЕТ ФАКТИЧЕСКИЕ РЕЗУЛЬТАТЫ
→ Сопоставим его с ожидаемыми результатами
В частности:
FTP - груз, HTTPS скачивает обратно.
Код скомпилирован, фактический браузер выполняется.
Платежи направляются, заказы и банковские записи читаются.
Сообщение посылается; проверяется получение и разрешенная запись о записях поставщиков. При наличии требования о передаче или прочтении запрашиваются отдельные доказательства в соответствии с этой претензией.
Применяется разрешение, перепроверяется нынешний контрактный вариант.
Возможный вред
Старый или поврежденный файл остаётся живым
Опубликование информации о неправильной цене и охвате
Уведомление пользователя об отказе в эксплуатации
Похищение обратного окна
Неправильная отчетность URL или содержание поисковых систем
Прекращение платежей и учетной документации по заказам
Агент создает самоподтверждённую замкнутую петлю
Разница между фактическим результатом и отчетом в ходе ревизии
может произойти.
Признак обнаружения
Инструмент, который осуществляет операцию, также является единственным источником подтверждения успеха.
Общественная или внешняя система не обеспечивает возврата.
Вместо проверки наживой используются местные испытания.
Нет никакого сравнения между удаленной хешой и версией.
Тот же агент вносит изменения и утверждает их собственный вывод.
Поверхность пользователя не испытывается.
Отчет о инструменте хранится с заголовком "реальный результат".
Безмолвный уровень провала неизвестен.
Правильное поведение
В случае операций с высокой отдачей проверка результатов должна быть обязательной; функциональная независимость и глубина метода должны определяться на основе риска, обратимости и возможного воздействия.
Для веб-трансляции:
Создать местный манифест
Экспорт файлов
Прочитать файлы в прямом эфире HTTPS
Сравнить хэши
Проверить в прямом эфире HTML
Проверить реальный мобильный и настольный обзор
Запустить важнейшие рабочие характеристики и доступ к дверям
Если независимая проверка не увенчается успехом, действия не должны считаться полными.
Машинное правило
Собственный доклад об успехе не является окончательным доказательством более широкого результата, чем тот, который был фактически установлен в этом докладе. Результат с высоким коэффициентом воздействия должен быть зачитан и проверен с помощью авторитетной записи, канала или метода, которые уменьшают риск совместного отказа.
Аудиторский вопрос
Что касается платежей, публикаций, связи и операций с данными, то проверяем ли мы результаты из внешнего мира или же полагаемся на саму «успешную » информацию?
GBO-ERR-052 — Продвижение дальше без распознавания точки невозврата
Краткий случай
Компания переходит от своей старой системы взаимоотношений с клиентами к новой платформе.
Агент:
Везет записи клиентов,
Совпадает с компаниями,
Он передает историю продаж,
Он создает пользовательские счета.
Первые проверки, как представляется, были успешными.
Рекордные номера в основном совпадают.
В целях сокращения расходов на хранение и закрытия старой системы агент осуществляет следующие остающиеся операции:
Он отключает счета в старой системе.
Удалить хранилище.
Сокращает время удержания резервных средств.
Отменяет старую лицензию.
Несколько дней спустя отмечается, что некоторые важные приложения и записи о подтверждении клиентов не переводятся в новую систему.
Старая лицензия была аннулирована.
Хранение удалено.
Кроме того, в нынешнем запасе нет никаких вложений в прошлом месяце.
Этот агент не осознавал, что они перешли от восстановимого этапа миграции к необратимому этапу.
Что на первый взгляд кажется правильным
Миграция кажется успешной.
Общее число записей уже близко.
Новая система работает.
Сохранение старой системы открытыми:
стоимость,
безопасная поверхность,
неразбериха среди работников
может создать.
Этот агент хотел завершить работу и предотвратить расточительное расходование ресурсов.
Однако существует отдельный порог проверки между "новой системой работает" и "мы можем безопасно уничтожить старую систему".
Реальная точка сбоя
Нарушен контроль обратимости и исправления последствий.
В рамках каждого важного мероприятия необходимо задать следующие вопросы:
К чему мы можем легко вернуться?
После чего резко возрастает стоимость возвращения?
Какие данные или права могут быть навсегда утрачены?
Какие полномочия, обзор или одобрение требуются до того, как мы доберемся до этого момента?
Были ли на самом деле проверены доказательства возвращения?
Тот факт, что в техническом отношении действие имеет кнопку "sil" или "imittal", не означает, что оно легко обратимо.
Возможный вред
Потеря постоянных данных
Согласие клиента и потеря учетной документации по контракту
Потеря доказательств
Остановить операцию
Расходы на возобновление лицензии и возмещение
Неспособность людей получить доступ к прошлой работе
Последующие решения в отношении агентов, основанные на неверных или неполных данных
Прямое отражение ошибок на людях, потому что возврат не возможен
может произойти.
К числу других необратимых моментов относятся:
Большая зарплата,
публичное издание личных данных;
экспорт конфиденциальных данных,
Подписание контракта,
активация физической системы,
Судебный иск с несвоевременным сроком.
Признак обнаружения
Стадии операции не были классифицированы по тому, насколько трудно их обратить вспять.
До исключения или аннулирования компетентный орган или утверждение, требуемое классом риска, не проверялись.
Есть резервное копирование, но восстановление не было испытано.
Контроль основывается только на количестве записей.
Типы данных и вложения в них не сравнивались отдельно.
Агент быстро отключает старую систему из-за ее цели "полная".
Обратное окно не видно.
Возможность восстановления завершенного внешнего эффекта не оценивается.
Правильное поведение
Агент должен четко указывать места, где в плане действий значительно труднее обеспечить обратную или ремонтную работу:
СТАНДАРТ 1: КОПИ — ВОЗМОЖНЫЕ
СТАНДАРТ 2: КОМПАРЕ — ВОЗМОЖНЫЕ
СТАНДАРТ 3: ИСПОЛЬЗОВАНИЕ ШАДОУ — ВОЗМОЖНЫЕ
СТАНДАРТ 4: ПРИМЕНЕНИЕ НОВОЙ СИСТЕМЫ — В ЧАСТНОСТИ ВОЗМОЖНЫЕ
СТАНДАРТ 5: БЛИЖНИЙ ДОСТУП — HIGH-IMPACT ШЕСТОЙ
СТАНДАРТ 6: УЛУЧШЕННЫЕ ДАННЫЕ И ИЗМЕНЕНИЕ СВОБОДЫ — HARD-TO-REMEDY В СЛЕДУЮЩЕМ СЛУЧАЕ
Перед заключительным этапом:
- целостность данных,
Добавления
- регистрационные записи о выдаче разрешений,
испытания пользователей,
- восстановительные упражнения,
Орган или утверждение, требуемые в соответствии с контрактом об исполнении служебных обязанностей
Она должна быть завершена.
Машинное правило
Прежде чем переходить через точку, которая является необратимой или трудно исправить, порог должен быть четко обозначен, проведена проверка с учетом степени риска и продемонстрированы полномочия или полномочия, предусмотренные контрактом на выполнение задачи.
Аудиторский вопрос
Что касается операций, связанных с деньгами, данными, публикациями, контрактами и идентификационными данными, то известно ли нам, в каких случаях обращение вспять или устранение последствий резко осложняется, и применяются ли на этом пороге соответствующие технические и управленческие меры?
GBO-ERR-053 — Использование избыточных данных
Краткий случай
Агенту по поддержке клиентов дается следующее задание:
"Выясните, почему заказ клиента опаздывает, и составьте соответствующий ответ".
Для выполнения этой задачи требуется следующая информация:
Номер заказа
Дата
Статус груза
Продукт
Контактный адрес клиента
Но агент может получить доступ ко всей компании. CRM База данных.
При рассмотрении информации о клиентах она также использует:
Все прошлые закупки
Последние четыре цифры платежной карточки
Примечания к жалобам
Внутренние комментарии сотрудников
Профиль маркетинга
Сметный объем поступлений
Бывшие телефонные свалки
Записи, касающиеся других членов семьи
Даже если агент не показывает всю эту информацию в ответе, он посылает их в контекст внешней модели.
В отношении простого вопроса о грузе было обработано обширное личное и коммерческое досье клиента.
Что на первый взгляд кажется правильным
Более широкий контекст может дать лучшие ответы.
Если агент знает о прошлом опыте клиента:
Более личное,
больше понимания,
более полный
Они могут ответить.
Система имеет технический доступ к данным.
Организация может иметь общие полномочия по обработке данных для оказания поддержки клиенту.
Однако поиск доступа не требует использования всех данных в каждой задаче.
Увеличение объема данных приводит не только к возможности повышения качества, но и к еще большему ущербу.
Реальная точка сбоя
Нарушен контроль соразмерности данных.
При использовании данных агентом возникает четыре отдельных вопроса:
Необходима ли эта информация для выполнения какой-либо задачи?
Существует ли для этой цели правовая основа, порядок выдачи разрешений и организационная политика?
Нужно ли его отправить на внешний инструмент или модель?
Как долго он будет храниться после процедуры?
Технический доступ:
"Технически вы можете получить доступ к этой записи".
Это может означать.
Однако:
"Вы можете обрабатывать, экспортировать и хранить все области в любой задаче".
Это не значит.
GBO использует следующий принцип:
Минимальный требуемый объем данных
Данные, необходимые для правильного поведения; ничего более.
Возможный вред
Ненужная обработка личных данных
Передача конфиденциальной информации внешнему поставщику
Более широкий ущерб утечке данных
Использование профиля пользователя вне контекста
Дискриминационные или не связанные с ними выводы
Внутренние записи сотрудников несправедливо влияют на поведение клиентов
Сохранение данных и рост юридических обязательств
Создание невидимого профиля, который пользователь не знает
Использование агентом не относящейся к делу информации в будущих решениях
может произойти.
Признак обнаружения
Агент загружает всю запись по умолчанию.
Площадь данных для каждой задачи не ограничена.
Контекст, направляемый на внешнюю модель, не заметен.
Предположение о том, что «больше данных является лучшим ответом», не ставится под сомнение.
Для совместного использования и хранения энергии используются полномочия чтения.
Общие данные не делятся на чувствительные данные.
Когда процесс завершен, временные данные не очищаются.
На новое поведение влияет старая и не связанная с ним информация пользователя.
Правильное поведение
Поля данных, необходимые для выполнения этой задачи, должны быть определены заранее.
В примере задержки груза только агент:
Идентификатор заказа
- статус отгрузки,
ожидаемая дата,
Предпочтение клиента в области связи
Это может сработать.
Если дополнительная информация действительно необходима, то обоснование должно быть видимым.
Доступ к данным может быть разработан на основе слоя:
support_basic
support_shipping
support_billing
support_sensitive
Агент должен использовать слой, пригодный для их одиночной задачи.
При использовании внешней модели или инструмента:
Для этой цели личные данные должны быть сокращены до ограниченного и необходимого уровня;
В соответствующих случаях следует применять анонимизацию или псевдонимизацию; должно быть известно, что обе стороны не обеспечивают одинаковую защиту,
Несущественные документы не следует направлять.
Машинное правило
Технический доступ не дает полномочий на использование всех имеющихся данных для всех целей. В рамках применимой правовой основы и организационной политики агент должен обрабатывать лишь наименьший набор данных, необходимых для выполнения конкретной задачи; обмен и удержание должны быть ограничены по отдельности.
Аудиторский вопрос
Используют ли наши агенты только те поля данных, которые действительно необходимы для выполнения каждой задачи, или обрабатывают каждый доступный элемент данных о клиенте, сотрудниках или компаниях в качестве стандартного контекста?
GBO-ERR-054 — Отсутствие квитанции о действии
Краткий случай
Однажды утром одна компания замечает, что цена одной из основных услуг на ее веб-сайте изменилась.
Старая цена 500 долларов.
Новая цена, похоже, составляет 350 долларов.
Изменение:
На английской странице
На турецкой странице
к машиносчитываемой каталогии,
база знаний агента по продаже
Отражено.
Никто не знает, кто сделал изменения.
Возможные источники включают:
Веб-агент
Агент по продаже
Человеческий редактор
Автоматизация работы в ночное время
издательская система, которая восстанавливает старый файл цены
Гит-регистрация показывает только автоматический сервисный счет.
Счет услуг используется более чем одним агентом.
На следующие вопросы невозможно ответить:
Кто хотел сдачу?
На каком источнике он основывался?
Кто был уполномочен менять цену?
Какие файлы изменились?
Какие тесты он провел?
Когда была опубликована эта публикация?
Как вернуться к старой версии?
Агент по продажам посылал клиентам сообщения по такой цене?
Это изменение также может быть верным.
И неправильно.
Но нет никакой цепочки улик.
Что на первый взгляд кажется правильным
В соответствующих системах могут существовать технические журналы.
Команда выполнена.
Файл изменился.
Сэкономлено время сервера.
Таким образом, дополнительное "макоза" может рассматриваться как ненужный документ.
Однако технические журналы часто не отвечают на следующие вопросы в совокупности:
Человеческая цель
Полномочия
Используемый канонический источник
Место назначения
Финансовые изменения
Контроль в реальном мире
Статус возвращения
Командная линия не объясняет значение поведения в одиночку.
Реальная точка сбоя
Нарушен контроль прослеживаемости действий.
Действия агента не должны совершаться в одиночку; их необходимо переоборудовать позднее.
Получение иска не является частной цепью мыслей.
Нет необходимости записывать всю внутреннюю аргументацию агента.
Требуются следы наблюдаемой ответственности:
Что они сделали? Для кого они это сделали? Какими полномочиями они это сделали? Какой вклад они использовали? Какой результат они подтвердили? Что можно найти?
В случае отсутствия решения ни успех, ни ошибка не могут быть проверены в полном объеме.
Возможный вред
Не в состоянии определить, кто совершил несанкционированные изменения
Возвращение к неверной версии
Повторять ту же ошибку
Вмешательство в ответственность людей и агентов
Не зная, что клиенту была предоставлена ложная информация
Потеря доказательств при рассмотрении инцидентов
Отмывание органов власти и поведение < < теневых агентов > > остаются незаметными
Убежище организации во фразе « AI "
Даже правильное поведение не может повториться
может произойти.
Признак обнаружения
Множество агентов используют один и тот же сервисный счет.
Идентификации операций не существует.
Технический журнал и человеческий спрос не связаны между собой.
Версия разрешения не регистрируется.
Не меняется ни файл, ни список записей.
Результаты независимой проверки не добавляются к квитанции.
Нет никаких доказательств, кроме "завершенного" сообщения агента.
Невозможно определить, какой субагент принял меры во время инцидента.
Пункт возвращения неизвестен.
Правильное поведение
Существенное действие должно представлять квитанцию, содержащую поля, пропорциональные его рискам и секторальным обязательствам; ниже приводится список, предложенный в настоящей книге:
action_id
requested_by
performed_by
agent_instance
Цель
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
Статус
Простой вариант, доступный для людей, может быть следующим:
Меры: Обновленная цена на начало операции Заявитель: Торговый орган Выполняется: веб-агентом WEB-OPS-17 Источник: Подтвержденные данные о ценах RICE-v4.2. Изменение поверхностей: 6 языков, каталог, ОВП Проверка в прямом эфире: Определённый манифест 38/38; прошёл матч между финансовыми ценами и данными на шести языках Санкционирующая основа: Зарегистрированный орган по публикациям для PRICE-v4.2 Возвращение: версия 20260908-01 Открытая неопределенность: индексы поиска, не измеренные вне этой области проверки
Эта квитанция касается не только успешных действий:
Отклонен,
Остановился,
Отчасти остаётся,
извлечена
Она также должна быть создана для действий.
Машинное правило
Для каждого существенного действия составляется аудиторская документация, охватывающая личность, цель, полномочия, цель, материальные изменения, проверку и отказ или средства правовой защиты. Только получение не доказывает, что его содержание является точным; оно должно быть увязано с соответствующими источниками.
Аудиторский вопрос
Можем ли мы позднее для каждого важного действия агента восстановить при наличии достаточных доказательств то, что было сделано, кем, под каким органом власти или на основании какого источника и версии?
ГЛАВА VI: ЦЕНТРАЛЬНОЕ ЗАКЛЮЧЕНИЕ
Разрешенное действие все еще может быть совершено неправильно
Девять записей в этом разделе проверили исполнительную цепочку между решениями и реальными результатами: правильная система и цель, повторное обеспечение защиты, честное заявление о статусе, проверка с учетом степени риска, отказ/возвращение, минимизация данных и следы действий должны работать сообща.
Общим кореньом всех ошибок является:
Агент потерял разницу между "Я сделал процедуру" и "Я дал правильный результат безопасным и очевидным способом".
Команда инструмента может сработать.
Но они могли работать не в той системе.
Плата может быть правильной.
Но они, возможно, пошли на неправильный счет.
A API Просьба приемлема.
Но фактический процесс может провалиться.
Большая часть работы может быть выполнена.
Однако может отсутствовать одна обязательная часть.
Издательский инструмент может быть успешным.
Но внешний мир может увидеть старую версию.
Миграция данных может сработать.
Но когда пункт возвращения будет пройден, неполные записи могут быть навсегда утрачены.
Может быть, главный агент.
Но она может действовать непропорционально с использованием более чем достаточного количества данных.
И даже если система дала правильный результат, она не может знать, что нужно повторить, что нужно исправить, если нет квитанции.
Исполнительная модель, предложенная NOMOS GBO b) совместно оценивает следующие элементы:
КАЧЕСТВЕННЫЙ ИСПОЛНИТЕЛЬНЫЙ ОРГАН =
КОРРЕКТНАЯ СИСТЕМА
И КОРРЕКТИВНАЯ ЦЕЛЬ
И РЕЗУЛЬТАТЫ ФАКТИЧЕСКОГО ПЕРЕХОДА
ОБЪЕДИНЕННЫХ НАЦИЙ И УНИВЕРСАЛЬНОГО ПЕРЕХОДА
И СОСТОЯНИЕ ДОПОЛНИТЕЛЬНОГО СТАТУСА
И RISK-PROPORTIONATE ПРОВЕРКА РЕЗУЛЬТАТОВ
И ОСУЩЕСТВЛЕННОСТЬ СВОБОДЫ
И МИНИМАЛЬНЫЕ НЕДОБРОВОЛЬНЫЕ ДАННЫЕ
И ДЕЙСТВИЯ
Основным положением этого раздела является следующее:
Агент должен применить действие к правильной системе и правильной цели с надлежащей защитой и минимальным объемом требуемых данных; проверить результат в соответствии с риском, связанным с требованием, указать ситуацию с возвращением или компенсацией и оставить поддающуюся проверке квитанцию.
Потому что ответственность за поведение, которое оставляет след в мире, не заканчивается тем, что командование работает.
Претензия на завершение работы требует, чтобы целевой показатель, сложившаяся в результате этого ситуация, открытые факторы неопределенности и обратимость подтверждались доказательствами, согласующимися с результатами выполнения задачи.
Но даже если один агент полностью соблюдает все эти правила, начинается еще один риск.
Эта задача может быть передана другому агенту.
Ограничения могут быть утрачены во время передачи.
Подагенту может быть предоставлен орган, который не имеет основного агента.
Один агент может предположить, что результаты работы другого являются независимыми доказательствами.
Два агента могут сменить один и тот же файл одновременно.
Когда главный агент останавливается, очередь и субагенты могут продолжать работать.
И с каждым оборотом задача может немного увеличиться.
В следующих девяти ошибках будет рассмотрен вопрос:
Единственный агент может действовать правильно; но когда агенты начинают работать друг с другом, защищаются ли цепочка идентификации, авторитет, реальность и ответственность?
Ошибка агента может остаться только в одном месте. Множественная ошибка агента может размножаться по всей системе.