ИИ-агенты в компании: процессы, полномочия, контроль

Глава 01 / 12

Агент начинается с поручения, а не с имени

Руководителю показывают помощника, который уверенно отвечает на вопросы о закупках. Через неделю возникает желание подключить его к учётной системе, почте и справочнику поставщиков. Каждое расширение выглядит небольшим. Но между ответом на вопрос и созданием обязательства перед поставщиком находится целая система решений: чьи данные используются, какая версия верна, кто вправе выбрать вариант и кто остановит ошибочное действие.

В этой книге агентом называется программный компонент, использующий ИИ для выполнения ограниченной роли в процессе и, при разрешении, обращения к инструментам. Это рабочее определение, а не утверждение о сознании или самостоятельной ответственности. Юридическую и управленческую ответственность не получает имя помощника в интерфейсе; её нужно распределить между людьми и системами компании.

Сквозной учебный процесс

Мы рассмотрим подготовку заявки на пополнение производственных расходных материалов. Нужно обнаружить потребность, проверить исходные данные, подготовить варианты и передать уполномоченному сотруднику решение. Компания, позиции, суммы и объёмы вымышлены. Это учебная архитектура, не описание уже внедрённого продукта EVOLVIN и не измеренный клиентский кейс.

На первом этапе система может читать разрешённые сведения и готовить черновик заявки. Выбор поставщика, принятие обязательства и отправка заказа остаются отдельными действиями с собственными основаниями. Рамка процесса должна быть видна до того, как команде откроют доступы.

Пять вопросов до подключения

Какое событие запускает работу? Какой проверяемый результат нужен? Какие данные разрешено использовать? Какие действия допустимы? Кто принимает результат и разбирает исключение? Если ответы расплывчаты, команда будет по ходу проекта расширять поручение до всего, что технически доступно.

Не каждая роль требует ИИ. Проверку обязательных полей, арифметику и разрешения часто разумнее реализовать обычным кодом. Языковая модель полезна для неструктурированного материала и подготовки объяснения; это не причина поручать ей каждый переход состояния.

Задание собственнику

Опишите первого агента одним абзацем без названия технологии: событие, вход, результат, разрешённое действие и человек, принимающий работу. Затем назовите действие, которое этой роли точно запрещено. Если запрет существует только в надежде на осторожность модели, архитектура ещё не закончена.

Следующая глава →

Глава 02 / 12

Описать состояние работы и границу завершения

В учебном процессе обнаружена позиция с низким доступным остатком. Это ещё не означает, что её нужно немедленно покупать: могут существовать резерв, подтверждённая поставка, замена материала или решение остановить выпуск. Состояние «замечен сигнал» нельзя незаметно превратить в «заказ утверждён».

Сначала опишите путь работы. Сигнал получен; исходные данные проверены; потребность рассчитана; черновик подготовлен; решение принято; действие выполнено; результат подтверждён. У каждого перехода есть основание. Если основание отсутствует, работа переходит в ожидание или исключение, а не движется дальше за счёт убедительного объяснения ИИ.

Учебный процесс · состояния и основания

Сигнал потребности ещё не означает заказ

Сигнал

Получена информация о потребности

Проверка данных

Подтверждены источники, единицы и актуальность

Подготовка драфта

Расчёт и объяснение с открытыми вопросами

Решение человека

Подтверждена конкретная версия

Передача в очередь

Получен идентификатор и понятный статус

В первом контуре завершается подготовка проверенного драфта, а не покупка.

SVG ↓Мобильный SVG ↓Поделиться схемой ↗

Отделить результат инструмента от результата процесса

Успешный ответ интерфейса может означать только приём запроса. Он не всегда подтверждает запись, исполнение или получение адресатом. Поэтому для значимого действия нужен проверяемый идентификатор и понятный статус. «Черновик создан», «поставлен в очередь» и «заказ исполнен» — разные события.

В первом контуре нашей учебной системы завершение означает, что проверенный черновик попал в рабочую очередь уполномоченного сотрудника и получил идентификатор. Оно не означает покупку, поступление товара или экономию. Ограниченная граница завершения позволяет проверить полезность, не подключая все последующие действия одновременно.

Исключение — часть процесса

Если источник недоступен, единицы противоречат друг другу или нужного полномочия нет, результатом может быть корректная остановка. Это полезный исход, если система объясняет, чего не хватает и кто должен решить вопрос. Скрытый бесконечный повтор не является обработкой исключения.

Для ожидания назначьте срок пересмотра и владельца. Запись «нужно уточнить» без ответственного способна оставить заявку незавершённой на неопределённое время. Человек должен видеть не только список обработанных задач, но и работу, застрявшую между состояниями.

Задание собственнику

Нарисуйте состояния одной работы и для каждого перехода назовите основание. Укажите, где процесс завершает автоматическое действие и где начинается решение человека. Уберите формулировки, которые смешивают попытку, приём запроса и подтверждённое исполнение.

Следующая глава →

Глава 03 / 12

Роли: разделить работу, не размножая сложность

Для подготовки заявки можно выделить приём данных, расчёт потребности, поиск допустимых вариантов, проверку драфта и передачу решения. Это роли процесса. Из них не следует, что нужно немедленно строить пять отдельных автономных агентов. Иногда достаточно одной модели, нескольких проверок кодом и существующего согласования в учётной системе.

Разделение становится полезным, когда у ролей различаются данные, права, критерии результата или способ проверки. Компоненту, извлекающему поля из запроса, не нужен доступ ко всем коммерческим условиям. Проверка суммы не требует права отправить заказ. Чёткая роль уменьшает пространство ошибок и упрощает объяснение результата.

Карточка роли

Для каждой роли опишите цель, разрешённые входы, выходной формат, допустимые инструменты, пределы расходов и повторов, запрещённые действия, критерии проверки и маршрут исключения. В карточке должен быть назван владелец. Фраза «за это отвечает агент» только переносит вопрос в интерфейс.

Не надо делать роль «контролёр», которая просто читает ответ первой модели и соглашается. Если обе используют один неверный источник, согласие не создаёт независимого доказательства. Для существенных полей нужны проверяемые основания, а для действий — контроль полномочий вне свободного текста модели.

Цена дополнительного участника

Каждая новая роль создаёт передачу состояния, задержку, стоимость вызовов и необходимость разбирать разногласия. Нужен ответ: какое конкретное свойство улучшается? Если разделение не даёт более узких прав или измеримого качества, оно может усложнять сопровождение без пользы.

В учебном проекте начинаем с двух ИИ-функций: разбор неструктурированного запроса и объяснение подготовленной заявки. Расчёт потребности, проверка обязательных полей и управление состояниями выполняются проверяемыми правилами. Такой выбор не является универсальным шаблоном; он следует из границ именно этой задачи.

Задание собственнику

Для каждой предложенной роли спросите, почему её нельзя заменить правилом, существующей функцией системы или объединить с соседней. Оставьте отдельными те границы, где различаются полномочия и проверка, а не только красивые названия.

Следующая глава →

Глава 04 / 12

Данные: у результата должно быть происхождение

В учебной карточке позиции числится 120 штук. Из них 100 зарезервированы. Доступно 20. Плановое потребление — 80 штук в неделю, горизонт поставки — две недели, условный запас — 40. Целевой объём для этого горизонта равен 80 × 2 + 40 = 200. Если до нужной даты подтверждено поступление 100, расчётная потребность — 200 − 20 − 100 = 80 штук.

Если поступление не подтверждено или не укладывается в горизонт, его нельзя автоматически вычитать. Тогда при тех же прочих условиях получится 180 штук. Это учебная логика одной позиции, а не универсальная модель управления запасами. В ней нет партийности, ограничений склада, нескольких площадок, динамики спроса и прочих особенностей реального планирования.

Одинаковое число может означать разное

В одной системе единица — штука, в документе поставщика — упаковка из десяти штук. Потребность 80 штук соответствует восьми таким упаковкам. Если отправить число 80 как количество упаковок, получится 800 штук. Это десятикратное расхождение, которое не исправляет красивое объяснение заявки.

Храните значение вместе с единицей, источником, временем среза и статусом. Ссылки на строки или документы должны позволять проверить, откуда получен результат. При конфликте версий нельзя молча выбирать удобное число. Нужно установленное правило приоритета или исключение для человека.

Проверка актуальности

Не все данные стареют одинаково. Описание материала может меняться редко, остаток — после каждой операции. Поэтому срок пригодности определяется видом данных и процессом. Если между подготовкой драфта и утверждением изменился существенный параметр, потребуется повторная проверка или явное предупреждение.

В журнале полезно сохранять версии источников, на основании которых принято действие, в разрешённом объёме и с установленным сроком хранения. Полное копирование всех документов «на всякий случай» создаёт собственный риск. Доступ к журналу должен соответствовать содержимому, а не быть общим только потому, что его создал ИИ.

Задание собственнику

Для пяти ключевых полей будущего агента найдите источник истины, единицу, допустимую давность и способ разбора конфликта. Проверьте, можно ли воспроизвести расчёт после обновления исходной системы. Если нельзя, определите, какое свидетельство нужно сохранять.

Следующая глава →

Глава 05 / 12

Полномочия: запрет должен исполняться системой

Поручение «не отправлять заказ без согласования» полезно, но недостаточно, если помощнику одновременно доступен инструмент отправки с неограниченными правами. Ошибка текста, чужая инструкция или неправильная интерпретация могут превратиться в действие. Граница полномочий должна проверяться там, где действие исполняется.

Для каждого инструмента определите, что можно читать, что можно создавать как черновик, что требует подтверждения и что запрещено. Доступ задаётся по конкретным объектам и действиям. Право читать одну заявку не означает право читать весь архив другой организации. Право предложить сумму не означает право изменить утверждённый лимит.

Матрица первого контура · редакционная модель

Права задаются по действиям, а не по уверенности модели

Разбор запроса

Чтение: разрешённый вход. Выход: поля. Автозаказ: нет.

Расчёт

Чтение: проверенные поля. Выход: количество кодом. Автозаказ: нет.

Проверка

Чтение: нужные основания. Выход: замечания. Автозаказ: нет.

Передача

Чтение: утверждённая версия. Выход: запись в очередь. Автозаказ: нет.

Подготовка заявки не требует права создать обязательство перед поставщиком.

SVG ↓Мобильный SVG ↓Поделиться схемой ↗

Утверждение привязано к содержанию

Человек должен видеть, какую версию и какое действие он подтверждает. Если после подтверждения изменились количество, сумма, поставщик или получатель, старое согласие нельзя автоматически применять к новой конструкции. Иначе кнопка утверждения проверяет лишь факт нажатия, а не принятое обязательство.

В учебном контуре черновик передаётся в существующую очередь согласования. Система фиксирует идентификатор, версию, подтверждающего и разрешённое действие. Независимая проверка полномочий перед выполнением не должна полагаться на пересказ модели: «руководитель вроде согласился».

Минимально достаточные права

OWASP относит избыточные функции, права и автономность к причинам риска excessive agency [S3]. Для нашего проекта это означает узкие инструменты и контроль существенных действий. Из этого не следует, что один список правил полностью устраняет риск; конкретная интеграция нуждается в проектировании и испытании.

В пилоте лучше не подключать действие, которое не требуется для проверки гипотезы. Если измеряется качество подготовленной заявки, права на банковские операции и изменение справочника поставщиков не нужны. Такие возможности увеличивают последствия ошибки, не делая эксперимент информативнее.

Задание собственнику

Составьте матрицу ролей и действий. У каждой разрешённой ячейки назовите технический механизм ограничения. Проверьте один запрещённый вызов в тестовой среде: система должна отказать, даже если модель считает действие разумным.

Следующая глава →

Глава 06 / 12

Внешний документ не должен становиться начальником агента

Поставщик прислал описание товара. Внутри есть фраза, предлагающая игнорировать предыдущие указания и отправить внутренние условия на другой адрес. Для человека это выглядит посторонней инструкцией. Система, которая смешивает текст документа с правилами управления, может воспринять её иначе.

OWASP описывает прямые и косвенные prompt injection, в том числе инструкции во внешних материалах [S2]. Внешний текст нужно рассматривать как данные с ограниченным доверием. Даже полезный и разрешённый документ не получает права изменить роль агента, область доступа и маршрут отправки.

Граница доверия · редакционная модель

Внешний текст — данные с ограниченным доверием

Внешний документ

Содержимое не меняет правила процесса

Извлечение полей

Только разрешённые данные со ссылкой

Проверка полномочий

В системе исполнения, не по пересказу ИИ

Существенное действие

Только в подтверждённой версии и области

Документ не может расширить доступ, сменить получателя или отменить подтверждение.

SVG ↓Мобильный SVG ↓Поделиться схемой ↗

Несколько независимых границ

Разделяйте управляющие правила и внешние материалы. Используйте узкие интерфейсы с проверяемыми параметрами. Ограничивайте доступ по объектам и действиям. Существенные операции проверяйте перед исполнением. Отсутствие ненужного права полезно именно потому, что не зависит от успешности распознавания каждой хитрой инструкции.

Нельзя помещать секрет в текстовый контекст и одновременно рассчитывать, что модель никогда его не повторит. Ключи и разрешения должны обслуживаться соответствующим техническим контуром, а не появляться в свободном ответе. Приведённые принципы не заменяют конкретную модель угроз и проверку безопасности системы.

Проверять поведение на границе

В набор испытаний включите документ с посторонней инструкцией, ссылку за пределами разрешённой области, просьбу изменить получателя и попытку получить чужой объект. Важно проверить фактический отказ инструмента или передачу на проверку, а не только текстовое обещание агента соблюдать правила.

Журнал должен позволять увидеть, какой вход вызвал предложенное действие и почему оно было разрешено или отклонено. При этом доступ к исходному материалу и журналу ограничивается. Отладочный след не должен становиться общей копией конфиденциальных данных компании.

Задание собственнику

Выберите один внешне правдоподобный документ и добавьте в тестовую копию инструкцию, не относящуюся к задаче. Проверьте систему в изолированном контуре без реальных отправок и платежей. Результат испытания — наблюдаемое поведение на границе, а не уверенный ответ на вопрос «ты безопасен?».

Следующая глава →

Глава 07 / 12

Исполнение: повторы, лимиты и подтверждение результата

Инструмент создания черновика не ответил вовремя. Агент повторил запрос. Первый вызов на самом деле успел создать запись, поэтому теперь в очереди два одинаковых задания. Языковая часть могла работать без ошибок; проблема возникла в организации исполнения.

Для значимого действия нужен способ связать повтор с исходным намерением. Идентификатор запроса и проверка его содержания позволяют отличить повтор той же операции от новой. Сам термин «идемпотентность» не является гарантией: нужно проверить, как именно интеграция обрабатывает повтор, изменение содержимого и неопределённый результат.

Неопределённый исход

Если система не знает, выполнился ли первый запрос, она не должна слепо повторять действие с последствиями. Сначала проверяется статус по идентификатору или выполняется предусмотренная процедура сверки. Если технический интерфейс не даёт надёжно проверить результат, граница автоматизации должна учитывать это ограничение.

В учебном контуре повтор подготовки той же версии заявки возвращает существующий идентификатор. Изменённое содержимое требует новой версии и проверки. Система не объявляет, что человек согласовал действие, лишь потому, что оно оказалось в очереди.

Ограниченный бюджет исполнения

Для процесса задаются пределы времени, числа обращений к инструментам, стоимости и объёма работы. Достижение предела должно приводить к понятной остановке или передаче человеку. Неограниченная попытка «додумать до конца» делает стоимость и задержку непредсказуемыми.

Повторы разделяются по причине. Временная недоступность, отсутствие права, неправильные данные и бизнес-отказ требуют разных действий. Повторять запрещённую операцию десять раз не полезнее, чем один раз получить отказ. Обратная связь должна помогать исправить причину, а не только запускать новый вызов.

Задание собственнику

Попросите показать четыре испытания: обычное исполнение, повтор того же запроса, изменение данных при прежнем идентификаторе и потеря ответа после выполнения. Для каждого результата определите, что видит сотрудник и как предотвращается повторное последствие.

Следующая глава →

Глава 08 / 12

Экономика: считать время до принятого результата

В учебной компании обрабатывается 600 заявок в месяц. Ручной процесс занимает в среднем 16 минут на заявку, всего 160 часов. После изменения 480 типовых заявок требуют по пять минут человеческой проверки, а 120 исключений — по 15 минут. Это 40 и 30 часов соответственно. Ещё 30 часов в месяц уходят на сопровождение, обновление базы и разбор процесса. Итого человеческая работа — 100 часов, высвобождается 60.

Все значения условны. Время работы модели не приравнивается к труду сотрудника; стоимость технического исполнения учитывается отдельно. Если проверяющий должен ждать ответ системы, такое ожидание также нужно исследовать, а не автоматически считать свободным временем.

Денежная оценка мощности не равна деньгам на счёте

При условной оценке часа 1 500 ₽ высвобождённые 60 часов соответствуют 90 тыс. ₽ трудовой мощности. Дополнительные внешние расходы на работу решения в примере — 60 тыс. ₽ в месяц. Разность 30 тыс. ₽ — сопоставление в выбранной модели до разовых затрат. Это не подтверждённая экономия фонда оплаты труда и не денежный доход.

Если зарплаты не уменьшаются и дополнительная полезная работа не возникает, компания может получить свободные часы и одновременно новые денежные выплаты. Поэтому собственнику нужны раздельно бюджет расходов, изменение занятости и механизм превращения мощности в результат. Разовые затраты на запуск, обучение и изменение систем также должны быть включены в решение, хотя в этом коротком месячном сравнении они не заданы.

Учебный расчёт · тыс. ₽/мес · не денежная экономия

7,5 минуты — порог только этой учебной модели

Исходно

600 × 16 минут = 160 часов в месяц

Проверка 5 минут

Труд 100 ч; высвобождено 60 ч; сравнение +30 тыс. ₽

Проверка 7,5 минуты

Труд 120 ч; высвобождено 40 ч; сравнение 0

Проверка 8 минут

Труд 124 ч; высвобождено 36 ч; сравнение −6 тыс. ₽

При пяти минутах сравнение даёт +30 тыс. ₽ мощности за вычетом расходов; при восьми — −6 тыс. ₽.

SVG ↓Мобильный SVG ↓Поделиться схемой ↗

Чувствительность к проверке

Если типовую заявку проверяют восемь минут, человеческая работа становится 64 + 30 + 30 = 124 часа. Высвобождается 36 часов, условная оценка — 54 тыс. ₽, что меньше дополнительных расходов 60 тыс. ₽. Разность составляет −6 тыс. ₽ до разовых затрат. Ускорение генерации не спасает модель, если основная нагрузка ушла в проверку.

При неизменных остальных допущениях равенство оценок достигается при 7,5 минуты проверки типовой заявки: 120 часов нового труда, 40 высвобождённых часов и 60 тыс. ₽ условной мощности. Это расчётный порог учебной модели, не норматив качества и не аргумент сокращать проверку ниже необходимой. Сначала обеспечивается допустимое качество, затем оценивается экономика.

Задание собственнику

На одном процессе соберите полный труд до принятого результата и новые расходы. Отдельно покажите исключения и сопровождение. Измените время проверки и долю исключений. Назовите, какая часть ожидаемой пользы действительно повлияет на деньги или измеримый выпуск, а какая останется резервом мощности.

Следующая глава →

Глава 09 / 12

Испытания: критическая ошибка не растворяется в среднем

Система аккуратно подготовила большинство заявок и один раз перепутала штуки с упаковками. Средняя оценка текста может оставаться высокой, хотя риск процесса неприемлем. Поэтому критерии испытания должны соответствовать последствиям ошибок, а не только удобству получения общей цифры.

Для учебного контура отдельно проверяются правильность позиции и единиц, допустимость источников, полнота обязательных полей, соблюдение прав, отсутствие дублей и корректность статуса. Стиль пояснения оценивается отдельно. Красивое описание не компенсирует заявку на 800 вместо 80 штук.

Правила допуска · редакционная модель

Критическую ошибку нельзя усреднить со стилем

Критическое нарушение

Остановить действие и передать на разбор

Несущественный дефект

Исправить по принятому правилу

Нет наблюдавшихся нарушений

Допуск только в проверенных условиях

Расширение полномочий

Новые испытания и отдельное решение

Позиция, единицы, права и отсутствие дублей проверяются отдельно от качества текста.

SVG ↓Мобильный SVG ↓Поделиться схемой ↗

Набор случаев до настройки

Подготовьте типовые и сложные разрешённые примеры, недостаток данных, конфликт версий, недоступность инструмента, повтор и постороннюю инструкцию во входе. Для каждого случая заранее определите ожидаемое действие: подготовить драфт, запросить уточнение, отказать или передать человеку. Не меняйте правильный ответ после просмотра результата только для улучшения итогового показателя.

Часть случаев полезно отложить от настройки и использовать для отдельной проверки. Если разработчик многократно подгонял систему под один набор, успех на нём не доказывает обобщение. Также сохраняйте версию модели, правил, данных и инструментов, с которой получен результат.

Условия остановки

Для критических нарушений задайте правило остановки пилота или отключения действия. Отсутствие такого нарушения в ограниченном наборе означает только, что его не наблюдали в этих условиях. Оно не доказывает нулевую вероятность в эксплуатации. Допуск к более широкому контуру должен учитывать остаточную неопределённость и возможность восстановиться после ошибки.

Нельзя расширять права только потому, что агент хорошо пишет пояснения. Каждое новое действие меняет последствия и требует соответствующих испытаний. Согласованный отчёт должен содержать также непроверенные условия и нерешённые ограничения.

Задание собственнику

Назовите три ошибки, после которых пилот останавливается, и три менее существенных дефекта. Проверьте, что они учитываются раздельно. Попросите предъявить не только итоговую оценку, но и конкретный вход, ожидаемое действие, фактическое поведение и основание решения по каждому критическому случаю.

Следующая глава →

Глава 10 / 12

Запуск: расширять контур по доказательствам

Демонстрация обычно показывает удачный путь на подготовленных данных. Эксплуатация добавляет неполные запросы, новые версии документов, занятых проверяющих и сбои соседних систем. Поэтому запуск — отдельная управленческая работа, а не перенос кнопки из тестового окна в общую сеть.

Для первого контура определите пользователей, разрешённые объекты, объём, срок, способ проверки и возврат к обычному процессу. Пока система только предлагает драфты, можно сравнивать их с действующим способом подготовки без реальных внешних последствий. Но даже такой режим требует разрешённого доступа к данным; слово «теневой» не отменяет правила их обработки.

Небольшой рабочий объём

После проверки можно допустить ограниченный объём с обязательным контролем. Важно, чтобы сотрудники действительно имели время и компетенцию для проверки. Формальное подтверждение человеком, который не видит исходных данных или не может остановить работу, не создаёт содержательного контроля.

Порядок расширения зависит от результатов: устойчивость данных, качество, время проверки, исключения и работа восстановления. Нельзя автоматически увеличивать полномочия по календарю проекта. Если ограниченный контур не даёт приемлемого результата, его пересматривают или останавливают, а не называют временную нестабильность признаком прогресса.

Версии и откат

Изменение модели, источника, инструкции или инструмента способно изменить поведение. Поэтому выпуск описывает связанный набор версий, повторно проверенные случаи и способ возврата. Откат текста инструкции не обязательно отменяет уже созданные записи или отправленные сообщения. Восстановление последствий проектируется отдельно.

В учебном процессе возврат означает остановить автоматическую подготовку и передать новые заявки в существующую ручную очередь, сохранив состояния уже начатых работ. Часть драфтов может потребовать повторной проверки. Компания должна знать, кто принимает это решение и как команда узнает о смене режима.

Задание собственнику

До первого рабочего запуска попросите показать ограничение объёма, выключение автоматической функции и ручной маршрут. Пройдите один такой сценарий в тестовой среде. Если процесс нельзя продолжить без агента, это отдельная зависимость, которую нужно принять осознанно.

Следующая глава →

Глава 11 / 12

Инциденты и сопровождение: проект не заканчивается запуском

Сотрудник замечает лишнюю заявку. Главный вопрос в первые минуты — не насколько убедительно агент объяснит её появление, а продолжаются ли похожие действия и можно ли ограничить последствия. Нужны сигнал, право остановки, сохранение свидетельств и человек, управляющий восстановлением.

Рабочая последовательность

Сначала ограничьте затронутое действие и определите масштаб. Затем зафиксируйте состояние и версии в разрешённом объёме. После этого разберите причину: данные, правила, доступ, повтор, инструмент или интерпретация. Исправление проверяется на соответствующих случаях; возвращение в рабочий режим подтверждает уполномоченный человек.

Контур восстановления · без обещания сроков

Возврат в работу — отдельное решение

Обнаружить

Сигнал и назначенный ответственный

Ограничить

Остановить затронутое действие и фоновые повторы

Сохранить

Состояние и свидетельства в разрешённом объёме

Разобрать

Данные, правила, права, инструмент или повтор

Проверить

Исправление и соответствующие тесты

Возобновить

Подтверждение человека и контроль режима

Исправить инструкцию недостаточно: нужно проверить последствия и незавершённую работу.

SVG ↓Мобильный SVG ↓Поделиться схемой ↗

Автоматический повтор после ошибки может увеличить ущерб. Поэтому аварийная остановка должна контролировать не только интерфейс, но и фоновые задания и очереди. При этом остановка не должна уничтожать сведения о незавершённой работе. Конкретная реализация зависит от системы и проверяется отдельно.

Журнал без иллюзии всезнания

Полезный след связывает идентификатор работы, версии, использованные основания, предложенное и выполненное действие, подтверждение и итоговый статус. Он не обязан содержать полный свободный диалог со всеми секретами. Доступ, срок хранения и объём записей определяются содержанием и применимыми требованиями.

Наличие журнала не означает, что ошибки кто-то заметит. Назначьте, какие сигналы просматриваются, кому они приходят и как быстро требуется реакция для этой операции. Не обещайте универсальное время устранения до понимания характера процесса и доступности команды.

Кто владеет решением после внедрения

Процессу нужен бизнес-владелец, техническая поддержка, ответственные за данные и за допуск изменений. В маленьком контуре роли могут совмещаться, но их обязанности должны оставаться различимыми. Поставка программного компонента без этих решений оставляет собственнику работающую демонстрацию и неуправляемую зависимость.

Задание собственнику

Проведите учебный разбор: система создала дубликат после потери ответа. Кто останавливает повтор, где ищет исходный идентификатор, кто проверяет последствия и разрешает возврат? Зафиксируйте пробелы, обнаруженные в упражнении. Это подготовка, не доказательство полной готовности ко всем инцидентам.

Следующая глава →

Глава 12 / 12

Рабочая тетрадь: договориться о первом контуре

Первые пять форм нужны для общего языка собственника, владельца процесса и команды реализации. Они не заменяют техническую документацию, проверку безопасности и применимых требований. Их задача — сделать видимыми решения, которые иначе растворятся между демонстрацией и запуском.

Форма 1. Паспорт процесса

Запишите событие запуска, вход, результат, получателя результата и границу завершения. Укажите владельца процесса, пользователей, исключения и ручной маршрут. Отдельный вопрос — можно ли вообще улучшить задачу без ИИ. Иногда достаточны единый справочник, обязательные поля или устранение лишнего согласования.

Форма 2. Роли, данные и полномочия

Для каждой роли заполните разрешённые источники, выход, инструменты, пределы и запреты. Укажите, как технически ограничивается действие. Для существенного результата определите подтверждающего человека и версию, к которой привязано его решение. Не оставляйте общую ячейку «полный доступ по необходимости».

Форма 3. Испытания и допуск

Для каждого критического случая укажите вход, ожидаемое действие, способ проверки и правило остановки. Добавьте версии модели, данных и правил. Условия, которые не проверены, остаются в отчёте отдельным списком. Испытание на подготовленном наборе не называется гарантией безопасной эксплуатации.

Форма 4. Экономика и пилот

Запишите исходное время процесса, новое время до принятого результата, исключения, сопровождение, внешние расходы и разовые затраты. Отделите мощность от денег. Укажите ограниченный объём, срок оценки, ответственных и условия продолжения. Порог учебной модели не переносится на другой процесс без нового расчёта.

Форма 5. Эксплуатация и восстановление

Опишите сигналы, канал реакции, право остановки, судьбу незавершённых работ, сохранение свидетельств, ручной маршрут и решение о возврате. Назовите владельца данных и человека, утверждающего изменения. Проверка восстановления должна входить в подготовку, а не впервые происходить во время реального сбоя.

Итоговое решение собственника

На столе должны оказаться понятная граница процесса, доказательства работоспособности, остаточные ограничения, экономика и способ остановки. Тогда решение можно принять содержательно: запускать ограниченный контур, дорабатывать, отложить или отказаться. Число агентов, название модели и скорость демонстрации сами по себе этого решения не определяют.

Полезная автономность заканчивается там, где заканчиваются проверенные полномочия.

Об авторе и источниках →