Работа с ИИ-агентами после запуска держится на конкретных людях. Владелец процесса определяет, какой результат нужен и принимает его; проверяющий смотрит выборку и разбирает ошибки; технический владелец управляет доступами и изменениями. Если агент неверно обработал реальную сделку, сначала останавливают опасное действие и проверяют, что уже произошло, затем исправляют последствия и меняют правило работы. Директору стоит начать с простого вопроса: кто по имени отвечает за результат агента в этом процессе? Без ответа запуск еще не готов к самостоятельной работе.
В Нейропреме мы внедряем ИИ и автоматизируем бизнес-процессы и производство. Для работы с документами предлагаем распознавать заявки и счета, проверять договоры на риски и связывать обработку с действующими учетными программами. После запуска особенно важно разграничить подготовку ответа системой и подтверждение действия человеком: красивый текст агента сам по себе еще не означает согласованную цену, верную номенклатуру или право отправить предложение клиенту.
Представим возможный сценарий. Агент читает письмо с заявкой на изготовление детали, извлекает параметры из вложения, находит похожую позицию в учете и готовит ответ менеджеру. Пока он создает черновик, ошибку можно исправить до отправки. Если агент сам отсылает клиенту срок и цену, та же ошибка уже касается обещания по сделке. Назначенные люди и права действия определяют, в какой момент ее заметят.
Кто принимает работу агента и отвечает за результат?
Владелец процесса - руководитель того участка, где используется результат агента. В продажах это может быть руководитель продаж, в снабжении - руководитель закупок. Он формулирует задачу в терминах работы отдела, назначает границы самостоятельных действий и принимает результат. Разработчик модели не может вместо него решить, допустимо ли обещать заказчику поставку при неподтвержденной загрузке производства.
Владельцу нужна конкретная единица результата. Для заявки это карточка с исходным письмом, чертежом, извлеченными требованиями и отметкой, чего не хватает. Для договора - список спорных пунктов с отсылкой к документу. Формула «агент помогает менеджерам» не сообщает, какую запись менеджер должен получить и что произойдет, если сведений недостаточно.
Затем владелец определяет приемку. Какие поля сотрудник сверяет с первоисточником? Какое условие переводит заявку из черновика в предложение? Кто решает вопрос, когда чертеж не совпадает с типовой спецификацией? Если правила отдела существуют только в устной практике, их придется согласовать. Мы можем помочь собрать документы, регламенты и базу знаний; готовый комплект не требуется для первого разговора о задаче.
При ошибке владелец решает судьбу конкретной сделки: останавливать ли отправку, кто свяжется с клиентом, можно ли сохранить прежние условия или потребуется новое согласование. Он также решает, какую часть работы возвращать агенту после исправления. ИТ-специалист может ограничить кнопку отправки, но хозяйственное решение о цене и сроке остается за отделом.
Чтобы назначение было настоящим, назовите имя, заместителя и способ связи в отсутствие владельца. Иначе любое исключение вернется к директору, а формальная надпись «ответственный отдел продаж» не поможет менеджеру в момент спорного обещания.
Кто заметит ошибку, если директор не читает каждую заявку?
Проверяющий смотрит реальные результаты агента по заранее выбранным признакам и поднимает спорные случаи владельцу процесса. Им может быть опытный менеджер или специалист по качеству данных. Вместо формальной подписи каждого ответа он ищет расхождения там, где неверная запись способна перейти в следующее действие.
Контроль выбирают по последствиям. Черновик с неверным названием детали можно поправить перед отправкой; обещанная без согласования цена или отправленный чужому адресату договор требуют немедленной реакции. Поэтому выборка обычных заявок полезна для поиска повторяющейся ошибки, а все операции с изменением условий сделки могут требовать подтверждения уполномоченного сотрудника до отправки. Выборочный контроль уже отправленных писем не заменяет эту границу.
Проверяющему нужны исходное письмо и вложения, запись в учетной системе, версия инструкции, по которой агент работал, и журнал его действий. Если он видит только итоговый ответ «все обработано», он не выяснит, откуда взялась неверная характеристика материала. Сверка с источником важнее объяснения самого агента: система может связно описать действие и при этом ошибиться в фактах.
Проверку стоит распределить во времени. На старте и после изменения инструкции смотрят больше обычных и нетипичных входов; позже частоту можно пересматривать по найденным ошибкам и цене их исправления. Не стоит заменять проверку одним процентом «точности»: верно прочитанная фамилия, правильная цена и корректно выбранный получатель письма имеют разные последствия. Зафиксируйте, какие расхождения проверяющий исправляет сам, а какие сразу передает владельцу процесса.
У проверяющего должно быть право остановить выпуск конкретного результата. Если он обнаружил ошибку, но письмо продолжает уходить автоматически, роль существует только на бумаге. При повторяющемся дефекте проверяющий отмечает класс входов, на которых агент ошибается, и передает техническому владельцу примеры для воспроизведения.
Кто управляет доступами и изменениями агента?
Технический владелец отвечает за то, какие данные агент читает, какие действия ему доступны, какая инструкция действует сейчас и что меняется при обновлении. Это может быть руководитель ИТ или назначенный специалист. Он не утверждает цену сделки; его ответственность - чтобы решение владельца процесса о границах работы было реализовано в системе.
Если агенту нужно найти данные заказа, доступ на чтение не должен автоматически давать право менять заказ. Если он готовит письмо, отправка может оставаться отдельным действием сотрудника. Текст в инструкции «не отправляй без разрешения» полезен как подсказка, но само право отправки лучше ограничивать настройками доступа и подтверждением в рабочей программе. Тогда неправильный ответ модели останется черновиком без обязательства перед клиентом.
Технический владелец хранит действующую версию инструкции и проверяет изменение на знакомых примерах: обычной заявке, письме с противоречивыми вложениями, документе с пустым обязательным полем. После обновления важно понять, не изменилась ли обработка старых типов входа. Ему также нужен способ приостановить конкретное действие агента, например отправку писем, сохранив возможность просматривать поступающие заявки.
После запуска права приходится пересматривать. Если агент начал готовить ответы по новому виду заявок, технический владелец сверяет список доступных ему документов и действий с новой задачей, а владелец процесса подтверждает, кто вправе принять результат. Если сотрудник, подтверждавший отправку, сменил должность, технический владелец обновляет маршрут согласования и убирает прежний доступ. Иначе письмо может уйти по старому правилу к человеку, который уже не отвечает за эту сделку.
Проверяющий может заметить повторяющуюся ошибку в маркировке материала. Технический владелец выясняет, изменилась ли инструкция, справочник или связь с учетной программой. Владелец процесса подтверждает, какое правило выбора должно действовать. Так исправление получает и техническое основание, и хозяйственный смысл.
Что делать, если агент уже ошибся на реальной сделке?
Начните с ограничения дальнейших действий и установления фактов. Представим сценарий: агент взял срок поставки из старой версии коммерческого предложения и отправил его покупателю вместе с верной спецификацией. Нельзя считать ошибку исправленной только потому, что агент подготовил новое письмо. Нужно выяснить, что получил покупатель, какую запись сохранила система и успели ли сотрудники принять на себя обязательство или запустить производство.
- Остановите распространение ошибки. Проверяющий сообщает владельцу процесса, технический владелец приостанавливает автоматическую отправку для затронутого типа предложений. Остальные функции отключают лишь при необходимости: если агент продолжает читать заявки и готовить черновики без отправки, отдел не теряет весь поток работы.
- Проверьте последствия по независимым следам. Откройте отправленное письмо, карточку сделки, журнал действий и актуальную запись о сроке в производстве. Выясните, кому ушло предложение, какие условия увидел адресат и какие внутренние действия уже начались. Объяснение агента можно сохранить, но подтверждать им состояние сделки нельзя.
- Исправьте сделку силами уполномоченных людей. Владелец процесса назначает сотрудника для контакта с покупателем и согласует корректную формулировку. Если предложение стало частью договора или затронуло другие обязательства, подключают тех, кто обычно утверждает такие изменения. Сотрудник фиксирует отправленное исправление и ответ контрагента; внутренней правки карточки здесь недостаточно.
- Найдите механизм сбоя. Проверяющий собирает исходный документ и ошибочный результат. Технический владелец проверяет версию инструкции, источник срока, права отправки и маршрут подтверждения. Владелец процесса уточняет, какой срок вообще можно обещать при неполных данных. Ошибка чтения файла, устаревшее правило и слишком широкое право отправки требуют разных исправлений.
- Верните действие под контроль и испытайте исправление. Для затронутого типа предложений оставьте подтверждение человеком, пока проверяющий не увидит на подходящих примерах, что новая инструкция или интеграция дает правильный результат. Зафиксируйте принятое изменение и человека, разрешившего вернуть автоматическую отправку, если она вообще нужна этому процессу.
Этот порядок зависит от того, куда успел попасть неверный результат. Если ошибку нашли в черновике, клиенту ничего исправлять не требуется. Если письмо ушло наружу, внутреннего исправления мало. Если вместе с ошибкой раскрыты чужие данные, в разборе участвуют ответственные за безопасность и правовые вопросы компании; одно уточнение условий сделки такую ситуацию не закрывает.
Как понять, можно ли оставить агенту самостоятельные действия?
Автономия определяется по конкретному действию. Читать заявку, собирать карточку и предлагать ответ - один уровень. Менять цену в учетной системе, отправлять покупателю условия или запускать заказ в производство - другой. Для каждого шага владелец процесса сравнивает цену ошибки и возможность обнаружить ее до последствий. Проверяющий показывает, какие ошибки действительно встречаются, а технический владелец обеспечивает нужную точку подтверждения.
Для руководителя полезна короткая проверка на живом потоке: назовите ответственному сотруднику одну недавнюю заявку и попросите показать исходник, подготовленный агентом результат, кто его подтвердил и что осталось в системе. Если вместо записи есть только переписка с агентом, трудно понять, было ли принято решение и на каком основании. Если подготовленный результат позволяет быстро открыть источник и исправить поле, контроль встроен в обычную работу отдела.
Особенно показателен момент, когда агент просит исключение: у покупателя иной чертеж, в заказе несколько сроков, договор содержит приложение в другой редакции. Здесь нужен маршрут к человеку, уполномоченному решить вопрос. Назначение владельца процесса снимает с директора постоянное участие в каждой такой заявке, но не отменяет управленческого выбора: какой риск предприятие готово принять ради скорости обработки.
Право агента отправлять предложения зависит от того, где рождаются подтвержденные условия сделки. Срок и цена могут уже храниться в учетной программе или согласовываться в переписке, которую агент не видит. От этого зависит, какие письма можно выпускать без отдельного подтверждения менеджера. Мы из компании Нейропрем предлагаем обсудить путь заявки: откуда берутся условия, как фиксируется их согласование и кому передают исключения. По разговору наметим, что стоит проверить в вашей программе, прежде чем расширять права агента на отправку. Оставьте имя и телефон в форме ниже. Мы перезвоним в течение двух-трех часов.